Open source code vs client/server cheating

[SteveSmith]

Does anyone have any thoughts or ideas on getting round the problem of having open source clients for multi-player games, but preventing those clients being modified by a player to give them an advantage? The immediate answer is to do all calculations and checking on the server, but what if that isn't practical?

[Julius]

Do the same as in closed source games: some things are left to the server where it makes sense, the rest on the client. Being closed source doesn't prevent cheating at all (as you can easily tell by all the hacks available for those games), in fact there are plenty of skilled hackers who do it because they can hack "around" some sort of protection. An open-source client is just boring for them.

What might make sense is some sort of social cheat protection, e.g. kick votes, electable server "admins", accounts which can be banned etc. But that is true regardless of the openness of the code.

[andrewj]

One idea is to release all the source code except a small but critical piece, e.g. a little library which encrypts/decrypes the connection protocol. Only the official binaries (containing this library) would be able to connect to the internet servers. The source code would contain a do-nothing version, which would allow the game to "work" if compiled and run locally, just not connect to the real servers.

[Sindwiller]

One idea is to release all the source code except a small but critical piece, e.g. a little library which encrypts/decrypes the connection protocol. Only the official binaries (containing this library) would be able to connect to the internet servers. The source code would contain a do-nothing version, which would allow the game to "work" if compiled and run locally, just not connect to the real servers.

That would work from the point of view of a proprietary developer who does not grasp the concept of free software development at all, but in reality, it would be a pain in the ass for everyone, developers, users and future contributors. External developers who would like to fix a bug in the netcode can't do that because it isn't available to them. If a project has been abandoned for sure, there's no way to recover the original netcode if the initial developers left. And so on. Besides that, you have to consider what Julius said as well; those who hack online games for fun do that because of the challenge.

[SteveSmith]

AndrewJ's idea is probably the only realistic option, and it doesn't have to be a PITA. All you have to do is have an encryption key hidden in the binary release that must match the key on the server. That way, the source code will still work fine, it just can't be used to connect to a server that is "encrypted"; people will still be able to start their own servers with their own key.

(I also think that assuming no-one will hack a free game is a bit of wishfull thinking. )

[charlie]

Of course the Freeness of it is also a security benefit. It means you can't make assumptions in the network code. So really only transport what is known to each player, as the server will know this and the clients won't. Then the whole encryption key stuff becomes icing on a cake rather than the being the crux of the solution.

[MCMic]

Does anyone have any thoughts or ideas on getting round the problem of having open source clients for multi-player games, but preventing those clients being modified by a player to give them an advantage? The immediate answer is to do all calculations and checking on the server, but what if that isn't practical?

All code executed on the client side, proprietary or free, can't be verified. So you have indeed either to do all calculation on the server side, or to trust your gamers.

A gamer will always be able to do an alternative client or some modification to his client in order to play more easily or conveniently.

As said before, proprietary games (like counter strike) have a lot of cracks and hacks running around, it's not a problem of license, it is a problem of client/server organisation.

[DrAltaica]

AndrewJ's idea is probably the only realistic option, and it doesn't have to be a PITA.

<sarcasm>Yep that's why Diablo 1 doesn't have a singe hack for multi-player to this day.</sarcasm>

There is no "Open source code vs client/server cheating" when you Follow the first rule of Client-Server Architecture!

[SteveSmith]

I said it was realistic, not perfect.

[alapshin]

One more question for the same topic, guys: If a game is in MMO style, how to prevent bots invasion? That would be pretty easy to implement bot with an open source game client. The only idea I have is Captcha images that are shown before user can do an important game action, but that's ugly. Any thoughts?

[TheAncientGoat]

Design the MMO game sothat botting would be pointless :P The world doesn't need more mindless grinding...

[Julius]

Design the MMO game sothat botting would be pointless :P The world doesn't need more mindless grinding...

QFT!

[DGMurdockIII]

http://stackoverflow.com/questions/8119 ... rver-games

[sfb]

I find this conversation interesting because I've been on both sides of this equation and I've found that the client suffers greatly when it's rendered completely dumb. I'm sure that this varies from game to game - a turn-based game for example would exhibit none of the problems I am about to discuss. In Werewolf we wanted to ensure all of the actions were processed within our server in order to legitimate. This meant that a client didn't tell me where it moved to or how fast. It would just say "I'm moving while facing this direction." And thus a state system was born. Now the number one problem that occurred here was that the client was totally reliant upon the server to give it guidance and direction as to where to go. It doesn't seem like much to talk about 30-100ms but as a player you start to feel that "jerky" nature very quickly. The obvious choice was to then make the state machine shared and use a track to interpolate the positions, slice and dice and add in some simple dead reckoning for corrections (typically more common with entities your client does not own.) This helped but it still felt sluggish and unresponsive. The interaction of the state machine instances between client and server was still causing trouble for *other* clients. Add on top of this the floating point issues - with a server running on Linux on a Pentium4 and a client running on Windows XP (build using VS) and an AMD Athlon64 you can see that the compiler and floating point differences needed to be addressed. Being a small team and spending a very long time trial-and-error versions this got the best of us and we wanted to just give up. What we ended up doing was just letting run its state machine and back-buffering events using "LCT" or latency compensation time we were able to keep the clients all pretty close in sync. The other component of this was that our front-end server blindly relayed position changes to other clients and *then* passed the position vector data back to our game service/classes and did fact-checking.

Ryzom has the same essential concept - they have service called GPMS (Global Position Management Service) which receives all of the position data for entities and one of its jobs is to perform fact checkign and correction of clients. So to the accuracy of the GPMS you are unable to cheat the server and other players. In an open-source game my hope is that as flaws are found in the GPMS we can react to them or potentially the reporter can supply a patch.

I guess the other reason I'm not so concerned about it anymore is because the 1.5+ months I spent designing, redesigning, re-redesigning, and testing our various motion systems concepts were *not* spent making the game. And so out of pure and total frustration due largely to lack of progress we're (Werewolf) an addition to the Happy Penguin Graveyard. I truly encourage that you not ignore this if you wish server-ownership to be a core tenant of your design. If you can make it work I agree that it is probably an ideal design. The problem is getting it all to work right without impact to client perception and so on was way more work than I anticipated. So design around this if you want it and come back to refactor it to be perfect.

Just advice from a casualty of war.

Thanks

[Sindwiller]

Sounds horrifiying indeed. To me it seems as though a FOSS project like Werewolf really ought to rely more on reports from players than on a 100% fail- and cheat-proof implementation.

[sfb]

Sindwiller,

That's exactly what I'm suggesting. For FOSS gaming I think, as much as a traditional software designer would bemoan this, the easy way is the better way. I know I've linked the Party of One article here a couple times but I think that it is a compelling article and the things he suggests parallel this very thread - bite of what you can chew and refactor later or you risk your project dying in stagnation - no matter how perfect the code in Git/SVN/Hg is.

FYI, Party of One article: http://www.pushing-pixels.org/?p=305

[charlie]

Bite off more than you can chew... then chew it.

[SteveSmith]

At the end of the day you have to keep it fun, both the game and the job of programming it.