# TA Spring development guidelines 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 (SJ) 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.