Making a Mod
This article is designed to help you make a modification (mod for short), for GoldSrc, Source, and Source 2. First, it has some advice on starting a mod and assembling a team. Next, a collection of helpful tips on figuring out the game design for your mod. Finally, it has a step-by-step guide on how to tie up the loose ends and finish your mod, which is actually the hardest part of development.
Starting out
Let's start by looking at how to assemble a team. The guiding rule here is to keep it small. Managing a team of people is a full-time job, even when the entire team resides in the same building. If you're dealing with an online team, you can easily spend all your time managing it, which means you won't have time to actually make your mod. Adding more people to the team doesn't mean more work will get done. The more people you have, the more time is spent managing them. Team Fortress's core team was three people. Counter-Strike's core team was just one person.
When looking for team members, try to recruit only people you absolutely cannot survive without. Your first instinct might be to bring on anyone who can code, model, or make maps. But for your first version, you probably won't need more than one person for each area of your mod (code, sound, models, and maps). You may not even need any new assets at all. Don't hire anyone until you've seen examples of their work. Make sure they've actually finished projects. If they're a modeler who's created 20 models that are all half-finished, you don't want them on your team.
Mod design
As a mod author, the most important question you can ask yourself is, "Why should someone play my mod?" It's a hard question to answer truthfully, but if you can nail it, you're on the right track. Think about existing mods and what they offer. Does your mod offer something new to the players? Is your core hook strong enough to entice players who are busy playing other mods? Even if you can't answer this question immediately, just thinking about it will benefit your project.
Compete with gameplay
You have a power commercial developers don't: you don't have to worry about the commercial viability of new gameplay styles. Commercial developers must worry about appealing to retail, breaking even, and other financial constraints, which is why most games are slight modifications of already proven gameplay. But you don't. You can try out truly new gameplay ideas that just might become the next big thing. This is your edge over commercial developers. Make your job easier by concentrating on this edge, and don't spend your time trying to compete in areas where commercial products excel. Most mods can't compete on a content level (maps, models, sounds, etc.) with commercial products—they have teams of artists with years of experience. Beat them with your gameplay. Players will play a mod that has very little new content but offers really fun gameplay. For instance, Team Fortress had almost no custom art for a year after its initial release.
Release soon, release often
You have another power over commercial developers: you can release much faster and more often than they can. We've summarized this mod development philosophy with the phrase, "Release soon, release often." Commercial developers work for two to three years, release their game, and hope to God people like it. You don't have to make that leap of faith. You can design your whole mod, write 25% of it, polish it to a playable state, then release it and begin getting feedback immediately. Then you can start adding the rest of your design piece by piece, while simultaneously incorporating player feedback into the first version, and continue releasing every month or two. You're in touch with your players at all times, so you'll never find yourself in a situation where you've spent a lot of time on something you're not sure your players will like. The trick is to cut your mod up into slices. The initial version needs to be fun and playable, but it doesn't need every cool feature you've thought of.
Be careful. "Release soon" doesn't mean releasing low-quality work; it just means developing your mod in small, polished increments. The first version of Counter-Strike didn't have half of the features it has now. The CS team released a high-quality but small mod. Since then, they've been regularly adding more features, and in response, their player base has continually grown.
Different is not always better
When thinking about your game design, don't fall into the trap of believing that "Different is Better." There's no reason to rewrite the shotgun code and create a new shotgun model if it doesn't impact your game in an interesting way. Keep in mind the first question, "Why should someone play my mod?" The answer, "My mod has a new combat system and a new movement system," isn't necessarily a good one. So, your combat system is different from Half-Life's. OK… but is it better? Does it make your mod more fun to play? Does a new movement system make the game more fun? Players are used to existing systems, and making them learn another one needs to be worth their while. So, before you think about changing something, make sure you know you're making it better and that it'll make your mod more fun. Don't be afraid to leave the rest the same as it was in Half-Life.
Realistic goals
Create realistic goals for yourself. Think about how long it takes a commercial developer to make an FPS with 10 weapons. If your mod is going to have 40 weapons, you're making life really hard for yourself. The key thing to keep in mind here is "Quality over Quantity." Players would far prefer to have 10 unique, well-balanced, and fun-to-use weapons than 40 unbalanced ones, some of which are just slightly tweaked versions of the others.
Don't be afraid to cut content and features. If the mod looks like it's never going to be finished, or if there's some content that you don't think meets the quality of the rest of the project, start cutting. During the development of Half-Life, at least 30% of the original features in the design were cut because it became obvious they were unattainable within our timeline, or because we decided they weren't worth the development time. As we said above, "Quality over Quantity." Players would prefer having three really good, well-playtested maps over 10 untested ones, and this will give your mod a reputation for quality content. Don't let the world see your worst work.
Understand the engine
You really should read the documentation included in the SDK. The most important thing you'll learn isn't whether you can do X with the engine, but rather how X should be done so it works well. You can make a gun that fires 50 rockets, but if you don't understand how the engine works, you might do it in a way that significantly increases your mod's network traffic. This is important for everyone on your team. If your mapmakers don't understand the engine, they'll make huge maps without thinking about how much network data will be sent to the players, and everyone will blame your code for being too unoptimized. If you're a developer, it's a good idea to explore the Valve Mailing List archives. You'll be able to read through discussions between modders and Valve employees. These archives contain useful solutions to common mod problems.
Finishing
We see a lot of mods that start out strong, produce a lot of great-looking content, and yet never quite make that final step of getting it into players' hands. This section will help you get into a release mode where you're driving towards producing a finished, stable version of your project.
We chose five weeks as a starting estimate of how long it'll take to get from normal development mode to a shippable version. It's likely you'll get better—and hence faster—at this with successive releases. If your mod is larger in scope, or if your team is substantially international, then it is likely to take longer, though the steps will be similar to the following. If possible, try to get the team to commit a few hours every day to the mod during this period. If some team members can't do that, you're probably better off removing them from the shipping process. Get them to hand their part over to someone else on the team who can put in the required effort. Shipping a product, even a small one, is hard and requires a substantial commitment.
There are many things in this section that might sound harsh or rigid. This is unfortunate, but it is a reflection of how hard this process is. The advice here is a summation of lessons learned from shipping many products, and most of it is the result of painful mistakes that set back our release dates. When you wonder whether a particular piece of advice here is necessary, remember that we once added weeks to our release date because we didn't take it.
This is also something that prospective employers are extremely interested in. It's one thing to see that a mod maker has produced a bunch of cool content; it's another thing entirely to see that they produced that content, actually shipped it, and people played it. The coolest assets in the world are useless if you can't go the last mile and ship them.
Fear not, as this gets a lot easier once you've been through it a couple of times. By the third or fourth release of your mod, you'll be an expert!
Five weeks out
Centralize ownership
You should designate a single member of your mod team as the Shipping Leader (SL). This person will drive progress on the mod for the next five weeks. From now on, any modifications should occur only at the request of the SL, and all such requests must be funneled through them. No team member should make any alterations, no matter how minor, to the mod unless the SL has explicitly authorized them. This doesn't mean the rest of the team is losing control of the mod; the SL is still a part of the team and will listen to all feedback. The point of the SL is to ensure that all changes go through a single person. This avoids problems such as a mapmaker breaking the game by making a last-minute change because he didn't realize something else had changed in the code. The SL will know the state of every component in the game (code, maps, models, textures, etc.) at all times throughout the next five weeks to ensure this never happens.
Choosing the SL isn't easy. Here are a few tips:
- Don't immediately assume the person who's currently running the mod is the best choice for SL—especially if the mod has been worked on for months and hasn't gotten any closer to being released.
- Programmers are probably the best choice. As the shipping process comes to an end, most fixes will be made in the code.
- The SL should be highly motivated, disciplined, organized, and as objective as possible. They will need to be able to commit five weeks of their life to this process.
- The SL should be able to make global decisions for the mod, understanding that this often requires cutting features and content in order to ship.
Establish a build process
You need to create a process for building your mod. Building is the method of taking all your work and producing an installable, working version of the project (generally as a standalone installer or archive). This should be done exclusively by the SL for the next five weeks, following a strict, repeatable procedure. This ensures you won't waste hours tracking down bugs that are simply a result of someone building the project differently.
The SL should maintain the final release candidate version of the mod from now on. All changes should be sent to them, and the SL should incorporate them into the master branch one by one, with a full understanding of their impact on all parts of the mod. Don't forget to back up your code and content regularly!
The SL should build the mod every day for playtests. More on that later.
Feature locking
Shipping is the process of locking down various components of your mod. "Locked" means that the asset or code is not to be touched from then on. Bugs found in locked areas should be evaluated carefully. Unless the bug is a critical showstopper, just note it down and fix it in a subsequent update. Regardless of the temptation to apply that one "easy fix", unlocking portions of your mod should be avoided as much as possible.
At this point in the shipping process, five weeks out, you should be feature-locked. This means you shouldn't be adding any new features to your mod whatsoever. If part of your team is not involved in shipping but wants to continue development, they should work in a separate repository or branch. Most source control packages allow for branching in this fashion (and yes, we strongly recommend using some form of version control). Every change made to the mod from now on should be a bug fix, and the SL must ensure this. Even if a coder thinks of another cool feature that takes only 10 minutes to code, do not let them add it. Even if they send the code, finished and bug-free, do not add it to the mod. Save it for the next version.
A healthy attitude for the SL to have is that every change to the mod from now on will add two days to the release date.
Playtesting
From now on, you should be running playtests every day—or every second day if that's too demanding. Playtests must be based exclusively on installable versions of the game built by the SL. Don't let team members play from their personal work directories. Everyone should be running a version of the mod installed from a build sent out by the SL, as this is exactly what your audience will be installing and using. You'll waste many hours tracking down bugs caused by incompatible versions if you don't do this.
To make this easier, the mod must be kept in a playable state at all times. Become extremely worried for every day the mod isn't playable. If a coder or mapmaker makes a change that breaks the build, think carefully before incorporating it into the SL's master copy. How long will the game remain unplayable? How many playtests will you miss? How many team members won't be able to work because the mod isn't running? Not breaking the mod should be a religion for the team.
When you playtest, make sure as many team members are playing as possible; everyone working on the game should test it regularly. Make sure you have external playtesters as well. Turn on server console logging by setting log on in the server.cfg file. This will dump all server output into a text file in the gamedir/logs directory, with the filename matching the date. Whenever any player spots a bug, have them use the in-game chat to say "BUG: description of bug." Then, when the game is over, you can open the log file and extract all reported issues simply by searching for the word "BUG."
Bugs and changes
The SL should maintain a complete list of all bugs and required tasks, along with their current status. Preferably, this should be done using some kind of dedicated issue tracker. E-mail is totally insufficient for tracking bugs; it's just too easy for items to drop off the first page of a user's mailbox. After each playtest, the bugs and necessary changes from the log file should be added to the list by the SL and assigned to team members. When a team member has fixed a bug or completed a task, they should submit the new content to the SL, who will verify the fix and update the status on the tracker.
The bug list is a fantastic tool for evaluating your progress. It can be used to identify who is overloaded with work, who is underutilized, who is not fixing their assigned bugs, and which area of your mod is farthest from completion. Don't remove anything from the list, even when it has been fixed (though you should mark it as fixed, of course). It's very useful to see which bugs have been fixed throughout the history of the project. A feature might regress, reintroducing a bug; knowing who fixed it last time makes it easy to ask them what caused it. At the end of the project, you should be able to see every bug fixed and every modification made during the entire shipping process. The SL shouldn't allow any fix or update into their master copy of the game unless the task has been detailed in the tracker.
There is dedicated software that will help you create and maintain a bug list. Alternatively, a spreadsheet will work just fine. Again, email is a bad choice.
Cut or defer broken features
The hardest, most painful, and unfortunately most necessary part of shipping is being realistic and cutting features. We have a saying at Valve that everyone will have their favorite feature cut from the game. While that isn't entirely true, it does help everyone prepare themselves for the reality that features they like—or spent a significant amount of time on—will be cut. Your game simply cannot have every cool feature and still ship within a reasonable time frame. The SL should make decisions about what to finish and what to cut, based on how far along in the release process you are.
The closer you get to release, the more you should think about each bug as you find it. Is the bug in a feature that absolutely must be in this version? How many days will it take to fix it? Can this feature be cut or deferred to a later version?
Work smart, not hard
As we've said over and over again, the shipping process is hard, and it's even harder if you don't think carefully about what to work on. Working long hours is no substitute for carefully choosing what to fix, what to defer, and what to cut out altogether. The SL should be extremely careful about which issues should be worked on, and by whom. Don't spend a week fixing a minor problem just because a mechanic is cool. Fix crashes (showstoppers). Fix bugs that utterly prevent you from shipping the game. Fix bugs that are blocking other team members from fixing their own. The SL should develop categories for bugs to aid in making the right decisions. A good level of granularity is: Must Fix, Severe, Medium, Minor, Zero, Deferred.
As the project gets closer to shipping, the SL should carefully evaluate every bug that emerges. Remember, every bug fixed requires additional playtesting, which usually introduces more bugs. If you are two weeks from your release date and have a bug that will take someone three days and 500 lines of code to fix, you're not going to make that release date unless you cut or defer that portion of the game.
Three weeks out
Content Locked
By now, you should aim to be content-complete. This means that all assets are in a locked state, except for the code itself. All maps, models, textures, sounds, HUD elements, and UI art should be finished and in the SL's master copy.
Shutting down
This was mentioned at the five-week mark, but it's even more important now. The SL is the only person who should be touching the master copy of the game, simply incorporating bug fixes from the programmers, who must only resolve the issues the SL assigns to them.
Playtesting
The mod must be playtested every day for at least two hours. Between now and launch, you want as many people as possible hammering away at your project. It's too late to make any major game design changes—don't even be tempted.
One week out
No last-minute changes
The SL should carefully evaluate every proposed fix, deciding whether it should be deferred to the next version. Again, a healthy way to think about it is that every single modification—even a single line of code—will add two days to the release date.
Two day safe period
Once every bug slated for correction has been fixed—and everything else has been deferred—you're still not done. Now you wait at least 48 hours, during which time you should playtest like crazy. Try to get everyone hammering away at the game for as much time as possible. If you find any more bugs that must be fixed, resolve them and restart the 48-hour clock.
If your mod passes 48 hours of heavy playtesting without any new issues appearing, you are ready to release!
Post-release
So, you've released, the players love it, and websites everywhere are talking about how much fun your mod is. Whether you're done now is up to you. From our experiences in the online multiplayer field, a mod only stays popular as long as it's supported. No matter how great your mod is, it's not going to garner really significant player numbers with its first version. Player numbers grow over time through repeated releases of new content, bug fixes, and of course, community support. Both Counter-Strike and Team Fortress started out small and grew over time. Each time they released a new version, more players tried them out and started playing them.
Knowing what to fix, what to change, and how to listen to your community is a continual learning process.
Good luck!