Hello. My name is Josh Sawyer. I am a game developer, formerly of Black Isle Studios, currently working for Midway San Diego. I’m not necessarily an expert on the game development process, but I have worked with quite a few producers and had the opportunity to see many different styles of project management and mismanagement. I see a lot of ambitious people set out to make mods, 90%+ of which are never completed. I don’t think it’s because the ideas aren’t sound or because the people involved are a bunch of idiots. I think it’s because the projects are a) poorly planned B) poorly scheduled and c) poorly managed in general.

It’s not common for projects to be successful in spite of mismanagement. You can certainly develop a game or mod without tight management, but you might as well wish, click your heels together, and hope that things will come together. Management takes time and is neither fun nor glamorous, but it is of vital importance to the success of a team endeavor. I’d like to suggest a process and some general tips on how to organize a mod project. These suggestions aren’t necessarily the best in the world. You may even think they are bad ideas, but they seem to work from my perspective. These suggestions assume that you, the initiator of the mod-making process, are the team leader/producer/god emperor. Don’t get too caught up on titles; only ego-tripping retards really give a damn anyway. If you’re the one coordinating things and getting the ball rolling, this post’s for you.

Before I begin with a phase breakdown, I’d like to suggest some general stuff:

• Set up a web forum, IRC channel, mailing list, bug database and FTP site for your mod. There are a lot of free web forums. http://www.ezboard.com/ is a decent one. Finding an IRC server to host your random channel isn’t necessarily that difficult, but may take time and require jumping through hoops. However, real-time discussion on a weekly basis is pretty important for team communication, camaraderie, and general cohesion. Mailing lists are a good way to prick the ears of people who may not read the boards every day or who were effectively put on a waiting list to joint the mod team. Just don’t abuse it. http://www.bugzilla.org/ is a pretty damned good open license bug tracking software package. The FTP site may be hard to swing for some people, but it’s really useful for organizing assets. Just give uploading privileges to people, organize the folder structure as you see fit, and it will make things much easier for everyone.
• Don’t let people (or the entire team) drift. Keep people focused on the tasks at hand. A lot of people who volunteer for a mod just want to do the high-level fun stuff. A lot of the stuff in game development is not fun. However, if you can keep people focused on the milestone tasks (even the un-fun ones), the milestone build should show enough progress to really get people pumped. Un-fun tasks are rewarding when the payoff exceeds the drudgery.
• If possible, use something like http://www.wikimedia.org for your master documents. Always keep backups of the source files, but it is best if the entire team has access to one version of documents. It helps prevent confusion when changes are made. Of course, always inform your team members when documents have changed, and let them know what has changed and where they can see what has changed.

VISION PHASE (team lead)

• Establish what you are trying to accomplish with your mod. Are you simply trying to create a set of new levels? Are you going to change the HUD? Are you going to add new weapons? Are you going to add new character models to the game with new animations? Cover breadth and depth. How many new levels? How many new monsters?
• Justify why anyone should give a **** about what you’re doing. Why is this fun? If you want to make a mod because you personally think it’s fun, despite its narrow appeal, that’s fine. However, it’s easier to get people (including potential team members) excited about what you’re doing when you can quickly and clearly tell them why what you’re doing is going to be fun and exciting.
• When you have determined what you want to do and why it will be fun, write it down in clear, concise terms for dissemination to people who may want to work on your mod. You really do not want to bring people on board only to have them leave halfway through the project because they misunderstood what the team/you was/were trying to accomplish. Keep everyone focused on your goals from the beginning, and remind yourself of them through the project.
• Given the scope of your mod, make a rough estimate of how many team members you will need. At this stage, you are guessing, because you will not have a good idea of what is involved with every task. However, you should be able to estimate certain things. E.g., if your goal is to make new levels and use existing tools to modify things, you probably will not touch code and will not need programmers. However, you will need level designers to lay out maps and 2D artists to create textures. Break down your needs into four sub-team disciplines: design, art, programming, and audio.
• For every discipline you will be staffing, try to find one really good team member. Do not try to staff the entire team immediately. As the project director, you have a good idea of the vision, but you may be abysmal at analyzing the details of implementing that vision. Before you throw 4-8 “artists” at a mod, you need a level-headed, informed analysis of your art needs. Find one good artist first. Find one good programmer if you need one. And hey, if one is all you need, that’s great. If a deluge of people volunteer, thank them for their submission, but tell them that it will be a short while before you fully staff up. Keep in contact with them throughout pre-production so they don’t drift away. PROTIP: You may find people who would like to help you, are super bitchin’, but just don’t have the time. Consider politely asking them for their help in analyzing other applicants, particularly if you don’t know enough about the discipline to separate the wheat from the chaff. Now that you have a core team, it’s time for pre-production.

PRE-PRODUCTION (team lead and core team)

• Once you have established your core team, disseminate your vision document for analysis. The goal is for the core team to seriously analyze the scope of the project and break it down into realistic lists of tasks. THE ESTABLISHMENT OF A TASK LIST IS OF VITAL IMPORTANCE TO THE SUCCESSFUL MANAGEMENT OF YOUR PROJECT. Remember, for everything you want to accomplish, someone has to make it happen. Things don’t magically get done. Even the smallest tasks should be listed (within reason of course -- just try to be thorough). Accompanying the task lists should be asset lists. An asset is any object (usually an art object, but possibly a table file or other bit of data) that needs to be created for use in the game. E.g.: One of the tasks is the creation of Monster X. Implicit in the creation of Monster X are the creation of Monster X’s data (in code or through an editor), its model, its textures, its skeleton, and its animations. When you schedule these tasks out, you may group them in the task list for simplicity (i.e.: Monster X’s animations), but be sure to actually list all of those assets out in a team-available list somewhere. If you don’t list it, you might as well assume that it is not going to be created.
• Create master documents for each discipline. These documents will effectively be the blueprints and guides for how your mod is completed. They will be referenced by other members of the core team and by the larger team during the production phase. The master documents should explain how each set of tasks will be completed and should list specifications for assets and processes where needed. If programmers will need a certain compiler or a set of libraries, make that perfectly clear. If the textures for level geometry need to all be power of two sizes, 4-bit, no larger than 512x512, .tga format, and come in under 2 megs on one load, it would be wise to list that out. The organization of these documents can be discussed by the core team, but the format should be decided by the team leader.
• Organize your task list. Remove redundant entries. Promote communication between team members to recognize dependencies and risks. You may find that some of the core team members condemn an element of the vision as impossible or extremely high risk. If the team comes to a consensus on this, seriously consider revising the vision and scope of the project. Anything that is “risky” is something that should be implemented and tested as early as possible. This is particularly important if it’s an element of game play that could make or break the project. If you have a strange new mechanic or weapon that may drastically alter game play, implement it early and test it. If the whole project rests on that “new thing” and it sucks, there’s no point to continuing forward with the vision as written. Dependencies between tasks (e.g., you need this editor support before you can make this feature work) should be clearly noted for later integration into the schedule. All dependencies should be completed prior to the tasks that need them. I know it seems logical, but you’d be surprised how many people don’t “get it”.
• Estimate the time required for each task. Yes, every single goddamned task. The smallest unit of time should be about an hour. These don’t have to be hyper-precise estimations, but they should be realistic. If you’re uncertain on a set of tasks, pad them a little. It’s almost always better to estimate a task will take more time than less time. If the task comes in under the estimation, hot damn, you’re momentarily ahead of schedule.
• Summarize the work-hour totals for each discipline, possibly organized by sub-discipline (animation or modeling, for instance). This will give you a good idea of your staffing needs. If you have 38 hours of programming tasks, one programmer working 5 hours a week for 8 weeks should hit the goal. If you have 180 hours of art tasks, one artist working 3 hours a week isn’t going to be done in the same year as the programmer, so that may throw a wrench in your plans for a three month dev cycle.
• Keeping dependencies in mind, start to organize the task list into a schedule. Give emphasis to high-risk items and coordinate them towards a pre-production milestone date. Also, if you have a multi-step pipeline/process for getting assets into the game, test them. A convoluted pipeline can spell disaster for a project. This pre-production milestone will serve as a proof of concept and of the team’s capabilities. If you can successfully complete the riskiest elements of the project in a timely fashion, completing the other elements should be easier, even with a larger (more difficult to manage) team. As you schedule these things, get realistic estimations from the team members on how many hours they can put in per week. Really, please, keep in mind that you’re working on a mod, and that people may have real lives and real jobs to attend to. End the implementation phase of your milestone about a work-week ahead of the actual milestone date. Leave the last week for tweaking and bug-fixing. Be firm about this. DO NOT let features get implemented after your one-week cutoff. A stable, playable build should be the goal. Quality, not quantity.
• If the schedule falls short in one discipline (e.g., it will take two weeks to do everything in pre-production but the animation, which will take eight weeks), either staff up or move the pre-production milestone date to something more realistic. Realize that it will take time to find new team members and get them up to speed, so schedule “their” tasks accordingly; do not schedule a non-existent team member with tasks the day that you realize you’re coming up short.
• Coordinate the new team members with the core so that the growing group is still all on the same page. Have them read through the master documents and take their feedback, when appropriate.
• Begin work on the pre-production milestone. Have all team members report daily on their progress. If a team member does not report, assume they accomplished nothing. Track progress realistically. If you see people slipping on dates, discuss the issues with them and try to adapt your schedule appropriately. Do not wait until the end of the milestone to take action. By that time, it’s too late to fix the problem. SLIPPING IN GAME DEVELOPMENT OCCURS BECAUSE PEOPLE DO NOT REALIZE OR DO NOT TAKE ACTION WHEN SCHEDULED TASKS SLIP. If necessary, re-assign tasks from a “slipping” team member to a team member who is ahead of schedule (or willing to do more work), or replace the team member. Mod workers are notorious for being all talk, no action. They will not be penalized for failing to do their volunteer work. Don’t bother trying to lay a guilt trip on them; if they aren’t enthusiastic enough to make time for it, get them off the team. It’s as simple as that.
• Continually keep the entire team informed (passively in web form and actively in a weekly e-mail update) of the every member’s progress on the milestone. Not only do the go-getters help motivate the other team members (“Hey, we actually did something!”), but the team will be acutely aware if any of their dependencies slip. Don’t just list dates, percentages of completion, and task names. Write up a brief overview of what got done, what didn’t, and what that means, overall.
• Near the end of the milestone, at a pre-scheduled date, have a team analysis of where the milestone stands and what needs to be done to make it happen “for reals”. Some tasks may not be attainable. Note that and discuss that in the pre-production post-mortem. For everything else, make realistic and appropriate modifications to the schedule. If one animation will be missing, maybe convincing the animator to work a little extra in the last week isn’t unreasonable. Crunch itself isn’t bad. No schedule is perfect. Crunch is bad when it is continuous because there is no realistic, monitored schedule.
• Create a build with the pre-production milestone assets (code, art, dialogues, etc.). Review it and disseminate it to team members. With them, carry out a post-mortem to analyze what went wrong, what went right, and what that means for the upcoming milestones and tasks. Actively draw opinions out of the team members on what they felt went right and wrong. Some people don’t volunteer opinions, even if they are of vital importance.
• If your pre-production milestone was not an abysmal failure, move on to production.

PRODUCTION (full team)

• Re-evaluate the task lists and break them down into milestones, similar to the pre-production milestone. Each milestone should have something to show. For amateur mods, it doesn’t necessarily matter if the milestones are two weeks long, a month long, or three months long. What’s important is that a significant volume of overall work is accomplished that takes the milestone build to a significantly higher level than the previous milestone.
• Address any risks that arose during pre-production. Change the scope of the project, begin looking for new team members, etc. Schedules and master documents are not carved in stone. They are living documents, and should be treated as such.
• As new team members come on, bring them up to speed, help them feel like they are part of the community, and work, work, work that schedule. Pay attention to it. Change it. Bring slippage to the attention of team members and act on it quickly.
• Complete the milestones, dummy. The hard part’s already been taken care of. I don’t care if you want to give the elf blue eyes or grey eyes, or if the rocket launcher should do 50 or 100 points of damage on a direct hit. You and the team can figure that out on your own. But if you don’t have an organized, scheduled approach to your project, it’s unlikely that any of those details are really going to matter.​