I'm Morgan McGuire (@CasualEffects). I've been working on computer graphics and games for 20 years at great places including NVIDIA, University of Waterloo, Williams College, Brown University, Roblox, Unity, and Activision.

See my home page for a full index of my blog posts, books, research, and projects.

Wednesday, January 28, 2015

Learning to Create Games

Why should you learn about game development? How and where should you learn? Most important, what do you need to learn? This article captures my current thoughts for those hoping to enter the industry, new indie developers, and games students as I refine my Creating Games course for next semester at Williams College.

Hive
There are many ways to think about games and inspire learning. One that excites me is the theme of the course: how quantifiable design elements give rise to meaningful player experiences. I assume that everyone is going to primarily make video games, but should learn about game design through board games.


I emphasize in this article and my course a combination of elegant strategic games, such as Hive and Dominion, and those with emotional impact, such as Gone Home and This War of Mine. The combination showcases games as an artistic medium, which is why I teach in both the studio art and computer science departments. While we also must study visual art and computer programming as tools for creating games, I think people interested in games should begin with the computational art of game design. As game developers, we create machines from mechanics, and these machines then create experiences with the players.



The Contents of this Article

  • Why and How to Learn
    • Understanding Games
    • Creating Games
    • The Burden of Dreams
    • A Supportive Community
  • What to Learn
    • Areas of Experience
    • Design Theories
    • State, Computation, and Abstraction
    • Some Game Design Skills
    • Process
  • A Syllabus
    • Games to Make
    • Games to Play
    • Further Online Reading

Why and How To Learn

Understanding Games

Monaco
Everyone can benefit from understanding and playing games well. Those activities develop planning, logical thinking, a good grasp of probability, and analysis of relationship graphs. Those are empowering life skills on par with calculus, reading great novels, and cooking.

Games are emerging as a dominant medium of our time. Nearly everyone plays board games (whether Poker, Agricola, or Go) and about half the population plays video games (whether Words with Friends or Halo). They are the only successful interactive art form and can be lighthearted entertainment or complex fine art. If you're not convinced, consider some recent (US-specific) indicators of the significance of games as a topic worth learning:

Creating Games

The Longest Journey
Although I recommend that everyone seek to understand games, creating games is not something everyone should pursue. In fact, you should probably only undertake it if you're sufficiently obsessed with games that you're willing to sacrifice a lot to engage them more deeply.

In this article, I'm using "games" to refer to aspirations of commercial-quality efforts such as Ticket to Ride and Kerbal Space Program. Everyone should make little ad hoc games as a natural process of play and incentivizing actions, and a Tetris clone or Monopoly modification is a fine weekend project. But making even moderately sophisticated, polished games that other people want to play is a serious endeavor at the level of taking on a new sport, writing a novel, or pursuing a major. Perseverance, skill, and talent are all required. Here are some reasons that you shouldn't attempt it, at least if you have the wrong goal in mind or underestimate the task.

Waking Mars
Games are not a lucrative or easy career. Game development doesn't make much money even for most of the people who are critically successful at it, compared to alternatives that could be pursued with the same skills. The amount of work for the infrequent gain of creating something worthwhile is high compared to even other creative fields.

Video game programmers are paid below market rate for their technical skills, although they make a good salary compared to non-programmers outside the industry. A few well-known developers drive exotic cars, but so do the first employees at Google, Apple, Microsoft, and Facebook, and for the same reason: they were in the right place at the right time.

Game artists generally are paid significantly less than programmers. They probably make less than graphic designers and 3D modelers outside of the entertainment industry, but the market for art skills is always weak and capricious. Management, audio, and other roles vary.

The hours are quite long in the industry whether you're independent or at a major studio, the perks beyond freedom of expression are few, and sometimes the fans turn on you in ugly ways. So few people make a living designing board games that it isn't worth analysis.

Monument Valley
Games are not an externally-rewarded art medium. Games are art, although it is exceptionally hard to produce good art as a game. That's mostly because it is hard to produce any game to begin with, and then if you do make a game, you often have to make significant artistic compromises to bring it to market. It is even harder to receive non-commercial funding for games than for other artistic endeavors; there aren't many painting grants and fellowships, but there are more than there are game art opportunities.

If you succeed at producing an artistically interesting game, it is hard to get serious critical notice or recognition. Some people deservedly find financial success and critical acclaim with expressive games. Monument Valley, Gone Home, Limbo, Journey, and Braid are a few commonly-cited examples. Their developers deserve everything that they've received, but keep in mind that those are the fortunate exceptions. Most great art games are known in the community but not such big hits outside of it, for example, The Stanley Parable.

There's only one sure path for achievement in artistically expressive games: Pursue your art for your own satisfaction instead of external validation.

Creating a game is very different from playing one. My students are often surprised by the challenge of creation despite being experienced players. Maybe that shouldn't be so surprising, though: I can listen to hundreds of violin concertos, but couldn't play even a few notes of one myself. That's not just about skill.

The Stanley Parable
It is true that some good, releasable games can be created in a few weeks by a single person with a lot of experience. However, most commercial video games reflect thousands of person-years of development. They are an inherently ensemble art and a major commitment.

The challenge of creating games isn't the only pitfall of attempting to make them. Regardless of whether you succeed, there's no returning to your previous level of ignorance and taste. Beware that my students also find that after studying games that they often no longer enjoy playing many of them--they see the flaws and strategies to plainly, and now have the burden of critical taste.

Masterful games are the those where you see what is happening mechanically, yet value the experience even more because of that appreciation...and are sometimes pleasantly surprised by being led astray by what you thought the mechanic was (Naughty Dog's games excel at this). That is, you see the artistry of the design and appreciate it at that level as well.
XCOM: Enemy Unknown / Enemy Within

So, if you learn about how games are made, you're likely to both fail to make them yourself and become unable to enjoy playing games made by others. Now that I've argued that most people are not prepared to really try game creation, I'll admit:
If you want to creating meaningful experiences through interaction, creating games is the best job or hobby in the world.
Creating games is immensely satisfying even if you're really inexperienced and untalented at it when you begin, as long as you're sufficiently committed. If you read this far in this article and want to continue, then maybe you really are sufficiently interested to attempt game creation. Welcome to the club. I'll spend the rest of this article assuming that you're invested and sharing some advice and experience to help you succeed.

The Burden of Dreams

Quotation from Ira Glass
When you first begin to make games, they're mostly going to be terrible. That's normal, and common to all forms of creative work. It is a good sign if you see many flaws in your work (even though you're proud of having made something!). It means that you have good taste and a drive to make your ability at synthesis match the quality of your analysis. Ira Glass explained this perfectly in the context of the craft of storytelling. The image on the right is a quote from his famous interview.

Keep up the hard work when you reach the point of finishing the construction of a game that you then don't like. Completing even a bad game project is an achievement. Make another hundred and one might rise to mediocre. Some day, you're going to do something that you will think is barely acceptable, but someone else will start raving about. That's how you know that you're doing really well. You're likely in trouble only if you believe that everything that you make is good from the start.

When you begin making games, you will spend more time playing at making games than doing productive work. This is natural and necessary. Humans learn almost everything by first pretending to complete the task and mimicking experts. There are cargo cult cases of mistaking the symptom for the cause where you can go astray. If you're spending your time making websites for your game company and picking out the right game developer T-shirt, then you're not on the right path.

You're on the right path if you're mimicking the productive activities of a game developer such as debating mechanics, modifying code, and critiquing other games, even if you're ineffectual at first. One day you find that you're actually doing it. By analogy, think about babies pretending to talk, small children pretending to read, and high school students mimicking academic tasks...at some point, they transitioned seamlessly from appearing to have these skills to actually having them.

A Supportive Community

Games are a craft medium. The best way to learn how to create games is to create games. Don't study something else for years to build up your skills first. It is like any other craft. You need to dive in, make mistakes, study some good examples in light of your mistakes, and then try again. It helps to have a mentor and a cohort for this process. They will share their experience so that you can at least make new mistakes instead of common ones, and they will provide both feedback and support.

Portal grew out of a student final project 
I recommend that you take a game development course if you are already at a school that offers one. However, beyond that course, I don't think it is necessary or even advisable to attend a game school or major in a games program. I know some successful developers who got their starts in game programs at schools such as CMU, RPI, UC Santa Cruz, SMU, and Full Sail. But I know many more who first excelled as computer science, literature, and fine arts majors and then brought deep knowledge of those skills to game development.

What you need to find success are a community, a set of skills, and a portfolio, not a specific set of games courses on your transcript.

Grim Fandango
If you aren't in school, or a school with games courses, then you're still in the mainstream of the community learning to make games. Many people of all ages who are learning games outside of their primary activity are doing so without a formal program. Many professional developers entered games from careers in other fields. Combined with the academics and professional developers, they form a large online game creation community.

The game creation community is welcoming and supportive, and it has grown substantially in the last decade. Perhaps from the combination of social media for collaboration, widespread excitement about games as a medium, the rise of casual gaming as part of a lifestyle through web and mobile platforms, and the emergence of inexpensive hardware and software computing tools.

Similar to those in film and music but with broader participation, there's now a vibrant "indie" game scene through which many explore the medium and build their careers. It spans small professional developers, artists using games as a medium, hobbyist game creators, and students.

Some current social media hubs for the game-learning and indie game community are:
The community frequently organizes around "game jams," both in person and online. These are intense creative sessions that build skills, connections, and camaraderie. Three popular jams are:
...and the practice has become so popular that there at least one web-based game jam nearly every weekend.

What to Learn

Some fundamental, high-level skills of a game developer are listed below, with examples to help you decode the technical terms. In the following sections I explain the game design, computer science, and economics terms and how to acquire these skills more fully in the following sections.

Recognize mechanics in an existing game, and separate them from the content.
The "wolves" in Age of Empires have a similar role to the "pawns" in Chess for the opening game...they prevent a direct rush attack and reward a positional strategy. See Koster's discussion of recognizing mechanics.
Abstract and form computational models of systems in the real world.
Diet affects short-term energy, long-term health, social status, ethical status, future food demand, and mental satisfaction. Let's model each of those as scalars for a given meal or ingredient, and purchasing food as trading income for a vector of these properties, where not all possible vectors are available in each store.  
Apply mechanics to those computational models to make them into games.
Let's make fire trucks a cool-down ability that can be deployed instantly to cancel fires, but deploying them creates vulnerability for a fixed period of time and thus requires careful planning or adaptive tactics for handling the second fire.
Map mechanics to algorithms and data structures (in video games).
We'll use a pointer-based graph to implement the skill-learning chains and compute a minimum spanning tree to identify when a character has enough skills to unlock the boss battle.
Analyze mechanics in the absence of experimentation, for coarse balance and to predict strategies
This new card offers two unrestricted actions, two draws, and one attack. That corresponds to an expected two victory points per play, so we should probably assign it a price similar to that of the Vindicator card. 
Perform qualitative and quantitative experimental evaluation.
Many people complained during the playtest that arrows are too powerful, but analysis shows that these complaints correlated highly with players who bought new weapons instead of plate mail to defend against ranged attacks. 
Add and tune mechanics to adjust the set of viable strategies.
Players are grinding and then hoarding treasure. That makes the game too repetitive early on. In the mid game it is too hard because players who don't buy equipment are underpowered. The game is then too easy for them at the end because they can go all-in on exactly the right gear for the final encounter. What if we continuously inflate prices throughout the game? That will encourage players to buy gear immediately and will discourage hoarding treasure.
Master role-specific tools and workflows (such as programming, asset creation, and team management)
The examples are numerous: using a C++ profiler, linking to new libraries, using non-destructive edits in Photoshop, working with asset management systems, handling human dependencies in a schedule, bringing a design team to consensus, etc.

Areas of Experience

Super Smash Brothers
There are three broad areas of experience specific to games: Technical elements (creating board game pieces, programming, mastering software), game rules, and content (visual art, music, stories, 3D models, layout, etc.) Each has its own "design" area that then blends into implementation through process. That is, there are three design fields to study for games, each providing theory for its own craft:
  • software design (sometimes called architecture)
  • game [rule] design (the "rule" is conventionally dropped)
  • art [and music, story, character...] direction
I focus here mostly on the first two, software and rules. Other people are better at teaching content creation topics such as visual art and writing. There's less need for new and specific educational material in those fields as well. They have been developing for thousands of years instead of the mere decades of modern software and game design.

Toca House
The distinction between software design for games and computer game design is important. They require different techniques and on a large game are created by different people.

Computer games have "rules" at two different scales of rigor and abstraction. One is the set of rules for the player. These are structured by game design.  The other is the set of rules for the computer, which micro-manage the player's rules.

The second set of rules in a computer game is one structured by software design. It is always much larger than the set of rules for the player.

For example, I can fully explain Tetris in about 500 English words. Yet, I need about ten times as many words in a programming language to express the rules to a computer. That's largely because computer programming is more detailed. Computers lack common sense and high-level concepts like rotation and obstruction. We also expect a computer game's code to handle graphics and sound, which aren't in the rules of most games.

Design Theories

The Elder Scrolls V: Skyrim
Software design, game design, and art design each admit a formal design theory and have a technical jargon for it. The elements of these design theories are primarily data structures and algorithms in computer science, mechanics in game design, and art principles for content.

Some design elements are readily quantified, for example hash tables for software, bidding mechanics for game design, and local contrast for visual art. Some are more abstract relationships for which formalizing a definition of the idea is tricky, and everyone seems to evolve their own intuition for them through experience.

Eminent Domain
There have been several efforts to categorize the more abstract elements of design theories, to support education and critical analysis. For software and game design, some well-regarded books on this topic are Design Patterns, Patterns in Game Design, and Game Programming Patterns (A Book of Lenses is in this vein, but doesn't go so far.)

I'm not in the educational mainstream on classifying design principles--I think that these categorization schemes are useful to the authors and might be useful to some experienced designers, but are largely misguided attempt to reduce creative and experience-born elements of design to a metagame and jargon. I find case studies and masterwork exemplars more valuable. I recommend a starter games canon at the end of this article, along with a syllabus of exercises for moving through important previous works.

State, Computation, and Abstraction

SimCity
Among the game development skills in my initial short list, I believe that computational modeling is the key skill. It is not something that many people learn in high school or even college unless they pursue a science or economics degree, and it is absolutely essential for game design (and programming; pure artists can probably get by).

Computational modeling happens to be a skill that is taught really well in computer science courses, which is why everyone should probably take a computer science course even if they don't plan to program. Chris Granger's "Coding is not the new literacy" blog post unpacks that wisdom very clearly. My introductory games course is offered by the computer science department. That's because computer science methodology is essential to design, not because we sometimes make computer games using programming in class.

Specifically, the three core elements of computer science are also those of game design. They are categories of mental and mathematical tools for modeling systems of the real world in a way that is objective, subject to analysis, and has manageable complexity:
  • State represents nouns/objects/things. Variables, constants, meta-state (types), properties for restricting and extending state, and a host of data structures are the tools that computer science provides for state.
  • Computation represents verbs/actions/rules can be applied to the nouns. Algorithms are the computer science tools of computation. Functions, events, callbacks, threads, and other features implement computation as well as abstract them...
  • Abstraction provides definitions/groups for related state or computation, for building large structures out of smaller ones. Functions, names, classes, references, modules, macros, languages, and code generators are some of the tools of abstraction. 
One application of these computer science ideas to game design is obvious. A game models nouns that have access to verbs, and these features need to be named and grouped into a rule hierarchy to be manageable. The process of writing any program is that of computationally modeling some system, whether truly from the real world or one that is mathematically possible but may not have a physical analog. "Games" are just the computational models that happen to be interesting to humans.

Rush Hour
The core skill of game design is the same modeling process learned in computer science, although it is a hard skill to study explicitly. Most of us learn the modeling process in computer science from trying to design programs many times, not from reading any particular text or hearing a lecture.

Interestingly, the power of computer science for game design runs even deeper than computational modeling. Some of the deep ideas are also accessible from a more theoretical side instead of requiring direct experience. I'm going to hint at this for the remainder of this section. This is an advanced topic and shouldn't be at the top of your list for first learning to create games. But it should pique your curiosity and hint why more than a single computer science course might be valuable to the non-programmer.

Most of the italicized terms in the examples from my list of computer science techniques sound like tools from pure mathematics...because they are. What computer science adds to mathematics is a notion of the cost of computation. In the concrete real world, actions take time, consume energy, require storage for the input and output, produce waste (e.g., heat), or incur some other form of expense. This is true for players trying to decide what move to make, economic agents making decisions, and computers evaluating mathematics. Once we have these real and measurable costs, we have an objective way of argument that one mathematical model is better than another.

San Juan
For example, I might try to arrange a deck of cards in order by repeatedly finding the smallest remaining card from a draw deck and putting it on top of my discard deck. On average, that process takes me a number of card comparisons proportional the square of the number of cards. We can measure how long it takes me to look at an individual card and use that to estimate how long the whole process takes.

You might achieve the same card-arranging goal by repeatedly splitting your deck in half until you have many single-card "decks," and then repeatedly reconstructing sorted ones. If we started with 256 cards, then after the first reconstruction step you'd have 128 two-card decks, each in the right order. Within eight steps you'd have the whole deck in order. That process is much faster (it takes a number of card moves proportional to the product of the size of the deck and its logarithm, which is smaller than the product of the size of the deck with itself). So you can make a really good argument that your method of repeated splitting and combining is better than exhaustive comparison for large, randomly arranged decks.

DayZ
While putting cards in order does come up a lot in games, that's not a particularly motivating example for game design. I chose it because it is a classic computer science example of two ways to solve a problem, where both are subject to analysis and one is obviously better under some initial assumptions. That kind of thinking is important for sophisticated design, both in creating mechanics and in analyzing strategies under them.

There are also many algorithms and data structures that suggest under explored spaces of mechanics. The games of Reiner Knizia are essentially a playground of set theory and computer science algorithms, disguised by evocative themes of exploration, battle, mythology, and statecraft.

Diablo
Finally, it is important to be aware of the inherent computational limits and current technological limits of computers when designing a video game, even if someone else will perform the programming of it. Often these limits are not particularly intuitive without a computer science background.

A game designer who specifies that each of 100 units in a real-time strategy game will compute the a good path from itself through a complex terrain map to a goal 30 times per second has actually asked for something reasonable, even though it sounds hard. Depending on how that terrain is configured, it is probably possible to find the best path for each unit independently in very little time.

In contrast, a designer who says that the inventory system will automatically pack objects on a 20x20 grid into the best arrangement in a fraction of a second has asked for something impossible, even though it sounds like an easy problem for a computer. (If the designer instead asked for a pretty good inventory arrangement on average, then that might be reasonable.)

Some Game Design Skills

I've repeatedly mentioned mechanics, but resisted concretely defining them or naming them. Some simple ones have fairly standard names that I'll admit. Others have ad hoc names in some texts, but best described by listing the games that use them and drawing the connection. Let's start with some simple ones to at least make concrete what a "mechanic" might be, but not seek a rigorous definition:
Warcraft III
  • Cool-down abilities come with little timers. Once an action is taken, it has to recharge before future use. These are popular in role-playing games and some tactical strategy games like Warcraft. They let the designer grant the players power while restricting the rate at which that power can be deployed. They also create texture to the game, since every turn cannot be played in the same way.
  • The leader-bonus mechanic (e.g., as found in Puerto Rico, Race for the Galaxy, and Eminent Domain) allows the current player to take an action, but in doing so allows all other players the option of taking a weaker version of that action. This speeds play in multiplayer board games; prevents one player from dominating a particular strategy; and creates situations of "chicken," where players try to force the opponent to pay the cost of a move that they both wish to make.
  • Bidding ensures that most items are assigned fair prices in a game and makes information a commodity: placing a bid reveals the strength of a player's hand or the magnitude of a player's desire for an item, so must be balanced against the value of winning the round.
  • Having a non-player character support the player's goals creates empathy for that character and affection for him or her. This can be deepened by also making the character dependent on the player at another stage. This encourages the player to value that character, creating an emotional lever for the designer. The Last of Us, Ico, Prince of Persia (2008), and Papa and Yo base their gameplay primarily on this mechanic. Portal famously creates great affection for the inanimate "companion cube" (crate) by presenting it as a useful new tool in the game and forcing the player to carry it through a level. Left 4 Dead and Team Fortress extend the mechanic to creating relationships between players, which then generates narrative as well as gameplay.
Desert Golfing
Learning to recognize these kinds of techniques across games and understand how and why they are applied is the first skill of a game designer. They're also the first skill of a master player, both for rising to strategic instead of emotional and intuitive play, and for making optimal choices in the game.

After acquiring a mental toolbox of mechanics, the next major skills of game design are in service of tuning and arranging the mechanics. These include:
  • Mastering statistically-driven processes, either through randomness explicit in the game's rules or as a way of modeling the players. The most fundamental concept here is the distribution, e.g., through understanding uniformly distributed; normally distributed; poisson distributed; variance, median, mode, and mean; sampling with and without replacement; conditional probability, and confidence intervals and tests. Naive designers make everything uniformly random and only see a range to manipulate, which usually leads to systems with large swings and unsatisfying play. Sophisticated designers adjust distributions to create a texture of mixed common and rare occurrences that players at least intuitively understand and are excited by.
  • Reward cycles are patterns, skills, and rewards at layered time scales. A player should simultaneously be incentivized by the next move, the next turn, the next upgrade, etc. through winning the game. A good designer applies different mechanics at different scales, and then links them to one another to create a continuous experience while restricting the complexity of any one decision. A game like XCOM or Ocarina of Time builds a dizzying tower of cycles that compel play.
  • Manipulating tension keeps challenges fresh and sustains emotional impact over the long timescale of some games. An action film can't keep the hero constantly under the same threat for two hours without numbing the audience. A board game might take just as long without the stimulation of a movie, and a video game has that stimulation but might be a 20 hour experience played over many months. Just as in the film, a game must build and release tension. The weakest form is narrative tension. That creates extrinsic goals that the player only pursues halfheartedly. A stronger form is mechanical tension. Bring players to critical points and then release them, or adjust the mechanics to suddenly alter the power balance. The Last of Us frequently deprives the player of weapons and even movement to renew the game's challenge, and then relaxes the player with humor or quiet, contemplative stretches. Yinsh removes the scoring pieces from the board, reducing the winning player's advantage and clearing large areas for a new battle.
  • Learning to deploy a variety of concepts from economics in an entertainment context. These include revealed preference, perfect substitution, hidden information, perfect complements, discriminatory pricing, and auction theory. Most good board games rely on such ideas.
  • Geometric and algebraic tools; square and hexagonal grid arithmetic, numerical approximations, solving simple polynomial systems, derivatives and integrals, awareness of cumulative rounding issues, and so on. 

Process

Minecraft
Creating anything is hard, in any medium. It takes vision, self-discipline, careful time and motion management, resource management, and a willingness to kill your darlings. To make games you must create an effective creative process tailored to your own psychology and resources.

Fortunately, there are some common elements of most effective processes for game development. You should begin with productivity and workflow techniques that others espouse, but constantly reevaluate how appropriate they are for you. As perhaps the top lifecoach for indie game developers, McFunkypants' energetic and supportive guide is a very good place to start.

Here's my advice for prototyping potentially complex games: board games with a large team and many mechanics, or any video game. It is in line with most other experts.

Settlers of Catan
Don't begin by diving into your first idea. You're going to invest at least a hundred hours in this project, and should make sure that you're spending that time on a worthy idea. So begin by discussing and writing down your vision. Use prose, diagrams, screenshots, or whatever else helps you make it concrete and on paper instead of vague and in your head. In a group, you can build on each other's different visions to generate a collective idea. If you're alone, force yourself to generate three or four ideas even if you're certain that you're going to reject them. Forcing yourself to consider more options will often lead to new and better ones. I might write half a page by hand and scribble some images on the first draft.

Once you've articulated your idea, pause for a day or so and to reflect on it. Research existing related games to see how they handle the mechanics. Collect concept and reference art. Then, revisit your idea in light of what you've learned. Your design on paper will probably change at this point, and might firm up to a page or so. Your goal is not length (in fact, brevity is much better) or a specific form of a "game design document," but to use the act of writing to ensure that you've thought things through enough to commit to your ideas.

The Last of Us Remastered
Keep iterating for a few more days. Modify and flesh out details of features. Draw up a schedule, start working out algorithms and equations...and cut some features. I have a specific one-page format that I use for my proposals, but it takes me about a week to collect the ideas into that format and I often start implementation before the proposal is complete. The idea isn't to reduce design to filling out a form, but to use the form to remind myself of issues that I should consider early in the process.

Once you have a firm idea, you should stop researching and start implementing. Ultimately the answers to design questions will come from your own game and players, so stop looking elsewhere once you understand the field.

While implementing, keep modifying the plan and reflect daily on your process and path. It is usually bad to drive from start to finish on the same plan by force of will, determined to execute on the original vision as if it were a specification. Implementing exactly the first design merely means that you didn't react to what you discovered about the game during development.

Bean Dreams
A good game design will change significantly over the course of implementation and testing, and lots of changes to the plan are signs that you're reacting well by incorporating new information. The frequent pauses for reflection are important. Before even a weekend game jam, many developers will draw up plans. They'll then revise them several times, with hours or days between revisions to gain distance from the ideas and judge them well.

Revising the design should often be a spontaneous and enjoyable process, not something that feels like a day job or administrative task (even if it is your day job). Many people report that good ideas come while in the shower, exercising, or talking over meals. Don't stare at a computer and expect inspiration on a schedule; provide yourself with other stimulation and situations that relax the pressure on your creativity.

This process is designed to improve the quality of your design and avoid a show-stopping redesign in the middle of development.

Hohokum
Perhaps the most important productivity tip is to always focus solely on the most important gameplay feature, ignoring all else until you're certain that the game is worth playing. That is, when reducing your design to a playable form, don't polish early. Don't make menus, title screens, credits, multiple levels, graphics or fancy sound for a video game.

For a board game, don't print pretty art on your cards and wordsmith the rule-book layout during early production. The gameplay is always the highest risk and needs the most work. Everything else is that cargo-cult trap that I mentioned earlier: mimicking the wrong aspects of creating games.

Make video games with colored rectangles, no user interface, and inefficient, quickly-written code. Make board games by using existing components and a cheat-sheet of entries such as, "the Ace of Spades is the Unicorn, which can bring any character back to life. The 2 of diamonds is..."

A good craftsperson micromanages every aspect of workflow. Efficient programmers have a full-screen code editor that they know by heart and rarely touch the mouse. Digital artists have hot-keys for their tools and digitizing tablets; natural media ones have everything that the need in arm's reach and plan their work to minimize downtime of drying paint or switching tools. A good designer knows when a conversation is getting off track or the research on ancient cooking implements has become an interesting rathole.

A Syllabus

Games to Make

Tetris
Artists first study their craft by re-drawing masterpieces, singer-songwriters begin by performing existing music, and film-makers imitate shots from great films. For both computer and board games, it is helpful to begin by mimicking good, simple examples.

You can then modify your recreations to explore related designs. For computer games, you'll learn a lot about game software design and a little about game design from this process, because that's where you'll spend your time. For board games, you'll learn a little about producing the materials and a lot about game design.

I recommend exploring modification more in board games--you can see all of the rules outright, so you spend much less time reverse engineering. A good way to mimic board games is to try and recreate them with new pieces and writing out a rule book without looking at the original. Like the beginning art student redrawing Monet in charcoal, this will force you to attend to detail and work through the design challenges.

Most people learning game design want to focus on video games. I recommend spending a lot of time at first with board games, playing, modifying, and analyzing them. Modern board games benefit from advances in video game mechanics, while emphasizing game design instead of technology for the aspiring developer.

Space Invaders
Below are some thoughts on sequences of games to clone and modify when learning. The idea is to focus on games that contain some core design elements common to large families of games.

Chain your exploration of these games in a way that presents each as an evolution of its predecessors. One could make many syllabi around this idea, and I welcome suggestions. In sketching one below, I'm inspired by the diagram from page 79 of Koster's A Theory of Fun. That image shows that classic arcade games were designed by copying previous games and adding a single rule variation (Levy provides more evidence for the examples Koster uses). Board games can be arranged this way as well; my favorite example is the evolution Tic-Tac-Toe to Go-Moku to Pente.

Board Games

Your goal is to gain both theoretical and intuitive understanding of mechanics by trying to recreate or modify these games. Measure how small changes improve or imbalance these games. Don't polish. Use existing pieces and standard playing cards with a decoding table wherever possible. Don't even write down the rules most of the time--explain them to the players, and feel free to modify them during your playtests as your learn more. You're playing to improve the games, not to win them.
  1. Uno (Recreate the game and rule book using two standard playing card decks, and then introduce your own variants)
  2. Hive (Try changing the rules while using the original pieces. What if there are two queens per player? Make pieces move differently. Add new constraints on when pieces can be deployed. Add exception abilities.)
  3. Dominion (Try to recreate and balance the recommended 10-card starting set without looking at those cards, and then invent some new cards of your own. Playtest with many different styles of player.)
  4. Settlers of Catan (Make your own variants. Introduce new victory cards. Adjust the board size, point limits, trading rules.)
  5. Pandemic (Play with the cooperative mechanic. Do you need a traitor, as in Shadows Over Camelot and Battlestar Galactica?)
  6. Choose Your Own Adventure (Make a graph of the branches in an existing CYOA book. Add new branches by replacing some pages. Experiment with new mechanics like state, multiple players, and randomness).

Computer Games

Defender
Your goal is to discover algorithms and data structures appropriate for the increasingly complex mechanics in these games, and to gradually increase the quality of input handling and output (graphics and audio).

Nested games on the list show a spur path from their parent that can be pursued before returning to the main line.

Don't polish. The graphics should be minimal colored primitives. Don't even implement sound. No menus. Consider what the minimal game that references the named one would be and then implement that.

Sometimes it is helpful to add further, extreme constraints to keep yourself focused on mechanics over all else. For example, the LowRezJam required games to render to a 32x32 pixel, or smaller, display. It is hard to get too distracted by painting sprites under such limitations.
  1. Pong
    1. Desert Golfing (turn-based, world state, procedural generation)
    2. Scorched Earth (destructible terrain, two-player)
    3. Stretch: Angry Birds (rigid body)
  2. Breakout (world state)
    1. Asteroids (dynamic entity creation, free-direction movement)
  3. Space Invaders (NPCs, increased state, multiple dynamic objects)
    1. Shariki (turn-based UI, grid state)
    2. Bejeweled (grid-shifting)
    3. Tetris (more complex grid state, lots of corner cases, constant tuning)
  4. Defender (complex controls, multiple simulations)
    1. R-Type (scrolling shooter: significant state and graphics)
  5. Donkey Kong (single-screen platformer: gravity, multiple traversal modes)
    1. Pac-Man (power-ups, NPC AI)
  6. Super Mario Bros (scrolling platformer)
    1. Metroid (area replay, ability evolution, multiple traversal mechanics)
  7. Contra (two-player platformer)
I chose mechanics first for this list and then found a relatively canonical game for each. You could easily say "Castlevania" instead of "Metroid," "Arkanoid" instead of "Breakout," and "Choplifter" instead of "Defender." The point isn't to replicate the theme of the game, anyway, so your Asteroids clone might be themed around special forces eliminating terrorist cells, or psychotherapy addressing painful memories. (Another example: Fe[26] is a great 2048 clone using the superior theme of nuclear fusion.)

Games to Play

There are a lot of great games and game series that every developer should know, or at least know about. These include:
  • Nearly everything popular in the Golden Age of arcade games
  • The games of Miamoto, Valve, Shaffer, Spector, Wright, Knizia, Jackson, Meretzky, Meier/Firaxis, Mechner, Church, Naughty Dog, Garriott, Packard, id software, thatgamecompany
  • Zork, Skyrim, Call of Duty, Halo, Guitar Hero, Skylanders, Splinter Cell, Grand Theft Auto, Madden, Myst, Fallout, Diablo, Warcraft, Starcraft, Age of Empires, Battlefield, Tomb Raider, Need for Speed, Grand Theft Auto, Assassin's Creed
  • Tetris, Monument Valley, Limbo, Braid, DayZ, Monaco, Jet Grind Radio, Minecraft, Wing Commander, M.U.L.E., Kerbal Space Program, Mirror's Edge, The Stanley Parable, 80 Days; Papers, Please; That Dragon, Cancer; Dwarf Fortress
  • Chess, Go, Mancala, Checkers (Draughts), Othello, Backgammon
  • Poker, Blackjack, Bridge, Whist, Blackjack, Mahjong, Scrabble
  • World of Warcraft, Dungeons & Dragons, Magic: The Gathering
  • Risk, Monopoly, Chinese Checkers, Connect-Four, Trivial Pursuit, Rubik's Cube, Simon Says, Stratego, Battleship, Mastermind
  • Settlers of Catan, Carcassonne, Puerto Rico, Citadels, Rush Hour, Ticket to Ride, Agricola, Race for the Galaxy, Dominion, Flash Duel, Eminent Domain, Shadows Over Camelot
Most of these games are amazing in many ways. All excel at least one way (albeit, possibly sales), and were historically influential.

Myst
Although it would take decades to cover even that incomplete list, I recommend that you immediately start reading about those games that you aren't familiar with and playing as many as you can.

No creation is unique and many of the greatest are almost wholly derivative, with the twist and interpretation being the act of genius. Since even your best games will reinvent some other game, it you can save yourself time by first learning about a lot of other games.

There are many ways of grouping games, including themes, eras, markets, and mechanics. I had some in mind when I created the list above and organized the games to imply that. I didn't explicitly name the categories. That's partly because wanted focus on the games themselves instead of external distinctions, and partly because it is hard to give a good name to some of the groupings.

This War of Mine
However, for my limited agenda of combining rigorous mechanics and artistic expression, I'll commit to some named categories within which that one should deeply study at least one game. I don't list these categories on the syllabus of my course. I'm showing the final list from which I selected eight to describe how I chose the games that I'm using next semester.

I began by listing about two hundred games that I thought were  appropriate for the class (including the ones above). I then extracted the ones that are practical to use in the classroom: not too long to learn or play, broad cultural representation without compromising quality, appealing to college students, and affordable.

I grouped the remaining games intuitively into ones that were roughly interchangeable for educational purposes. I named the groups to try and rationalize my intuition, and then chose the game from each group that would be the most practical, or least familiar (to put most students on a footing of equal ignorance). The result of this process is below. If you're looking for a starting set of games to learn from, you might want to choose the one from each category that appeals to you instead of the one that I chose.
Mirror's Edge

  • Abstract Strategy: tight single-mechanic games that act like poems
    • *Hive
    • Tetris
    • Abalone
    • Yinsh
    • Othello
    • Rush Hour
  • Simulation: Driven by emergent properties of physical simulation
    • Minecraft
    • Burnout
    • Octodad
    • Starwhal
    • Little Big Planet
    • Element4l
  • Party Game: Easy to learn games for many players that rely on social skills
    • *Spyfall
    • Mafia
    • Charades
    • Werewolf
    • Balderdash
    • Apples-to-Apples
  • Card Games: Modern Euro-style card games
    • *Dominion
    • Eminent Domain
    • Race for the Galaxy
    • Magic: The Gathering
    • San Juan
  • Fine Art: Nuanced, emotional games
  • Economic: Engine-building games with commodities
  • Epics: Polished mechanics hybrids, comparable to novels
There are plenty of categories one could make, including first-person shooters, racing games, rhythm games, sports games, and adventure games. Those aren't in this list. Something needs to be culled to yield focus, and while there are undeniably important games in those other areas, few are at the core of what I'm trying to teach: rigorous mechanics and emotional, meaningful experiences. I think that a lot of the independent game scene is aligned with this agenda, although It's reasonable if you're not.

While you should study and practice making all games, put your heart into the ones that you care about and not the ones that I do. If they're good enough, you can show everyone why they should care about them too.

Further Online Reading

This isn't a list of hardcore games articles or textbooks that you should read. Recall that I believe you should be spending most of your time making and playing games, not studying other resources. A guide like this one or a single textbook will cary you through the first stages well enough, and after that you'll know enough to select books on your own.

Metroid
However, I collect short, interesting articles about games (and short interesting games themselves) and resources for programmers, artists, and designers. I don't necessarily agree with all of these, but they are the kinds of articles that you're probably be interested in. At the least, they're probably pleasant diversions on the days that you've worked too hard to make further good progress on your creations. Some of these are assigned reading for my course. 






Morgan McGuire (@morgan3d) is a professor of Computer Science at Williams College, a member of NVIDIA Research, and a game developer. His most recent games are Rocket Golfing and work on the Skylanders series. He's written several books, including the Graphics Codex, an essential reference for computer graphics now available in iOS and Web Editions.
Posted by at