I am making a game which i will be open sourcing. Its a simple arcade like game but requires a network connection because it is meant to be played with other people.

The thing i am worrying about is how would i be sure that the client is the one that i put out for the end user to play with? Kind of a like of sv_pure for Team Fortress 2.

I was thinking of different ways to combat this such as the server requesting the client's version or even it's md5 hash but people with simple java knowledge could just force a method to always return what the server wants.

  • 5
    \$\begingroup\$ -1. Google "secure login". This question shows no research effort, which is really only in your own interests. gamedev helps those who help themselves. \$\endgroup\$
    – Engineer
    Commented Nov 13, 2011 at 16:12
  • \$\begingroup\$ If it's going to be open source, then it's going to be hard to really secure the login. An md5 hash of the version is a nice simple solution, though. \$\endgroup\$
    – thedaian
    Commented Nov 13, 2011 at 16:15
  • 3
    \$\begingroup\$ An MD5 hash solves nothing - anyone with the code can just edit it to send whatever value they like, removing the hash function entirely. \$\endgroup\$
    – Kylotan
    Commented Nov 13, 2011 at 17:13
  • 3
    \$\begingroup\$ You could sign all your 'official' JAR files - at runtime merely check that your signature matches (as the JRE will do the actual signature verification for you) - you control the private key for the signing, so you can decide what is official. You could also look into draconian DRM for inspiration (where your 'permanent connection' is with your peer). \$\endgroup\$ Commented Nov 14, 2011 at 12:10
  • 6
    \$\begingroup\$ @thedaian you could not be more wrong. Being open source is completely irrelevant to the login system you use, since security by obscurity is wrong anyway. \$\endgroup\$
    – o0'.
    Commented Nov 14, 2011 at 13:43

2 Answers 2


There is no way to guarantee that the client in use is the client you want them to be using, there are always ways around every technique, even with a closed source application. When it comes down to it, with a closed-source application, any good reverse engineer with some free time can spoof packets to/from your server. In an open-source application, it would be even easier to have some fun. All you can do is make sure to give the client limited control over the game. The less control you give the client, the less you have to worry about what is sending your server packets.

  • 2
    \$\begingroup\$ + and the less the client control over the game, the more client side work in needed. \$\endgroup\$ Commented Nov 13, 2011 at 19:21
  • 1
    \$\begingroup\$ Just to expand, be sure that the game server and match making makes it easy for players to avoid cheaters. Cheating is unavoidable, and the best you can do give players the tools to make their play experience better. Reputation systems, preferred/avoided player settings, friend lists, and skill-based match making all helps tremendously with this (if implemented well, at least). It's all about helping players find the kind of people they want to play with. \$\endgroup\$ Commented Nov 15, 2011 at 0:20
  • \$\begingroup\$ @iamcreasy, did you mean, "the more server-side work is needed"? \$\endgroup\$
    – Cyclops
    Commented Nov 19, 2011 at 13:13
  • \$\begingroup\$ @cyclops No. Its like predicting / transitioning between 2 states/positions. \$\endgroup\$ Commented Nov 19, 2011 at 13:45

I have 2 rules of networking that I keep in the back of my mind when programming.

  1. Give the client, only what information it needs. This isn't completely relevant to the question, but still on the same topic. The client doesn't need the position of all the gold in the map, if they are no-where near it

  2. Keep it server side.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .