This article, the second in a three-part series, 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.
[Back To] A Primer for the Design Process: Part 1, What to Do
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 About:
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 More Questions:
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.
What options or modes should be included?
Creating a player in International Superstar Soccer '98 |
This particular 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 tournaments.
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 hard?
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 load/save times?
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.
Updating the design document.
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 Journal
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?
Critical Evaluation
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 of "Never":
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.
1. Never overcomplicate a game if you can help it. Stated in the obvious way it reads, "Keep It Simple, Stupid." Those of us old enough to look back on what is considered the "classic" era of video gaming remember it as being a time of very straight forward gaming that could keep you glued to a monitor for hours. Games evolved around a simple premise or method of controller input. Those games were not limited by technology or the lack thereof, but were instead solid concepts of experimentation. The KISS principle still holds true today. Pac-Man had one joystick and one maze. Tetris had a few simple shapes falling gently from the sky. Even Quake III Arena follows the KISS ideal of not over-complicating the main goal, which in this case happens to be blasting your opponent as many times as you can till your hands fall off.
The context may change with player expectation or technology, but the principle will always remain sound.
The arcade game designers from the good old days knew what they were doing. The philosophy there was that they had 30 seconds to introduce someone to a game and maintain that interest. People are willing to drop 25 cents into a cabinet to see what it does. If they don't see it immediately, they won't drop another 25 cents into the machine. You have to grab them quickly. You do that by keeping it simple. The next time you go to E3 or some such event, spend some time watching not the game, but the people playing the game. See what's grabbing their attention. Find the games that people won't put down then try them yourself with an eye towards critical evaluation.
2. Never make the same mistake twice. Critical evaluation of your competition means looking at what's been done and what's out there. It means if you're doing a game in a similar genre, you should be borrowing from the things that they do well, and avoiding the things they don't do well. Don't re-invent the wheel unless you sincerely have the time and wherewithal to come up with a better way.
3. Never take control from the player if you can help it. Don't make the player sit through some animation, cut-scene, or musical interlude if they don't have to. Metal Gear Solid did a great job of using run-time transitions to keep you there and interested. Valve's Half-Life was another excellent example of transitioning-taking control from the player-but it didn't really feel like it. Revenant by Cinimatix, on the other hand, is a frustrating example of waiting for the developer's scripting engine to putter characters around the screen while you mash the ESC key in frustration.
This rule also works for "in-game" events. A constant and common failing of many fighting, action, or other titles where the player is physically "fighting" an opponent happens when the player gets "stuck" in a hit reaction loop. The animation may have looked cool on the animator's screen, but while the hero is writhing in pair from a vicious blow on the part of the attacker, this same attacker has finished his animation and has initiated another attack. (while the hero is still writhing) See where I'm going here? The player ends up getting hit 3 or 4 times with no chance to defend themselves. This is a very frustrating flaw.
4.Never forget the controller or I/O device you will be using to play the game. Obvious problems are when PC games are converted to consoles. It's hard to type from 16 different hot-keyed actions with a Playstation controller. You've figured out what your character will be doing in the game, at the same time you should have figured out how the player is going to maneuver the character through your world. This applies to navigating inventory screens and complex selection schemes as well. You should always defer to the KISS philosophy here unless you absolutely can't help it.
5. Never assume the player knows what you're thinking. Players are usually bright people who can intuit a pre-existing puzzle or situation rather quickly. Because of this, designers must think of ways to challenge the player. Sometimes, we will challenge the player by presenting to them something that makes sense to us while we were working on it, and make sense to QA while they were testing it, but doesn't translate for a player who hasn't spent the last 9 months of their life working on the game.
Soul Reaver is a good example of maintaining this rule AND breaking it at the same time. The tutorial portion of the game was an excellent introduction to the game's world. At several points, however, the game would tell you do something without any explanation. Case in point: Directions were given in the form of a compass point (go North, young man. . .) yet there is no compass in the game so, just how am I supposed to know which way is North? Sound's easy, but I lost 4 hours backtracking to figure this one out.
6. Never break the established rules unless you TELL the player. There are a number of games out there that will teach the player certain habits by NOT letting them manipulate their environment. That's OK, but if at a later date you decide to allow the player to use these objects in a way that's different from previous lessons, TELL THEM! Metal Gear Solid was good about this. The game gives you the information you need to accomplish your goal. It begs a little suspension of belief when this happens, but it's far better that fumbling around for several hours trying to unlearn something you've been doing the entire game to this point. Withholding information from the player should not be the extent of the puzzle. There's also the parallel argument here about making your puzzles somewhat dependent on existing logic. Return to Zork was a prime example of logic having nothing to do with solving the puzzle and the players lost interest for that very reason.
7. Never assume technology can fix bad design. This is a BIG rule that this industry is guilty of breaking repeatedly in the last few years. We see a number of titles every year that claim to make certain technological feats, usually in terms of pushing poly's or having "the most realistic AI ever encountered!" You're answer to marketing ploy's like this should be, "So, is it fun?" Real-Time Lighting! If the game's not fun, no one is going to want to play it.
There are cases where technology can ease bad design. Pushing more poly's, thus raising the frame rate and smoothing out your visuals, is a good thing. Some technologies, however, don't or won't filter through to the average end-user. They generally don't know about or care about technical specs, they just want to know if the game is fun.
An example here is the PC product Nocturne by Terminal Reality. The game has great "real-time lighting and shadows" FX that lead to some truly creepy moments in the game, but anytime more than two creature jumped on screen, the frame rate would bog to amazingly bad rates, making combat near unplayable at certain points. Very frustrating.
8. Never assume the license is all you need. No association in the world will help you sell an inferior product. There are some exceptions to the rule but as above, players want to know if the game is fun.
9. Never cheat the player. The basic rule here is that if the player can't do it, the CPU shouldn't be able to do it. It's AMAZINGLY easy for a programmer to set up the AI to be perfect but it's a lot harder to get that AI to act like a human would. The hand's-down winner of cool creature AI would be Unreal because they do human player-type things to get on you.
10. Never design morality. If players find a way to circumvent a "feature" of your game by utilizing the save feature, let them. You see this kind of problem in RPG's like Baldur's Gate or Jagged Alliance II. I myself was guilty about sending guys blindly into the fray just to see where the bad guys were coming from, then re-loading the game and planning accordingly. Don't penalize the player for re-loading a failed attempt at a room or hurdle. A specific example of creaming the player in this manner would be the expansion pack to Baldur's Gate-Tales of the Sword Coast. They had a feature that, if you re-loaded a previously saved game, they would throw MORE monsters at you or make some sprung trap hit you even harder. This, quite simply, sucks. It's also a poor excuse for problem solving. If the player wants to save his game, walk into a room to see what jumps out, the re-load and re-configure his characters, let him. So what? We don't design morality. If the player wants to "cheat" let them but if you can come up with a solution that DOESN'T screw the player, even better.
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 [email protected] Tim's always looking to learn from his peers.
Read more about:
FeaturesYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
