This page will discuss how you can design an adventure game. The design is independent of Smash, so you can turn around and implement your design in as many different languages as you like.

It is important that you design the bulk (preferrably all) of your game before writing any final code at all. There are many ways to design a game. Some work better than others, and sometimes it depends on the individual as to which method works best. The method outlined below is how I design adventure games. You may find this useful in designing your own.

Design the World

I design the world first, before I have much of an idea at all about puzzles or storyline. Decide what type of world your game takes place in. Is it realistic or fantasy? Historical period piece or modern day? Domestic or exotic? Determine the different types of places you'll be able to go. Decide what the world is like in terms of culture and history -- at least insofar as it may affect the storyline of your game. Develop story ideas in the back of your head as you are doing this, then flesh out the backstory. Develop the main character. Decide what tone the game will take -- is it humorous, deadly serious, or just quirky?

But back to the world, once you've figured out the types of places you'll be able to go, sketch out a map. Draw black squares or something for places that you'll be able to "stop" at in the game, and paths dictating how you are able to move between them. The map doesn't have to be finalized at this point, but you should have a rough idea, at any rate.

It's important to decide how big you want your game to be. Remember, you'll have to code every location you plan, so don't bite off more than you can chew and design a game larger than you'll be able to complete. On the other hand, you don't want a game to be too small, either, or it won't be broad or deep enough for players to develop an investment in the world or the story.

Your map is not fixed, though. Once you develop a storyline and puzzles to go with it, you may find yourself needing to make adjustments to your map. Feel free to do this. There's give and take between all the different elements of a game like this.

Design the Story

Adventure games typically have some kind of broad story arc to them that provides an ultimate motivation for the main character. If a story hasn't come to you in the course of designing the geography of the game, it's probably best if you come up with something immediately afterwards, before progressing any further.

Some people have an easier time if they have the story first, and only then design the world -- this can result in a very different kind of game, one more oriented on story than world. This can have rewarding results, but it's typically more of a challenge. If you're designing your first game, it is recommended you design the world first, then the story.

Generally, you want to keep it at a very basic story arc. Badguy rules land oppressively; you must overthrow him. You can be more creative than this, but we're only after a very general plot arc. The reason is that if you constrain the story too much, it makes it more difficult to come up with puzzles later. Plus, we don't want to constrain the course of events too much anyway. We want the player to feel like he has the freedom to act as he pleases, rather than being locked into a set pattern of events. In reality, of course, the player is locked into a set pattern of events; what we're concerned about preserving here is the illusion of freedom. Developing the story too much at the outset will have a tendency to lead you to a game design that forces the player through narrow channels of events, which breaks that illusion.

Design the Puzzles

Puzzle ideas will probably come to you as you're designing the map, and probably a few will come to you as you're designing the general story. Jot these down. When the map and story arc have been fleshed out a bit, start to develop puzzle ideas. Develop the other characters you'll encounter in the game, too. Try to think of innovative things that the game player will have to do.

Also keep in mind the kind of interface your game will have. If your game will ultimately be coded in Smash, remember that Smash games have menu-based interfaces, where the player's options of what he can do at any particular time are always present. It can be tricky to design good, satisfying, challenging puzzles in a menu-driven game, but it can certainly be done. Good ways to do this:

• Require actions to be done in a particular sequence.
• Include puzzles that require coordinating multiple entities (objects, components of the world, other characters, etc) together.
• Include lots of options, preferably most of which sound like reasonable things to try.
• Include puzzles where the challenge is for the player to figure out where to go.
• Include puzzles based on timed events.
• Include puzzles that involve using objects in unconventional -- but logical -- ways. Include puzzles that involve using more than one object together.
• Make your world "interactive." By this I mean, let the player do things with the world you're in. Let the player change the world and do fun things, even if it doesn't necessarily further your quest. Don't throw in too many gratuitous red herrings, but small interactive diversions can be fun.
• Make your world intriguing. Make it fun to explore. Make your characters interesting in some way. The playability and the puzzles come first, but after that your world should be exciting for the player to explore and discover.

Some things to avoid:

• Don't require the user to select options multiple times unless it makes sense.
• Don't require inordinately long treks to move around from place to place. If you require much back-and-forth travel, don't have the journeys be too long. Exploration is fun. Quick jaunts over to already-explored places are fun. Long treks through familiar ground gets old. Then again, if the player is too mobile, it can shorten the game and make it too easy. There's a happy medium in there, and there's a broad range of what's acceptable.
• Don't include illogical puzzles. Try to make the puzzles as logical as possible. Even if they are obscure and difficult to solve, they should make sense after the fact, at least.
• Avoid linear plotting. Don't have your game resemble a linear format, that is, there's exactly one thing you can do, and that leads to exactly one other, and that leads to exactly one other, etc. Some parts of the game can be like that, but on average there should be several different things you can do to further your quest.
• Don't make the gameplay too "sparse." Make at least half of the locations in game "significant" with respect to solving it. If you have too many locations that don't have things in them that play a role in solving the game, then the gameplay is too sparsely distributed over your map. Few game players are going to want to explore dozens of places where you can't do anything helpful. Somewhere between 50% and 100% of your locations should be "significant." Generally speaking, the higher this percentage, the better. Don't worry about calculating what your significant location percentage is, though -- just be aware that games can be made too sparse and then do what feels right.

As the individual puzzles start to come together into a course of play, write down a walkthrough of the game, which is a step-by-step list of instructions for how to solve the game. This need not be so detailed as to include every menu option the player ever need select: just list the "significant" actions that lead to the solution. This helps get the course of play straight in your head. Also make a list of all the inventory objects that you'll have in the game.

Resolve any problems that arise from this process. Does your game design have any impossible situations in it, such as requiring you to have object A before obtaining object B, and object B before obtaining object A? Work out these issues.

Once you have a map, an object list, and a walk-through, you're ready to code your game!