Hi! That's my first post here on the gamedev community so i aplogize in advance for making any kind of mistakes (breaking forum rules, etc...)

I have a few questions regarding my current project (not programming related, it has more to do with releasing/supporting this project after its release.)

Now what exactly am i talking about:

My current project is a first-person parkour styled platformer in which you race agains the time and try to beat maps/levels as fast/efficiently as possible by abusing the enviroment and using it to your andvantage. To visualize it better think about the general premise of Trackmania mixed with Mirror's Edge styled gameplay.

Now, i'm also working on multiplayer for this game.

The main progress in the game is done by playing each map one by one, win medals and proceed to the next map. Additionally your best times will be uploaded to a webserver so that you can compare your best time with other players.

In addition to that i'm also working on a server application so that players can race against each other in realtime. (Players will be able to host a server application to which clients can connect to.)

The server application itself is written in Java (more on that later.)

And here is the thing: I was thinking about releasing the server code to the public so that players can mod it and (potentially) extend it with server sided gameplay modes.

There are a number of reasons why i'm considering to do this:

• Players can mod it (new gamemodes?)
• Making it "open source" would benefit me as issues in the servercode (which i've overlooked) may be found by others
• The Java servercode is easy to decompile so if someone wants to get the source code, he could do that anyway. (of course i could use an obfuscator but...)

What speaks against it though is cheating. As i will release the server to the public (and i can't quarantee that someone doesn't decompile/alter the source code of the server) i already dropped the idea of allowing the server to change any important scores on the main webserver. So the realtime multiplayer scores will be only stored locally on the java server and not on the main webserver (to avoid anyone to cheat with the global scores.)

The question is: How do i prevent someone to host a server which is modified to allow cheating (by modifying the code)? Or a better question is: Should i worry about it?

The java based server application can't alter anything important on the main webserver (where all the time trial scores are) but there is still a chance that someone gets the idea to alter the servercode so that he gets certain "admin privileges" to (as an example) reset his time, teleport around the map, etc...

It certainly isn't going to be fun for anyone if someone on the server breaks the rules and uses servermodifications to his advantage.

And that's where i'm stuck. I don't know if releasing the source code is a good idea or how to restrict servermodifications/give players the ability to defend themselves against something like that. (I can't just "test" that out by releasing the source code to see how it goes. Once the source is out i can't do anything about it.) Maybe a reporting system would be a solution (as all hosted Java servers would register themselves with their IP onto the master server. If enough reports come in i might be able to block the IP for a certain amount of time.)

Is anyone out there who did a similar kind of thing? (Releasing a free/commercial game with a server which was also released with the source code?)

Any experiences to share?

Don't worry about cheating and make your server open source. On client create window with selection of servers. You will have one main trusted server (yours) and many untrusted (someone else). So you'll get benefits of open source (bug hunting and pull requests) and nothing bad.

Sorry for my bad English.

And one more question. Why do you choose Java for back end? I ask just for information because I'm creating game and I need back end too.

I wouldn't worry about preventing cheat servers -- I'd worry about and prevent them from masquerading as an official server or participating in any sort of official gamerank/leaderboard/matchmaking. You can accomplish this by tying that sort of traffic to your web-server to public-private key cryptography (keeping the private key private and out of any source control, though you're responsible for protecting it by securing your own game and back-end servers), that's the gist of it anyways. If you do that, you can even track different key-pairs relative to different community-made flavors of your game -- each key-pair would represent its own universe of stats, etc. Its just a matter of whether you want to provide that service to the community, and you might not for purely business reasons; maybe you want to offer it on a case-by-case basis through an application/registration process.

Let cheaters play by their own rules if they want, its only a problem if they mix with those looking for a fair game.

Don't worry about cheating and make your server open source. On client create window with selection of servers. You will have one main trusted server (yours) and many untrusted (someone else). So you'll get benefits of open source (bug hunting and pull requests) and nothing bad.

Sorry for my bad English.

The question is how to prevent someone to modify the server which "pretends" to be an unmodified one. It would be ideal if the server application (after registering to the master server) would tell the master server if it is a modified or an unmodified one. (so that a player can tell in a server browser if he is about to get onto a modified server or not.)

And one more question. Why do you choose Java for back end? I ask just for information because I'm creating game and I need back end too.

The main reason for that is that i'm fammiliar in Java. C# is another option (but i don't see what the benefit would be over Java. In addition Java already has a nice networking API.)

I'm not experienced at all in C++ so this options falls right out of the window.

Note that i'm talking about a server application which players can download, start and thus host their own multiplayer servers/lobbys. The main master server will be a simple http webserver with PHP installed on it.

I wouldn't worry about preventing cheat servers -- I'd worry about and prevent them from masquerading as an official server or participating in any sort of official gamerank/leaderboard/matchmaking. You can accomplish this by tying that sort of traffic to your web-server to public-private key cryptography (keeping the private key private and out of any source control, though you're responsible for protecting it by securing your own game and back-end servers), that's the gist of it anyways. If you do that, you can even track different key-pairs relative to different community-made flavors of your game -- each key-pair would represent its own universe of stats, etc. Its just a matter of whether you want to provide that service to the community, and you might not for purely business reasons; maybe you want to offer it on a case-by-case basis through an application/registration process.

Let cheaters play by their own rules if they want, its only a problem if they mix with those looking for a fair game.

The question is though how easy/hard it would be to protect this key from third party access. (Given that Java can be decompiled.) Packet sniffing is another potential vulnerability.

Once someone finds out the key, he has to just add this key to the open source server and send it to the master server. (I could then change the keys regulary with updates but this feels more like a pointless cat and mouse game.)

The question is though how easy/hard it would be to protect this key from third party access. (Given that Java can be decompiled.) Packet sniffing is another potential vulnerability.
Once someone finds out the key, he has to just add this key to the open source server and send it to the master server. (I could then change the keys regulary with updates but this feels more like a pointless cat and mouse game.)

Your official servers are the ones you run, so you control the hardware, the private key only ever lives on the back-end server (stat tracking, etc), the public key only *needs* to be on the game server but could also be shared with clients (sharing the public key is safe) -- the private key isn't distributed to anyone; so its as secure as you keep your servers, and you'd only ever have to change it if the key got leaked (e.g. you were hacked). Other flavors of the game server (modders, cheaters, whatever) would generate their own key pair, the keys are not in the source code or otherwise baked into the application.

How do i prevent someone to host a server which is modified to allow cheating (by modifying the code)?

The question is though how easy/hard it would be to protect this key from third party access. (Given that Java can be decompiled.) Packet sniffing is another potential vulnerability.
Once someone finds out the key, he has to just add this key to the open source server and send it to the master server. (I could then change the keys regulary with updates but this feels more like a pointless cat and mouse game.)

Your official servers are the ones you run, so you control the hardware, the private key only ever lives on the back-end server (stat tracking, etc), the public key only *needs* to be on the game server but could also be shared with clients (sharing the public key is safe) -- the private key isn't distributed to anyone; so its as secure as you keep your servers, and you'd only ever have to change it if the key got leaked (e.g. you were hacked). Other flavors of the game server (modders, cheaters, whatever) would generate their own key pair, the keys are not in the source code or otherwise baked into the application.

I'll look into that. Thanks for the insight.

How do i prevent someone to host a server which is modified to allow cheating (by modifying the code)?

You can't do that, in this situation. Building a web of trust ("the official server") seems much more important.

However, you may not necessarily have to release the entire server for people to be able to develop mods.
You could have a "development host" that only allows, say, 3 people to connect, and that doesn't have persistence.
This is what people download to test their mods.
There are also different ways of structuring this -- for example, you can have the "development server" being your real game server, but chop out the "talk to a back-end database" part and make it hard-code a set of 10 possible user accounts, with user data stored in a simple file.

Once they've tested their mod, they upload the source code to your system, which builds a jar to make available for "real" game server sessions.
Requiring the source for mods is great for a few reasons:
1) It serves as documentation for the community
2) It allows more people to review the mod for badness
3) If you ever change the API, it allows you to update popular mods to work with the new version if that's important to you

This requires a little more investment on your part, and in turn, you'll get a little better handle on how the servers run.
Whether that's worth it to you is not something I can answer. Most games will not have the number of players where this matters.

That's a very interesting concept. But at the same time it's an overkill for this project. Though, i'll note that for future reference. :)

Thanks for the help guys. Now i have a bit more confidence and will release the source (one way or another) to the public.

Hi, first of all, I and my team are doing the same thing, we open source a game server framework, we call it NoahGameFrame, short as NFrame, we put this project source code in Github.

You think this thing have some good or bad influence, it is not superfluous, you need more time to maintain it and answer people's issues. But there's a positive thing, it's a helpful thing to you and other programmers.

I suggest you need to find some friends in the same camp, they can involve this project and get an improvement in their skills.

even if your server is open-source, cheating shouldn't be an issue. Just follow this one rule (which is even good for cases other than cheating - laggy connections and corrupted packets can cause issues too): don't trust what your clients tell you. As in, do all the important work (collision detection, physics, etc) on both ends - on the client end to minimize the number of "bad" cases to check, and on the server end just to ensure everything is right.