Far too many mappers and modders seem to end up with piles of unsorted stuff on their hard drives. Some can’t find certain files in a pinch, can’t easily give their mod to playtesters, forget what changes have been made where and why and at what time, don’t prepare for additional people joining the project, have maps on the brink of failing to compile or using obscure formats (Valve 220 needs to die), no .def or .fgd files for level designers, no ordered way of collecting feedback and ideas, and generally end up in an uncontrollable clusterfuck. On top of that, a lot of content is lost to disk or PC breakage – I have seen it several times in the last year alone and every time I wanted to scream “Nooooooooo!”
There are better ways to do things.
First off, it is better to work in a team than to work alone. Full stop. A team can do things that an individual can only dream about. And it can do it in a shorter time. Teamwork is key to actually getting an ambitious project released. In pro game design, a lot of people are part of making one level of a game. That’s beneficial – as long as someone has a plan and everybody is good at what they’re doing.
The most crucial things for teamwork are organisation and communication. There must be a way to distribute the content to content creators and playtesters, and relatively quickly create a release from it. There needs to be something where feedback and ideas are collected, sorted and made accessible. E-mail is not the best way to accomplish any of this. Chat is a good way to quickly and informally develop ideas, though.
RMQ uses two main tools to organize itself.
1. A central SVN repository. This keeps track of any change that is made, and archives each revision so it can be reverted to if needed. It acts as a rather safe backup mechanism – the importance of this can’t be underestimated. It allows all coders, level designers, modellers, artists, playtesters E.T.C. to access all of the mod at any time. Even if your harddisk breaks, it’s just a matter of checking out the entire thing onto your new system again.
It allows everybody to make changes without breaking stuff. It provides a directory structure for the mod from which a release can be relatively quickly packed together (a matter of one or two hours). It contains important resources like entity definition files which are continuously updated.
A new playtester simply needs to install TortoiseSVN and check out a local copy. He can then immediately play RMQ by using his local SVN copy as a gamedir.
A new level designer on the team does the same. His working copy will come with .def and .fgd files and everything needed to start mapping. Even texture wads. Documentation, even. On top of that, the SVN acts as a backup – no need to lose 2000 brushes because your PC broke. Maps are regularly checked in (uploaded). And then they’re safe.
The SVN also contains the engine. There is always a Windows and a Linux binary in the repo.
2. A TRAC system that’s used like a private forum and represents an organical, self organizing game design document. The TRAC contains close to 200 tickets. There are tickets for everything in the game, from “Ogres” to “E1M1RQ” to “Multiplayer” to “Episode meta ticket” and “Chat”. Tickets can be organized and searched. They can have images attached. They can contain bullet point lists (Wiki formatting). They can be crosslinked. They have properties like Priority, Owner, etc.
The TRAC is the heart of the project, its communication hub and its collective memory. All team members have TRAC access.
A new level designer would typically accept ownership of his map’s ticket, creating the ticket first if necessary. The episode directors have ownership of the meta tickets (Episode 1-4 and multiplayer) from which the individual maps etc. are linked.
Playtesters post feedback into the relevant tickets and pitch ideas in Chat tickets etc.
Coders have an eye on the QC Bugs ticket and the project related tickets (a demo would have its own ticket from which it is organized) as well as many individual tickets and chat.
Other communication channels are used besides the TRAC, such as an IRC channel and e-mail.
This is a print-out of the top of the ticket list; note the colors signify priority. A demo ticket will typically be top priority, next are the episode tickets and everything someone considers important (if only to remind himself, heh). This is only page 1 of 5! And many tickets have a lot of entries. The TRAC runs since the end of 2008; it was established along with the SVN when more people started to join the project. It has really paid off. And I dare say the RMQ TRAC is more active than any community forum.
The TRAC is kept private at the moment, to avoid too many people talking into our ears without really contributing anything. Imagine someone spamming our TRAC or posting insults. No thanks.
However, we have 3. A development blog for making assorted things public. You’re reading it. Via comments here, people can talk to us. Several members have blogs or websites. The IRC channel, #rmq on irc.anynet.org, is also open to everyone. And finally, most of us frequent the community boards and sometimes servers.
The Realm of Blog Magic 