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:
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:
Is this a *decent* way of doing things without true C++ superClass support?
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.
#2
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.
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
Thanks guys ;)
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
http://tdn.garagegames.com/wiki/TorqueScript_Quick_Reference_2#package
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
Ricardo Vladimiro
Default Studio Name
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.