# FSM's vs Scripting

This topic is 5402 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello... I have seen several threads here about Scripting. From some of these threads it seems that the authors make Scripting and an FSM game implementation sound like opposites. I am familiar w/ FSM's. But can someone clarify this "Scripting" idea to me? At least in the way that is explained here. Does your engine read in, say a text file, and this file dictates how the game progresses ? Example "A B C D @ % T ......" A - Load Stage one B - Show Stage one completion Animation C - Tally points screen - show points obtained in previous stage D - Start Stage 2 @ - Spawn Stage 2 Boss % - etc etc ???? Is this guess waaaaay off ? -Breaka

##### Share on other sites
Breaka, when it comes to scripting used for Artificial Intelligence, FSMs and Scripting are NOT exclusive. Scripting is just the technological "wagon" used to implement your logic. The logic in the script itself can be an FSM, Neural Nets, Fuzzy Logic, etc. My familiarity with scripting for AI is that each script adheres to an "interface" (this can be inforced (and probably should be)). When the "intelligence" needs to "processed", a method is called in the script (the script is actually loaded and compiled well before this stage for performance reasons). Whatever kind of intelligence is used within that script doesn't matter. The only thing that matters is that the code knows what to call and when.

The other approach to scripting would be something like saved games and replays. In this case, the "command processor" saves all game commands that occur into a "script" along with a timed offset of how long has expired since the previous message. And then when you replay the game, you simply have a script loader that loads the scripts and fires off the commands to the command processor when necessary.

There are a *lot* of different places you can apply scripting to your game, these are simply two of them. Think of "scripting" basically as a way to control your game from an external source like a text file.

##### Share on other sites
I'm familiar with fps games and looking at quake will show you that they use scripts for game elements like ai, door logic and offload some heavy computations like the actual door movement onto C which the engine handles. So there is a cross over point due to efficiency reasons. The quake's FSM is a pseudo FSM system implemented using function callbacks. Then engine calls your think function then you give control to the engine, since it's a callback. You can map quake's fsm onto a paper in style of fsm uml state chart. It's not easy because it's a pseudo fsm. You kind of have to figure out which functions are transitions, which are actions, etc. Kind of backwards going if you ask me. Some ID games are written with dlls for the scripts for speed reasons. In quake, your scripts can call engine built in functions as well, again for speed reasons.

##### Share on other sites
I just read one of the articles on Scripting and now I have an architectural question.

The script is as follows:

Script01{ Run, Talk, FindPlayer, AttackPlayer, End }

Should Badguy002 have this script as a member?

Or, should some controller own the script, and know which entity (in this case Badguy002) the script is for ?

How is it usually done?
Or is this up to architectural preference?
What are the pro's and cons of each?
Or is their another method I have not mentioned?

Thanks ....

##### Share on other sites
When you create a BadGuy, determine which script applies to him, and attach that script as a member of that particular BadGuy. In BadGuy::act(), check the current state of the BadGuy (point in the script), and do the appropriate thing. Basically, you want to compile the script into some data representation of an FSM. For the simple linear example, you might have

class FSMNode {  static FSMNode* parse(string filename) {    // open the file, parse a script and create a graph of    // FSMNodes.  }  map<ActionResult, FSMNode*> successors;  public:  FSMNode* goToNextState(Entity actor) {    return successors[act(actor)];  }  virtual ActionResult act(Entity actor) {}}class Run: public FSMNode {  ActionResult act(Entity actor) { /* implement running */ }}// Ditto for other possible actionsclass BadGuy : public Entity {  FSMNode* currentState;  void update() {    // Run And Return Successor pattern.    currentState = currentState->goToNextState(this);  }  public:  BadGuy(string scriptname) {    currentState = FSMNode::parse(scriptname);  }}

Just off the top of my head... :s

##### Share on other sites
Often if you use a scripting system for AI, then you can eliminate a FSM to track the agents current goal, since this is explicit within the scripting logic. What really accomplishes this is the micro-thread back-end of the scripts, and the thread-slicing is how the system "remembers" what that agent is thinking (as opposed to storing a state).

So instead of having a state called 'LookingForTarget' you can have a sub-function called FindTarget. This gives the AI scriptor much more freedom that the state-strategy method currently under discussion. I’ve never used it myself, but I think Quake C is an example of what I am talking about.

• 18
• 29
• 11
• 21
• 16