The single biggest factor that decides the amount of work you need to do to get your game out the door is the project’s scope. Time is money, so it’s also the single biggest factor determining the budget of your game. If your scope grows halfway through production, your game is going to slip. Making certain decisions early and sticking to them will have a big impact on your ability to ship your game in a predictable amount of time for a predictable amount of money.
Scope in Game Design
The best place to control scope is in your game design. A single paragraph in a design document can represent day or weeks of work for other departments, so it is vital that the game designers keep project scope firmly in mind at all times. To that end, here are some things that designers can determine at the start of the process to keep the scope constant.
1. How many player modes does your game have?
How often does the control scheme change in your game? Does the UI change with it? For many MMOs there is only the “run around and fight stuff” player mode, and the player’s avatar follows that control scheme consistently throughout the game. Some games, like Star Wars Galaxies (with Jump to Lightspeed) and Pirates of the Burning Sea have the standard MMO player mode for avatars and a very different player mode for vehicle combat. If you budget for one player mode but try to cram two in, your players will notice and they won’t be happy about it.
The number of modes will drive how many times you need to fine tune the UI, camera controls, and character controls. Every UI element in the game needs to consider player mode to decide if that UI element can appear in all modes unmodified or if it needs to be customized for one or more modes. If you are trying to build a game on the cheap, find a design that works with only one player mode. A second mode won’t double your budget, but it will increase it substantially.
2. How many players do you want to support in a single world instance?
Much of the budget of your game is driven by shard size. You will need a lot more space in your world to support 1,000 simultaneous players than to support 100. You will need more zones, quests, NPCs, mobs, long distance travel mechanisms, and map systems the bigger your world gets. Figure out how many people you need in the game to make the multi-player systems function and use that to drive the other number-of-players based decisions (like world size.)
3. How many parallel advancement paths do you have?
Many games allow the player to advance along many paths at the same time. WoW has level, two crafting professions, and honor-point based advancement. SWG had three major skill advancement paths (crafting, combat, entertaining) plus faction-base advancement. Each of these paths has unique ways to make and measure progress that are not present in the other paths. That means they each require design of new advancement systems and new code to implement those systems. To keep your costs down, use the same mechanism for advancement in all of your parallel paths. If players earn XP that they use to buy skills off a tree, use that for all your paths and differentiate based on how they earn XP. If the players advance down a linear path by using skills but spend currency on buying skills off the line, leave everything the same except the way they take a step down that path.
4. How many branching advancement paths do you have?
Many of your parallel advancement paths will have branching within them, or at least allow the player to select a small number of parallel paths out of a larger set. The number of options has a big impact on how much time you will spend tuning your game. You will also need unique skill icons, animations, particle effects, and equipment for many of these branches, so the number of options will directly affect your art budget. Determine early in the project how many branches you need to let the players feel differentiated, and stick with that number. Adding branches after launch incurs the same tuning cost as adding them before launch, but is something your players will love.
5.How important is replayability to the game?
Do you expect players to play through the entire game with several alts? How many different newbie experiences do you need to provide? Each of these parallel content paths costs scarce content creation time. If you aren’t expecting a lot of replay from the beginning there may be time you can save here.
6. Do you need a seamless world?
Does your game call for a seamless world? For some games the answer is definitely “Yes”, but many games will do just fine with hard zone boundaries. Some players will make noise about the loading screens, but that’s true of any design decision you make. Having zones didn’t hurt EverQuest or Dark Age of Camelot’s performance, and I don’t think that having a seamless world has really helped World of Warcraft’s.
Seamless worlds are more expensive than zoned worlds. On the art/world building side you have to build the transition areas in a way that lets you have the textures and geometry from both areas loaded at the same time. The world builders also have to deal with editing what’s effectively one continuous ground mesh for the whole world. Engineers get a lot of extra work from seamless worlds because of the server hand-off issues and issues with players acting across server boundaries. The game’s world building tools have to be much more sophisticated to support editing transitions between zones. Operations and customer support costs are going to be higher for a seamless world thanks to all the object-dup and object-lost problems that are inevitably going to crop up with the more-complex server technology required.
If your game requires a seamless world, by all means use one. If not, use zones and save yourself months of development time. Make sure you stick with this decision once you make it, however. Switching from one to the other is going to invalidate a lot of code and art.
Scope in Production
There are many production-level questions to resolve to determine the scope of your project. These factors don’t really affect the game design, but can change the way the game appears to your customers.
7. How big is the gap between your minimum hardware spec and your recommended hardware spec?
Your art and engineering teams are going to have to do the most work to make the game run well on your minimum spec machine. If your recommended spec has to look significantly better than that, you will probably be incurring significant additional art time for second versions of many assets. You will also require additional engineering for the switching between quality levels.
8. How high-end is your minimum hardware spec?
You pay for every pixel and every polygon that an artist produces. Higher poly budgets and bigger textures will increase the time it takes for your artists to develop assets. Because these things are driven by the CPU and GPU horsepower on the min spec machine, picking your minimum hardware spec can have a huge impact on your project’s scope. Higher system requirements will also affect the potential size of your market, particularly in Asia.
9. Can you buy technology, or do you have to build it?
Developing every new piece of technology for your game costs money. You can often constrain the scope of the project with middleware. There are game middleware products for just about everything these days, so even if the “whole game” middleware like Big World or Hero Engine don’t work for you, smaller “just one feature” middleware like Speed Tree, Path Engine, or Ageia’s PHYSX probably will. Of course middleware is never going to do exactly what you need it to do, so evaluating and integrating this middleware as early in the process as possible will allow your designers to deal with middleware limitations in the game design. You don’t want to get into production and then find out that a core element of your design and a core piece of your middleware are incompatible.
Scope your project early
Every single one of the 9 scoping decisions listed above is a decision that needs to be made early in the project. In fact, they are core enough to the process that you probably have answers for many of them in your first round of documentation. Make sure these are things that you talk about up front. Spend enough time prototyping your game that you can be sure that you have the right answer to each question. If you think you need to change the answer to one of them, take a step back and see how that will affect the project’s scope as a whole. Don’t allow your scope to drift gradually upward without ever having made the decision to change it.
Be realistic about your project’s scope. If you can’t build the game you want at a given scope, don’t just charge ahead and try to do it anyway. Either accept that your game is a bigger scope (and higher budget) or start again and come up with a game that you can build at the scope you can afford. There is no shame in building a game with a small scope. Puzzle Pirates, City of Heroes, and World of Warcraft are three games with very different budgets. The thing that they all have in common is that they have solid return on investment and are making plenty of money for their respective companies.
Once you decide on a scope for the project, make sure that everyone knows what it is. Let your team, your community, and your publisher know what your scope is the whole way through the process so that they can set their expectations accordingly. If you change your scope (and slip your target date), make sure you include the scope slip as one of the reasons you’re slipping the date.
Controlling the scope of your project is the first step to controlling the project’s budget and schedule. If you want to avoid slipping repeatedly or being forced to launch before you’re ready, scope creep is something you must watch out for. You will be glad that you did!
