Development guidelines

[Minthos]

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.

int32_t is defined in stdint.h and is exactly 32 bits wide
according to a quick google, msvc doesen't have stdint.h, but it has __int32 which should also be exactly 32 bits wide

[mikosz]

Hello there,
I'm looking for a game-programming related MA-thesis subject and I thought that maybe I could do some coding for the Spring project. Could someone suggest anything? It needs to be enough for a thesis, but it also needs to be possible to do in, say, 4 months...
Thx,
M

[Peet]

Fix/rewrite/finish sm3!

[mikosz]

Who can I contact to discuss this?

[Tobi]

You could drop me a PM. Or if you want to work on SM3 drop jcnossen a PM

[SwiftSpear]

It's an unfinished mapping format, just so you know well what you're getting into. SM3 was a fairly generic texture splatting system similar to what most RTS's use, but there's alot of improvement space in the land of texture splatting, so it could definately make a viable thesis IMO.

Keep in mind, for spring we also want something that is easy for our artists to work with. Spring artists in many cases have little or no code training.

[edit] If it doesn't sound interesting, PM tobi, he's got a million other things he can probably suggest.

[Hoi]

Posted: 09 Dec 2008, 09:15

Posted: 21 Mar 2009, 20:31

[SpliFF]

Weird mispost, sorry

[oliveoil]

Hi,

I'd like to take up work on SM3. If anyone has a better idea however (e.g. if there's someone who is already doing that, other things with higher priority) please PM me.

Thanks!

[FLOZi]

Nobody is really working on Sm3. So do it. Do it do it do it please.

[Kloot]

I intend to do a few SM3 fixes as well.

[FLOZi]

There is a difference between fixing the current implementation and rewriting it into a better model (i.e. filter tree instead of pipe) however.

[Kloot]

I'm quite aware of the difference, thanks. I also don't really need other people's posts copy-pasted for me to know where the format falls short.

[FLOZi]

Yeah and fuck you too.

Seriously why is it all the main Spring devs (other than Tobi who is always gracious edit: and baczek) are utterly fucking rude, all the time, to everyone.

I was just encouraging the new guy to work on an important project - I didn't realise you were planning to do any more than cosmetic changes here and there as i know you work on plenty of other aspects of the engine.

Seriously, w.t.f.

[Kloot]

It's just that "there is a difference between fixing and rewriting" seemed like a rather condescending (rude ) thing to say in response to "I plan to do some fixes", as if my post implied ignorance of that fact (or of SM3's design issues for that matter) or some form of hidden discouragement toward oliveoil. Perhaps the "as well" was a bad choice of words.

[FLOZi]

To me 'a few fixes' implied something less than a complete overhaul, which I think we can agree is what is needed (hence my hint about the structure which was aimed at olive oil rather than you)

[oliveoil]

No need to quarrel, please.

I am going to work on SM3 and see what I can do for it. For anyone else new and interested, there is a thread about SM3 going on now:
http://springrts.com/phpbb/viewtopic.ph ... 9&start=40

I welcome any suggestion what to start on -- e.g. issues that are not high priority at the moment and nobody is working on them yet.

[zwzsg]

In light of google summer of code, I wanted to check what an outsider wannabee student would find. First, G.S.O.C. mention alot using IRC, and neither irc.quakenet.org #sy nor any other IRC where Spring devs might hang are mentionenned anywhere on Spring website.


Secondly, this sticky is wholly out of date:

I'm not even sure sure Fnordia is still around. Might be better if the same info was posted by a currently active dev! All the other persons he mentions, SJ, Jouninkomiko, Piu, are also retired.

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.

That one part is still true and relevant. Though hard core fundamentalists might want to rephrase "Spring is a game" into "Spring is an engine".

Make Spring platform independent (SJ)
To begin with make it run on linux x86

I'm pretty sure that has been achieved years ago.

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

We now have several lobbies, TASClient by Satirik, SpringLobby by BrainDamage, QTLobby, ... I forgot how the old lobby was, but I'm sure the new one aren't as sparse and are much more feature rich.

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.

Making any pretty GUI you wish is now pretty easy to do as a widget. There's already quite a few GUI frameworks and GUI widget suites released. Game GUI is now the responsability of the game content developper, not of the engine developpers.

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.

Too technical for me to judge, but I'm sure networking was improved.

Add console

There's the ENTER key to send commands. And there's some widgets to improve it and make it behave as good as the console of any game.

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.

And then Trepan gave us Lua!

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.

Group AI was deprecated, and IIRC even removed. The same functionality are now implemented through widgets, in the Lua scripting language.

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.

We have skirmish AI interface now, and it's already been rewritten a couple time.

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.

That one may still be lacking.

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.

If we consider widgets replace the now deprecated group AI, we have plenty of those, some players would even say they are too many and too powerful!

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.

We got C.E.Gs. And later, L.U.P.S..

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.

Ok, no work has been done on that one.


If you want to stand a chance at google summer of code, this sticky needs to be unstickied, and an up-to-date one be created by a currently active dev.