Archive for the ‘Production’ Category

Slides from my middleware talk

As promised, here are the slides from my “Adventures in Middleware” talk at OGDC 2007. Thanks for braving the 9am time slot to come and hear me yammer for an hour. I hope it was helpful.

I had a great time and learned a lot at OGDC. I’ll have to post more on that later.

Non-game innovation is hard too

Scott Berkun has a nice post up about why research labs fail at high tech companies. He has written a book called The Myths of Innovation that comes out next month.

Book Report: Winning at New Products

I give up. I’m not going to finish this book, and I suggest that you don’t even start it. I made it through Chapter 9, which is about 2/3 of the way through the book, and that’s enough. My time is worth more to me than the remaining 140 pages.

Winning at New Products: Accelerating the Process from Idea to Launch is an incredibly dense and poorly written examination of the new product process in a wide variety of industries over the past twenty years. It has a few good points, to be sure, but it bombards you with those same few good points over and over. Most of the book is mind-numbingly obvious observations about what makes a product successful. I’ll just tell you those few good points here and save you the trouble.

The Good Parts Version

Robert Cooper has studied the new product process at hundreds of companies over the years and has gathered some useful data. Here are the few points I think it’s worth taking from the book:

  1. Do your homework up front — Research your market, focus test your concepts, and get buy-in from your own management at the start of the process. If these things, don’t look right, figure out how to adjust your concept or cancel the project. Do all of this before you go into development and spend a bunch of money.
  2. Dedicate people to new products — The people working on a new product team should report to the project leader of that team. Matrix Management just leads to less-dedicated teams and makes it much harder for the project lead to do his or her job.
  3. Involve the customer every step of the way — Test your concept with them. Talk to them to get an idea what their actual needs are. Let them test the final product in the field before you sell it to everybody so you can work out the kinks. Your customer is your strongest asset in developing a new product.
  4. Have a new product strategy — Your company is hopefully going to have more than one new product. Develop a plan for what markets you want to go after, and then develop products to fit your strategy. Adapt your new product strategy to meet changing market conditions once you see how your products are doing.
  5. Have strong go/kill gates — Have a process by which projects are evaluated based on profitability, feasibility, and fit with the strategy. Actually use these gates to kill projects based on reasonable criteria and not just the internal political power of the project lead.

All of these are very good things to do. They also aren’t completely obvious, and it’s valuable to read about them and how they have worked (or not worked) in companies in the past. But a book with these five points is about 150-200 pages long, not the 400 that Winning at New Products weighs in at. This book has so much extra junk in it that it’s hard to find the good stuff.

Incredibly obvious observations

On page 101 of the book we find the two dimensions of market attractiveness:

  1. Market potential: positive market environments, namely, large and growing markets, markets where a strong customer need exists for products, and where the purchase is an important one for the customer. Products aimed at such markets are more successful.
  2. Competitive situation: negative markets characterized by intense competition, competition on the basis of price, high quality, and strong competitive products and by competitors whose sales force, channel system, and support service are strongly rated. Products aim at such negative markets are less successful, according to both NewProd and the Stanford Innovation Project.

So what he seems to be saying here is that a product that the customer needs in a wide open and growing market will do better than a new product that is going up against an established market leader that is already doing a good job of meeting the customer’s needs? Brilliant! That must be why he spent half a chapter explaining this concept. (What you see above is a summary of that longer version.)

Completely clueless about software

I didn’t expect the book to have any examples from game companies, but there also aren’t any examples from software companies. In fact, the following quote, from page 261, shows that the author doesn’t understand software in the slightest:

For example, in the development of a new software product, the proposal “to have most of the code written and partially debugged” is a very poor milestone. Words such as “most of”, and “partially” are not measurable, and further, there is no time frame. Rather, the milestone should be quantifiable; “to have 30,000 lines of code written and fully debugged by day 95 of the project” is more appropriate.

Judging the completeness of a software project by the number of lines of code it contains is ridiculous. Unroll your loops, boys! We’ve got a milestone to hit!

Not only can you not reasonably predict the number of lines a project will contain in advance, you are also usually better off if you have fewer lines rather than more. You really don’t want the criteria by which your programmers are judged to be number of lines of code they produce. You would be driving them to copy-paste-modify more, and pay no attention to re-use or reducing coupling in their code.

Most of the examples in the book come from manufacturing. Software development is much more like the “fundamental research projects” described on page 151:

Although a fundamental research project or science project may ultimately yield a new product, often the new product cannot be well defined at the beginning. Indeed, it may take months of technical research before it’s even clear what might be technically possible. [...] the Stage-Gate process described above may be inappropriate [...]

Obviously the average software project starts with a much clearer picture of the project’s goals than the average research project, but the “we don’t know what we can do technically” aspect of them is very similar.

Credit where credit isn’t due

The book, and the author’s website, state that 60% of the businesses surveyed use the Stage-Gateâ„¢ process. The reader is left to infer from this that these companies read Dr. Cooper’s books (or paid him to consult) and implemented their new product processes as a result. While I’m sure that has happened in numerous cases, it certainly isn’t the case in most of them. In many cases, the new product process in these companies predates the coining of the term “Stage-Gate”.

The author has attempted to apply Stage-Gateâ„¢ to any new product process in any company that has a series of steps with go-kill decision points between them. It’s sort of the reverse of what happened with Scotch Tape and Kleenex. He’s trying to associate his trademark with the successful new product processes in the industry even though no causality exists.

But what about Stage-Gate itself?

The Stage-Gateâ„¢ process, as described in the book and at Stage-Gate.com is not a software development process, it’s a new product development process. It operates at a higher level than project management processes like Scrum. It emphasizes cross-functional teamwork, but in the business-level context of Stage-Gate, cross-functional means Marketing, Manufacturing, Development, and Sales, not what we usually take it to mean: Art, Design, and Code. I didn’t really understand that when I wrote my previous stage-gate post.

Most of the people on a software project work on that project within a single stage (Stage 3 – Development) of the overall project. For those people, stage-gate doesn’t affect them except to define the criteria they must meet for development to be considered finished. For those of us who are in a position to influence the “what project should we start” decisions in our companies, we should consider something like stage-gate to make informed go/kill decisions on the projects. The criteria for our “want” driven entertainment products is not going to be very similar to the criteria outlined in this book for “need” driven products, but the idea of having defined stages and gates is a good one. We just need to figure out what it is we can measure in our industry to use as a basis for our own gate criteria.

Data-Driven Design

I just came across an article on Data-Driven Design for game engines. We have found it to be very useful to data-drive as much of the game as possible. Though we haven’t managed to be as complete in our purging of hard-coded game-specific features, we have gone pretty far down the data-driven road. The biggest thing that we still have hard-coded (and I wish we didn’t) are the global enums… things like the nations, careers, control types, and outfitting slots that appear in the game. The stuff that actually USES these things all comes from XML files, but the constants themselves are all defined in the code. Unfortunately that means that every time we need to add something to one of those lists we have to make a code change and make the poor designer wait for a build, a sin that breaks one of my own rules.

Look at me reblogging 5 year old posts. :)

Controlling Scope

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!