In my Dreadnoughts app, I found it convenient to create a holder class (which I called Duty… Role would be a good synonym) for a particular person’s “job type”.
The Duty was updated once per sim cycle and had links to an object for UI and one for AI – it would call the UI’s update method if the local player was currently “playing” the person fulfilling the duty, and the AI would do the thinking for the person in cases where local AI control should occur.
The UI processed user inputs and updated any HUD’s. I suppose a class similar to these could have been used by entities who were under a remote player’s (or AI’s) control, but I have not done networking yet.
The nice part about having the “Duty” object was that it existed solely to be the repository of state information (e.g.: the Helmsman’s Duty would record the commanded heading whether or not that sailor was under local player control… this would ensure that if you decided to play from some other vantage point at any time that the AI would take over and be fully apprised of the heading to be steered).
tone
ok, a finite state machine is working. yay, its brilliant.
DP
Good, did you use entities for each objects state machine?
no. However, FSM machine should be created in the new proposed entity and processMessage() is called upon when a message is recieved. the processMessage() should change the FSM which changes the state at which the entity is currently in. So in a sense, entity is tied in with FSM and the messaging system.
If mojo sees my codebase as a good place to start AI, it will be included in jME and you’l see what I mean. If you want to have a look at the code anyway, email me and il send you the code.
DP
Ok, whats your email?
tomcat
am_alhindawi (at) hotmail (dot) com