Advice/sharing on developing OO framework
by Phil Shenk · in Torque Game Builder · 07/01/2005 (5:14 pm) · 28 replies
I'm starting to move away from the "nest" of just hacking experiments together, which has me starting to think about how to organize my code. I've done some OOP in C++, so I know the theory, but I'm still pretty new at it. I'm wondering if anyone out there has some concrete advice or examples on how they've approached this.
Specifically, what I'm looking to do is create a large variety of entities that can do a large variety of things. I'd like them to have inventory, or at least modifiable properties, RPG style (i.e. + 2 to armor, +25% to damage, etc). I like the idea of having different unit types have different movement styles. For example, some might move by thrusting and applying incements to velocities (like flying, drifting), others might explicityly move location to location (like walking).
That's what I'm looking at for a unit class, at least. Beyond that though, I'm interested in talking about how AI interacts with the units, how people handle unit and game states, how unit interaction is handled, etc. I'm wondering about the big picture, not stuff like, "store unit refs in an array" type things.
Like what about events? Are people scheduling individual unit actions, or putting active units and actions in a queue that gets get called on a regular tick? What do people's main loops look like?
Someone on these forums linked to an article on OO game framework that set everything up with action and state objects that were contained inside of unit objects (can't find the link right now). That theory intrigued me, moving the actions outside of the unit class methods and into a seperate class that acts directly on units. I'd be curious to hear if anyone experimented with anything like this.
I guess, generally, I think it would be cool to share methodologies for how we are setting up our game structure. Start drilling down to what specifically we're doing, and what rewards/problems we're encountering. I think it could be a potentially interesting topic.
Specifically, what I'm looking to do is create a large variety of entities that can do a large variety of things. I'd like them to have inventory, or at least modifiable properties, RPG style (i.e. + 2 to armor, +25% to damage, etc). I like the idea of having different unit types have different movement styles. For example, some might move by thrusting and applying incements to velocities (like flying, drifting), others might explicityly move location to location (like walking).
That's what I'm looking at for a unit class, at least. Beyond that though, I'm interested in talking about how AI interacts with the units, how people handle unit and game states, how unit interaction is handled, etc. I'm wondering about the big picture, not stuff like, "store unit refs in an array" type things.
Like what about events? Are people scheduling individual unit actions, or putting active units and actions in a queue that gets get called on a regular tick? What do people's main loops look like?
Someone on these forums linked to an article on OO game framework that set everything up with action and state objects that were contained inside of unit objects (can't find the link right now). That theory intrigued me, moving the actions outside of the unit class methods and into a seperate class that acts directly on units. I'd be curious to hear if anyone experimented with anything like this.
I guess, generally, I think it would be cool to share methodologies for how we are setting up our game structure. Start drilling down to what specifically we're doing, and what rewards/problems we're encountering. I think it could be a potentially interesting topic.
About the author
#22
The original design had the "action" objects schedule their own updates. My thinking was that I could a) optimize how often actions updated on a per action basis. If an action didn't need to update 30 fps, I could dial it way down. b) Balance the load a bit since the scheduled actions would be offset from each other.
The issue is that actions store a handle to the game object they are "actioning" on, and the game objects store a list of all the actions that are actioning on it. When a game object is deleted, it should also delete all the actions that are acting on it. Additionally (tangentally), some actions like "look at" can look at a unit, so they need to be smart enough to kill themselves if the thing that they are looking at gets killed.
When I delete and clean up a game Object, I can set it up so that the action dies the next time it executes. THe problem is that since the actions are updating on their own schedule, I have no idea if an action is currently executing. It seems like I was running into a lot of deleting objects out from under an action in mid-execution.
Now, the game still runs when this happens, and the actions are smart enough to delete themselves if an object that they reference isn't there anymore, but it's ugly. I can see it getting uglier also as more and more actions started referencing more game objects. Those issues could probably be improved, but it's starting to feel a but shoestringy, I don't feel like I have a good handle on what's going on without doing a lot of checking for missing stuff all the time.
I'm thinking of moving the actions into a "call stack"... basically a simSet that updates all the actions inside it at interval x. That way, I can more confidently have a game object die and tell all it's actions "next time you run, kill yourself", and not worry that an action might be in the middle of doing something when the game object is deleted.
Like(pseudocode)
Maybe I should move this to a .plan file...
07/11/2005 (1:40 pm)
Didn't really get as much done on this as I wanted to. One thing I'm running into now kind of set me back a bit. The original design had the "action" objects schedule their own updates. My thinking was that I could a) optimize how often actions updated on a per action basis. If an action didn't need to update 30 fps, I could dial it way down. b) Balance the load a bit since the scheduled actions would be offset from each other.
The issue is that actions store a handle to the game object they are "actioning" on, and the game objects store a list of all the actions that are actioning on it. When a game object is deleted, it should also delete all the actions that are acting on it. Additionally (tangentally), some actions like "look at" can look at a unit, so they need to be smart enough to kill themselves if the thing that they are looking at gets killed.
When I delete and clean up a game Object, I can set it up so that the action dies the next time it executes. THe problem is that since the actions are updating on their own schedule, I have no idea if an action is currently executing. It seems like I was running into a lot of deleting objects out from under an action in mid-execution.
Now, the game still runs when this happens, and the actions are smart enough to delete themselves if an object that they reference isn't there anymore, but it's ugly. I can see it getting uglier also as more and more actions started referencing more game objects. Those issues could probably be improved, but it's starting to feel a but shoestringy, I don't feel like I have a good handle on what's going on without doing a lot of checking for missing stuff all the time.
I'm thinking of moving the actions into a "call stack"... basically a simSet that updates all the actions inside it at interval x. That way, I can more confidently have a game object die and tell all it's actions "next time you run, kill yourself", and not worry that an action might be in the middle of doing something when the game object is deleted.
Like(pseudocode)
// do this every X ms
// loop through all the actions
for (loop through simset ActionList with %i)
{
if( actionList( %i ).killme == true )
OR if( any game objects the action uses are gone) then put the action in killList
else actionList( %i ).do() // action alive and kicking, axecute actions do()
}
kill all actions in killList
delete action objects listed in killList from ActionList
clear killList
// loop through all the game units, checking for stuff (like health <= 0 for example)
for (loop through all game objects in simset UnitList with %i)
{
if( UnitList( %i ) is supposed to die)
{
put unit in killList
set all the actions that are affecting it to die next update
}
kill units in killList
delete Unit objects listed in killList from UnitList
clear killList
}
schedule next tickAnyway, that's the general idea I'm going to work on. Feedback welcome.Maybe I should move this to a .plan file...
#23
Are you sure that this is what is actually happening?
According to this thread (search for "Posted: Jun 12, 2004 00:03")
www.garagegames.com/mg/forums/result.thread.php?qt=11779
TorqueScript is not multithreaded.
07/11/2005 (7:22 pm)
Quote:
That way, I can more confidently have a game object die and tell all it's actions "next time you run, kill yourself", and not worry that an action might be in the middle of doing something when the game object is deleted.
Are you sure that this is what is actually happening?
According to this thread (search for "Posted: Jun 12, 2004 00:03")
www.garagegames.com/mg/forums/result.thread.php?qt=11779
TorqueScript is not multithreaded.
#24
Basically, I'd create some action like "lookAt", which is a script object. The scriptObject has a do() function that gets executed according to a schedule that it sets up iteself.
Then there is also a gameObject, also a scriptObject. The game object stores a list of all the actions acting on it, and the action object stores handles to the game object.
I tried two things to get the deletions happening smoothly. First, I tried having the game object call kill() on all the actions that were acting on it. This is ultimately maybe the best way. At the time, there were issues, because the kill() function of the action object was also set up to delete the handle to itself that was stored in the game object.
THen I tried simply having the action object check for he existence of all the objects it needed at the beginning of its do() execution. If they object wasn't there, call its own kill().
THis is where I thought it might be getting deleted in mid execution because I'd get a bunch of warnings in the console about not finding the game object, and then the action logic would kick in and the action would kill itself.
But, if it's single threaded, then maybe that's not happening. I'm probably not doing something right.
So, is it that the script is single threaded, or the whole Torque enchilada? If I tie up things in script, physics, for example, will stop running?
07/11/2005 (8:02 pm)
Hmm, no I'm not sure... it seemed like something weird was happening. Maybe I'll spend some more time trying to figure it out. Basically, I'd create some action like "lookAt", which is a script object. The scriptObject has a do() function that gets executed according to a schedule that it sets up iteself.
Then there is also a gameObject, also a scriptObject. The game object stores a list of all the actions acting on it, and the action object stores handles to the game object.
I tried two things to get the deletions happening smoothly. First, I tried having the game object call kill() on all the actions that were acting on it. This is ultimately maybe the best way. At the time, there were issues, because the kill() function of the action object was also set up to delete the handle to itself that was stored in the game object.
THen I tried simply having the action object check for he existence of all the objects it needed at the beginning of its do() execution. If they object wasn't there, call its own kill().
THis is where I thought it might be getting deleted in mid execution because I'd get a bunch of warnings in the console about not finding the game object, and then the action logic would kick in and the action would kill itself.
But, if it's single threaded, then maybe that's not happening. I'm probably not doing something right.
So, is it that the script is single threaded, or the whole Torque enchilada? If I tie up things in script, physics, for example, will stop running?
#25
It was coming back into the Do() function after it killed the action, and trying to execute it one last time. Works fine now.
And since you brought up single threading, I guess my original plan would be better, to stagger the scheduled events instead of queing them all up in one loop.
07/11/2005 (8:11 pm)
Haha, I guess it would help if I put a return; after I call kill( %this );It was coming back into the Do() function after it killed the action, and trying to execute it one last time. Works fine now.
And since you brought up single threading, I guess my original plan would be better, to stagger the scheduled events instead of queing them all up in one loop.
#26
07/11/2005 (8:15 pm)
For events that all happen very nearly at the same time, I just use a slightly randomized delay so they don't all hit at once. Ie:%myobj.schedule( GetRandom( 20, 200 ), myfunc );That gives a bit of breathing room when 100 events all fire at once. :)
#27
It includes multiple inheritance for interfaces, which is essentially Java-style OOP. This has about completed the OO implementation in script, and will probably be the final major release.
Check it out here - www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=8216
07/11/2005 (9:28 pm)
BTW, OOP In Torque Script 3.0 is up! :)It includes multiple inheritance for interfaces, which is essentially Java-style OOP. This has about completed the OO implementation in script, and will probably be the final major release.
Check it out here - www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=8216
#28
So, is it that the script is single threaded, or the whole Torque enchilada? If I tie up things in script, physics, for example, will stop running?
[quote]
AFAIK effectively yes! e.g. shoving this in fxSceneGraph2D::onUpdateScene() !!!
[code]
for( %i=0; %i < 680000; %i++ )
{
testPlayer.getId();
}
[code]
will, pretty much, grind the game to a halt. Though this is clearly an extreme case.
If you put very time-consuming script code elsewhere it will also introduce a stutter in the gameplay but the physics code seems to try and "catch up" after the delay.
Perhaps someone else can shed more light on this?
07/12/2005 (4:02 am)
[quote]So, is it that the script is single threaded, or the whole Torque enchilada? If I tie up things in script, physics, for example, will stop running?
[quote]
AFAIK effectively yes! e.g. shoving this in fxSceneGraph2D::onUpdateScene() !!!
[code]
for( %i=0; %i < 680000; %i++ )
{
testPlayer.getId();
}
[code]
will, pretty much, grind the game to a halt. Though this is clearly an extreme case.
If you put very time-consuming script code elsewhere it will also introduce a stutter in the gameplay but the physics code seems to try and "catch up" after the delay.
Perhaps someone else can shed more light on this?
Associate Phil Shenk
Yeah, I was going to do that, but it's in kind of a messy state right now. Let me work on some more over the weekend, and I'll post up what I've got.