Is your feature request related to a problem? Please describe.
HorizontalSmoothing is a configurable field that duplicates what Unity's InputManager already provides.

Describe the solution you'd like
Remove the horizontalSmoothing field and modify the script to allow the InputAxis to handle this natively.

Is your feature request related to a problem? Please describe.
Yes, if you would like to migrate the movement controller to a new project, you would also need to migrate the animator and its parameters as well. The player's movement should be agnostic of the animation, especially knowing that we may implement the DragonBones or Spine runtimes, or Unity's 2D Animation package.

Describe the solution you'd like
Create a generic PlayerMovementController class with virtual methods for Jump() and RunDirection(Vector2 dir) that can be based and overridden to trigger specific animator implementations.

Describe alternatives you've considered
Expose subscribable events that a second script can listen to and trigger animator actions from.

Describe the bug
If something else passes through the a trigger that a SpawnPoint is listening to, enemies still start spawning.

Proposed Solution
Check the triggering GameObject (go) to see that it is the player. This should not be done using tags. Instead, check to see if the triggering GameObject has a component that only the player would have (Like PlayerLevel, or PlayerStatsSystem) and only start spawning if it exists.

Is your feature request related to a problem? Please describe.
This is non-critical. The launch parameters are lengthy and mostly related to one another. It would be beneficial to simplify this into one or two paraemeters.

Describe the solution you'd like
Simplify the input parameters with a struct, or a simple system class.

Additional context
In addition to modifying Projectile.cs, you will need to update the method callers WeaponRangedController.cs and EnemyAttackRanged.cs

Is your feature request related to a problem? Please describe.
Currently pausing occurs within the InventoryUI script, and the WeaponMelee/WeaponMelee Controllers check the timescale value to determine if the game is paused. This is obfuscating the functionality and can confuse those unfamiliar with the project.

Describe the solution you'd like
Create a singleton GameSpeed manager that contains an Enum for GameSpeed (Paused, NormalSpeed), as well as a public PauseGame() and UnPauseGame() methods that sets Time.timeScale to 0. Update InventoryUI to invoke the Pause/Unpause methods and the Weapon Controllers to check the GameSpeed instead of directly comparing against Time.timeScale.

Additional context
You will need to modify InventoryUI, WeaponMeleeController, and WeaponRangedController

Direct dependents on the PlayerStatsSystem will depend on the StatsChanged. To allow for reflection and ease development, it will be more wise to have this as a C# event that can be configured via code, rather than the current GameEvent and configured via GameEventListener.

Does the documenation already exist?
No

If no, what needs to be documented?
The interaction of the Weapon layers and the physics2d matrix that controls how these interact.

Is your feature request related to a problem? Please describe.
The PlayerMovementController has a dependency on CharacterHealth so that it can disable itself. If we continue to follow this pattern, this leaves "Death Handling" to each script themselves. Sooner than later "Death Handling" will sprawl across multiple scripts and updating or understanding what happens on death will become less manageable.

Describe the solution you'd like
A second script whose job is explicitly "Death Handling" should be implemented to disable or deactivate gameObjects and scripts that should be affected by death, keeping all of the results of a death in one script (singularly responsible). This has the added benefit of decoupling the PMC's dependency on CharacterHeatlh.

There is a minimum reloadTime before the enemy will never be able to throw projectiles (due to the animation restarting), or the animation speed will override the reloadTime.

Possible solution: Change AttackRanged to a bool, and inversely relate reloadTime with animation speed. (More convoluted, but might look prettier)

Other posible solution, Erik's suggested solution: Do not trigger projectile throwing from the animation. The first frame of the animation should match the projectile leaving the character's hands. (i.e. remove the wind-up from the animation)

Describe the bug
If an external system calls LevelUp in the PlayerLevel.cs script, the nextLevelExp is not updated.

Unsure of what the purpose of this is. targeting.target is going to be called no matter what. Storing it in a new Transform variable seems wasteful.

Doing a null check proves valuable, but it needs to happen earlier so that we aren't creating/pulling unnecessary prefabs from the Object Pool.

EnemyAttackRanged.cs line 74

Is your feature request related to a problem? Please describe.
Current lootrate is attached to the enemy's general droprate. The lootrate should still be configurable on a per-enemy basis, but it should be item specific.

Describe the solution you'd like
Combine both the item and the loot rate into a struct on the CharacterLoot class. Hold an array of LootStructs, rather than just an array of Items.

Additional context
Will require modifications to CharacterLoot.cs and EnemyTemplate.cs. May require changes to EnemyHook.cs

Is your feature request related to a problem? Please describe.
Currently enemies don't scale in difficulty as time goes on/the game progresses. There is an Enemy Scale By Level functionality, but the enemy levels don't go up over time or on level change.

Describe the solution you'd like
This can be done through increasing the Enemies' levels over time, having difficulty scale by clearing stages and reaching the next level, a mixture of the 2, or another alternative.

Additional context
This is a very abstract implementation. I would suggest modifying the EnemyScaleByLevel to customize the scaling. You will likely need to create a new script that sets CharacterLevel.

Is your feature request related to a problem? Please describe.
Enemies cannot apply force to the player reliably due to the player's velocity being set directly.

Describe the solution you'd like
The player's movement control should implement a solution using AddForce instead of setting the rigidbody's velocity directly.

Is your feature request related to a problem? Please describe.
Currently the Hud UI is maintained by 3 separate scripts. While this is technically singularly responsible, this is probably too granular.

Describe the solution you'd like
Create a generic HudUI script that manages all Hud aspects. Additionally, expose a public "UpdateUI()" method that can be called externally.

Describe the bug
The player cannot click faster than the player animation can throw. This results in a sluggish responsiveness. Tying animations to player input gameplay controls feels slow.

Related issue: #37

Is your feature request related to a problem? Please describe.
Currently the inventory system only allows weapons to be equipped.

Describe the solution you'd like
Look into using the ScriptableObject implementation of the items to generate unique iteminstances with their values specified. This should allow serialization and deserialization using our dictionary model.

Is your feature request related to a problem? Please describe.
Some users would like to have multiple different ways to jump (keyboard input, controller, mouse). This is a configuration and should not be hardcoded.

Describe the solution you'd like
Use an Input axis on the Player Movement Controller instead of a hardcoded key.