GunzGame: Refactoring

It is now possible to move a player unit around. It's also possible to jump by pressing space. As one might expect, having different types of actions resulted in many nested if-statements. Therefore, I decided to refactor the code, so it uses the state-pattern. Walking and standing still are handled in a common state class called WalkingState. The merge is mainly due to standing still not really being worth handling in a separate class. Jumping or just flying in the air is handled in a class called JumpState. All state classes inherit some common abstract methods from an interface called PlayerState. One of the existing downsides of using the state-pattern is that it naturally produces duplicate code, even though one could go through big efforts to minimize it. In my opinion, these efforts are not worth the time. One extra, invisible, downside with the state-pattern is that it hides something horrible... it hides... GOTO calls. Example; WalkingState calls GOTO JumpState and JumpState calls GOTO WalkingState given certain conditions. If you have too many states, these GOTO calls will cause spaghetti code. Hence, it is quite important to not use the state-pattern too much.

The state that I plan to add for this game are the following: WalkState, JumpState, SpecialMoveState1, SpecialMoveState2, SwordAttackState1, SwordAttackState2, DeadState. All states can produce a DeadState, which happen when the player runs out of HP. I should really add a class that holds all player parameters as a next step in my game development process. Now that I have started creating a state machine I may as well create all the states. SpecialMoveState1 will only be possible while holding a gun and SpecialMoveState2 only possible while holding a sword.