Hey, I''m currently working on a massively multiplayer space game that''s similar to Elite. I''m surprised at how quickly it is progressing and it actually looks like I''ll have some sort of playable game soon. Which brings us to the issue at hand. I''d really like to be able to release the source on my programming webpage like I do with all my other projects. I think the source to my game would have a lot of value to other developers for several reasons (it''s a large project in C#, uses managed directx, and there aren''t many (any?) open source mmo games). The problem is, I don''t want people to be able alter the client in such a way that would let them cheat in the game (it''s easy to imagine lots of things one might hack into the client to get an edge - maybe an aimbot or something like that). Is there anyway to prevent this and still release the source? I have been structuring my net code so that the client is trusted with very little, so that the number of possible client hacks is reduced, but it''s impossible to stop them all. Also, it seems like a bad thing if potential hackers get the DPlay Guid for the program (though I guess it''s compiling into the exe with the rest of the string literals). I was reading in my C# book something about signing executables with certificates that guarantee in a cryptographically strong way that the exe has not been tampered with since it was compiled. Would something like this work in a MMO setting? I don''t see how it would, but cryptography can be magic sometimes. I don''t think I would release the source without any such gaurantee that people could easily cheat. There''s no way I''ve worked on this game for so long only to play against cheaters. Comments please! ---------------------------------------- Let be be finale of seem, seems to me. ---------------------------------------- Coding: http://www.stanford.edu/~jjshed/coding Miscellany: http://www.stanford.edu/~jjshed

No, if your game is designed in such a way that client side cheats are possible (ie. client has any authority at all) then there''s no perfect solution to prevent them. You could do something odd like have the "open-source" client download the critical code as a regularly updated proprietary .dll from the server every time you log on, but it''s (1) a lot of trouble and (2) kind of makes the open source thing irrelevant. Open source in a multiplayer environment really isn''t a good idea unless the client is just a dumb terminal (like VGA planets).

I would love to hear what the PlaneShift guys say on the subject of open source multiplayer games. From what I can see of their system the client is not trusted much (if at all) so they are OK. Sure having the engine open source does mean that people can hack in a radar, transparent walls and other nice non-standard game features but then these would only be small exploits.


--
Martin Piper
Network programming made easy with ReplicaNet
http://www.ReplicaNet.com/

Yeah, you might want to ask the Planeshift programmers (open source MMORPG game) about their experiences. They have a forum at http://www.planeshift3d.com/wbboard/main.php

I know ACraig (one of the main programmers) visits these forums from time to time.

[edited by - RonHiler on December 31, 2003 12:28:26 PM]

Yes, at PlaneShift one of our goals is to just make the client do two things:
a) display graphics
b) accept input

Aside from that there is 0 trust in what the client does. At least this is our plan until we can add more detection/validation into the server. We have a cool acronym for that module when it is finished .

Because of this we have had to discount some things. One example is night vision. It would be fairly easy for a player to hack their own client to give this themselves. Or even just hack the graphics engine to remove all the lighting effects to have a noon day sun inside a cave.

To counter this we've limited what information is sent to a client. Each client will have something like a 'sphere of sight' so as you move about you are only sent information about things that are close to you. We can adjust this as well so you may know about players that are 100 meters away but for that magical ring you have to be within 10 meters before the server will send you any information about it.

This prevents people snooping the incomming data to see exactly where all the 'goodies' are. This can also be done with chests. Only the chest information will be sent and not the contents until it is open.

The basic idea is only send the client the data that it *needs* to render the world. PlaneShift is also a very data driven game so a lot of the data is 'hidden' inside the mysql database on the server where no player can see/access it ( unless they hack into the server machine and then we have bigger problems ).

We hope that by going opensource any exploits can be descovered and fixed more quickly. Of course this is a cliche but I do believe that there is some truth to this.

-------
Andrew

PlaneShift - a MMORPG in development



[edited by - acraig on December 31, 2003 4:50:48 PM]

Not that I have anything to add to the discussion, but I''d really be interested in seeing the code behind the game you described. Is there any way you could set up a distribution list to let people know when something will be ready?

Joel Martinez
http://www.codecube.net/

Well, if you only send the client needed data, as you said, and all the client can do is input/output, then you shouldn''t have too much trouble. The worst he could do, as you said, is change the contrast.

Hey,

Thanks for all the great input! I am familiar with the idea of assigning zero trust to the client and have tried to keep it foremost among other consideration when coding. However, in doing this, you lose the opprotunity to do some nice optimizations - for example ACraig spoke about a "sphere of sight". My game has a similar notion. Something I''d like to be able to do is pre-cache a lot of the player''s surroundings (large bitmaps for planet textures, ect.) before he gets too close, otherwise the game won''t play well under lag (if the sphere of sight is not updated fast enough). Also, there is collision detection. Ship to ship collision detection should definately be handled server side, but what about ship to asteriod collisions? If the game universe has 100 planetary systems with 1000 asteriods each, that''s a lot of collision tests to do without some kind of space partitioning. I guess it''s more of a concern for my particular game since the asteriod''s positions are procedurally generated as densities of asteriods rather than actual positions (it''s complicated).

Plus no matter how much you rule out direct cheats like maphacking or invincibility by not trusting the client, there are more devious hacks one could do.

For example, in my game you can make a minimal amount of money by mining hydrogen from the sun. This is tedious and doesn''t produce too much of a cash flow, so mostly only starting players will do it for a little while to get enough money to buy a nice ship. However, if I had access to the client source of my game, I could easily write a bot that would do nothing but harvest hydrogen 24 hours a day. This is a problem because it 1) effectively gives the cheater infinite cash and 2) consumes server resources 24 hours a day to run a bot instead of hosting a human player (I have only a modest machine to use as a server and can''t handle thousands of hydrogen harvesting bots).

It''s an interesting problem. I may be worrying about nothing. I suppose it takes a lot of conceit to think my game is going to be so awesome that people will devote time to reverse engineering and hacking it up. One idea I had (similar to what Fingers_ mentioned with releasing the source to the game, but then having some kind of activator DLL) was to write a small program that would validate checksums on the game executables (as they were running) and send some kind of authentication message to the server (probably using some kind of public key scheme - I think this is how the punkbusters for CounterStrike work). One thing I think would be cool would be to send the authenticator program as an ASCII string to the client during setup and have the client program store it in a buffer and then set the program counter to the buffer address and execute the program directly from memory - which would make it rather difficult for a hacker to get an actually executable of the authetication program (since it never exists as a file). But I''m sure it''s much more work than it''s worth, considering that no protection scheme is going to be 100% safe. Actually, come to think of it, that whole idea is trash - if the client was open source. Hmmm...




----------------------------------------
Let be be finale of seem, seems to me.
----------------------------------------

Coding:
http://www.stanford.edu/~jjshed/coding

Miscellany:
http://www.stanford.edu/~jjshed

I have a question related to this. This, of course, is totally speculative, but in general, how many clock cycles do a typical game server eat up? In terms of percentages I mean. That may be way too difficult for anyone too answer, but some real-life examples would be OK too. E.g., how much CPU time would a 2GHz server with 32-players take up?

quote:

---

Original post by Telamon
One idea I had (similar to what Fingers_ mentioned with releasing the source to the game, but then having some kind of activator DLL) was to write a small program that would validate checksums on the game executables

---

That would probably be bad if you want to release non-Windows versions. *nix users likes to compile their own binaries.

The bot-problem is very hard to solve; not releasing the source will not stop it, only make it a bit harder for the bot coder. One suggestion is to take this possibility (that the client might be a bot) into account in the game logic. In this case it might be to do so that a client (human or not) cannot mine for 24/7. Another way might be to implement clever features that only a human can handle, eg. displaying an image with a random question to be answered for the client to be able to continue, would be very hard for a bot to get around (I''m not suggesting exactly this, it is only an illustration; it should be subtle and don''t interfere with gameplay).