Introduction to Game Design, Prototyping, and Development (2015)
Part I: Game Design and Paper Prototyping
Chapter 7. Acting Like a Designer
Now that you’ve learned something about how to take a designer’s approach to thinking about and analyzing games, it’s time to look at the way that game designers go about crafting interactive experiences.
As mentioned in previous chapters, game design is a practice, and therefore, the more design you do, the better you will get at it. However, you also need to make sure that you’re starting with the kinds of actions that will yield you the greatest gains over time. That is the purpose of this chapter.
“Game design is 1% inspiration and 99% iteration.” —Chris Swain
Remember this saying from the first chapter? In this section, we explore it further.
The number one key to good design—the most important thing that you can learn from this book—is the process of iterative design shown in Figure 7.1. I have seen iterative design take some games that were initially terrible and make them great, and I’ve seen it at work across all forms of design from furniture to illustration to game design.
Figure 7.1 The iterative process of design1
1 Based on: Tracy Fullerton, Christopher Swain, and Steven Hoffman, Game Design Workshop: A Playcentric Approach to Creating Innovative Games (Burlington, MA: Morgan Kaufmann Publishers, 2008), 36.
The four phases of the iterative process of design are:
Analysis: The analysis phase is all about understanding where you are and what you want to accomplish. Understand the problem that you’re trying to solve (or opportunity that you’re trying to take advantage of) with your design. Understand the resources that you can bring to bear on the project. Understand the amount of time you have.
Design: Now that you have a clear idea where you are and what you’re trying to accomplish with your design, create a design that will solve the problem/opportunity with the resources you have available to you. This phase starts with brainstorming and ends with a concrete plan for implementation.
Implementation: You have the design in hand; now execute it. There’s an old adage: “It’s not a game until people are playing it.” The implementation phase is about getting from game design idea to playable prototype as quickly as possible. As you’ll see in the digital game tutorials later in this book, the earliest implementations are sometimes just moving a character around the screen—with no enemies or objectives—and seeing if the movement feels responsive and natural. It’s perfectly fine to implement just a small part of the game before testing; a test of just a portion of the game can often be more focused than a large-scale implementation could be. At the end of implementation, you’re ready to run a playtest.
Testing: Put people in front of your game and get their reactions. As your experience as a designer grows, you will get better at knowing how the various game mechanics you design will play out once the game is being tested, but even with years of experience, you will never know for sure. Testing will tell you. You always need to test early, when it’s still possible to make changes to the game and get it on the right track. Testing must also be done very frequently so that you can best understand the causes of the changes in player feedback that you witness.
Let’s look at each phase in more detail.
Every design seeks to solve a problem or take advantage of an opportunity, and before you can start to design, you need to have a clear idea of what that problem or opportunity is. You may be saying to yourself “I just want to make a great game,” which is true of most of us, but even with that as your initial statement, you can dig deeper and analyze your problem further.
To start, try asking yourself these questions:
1. For whom am I designing the game? Knowledge of your target audience can dictate many other elements of design. If you’re creating a game for children, it is more likely that their parents would let them use a mobile device than a computer connected to the Internet. If you’re designing a game for people who like strategy games, they will most likely be used to playing on a PC. If you’re designing a game for men, you should be aware that nearly 10% of Caucasian men are colorblind.
One thing that you should always be aware of is the danger of designing a game for yourself. If you just make a game for you, there’s a legitimate possibility that only you will want to play it. Researching your intended audience and understanding what makes them tick can tell you a tremendous amount about where your game design should go and help you to make your game better.
It’s also important to realize that what players think they want and what they will actually enjoy are sometimes two different things. In your research, it’s important to try to differentiate between your audience’s stated desires and the things that actually motivate and engage them.
2. What are my resources? Most of us don’t have a budget of tens of millions of dollars with which to employ a studio of 200 people to make a game over the span of two years. But you do have some time and talent and maybe even a group of talented friends as well. Being honest with yourself about your resources, strengths, and weaknesses can help shape your design. As an independent developer, your primary resources are talent and time. Money can help you purchase either of these through hiring contractors or purchasing assets, but especially if you’re working on a small indie game team, you want to make sure that the game you’re developing makes the best use of the resources on your team. When working on a game, you should treat your time and that of your team members as a precious resource; be sure to not waste it.
3. What prior art exists? This is the single question that is most often ignored by my students (often to their detriment). Prior art is the term used to describe existing games and other media that are related to yours in some way. No game comes from a vacuum, and as a designer, it is up to you to know not only the other games that have inspired you (which, of course, you know), but also what other games exist in the same space that came before or after your primary inspirations.
For instance, if you were to design a first-person shooter for console, of course you’d look at Titanfall and the Call of Duty: Modern Warfare series, but you would also need to be familiar with Halo (the first game that made the first-person shooter [FPS] genre work on a console when conventional wisdom held that it was impossible to do so), Marathon (Bungie’s game prior to Halo, which forms the basis for a lot of the design decisions and mythology in Halo), and the other FPSs that were precursors for Marathon.
You must research prior art because you need to be sure to know everything you can about the ways that other people have tried to approach the design problem that you’re tackling. Even if someone else had the exact same idea as you, it’s almost certain that they approached it in a different way, and from their successes and mistakes, you can learn to make your game better.
4. What is the fastest path to a playable game that demonstrates what I want to test? Though often-overlooked, this question is critical for obvious reasons. You only have 24 hours available to you each day, and if you’re at all like me, only a small fraction can be devoted to game development. Knowing this, it is critical that your time is used as efficiently as possible if you want to get your game made. Think about the core mechanic of the game you want to create—the thing that the player does most throughout the game (for example, in Super Mario Bros., the core mechanic is jumping)—and make sure that you design and test that first. From that, you’ll know whether it’s worth it to make more of the game. Art, music, and all other aesthetic elements are of course critical to your final game, but at this point, you must focus on the mechanics—on gameplay—and get that working first. That is your goal as a game designer.
Of course, you’ll have many more questions of your own to add to these, but regardless of the game you’re making, these four are critical to keep in mind during the analysis phase.
A large portion of this book is about design, but in this section, I’m going to focus on the attitude of a professional designer. (Chapter 14, “The Digital Game Industry,” covers this in more detail.)
Design isn’t about getting your way, it’s not about being a great genius or auteur who is followed by everyone else on the team, and it’s not even about doing a great job of communicating your vision to the rest of the team. Design isn’t about you; it is about the project. Working as a game designer is about collaborating with the rest of the team, compromising, and above all listening.
In the first few pages of his book The Art of Game Design, Jesse Schell states that listening is the most important skill that a game designer can have, and I emphatically agree. Schell lists five kinds of listening that you need to develop:2
2 Jesse Schell, The Art of Game Design: A Book of Lenses (Boca Raton, FL: CRC Press, 2008), 4-6.
Listen to your audience: Whom do you want to play your game? Whom do you want to buy your game? As mentioned previously, these are questions that you must answer, and after you have answered them, you need to listen to the kinds of experiences that your audience wants to have. The whole purpose of the iterative process of design is to make something, throw it out to playtesters, and get their feedback. Make sure you’re listening to that feedback when they give it, even (especially!) if it’s not what you expected or what you want to hear.
Listen to your team: On most game projects, you’ll be working with a team of other talented people. Your job as the designer is to listen to all of their thoughts and ideas and work with them to unearth the ideas that will create the best game for your audience. If you surround yourself with people who are willing to speak up when they disagree with you, you will have a better game. Your team should not be contentious; rather, it should be a team of creative individuals who all care passionately about the game.
Listen to your client: A lot of the time, as a professional game designer, you’ll be working for a client (boss, committee, etc.), and you’re going to need to take their input. They aren’t usually going to be expert game designers—that’s why they hired you—but they will have specific needs that you must meet. At the end of the day, it will be your job to listen to them at several levels: what they tell you they want, what they think they want but don’t say out loud, and even what they really want deep down but might not even admit to themselves. With clients, you need to listen very carefully in order to leave them with an excellent impression of working with you and an excellent game.
Listen to your game: Sometimes certain elements of a game design fit together like a hand in a glove, and sometimes, it’s more like a wolverine in a Christmas stocking (p.s.: bad idea). As the designer, you’ll be closest to the gameplay, and it will be up to you to understand the game from a gestalt (holistic) perspective. Even if a certain aspect of a game is brilliant design, it might not fit well with the rest. Don’t worry; if it is a great bit of design, there’s a good chance you can find a place for it in another game... you’ll make a lot of games in your career.
Listen to yourself: There are several important aspects of listening to yourself:
Listen to your gut: Sometimes you’ll get a gut feeling about something, and sometimes these will be wrong, but other times they’ll be very right. When your gut tells you something about a design, give it a try. It may be that some part of your mind figured out the answer before your conscious mind had a chance to.
Listen to your health: Take care of yourself and stay healthy. Seriously. There is a tremendous amount of research out there showing that pulling all-nighters, being stressed, and not exercising have a tremendously negative effect on your ability to do creative work. To be the best designer you can be, you need to be healthy and well rested. Don’t let yourself get caught in a cycle of one crisis after another that you try to solve by working crazy hours into the night.
Listen to how you sound to other people: When you say things to your colleagues, peers, friends, family, and acquaintances, take a moment every once in a while to really listen to how you sound. I don’t want you to get a complex about it or anything, but I do want you to listen to yourself and ask these questions: Do I sound respectful? Do I sound like I care about the other person? Do I sound like I care about the project? All other things being equal, the people who do best in life are those who consistently demonstrate respect and care for others. I’ve known some really talented people who didn’t get this; they did all right initially, but without fail, their careers sputtered and failed as fewer and fewer people wanted to work with them. Game design is a community of shared respect.
There are, of course, many more aspects to acting like a professional designer than just listening, but Schell and I agree that it is one of the most important. The rest of this book covers more nuts-and-bolts aspects of being a designer, but all of it must be approached with the humble, healthy, collaborative, and creative attitude I’ve outlined here.
The latter two-thirds of this book are about digital implementation, but it’s important to realize that the key to effective implementation in the process of iterative design is to get from design to playtest in the most efficient way possible. If you’re testing the jump of a character in a platform game like Super Mario Bros. or Mega Man, you will need to make a digital prototype. However, if you’re testing a graphical user interface (GUI) menu system, you don’t need to build a fully working digital version; it’s perfectly fine to print out images of the various states of the menu and ask testers to navigate through them with you acting as the computer (and swapping the printed images by hand).
For instance, the diagram in Figure 7.2 shows some different screens from a GUI mockup of an options menu. Each playtester would only be shown one screen at a time, starting with #1, the Options Menu. While shown screen #1, the playtester would be instructed to “Press the selections you would make to turn the subtitles on.” (You would encourage the playtesters to actually touch the paper as if they were touching a touchscreen.)
Figure 7.2 A simple paper GUI prototype.
Some playtesters might press the Video button, whereas others might press Audio (and a few might press Game). Once the user made a selection, the #1 sheet of paper would be replaced with the menu of their selection (for example, #2 Video Options). Then, presumably, the playtester would press the Subtitles: on / OFF button to switch the subtitles on, which would cause #2 to be replaced with #4 Video Options.
One important thing to note here is that subtitles are available to be changed on both the video and sound options screens. For testing this works well because regardless of which of the two options are chosen by the player (Video or Audio), you can then subsequently test whether the “on / OFF” capitalization clearly conveys that the subtitles are currently turned off.
Paper prototyping is covered further in Chapter 9, “Paper Prototyping.”
As you’ve just seen, paper prototyping can be the fastest way to get to playtesting when you’re in the early phases of a project. Chapter 10, “Game Testing,” covers several different aspects of testing. The key thing to keep in mind now is that regardless of what you think about your game, you won’t really know anything until a player (who is not you) has tested it and given you feedback. The more people who play your game, the more legitimate that feedback will be.
In my Game Design Workshop class at the University of Southern California, each of our board game projects took place over four weeks of labs. In the first lab, the students were placed in teams and given time to brainstorm their game ideas. Every subsequent lab was devoted entirely to playtesting the current version of their game. By the end of a 4-week project, each student team had completed nearly 6 hours of in-class playtesting and had drastically improved their designs as a result. The best thing you can do for your designs is to have people playing them and giving you feedback as often as possible. And, for the sake of all that is good, please write down what your playtesters tell you. If you forget their feedback, the playtest is a waste.
It is also important to make sure that your playtesters are giving you honest feedback. Sometimes, playtesters will give you overly positive feedback because they don’t want to hurt your feelings. In The Art of Game Design, Jesse Schell recommends telling your testers something like “I need your help. This game has some real problems, but we’re not sure what they are. Please, if there is anything at all you don’t like about this game, it will be a great help to me if you let me know”3 to encourage them to be honest with you about flaws they see in the game.
3 Jesse Schell, The Art of Game Design: A Book of Lenses (Boca Raton, FL: CRC Press, 2008), 401.
After you have run your playtest, you should have a lot of feedback written down from your testers. Now it’s time to analyze again. What did the players like? What didn’t they like? Were there places in the game that were overly easy or difficult? Was it interesting and engaging?
From all of these questions, you will be able to determine a new problem to solve with your design. For instance, you might decide that you need to make the second half of the first level more exciting, or you may decide that the game has too much randomness.
After each playtest session, I review the feedback from my players and fill out the chart shown in Figure 7.3 with a line for each issue on which players have given feedback.
Figure 7.3 One line from a playtest analysis chart
This is only a single sample line from the chart that could be dozens or hundreds of lines long. The first thing I do when creating this chart is to collect similar feedback together. You need to make sure that all testers are talking about the same part of the game, so you should have some sort of system for marking where they were in the game when they made the comment (e.g., Boss1). Then, place all similar comments in the same Feedback cell. Next, analyze these comments as a whole and attempt to understand what is causing the players to feel this way. Then decide how serious you think this underlying issue is and if it is an issue of Medium or High severity, propose a solution that might fix the problem. After you have all of your proposed solutions it’s time to take them into the design phase and continue the cycle of iterative design. Each subsequent iteration of the design should include some changes, but not all of those you have proposed. The most important thing is to get to the next playtest quickly and determine whether the solutions that you have implemented solved the problems they were meant to solve.
In his book The Medici Effect,4 author Frans Johansson writes about two kinds of innovation: incremental and intersectional. Incremental innovation is making something a little better in a predictable way. The progressive improvement of Pentium processors by Intel throughout the 1990s was incremental innovation; each year, a new Pentium processor was released that was larger and had more transistors than the previous generation. Incremental innovation is reliable and predictable, and if you’re looking for investment capital, it’s easy to convince investors that it will work. However, as its name would suggest, incremental innovation can never make great leaps forward precisely because it is exactly what everyone expects.
4 Frans Johansson, The Medici Effect: What Elephants and Epidemics Can Teach Us about Innovation (Boston, MA: Harvard Business School Press, 2006).
The other kind of innovation is intersectional innovation. Intersectional innovation occurs at the collision of two disparate ideas, and it is where a lot of the greatest ideas can come from. However, because the results of intersectional innovation are novel and often unpredictable, it is more difficult to convince others of the merit of the ideas generated through intersectional innovation.
In 1991, Richard Garfield was trying to find a publisher for his game RoboRally. One of the people he approached was Peter Adkison, founder and CEO of Wizards of the Coast. Though Adkison liked the game, he didn’t feel that Wizards had enough resources to publish a game likeRoboRally that had so many different pieces, but he mentioned to Richard that they had been looking for a new game that could be played with very little equipment and resolve in 15 minutes.
Richard intersected this idea of a fast-play, low-equipment card game with another idea that had been kicking around in his head for a while of playing a card game with cards that were collected like baseball cards, and in 1993, Wizards of the Coast released Magic: The Gathering, which started the entire genre of collectible card games (CCGs).
Though Garfield had been thinking about a card game that was collectible for a little while before his meeting with Adkison, it was the intersection of that idea with Adkison’s specific needs for a fast-play game that gave birth to the collectible card game genre, and nearly all CCGs that have come since have the same basic formula: a basic rule set, cards that have rules on them which override the basic rules, deck construction, and fast play.
The brainstorming procedure described in the next section takes advantage of both kinds of innovation to help you create better ideas.
Brainstorming and Ideation
“The best way to have a good idea is to have a lot of ideas and throw out all the bad ones.” —Linus Pauling, sole winner of both the Nobel Prize in Chemistry and the Nobel Peace Prize
Just like anyone else, not all of your ideas are going to be great ones, so the best you can do is to generate a lot of ideas and then sift through them later to find the good ones. This is the whole concept behind brainstorming. This section covers a specific brainstorming process that I have seen work very well for many people, especially in groups of creative individuals.
For this process, you will need: a whiteboard, a stack of 3x5 note cards (or just a bunch of slips of paper), a notebook for jotting down ideas, and various whiteboard markers, pens, pencils, and so on. The process works best with five to ten people, but you can alter it to work for fewer people by repeating tasks, and I’ve modified it in the past to work for a classroom of 65 students. (For instance, if you’re by yourself, and it says that each person should do something once, just do it a few times until you’re satisfied.)
Step 1: Expansion Phase
Let’s say that you are just starting a 48-hour game jam with a few friends. The theme of the game jam is uroboros (the symbol of a snake eating its own tail symbol). This was the theme of the Global Game Jam in 2012. Not much to go on, right? So, you start with the kind of brainstorming that you learned in grade school. Draw an uroboros in the middle of a white board, draw a circle around it, and start free associating. Don’t worry about what you’re writing at this point—don’t censor anything—just write whatever comes to mind as you go. Figure 7.4 shows an example.
Figure 7.4 The expansion phase of brainstorming a game for uroboros
Beware the Tyranny of the Marker If you have more people taking part in the brainstorm than you have whiteboard markers, you should always be careful to make sure that everyone is being heard. Creative people come in all types, and the most introverted person on your team may have some of the best ideas. If you’re managing a creative team, try to make sure that the more introverted members of your team are the ones holding the whiteboard markers. They may be willing to write something on the board that they aren’t willing to say out loud.
When you’re done, take a picture of the whiteboard. I have hundreds of pictures of whiteboards in my phone, and I’ve never regretted taking one. Once you have captured it, email it out to everyone in the group.
Step 2: Collection Phase
Collect all of the nodes of the brainstorming expansion phase and write them each down on one 3x5 note card. These are called idea cards (see Figure 7.5).
Figure 7.5 Uroboros idea cards
A Quick Aside and a Bad Joke or Two
Let’s start with the bad joke:
There are two lithium atoms walking along, and one says to the other, “Phil, I think I lost an electron back there.” So Phil says, “Really Jason, are you sure?” And Jason replies, “Yeah, I’m positive!”
Why was six afraid of seven?
Because seven eight nine!
Sorry, I know. They’re terrible.
You may be wondering why I’m subjecting you to bad jokes. I’m doing so because jokes like these work on the same principle as intersectional innovation. Humans are creatures that love to think and combine weird ideas. Jokes are funny because they lead our minds down one track and then throw a completely different concept into the mix. Your mind makes the link between the two disparate, seemingly unrelated concepts, and the joy that this mental link causes comes across as humor.
The same thing happens when you intersect two ideas, and this is why it’s so pleasurable for us to get the eureka moment of intersecting two common ideas into a new uncommon one.
Step 3: Collision Phase
Here’s where the fun begins. Shuffle all the idea cards that you’ve made and deal two to each person in the group. Each person takes their two cards up to the whiteboard and reveals them to everyone. Then the group collectively comes up with three different game ideas inspired by the collision of the two cards. (If the two cards either are too closely paired or just don’t work together at all, it’s okay to skip them.) Figure 7.6 presents a couple of examples.
Figure 7.6 Uroboros idea collisions
Now, the examples in Figure 7.6 are just the first ideas that came to me, as they should be for you. We’re still not doing a lot of filtering in this phase. Write down all of the different ideas that you come up with in this phase.
Step 4: Rating Phase
Now that you have a lot of ideas, it’s time to start culling them. Each person should write on the whiteboard the two ideas from Step 3 that she thinks have the most merit.
Once everyone has done this, then all people should simultaneously put a tick mark next to the three ideas written on the board that they like the most. You should end up with some ideas with lots of tick marks and some with very few.
Step 5: Discussion
Now that you have lots of ideas, it’s time to boil them down and combine them into good ideas. With dozens of different crazy ideas to choose from, you should be able to find a couple that sound really good and to combine them into a great starting point for your design.
Changing Your Mind
Changing your mind is a key part of the iterative design process. As you work through the different iterations of your game, you will inevitably make changes to your design.
As shown in Figure 7.7, no one ever has an idea and turns it directly into a game with no changes at all (as shown in the top half of the figure), or if anyone ever does, it’s almost certain to be a terrible game. In reality, what happens is a lot more like the bottom half of the figure. You have an idea and make an initial prototype. The results of that prototype give you some ideas, and you make another prototype. Maybe that one didn’t work out so well, so you backtrack and make another. You continue this process until you’ve forged your idea over time into a great game, and if you stick to the process and engage in listening and creative collaboration, it’ll be a much better game than the original one you set out to make.
Figure 7.7 The reality of game design
As the Project Progresses, You’re More Locked In
The process just described is fantastic for small projects or the preproduction phase of any project, but after you have a lot of people who have put a lot of time into something, it’s much more difficult and expensive to change your mind. A standard professional game is developed in several distinct phases:
Preproduction: This is the phase covered by most of this book. In the preproduction phase, you’re experimenting with different prototypes, and you’re trying to find something that is demonstrably enjoyable and engaging. During preproduction, it is perfectly fine to change your mind about things. On a large industry project, there would be between 4 and 16 people on the project during preproduction, and at the end of this phase, you typically would want to have created a vertical slice, which is a short, five-minute section of your game at the same level of quality as the final game. This is like a demo level for the executives to play and decide whether or not to move the game into production. Other sections of your game should be designed at this point, but for the most part, they won’t be implemented.
Production: In the industry, when you enter the production phase of a game, your team will grow considerably in size. On a large console game title, there could be well over 100 people working on the game at this point, many of whom might not be in the same city or even country as you. During production, all of the systems design (i.e., the game mechanics) need to be locked down very early, and other design aspects (like level design, tuning character abilities, and such) will be progressively locked down throughout production as the team finalizes them. From an aesthetics side, the production phase is when all of the modeling, texturing, animation, and other implementation of aesthetic elements take place. The production phase expands the high quality of the vertical slice out across the rest of the project.
Alpha: Once you’ve reached the alpha phase of your game, all the functionality and game mechanics should be 100% locked down. At this point, there are no more changes to the systems design of the game, and the only changes you should make to things like level design will be in response to specific problems discovered through playtesting. This is the phase where playtesting transitions to quality assurance (QA) testing in an effort to find problems and bugs (See Chapter 10 for more information). When you start alpha, there may still be some bugs (i.e., errors in programming), but you should have identified all of them and know how to reproduce them.
Beta: Once you’re in beta, the game should be effectively done. At beta, you should have fixed any bugs that had the potential to crash your game, and the only remaining bugs should be minor. The purpose of the beta period is to find and fix the last of the bugs in your game. From the art side, this means making sure that every texture is mapped properly, that every bit of text is spelled properly, etc. You are not making any changes in the beta phase, just fixing any final problems that you can find.
Gold: When your project goes gold, it is ready to ship. This is a holdover from the days of CD-ROM production when the master for all the CDs was actually a disc made of gold that the CDs were pressed onto. Now that even disc-based console games have updates delivered online, gold has lost some of its finality, but gold is still the name for the game being ship-ready.
Post-release: With the ubiquity of the Internet today, all games that aren’t on cartridges (e.g., Nintendo DS games and some 3DS games are delivered on cartridges) can be tuned5 after they’re released. The post-release period can also be used for development of downloadable content (DLC). Because DLC is often composed of new missions and levels, each DLC release goes through the same phases of development as the larger game (though on a much smaller scale): preproduction, production, alpha, beta, and gold.
5 Tuning is the term for the final stages of adjustments to game mechanics where only tiny changes are made.
One critical concept you must understand to act like a game designer is how to scope your work. Scoping is the process of limiting the design to what can reasonably be accomplished with the time and resources that you have available, and overscoping is the number one killer of amateur game projects.
I’ll say that again: Overscoping is the number one killer of game projects.
Most of the games you see and play took dozens of people months and months of full-time work to create. Some large console games cost nearly $500 million to develop. The teams on these projects are all composed of fantastic people who have been doing their jobs well for years.
I’m not trying to discourage you, but I am trying to convince you to think small. For your own sake, don’t try to make the next Titanfall or World of Warcraft or any other large, famous game you can think of. Instead find a small, really cool core mechanic and explore it deeply in a small game.
If you want some fantastic inspiration, check out the games that are nominated each year at the IndieCade Game Festival. IndieCade is the premier festival for independent games of various sizes, and I think it represents the vanguard of where independent games are going.6 If you take a look at their website (http://indiecade.com), you can see tons of fantastic games, each of which pushes the boundaries of gaming in a cool new way. Each of these was someone’s passion project, and many of them took hundreds or thousands of hours of effort for a small team or an individual to create.
6 For purposes of full disclosure, since 2013, I have served as IndieCade’s Chair for Education and Advancement, and I am very proud to belong to such a great organization.
As you look at them, you might be surprised by how small in scale they are. That’s okay. Even though the scope of these games is pretty small, they are still fantastic enough to be considered for an IndieCade award.
As you progress in your career, you may go on to make massive games like Starcraft or Grand Theft Auto, but remember that everyone got their start somewhere. Before George Lucas made Star Wars, he was just a talented kid in the film program at the University of Southern California. In fact, even when he made Star Wars, he scoped it down so perfectly that he was able to make one of the highest-grossing movies of all time for only $11 million. (It went on to make over $775 million at the box office and many, many times that in toy sales, home movie sales, and so on.)
So for now, think small. Come up with something that you know you can make in a short amount of time and make it. If you make something great, you can always add on to it later.
The tools and theories you’ve read in this chapter are the kinds of things that I teach to my students and use in my personal design. I have seen the brainstorming strategies that I listed work in both big and small groups to create interesting, off-the-wall, yet implementable ideas, and every experience that I have had in the industry and academia has led me to feel that iterative design, rapid prototyping, and proper scoping are the key processes that you can implement to improve your designs. I cannot more highly recommend them to you.