I'm still fiddling with the best ways to handle player input. Currently, the only player states implemented are Walk and Idle. I did solve a little problem that Golem 1 had: in Golem 1, input such as mouse clicks and such were still passed to the player even when another window, such as the character screen or inventory, was open and 'owned' the cursor. This was a result of the player control system querying SDL directly for keypresses and mouse state. Now, I've implemented a special GUI widget that bears the responsibility of relaying along input events to the player control system, rather than allowing the control system to query directly. This way, if the widget does not have the cursor focus, events are not relayed. Additionally, loss of focus from this widget triggers the clearing of all toggled state (mouse button state, for instance) in the control system, to avoid the problem of a mouse button appearing to be depressed because focus was lost before a release event was passed. This could cause the character to keep walking even while the player is fiddling around on other windows.
I've always found management of player input to be one of the trickier issues I've had to tackle in game programming.
It's been a pleasure hacking on the state machine stuff this time around. Golem 1's state machines were what they had in mind when they coined the term 'spaghetti code'. A godawful mess. This time, I'm using the function-ptr based FSM implementation outlined in Game Programming Gems 3 by Charles Farris. It works pretty well, and lends itself well to my stub-out-now/flesh-out-later process. Tracking state changes is simple, and diving back into the state code later on is not difficult to do. (There were parts of the Golem 1 state code that I absolutely dreaded diving back into. [grin] )
