Removing editors from release build... & Preventing Mods
by Nick "Dig" Koirala · in Torque Game Engine · 12/04/2002 (4:48 am) · 4 replies
I'm going to release two versions of my game, a demo verison and a commercial version. As one of the 'hooks' for buying the commercial version is that is will have more levels and you can add your own it wouldn't make much sense if the Demo users could jsut build their own levels and use the commercial mods.
How can I prevent the engine using additional mods? AND how can I remove the gui and world editors from my demo version?
Cheers,
Nick
How can I prevent the engine using additional mods? AND how can I remove the gui and world editors from my demo version?
Cheers,
Nick
#2
12/04/2002 (8:38 am)
I will add also to remove the .cc file corresponding to the editor so nobody can copy script file from a free torque game with the editors and use it with yours.
#4
You could also hardcode certain effects in. For instance, if you were doing a racing game, only put snow levels in the demo. Then hardcode the skybox textures (don't worry too much about people editing the images; the idea is to make it a pain, not make it impossible), and hardcode the presence of precipitation objects. Even if people modify all the textures and level data, they'll be stuck with snow.. and they'll also screw up the demo level(s). Water levels might be another option.
You could also add some md5 checksums to the EXE. One good trick might be to express certain constants in the code in terms of "the last byte of the md5 of the level file + 7 is the speed of the vehicles", and then check to make sure the vehicle speed is right. That way if someone removes the check with a crack, the vehicle speeds will still be very wonky if they start editing levels...
Basically, make it break in all sorts of weird subtle ways if stuff gets changed, and add checks for most of it so honest users don't get caught up if their data gets corrupted.
12/04/2002 (6:36 pm)
One trick might be to hardcode some limits into the compiled code of the demo, like the number of textures a level can have, or their size, or how large a level can be. Set the limits such that the demo data doesn't exceed them.You could also hardcode certain effects in. For instance, if you were doing a racing game, only put snow levels in the demo. Then hardcode the skybox textures (don't worry too much about people editing the images; the idea is to make it a pain, not make it impossible), and hardcode the presence of precipitation objects. Even if people modify all the textures and level data, they'll be stuck with snow.. and they'll also screw up the demo level(s). Water levels might be another option.
You could also add some md5 checksums to the EXE. One good trick might be to express certain constants in the code in terms of "the last byte of the md5 of the level file + 7 is the speed of the vehicles", and then check to make sure the vehicle speed is right. That way if someone removes the check with a crack, the vehicle speeds will still be very wonky if they start editing levels...
Basically, make it break in all sorts of weird subtle ways if stuff gets changed, and add checks for most of it so honest users don't get caught up if their data gets corrupted.
Torque Owner Davis Ray Sickmon, Jr
Default Studio Name
To prevent mods, don't distribute the source - instead, only distribute the .dso files, no .cs files. That will prevent most people from making mods rather quickly (you'd have to write a de-compiler for the .dso files before moding would be useful.)
However, just to point out, someone could download the TorqueDemo, and use the editors in it to make new levels, etc - so, be sure to hardcode the names of the levels into the scripts (IE, you can only load these level names) and you'll get rid of that problem too.