Making Mods/Distributed Development

Making a Distributed Development Team Work

It's fair to say that most mods are developed by a single person working on their own, or maybe a couple of people in the same time zone. When a team is distrubted in both space and time zone the single most important factor for a mod team's success, communication, becomes extremely difficult.

Talk or Die

People communicate most effectively when they are sat in front of each other. You can talk freely, draw diagrams, and generally make points that would be missed or misinterpreted via another medium (axcept maybe by phone). I have seen a very long and dull e-mail conversation (about 90 odd messages) over 2 days about a particular problem get resolved in a 10 minute face to face meeting.

When a mod team is distributed face to face meetings are hard, and most likely impossible. It seems that if you are not sitting next to, or near, a person you are working with it's very easy to forget that they exist. Once you forget that they are around then you stop communicating. That's bad.

Isolation is the killer. It can cause any or all of the following destructive patterns, all of which can be avoided by good communication.

One thing vital to the success of your mod is that everyone on the team needs to be working towards the same end result. When the team is separated diverging ideas about what the mod should be can easily creep in.
Sitting alone building a model or coding up a new weapon it can be very easy to get the feeling that you are the only person doing anything on the mod. Especially if you've not heard from anyone on the team for a while.
Lack of feedback is particularly disheartening. If you want to discourage someone working within the same mod team as yourself then never give them any feedback on the work they do.
Failing to track progress effectively can be a killer. It doesn't matter whether you deliver the mod early or late, it's only a game mod, but not knowing how far towards completion team members are can be frustrating and worrying.
When a team member goes quiet, either by no longer replying to e-mails (or maybe they get bounced), or simply no longer sending out a steady stream of information, it effects everyone on the team. Perhaps they've quit the team and are too scared to tell anyone. The could even be working away, quite happy in their own little world, cracking on with the delivery of their bits of the mod. The fact that you don't know will cause confusion and possibly duplication of effort. It can also be discouraging for them if they pop up suddenly and say, "Here's that widget we needfor map X.", and get a response like, "Oh, Dave did that last week, we thought you'd gone.".

Little Bits

Although communication is the most significant problem facing a distributed development team there are additional challenges that can just as easily cause problems.

Having more than one developer work on code is hard. It's vital that you break the code into different parts (modules) that can be developed as separatelt from each other as possible. For example if your mod has new weapons and new gameplay elements, then its not too unreasonable to have one coder work mainly on the weapons part while another coder works on the gameplay (the game type, HUD, mutators, etc). If you have purely a weapons mod, you could simply assign three to each coder for example. The tricky part is always the integration of the code after it's been written.
Code integration is hard. It's well worth the effort of assigning owners to specific modules and files. Even though the temptation will be extreme, never change files you don't have checked out (or you don't own). I guarantee that you will lose code at some point during the mod development when you try and integrate your code with that from the other developer(s) if you do.
It's well worth taking the "release little and often" approach within the team. Releasing your code and content to each other as often as you have a stable version of a new feature has a number of benefits. It provides the team with a sense of progress. It gives everyone in the team practice as pulling the whole mod together. It allows for regular internal shake down testing. It ensures that everyone is working towards the same goal (there should be no suprises in what's delivered). Don't fall into the trap of releasing code that simply won't run though. You'll simply hold everyone else on the team up (and they'll hate you for it).
Every time a member of the team releases some new code, texture, model, or other asset do your very best to grab the release and apply it to the build you are developing against. This ensures that there are no integration nightmares at the end of the project. It's not uncommon for things to break when mod assets are integrated. Frequent integrations keep the amount of pain to a minimum.
Make sure you have a centrally maintained build script (and build manager if you can manage it) to pull everything together.
Small teams are better.
Over all it's much easier to transfer little bits exactly how you want them then it is to transfer the entire mod and find that it is like putting a square in a circle.

If at all possible set up a Subversion or CVS system on a server, so there is always ONE true up-to-date version, and anyone can grab it. This is worth doing even if the only CVS server you can get hold of runs on one of the team's PCs and is not available 24 hours a day.

Jb: One thing that I think works for sharing code is when you can break you code into different parts (modules) that can be developed in part, separate of each other. For example if your mod has new weapons and new gameplay elements, then its not too unreasonable to have one coder work mainly on the weapons part while another coder works on the gameplay part (new game type, HUD, mut, ect). Or if you say have a weapons mod. Here you could split up the weapons an "assign 3 to each coder" for example. Then the tricky part is only have one to bring it all together. Not sure if that fits anywhere... just IMHO that it might work somewhere

EntropicLqd: Agreed. I've got a paragraph written up on that at work that I never got time to paste in. I'll combine yours and mine and drop it in. Your examples were better I think. You can just edit the text of the main content if you want though. I'll update it tomorrow.

EntropicLqd: Yours was much better so I kept it, and tacked what remained of my thoughts on the end.

Jb: Nice work EntropicLqd!

EntropicLqd: Thanks, but you started it, and that last update was pretty much all yours anyway.

ZedSquared: This whole making mods section is fantastic folks! Well done, I'll see if I can add anything worthwhile but I think you've got it all already :-) It might be worth mentioning that for good reliable free cvs services (as well as mailing lists, forums, bug trackers and loads more) it's worth considering hosting your project on sourceforge, the only downside is that your development stage code will be available for anyone to download if they can work CVS. Oh and you have to be releasing your mod under GPL type license too. There are also some good docs on installing wincvs over there.

Lilguy: I don't have time to reformat it at the moment, but a lot more has to be said about version management systems like CVS and Subversion. These types of programs are standard in any type of professional development environment with more than a couple developers, and can even be very useful on a personal level. They track changes, and efficiently store everything that has ever been committed – so nothing that's been checked in can ever be truly destroyed, unless the cvs server itself gets destroyed. They also are fairly good at merging code changes together, so if two people happen to work on the same code (changing different lines) then there's a pretty good chance that it will be able to merge the changes correctly. So essentially, it deals very effectively with every one of the issues in the "other issues" section. They are used most effectively when everyone who's working on something does an update before starting to work on something, and commits as often as possible (i.e. as soon as the code you're working on compiles and runs)

Foogod: BTW, I've just added several pages to the Wiki about setting up Subversion for Unreal projects. Comments are welcome.

Lilguy: Thanks! Subversion rocks, everyone should use it.

TSOShadow: I like what you all have done here. It really explains communication and file intergration well. Although I think I'll touch up the other issues as I got alittle lost in there...