Scripting Best Practice
by Rodney Rindels - Torqued · in Torque Game Builder · 05/20/2006 (1:06 am) · 5 replies
Ok I'm settling in with the idea of using TGB for my engine for my production game. I have spent the last few months of free time protoyping, engine crawling, and beating the hell out of F5 and F11, learning what I can.
Now I guess I would like a little validation on my scripting plan. While I know torque is flexible, and there are often several ways to accomplish the same thing, sometimes one approach wins because of maintainability, stability, scalability, etc. So the model I think I'm going with for my game works like this.
1. Use a "game" package to hold common functions for game specific things, as well as holding the exec's for the game specific assets.
2. Use a "player" package to hold all common player actions, execs for player specific assets.
3. Use individual level packages to hold keybindings, non common functions, except for datablocks, but I'll exec the proper datablock files for the assets for that level in the package. I'm pretty sure its safe to do a deactivation on the package at level end, clean up all level assets, then activate the next level package.
4. I think I'm going to use a localized file based database to hold all game assets, this gives me asset protection, as well as iterators for updating,loading, unloading, and callbacks for progress bars, etc.
5. I've decided to leave particles out until RC1, i'm sure its just my not understanding them, but my framerates really drop when using them in any real capacity.
6. Gui Controls will be built with the editor, then hand tuned to a final versions.
7. I'm going to use SimSets for most things, but my inventory / bank system is going to be implemented using a SimGroup, If I'm right, that should allow me to add, remove, inventory /bank items fairly easily, because objects that are in a SimGroup, can't be in any other group. just doing an inventory.add(%obj), and an %obj.visible=false; should be all thats needed then to pickup items from the level, and not have to worry about cleaning them up from the $world.
Does this seem like a Safe plan for the scripting portion of the game? Am I missing anything major in my plan? This being my first TGB game, I just want to make sure I get off on the right foot, when I start tacking down production code.
Thanks for any input,
Rodney
Now I guess I would like a little validation on my scripting plan. While I know torque is flexible, and there are often several ways to accomplish the same thing, sometimes one approach wins because of maintainability, stability, scalability, etc. So the model I think I'm going with for my game works like this.
1. Use a "game" package to hold common functions for game specific things, as well as holding the exec's for the game specific assets.
2. Use a "player" package to hold all common player actions, execs for player specific assets.
3. Use individual level packages to hold keybindings, non common functions, except for datablocks, but I'll exec the proper datablock files for the assets for that level in the package. I'm pretty sure its safe to do a deactivation on the package at level end, clean up all level assets, then activate the next level package.
4. I think I'm going to use a localized file based database to hold all game assets, this gives me asset protection, as well as iterators for updating,loading, unloading, and callbacks for progress bars, etc.
5. I've decided to leave particles out until RC1, i'm sure its just my not understanding them, but my framerates really drop when using them in any real capacity.
6. Gui Controls will be built with the editor, then hand tuned to a final versions.
7. I'm going to use SimSets for most things, but my inventory / bank system is going to be implemented using a SimGroup, If I'm right, that should allow me to add, remove, inventory /bank items fairly easily, because objects that are in a SimGroup, can't be in any other group. just doing an inventory.add(%obj), and an %obj.visible=false; should be all thats needed then to pickup items from the level, and not have to worry about cleaning them up from the $world.
Does this seem like a Safe plan for the scripting portion of the game? Am I missing anything major in my plan? This being my first TGB game, I just want to make sure I get off on the right foot, when I start tacking down production code.
Thanks for any input,
Rodney
#2
btw. I have multiple players that can have distict actions, thats why I included it for them as well..
thanks for the feedback.. validation is a good thing.
05/20/2006 (8:34 pm)
@ Jason - thats exactly the plan Jason, to override certain actions in each level to keep the function counts lower, and not pollute my namespace as much ,etc.btw. I have multiple players that can have distict actions, thats why I included it for them as well..
thanks for the feedback.. validation is a good thing.
#3
leveraging the new TGB level builder I am putting into each level some controller objects (just off-camera sprites) which get a callback when the level is loaded . For example, when level1 is loaded, the script for level 1 is invoked by that controller sprite:
packages I am not using packages at all. I really don't see the utility- I guess jason is right for it being mainly useful modders, not original games. Instead I am using levels (ala TGB level builder) and using inheritance and encapsulation in my script objects.
gui controls I will probably use t2d sprites as gui controls instead of actual gui buttons etc. the sprites can often look nicer.
05/20/2006 (8:42 pm)
@Rodney I think everyone handles these things differently, but here is my take on a few thingsleveraging the new TGB level builder I am putting into each level some controller objects (just off-camera sprites) which get a callback when the level is loaded . For example, when level1 is loaded, the script for level 1 is invoked by that controller sprite:
//----------------------------------------------------------------------
/// purpose: Callback from levelManagement.cs
/// params: sceneGraph
/// returns: -
function MLEggsLevel1::onLevelLoaded( %this , %pSceneGraph)
{
%this.init();
$MLEggs::level = %this; // register self as current Level
}packages I am not using packages at all. I really don't see the utility- I guess jason is right for it being mainly useful modders, not original games. Instead I am using levels (ala TGB level builder) and using inheritance and encapsulation in my script objects.
gui controls I will probably use t2d sprites as gui controls instead of actual gui buttons etc. the sprites can often look nicer.
#4
My plan is to be able to distribute new levels and change the functionality of the game pretty easily by mod'ing in / overriding functionality. I like packages for simplicity in activating and deactiving (like exec is hard), hell I'm sure I'll end up changing this 100 times before I'm done :-)
Yeah I've been having some issues with Gui's crashing the engine that I haven't had time to track down, I may end up going with sprite based gui's as well.
05/20/2006 (8:46 pm)
@alex - Neato. My plan is to be able to distribute new levels and change the functionality of the game pretty easily by mod'ing in / overriding functionality. I like packages for simplicity in activating and deactiving (like exec is hard), hell I'm sure I'll end up changing this 100 times before I'm done :-)
Yeah I've been having some issues with Gui's crashing the engine that I haven't had time to track down, I may end up going with sprite based gui's as well.
#5
Alternatively (as most due) you can have all the functionality in place at all times and just change datablocks/object namespaces, but packages are the more elegant solution when used correctly.
05/21/2006 (12:39 pm)
Yes, your overall plan sounds excellent, and packages are meant for exactly what you (re-described) intend--changing functionality easily by unloading one controlling package and loading the new one--perfect for different behaviours on different levels without a large memory footprint since you can dump and load in the new functionality.Alternatively (as most due) you can have all the functionality in place at all times and just change datablocks/object namespaces, but packages are the more elegant solution when used correctly.
Torque Owner Jason Cahill
Default Studio Name