Unreal Annihilation Post Mortem news

The Postmortem

Introduction

UA mod developer, FireSlash, lets it all out on the development of Unreal Annihilation, which spanned the lifetimes of three Unreal Tournament games.

"The main concept behind Unreal Annihilation is to bring the RTS style of Total Annihilation to Unreal Tournament 2003. To do this, we plan to employ two methods; The classic Overhead view, and the engine's favorite First Person view. Both of these views will aid the player in leading his units to victory.

The story line simply follows in Total Annihilation's footsteps. Even after the war between humans had ended, the two factions of the Arm and Core still fight on over un-inhabited worlds, lead by their Commanders. Instead of human pilots, the Core simply copied their soldier's brain patterns into a computer, allowing them to simply copy it into each new unit, where the Arm uses cloning to create its pilots. Thus the war of the clones vs patterns began, better known as the Arm vs the Core."

The Unreal Annihilation project started in 2001 as Total Annihilation:Unreal Tournament (TA:UT for short), on classic UT. UA was the evolution of the failed TA:UT project on new technology provided by UT2k4

WHAT WENT RIGHT

1. Make a mod that is so unique, everyone will want to play it: UA was special. And not in that 'I drool on people' kind of what. UA was the first mod I'm aware of that even attempted, let alone executed an RTS gameplay style on the Unreal engine. Further pushing this to UT2k4, with it's vast terrain abilities, the engine seemed to almost scream for UA. The great thing about UA is that it turned heads. We got tons of traffic every time news was posted, and people were genuinely interested in the mod. It wasn't just another mod with new weapons and some gimmicky gameplay mode.

   
   
   

2. Make everyone in your team feel important: Taking what I learned from TA:UT, I organized the team less like a company and more like a group of friends. I continued to be the leader, but I gave everyone a say and took a more democratic approach to major decisions. This gave everyone control on the mod's outcome; because let's be honest: UA wasn't going to write, model, skin, and animate itself. I had to remove the "My mod" mentality and replace it with the "Our mod" mentality, and it worked well. People felt more attached to UA, and things moved a lot smoother.

3. Make communication easy: I realized that a lot of problems in the team came down to communication. Forums were a great tool, but they don't work well for more perminant data storage, as well as task assignment and "What I'm doing" kinds of posts. With these problems in mind, I wrote three web applications to enhance communication through the team.

   • Xephon Wiki - A simple online wiki. The wiki produced a solid storage place for people to write information down without the need to dig through old posts or worry about it dropping off the front page.
   • Xephon Task Manager - This PHP driven application allowed the team to create tasks for things that needed done. For instance, if a coder needed a model's animation sequenced fixed, they would create a task. Arm Peewee fire sequence does not loop properly. An animator would log in, and see this task floating around on the list for his department, and would have the option to accept the task, or delegate it to another animator. Once accepted, it would show on this person's task list until the animator fixed the sequence and uploaded the fixed files. Then, the animator would create a task Arm Peewee needs re-imported with latest UKX. Rinse and repeat.
   • Xephon .plan - A simple .plan system to allow team members to give everyone an idea of what they're doing.
   
   
   

4. Set a deadline: I learned after a while, that people love to procrastinate. If you give them a deadline, they see this as a "I have to get this done before xxx", instead of "I have to get this done some time". Every time I set a solid deadline, staffing permitting, the job got done. This was best illustrated by the two public releases, both of which were given very definite release dates.

5. Keep the rest of the world in the loop: It's easy for mod teams to forget that everyone else likes to know what's going on. If you look at the UA website, you'll notice that .plans and tasks are externally visible. Certain parts of the wiki are going to be external too after a few more revisions are made to the website's content management system. The main advantage of this approach is that it keeps potential developers interested. Let's be honest, people come and go all the time in a mod team. Having people educated about your mod and ready to jump in really makes things easier in the long run, and reduces downtime between members.

WHAT WENT HORRIBLY WRONG

1. Scope, scope, scope! UA had plans for a mind-boggling number of units. This put our modeling, skinning, and animation folks in so many kinds of screwed that I sometimes wonder what kept Lupin from going postal on us. On top of that, we were trying to code every little feature TA had into UA's interface, plus a first person interface for every unit. Needless to say, this turned out to be a gigantic task that seemed at times endless. This tediousness really reduced team morale, and kept development in the grand scheme of things, at a crawl. One must remember, a mod team is not a commercial development team, and scopes should not be written to match one.

   
   
   

2. Write, re-write, delete, and write again: UA suffered from a major problem in it's code. Almost monthly, at least one major chunk of code was tossed out and re-written from scratch for flexibility issues, or general problems including the infamous "I don't know WHY this isn't working, so screw it, lets rip it out". This constant turnover in code produced countless bugs on the side, and made the code practically impossible to properly document. New coders would look at the code notes, then the code, scratch their heads, and cry. Almost half of the coders that joined the project left after a single compiling commit.

3. Transparent productivity: One major issue in coding is that 3000 lines of code can compile out to adding a cool looking bar at the top of the screen. There was always a feeling in the team that the coders didn't do much, because progress was externally so slow. This, in turn, generally pissed our coders off and further increased turnover. It also made the mod's frequent updates look like all we were doing was making models and skinning them, in effect making it hard to locate additional coders willing to help out in what looked like a project without code.

4. Code + netcode != network capable code: None of our coders really understood the Unreal engine's network system. Instead of learning it, we just ignored this issue and wrote the code to work in single player, using the excuse "Oh, we'll add netcode later". When it finally came time to add the network code, we ended up ripping out massive portions of code that simply weren't compatible, further slowing down the development cycle and obfuscation of the code.

   
   
   

5. Anyone seen a texture artist? With a massive project such as UA, we found ourselves missing a texture artist most of the time. Without one, progress literally ground to a halt. When we did have one, he'd be overworked and without help. This problem held up progress on a regular basis, and further contributed to the Transparent Productivity issue.

Conclusion

At the end of the day, we can only look back and learn from our mistakes and folleys. UA was a massive project with about half the staffing required to complete it. In the 6 years now that this project has been in and out of development, I can only look back and wonder what could have happened if things had been done differently.

The biggest problem overall is that we're not a professional team. I can't threaten to fire people if they don't work, and I can't expect professional quality work. The best I can hope for is for progress, in any form. Furthermore, the larger problem in the Unreal community is that there are too many mods with not enough people. there was never a time when I could sit back and say to myself "Wow, we're fully staffed". I fear this may be creating a further mentality that almost no mods make it, because it's sadly true with things moving the way they do.

While UA may not have made a solid release, I do like to think it was a success. Progress may have halted with UT07 around the corner, but the mod itself hit a state where it did get released, and with all the assets public, I can only hope people finish what we have started.