Primer for the Design Process, Part 2: What to Think About
By Tim Huntsman
July 7, 2000
Previously, I talked about the "Do" process, about what you as a designer can do as you ramp-up in the early design process. The focus was on asking questions, finding out what people want, getting a focus for your project, and putting it into a format everyone could (and would) use. This next section should help in giving you some insight about the frame of mind you should be in during the early design and implementation phase.
What to Think
The "Think" section contains info that you, as the Designer and maintainer of the overall vision of the product, should be thinking about to improve the quality of your game. To be thinking is to be involved in the design process. You should be in constant contact with all the people working on your title. You should know what goes where,who's supposed to put it there, and be able to answer just about any question anyone might have about the product.
1. Asking Even
The following section can be employed through the development process. These are things you should be asking as you go Alpha, and they should be finalized before you go Beta.
(Just so you know where I'm coming from, I've always understood the terms Alpha and Beta as they apply to game development in the following way: Alpha means that all of your "major" technology is in place, but not working 100%. This also applies to sound and art. Beta means that everything that's supposed to be in the game IS in the game. It's all down to tweaking and bug hunting from there to turnover.)
How is our
front-end/fluff going to flow?
The "KISS" rule applies here (See "Never" rule #1.) Don't force the player to filter through 6 or 7 screens to get to the game play unless it's absolutely necessary to the game. Put things in their logical place, and don't be afraid to give the player help or tell them what buttons do what within each screen. Another rule for you PC developers out there: If you're going to make me type a new name for a game save, please allow me to hit the "return" key to save instead of forcing me to go back to the mouse and click on the "save" button. I won't even talk about deleting an old save to free up some space.
This also includes thinking about what you're going to let the player do to configure their individual gaming experience.
On a side-note-many companies have front ends that, to put it simply, suck. They have limited options, navigating these options is a task Uri Geller couldn't fake, and it's usually a chore to try to configure something for your own liking. This comment holds true for the vast majority of PC game companies and not consoles. The console companies have standards that they are held to. Make it easy for players to modify things that you're going to allow them to modify. And, I might add, there's absolutely nothing wrong with giving players instructions on what button(s) they need to press to make something happen on a menu screen.
or modes should be included?
Creating a player in International Superstar Soccer '98
question could be restated as, "How can we empower the player?" More
and more players want to "mod" their games. I've seen this with the
popularity of Quake mods-special fan-made levels, skins, and sound FX-and
in games I've worked on like WWF Warzone and WWF Attitude. Giving
players some measure of control over their environment will do wonders to increase
the replay value of your title. It pumps up the "cool" factor. Konami's
International Superstar Soccer '98 had the same create a player idea allowing
the player to make either real or fantasy teams and using them in long-term
Empowering the player with cool features, options, and game modes also has a definite payback in the fact that you will build a loyal fan-base that will buy into the franchise you create. (Sequels, people, sequels.)
A simple way to find options and modes to add to your title is to ask your testing department (or your publishers) or get some focus group testing done. Everyone has an opinion, you might as well listen to them.
How's the pacing?
Simple question. Is the overall game too long? Usually, you'll find that the game's too short. Players fork out anywhere from $20 to $70+ bucks for a game and it better be worth it. There are no rules on just how long the total gaming experience should be (with the exception of arcade titles) but players should feel like they got their money's worth.
A secondary consideration is to consider in-game pacing in the same way you'd critique a book or a film. Does your product drag its heels for an ungodly long time, boring the player to tears from one scene to the next? Does it go crashing through it's paces at breakneck speed, never giving the player time to catch a breath or reflect on what he's supposed to actually be doing other than surviving? 'Balance the flow' are the words to remember. Changes in tempo are a good thing but remember to take care how you manage those changes.
How hard is
Get QA's feedback when considering the difficulty. Can players breeze through your game in minutes, in hours, or days? Remember the players who are buying your game, and don't always look to please the QA testers who have been playing the game solid for the last 6 to 9 months. Whatever is going to be considered difficult for your testers will probably cream the average player who might purchase your game, and force them to return it because they can't get past the first level. More than three levels of difficulty are usually better if you can swing it. Sad to say, tweaking levels of difficulty - adjusting AI to match and balancing game play to accommodate - is a tough and time-consuming thing that needs to be addressed by everyone involved on the project.
How can we integrate
cut scenes, FMV or Run-time movies?
The first question is simple: Do you really need something like this, or can your game survive (quite nicely) without this? If absolutely necessary, try for the "in-game" movie rather than the pre-rendered cinematic escapade. It not only helps to keep the player immersed, but your transitions will be less jarring to the player. Metal Gear Solid, Half-Life, and Soul Reaver were good examples of the In-game movie.
How can we
get replay value out of this?
Some games are over when they're over. The surprise is done and there's really nothing left to look for. Others can be played again and again, either because there's more to discover, or you're trying to do something personal like beating a high score. (Score? Games keep score? What's that? I'm sorry, but I'm a throwback to halcyon arcade days of the early 80's where score was EVERYTHING!)
How are our
No one wants to sit around looking at 2-tone bar fill while waiting for the game to load. Sony has standards for it and it's not really an issue for the N64. PC guys, you're on your own. Push the programmers to optimize this. It's ALL part of the total game experience.
On a related note here-allow the player to save where they want to unless it's fundamentally necessary to not let them save. Reflection's Driver for the PC is a glaring example of forcing the player to get through 3 or 4 scenarios before they can save. You should know just how annoying this is and furthermore, you shouldn't be doing this to the gamer unless it's absolutely necessary to maintain the fundamental design features of your game.
2. Good Habits,
A Critical Eye, and the Fun Factor
Merging Design Documents, Schedules, and Budgets.
Time will need to be taken during, or immediately after, the pre-production design phase to come-up with real numbers, times, and dates for the project. The usual problem with those above-mentioned words is that, for each concept mentioned, you have a different group of people crunching the numbers. They also don't tend to be in very close contact with each other. Many companies are fond of saying, "Hey, we need to fill a gap in the quarter here! You guys, do this game in 8 months!" Your response is, "Not on your life, but if we must, we'll need more money and resource to do it." Of course, they don't want to give you more money and resources to do it. That's why it helps to gather all relevant parties to this portion of the development process, bring them together, and hash out the numbers. That's why it helps to have your design broken down into needs, tasks, and features at the start.
There is no better time to examine resource and budget considerations then while you're hammering out design detail, unless of course you have nothing to do with making the schedule or planning the budget. If you're leading the design vision of the product, however, you should very well have a hand in the schedule and budgetary considerations. Get all the relevant people into the room at one time and hammer out the numbers. It's a big pain in the backside, but it's definitely worth doing in the long run. Remember, when the design doc is changed, or features are re-worked, you're going to have to take a look at the impact and figure out if this is going to push you back in the development process.
This sounds easy, but in the throes of development long hours and crushing stress from all sides can cause details to slip through the cracks. You might talk about a feature in a late-night impromptu gathering and then implement the change the next morning. You should document that change, especially if you end up doing a sequel a year or so later, so that you remember what you did in the first place.
When anybody on the team decides to round out a feature, change a feature, or add a feature this change should be noted, documented, and brought to everyone's attention. If you've created an on-line style design document not entirely unlike the one mentioned part one of this article, you'll have the mechanism in place to keep the team informed and responsible.
Keeping a Design
This is as straightforward as it sounds; keep a running dialogue of what's gone right and wrong during the project. Week to week will probably do unless you're in the middle of one heck of a crunch time. This will serve a number of purposes. First, it lets you recall, months and months after the fact, lessons you may have learned or not learned early in the project before the press of 15 hour days began to blur one day into the next. Secondly, it allows you to bring up key issues of good or bad work done by people throughout the project during the post-mortem (your company has post-mortems, right?) And lastly, it will help you in publishing a post-mortem article for a relevant publication so your fellow designers out there can learn from your experience, right?
One of the best things you can do for your game when you're looking to implement features is to critically evaluate the competition and I mean look at them. There is a saying, "It's amazing how much you can see if you just look." Don't knock on the competition simply because their title is out before yours hits the shelves, evaluate it. Every title, no matter how heinous, has some lesson to be learned tucked within its folds. The primary lesson here is to avoid making the same mistakes that killed a rival product.
This goes for the whole game, look at things like their front end to see how easy it is to get into the game, check the controller set-ups, examine screen real estate and test in-game timing issues and controller sampling. You don't want to be reinventing the wheel if you don't have to. If some other game is doing something well, borrow that idea or concept. You just have to make sure that you don't outright steal the concept. That would be a no-no. Remember: Good design not only about ideas, but it's also about the implementation of those ideas.
Of course, at some point you are going to need to turn that cruel, cold eye of unswerving criticism on your own title. Testing feedback will help here but ultimately someone's toes are going to get stepped on. When looking at your own product, put your ego in your back pocket. Many a title has crashed-and-burned because someone's ego fought against the tide of popular opinion and washed-out (or in) a feature (or features) that killed game play.
The 'Fun Factor'
Some companies want you to work on the "fun factor." Everyone's looking for that elusive concept that you read so much about in fluffy design treatments and marketing blurbs. The causal gamer and average consumer can't nail down what is really fun. They'll tell you something's fun, but they can't tell you what's happening inside the game and what they're responding to. Fun tends to be a relative concept that revolves around things like pacing, timing, and excitement as specific to that particular title. These are things you can theorize about; tell people "punching this guy is fun!" but you'll never really know until you spend time with the game and work it out. As a designer, you need the ability to critically evaluate the competitions efforts. Look at how they handle certain issues and make note of them.
The fun factor comes from being able to identify exactly what's being done, how it's being done, and you can continue to do it without the game getting boring. This is a touchy part of the implementation of the design. Lots of people are going to have arguments one-way or the other about the details. One thing that will help you with this is filtering proper information and feedback from your QA department, but I'll go into that later.
3. The list
The list of "Never" has evolved into a kind of Ten Commandments for me. They've evolved over the years, usually noted and expanded upon while playing games. They are things I've noticed, come to realize, and things that are brought up in conversations with my peers. I've also noted that some of these rules get repeated in game previews and reviews.
Like all good rules, however, they are ALWAYS made to be broken. And, of course, you are allowed to break them. You just better make darn sure you know what you're doing when you do break them.
The last installment of this series (Need) will deal with some of the things that you, as a designer, should have available to you within your development environment. Did I happen to mention time . . ? There's also a small section at the end called 'Expect.' This is more of a personal bit about how I see the intrinsic philosophy of game-making and how it relates (and rules) my life.
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 firstname.lastname@example.org Tim's always looking to learn from his peers.
Copyright © 2003 CMP Media Inc. All rights reserved.