Published: 10 July 2009
What is 0 A.D.?
0 A.D. is a free, cross-platform, under-development, 3D, historically-based, real-time strategy game.
What are you doing?
Switching from a closed development process to open source: making the code available as GPL and the art content available as CC-BY-SA, and encouraging external contributions. We've been working on 0 A.D. in our free time for years, and now we want to show what we've achieved and make it easier for more people to get involved.
0 A.D. is a very complex and ambitious project. A lot of work has been put into it, but a lot remains to be done. We're not releasing a playable game – you'll have to wait until much later if that's what you're interested in. There are plenty of major missing features and bugs and rough edges. We're releasing this as a work-in-progress, pre-alpha project, aimed at developers who might be interested in this kind of thing, in the hope of sharing resources with a community that would otherwise be excluded from our development process.
This is an experimental step and we don't quite know what's going to work best, so we're going to move carefully and try to adapt based on experience. This document describes our current plans; feedback will be appreciated! Contact us on our forums, or #0ad on QuakeNet IRC.
Why should I care?
We think there's a good chance we can produce a pretty decent game with some unique features. Maybe you want to help that game come into existence.
Maybe you want to learn from the experience of working on a complex software project, or particularly on a game. There's a wide range of areas involved: graphics and audio, AI and UI, file handling and gameplay scripting and networking and so on. The basic framework is all in place, and some of it is already very solid, but there's a lot of scope for diving into the details and working on various components.
Maybe you want to make the game work better on your favourite platform. Maybe you want to show us how stupid we are and how you can write code that's much better. (We're far from perfect!)
Maybe you want to use parts of our code or art in your own project. Maybe you want to use our game for teaching a practical game development class. And maybe you have other reasons.
Why are you doing this?
We've been working on this game in some form or another since 2001. We've come a long way since then, but making this kind of game is really quite hard. The original team members were largely students, and have now moved on in life and can't devote much time to the project. Attracting new developers is difficult and time-consuming – few people have the time and skill to learn how to work within our existing code and to make significant contributions. So we want to lower the barriers to entry, making it easy for people to check out our project and see if it interests them, in the hope that some will decide it does.
Also, we have some ideas and tools and code that we think are quite nice and would like to share. We ought to clean them up and document them properly so they're more useful to other people, but making the code available is the first step. And, particularly on Linux, open source simplifies a number of issues with distribution and debugging, so it makes things easier for us and for users.
Up until now, access to the project has been limited to 'official' members of our group, though the intent has always been to produce a non-commercial game and membership has always been quite open. The concept of open source simply wasn't considered interesting a couple of years ago, but times have changed and it now seems the natural way to develop our project.
How is the development going to be organised?
In opening this project, we need to respect the community by providing as much information and communication and support as possible, so you can benefit from participating in the project (hopefully contributing back and benefiting us, of course!), balanced with our desire to get the game completed to a high standard and with some constraints from our past organisation.
In the past, all developers have been part of the official 'team': anyone can apply to join, we'll have a short interview over IRC to get to know them, and if it seems they have the time and energy and skill to contribute usefully then they're made a member. We're going to keep the core group of developers and the private communication methods – we don't want to risk destroying the team we've already got. We're going to keep aiming towards a particular design vision, and we don't want to diverge much from that – we'd rather not add (and have to maintain) features that aren't part of that goal. We're releasing the art and gameplay data for two of the game's six civilisations, but holding back the work-in-progress civs until they are more complete and usable.
Apart from those restrictions, we're opening access to the source control server (Subversion), and the documentation and issue-tracking system (Trac), and moving our technical discussions to an open forum. Anyone can download, build and run the latest version of the game. Our initial process for contributions will be very basic: If you make some changes, you should create a patch and submit it to us, and we should then review it and maybe suggest some changes or commit it to SVN.
Licensing of contributions is an open question. On one hand, accepting GPL code would guarantee to contributors that we're not going to unfairly use their work. On the other hand we'd like to keep our options open by only accepting BSD-licensed code, perhaps to produce a special version linked with proprietary cheat-detection software to discourage multiplayer map hacks that would be trivial to add to an open-source game, or to link with proprietary digital distribution systems to get more widespread distribution. The ideal solution is not clear, so we'd be interested in discussion of this issue.
What is the code like?
The code isn't all extremely clean or extremely modular or extremely well-written. It's been written by a wide variety of programmers, and it's far from a "completed" codebase. We want to continue cleaning things up as part of the normal development process. We're not averse to rewriting entire subsystems if that's the most effective way to make them satisfy our requirements. But in many areas it's quite solid.
What reusable code is there?
Most of our code is specific to the game and not very useful outside it, but some parts could perhaps be interesting for developers working on other projects. Some examples:
- Low-level library providing cross-platform support for resource management (archive file loading, GL textures and shaders, ...), debugging tools (error reporting, memory tracking, stack dumps), timers, asynchronous IO, allocators, ...
- Converter from COLLADA models with skeletal animation into a simple game-friendly format.
- Binary XML caching system, for faster resource loading.
- Automated build tools using Amazon EC2.
- Boring maths code for matrices, vectors, quaternions, etc.
How does this compare to other games?
We are aware of several other open-source RTS games. Glest has reached 'stable' status and is set in a medieval/fantasy world, with less complex gameplay and graphics but with AI opponents (which are not yet implemented in 0 A.D.). ORTS is a framework emphasizing AI research more than a playable game. Spring is another RTS engine that appears designed for gameplay similar to Total Annihilation. 0 A.D. is striving to differentiate itself by providing new gameplay ideas, detailed graphics and an an accurate historical setting.
How can I get started?
See the Getting Started guide to find more information about the game, forums for discussion, instructions for building and running the game, and links to further details.