Game Development Community

Hackable Mission File?

by Shon Gale · in Torque Game Engine · 05/19/2007 (4:52 am) · 3 replies

It appears to me that the .mis file does not get compiled. As a result I have been able to look at and modify anybody's mission file. Is this intentional? I can't understand why? Was this an oversight? It bothers me because there are more and more savvy Torque users daily and who says everyone's nice and will not screw with your objects. We also need a way to lock our .dts and .dif, if we can load these into Constructor and change scenes, objects, etc. we should have a save mode in the .dts and .dif structure that says you are finished with it and can not change it. The better our tools and the more popular the engine gets the more we developers have to think of security. A lot of work (months, years) goes into development and it is a shame to waste it.
Does anyone have a work around for this or has anyone else considered this problem and has an opinion?

#1
05/19/2007 (5:15 am)
Shon,

As I understand it, the mission file is pushed from the server to the clients, so everyone is living in the same world, encountering the same objects.
#2
05/19/2007 (5:48 am)
The problem with including lockable assets in the SDK is that ALL developers would have access to the source code and as a result any Torque licensee could hack the system, quite easily.

As Aaron mentions, all missions are run from the server. Additionally, the client does not load any server side scripts and all assets are checked to make sure the client is running an identical version to the server. If there are any discrepancies, you will not be able to join the server.

If you want to protect your assets, adding encryption is quite trivial. There are several resources available on this subject. You could also pack all your assets into the executable, once again pretty easy to do. The point is, it would be futile for Garage Games to implement an official protection system seeing as all licensed users would be able to view and exploit the source code. This is something that is the individual developers responsibility.
#3
05/20/2007 (5:04 am)
Aaron and Tim you both make excellent points and enabled me to look at it in a different light. It seems that the network security is substantial and probably adequate. Also that's a good idea to hard code some of the loading code into the executable. I will track that down. Once again thanks for your comments. I feel better all ready.