Finite State Machine in TGB for RPG Games
by Gustavo Boni · 01/17/2007 (6:49 am) · 11 comments
Wow! This is my first blog! In the first place i want to thanks all the community for the help in the forums to learn Torque, really appreciate that.
So, let's talk about what i'm doing with Finite State Machines (FSM)^^
Months ago i created an FSM class implementation in c++ to see how it works following the excellent AI book Game Programming AI By Example. It worked nicely and i wondered how good it will be to have it working in TGB.
Thus, i thought in a prototype of a RPG game, where you would have a Warrior, an Monster and a Banker guy.
Each of them will have own states like: Eating, Sleeping, Fighting, etc. The FSM will handle all the actions making the Warrior go back to home to sleep if tired, for example.
The script code will be very simple. Basically you'll have to create a FSM to the player:
And then, create your states:
This is in the very beggining yet, i'll try to keep it as simple as i can.
Hope in the next blog show you some screens of this working too.
Thank you all for reading,
Gustavo Boni
So, let's talk about what i'm doing with Finite State Machines (FSM)^^
Months ago i created an FSM class implementation in c++ to see how it works following the excellent AI book Game Programming AI By Example. It worked nicely and i wondered how good it will be to have it working in TGB.
Thus, i thought in a prototype of a RPG game, where you would have a Warrior, an Monster and a Banker guy.
Each of them will have own states like: Eating, Sleeping, Fighting, etc. The FSM will handle all the actions making the Warrior go back to home to sleep if tired, for example.
The script code will be very simple. Basically you'll have to create a FSM to the player:
%myFSM = new FSM();
And then, create your states:
%sleeping = new State(sleeping);
This is in the very beggining yet, i'll try to keep it as simple as i can.
Hope in the next blog show you some screens of this working too.
Thank you all for reading,
Gustavo Boni
#2
01/17/2007 (7:30 am)
Funny coincidence because I was looking at this book just yesterday and thinking of AI for RPGs.
#3
i.e.
%myFSM = new FSM();
%myFSM.AddState("Resting");
%myFSM.AddState("Fighting");
You get the point. Its hard to keep the balance right when looking at torquescript vs C++, but I've found that the above interface works pretty well (i.e. the FSM is the scriptable object, everything else is managed by it).
01/17/2007 (7:41 am)
I'd suggest having the FSM object be a scriptable class, but have the states as methods/accessor functions on the FSM class, mainly because there's no need to create a "state" object in script. You can add/update/remove state objects using the FSM's methods then.i.e.
%myFSM = new FSM();
%myFSM.AddState("Resting");
%myFSM.AddState("Fighting");
You get the point. Its hard to keep the balance right when looking at torquescript vs C++, but I've found that the above interface works pretty well (i.e. the FSM is the scriptable object, everything else is managed by it).
#4
@Phil Carlisle: yup, i got it Phil, but the reason to have the state in script is because eith the state object you can create the logic for this states. I mean, you will have 3 methods: onEntryState(), onExecuteState(), onExitState().
So, lets do it with the "sleeping" state.
01/17/2007 (7:55 am)
@Chip Lambert: ok Chip, thanks man ^^@Phil Carlisle: yup, i got it Phil, but the reason to have the state in script is because eith the state object you can create the logic for this states. I mean, you will have 3 methods: onEntryState(), onExecuteState(), onExitState().
So, lets do it with the "sleeping" state.
function sleeping::onEntryState(%this, %var)
{
echo("I'm tired....");
}
function sleeping::onExecuteState(%this, %var)
{
if(tired)
{
return $TRANSITION_FIGHTING_SLEEPING;
}
}
function sleeping:onExitState(%this, %var)
{
echo("I have to wake up now... that sucks...");
}
#5
01/17/2007 (8:44 am)
I own this book aswell. It's great! :) Keep it up. 
#6
01/17/2007 (12:42 pm)
I own this book too. Unfortuanately I haven't had much time to spend with it.
#7
01/17/2007 (1:01 pm)
I own this book too :-) Keeping the logic in state objects make totally sense :-)
#8
So I could have
FSM.addState("onEnter","onUpdate","onExit","MyStateName");
It worked fine.. but I guess each to thier own.
01/17/2007 (2:12 pm)
Gustavo: Well, you could do those callbacks from the C++ object. I added a state entry into my FSM C++ class that basically had entry, update, exit script callbacks.So I could have
FSM.addState("onEnter","onUpdate","onExit","MyStateName");
It worked fine.. but I guess each to thier own.
#9
01/17/2007 (4:09 pm)
@Phil: interesting way... but you should implement the callbacks in c++ code right? it's interesting, but i'm trying to let the developer create that in script, dont allowing him to tocuh the c+ code.
#11
01/17/2007 (10:29 pm)
@Gustavo: I think Phil meant to call the TorqueScript functions you deliver from C++ which is perfectly possible. 
Associate Chip Lambert
Crusader Games