Signed Multiplayer Binaries


I'm sure that it is 100% legal if you distribute a dynamically linked binary with your crypto stuff in it (one file) plus separate files of those libraries that you use (other files: .dll for windows, .so for linux).

If you link statically, I mean - the executable is a single file which includes both your crypto stuff and the libraries, then I suppose it might be a problem. But I'm sure that it will not bother anyone.
 
cosurgi said:
I'm sure that it is 100% legal if you distribute a dynamically linked binary with your crypto stuff in it (one file) plus separate files of those libraries that you use (other files: .dll for windows, .so for linux).

If you link statically, I mean - the executable is a single file which includes both your crypto stuff and the libraries, then I suppose it might be a problem. But I'm sure that it will not bother anyone.
Let me turn this whole thing on it's head then. For a dynamic linux compile, is it possible for me to include compiled linux libs (.so files) in the game directory like I do the Windows dynamic binary? I know I did this for SDL_gfx for my first release... but the file had to be placed in a specific directory and it was a mess for the poor Linux users.

Alternately I could put my Crypto code into a lib, which leaves me with the same problem, actually.

Hmm, new question... how easy is it to decompile from a .o file to a .cc and .h? That might be another interim solution, including Crypto.o . Probably won't work. Not for Windows users for sure.
 
Last edited by a moderator:
cosurgi said:
I'm sure that it is 100% legal if you distribute a dynamically linked binary with your crypto stuff in it (one file) plus separate files of those libraries that you use (other files: .dll for windows, .so for linux).

If you link statically, I mean - the executable is a single file which includes both your crypto stuff and the libraries, then I suppose it might be a problem. But I'm sure that it will not bother anyone.
I'll second that: dynamic: 100% safe, static: technically not, even though true to the spirit. The crypto-class sound like a really good idea, though. Now that you brought that up, I think Cube/Sauerbraten did something similar.
If you don't want the user to go through the hassel of installing a bunch of libraries, you could try to just include them in a local lib-folder and add that to LD_LIBRARY_PATH in a startup-bash-script.
BTW, I really appreciate that you put so much thought and effort into offering a free and open version of your game while at the same time taking care of dependency hell on Linux-systems! It would be much easier for you to just release a closed, dynamic build and let the users deal with it. Thanks!
 
Last edited by a moderator:
Trevor Bradley said:
Let me turn this whole thing on it's head then. For a dynamic linux compile, is it possible for me to include compiled linux libs (.so files) in the game directory like I do the Windows dynamic binary? I know I did this for SDL_gfx for my first release... but the file had to be placed in a specific directory and it was a mess for the poor Linux users.
Yes, you have to add the current directory to the LD_LIBRARY_PATH environment variable. Though normally you would use a makefile to copy the files into the correct directory's.
 
Last edited by a moderator:
Hessiess said:
Trevor Bradley said:
Let me turn this whole thing on it's head then. For a dynamic linux compile, is it possible for me to include compiled linux libs (.so files) in the game directory like I do the Windows dynamic binary? I know I did this for SDL_gfx for my first release... but the file had to be placed in a specific directory and it was a mess for the poor Linux users.
Yes, you have to add the current directory to the LD_LIBRARY_PATH environment variable. Though normally you would use a makefile to copy the files into the correct directory's.


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.
 
Last edited by a moderator:
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.)
 
Last edited by a moderator:
elanthis said:
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.
Yep, that's what I was talking about. Maybe it wasn't too obvious in my awkward English.
 
Last edited by a moderator:
assuming that the game is ran from the current directory, you just add ./ to existing LD_LIBRARY_PATH
CODE
LD_LIBRARY_PATH=./:"${LD_LIBRARY_PATH}"

then simply copy all the .so files into your game directory.

To support different architectures, like ARM, 64bit, 32bit, you can make separate directories, put .so files in respective directory and make several different startup scripts, each of them will do:
CODE
LD_LIBRARY_PATH=./arm/:"${LD_LIBRARY_PATH}"

CODE
LD_LIBRARY_PATH=./32bit/:"${LD_LIBRARY_PATH}"

and so on. Then you will have several different executables, compiled for each architecture, and each startup scrip will call the right one.
 
could you dont have something that shows the screen of the players or something and if someone violate the rules you ban them for half a year or something. or you could have your server to look through the players files and compare them to some standard file or something(depending on size of the game though) or you will just trust that people will bash down at cheaters enough for people not daring to cheat.

Also I dunno whats possible I just have ideas.
 
Back
Top