FSM's vs Scripting

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.

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.

I completely agree, FSM and Scripting shouldn't be considered mutually exclusive. If anything, they work well when they're combined. If your game objects have specific states, you can use your scripting logic to switch between them. The script would essientially glue the states together, allowing the scripter to alter the behaviours of the entites with ease. You could have hard coded "attack", "track", "flee", etc states that will need linking. It makes little sense to have a huge giant robot monster use the same state logic as smaller grunts and scripting is one of the ways you can alter this. As blowfish said, you can even script the state machine itself, adding new states from the script and specifying the logic from within its environment, it all depends on the extent of your use of scripting in the game. In the example you specified, you'd set your game states up and use scripting to control the conditions that need to be met for the game to change state. For example, your scripting logic would measure if there's no enemies left in the level, this triggering an advance to stage 2 in the game. The beauty about this is that you can essentially use the same game states and mix and match your scripting to make new levels and level objectives. One level might need you to kill all enemies, another might want you to survive for 20 minutes - you could specify this from within script.

Thanks for your responses.
I just read one of the articles on Scripting and now I have an architectural question.

Say we have a script for some badguy, Badguy002.
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 ....

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.