Topic : Making a game: The Design
Author : Drew Sikora
Page : << Previous 2  
Go to page :

– 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).

Choices, Choices…
So far you’ve heard a lot about me saying, "You can’t 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.

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.

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.

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…

Page : << Previous 2