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.

    Unreal Annihilation Screenshot

  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.
    Unreal Annihilation Screenshot

  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.

Next: What Went Horribly Wrong...