Dedicated Client?

#1 Yup, done it.

For the client, I stripped away everything I could find that had to do with the server. Removed the consolemethods, and alot of stuff in the NetInterface and the rest of the Net* files.

There is really no general way, IMO. There's too much to mention that you could remove. Just make sure that when you're done, the client still works as before and all features are intact. Also check the memory footprint. I had problems with leaks when I broke stuff here and there, but now it works just great.

Edit: There is no way to protect anything 100 %. People can always replicate what the server does with their own server application, especially if you're working with Torque.

#2 While I agree that people can ALWAYS create their own server with enough reverse engineering, I want to make it as big of a pain in the arse as possible to do so. I've already written a piece of code that will put some industrial strength encryption on my art, then modified the engine to be able to read those files. So next thing to do is remove the server code from the client build and hope it doesn't bring everything crashing down on my head. I was and still am looking for a way to do this automagically in the make files, so that I don't need to keep two seperate code bases.

To wit if I can accomplish all of this and they still reverse engineer their own server, then I say let them have it, you can only fight your fan-base so much. Anyways I'm really more worried about commercial competition.

#3 Seriously, is it possible to make it with only makefiles? I have a feeling that doesn't cut it.
If you find a way to do it, let me know and I'll eat my hat.

#4 Is it possible to make what with only makefiles?
I can very easily build Torque_Demod_DEBUG and/or Release then switch back to making the standard Torque binary, just issuing a few quick commands to make. This basically strips all the graphics parts out very nicely for a dedicated server setup.

I would hope that the same makefile setup can be configured to strip all of the server specific stuff out, so I can just issue a command like make --dedicated-client

But like I've said before I need to get MUCH better with makefiles before I would attempt it :(

#5 The point is, you'd also need to edit a lot of the code to add #ifdefs and so on - it's not going to be a simple makefile change. No way, no how.

#6 Hmm ok I understand his point now...
Thats a shame we'ld have to ifdef the code in a bunch of places.
I wonder if there is code flow chart for TGE so I could start trying to ifdef the code base and see what I can come up with.

#7 You could also modify the Net code so that it does nothing when asked to listen to a port. That way they may be able to start a server but nobody will be able to connect to it save for the loopback shortcut.

#8 Hey thats a great idea!

#9 If you added one ifdef to

inline bool NetObject::isServerObject() const
{
#ifdef SERVERp
return !mNetFlags.test(IsGhost);
#else
return false;
#endif
}

a decent optimizing compiler *should* remove a lot of your server-specific code in the dedicated client build. The more custom C++ code you have using "isServerObject()," the safer you are from reverse engineering.

I suspect that commerical theft is more likely to be on the concept level than the code level, though.

#10 Ack!! Well, after thinking about that code snippet above, I am not at all sure it wouldn't break things terribly. :-)

However, the basic concept is sound.

Find a place in the code where it asks, "am I on the client or on the server?"
Hard code the answer to be one or the other at compile time and rely on the compiler to protect some of your code.

#11 Hmmm, I disagree with you Andrew. Partly because these checks are easier to reverse engineer and pick apart than just removing the code.
I understand that what you want is easier management between client and server, but I'm using the approach I lined out above and it works great. I have to make all changes twice, if I make something that affects both builds, but with a good merge tool and some patience, that's not too difficult at all.

I still think it's way too early to get heavy on these kind of things though. Make your game and if it is needed in the end, put your best effort into making the game secure. But not the other way around.

#12 I have to disagree with you Stefan on that last statement.
Security, of the code base and security of the assets (this includes private information you may be gathering), need to be a top priority from the beginning, if it isn't it is alot harder to correct for later on.

Take for instance the Windows operating system.
In truth it was NEVER meant to be a secure OS, it was designed for standalone usage only.

Now here we are in the age of the internet, every computer is connected to every other computer, and a large portion of those computers are running a program (the OS), that was never intended for that use.

So what has MS done? They have issued patch after patch, alot of times those patches break more than they fix. The latest SP2, turns your computer into an essentially useless machine.

My point is really simple here. If you are going to try to make ANYthing secure, you should really try to put that issue in the top 10 of your features list, from the beginning, it really should be priority #1 in ANY game where you hope to make a monthly residual i.e. a MMOG.

Remember it's ALWAYS easier to write your programs with security in mind from the beginning than it is to go back later on and try to secure it.

This dedicated client build is really something that IMHO should be included as the default build for TGE, and the server should really be a completely seperate component, just like the other tools.

Anyways thats my 2 cents.

#13

Quote:Partly because these checks are easier to reverse engineer and pick apart than just removing the code.

Aroo? The compiler should remove inaccessable code, just as if you have removed it by hand.

DoFoo();
if (false)
{
   DoQuux();
}
DoBar();

Should, in an optimized build, compile to the same thing as

DoFoo();
#if 0
   DoQuux();
#endif
DoBar();

But, yeah, going through the code and doing it all by hand will probably get you a better result.

In the end, though, cutting out Torgue code isn't going to protect you from any dedicated foe. They will just download the source, and they could do that even if GG packaged client and server as different executables.

Hide your custom server-side code with ifdefs or a compile-time variables as you prefer, and with your current precautions it ought to be adequate to the task. After all, you don't need to run faster than the bear....