Jump to content
  • Advertisement
Sign in to follow this  
Breaka

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ....

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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 actions

class 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 this post


Link to post
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!