A Primer for the Design Process, Part 3: Need

[Back To] A Primer for the Design Process: Part 1, What to Do

[Back To] A Primer for the Design Process: Part 2, What to Think About

This article deals with what you'll need (or need to be asking for) from your company and development team. You'll note a reoccurring theme here, and anyone who has made a game that someone else is waiting to play will recognize it. It should also be considered as a reminder to those very people waiting for you to deliver your title.

You need time, time to design, implement, experiment, and above all, have fun. Don't forget time to fix bugs since there are no patches for console games. Time, indeed is the single-most painful entity with which to joust. Many (and I mean many) games have suffered due to lack of time to finish the job properly.

Good design is not only about good ideas, it is also about the implementation of these ideas. If you don't get the time you need to do your job, the company is wasting money on a title that will fail in the marketplace.

This is a hard battle to fight. Corporate has their own considerations such as money, product on schedule to generate revenue to make other products, and other simple things like that. When schedules get bumped, there are reasons for it. Sometimes you'll have to pick your battles, others you'll need to cut-up your precious masterpiece to make milestones. That's the way of the biz.

Know that you need to plan on experimenting at the start, and bug-hunt at the end. Don't scrimp.

Communication

Communication is not only a two-way street, but it's everybody's responsibility to maintain open channels of communication with people involved with the project.

Nothing is more frustrating that to have a memo finally work it's way down from upper management saying "you need to make these changes," when you're supposed to turn over in 2 weeks.

Conversely, you can't walk up to you're bosses and say, "oh by the way, we need 2 more months," when they just spent a quarter million dollars for print ads expecting to have product next month.
Getting what you need when you need it is hard enough when everything for the game is being done under one roof. If you're dealing with contractors for things like motion processing or sound, you have to stay ahead of the game. You also need to know if this out-sourced talent is going to keep to your schedule. Their slip affects your schedule, which in turn will interfere with marketing, and so on. This is why upper management needs you to give them a proper, realistic schedule to begin with.

Management, at the same time, should not try to interfere with your scheduling by pushing your turn over date forward, or pulling resources from your game to help on some other title. Once you're plan is set and all parties involved have signed off on the timeline, you must stick as close as you can to that timeline, even if it means dropping features. And if you do happen to cut features, let people know so they can make the proper adjustments. This is another reason to keep your design document up to date.

Good direction and open lines of communication with other parts of the company also help in keeping you from getting bit by sudden, marketing driven changes. I say marketing as opposed to the market driven because it's usually someone down the pipe hollering about the need to add some thing for some reason rather than adapting to a new market standard or good design feature in the genre title you're developing.

Deliverables

People need to get you the data you need when you need it. You need to make milestones for management when management needs them. It's a simple cause and effect relationship here. It's why they have all those planning, scheduling, and budget meetings early in the products green-light cycle.

You need people to read the design document. It should be common practice for everyone on the project to be familiar with it. There are specific spots for everyone on the project to look at, get familiar with, and understand what's expected from them. They will also help you plan for time in certain tasks. The hope and goal with the T/Q section is to get input before it's too late. It will also help you get commitments from people on the project about what they will and won't be able to do.

This is why I'll reiterate the need to keep, maintain, and distribute a design doc (especially an E-version on the LAN.)

Many a project has been held-up because of waiting for data needed to test the engine or implement a new feature. You could make yourself useful as a designer by figuring out how you could work around the wait for data. Not to say that you're going to get screwed over every time you out-source work, but you should probably plan on it being late.

Tools

Speaking of Deliverables, you also need proper tools to deliver your end of the bargain. Just as a can opener beats a butter knife to open a can of soup, good tools facilitate the design process and save time on implementation. Your tech guys need to know what you need before the project starts so they can work on developing the tools to do the job.

Time to cut features

Sometimes, due to Murphy's Law, lose of resource, or bad planning, game features may need to be chopped. This is an amazingly agonizing process for anyone who's had to drop things from their game. This is when you really need to critically evaluate your title and find what it can do without. Some features, while sounding cool on paper or looking good on a mock-up screen, just won't cut it. Especially if there's a lot of special casing or art resources that will need to happen to implement the feature.

In cases like this, it's usually better to drop some of these features so you'll have the time to really refine the ones you've kept. Remember a simple, KISS lesson-Less can usually be more.

Another resource you may want to utilize when cutting features is marketing. They might have information on what features the public wants. They also might love a feature that upper management wants to cut due to time or money reasons. This is a very good way to get the help you'll need to save the feature. This should, of course, be a product of good communication.

Good Q/A

Good play testing is essential to a good product and that's the bottom line. This should be your primary argument for more time. "We need more testing," because you do, and you will. Console developers don't have the luxury of doing a downloadable patch to fix a game. You have to get things right the first time.

A testing liaison is someone you educate about your game within the Q/A department. You can then help that person to help testing, rather than getting caught up on alpha features that have yet to be fully implemented. You can use the a liaison to insure that certain features are highlighted so they can solicit specific feedback from the Q/A group.

You also need the time to balance and fine-tune your game. The testing department, in addition to bug hunting, standards checking, and crash reproducing, should be used as a passive source to help in the refining of game play. Most testers are avid-and I mean avid-game players. No one else would take the job. As such, they usually have a good idea about how the game controls, what could make the front end easier or more intuitive to get through, and the like. Listen to these people, they are a great resource.

Creeping Feature-itus

This is a bad one. As a designer, you can't let this insidious disease take over your project. It's very hard to fight the lure when you think you might have a little extra time to squeak in a new feature. Don't let delays on one side of the project give you an excuse to add features to the game late in the process. This is a terrific way to introduce more bugs, unbalance game play, and generally screw-up the development process. The whole point of taking a month or three at the beginning of the project is to design the best game possible, answering as many questions as needed.

I guarantee it, Creeping Feature-itus is a surefire way to hurt your game, kill your timeline, and ruffle a few feathers up the ladder.

Wrapping it up

Sometimes you need to butch-up and call it a day. Some people have a tendency to tweak and tweak and tweak, never quite calling it soup, and making excuses as to why a milestone can't be met and a feature can't be wrapped. This is bad. Like the aforementioned creeping feature-itus, you need to call it done at some point in time. The lure to keep reworking is a strong one, especially amongst smaller developers. Remember-that's why we have sequels; so you can add the things that didn't make it into the first game.

EXPECT:

The 16th century Japanese swordsman Miyamoto Musashi said that, to know one thing, understand 10,000 things. What he meant was that knowledge transcends the moment; that what you learned in the past will, in no uncertain way, apply to what you're doing now.

Now, I know that I'm going to take some heat for what I'm going to espouse here, but It's my firm understanding that designers need to be well-read individuals, in order to function above par in this market, especially within a smaller company that won't let you hide in the cracks that some corporate entities can create. You can't hide in a hole, contemplating your navel. You need to interact. You need to live. You need to keep plugged-in to pop culture. You should understand concepts like Feng Shui, color theory, and the tonal difference between a natural, flat, and sharp music note and their effect on the human psyche. Learn a second language. Be educated. Read.

Game design should be an intrinsic part of your life-you don't turn it off when you leave the office. Many of our personal interests revolve around gaming, game playing, and game design. Are we geeks? Sure, but who cares. One statement I'm known for repeating around our offices is the fact that we, as game developers and designers, have the coolest job in the world. "I'm not playing games, I'm doing R&D."

A final thanks
After all of this, I'd like to take a moment to thank three people for, not only helping me in this industry, but for helping me as an individual: Jeff Peters for giving me a leg up, Clark Stacey for fighting the good fight, and Vince Bracken for helping me tone it down a bit.

Tim Huntsman has been with Acclaim Studios, SLC for over 4 years and is the Lead Designer for Acclaim's next-gen wrestling title. He has worked on the ECW wrestling franchise as well as the genre-defining WWF Attitude for PSX and N64, projects that taught him more about professional wrestling than he ever thought he'd know. When not working on games and their design, he's playing guitar in experimental projects, writing various forms of fiction, painting in the Sumi-E style, and fencing (with swords, not wooden planks.) Questions, comments, atta-boy's, or derisive snorts of laughter should be sent to [email protected] Tim's always looking to learn from his peers.