Making Mods/Building A Team

Building a Team

So you have a truly classic idea for a mod, and you've read the Mychaeel/Mod Startups and Mychaeel/Modding Etiquette pages so you know how to avoid some of the obvious pitfalls. You now need a team to help you bring your stunning mod concept to life.

Do you really need a team

The very first thing you must do is challenge the idea that you need a team at all. Is the mod big enough to warrant building a team to do it? You might not have all of the skills necessary to bring the mod to life, but, you may not need a full time team to work on it. You may also be able to acquire the skills you need to create your own mod. Making small mods with other people is hard. It's easy to get to a point where the "maintenance of the team" becomes more of a burden than the help the team itself provides.

Consider a weapon mod.

I'm a coder at heart, writing software is where I get my kicks. In order to do a proper weapon mod I'd need a set of models and skins for the weapon, ammo packs, and bullet effects. I've never tried modelling anything with a proper 3D package – I'd much prefer to type the vertice and facet definitions in by hand. My texturing skills are so poor that they deserve warning stickers.

However, do I really want or need to build a team of modellers and skinners around me before I start my mod? The answer is not at all. I'd start by writing the code for the weapon using one of the standard game models. I might attempt to sketch my idea for the weapon in Corel Draw or Photopaint - or even on paper. Once I'm at least semi-happy with the code I might start up my favourite (ie. the one I have installed) modelling package and see how far I can get. Alternatively, I could post on one of the many forums a request for help. I could then finish off the mod without ever having built a team to do it.

Balance is important

If you are convinced that your mod is big enough to warrant a team of people working on it full time then you need to consider how many people capable of each discipline (modelling, coding, skinning etc) you need. Having multi-skilled team members is extremely useful as they can have areas of overlapping responsibility.

Don't fill your team with modellers when your mod only needs three models. This applies equally to the other elements of your mod. In the case of the modellers, one modeller will do most of the work and the other two will get frustrated, fed up, and then leave, because they have nothing to do. Before they leave though they will be unconciously (or maybe conciously) spreading disastisfaction with the team and mod. This is bad for morale and will hurt productivity.

Probably the hardest area to accurately recruit for is your coding. Splitting code up is difficult unless you have a reasonable idea of how everything fits together. The best approach to use is to recruit a single coder and make them responsible for the overal design and structure of the code. Only bring in another coder if they can see some easy way to partition the development responsibilities, or, if they start to get swamped.

It's better to have a small team and take longer to finish the mod than it is to have a big team and risk never finishing anything. As the size of the mod team increases, the amount of time spent communicating within the team increases exponentially. The more time that is spent in communication, the less time is spent actually doing any work on the mod.

I have seen two teams of 4 people deliver a project in 6 months that a single team of just over 100 couldn't deliver in a year. So having a large team can be a good way of assuring failure rather than success. It's more important to have a large team testing the mod than it is a large team building it.

Make Responsibilities Clear

Make sure that everyone in the team knows not only what they are responsible for delivering, but also what everyone else is responsible for as well. In most cases this split of responsibility is easy to define. Where this split of responsibility is difficult to define spend some time thinking about it rather than just ignoring the issue. It will save you some pain later on down the line. Don't worry if your initial split of work and responsibility seems unbalanced, having one person picking up more work than an another. Clarity is what is important here.

Review the responsibilities or each team member regularly. You may find that your original split of work can be further refined to balance the work out between the team members. You will find that this needs to be done anyway as real life and other unexpected events kick in and impact on your project team.

If you can specify internal delivery dates for the components of your mod all the better. This helps you keep track of where you are up to. Remember though, any dates specified are simply working values. They can and will move both forwards and backwards. Being able to check delivery dates against components can be a good indicator of whether one member of the team is swamped with work, or simply needs a break.

Know When to Stop

At the point the team starts the mod you should have stated clearly and concisely exactly when the mod is finished. If the mod's final state is left as a vague description then you risk catching "When It's Done" syndrome. Knowing when the mod is finished is as important as starting it in the first place. The clearer the specification of the mod the better your position is going to be.

Make sure everyone in the team understands and agrees with what constitutes the finished mod. The team members will almost certainly want to add features of their own, so be prepared for that. Just make sure that you agree from the outset which features will make it into the current version.