Development guidelines

Post by **Fnordia** » 27 Apr 2005, 14:58

This document describes important things to think about when developing code for Spring.

Spring runs synchronized on all computers
Spring's networking is built upon the assumption that all player's simulations are in sync and only send their (or their AI's) input over the network. This mean that you will have to be very careful to keep the simulation deterministic. Here is a few pointers to think about.

There are essentially two sorts of code in spring, synced and unsynced. Which code is what is not as clear as one could wish but essentially the synced code is anything that is reached through CGame::Simframe or handlers of some network msgs, unsynced is everything else (graphic, input, sound etc). Synced code can write anything but should only read synced data. Unsynced code can read anything but must not write synced data. The rest of the points here is essentially about synced code.
Always make sure to initialize variables. Even if the value doesnt seem to matter it might unsync the simulation.
Be paranoid about array boundaries, reading one byte beyond an array might not crash but it will probably cause sync problems at some point.
For random numbers use the CGlobalStuff::RandFloat etc functions (but never use these from unsynced code)
Never compare memory block locations other than for equality. This mean for example that you shouldn't create a std::set or std::map with a pointer as index if the order might matter.

Adding your own stuff
We welcome anyone to make changes to Spring but in order to get them accepted into our distribution the following can be worth thinking about.

Spring is a game and different people might want different things from it. So if your changes change gameplay it might be a good idea to make it optional.
Resources (esp. CPU time) is always in short supply for spring so make sure that you dont waste them needlessly and that your resource usage is in proportion to the impact of your changes.
Ask around before starting on a change. Not only might you get tips about how to implement it in the best way but also if anyone else is working on something similar.

Some example projects
Here is some stuff that we know needs improving in Spring. Of course there is about a million other things that also need improving. If you are interested in something and want to help out with the development, you can talk to the responsible person to get more information.

Make Spring platform independent (SJ)
To begin with make it run on linux x86 (making it sync with exes running on other CPUs might be hard, even different compiler options can cause problems with floating point stuff it seems). Will probably involve lots of changes in different parts of Spring, although hopefully not that big.

Improve the lobby (Jouninkomiko)
The current lobby is very sparse and need more features.

Game GUI (SJ)
The current GUI in Spring isnt that good however there exist a new gui that is almost finished. Unfortunally Pius that was working on it disapeared some months ago so we need someone else to finish it and generally improve the GUI.

Game networking (SJ)
Its probably possible to crash the game or worse by sending malformed data to the network at the moment. Fix this and also see if you can reduce bandwith usage and/or improve the handling of packet loss.

Add console (Fnordia)
Add a game console to the game, preferably tied to some scripting language (below).

Add scripting language to game (Fnordia)
Add some sort of general scripting language to the game to run non performance critical game code in and allow easy modability through some sort of plugin system.

Improve groupai interface (SJ, Fnordia)
Make it possible to write groupais in a scripting language(above) in addition to as DLLs. Also add some more functions to the interface to allow communications between AIs.

Add a global ai interface (Jouninkomiko)
Add an interface similar to the groupai one but with an extended interface (possibly allowing some amount of cheating) in order to allow the writing of skirmish AIs. If the cheating part could be disabled it might also be good to create a global helper AI for the player.

Create a map editor (SJ)
The current mapconv program is very limited and only allow compiling maps from already created data. Create a real mapeditor to allow editing of spring maps.

Write more Group-AIs (SJ)
Spring is designed to allow each player to run their own groupais. So the more the merrier. The license doesnt in any way force you to release these to others but it would be greatly appreciated.

Improve explosion grapics (SJ)
The explosion interface has some support for adding different types of explosion graphics although there currently only exist one. Add some new types and bind certain explosions to them. This is for all you mushroom nukers out there.

Create an anticheat program (SJ)
Since Spring is opensource it will be very easy to create information cheats for it (the networking protocoll should prevent outright manipulation of data). Therefore create some sort of PunkBuster like program that only allow playing with known good exes. Either dont use any Spring code in it to go around the GPL or we will make an exception for it in order to allow it to be closed source. Sadly security through obscurity is the only thing that will work (and it only works to a degree) in this kind of situation (except calculating everything on the server and sending ready made screenshots to the clients), at least until Paladium arrives.

IceXuick · Post by **IceXuick** » 17 Mar 2006, 01:25

I think i might help you devs with the gui (for as far as it is unfinished)

And you don't have to worry that i will disappear. As a matter of fact, in 2 weeks, i can plan 4 months of study. I was thinking of going for game design. So if i do this, which is probably going to happen, i can at least help you guys for 4 months full time! after that, i'll probably be so addicted i will continue to help out with all kind of graphics which is needed. (lobby, skirmish thing, settings, textures etc.)

let me know what you think.
For some demo TA graphics check a concept page of mine:

http://icexuick.dagdief.nl/ta2/conart.htm

For some demo graphics check my portfolio site (which is in high need of updating (last update was like 7 months ago))

http://icexuick.dagdief.nl/cv

If you like to get in contact, mail me: icexuick@dagdief.nl

SeanHeron · Post by **SeanHeron** » 17 Mar 2006, 10:45

Hey, I sent you a private message (just in case you didn├é┬┤t notice... ) .

IceXuick · Post by **IceXuick** » 17 Mar 2006, 16:21

Ah! so i see. I replied you with a pm as well.

thx for the fast reply.

IceXuick

Tobi · Post by **Tobi** » 25 Apr 2006, 20:31

Another guideline:

* Don't use longs, as they're 64 bit on 64 bit platforms and 32 bit on 32 bits platforms. As such they may cause sync errors, and on 32 bit int has the same range anyway.

PauloMorfeo · Post by **PauloMorfeo** » 27 Apr 2006, 21:01

Tobi wrote:...
* Don't use longs, as they're 64 bit on 64 bit platforms and 32 bit on 32 bits platforms. As such they may cause sync errors, and on 32 bit int has the same range anyway.

Aren't integers the same ├é┬½size as the OS├é┬╗, beeing integers 64 bits on 64 bits platforms and 32 bits on 32 bits platforms?

Tobi · Post by **Tobi** » 27 Apr 2006, 22:09

Not with gcc

PauloMorfeo · Post by **PauloMorfeo** » 28 Apr 2006, 23:40

I would never have guessed of such a diference. I thought it was some kind of specification of the language, C/C++, and not of the compiler.

In GCC integers behave like what? Always 32b?

Tobi · Post by **Tobi** » 01 May 2006, 10:50

yes (on modern desktop platforms at least)

keithjr · Post by **keithjr** » 07 Aug 2006, 18:37

There are some differences in how data types are handled in 64-bit on different OS's. It depends if the architechure uses LP64 or LLP64. Check out the table on this page for more info:

http://www.unix.org/version2/whatsnew/lp64_wp.html

Windows uses LLP64. Most unix flavors, however, use LP64. 32-bit today is almost entirely ILP32. Consider the differences between 32-bit and 64-bit schemas, as well as the differences between LLP64 and LP64, when coding for maximum compatibility.

Caradhras · Post by **Caradhras** » 18 Nov 2006, 20:06

I've got a question to this point:

Create an anticheat program (SJ)

Why do you just want to make the system closed source?
As I learned while making a presentation about encryption, that a real good algorithm is 'open source' or just public known.

For example the Rijndael-algororithm (AES, used in WPA2,Skype...) and as far as I know, it hasn't been broken yet, even though it just offers a keylength from 128 to 256bit.

And among cryptographer this is a holy principle, what is known as the Kerckhoffs-principle (have a look at wikipedia, there's a good article about it).

So, isnt there a possibility, to create a system that is secure enough, without beeing closed source?

And Palladium will probably (hopefully) never be released as it was planned...

If anyone works on this anticheat thing, I got some ideas.

Now, I if you want to play Spring over the internet, you have to connect to the server, right?
So we could code a program, that calculates a hash of the critical spring files and sends this data with information about buildnumber of spring etc to the spring server, when the spring server accepts the calculated hash, it allows the client to connect to the lobby.

For the case, that an attacker wants to change the hashprogram, we need to integrate support for certificates and perhaps ssl, to transfer the hash etc.
I think there are some Opensource programs, that could be implemented.

I think, this could be an efficient way of solving the problem...

Opinions?

Before you're asking, I would lovely do that, but I have no idea of coding...

Tobi · Post by **Tobi** » 18 Nov 2006, 20:10

IMHO any anti cheat method other then not playing with cheaters (or e.g. building a sort of web of trust of known good hosts/players) doesn't work. Checksums that have to be sent to a server can be easily spoofed, spring binaries even differ on different platforms, etc.

In short I think it's a waste of time to develop anticheat measures, unless they're trivial.

Thanks to the network model any other cheating then info/maphacks or GroupAIs that perform micro or something isn't possible anyway.

Caradhras · Post by **Caradhras** » 18 Nov 2006, 20:43

how can they be spoofed?

if you use certificates, which proof the correctness of the checksum?

Why do the checksums of the exes, for example, differ?

Shouldnt they be the same for for build 0.73b1, for example?
Linux users would need a seperate handling...

Post by **Kloot** » 18 Nov 2006, 21:35

They can be spoofed because somewhere in the client code there has to exist a function calcHash() and another function sendHash() which calls calcHash() and sends its return value along to the server, meaning all you need to do to bypass the server-check is change calcHash() so that it always returns a valid value (say 12345):

Code: Select all

int calcHash() {
//  return (hash(file1) + hash(file2) + hash(file3));
    return 12345;
}

Caradhras · Post by **Caradhras** » 18 Nov 2006, 21:58

hmmm, I am no mathematician, but I will get some books about cryptographics, perhaps a mathematicial no-brainer like me finds possible solution...

jnnnnn · Post by **jnnnnn** » 20 Nov 2006, 12:59

Although there is a simple method of avoiding hash spoofing (salt values), I agree that cryptographically strong anti-cheat methods are not effective and incredibly difficult to get right (I can't think of any examples, even commercially - look what happened to Valve).

Salting: The easy way to block the simple hack below is to require the server to send a salt value that gets appended to the valid file(s) used to generate a checksum. There are, of course, more ways around this, but it prevents a simple hack like the one suggested above.

bamb · Post by **bamb** » 20 Nov 2006, 15:13

A closed source security dll/so that yes, checks server-sent data against the executable. That's how it's done in qw.

Assets like models or textures are probably not worth checking here, are they?

AF · Post by AF » 20 Nov 2006, 15:33

is a closed security dll even possible under springs GPL license?

BlackLiger · Post by **BlackLiger** » 20 Nov 2006, 15:54

AF wrote:is a closed security dll even possible under springs GPL license?

Yes, they can make an exception under the license, AF. Part of the way it works :)

elio · Post by **elio** » 09 Jan 2007, 14:53

bamb wrote:A closed source security dll/so that yes, checks server-sent data against the executable. That's how it's done in qw.

Assets like models or textures are probably not worth checking here, are they?

There may go some platform independence; you'll need to have a trusted coder/porter for each platform/arch you want added to the group.

Spring RTS Engine

Development guidelines

Development guidelines