Those who read my previous entry might have picked up that I was pretty pissed off with how the 4E4 game is going. After trying to make a few additions (namely combos) I realised that the current implementation is working because of sheer luck and not because it's well coded, as such it annoyed me and has set me back even more than I hoped.

Here's some information about what was going wrong...

When the player hits a key that's associated with movement, a state is set on the player object (eg: RARROW will set state 'move_right' to on). When a certain state is on, the game will call a scripted event on the object, so 'move_right' will call the script player_MoveRight. This script will move the player's avatar as well as starting the animation that shows the player moving in that direction... Sounds about right, except it is flawed.

A single keypress is echoed across a couple of frames as a 'key held' event (due to the nature of how the events are worked); because of this, the state remains set and the script is called to move the player. Again, this works but isn't how it should be working - this became evident when trying to build combos, a single press of the right arrow key would register a load of single rarrow presses and wouldn't register the 'dead' time in between. When I tried to unset the states (eg: a press triggers the event once) the game would become unresponsive to input and the animation would play on the spot.

Flow:
- Key is pressed
- State 'move_right' is set on 'player'
- Script player_MoveRight is called whilst 'move_right' is set
- Animation continues to play, regardless of moving right or not


Instead, we need to have the system set up so that the key press sets the state, triggers the initial event (to start the animation) and the presence of the state executes the separate script to actually move the player. The state will only become unset when the animation ceases, requiring the need for a callback event to be triggered at the end of the animation.

- Key is pressed
- Event player_MoveRight is called
- State 'walk_right' is set in script
- Animation started, with parameter to call event player_WalkRightEnd when animation is completed
- Whilst the walk_right flag is set, player_WalkRight is called to move the player
- When animation finished, player_WalkRightEnd is called to unset the 'walk_right' state

The input system also need some rework so that I can register 'dead' time. Specifically, I need to know if a key was pressed once, or pressed and held. I also need to know if there was any 'dead' time between the presses, the most certainly will be - but I need to be able to quantify this with a time value.

My issues come from the age-old problems of organic games/game engines. The system is allowed to grow with little or no control; sure, you may think you know where it's headed, but without things on paper, documented and written down you quickly lose sight of who owns what and where the data is coming from.