Script Hierarchy - Documentation

#1 "Game/Core" contains all the scripts which are need to make Torque "go". The other "game/scripts" folders can overrule them. If you're making new scripts, probably best to stay out of "core".

Technically this is a left over from "Ye Olde Dayes" when "game/scripts" were seperated to making modding easier.

#2 Thanks steve,

So basically stay out of core unless there's as good reason.

#3 You can actually go and delve around, but there are many things that you can overrule with "game/scripts" files.

A couple of reasons why you would want to go into core is to change or add default settings "core/scripts/client/defaults.cs" which are then saved out in the "scripts/client/prefs.cs" file when the game shutsdown (user defaults and the sort), or new audioEnvironments - though again you have the later in a file elsewhere and as long as that file is exec'd they'll all load nicely.

There's not "usually" too much reason to go around hacking away in core, and I certainly try to avoid it except for my custom default variables and custom option settings.

Maybe Silent Mike will chime in when he's around, he knows more about this sort of thing than me.

#4

Quote:
Maybe Silent Mike will chime in when he's around, he knows more about this sort of thing than me.

You just know that the persistence of the core + game-as-a-mod approach is a personal annoyance of mine ;)

The script hierarchy has more to do with the package system than an actual order of execution for the scripts. The core is indeed a holdover from TGE when GarageGames kept the different projects all in the same directory and exec'd them individually as a mod over a "common" script base that provided basic functionality. These were the scripts, assets, guis, etc, that were *theoretically* used by all projects.

Over time, with many other developers adding, dropping, and modifying bits here and there some overlap between the common scripts and the game (mod) scripts began occurring, yet no one took the time to clean these up. There are some "core" guis and scripts that can and should be modified for each and every game. So long as you are following the official core + scripts(mod) setup you are actually writing your game as a mod built on top this core functionality.

What happens when the scripts are executed is that the core is the primary or base game package that holds the basic functionality to get things going, and the scripts directory is a separate package (mod) that extends and in some cases overrides the functionality of the core. The scripts (mod) is where you add the scripts that contains all of your game functionality -- much as your specific game art goes into the art directory, and levels into the levels directory.

Basically the scripts are grouped into packages and the Core Package (basic functionality) is exec'd first, followed by the FPS Package (the scripts directory which contains specific game code), and then by the GameType Package(s) (the various game types such as Deathmatch, CTF, TDM, etc). Each successive package is able to override the functionality over previous packages.

An example of overriding some core methods can be found inside of "scripts/server/gameCore.cs". Functions loadMissionStage2(), endMission(), resetMission(), onConnect(), and others... are all duplicated from the core, but have additional functionality added to them.

Admittedly, this can cause confusion, and it would make more sense just to have this functionality added to the core versions of the functions. But at the time when I added the Game Type system (which required these overrides) to the FPS kit, due to the way in which GarageGames had their code repository configured if a change was made to the core then it was affected across all projects which was undesirable since we were only needing this additional functionality in a specific project.

You can modify anything in the Core to your desire, but keep in mind that if a modified version of a function exists in the game (mod) then the last exec'd package will have authority. So if you do modify a core method and see no functional change, that means more than likely that the method is overridden by a game script (mod) package alternative.

It is possible to move the modified methods over into the core and remove the package overrides. In fact it's entirely possible to merge the game scripts (mod) into the core, or vice versa. I've done this for my own projects completely doing away with the core directory and my game is the "core" and not a mod on top of the core. Merging the scripts is somewhat easy. Merging the core art is somewhat more tedious due to the many hard coded paths for various assets that can be found inside the Tools (mod) and the source code itself.

#5

Quote:
You just know that the persistence of the core + game-as-a-mod approach is a personal annoyance of mine ;)

And if I say your name 3 times whilst running around the house "widershins" on a full moon - you'll drop into the thread ;)

#6 Lol!

The question is does what I said make any amount of sense, or was I just rambling/ranting?

#7 After messing with adding Python to Torque it really made me want to reduce the scripting code to the bare necessities to get the engine running. Part of the reason is because the engine is hard coded to launch main and requires a certain amount of objects to exist before it begins executing the main loop. When I tried to follow through the script I got lost very quickly and it was difficult for me to understand what was actually needed.

At some point I will revisit this as I really want as lean a startup process as possible. Then build up my own script libraries to add features as necessary. To me there would be a lot of value to having this as an option you can select in the Torque Toolbox when creating a new project. Maybe call it a "barebones" version of a project.

@Michael,
Yes, your post made a lot of sense to me. Thanks for clarifying the startup process. That is probably why I found it so confusing to determine what was actually running and what was not.

#8 @Frank: I actually have a Barebones template project I started a while back that I was going to offer up as a Resource once it was done. I started with the Empty Template merging the core scripts into the actual game scripts, reducing one whole package level of complexity, and was paring them and the GUIs down. My intention was to have a startup package that would initialize the audio, the canvas, the console, the tools mod, and get you to a blank main menu with some other basic support scripts remaining (server creation, level loading, options gui, metrics, etc). I never did finish it although I keep meaning to tinker with it some more.

#9 @Mike,
You could make it a live resource. Offer it up as a resource and encourage people to tweak, add, change, etc. They in turn could offer up their own versions of the resource and in time we would have a selection of barebones templates to choose from.