Game Development Community

Multiple Object States

by Phillip O'Shea · in Torque Game Builder · 10/24/2007 (2:05 pm) · 4 replies

Alrighty, I'll give you all a quick rundown of the issue that I have.

I'm designing a platformer game and I have a character, lets call him Pete. Pete runs around, jumps, does other neat things and every frame updates his physics. At the moment, I am calling the functions "onGroundPhysics", "inAirPhysics" etc. Now, I plan on having multiple player "states", so that I can do various things to Pete while under the different states all by calling "updatePhysics" instead of all of the different ones.

I was thinking of superClasses, but that went out the backdoor (if the are different to regular classes, I have no idea how they work).

So basically, what I want is something like below:

onGround
{
    UpdatePhysics(params)
        doStuff
}

inAir
{
    UpdatePhysics(params)
        doStuff
}

This will give me a nice way to neaten up all of the code I have. What I've done so far is have a rather large series of nested if statements to choose which updatePhysics function is called.

I was thinking of having a scriptObject help do this by doing something like:

sObject.superClass = "onGround" | "inAir" | "otherStates"

function onGround::UpdatePhysics()

function inAir::UpdatePhysics()

...

Is this a *decent* way of doing things without true C++ superClass support?

About the author

Head of Violent Tulip, a small independent software development company working in Wollongong, Australia. Go to http://www.violent-tulip.com/ to see our latest offerings.


#1
10/24/2007 (2:40 pm)
If I'm not mistaken class and superclass are more namespaces than actual classes. There's no big OOP here so a class and a superclass are namespaces for a series of objects on a screen. In a previous version of TGB I had a problem with those namespaces, basically you can't change an object namespace. No idea if you can do it now, but I doubt.

How I would solve it: I would write all the methods I need to update all the physics and then would have an event that would change some state on Pete. For instance, if Pete colides with the ground, change Pete.whereAmI = "onGround". Then onUpdate would have a case statemente that would invoke the appropriate methods.

Another way is not using onUpdate at all and the event of being onGround or inAir would load and remove behaviors.

I hope I understood your problem correctly and this helps.
#2
10/25/2007 (11:40 am)
This is just my rambling while attempting to think out of the box, so......

What about creating and OnGround Behavior and a InAir Behavior? You can then attach/unattach the behaviors when the state changes.

I haven't thought through the ramifications, or performance issues, but I thought I would throw it out as something to discuss.
#3
10/25/2007 (2:07 pm)
I don't know if its a really good way of doing it, but basically I have a switch statement (thanks Ricardo) and it calls "onGroundState::updatePhysics", "inAirState::updatePhysics" ... I know its a bit hacked, but it helps me tidy things up for later.

Thanks guys ;)
#4
10/26/2007 (1:54 pm)
I was poking around today and came across 'package'. What if you had methods for onGroundState and had a inAirState package that is activated on state change, thereby overriding the methods.

http://tdn.garagegames.com/wiki/TorqueScript_Quick_Reference_2#package