Klaus said:
The point was to deliver an easy package to the users. A Makefile, that would require root-access, wouldn't do. And you'd have to check if some of the provided libs are already installed on the system.
You include the libs in the package and you make the main executable a script that sets the LD_LIBRARY_PATH environment variable before exec'ing the actual game binary. Same thing all the other commercial games for Linux do. No need for users to run makefiles or have root access or do anything else other than unpack the files and run the game script.
You can also use one of the open source installer builders that will create menu icons and the like... or create some simple RPMs.
So far as the anti-hacking stuff... I don't see how the crypto stuff would work against a dedicated cheater. It would be a very simple process to extra the compiled code from the official game and link it against a custom-compiled one.
Professional anti-cheat systems are VERY complicated, and include a great deal of sophistication. For one, your key checking and the like has to be strewn out all over the executable code, not just inside of a single easily separable module. The systems also do key checks against the binary to make sure it hasn't been modified and hook into various parts of the OS (not something that is Linux-friendly at all) to help ensure that the user isn't tricking the system.
Those are only really necessary for very latency-sensitive games (e.g. shooters) where the client has to be trusted to a degree. ALL games require that the server do every single last bit of processing that it can. That is simply a fact of multiplayer games. Even those shooters end up duplicating a lot of the anti-cheating work by having the server use sophisticated heuristics to second-guess the calculations it "trusted" the client with. And even then people manage to hack the clients (in the case of consoles, they'll sometimes hack the hardware itself!) and get past all those restrictions.
Mildly latency-sensitive games sometimes make use of a great deal of other tricks. For example, in a third-person click-to-move game, the client might send both the location it thinks the player is at along with the new desired direction and speed to the server. The server might have a slightly different idea of where the player is at (because it had kept moving the player by its old velocity for a few update ticks before it got the update), but it will allow the player to "jump back" slightly when the movement update is received. The server won't allow the player to jump forward (the player couldn't possibly have moved faster than the server said it could) and it won't allow the player to jump back too far (only within a reasonable distance for estimated lag and the player's velocity).
The server is the ONLY piece of software you can trust. Never send information to the client that the player is not in immediate need of, and never allow the client to make decisions that the server doesn't verify as legal. Whatever the client sends has to be treated as suspect. Balancing the needs of latency and the needs of anti-cheating is difficult... but if your game is not latency sensitive, you can ignore those issues. Treat the client as a dumb terminal, never send it information it doesn't need (if the player shouldn't know the end goal until it occurs... don't send the end goal to the client!!).
(Personally, I refuse to play online multiplayer games anyway. If I want to do multiple, I play with my group of friends who I know aren't cheating... having to actually interact with online game "communities" is one of the most frustrating and infuriating experiences I can think of.)
