some hawtness for all you scripters out there.

the GameMode interface allows for pluggable game modes (Capture the Flag, Racing, special deathmatch rules, etc) without having to edit core files makes installing and removing mods easier than ever.
To further convenient modding, your whole mod (or content pack) can be packed up into a single zip file and dropped into the mods directory. Torquescript's package functionality allows you to override core functionality without risking the user's core scripts. Even better, the users can select from a single gui inside Torque which mods they want enabled, and which they want disabled.
Datablocks are designed to be reusable, a feature of the engine which most scripters ignore, largely because there is no convenient way to share particles, projectiles and other useful data between each other's mods when you have no way of knowing which mods are used. TBG changes that. Each type of reusable datablock has a special directory, and named with a scheme based on their basic properties. Any datablocks which your content pack or mod is dependent on, should be packaged with your mod. Your scripts which need reusable datablocks register themselves with the engine and request the datablocks they require. If that datablock has already been loaded, the request is ignored, otherwise it searches the entire modpath for the appropriate datablock and exec()s its file.

Finally, porting terrain based maps to a new mod directory (as required by TBG) is always a pain, but we've created a tool to streamline the process and make it as painless as possible. We've also taken the opportunity to reorganize the directory structure to make it a little more logical and less cluttered. Mission previews now belong in core/data/missions/previews. Terrain files, oddly enough, now belong in the core/data/terrain directory, just like their textures.



Anyone who actually codes for the Torque Game Engine should understand the significance of this.
It's going to be great. Maybe we can even get some online action going, a little two on one, perhaps? That is, if Elf starts remembering to put close dialog commands in his buttons Rolling Eyes.

Code:


//USING THIS PACKAGE NAMING SCHEME
//WILL HELP MAKE IT EASIER TO AVOID CONFLICTS
package _GameMode_Sandbox{

    function beginSandboxGame(){
        //We don't need to do any initialization here, because Sandbox uses the default stuff anyway
        //And is mostly just for an example
        //But if wanted to do anything (like begin a race),
        //Or reset scores, this is the place to do it.
        //Or set a timer to end the game.
        echo("I <3 playing in the sand, don't you?");
    }
   
    function endSandboxGame(){
        //End of game cleanup
        //Send scores to clients, whatever.
        //End of the race, all players dead, whatever.
        echo("Oh :( Leaving so soon? I know lots of other good beaches to play at.");
    }
   
    //If you want to override any other functionality
    //Or add any helper methods
    //DO IT HERE.
   
    //If you're overriding something, please be polite
    //And use Parent::functionName
    //So that your gamemode will chain nicely
    //If you're overriding something really basic
    //And don't want that, it would probably be better off
    //in a full-out mod.

};

function activateSandboxMode(){
    //Any initialization that wouldn't change from game to game. (SO NOT SCORES)
    //This is global stuff that you want to persist between rounds of your game
    //As long as the GameMode is active and that server is running
    //WE just want to activate our package.
    activatepackage(_GameMode_Sandbox);
}

function deactivateSandboxMode(){
    //Courtesy function for cleanup
    //Do what you gotta do.
    deactivatepackage(_GameMode_Sandbox);
}

//NOW WE REGISTER
registerGameMode("Sandbox", activateSandboxMode,  beginSandboxGame, endSandboxGame, deactivateSandboxMode);




Code:


//USING THIS PACKAGE NAMING SCHEME
//WILL HELP MAKE IT EASIER TO AVOID CONFLICTS
package _GameMode_Deathmatch{

    function startDeathmatchRound(){
        for(%i = 0; %i < ClientGroup.getCount(); %i++){
            %client = ClientGroup.getObject(%i);
            if(isObject(%client)){
                %client.setScore(0);
            }
        }
        messageAll('MsgAdminForce', "A Deathmatch is beginning. You got the right same as anyone to live and try to kill people.");
    }
   
    function endDeathmatchRound(){
        //End of game cleanup
        messageAll('MsgAdminForce', "Deathmatch has ended.");
        for(%i = 0; %i < ClientGroup.getCount(); %i++){
            %client = ClientGroup.getObject(%i);
            if(isObject(%client)){
                commandToClient(%client, 'ShowScore');
            }
        }
    }
   
    function GameConnection::incScore(%this, %delta){
        Parent::incScore(%this, %delta);
        if(%this.getScore() >= 10){
            messageAll('MsgAdminForce', "%1 was the first to 10 frags!", %this.getName());
            endDeathmatchRound();   //SOMEONE WON!
        }
    }

};

function activateDeathmatchMode(){
    //Any initialization that wouldn't change from game to game. (SO NOT SCORES)
    //This is global stuff that you want to persist between rounds of your game
    //As long as the GameMode is active and that server is running
    //WE just want to activate our package.
    activatepackage(_GameMode_Deathmatch);
}

function deactivateDeathmatchMode(){
    //Courtesy function for cleanup
    //Do what you gotta do.
    deactivatepackage(_GameMode_Deathmatch);
}

//NOW WE REGISTER
registerGameMode("Deathmatch", activateDeathmatchMode,  startDeathmatchRound, endDeathmatchRound, deactivateDeathmatchMode);
Dynamic mod loading is now fully functional, the system loads any .zip files that are dropped into the mods folder, and has a GUI with a preview of things like the author, and version number, with an option to dive more indepth and see things like the mod description.
You can also activate and deactivate any mod from within the game with a click of a button.
This mod system will allow people to add functionality, weapons, decals, game modes, GUIs and settings without having to change the actual game files as you did in TBM and RTB. This is a huge advance in stability, and ease of use, and we think you are going to love it as much as we do.


More details on this.

Any .zip file dropped into the mods/ directory will be detected and added to the mod gui at run time. To enable mods, just set their checkboxes and hit apply. This will cause the mod stack to be reset and for modfile.zip/init.cs to be executed. All functionality in the mod should be self contained in packages and functions and in most cases make use the Parent:: namespace to allow chaining of any core functions they alter. Example init.cs

Code:

package mymod{
 function foobar(%args){
   Parent::foobar(%args);
   echo("Well ain't that somethin'");
 }
};

activatepackage(mymod);


A modinfo.txt file should also be present in the root of the zip file. With the following format

Code:

NAME: modname   (this should be the same as the name of the zipfile without the .zip)
AUTHOR: modauthor name, or names
VERSION: Version 1337.42
INFO: Anything else you want to say. This last field can have multiple lines.


More info to follow on how to handle design game modes and the use of datablocks within your mod.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement