CAP 203 -
Computer Animation III
Chapters 6 and 7 - The Game Begins with an Idea; The Game Improves through Iteration
This lesson discusses material from chapters 6 and 7 of The Art of Game Design. Objectives important to
- Stating the problem
- Brainstorming ideas
- Design Life Cycle
Chapter 6 begins with the advice that we must find an idea for our game. The author offers a story about meeting a juggler who performed tricks that the other jugglers watching him could not copy. Mr. Schell watched in admiration, and the unusual juggler revealed that his tricks were not learned by watching other jugglers, but by watching the world around him. This leads to lens 11, the Lens of Infinite Inspiration. Look at everything around you for inspiration, since it can come from anywhere:
- Don't look just at games, look at nature and at life.
- Think of experiences you have had or know about that you would like to put into the game.
- Think of a way to put the essence of that experience in the game.
The point that the author makes here is not to look at other games as your only inspiration sources. Copying another will not generate new and unique content. Like the juggler in the story, you should look outside your discipline for inspiration. If you see something that makes you think of something new to put in a game, that makes the time it took to find that thing worthwhile.
The text moves on to a standard tool in software design: stating the problem you are trying to solve. In this case, the general problem is applying an inspiration to your game. Stating a specific problem, or a series of them, will let you focus on what has to be done to create your design.
Mr. Schell recommends stating a design problem in terms of the tetrad of game elements (story, technology, aesthetics, and mechanics). This makes sense for a problem statement, because it leads to clearer statements and gives us a focus on how to resolve the problem.
In terms of the Star Trek example I used earlier, what is the problem the probe designer had to solve? Is it to make Picard (or someone like him) play a flute? Is it to take control of an alien species? No, it is neither of those, although both of those things became elements of that designer's solution. Think about it for a moment. (We'll come back to it.)
Lens 12, the Lens of the Problem Statement, asks us to think of our game as a solution to a problem which we must state.
- What are the problems (game objectives) that the game must solve?
- What is the true purpose of the game? (Our problem is to achieve that purpose.)
- Are we designing a solution to the problem, or are we wasting our time?
- Can the game be a solution to the problem?
- How can we tell if the problem has been resolved?
- Review the description of The Inner Light in the notes for Chapters 4 adn 5.
- Use the Lens of Problem Statement on this game problem. Make a problem statement that would have worked for the probe designer, using elements of the tetrad in the statement.
- Consider whether the problem could be solved with a computer game. Write a paragraph for or against it.
The text moves on to discuss using your subconscious mind to solve problems more creatively. Most people I have asked have had the experience of trying to solve a problem unsuccessfully, only to have a solution occur to them immediately after they stopped trying to solve it. Mr. Schell explains that this may be due to letting the subconscious mind have a try at it. Letting go of the problem can allow the subconscious to consider the problem, and can also allow the subconscious to communicate its solution to our conscious mind.
To enable better communication with your subconscious, Mr. Schell offers a list of tips:
- Pay attention - when your subconscious pops a creative idea into your conscious thoughts, consider the idea, and you may find that you will have more of them to consider
- Record you ideas - ideas tend to fade away like dreams if you don't make some notes about them, so make notes, draw sketches, or do what you need to do to have a record of the ideas
- Manage subconscious appetites - Mr. Schell makes reference to Maslow's hierarchy, which some of you will not know about. Abraham Maslow was a psychologist. He is famous for a theory that the needs people have can be arranged in a pyramid. If a need close to the base is not met, then needs higher in the pyramid will not be addressed. Note that creativity is in the top layer of the pyramid. The theory would say that creativity will not be addressed until the lower layer needs have been met first.
- Sleep - the subconscious needs rest as much as the rest of the mind, so lack of sleep can prevent interaction with it
- Don't push too hard - give the subconscious time to work on a problem
The text discusses brainstorming tips that apply as well to brainstorming with others as they do to brainstorming with yourself. In fact, that is another tip that should have been in the set above: don't expect your creative subconscious to solve all the problems. Sometimes you need the help of someone else's creativity.
In the list of brainstorming tips below, consider that each is an approach to address gathering new ideas. You might use any or all of them, but don't feel that you have to use every one every time. Also, consider whether a tip applies to your situation. If not, try another one.
- write down possible solutions - this is to avoid losing them, just like you don't want to lose ideas
- record your way - some people type, some write, some draw diagrams; do what works best for your situation
- sketch - if you need to draw something do it; if you don't like your drawing skill, practice them
- toys - use toys that can represent something in your problem; clay is a good universal toy that can represent anything you like (it is included in most of the Cranium games)
- change your perspective - once you know them, you can use various lenses in the book; the text also recommends thinking in different settings, doing different things, and just moving around
- immerse yourself - study the problem, look at how it has been solved by others, look at users who will have the problem, look at anything you can do to address the problem
- crack jokes - humor can relieve tension, and it can also suggest a different spin on the problem; don't make the humor a distraction from the brainstorming task, make it an addition or don't pursue it
- spare no expense - this tip is one to think over before using it; spend the money needed to get the job done, but don't spend if you don't have the money
- writing on the wall - lots of brainstorming is done with blackboards, whiteboards, greenboards, and sheets of paper on walls; this is particularly good for groups that are brainstorming, since people can see the notes better, and it can involve more people in the physical process
- space remembers - this means that you can recall a idea better if you recall it being written in a place in the room; use this to keep ideas in your mind and to get the big picture that comes from combining ideas
- write everything - when brainstorming, you write down all the ideas: evaluation of ideas comes later
- number your lists - personally, I don't like this one, because I believe that ordinal number should be used with things that follow a sequence, not with things that might be alternatives to each other (which is why this list is bulleted, not numbered); on the other hand, if numbers make list items more real for you, go for it
- mix and match categories - in this example, the text puts several ideas under the four categories of the gaming tetrad, then asks what would happen by selecting one item from each category; you can use other categories if your brainstorming session needs them
- talk to yourself - if writing down and numbering ideas help make them more real, hearing an idea aloud changes it, too; sometimes this is what you are doing when you talk a problem over with a friend, it is not important that they even hear it, it is important that you hear yourself explain it
- find a partner - as much as the techniques above will work whether you are alone or in a group, you should consider brainstorming both ways to get the benefits of a group as well as the benefits of brainstorming by yourself
Chapter 7 assumes that you have done the idea generating in chapter 6, and now you are ready to examine and select ideas to use. Oddly, Mr. Schell does not give you any advice on making the selection. Instead, he advises you to make a selection, make a plan based on your selection, and to proceed with a design based on that selection. He also advises you to show some common sense, and to be ready to give up the selected idea if it turns out to be unworkable in any of the eight filters he describes. This makes very good sense: you have to pick a direction to go anywhere, but you have to be willing to change direction if it turns out you were wrong.
An aphorism that has always comforted me is "no plan of battle ever survived first contact with the enemy". Be willing to change when you see that the plan is not working.
The eight filters promised above are eight ways to test whether your design works. The filters are the basis for lens 13, the Lens of the Eight Filters:
- artistic impulse - Is the designer happy with the completed design?
- demographics - Will/does the audience like the design enough?
- experience design - This label is not clear. The author wants to know whether the experience will stand up to the various lenses.
- innovation - Is there something new and exciting in the game that people will want?
- business and marketing - Can we produce, market, and sell enough copies of the game to make a good product?
- engineering - Is it possible to build this design? Are there hardware or software problems that we can't solve?
- social/community - Is there a community based goal, and does the design meet it? For instance, does it require a user base of a certain size to make it worth playing as an online multiplayer experience? Can we get enough committed users?
- playtesting - Does the game pass playtesting? How good do the playtesters think it is?
The chapter turns to what it calls the Rule of the Loop. The idea Mr. Schell is promoting is that you develop games in iterative steps. Most software is designed in an iterative cycle like this. It may be easier to consider it in terms of Quality Improvement, since one of their cycle models has nice, short names:
- Plan - plan your design, based on the requirements as you know them for this cycle; even if your requirements are correct, they will change as time passes
- Do - create the design, and build the system; for several cycle, you are building prototypes, not finished versions
- Check - examine the system in terms of the requirements (in this case, filters and lenses); make note of anything that does not pass inspection
- Act - enter the cycle again, correcting flaws found in the step above, or accept the system if there are no flaws; even if you accept the system, you should set a date to revisit it to determine new requirements in the future
Mr. Schell describes a similar cycle on page 82, although it does not look like a cycle. His steps include figuring out the risks of a design. Your design has not been produced at this point. Your risk evaluation consists of a listing all the things that could go wrong, based on your design choices. Your risk mitigation plan is a list of what you plan to do to correct the anticipated problems, if they come up. This takes us to lens 14, the Lens of Risk Mitigation:
- What could go wrong with our design?
- What are we going to do to prevent things from going wrong?
One of the things you do to prevent or correct things going wrong is to create a series of prototypes, working models, of the game. Each successive prototype should contain improvements based on problems that have been eliminated from previous prototypes. As such, you need to produce and test your prototypes as quickly as you can, adding quality in each cycle. Mr. Schell offers some advice about making prototypes:
- answer a question - each prototype should be created to provide an answer to a design question; state your question before building the prototype
- forget quality - for each prototype, make it good enough to answer the question it was built for, but don't waste time building in quality that it is not testing
- don't get attached - you will need to be able to discard each prototype in favor of the improved version that the prototype leads you to create
- prioritize prototypes - test the things that will have big effects first, especially those that other tests depend on
- prototype in parallel - when you are testing things that do not depend on one another, you can run separate prototypes at the same time, providing your testers are not the same groups
- doesn't have to be digital - some tests can be done without designing a new software version, such as art tests and rules tests
- pick a fast loop game engine - build prototype with a game engine that does not require you to recompile the entire game to test a change
- build the toy first - if the game is supposed to contain a toy, a piece that is fun to play with, build it first and test it first, since the rest of the game depends on it
The last bullet above has its own lens. Lens 15 is the Lens of the Toy. We must think of pieces of the game as toys, and ask whether they are good toys:
- Is the game fun to play with?
- Does the game make players want to play it before they know the story and the rules?
Chapter 7 ends with an example of looping through a design process with the completed looping model. Read through it to get an idea how this design loop went.