0 A.D. is an open source and free to play RTS being developed by a team of volunteers all over the globe. Erik Johansson provides some insights into this project in this Q&A.
What was the inspiration for the development of 0 A.D.?
0 A.D. started as an attempt to bring the time and civilizations from the first Age of Empires game into the engine of the second. It soon grew to be more than that and so work begun on creating a game from scratch. Over time other real time strategy games, like Empire Earth, Rise of Nations, and more, have inspired us as well.
What technologies are you using to build 0 A.D.?
0 A.D. uses a custom game engine named Pyrogenesis which is developed as part of the project. The engine is written in C++, a lot of it is custom written for the game, but we use libraries where it makes sense. We use SDL2 and sometimes need parts of the Boost library – we avoid overusing it because of compilation times. We also use Xeromyces for XML, libjpeg, libicu, NVTT for graphics, as well as a few other small libraries.
A lot of code is in-house, such as the graphical engine, the file management system, the audio manager, and most low-level code. This was to provide a FOSS game engine (Pyrogenesis) as opposed to say, using Unity or Ogre (which is strictly graphics).
Rendering is performed using OpenGL. We’re currently running OpenGL 2, but are working on upgrading. This is for historical reasons mostly, OpenGL support being in a different state on Linux/OSX/Windows. Audio system is based on OpenAL, with sound files stored in Vorbis.
The lobby system is based on XMPP with ejabberd server.
Since the project is cross-platform, programmers are using various tools for development.
3D models are stored in COLLADA format, which can be exported from different 3D CG software, many recent models are done in Blender.
To create game maps we use our custom scenario editor named Atlas, for which we use the wxWidgets library.
What have been some of the biggest challenges developing 0 A.D.?
The biggest challenge is probably to keep moving forward when you have a project of this scale, but people join and leave all the time. There can be quite a bit of a learning curve for new contributors. Especially since the people who wrote the code or designed the concept are not always around anymore, so it can be hard to know exactly what a piece of code is supposed to do or exactly what was meant by a specific concept.
Another challenge is that very few of us have got any previous experience with creating a game, or even working on a project of this size in general. It has lead to us having to start over on a couple of occasions, both with writing code, designing the GUI and forcing us to rethink gameplay concepts.
How do you manage the financial demands of a project like 0 A.D.?
The biggest aspect you have to learn to manage is your expectations. Things do not always go the way you expect them to. In summary we have had more money than we have absolutely needed, but not as much as we have wanted. We work on the project mostly in our free time, for free, so we don’t absolutely need money to pay for the development. Thanks to donations from people all over the world we have more than enough money to cover the necessary things like a dedicated server which both allows us to host the web site, downloads, and have some automated builds/testing done.
What has the reaction been like to 0 A.D.?
Mostly positive, it’s been obvious that there are a lot of people who are interested in a "classic" RTS. It’s been interesting to see how many different opinions there are however. Some players find the game too easy, some find it too difficult. Some players think that the game is too slow, some that it’s too fast. Some think we focus too much on history rather than gameplay, and some think that we don’t take history seriously enough. It’s an interesting challenge to try and find a good middle ground that can be interesting and fun for as many players as possible. Our goal is to make the game as moddable as possible though, so if people would like to do things differently they always have the chance.
How do you manage a team of volunteers from all over the world?
To manage the code and art we use SVN, and have Git clones for those who prefer to use that to stay up to date. To keep track of issues and improvements we use the bug tracker software Trac, and to communicate within the team and with other contributors we use our forums and IRC channel.
We use weekly meetings, to know what everyone is doing and what progress was made. During the Alpha 20 release cycle it became obvious how useful meetings can be. We didn’t always have enough things to discuss to warrant a meeting, so we ended up having almost no meetings at all. This meant that issues weren’t discussed as they came up, but rather were left and became too big to be easy to solve.
We do some rough planning for each Alpha version to make sure most urgent tasks are addressed. Depending on which developers have enough free time during a specific release cycle the exact features that go in a specific Alpha are hard to plan.
Development is very open with many discussions happening on public forums/IRC channels with community involved. Main difference of team members from community members is commit rights, which are granted after contributing to the project for some time.