As stated in another post, I’ve made use of a state-based programming technique that manages my application’s current state. I use enumerated constants the index an array of function pointers for states. Simple, right!? I’m onto the logic part of now. The game is a class Arcade style Shoot-Em-Up with lots of bullets and enemies flying every where and power ups floating around, plus the player. I’m still researching on this for the most part. I’m trying to gain as much knowledge as I can by reading articles I come across and others input. Basically, to adopt my previous idea for states into logic is the best solution I’ve come up with. The natural FSM I would say for AI & logical processing. I’m trying to visualize the process in a whole to help me in the design. Pretty much, each object (entity) is like the FSM or state controller; in a way. They store the needed information about moving onto the next state of operation and so on. I my case, this information is position, velocity, health, etc.. Each active entity is given a turn at the processing of it’s states each iteration of the game’s loop. In these states, the logic is processing and certain events are created. For instance, a sound or particle effect such as an explosion or jet exhaust is scheduled or triggered. How does one do all this? And! What about double states? For example, and object can be moving and attacking at the same time but both those actions are separately defines. I use enumerated constants as flags to index into the array of available states, how would I specify two, three or even four states to process at one time? I would have it this way to avoid writing lots of the same code over again for several combinations of states. Anyways, about triggering events, I just make a message queue similar to Window’s message queue? Drawing is the easy one; I don’t have to build a queue for those types of things. I already have one for active entities. I just retrieve the entity’s current state (as for drawing) and render it. Then there are the particle effects that are drawn next. An emitter is a different type of object unlike an entity; it could be represented by one I guess. But an emitter has children (particles) that can’t really be represented by entities. Or maybe, should I represent them in such as way? Ordering all this information around to run smoothly is very difficult. Oh well, thanks for any comments you leave anyways.

I think hiearchial FSM states could work for you. They're kind of hard to design at first. The other thing about FSMs is that queue thing. I see a need for it to catch any events that can make you go into another state you're not ready to go into until your actions for this state are finished. Also, task driven FSM system is neato but I kind of have a half-botched FSM system. The reason for this is that it's simpler sometimes to rely on state guards to drive the logic. It depends on what makes sense in certain situations.

I was just curious to your response about hierarchical state machine. Hierarchical, from what I’ve read so far, are just the same as most other state machines. The only real difference is sub state machines. For example...

Run
- Look for enemy
- Fight enemy
- Pickup items
- etc...

So it’s pretty much just a simple FSM with good state communication. Or many of that same type of states for different parent states. For example, Run could be walk or stand.

I’m failing to see the big difference in how they work from other FMSs. I did however, gain a little insight and more knowledge. So I see your point. That, sort of answered a few questions, but also made some others. I can see how that type of FSM would be a bugger to design, or write because of the many different (and similar) states that exists. Also, just one additional state and add like 4 * N states where N is the total number of states (I actually read that from an article).

What’s getting me is how to make "Look for enemy" cooperate with Run, Walk or event Stand. I guess it’s really just a matter of breaking things down into the simplest forms. Like, look for enemy only really needs a position of an eye and a view frustum of some sort to scan with. Run, Walk and Stand and all cooperate with that easily. But other "inner" states may not be as easy. So I can see you point there too.

In any case, thanks for the reply because you actually helped my out quit a bit. You wouldn’t happen to have any more tricks up your sleeve would you?

Over looking what? I said I was going to try it, didn't I?