[size="5"]Recap

In part one of the series, we created the game idea that is to be the focus of this article series. Of course, I mean your game idea, not one I came up with for the article. We went over the basics of grabbing an idea, fleshing it out, and jotting down some features on a piece of paper. Then we subjected it to the Test of Time as the final judgment of whether or not to proceed. But if you're reading this article, then I guess we're good to go!

In this part, we will go over the idea and try to weed out anything that could trip us up when we get to the development process. It's a very good idea to kill off these things before they waste a lot of money and time, both of which are rather hard-won these days. Indeed, there are even a few things we have to look for so that we don't spend an undue amount of time writing up the design spec with features we'll never use.

All said and done, it's time - let's get ready to rumble!


[size="5"]Stomping on the Feature Bug

Since this is an important topic, we'll discuss it first. Feature creep is an expression used to describe the want or need by the designer to add in too many "cool" things to spice up the game. The problem? Well, it's rather complicated. First off, feature creep is a great way to extend development time unnecessarily. Secondly, some of the features the designer chooses to include have absolutely no impact on the way the game is played. This is the worst aspect of feature creep. Adding in things that do not improve gameplay is simply a waste of time and resources.

Feature creep is acceptable in small amounts, however. Sure, it's always good to add in some spice to make things look cooler. The problems I described above were when the creep gets to a point where it just doesn't add anything anymore. This is where the hard part comes in: when to we get to the point of saying, enough is enough? What features are good and what features are bad? Which do I keep and which do I throw out?

Well, the first step is to take a look at the features list and see if you can pick out anything that might be chrome, or feature creep applicable. If you can, separate these items now. If you can't then don't worry, we'll revisit feature creep when we get to the Development stage. Of the items you separated, order them from what you think is least important, to the most important. Be sure to keep in mind certain things such as: how often this will be used? Will it affect gameplay? Is it a developed technology, or will it take time to research? These questions will help you order them correctly and maybe root out some more from the features list. Now keep this separate list with the features list -you'll need it during development.


[size="5"]Story is Good, Gameplay is Better

Games these days always seem to need a story. But not just any story, they need a raging epic of mass proportions. Well, while it may make a good book, it won't necessarily make a good game. Of course, every game really does need some kind of story. Some games have a storyline that the player follows as he progresses through the game. Other games have a short backstory that introduces the player into the world, and then turns him loose. Both methods are used about equally - mainly it's RPGs that use storylines and Adventure or Action games that make the most use of backstories. But this is not always true.

Getting back to the section title, it is time to analyze the story you came up with for your game, if you did. Some games do not even have a story, but instead let the player create a story from the gameplay. The Sims is an example, as well as Sim City. If you do have a story, then lets take a look at it. Does it fit in with the gameplay? Does it support the gameplay? Does it interfere with the gameplay? These questions all have a simple meaning. The player did not just spend 50 bucks to come home and sit down to watch an interactive movie.

Gameplay is what games are all about. The story is just there to support the gameplay and should never dictate the actions of the gameplay. This leads to linearity and a boring game. Instead, the story is used to guide the player and to explain away certain things like why should I have to ride this hover bike? Because you need to get to the other side of town. But then you see a sign for the subway. What should you do? This is a prime example of good gameplay and story mixed together. Now, suppose the story said you had to ride the hover bike even though the subway was right there. Well, there goes the fun of deciding whether or not to take the subway. In that case, the subway should either have not been there or the story should have explained why you couldn't have taken the subway.

Whoops, overstepped my bounds a little bit there, we're already moving into the next section.


[size="5"]Ensuring Good Gameplay

As in the earlier example, there are things you must watch out for when marrying a story with gameplay. Everything has to work out - you can't just leave the player hanging or take a decision right out of his hands. There are other dangers as well. These include dominant and dominated strategies or choices. Also is the lack of interactivity. All these can combine to totally kill off any semblance of gameplay.

First let's go over dominant and dominated choices. The dominant choice is one that will always be taken, regardless of any other factors. This is not good. Even worse are the dominated choices. These are choices or strategies that will never be used, regardless of any other factors. Sound familiar? No, dominated choices aren't feature creep - they are bad game design - but they are just as bad as feature creep. Avoiding dominance in a game is a matter of balancing out all the other factors that affect the player's decision. The term balancing is used mainly in strategy games, because of the units, but all games must be balanced in order for the player to enjoy them the most. You may not think an Action game needs to be balanced but if you play a game where you have to take out a fortress with a pistol, I think that's quite unbalanced.

And then there is interactivity. What is interactivity? Interactivity is a game. All games are interactive and let the player provide input. Well okay, I have a mouse and keyboard right? No! An interactive game lets the player change the course of action with his own actions. A non-linear game is an interactive game, and that is why they are the most interesting and fun to play.


[size="5"]Graphics are Good - Gameplay? Still Better

Yep, here we go again. This time it's graphics under the gun. To be prompt, a game without good graphics is commercial suicide. No one will look at it, no one will take interest in it, and no one will talk about it. Now, notice I was careful not to say no one will like it. Aha, there's the kicker. The chance still remains that it will be a good game with an engrossing story, fun gameplay, and lots of cool features that don't detract from the experience. So why doesn't anyone care about it?

A lot of people today believe that if you make a cool looking game, people will buy it, and they will love it. Well, we're still slowly trying to reverse that sentiment back to its original state. Like I stated in the last Gameplay is Better section, no one will want to spend 50 bucks on something they can stare at and go "ooooh" but not enjoy playing when they can just spend 6 bucks on Sports Illustrated Swimsuit Edition. (sorry, girl gamers - typical male pig, right here. Spoiled fruit is in the basket over there...)

Gameplay still rules supreme over all, and there is nothing to dispute it. Not good graphics, not good story, not anything. Like I said before with good story, good graphics do help, but here is where feature creep uhh, creeps in wearing a different hideous face. This time, however, instead of being called chrome, we call it eye-candy. Everything that applies to chrome applies to eye-candy. There is such existence of too much of a good thing, and when applied to graphics, it results in eye-candy, which in turn can result in extended production and falling behind schedule.

You can beat back eye-candy the same way you beat back chrome - by going in and rooting it out and asking the same questions: Does this help gameplay? Does it detract from gameplay? How many times is it seen? Does it require research? If you think you have too many, then you'll have to knock off the ones that are the least important and file them away as things to be done if you end up under budget or schedule (ha, ha and double ha).


[size="5"]Choices, Choices...

So far you've heard a lot about me saying, "You can't take a choice away from the player" and stuff like that. Why not? What do choices do for gameplay? Well, a choice brings up strategy, and strategy brings up thinking, and thinking about something immediately alerts you to the fact that it is interesting - otherwise why would you be thinking about it? So in a nutshell, choices lead to interesting games.

The example I used before is still valid in this case. Having the player choose whether to take the subway or the hover bike makes the player think. Would the bike be faster because he could then zip in and out of alleys and side streets? And then he might think further, about the police, or if he got in an accident. And the subway might be slower, but it would be more direct being able to go beneath buildings. No one wants to be spoon fed as they progress throughout the game, and those who do can go out and buy a strategy guide.

But like all other things, choices must help the gameplay and be interesting. The above example was an interesting choice. A choice that would not help gameplay would be something like having to decide which shield to buy when the only thing different between them is their color. A boring choice would be which rope to climb when they both lead to the same ledge. You could easily convert this into an interesting choice by placing a rock on one rope that will fall down on the player when he starts climbing it. Boring and unhelpful choices should not be too hard to find and squash early on, which you should do.


[size="5"]Rules and Emergence

Rules dictate the behavior of the game world, just as they do the real world. A rule can be anything so long as it creates some sort of a choice for the player. For example, a rule states that in this room there is no gravity. Well then, says the player, should I float across or use my magnetic boots? Which will be more beneficial? This is a choice, which means the rule was in good effect.

Emergence is the result of having rules. What basically happens is rules, combined with certain features and situations, can produce features you never knew existed. For this reason, emergence can be categorized as a type of feature creep. However, this is the in-game type, as most of these features will become apparent only when the player is playing the game. For that reason, we will hold off further discussion until the fourth installment.


[size="5"]Thinking Ahead

Last but not least, I must remind you to always think for the future. A common mistake is to plan a game that will look good in today's market, and then when the game is finally released a year and a half later, the market has changed, and the game bombs. This is one very good reason why all budding game developers should learn from the beginning how the market works, and then start to follow its trends. You must be able to somewhat predict what the market will be like at least a year down the road in order for your game to be extremely successful.

Of course, making an accurate prediction is near impossible given how fast this industry revolutionizes itself. However, that does not nullify the fact that you must try. Take a final look at the features in your game and see if any of them might be considered out-of-date by the time the game is released. There is also the worst-case scenario, where the game idea itself goes the way of the Dodo. This can be because the genre loses sales, or another developer releases something close to your own idea. You must account for any or all of these possible pitfalls.


[size="5"]Conclusion

Wow! We sure did cover a lot of ground. Now your little baby idea should be almost fully grown and sharpened to perfection. If you paid attention here, you should have no problems as you start to develop the game. However, you could not have possibly wormed everything out, and during the development you will be faced with choices: Should I drop this feature? Should I add this feature? Should I tone down these graphics? Do I need to revise the story?

All these will be answered in part four, as I walk you through the development process. In the next installment, we will discuss how to put all your ideas down onto paper so that you can form your design spec and the shorter version that you'll pitch to publishers. Until then, happy coding!!

Questions? Comments? That's what email's for...

[email="drew@gamedev.net"]drew@gamedev.net[/email]