Jump to content
  • Advertisement
  • entries
  • comments
  • views


Sign in to follow this  


Fleshing out the state machine and AI systems to control monsters and NPCs. NPCs are currently all stubbed, outside of the basic movement states that are applicable to all creatures, so they don't really do anything but stand idle or maybe a little random walking. As far as combat and actions, I've stubbed out most of the functionality, but nothing does anything yet. All the basic states, though, are implemented. Melee attacking, ranged attacking, spell-casting, using switches/doors/etc, walking, running, picking up, dropping, etc...

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] )
Sign in to follow this  

1 Comment

Recommended Comments

I got an email from Jade last saturday, I guess I was drinking in the hot tub and missed it. He has voice chat or some thing. I'm going to have to setit up now. Have a good one. WSM

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!