Committee Meeting Notes: 07/15/2013

#1 Thanks for the update, Dave.

#2 Modular Templates: Is this going to be a big scripting change?

I am working through understanding the mission loading sequence. I am starting to get my head around it. However, I was wondering if the new templates will be a big change those scripts.

#3 @Demolishun: no major difference in mission loading mechanics... but the base app will be stripped of all game-specific functionality. The base module will do nothing but initialize all of those fiddly client bits in the core, enable mission loading, and enable the use of the Tools which requires the mission loading.

A module can be somethiing as simple as a gui dialog that gets loaded after the base app. For example I'm using the consoleDlg as a self-contained module for testing. Once I'm done developing my project I can simply remove the console module and the end-user doesn't have access. I've also tested with "asset modules" -- but, and this is a big but, there is no asset management nor do I plan on providing for one. Also a module could be something as complex as say a game or gametype template. This latter example is actually more effective than the little mini-modules or toys (if you thinking of T2D modules) approach that I was initially looking at. At the end of the day, it will be the users' (you and everyone elses) choice as to how you build/assemble your game:

• build upon the base app
• assemble a bunch of modules dealing with your own dependency and asset management issues
• build upon a gametype module (think TGE's common/fps.starter or common/racing.starter or common/demo or common/tutorial.base approach)

#4 We've really got to come up with a non-conflicting name for these things. Modules are just mods (client and/or server), but the word mods itself seems to have some negative connotations from the "real" game devs.
Modules are already being used to denote modules of code in the source.
Packages is a strong choice seeing how the script modules sort of depend on the script package system to work.
Plugins... etc, etc... whatever it ends up becoming named we're definitely not going to call them toys ;)

#5 I use to browse for synonyms, if I need to chose naming for things, in this case for example: thesaurus.com/browse/module and/or thesaurus.com/browse/modification ;)

I tend to like "component"

#6 To clear things up:
Mods stands for Modifications, not Modules. Mods slang comes from the times when it was common to be able to modify vanilla retail games and become modified (mod). Modification meaning the game was changed from original intent (set by the developers/publisher) to operate differently, either that be rules, assets, etc.. Over time several modifications (mods) became available as community members of said modified game and released them. Not to say that mods don't exist now a days, but less and less recent games are modifiable because the publishers don't want the gaming community to outshine their DLCs(Downloadable Contents).

When a game developer is modifying an existing engine or support code/scripts to create their own stand alone game it isn't considered a mod, but creating an original work or intent. No different than taking existing libraries and using them to create an application.

So overall just don't call Modules as Mods, as those two terms have entirely different meaning.

#7 I find it funny how serious we need to be in naming things when we are developing games.

@Michael,
I think modules is fine, but no matter what things get named put a definitions list somewhere. Every time I turn around someone is adding new jargon and I don't read enough gaming dev articles to keep up. So a nice key as to what the terms mean would be really nice no matter what you decide.

So based upon your comments I can assume gameCore.cs is not going to redefine the second stage of the mission loading?

I would only call something a package if it gets loaded using the package functionality of Torque Script.

For the mission loading scripts I am working on serializing mission data into a database. So I was starting to think it might be good to document what I am doing on mission loading/editing/saving. This way I can perhaps a generalized solution can be developed for determining the source of mission data. It would be really nice if the source of the data could be: file, database, or some other source.

On that note, where do I get intercept datablock loading? I have not found that yet. I see where I intercept mission file loading, but not datablocks. I know this is an exec thing for those.

#8 @Demolishun

This is found in core/scripts/server/missionDownload.cs

// Send over the datablocks...
   // OnDataBlocksDone will get called when have confirmation
   // that they've all been received.
   %client.transmitDataBlocks($missionSequence);

Actual transmission I believe is in the engine, and that is just a DefineEngineMethod/ConsoleMethod that transmits the datablocks.

For executing the actual datablock script, there is some stuff found in gameCore.cs I believe in function onServerCreated

#9 @Jeff,
Awesome Jeff! That helps a lot. I will definitely have to compile all this info into one place for everyone to use.

#10 Modules sounds fine, unless you're concerned it would be confused with T2D's modules. Packages also sounds good!

#11 @Demolishun,

No problem! Another thing I want to point out is that this can be done from a script point as well if you have a serialized method for simdatablocks and want to store all of the datablocks into a database or something:

%count = DataBlockGroup.getCount();
for (%I = 0; %I < %count; %I ++)
{
   %obj = DataBlockGroup.getObject(%I);
   %str = %obj.serialize();
   // do something with %str now
}

If sending datablocks to client from a server to load/execute:

The only limitation is I believe if your using commandToClient or commandToServer is a 255 max character limit in a string, so you would have to split it up in a for loop to send the data to build the object on the client by sending a done flag or something in the last one in the list.

Hopefully this provides useful info to somebody.

#12 @Jeff,
I think the way datablocks work is they get executed on the server and then transmitted via %client.transmitDataBlocks command specifically designed to transmit datablocks. So the client never actually execs any datablock structures. Also, I think it would not be desirable to have a client execute datablocks.

What I mean by serialization is how the datablocks are stored in the first place. Right now they are stored in a file. I am looking into converting them to XML and then storing them in a database. I am not sure if I will include datablocks right now or not in my serialization. I am going to include the missions objects though. This will help in creating dynamic missions as I can customize each mission by using XSL.

I am also looking into leaving the editors to work as they do now, but have a button or script that converts existing missions and stores them in a database. That way normal editing/testing can occur, then everything can be dumped to a database. An engine flag can be set to make it so the script looks for the source of the data in the database instead of in a file. That is why I am thinking about a generic resource to select sources of data based upon package implemented functions. Like adding functions to GameCore to provide functions that snag the data from a different source. I figured making functions for datablocks would be more complete. Even if I don't use them.

#13 @Demolishun,

Ah okay, thanks!!

Yeah I figured they were transmitted via %client.transmitDataBlocks()

To be honest, IMO, you probably don't even need to store them in a database, I mean its common data structures that probably shouldn't be changed too much on runtime, let alone instantiating new ones at run time, which is probably not necessary as its preloaded data.