Introduction

Mods are modifications to existing games. They can range in complexity from a simple model replacement, to a new level, to completely transforming the game into an entirely new game, re-using little-to-no content or code. Mods are created by students and hobbyists with an interest in game design and game development. Modifications rarely turn into successful commercial ventures, and often that's not the goal of the project. Some of the rare instances of successful commerical mods include Day Of Defeat, Counter-Strike and Red Orchestra.

Mods are becoming an ever increasingly important factor in the games industry today and bring many benefits to the industry. For a game, mods can extend the lifetime and dramatically increase sales. Mods also benefit the game development industry by helping to train current and future game development professionals. By working on a mod a person can vastly increase their skill, and get exposure to industry level technology. Many people use mods to gain experience with industry technology and use as a demo reel to potential employers.

Motivating factors behind mods are not financial incentives but the passion and commitment of the team members who give up their afternoons, nights and weekends to produce a high quality realisation of their vision.

Due to the nature of mod development there are many significant challenges that plague mod teams, and strong leadership is essential to successfully producing a mod. Without strong leadership it's very easy for the team members to divert from the original vision and lose cohesion on the project. Strong leadership helps maintain this cohesive vision, as well as keep members motivated, aiming for common goals, and above all communicating.

This article will describe some of the problems faced by mod authors, some of the solutions used during the development of Hostile Takeover 2050 and some points for improvement.

Team Structure

The team structure is an important item to consider. The team structure will influence member retention, how well people perform, and even milestone planning. A poor team structure can lead to communication issues, conflict and poor time frame estimation. It's important to keep the team organised, and have well defined roles in the team, so everyone knows their place and how to raise issues.

The team structure we adopted in Hostile Takeover 2050 was that each "team" had a lead. We had a lead for map/prop creation, programming, characters, and sound. Some of our teams ended up only being one man teams due to troubles with recruiting. However the multi-person teams worked effectively through this method. It meant that communication was segmented appropriately between teams, but there was still good cross communication and co-operation between the teams. It also made the role of Project Coordinator much easier as the number of people to liaise with was much lower. It's important to note that the person who was team lead was not always the first person to join that team. The lead had to be a good communicator, committed to the project, and online fairly consistently. People that go dark don't really suit this role. The lead also needed to have a solid understanding of what they and the team were working on so proper planning could take place.

On top of this we also had a Project Coordinator. This person liaised with all the leads to plan milestones, keep communication happening between teams and keep track of the whole project. This also ended up involving PR, web administration, release packaging and recruiting.

Recruiting Team Members

Potential new team members want to see what has been done on the project and know what the project is about. Committing to such a project is a daunting prospect, so the more information the potential member has about the mod, the easier and the more informed the decision will be, so make sure you have plenty of information available about your mod.

When trying to recruit, the first stop should be the usual channels in which people in the modding community for your chosen engine/game congregate. The IRC channels, forums, mailing lists etc. Another thing to try is finding some non-engine specific forums where people interested in the same kind of work (modelling or sound engineering for example) congregate. Be sure to check back regularly when posts are made, as we lost a few potential recruits by members forgetting to check where they posted until a few weeks later.

When considering new team members there are a few things to take into account. Age is often used too quickly to dismiss team members, however on Hostile Takeover we found it was a poor indicator of performance and commitment. Some of our oldest and youngest members were our best performers and the most professional acting.

Also take into account, but do not dismiss based upon, the native language of the potential new member. Some will turn out to be very competent communicators and many will be very talented, producing great work. You may also find that another team member can speak that person's language as well as yours in a fluent-enough manner to facilitate communication.

A few potential recruits for Hostile Takeover were from Turkey, and also around Europe. While we had no problems with this, and were quite excited with the previous work of these members, we found that the communication of ideas and working conditions was hard to translate. One recruit pulled out after doing a little bit of work as they didn't understand it was a volunteer project and was expecting payment. We only dealt with non-native english speakers on a few occasions, and often the agreement fell through due to communication issues. It is important to remember that communication is a very critical factor in mod development, and this is more complex than in an office environment due to time zones affecting real time communication.

Consider also the timezone of the potential recruit as this can make meetings a nightmare to organise, or affect communication in a bad way.

You should also clarify a few things up front with potential new members, such as whether it's a paid position or not, and what the copyright on all work will be. This might mean that it is author-retained copyright with a permanent irrevocable license to the mod, or whether copyright is assigned to the mod team. By discussing these things up front everyone has the same understanding and expectations and it can help avoid conflicts later on.

Communication - The Backbone of a Mod Team

Communication is vital to the success of a mod. If team members aren't effectively communicating it can lead to inconsistencies in work and directions. Issues with communication can also lead to rifts in the team as members start to get frustrated when dealing with each other. These are issues that must be dealt with swiftly, or avoided entirely.

Common communication channels must be set and mandated early to provide trouble-free communication. Many different communication methods must be available to team members so that the methods themselves never get in the way. For instance when a member has a small clarification question that can be answered in 30 seconds, the procedure shouldn't be to create a forum thread and wait for the person who can answer it to check the forum and answer which could be 24 hours or longer. A more appropriate method would be ensuring everyone has a common instant messaging program.

Ideally communications should be logged when possible so they can be revisited at a later time for clarification. This isn't always possible or practical, for instance with VoIP, so there should be a procedure in place to allow most of the contents of the important discussions to be captured. For every scheduled meeting, a person should be nominated as a note taker, and minutes should be published in a central location (forum, wiki, etc.).

When a member goes "dark", it means they have just dropped off the radar, they aren't giving status updates and are hard to contact. This may mean they are just dealing with issues for a while and will come back when they can, or it could mean the member has dropped off the project for good. Make it clear you'd like members to check in regularly even if they are dealing with issues, just fire off an email once a week or before they disappear for a period, just to let the team know what's going on. This makes it easier for the rest of the team to deal with any issues during that time, for instance the team can re-prioritise other work to cover an important section the missing member was working on

Scheduled meetings provide an effective way of keeping members motivated and keeping communication active. Scheduling a meeting once a week allows all members to see every other members progress, which in turn inspires them, and reduces how often people go dark. It is alright to vary the frequency of these meetings every so often. During Hostile Takeover's development cycle we varied it a few times to according to what was happening with development. As deadlines approached frequency was increased to twice a week, over the Christmas period our team would cancel all meetings for a month, and during times when everyone was busy frequency was reduced to once every 2 weeks. I can't think of many things that are less fun than turning up to meetings twice a week with zero progress to speak of.

When organising meetings you may find, due to the locations of all members, that choosing a time for the meeting can be difficult. This shouldn't discourage you from trying to meet often. We found the meetings were very useful for keeping the team up to date and on track and many members were willing to get up early or stay up late to attend meetings.

In the early days of Hostile Takeover, a few members went dark at the same time for a period of several weeks. After several attempts to contact them we found out what was going on, they were all studying hard for upcoming university assignments and exams. This helped us realise that we needed to identify possible times when members were likely to go dark. From then on we always asked members to let us know of upcoming situations, and kept track of university semesters regardless of status updates so we could plan work and communication with the possibility of periods where members would go dark.

One thing to try and avoid also is different teams not communicating enough and causing conflicts. For instance we noticed the art team got frustrated with the code team on a few occasions because there was no visible work being done. This issue arose from the teams not understanding each other's disciplines and not enough communication was happening to show that the programmers were still hard at work.

The communication methods used on Hostile Takeover 2050 are documented below. These were not the only communication channels, some members spoke to each other through other means, but these were the ones required so the team had a variety of standard contact mediums.

HT 2050 Communication Guidelines and Rules

Wiki

This was used as the main document manager for things like the game design document, and also for procedures, such as how to install or use certain features. This enabled members to work effectively on their own, not requiring the person focused on a particular aspect of the mod to be present to aid other members. This had the other benefit of allowing the authoring member time to work on their assigned work instead of answering the same questions for all team members. More specific details on the wiki and documentation will be discussed later.

Skype IM

Skype was used as an instant messenger because it allowed a group chat to be created and have all members view all conversation that happened, regardless of whether they were online at the time or not. This allowed for team wide conversations to happen regularly, and provided a convenient and logged communication channel.

Members could also branch off into private conversations through text or voice really easily through this.

Ventrilo

Group voice conversations were held through Ventrilo because voice communication is significantly faster paced than text based communication, and it allowed conversations to happen during play testing. For all Ventrilo conversations a note taker was appointed and that note taker would then post the minutes to the forum. We would have posted this on the wiki, however the wiki was not used until later in the project. This allowed conversations to be acknowledged and decisions to be documented without having to record the conversation and also allowed it to be search-able.

Ventrilo was used instead of Skype due to issues with Skype not scaling particularly well past ~3-4 users, drop-outs were noticed, and Ventrilo allowed push-to-talk.

Forums

When conversations were not time critical, but a structured conversation was required, we used forums to facilitate this. Forums allowed pictures to be embedded to show a concept or work-in-progress.

Email

Emails were exchanged in case a member went dark. However, emails were rarely used as they didn't provide any benefit over our other communication mediums, and members didn't go dark too often, and when they did, they didn't really return or reply to emails.

Mobiles/SMS

Mobile phone numbers were also exchanged for emergency reasons, this primarily worked due to most members being based in Australia, which meant communication wasn't expensive. Due to this, members could be SMS'd if they were required at a meeting. This became less effective when members from other countries were involved, however fellow members in the same country would often exchange numbers too which opened an avenue if there was another member online in the same country.

Documentation

Documentation is another critical factor in creating a mod. Poor documentation means the mod is at risk of losing a significant amount time re-working content and procedures when a member leaves, or goes dark. Clear documentation also aids in having a cohesive vision for the game.

It's important that there are procedures in place so all important processes are documented. This includes the development environment setup, how to build the mod, how to package the mod into an installer, etc. The procedures don't need to be written in legalese as if you were sending them to a client on a multi-billion dollar deal, they just need to be complete and clear. Adding plenty of screenshots can help vastly in making the instructions easy to understand.

The procedures should be set out early so the documentation is created as the mod progresses. If you start the documentation process too late you'll have a lot of documentation to write in one big chunk. If the procedure is in place early it will also provide the most benefit to the team as the documentation will be there for when new members come on board.

With Hostile Takeover, we set up our wiki later in the production of the mod after trialing several methods of keeping documents. Unfortunately because the other methods didn't work out too well, our documentation was lacking in the early days. As opposed to spending days and weeks purely on documentation we took the path of creating the documentation as a situation occurred that made the documentation process easy and/or would provide a benefit. For instance, we wrote the development environment setup document as a new member was about to come on board.

Documentation doesn't only apply to the technical aspects of how features work, documentation also includes details on servers that are used for testing, communication, as well as documentation on game design and inspiration.

Managing Game Design

Game Design Document

The game design document is THE single most important document on a mod. This document should describe the current game completely, listing all features and an explanation of each feature. It should also clearly convey the pacing and feel of the game.

Initial Development

The game design should be in development long before actual development work takes place. You need a setting and a rough idea of the style of game you want to create. As you start to flesh this idea out you should write down every feature and idea that gets suggested. Brainstorm regularly. Start discussing how the game should play out.

During this stage of the game concept development we wrote a short recount from the perspective of the character to give a good mental picture of the game. If you decide to write a short story like this, remember, it doesn't have to be long, just enough to identify the desired feel and pacing of the game. Strive to use some colourful language in this story so you can create a very vivid mental picture. Here is a snippet from ours:

The team fans out, some of the infiltrators hear guards approaching. Their footsteps are very loud on the linoleum floor. Someone yells out "Stealth" over the intercomm. Each of the team finds various corners and engage their stealth suits, the guards wander in and spy the dissolved window. You just know they are radioing this in to their comrades. They quickly stand back to back and scan looking for a stealthed charater. You know it's only a matter of time before they spot one of the distorted images. Several guys start firing their guns in tranquiliser mode. They aim at the guards legs, 4-5 shots hit the guards simultaneously, they don't even have time to get dizzy, they go down like a sack of potatoes.

After you have a detailed picture of the feel you want from the game, and a lot of good ideas written down, it is time to start looking at each idea closely, identifying what needs more thought, and also what doesn't fit or is too complex for the initial version.

Culling Features

When culling features you need to look at several factors for each feature: How long will it take to implement? Does the feature fit the rest of the game? Will removing this feature significantly alter the desired game play? Does the engine have the capabilities to support this feature? Does the team have the skill or enough developers to implement this feature?

For many features it will be a difficult balancing act to decide whether or not to include the feature. Some features might be a nice addition to the game, however the extra time needed for this feature may drag out the project too long, or be above the engine or team's capabilities. Keep in mind that while the development time of a feature is less important on a mod than on an industry project it is still a big issue and must be taken into consideration as it will affect developer motivation, dictate how many developers are required on the mod, and impact the timeline of the project.

As you cull ideas don't just delete them, add them to another section of your game design document called "Version 2" or something. This way as you approach the finish line for the game you have have a few ideas saved up in case you want to take it further, or create a sequel. This can also come in handy during the development of the game if you feel it's shaping up to be a little unbalanced. You can always reference back to this section for some extra ideas to balance out one side or skill.

Evolving Design

Once you have a solid game design document you can start developing the game in earnest. It's a good idea to try and get a game prototype up as early as possible so you can see how the game plays out. Not all features or rules need to be implemented for this. Amongst the development team you can play with the "honour system". In this you have a play test with the game as-is, and play the game according to the rules even if not implemented, such as don't use a level 2 gun if you shouldn't have access to it. This allows you to get an early indicator of how the game will play out allowing you to relax rules, decide on new features or change weapon attributes earlier. Don't get too caught up in playing with fine tuned values too early on, rough enough is good enough, because as development progresses and design changes are made, these values will inevitably need to change as well.

Once you've had a few play tests your game design will show what is working, what isn't, and what needs a bit of adjustment. Don't be afraid to change the game design, just be mindful of the impact of every change to the time frame, the resources required and the game itself. Be sure to update the game design document to reflect every change.

Organising and Sharing Content

How you are going to deal with large amounts of content among many developers is also something you'll need to get sorted very early on in the project. Modern mods will be dealing with data easily in the range of several gigabytes. A lot of this data will be constantly changing, changed by many developers, and required by all of the developers. It's important to have a very clear structure worked out for organising all of the data, as well as having clear processes on how to update data while avoiding conflicts with other developers trying to edit the same file.

The solution we decided upon wasn't perfect, however it allowed us to develop relatively hassle free without spending a fortune on software, hosting or bandwidth. We used a privately hosted Subversion server for all code files. Version control software was a lot easier to work for the programming side than it was for the art side. This didn't use much bandwidth at all.

For our art content we ended up just using a shared hosting service which provided plenty of bandwidth and storage space without costing a fortune. We used this for our public and development forums, our website and also the main usage was the FTP side for content management. Due to the unreliable reputation of cheap shared hosting solutions we made sure we had regular backups of the FTP, however we never ran into an issue. If you do follow this method, make sure you do take care with backups.

To help avoid change conflicts we had 2 directories for each type of content, an In and Out folder. When a developer was working on a file they would move it to the Out directory and would put their name in the file name. When the developer was done with the file they would re-upload it to the In directory and delete the file from the Out directory. This allowed other developers to know that changes were being made to it and who they could contact to discuss the work they needed to do.

We had scripts which would auto-download any changed files and would extract them to the appropriate places. To avoid issues and conflicts the scripts could have certain portions disabled. This prevented instances of two developers working on a file, and when one uploaded it automatically wiping the other developers changes. While this wouldn't have been an ideal circumstance anyway, it was something we didn't want to ignore as work could be exported and re-imported into the correct file.

While version control would have been nice for the art content, we never found a solution which would have worked for us. Hosting costs or software costs were prohibitive for a volunteer project. However the potential issues never arose for us as the art developers would keep regularly dated copies of their work so we were always able to revert when required.

It's important to plan some time for the team to develop some custom tools and scripts to aid in a lot of this work. Whether it be installers, build scripts, auto updaters, or anything else. This also involves getting the team to follow strict processes on things like content directory layouts. The time spent developing these tools and processes greatly reduces the time lost later when everyone is trying to sync up for a test game, or when a developer accidently corrupts their environment. Even when building the final release, having a tested script that builds the game and packages it into an installer ensures that no steps are missed and a solid release is ready for upload.

Planning Deadlines

Setting deadlines on a mod is both important and difficult. Setting deadlines gives you a method to help inspire and motivate team members, and allows you to plan community advertisement. When planning milestones and deadlines it's important to speak with the heads of each "team" or "department". These members will be in the best position to give correct advice on realistic time frames, and status updates for their progress.

Don't attempt to use deadlines to rush development. We tried this in Hostile Takeover 2050, and found it didn't really work. The team enjoyed the sound the deadlines made as they whizzed past. We found deadlines were most useful to keep the team on track and motivated. Realise the project is still going to take a significant amount of time. You must remember all members are volunteers with a life outside of the mod.

When unexpected set backs happen, such as a member going dark, just power through and ask other members to step up and try and cover the position that's down. Hopefully your team will have a few standout members who will help cover the position. With well planned deadlines and some helpful standout members, you shouldn't fall behind much, if at all.

Preparing for Releases

When planning your release, try and plan to have work wrapped up several weeks before the release date so you have time to play test, and correct any unforeseen bugs and exploits. Don't underestimate the work involved in releasing either. Here are a few things to remember to schedule time for which can be too easily overlooked when developing:

• Developing and testing an installer
• Icon Art
• User Guides
• Release Page
• Organising Download Mirrors
• Splash Screen Art

After you have wrapped up work, play test like crazy. Schedule regular games with team members. Recruit some people from outside the team to help as well. Play dirty. See if it plays well and doesn't have any issues with dirty play such as spawn camping. Also any members you bring in from outside the team should be watched like a hawk. See where your documentation and help systems are failing. Identify if things need to be explained clearer or if an interface is awkward.

After you have released you should make sure members have plenty of time set aside for community interaction, watching message boards, replying to comments, watching for bug reports etc. This constant activity can be helpful in growing the community. We found scheduling a few games against the developers was helpful in regards to getting players onto the servers at the same times. We watched a lot of players log onto the server, get bored waiting and logging off 2 minutes before another person did the same thing.

Managing Community

Throughout the development of the mod you'll need to keep up the PR/Marketing efforts. As development progresses keep looking for some interesting areas where you can get a video or a screenshot that you can show to the community. Even keeping a trickle of screenshots coming out can help to keep traffic coming through on a site like ModDB.com. Before release you want to ensure you have had a lot of eyes look over your mod so when you release there is plenty of interest.

Another good thing to do is to look at some of the challenges you face each month and write a blog post about it. Write about some technical challenges, and how you got around it. Whether this be on the coding side, or on the mapping side. This is good for a few reasons: It shows the community that development is still progressing, it shows off the technical skills of the team (which is good in inspiring confidence in the quality of the mod, and for portfolios), and it gives back to the modding community that exists around that engine. Also write about some design challenges you have had to overcome, this can show the community more information about the game and give them more insight which will help build interest. We didn't do this as regularly as we should have in Hostile Takeover 2050, however when we did, we saw big spikes in traffic and interest in our mod.

Another mistake we made in Hostile Takeover 2050 was hoarding information up front, and not releasing anything early. We did this out of fear of the idea being stolen, which in a modding environment is not something you have to worry about. Everyone has their own ideas which they would much prefer to work on, and it's not going to be stolen and exploited commercially until it's been a proven success, at which point you will already have the market and the interest in your IP and team. This harmed our team greatly because we found it hard to recruit members as people weren't interested in our mod with nothing to show, and by the time we did release information everyone was already in teams and engaged in projects, which was exacerbated by the Make Something Unreal Competition.

This differs substantially from the industry as trade secrets don't come into play when the communities are so open, and marketing is an entirely different ball game.

Conclusion

Managing a mod team is a very complex and challenging task. Most issues can be avoided or minimised with adequate planning and thought. Take time initially to plan how you are going to develop the mod, don't rush into development. Also constantly keep a look out for any issues that arise which could be solved with a few rules, such as a change in documentation requirements, or a new communication channel everyone should have.

Hopefully by sharing some of the lessons we learned while developing Hostile Takeover 2050 you can avoid making some similar mistakes or at least have some guidance during your own projects. We all enjoyed working on Hostile Takeover 2050 and have gained a great deal of knowledge, both in the technical aspects and in management.

If you have any questions or comments please feel free to email me at philip@gdcorner.com or comment on the article below.