Coding
From WarzoneWiki
Warzone Resurrection is written in C and uses the SDL (input and graphics context), OpenGL (graphics), OpenAL (sound) and PhysicsFS (filesystem) libraries.
All development activity goes through our Gna! project page. If you want to contribute, then first add yourself to our mailing lists. You can find us on the freenode irc network, channel #warzone as well.
The source code can be built in several ways. You can use the standard GNU Compiler toolchain with ”./autogen.sh && ./configure && make” (you can skip the ./autogen.sh part if you download a snapshot or release tarball). You can also use static makefiles with “make -f Makefile.raw”. Finally there are build projects for MSVC, Code::Blocks and Xcode.
Contents |
Directory structure
The source is structure as follows:
| Directory | Description |
|---|---|
| / | The root directory, containing build scripts mostly |
| /src | The main source code directory |
| /lib | Additional code factored into multiple separate parts |
| /lib/framework | Basic code and types used everywhere else |
| /lib/gamelib | todo: add gamelib information here |
| /lib/ivis02 | This used to be the old software renderer, which has been removed |
| /lib/ivis_common | Common code between all renderers |
| /lib/ivis_opengl | The OpenGL graphics renderer |
| /lib/netplay | Network code |
| /lib/script | Much of the scripting logic resides here |
| /lib/sequence | Code to show game videos (currently doesn't do much) |
| /lib/sound | Sound code |
| /lib/widget | Widget (basic UI) code |
| /m4 | m4 files beloning to the GNU build toolchain |
| /data | All the data files we can legally distribute |
| /win32 | MSVC project files and icons |
| /autopackage | Support files for building AutoPackages |
| /makerules | Support files for the Makefile.raw build |
| /debian | Support files for building Debian packages |
If you want to get a feel of how Warzone works, you may want to start looking at src/main.c. Command line parsing is done in src/clparse.c, and key mappings are in src/keymap.c. Enjoy!
Network
The network code needs a major overhaul. Details in the Netcode page.
Music
Not a game without an audible theme, to solve this, some community members have made Music proposals.
Todo
See the TODO file, and the task list on the gna.org project site. Warzone is a complete and mature game, but it still has great potential for improvement. The source code also needs cleaning. A good place to start is by writing some patches to eliminate compiler warnings, specialy 64bit pointer<->int casting warnings.
Release check list
Naming Conventions
- Project: Warzone Resurrection Project
- Title case
- Product: Warzone 2100
- With a capital 'W'
- Binary executable: warzone2100
- All lowercase and no whitespaces
Trunks and Branches
Code which is or is going to be released, resides in /branches/.
Eg. 2.0.6 is in /branches/2.0/. This is for bugfixes and tiny features.
Code which is in active development is in /trunk/.
Main development will take place in the trunk (/trunk/). Main development here means reasonably stable, yet untested, development. This means that the trunk should always compile, and run reasonably predictable. Of course mistakes are made so both of those two conditions can be violated at some times but should be corrected rather fast. (Apart from mistakes, these two conditions are usually met.)
As for branches, we should really distinguish between two distinct kinds of branches:
- release branches;
- development branches
Release branches are branches meant to stabilize the codebase, so these should only receive bug fixes, and at rare occasions small feature expansions. (E.g. the 2.0.x branch is a release branch in this respect, /branches/2.0/)
Development branches are branches for certain lines of development which will most likely cause a severe destabilization of the regular codebase. So to prevent severe destabilization of the trunk they're moved into an isolated area (the respective dev branch), so they don't cause problems for people working on the trunk. (E.g. the sound branch is a development branch by this definition, /branches/sound/)
The revision is a versioning number SVN provides for the whole source. It is not specific for stable or development version. From a simple revision number you can not immediately see whether it was a change to the /trunk/ or to /branches/2.0/.
This number is not updated by us, but by SVN when we “upload” code into the repository. It can _not_ be seen as a release. It merely is something for developers so they know about which change to the sourcecode someone is talking.
Revision numbers in combination with the respective branch (or trunk) can be used as a means of identification, but are nothing more than that: a means of identification.
You may want to look into the SVN-book for the basics. (the how)
Some info about branching: (the why)
- the Wikipedia article about branching
- a paper on branching and its reasons: Streamed Lines: Branching Patterns for Parallel Software
The /trunk/ is already extremely different from /branches/2.0/(and thus 2.0.6) when it comes to the code. That's also what makes backports more difficult. Not all of those changes are visible to the user.
What will go into 2.0(.x)? Bugfixes. Tiny features which are strongly requested and possible without breaking anything. The Changelog contains the current changes.
What should wait until 2.1? What currently is in /trunk/ will not appear before 2.1. What will go into the /trunk/? Anything that involves bigger changes (measured in lines of code) or might break something (including backwards compatibility). This includes any new features.
