Tagged in: game design

Review: The Art of Game Design by Jesse Schell

Book: The Art of Game Design: A Book of Lenses
Author: Jesse Schell, game designer, VR enthusiast, and professor at Carnegie Mellon
Year: 2011 – 1st Ed. (2nd Ed. came out in 2014)

Summary: A really excellent, comprehensive introductory textbook to the field of game design. There’s a supplemental card deck of “lenses” that are nice for early prototyping or smaller indie projects.


There are many books touted as introductions to game design for students or aspiring designers and I’m often skeptical of their claims, having run across so much bad advice. When doing the initial research for this game design library series, I’ve found dozens of books that seem to paint an incomplete picture, or whose lessons quickly become outdated with new technology. The Art of Game Design has none of these flaws: it’s comprehensive, covers design irrespective of technology (but does not ignore it), and contains concepts and examples that have me nodding along in agreement from experience.

The Art of Game Design is a Game Design 101 textbook: it reads to me like a full semester college curriculum on game design, from theory to practical concerns, that has everything you need for self-study except for a list of assignments. If I ever taught a game design course, I would design my curriculum right from this textbook – so while I definitely recommend it for students, it should also be necessary reading for teachers of (practical) game studies courses. (Schell himself teaches at Carnegie Mellon and I’ve been told the book is based off of his teaching materials, which is a good recommendation for that program).

The book itself is split into 33 chapters, each one tackling an important concept that builds upon previous ones. Schell starts at the beginning with basic ideas and definitions – designers, games, players, ideas, iteration – continues into the heart of game design – mechanics, balancing, puzzles, interface, story, spaces – and even dives into the necessary logistics – documentation, playtesting, publishers, and profit. It is extremely comprehensive in that he covers all the major topics of game design, familiarizing students with important concepts and giving them the language to describe and analyze them. It clocks in at 489 pages with large pages packed with text and plenty of diagrams.

Schell’s approach to game design differs from my own in many ways, and has its own quirks or proposed ways to model complex ideas. For example, he offers his own alternative to the MDA (Mechanics-Dynamics-Aesthetics) framework that specifically incorporates story and technology. He analyzes and compares a number of different definitions of “game” and offers his own admittedly incomplete but highly practical definition: that a game is an experience. I can get behind these mental models and add them sparingly to my toolbox, though I didn’t find anything really revolutionary within its pages (nor did I expect to).

As a working designer reading this, it retreads a lot of familiar ground. If someone has never really put any thought into what it takes to balance a game, this book will give you not one but twelve different axis to think about (physical vs. mental, easy vs. hard, short vs. long, and so on). Most of this is already second nature to me, so at times the reading felt a bit of a slog. It’s only when Schell dove into subjects I know very little about – such as his chapter on transmedia storytelling – that I found myself fully engrossed in the text. I appreciated the book, personally, as a tool to fill in holes in my knowledge I didn’t realize I had. I can’t honestly think of any subjects he failed to cover, and all the usual “rules of thumb” or lessons taken from other media (from the hero’s journey to the Big Five in psychology) are all mentioned.

One of the strengths of The Art of Game Design lies in its personal anecdotes and examples used throughout to illustrate every idea, concept, piece of vocabulary, and step along the way of making games. Sometimes this feels a bit wordy and long-winded – long paragraphs describing a real or hypothetical game can feel redundant if you already grasp the idea. But since I consider the prime audience for this book to be students, the repeated information presented in a variety of ways means that almost everyone will come away with a good understanding of any given concept.

Schell’s playful enthusiasm for games (which you’ll know if you’ve ever heard him speak) shines everywhere. It’s written personably – the author has a distinct, friendly voice and uses his previous experiences in games and other careers (like juggling) to tell anecdotes and explain his process. Some chapters interested me more than others but, to be honest, the tone and quality of information was really even throughout the entire book. A few sections I could have skipped (interface, brainstorming) because the topics did not interest me as much, not because they weren’t well-written.

I read The Art of Game Design at the same time as I began design for a side project. I found myself wishing there was a workbook or checklist companion for the textbook – but this is where his Deck of Lenses comes in.

Art of Game Design: A Deck of Lenses – not my image, but rather from the Amazon.com’s customer reviews

“Lenses” are different discrete concepts – such as the Lens of Flow or the Lens of Fairness or the Lens of Story – that give you unique points of view on your game. These concepts are the core of the textbook, where any chapter may have a half a dozen different lenses called out in its own box summarizing and repeating the information written within the text. Each lens has a number of questions to ask yourself about your game when evaluating it.

A Deck of Lenses is a companion to the Book of Lenses: it is a deck of 100 cards, each one containing a different lens (you can see some examples with a quick google search). The deck is also available as a free app for iOS and Android – I didn’t install it since I have my own hardcopy, but I encourage readers to check them out. [iOS link] [Android link]

The lenses he chooses are all excellent, asking important questions to help you reflect on your game. They act like a condensed version of the textbook: if you have already internalized the concepts, these are your snapshots to remind you and act as a direct tool for evaluating your game.

If you’re deep in mid development of a AAA-sized game then I’m not sure you’ll find much use for A Deck of Lenses. But I think they could be a tool for indies or people making small games by themselves judging by how I used them on my own small project this month. It will vary based on whether you, personally, find a use for them or add them to your habits. I suspect mine will soon end up back on the shelf gathering dust again like they had for the last two years.

There is a second edition out now and I briefly looked at it – it has some new content, new lenses, and recommendations for further reading at the end of each chapter. I don’t think the changes are substantial enough to warrant getting a second copy, but if you can’t decide between the two then pick up the second.

Personally? I found The Art of Game Design kind of boring since it spent most of its time introducing me to concepts I am already familiar with. For this reason, I hesitate to recommend it to experienced designers but, as they say, your mileage may vary. So far this looks like the most comprehensive (encyclopedic even) book on common design concepts. I think most students and aspiring designers (as well as those that feel they have gaps in their knowledge) would be better off armed with the information in these pages.

Review: A Theory of Fun for Game Design by Raph Koster

Book: A Theory of Fun for Game Design
Author: Raph Koster, game designer on MUDs, MMOs, virtual worlds
Year: 2004, but I read the revised edition for 2014

Summary: A good introductory text on game design that briefly covers a gamut of practical topics in game design, but doesn’t go into much depth on any one of them. Good for students completely new to design, but I would not recommend it for professionals.


When asking for a good book on game design, A Theory of Fun is usually pretty high on everyone’s list – and for good reason. It’s short at only 279 pages, but only about half of those have text – sometimes not even a full page. Each page has a matching illustration on the opposite, ranging from whimsical drawings to infographics. The writing is easy to read, full of personal anecdotes and a teacher’s patience rather than a dense academic book or one set out to evangelize a particular view of games. It has a personal but also very matter of fact tone that jumps right into the content.

This is not a how-to book: you will not get practical advice for being a better designer or designing a game within its pages. It starts off with the question of “what are games and why are they important?” and answers it with the meaning of games, what is fun, how games are used for learning, how people interact with games, and finally a call to action for games to take their rightful place among the arts. It provides a good informative basis for what design is and general issues designers must consider, such as player retention, skill, mastery, core types of games (dominance, territory acquisitions, etc.), the difference between systems and aesthetics. It’s the kind of book that I may hand to an outsider to explain what makes games different from other media, and why they should be considered art.

Keep in mind that the book is very short and despite its brevity it jumps between subjects so quickly that it can feel that you don’t really dig into any given one. However, everything it does cover is pretty meaty, if short. This is in contrast to other introductory books that are very, very long because they repeat information or spend a lot of time explaining the same concept in multiple ways. It’s well-divided, and uses plenty of bolding or bullet-points, so it’s also an easy book to skim for information.

I first picked up A Theory of Fun nine years ago – and I read about half before deciding that it was okay but a bit basic. Now that I know a bit more about design, I thought it was a good moment to reread this – all the way to the end – with a more critical eye. I personally like much denser texts, so while I appreciated the breadth of A Theory of Fun it left me rather unsatisfied and retreading ground I am already familiar with. I am not going to repeat everything the book covers here – if you want that, you should read the book – but rather just some points I found particularly interesting.

The author throws out most of the definitions of “game” because they aren’t very good at giving working designers a good model for making games. Instead, he offers his own – that the purpose of games is to exercise the brain, and you exercise the brain by challenging it to identify patterns. Games give players an opportunity to practice and understand patterns in a safe context, where stakes are not as high as in the real world.

Patterns require interaction and feedback, and this loop allows players to develop their own mental model of the game and its objects and, with iteration, improve that mental model. From this, Koster focuses on games as systems and most of his lessons on games, challenge, difficulty, interaction, feedback, and so on rely on this understanding of the relationship between games and patterns. His definition of games notably includes practice, training, roleplay, simulation, and drills.

One of the important arguments he makes is that games are, at their core, about systems and everything else – like aesthetics and narrative – are dressing. He argues that the value in games must be found in that interaction and feedback loop and this is what sets games apart from, say, a book. You could describe this as a two-way dialogue between the player and the system. He even says at one point that game systems by themselves do not contain morals – Tetris with a different dressing could be a game about mass murder, for example. Ultimately, he points out that we (as developers) have done a great job at improving the dressing in games, but a poor job of innovating on those systems.

This isn’t really new territory – people have been talking about how to evaluate games on their systems and aesthetics for a while, and practicing game designers mostly know that the hardest, most important, and most time-consuming part of making a game are its systems, rules, and mechanics and not the narrative dressing. A lot of students, aspiring designers, and amateurs avoid thinking deeply about the systems, copying them from other games without too much reflection, and instead put all their efforts into the dressing (see: all those 2D platformers). Of course, the same can be said of mainstream AAA games – a different skin, but the core mechanics are usually recycled.

My only misgiving with the book are its nods to scientific studies and evolutionary psychology, largely because both have been used all too often by non-experts to explain away culture as biology. These include topics like brain function, player psychology, how different genders play, and games acting as training for survival. As I mentioned the purpose of this book is to introduce, not dive fully into depth on any one of these topics, so I think it’s better to look at the source materials (he provides many recommendations for further reading) before accepting them at face value. (This is always my rule, regardless of author, and it’s why I have a lot of psychology texts in my reading list).

Much of the information in the book I already knew, but it was nice to have it spelled out directly, including some new vocabulary. The book covers several other topics – I particularly enjoyed the parts on how games are ultimately consumable, and how players are driven to exploit systems. There are a lot of really excellent charts in here for modeling games, including ways to compare them to other media, especially music, to show that all forms of art can be looked at as formal systems, metrics, rules, and mechanics.

I’ve read some of the author’s other writing and I find those more effective than this book, so I was a bit disappointed by A Theory of Fun. The fact that it’s broad in scope, written approachably with a lot of personal anecdotes, and full of whimsical drawings makes it a non-intimidating introduction to design, especially for those outside of the game industry.

A Game Design Library

I’m starting my next side project: to read as much as possible on the topic of game design AND to engage with that writing critically. Specifically, I plan to read books on game design and related disciplines as a supplement to my main source of information: articles, talks, conferences, and chats with other designers.

A few months ago I started collecting books on game design, film, art, narrative, digital media, technology, history, psychology, anthropology, economics, architecture, and so on. These books range among introductions to the medium, specialist texts for working professionals, and academic texts on critical theory.

My current collection, at 64 books

This collection isn’t complete. As of the time of this post, I have about a hundred more I haven’t picked up yet, some other sources of recommendations I need to go through, and several more books that will be published by the time I am done with these.

My plan is to first read the basic textbooks about game design – both textbooks written by game designers and foundational academic texts on games and play. Once I get passed that base, I’ll start branching out into sub-topics, like social/community/multiplayer, or strategy/competition, or level design/architecture. That’s also when I’ll start grabbing more books to add to my library and fielding more recommendations. I also have a large collection of academic writing, but haven’t decided when or how I’ll integrate it into my reading.


My List of Books


I’ll keep this list up to date, with the first column listing the status of the book and replaced with links to my reviews as I write them.

You’ll find my reviews under the Game Design Library category on my blog (and I’ll number each one and use tags to help categorize topics, too). Each book will get its own post, but I’ll do separate articles to address specific ideas I found interesting or to compare and contrast how different authors approach the same concepts.

I expect this will be a long-term project. I read quickly – about 2-3 books a month – but I write slowly. I expect to read and review about 20 books a year (maybe more if I can figure out how to edit myself…).


If you want to recommend a book not already on the list…

Please check it against my wishlist of books I haven’t bought yet to make sure I don’t already have a record of it. Feel free to leave a comment below with new ones with a brief reason why it’s important and I may add it to my list. I am particularly looking for books written from outside of the American perspective so if you know of any please share (this includes but in no way limited to games history and culture in Japan or Europe).

I may eventually open up my list to voting if there’s a specific book that people would like to see a review of, but for now I have a pretty solid plan in place to keeps me busy up through April.

From Student to Designer: Part 4 – Design Tests

As usual, my advice is specific to design and to seeking a more traditional job in AAA development, as opposed to breaking in as an indie, but most of it can be applied elsewhere. This is just my personal advice, so I recommend getting others to review your work for second and third opinions, and ultimately make your own decisions.

Part 1: Websites & Resumes
Part 2: Portfolios
Part 3: Cover Letters
> Part 4: Design Tests
Part 5: Interviews
Part 6: Entry Level Design Jobs


What Is a Design Test?

A design test is a test of your design skills where a studio asks you to perform some kind of design work as part of the interview process. Usually a design test is timed (i.e. one week in your spare time seems to be pretty common). Sometimes the design test is on-site as part of the interview process, where you are given anywhere from one to four hours to complete an assignment by yourself.

I’ve done several design tests, been given (and passed on) a few more, and even designed one. When writing this article, I reached out to a lot of other people in the industry for their advice and experiences. The type of work varies depending on what kinds of games a company makes and what work designers do there. Design tests may ask you to:

  • Analyze or deconstruct mechanics or systems in an existing game
  • Take an existing mechanic or system and propose changes to meet a new design goal
  • Design and document a chunk of new gameplay in an existing game, such as a new feature, gameplay mechanic, weapon, boss, puzzle, etc.
  • Design and document a new level or mission to an existing game or within certain parameters, including all the information needed to put that level into production.
  • Implement a level in a particular toolset.

These tests are pretty always specific to the studio. A company that makes puzzle games will have a design test that involves designing a puzzle, whereas a company that makes third-person shooters will probably have you design a level for one of those. A mobile company that makes free-to-play games may test your knowledge of monetization, the audience, and platform, but a AAA studio probably won’t since that’s not part of the job of a designer. So the best way to prepare for a design test is to know what kinds of games the studio makes.

The design tests usually have a number of requirements and limitations that they expect you to follow when doing the test. In my experience, these kinds of constraints are usually realistic and mirror normal development of a game, thus keeping the scope of your work in check.

Not all studios have design tests. Studios that do have design tests may only selectively choose who needs to complete them or give them to everyone no matter the position. I think they are more common in junior roles, where there are more applicants and those applicants have less experience, so as a student (which you, reading this, probably are!) you are likely to come across them.


Why Are There Design Tests?

The design test is a supplement to the interview process – it’s just another way to filter applicants and find out which one is best for the job. Most design tests are sent out before or between interviews or take place during an on-site visit.

There’s a few key things that someone can discover from a design test that can be hard to learn otherwise:

  • Evaluate your skills in the genre assigned, assuming you have no previous professional experience.
  • Help identify designers that will need to be micromanaged and hand-held through the design process, as opposed to those that can make intuitive leaps and show initiative and creativity.
  • If you have a realistic understanding of game development process and scope of work you’re detailing out.
  • If you care about the quality of your work and will finish your work to a high standard of polish. I can see this in the presentation, completeness, and quality of the design test submission.
  • If you’re able to communicate your designs clearly and effectively in ways that everyone, not just designers, can understand.
  • If you can plan ahead for many different test cases (“what if the player does x?”), and spec out mechanics with a certain level of completeness. This is kind of asking if your design is water-tight.
  • If you can plan ahead for all kinds of details that affect other departments. Examples: audio cues, lighting, dialogue and story moments, cinematic events, identifying destructible objects or new assets specific to newly-design mechanics.
  • If you did proper research on, and have familiarity with, the studio’s games, or games in the same genre.
  • If you can follow directions!

One thing to keep in mind is that while a design test is a “test” and not final work, I would treat it like you are documenting something that needs to fit into a final game. Work on it knowing (‘pretending’) that this is work that you need to make as part of your job, and that you may be handing it to your leads or peers for review or to other departments as information they need to know.



So when asking others for their experience with design tests, a lot of people shared real-life examples, many of them old and no longer being used, and others actually available publically (if you know how to google for it).  I’ve still summarized and anonymized them since it’s bad practice to share design tests verbatim (it’s kind of like sharing exam questions during finals week). This also means I changed a bunch of key details so, no, don’t expect to see these exact ones anywhere. The below examples come from a big cross-section of studios, from indie to mobile to AAA to third- or first-party studios.

It’s common to see a combination of design tasks that ask you to analyze a game, modify a game, and design a new game (substitute “game” for “mechanic” or “level”). A smaller subset also asks you to implement that game (or mechanic or level) in a game development toolset. This is how I’ve divvied up the types of questions or tasks assigned. But design tests can be anywhere from one to ten different tasks, depending on the studio and the questions they are asking.

Analysis Examples

  • Take two games and analyze their strengths and weaknesses.
  • Take the studio’s existing game and create a flowchart of one of the gameplay loops.
  • Take a successful free-to-play game and analyze it. Explain how monetization works.
  • Deconstruct a competitor’s game and analyze its structure and gameplay.
  • Take an existing game and pick one feature that you think it does best.
  • Deconstruct a level you have shipped in a previous game, including your design process from beginning to end.
  • Compare and contrast how two games implemented the same feature
  • Document a given gameplay mechanic

Modification Examples

  • Take the studio’s existing game and identify a feature you would cut, and explain why.
  • Design a new feature for the studio’s game
  • Balance gameplay values for a specific design goal, such as with a spreadsheet
  • Take a singleplayer gameplay mechanic and adapt it for a multiplayer environment, or vice versa
  • Take an existing premium game and explain ow you would make it free-to-play with monetization

Creation Examples

  • Design a game that could ported to a different platform at a later date, such as the iPhone or Oculus Rift.
  • Design an extensive first-person shooter level in an existing franchise
  • Design a new mobile game, and spec out all the relevant details (story, setting, abilities, puzzle elements).
  • Design a choice-based dialogue tree that fits within an existing franchise. Spec out the consequences/rewards for each path.
  • Design a pitch for a new level in an existing franchise, including level design documentation.
  • Design a level that suits both singleplayer and cooperative gameplay mechanics for a given franchise.
  • Design a new weapon, ability, enemy, or mechanic that fits into an existing game.

Implementation Examples

  • Design and implement a new mission or level with our in-house (3D) tools, including new gameplay mechanics.
  • Design and implement a new level with our in-house (2d) tools, including new gameplay mechanics.
  • Design and build, in the engine of your choice, a singleplayer combat space.
  • Design a new level for an existing singleplayer game, and then implement it in the engine of your choice.
  • Take a level design document and use it to implement the level with our in-house (3D) tools

Now, keep in mind: there’s a bunch of design tests easily within reach if you use google. Tests are normally a lot more specific – I’ve seen everything from one sentence to several pages of specifications. Like I mentioned above, tests are usually context sensitive to the studio you are applying for. If I applied to, for example, the studio that makes Assassin’s Creed, I might expect a test on creating a mission for an open world game, or designing a space meant to be traversed from many angles, or to design a new stealth weapon for the player to use.



Below I’m going to outline some tips on how to complete a design test which, depending on the size and questions asked, can be pretty daunting.

Some of these seem like a lot, and they are. Doing paper level design layouts gets a LOT easier with practice, especially if you have some development experience behind you. So if you go around and compare your results to professional level design documentation, don’t get too disheartened.

When I talked to fellow designers in the industry, the main pieces of advice that came up were:

  • Follow the rules!
  • Understand and use space, scale, and metrics appropriately
  • Flesh out story, character, and drama as it pertains to player experiences
  • Presentation of the final submission matters
  • Be thorough and concise in any written portions

Follow the Rules

This advice is first for a reason! Some tests are deliberately vague, which means that part of the test is you coming up with the right set of information to communicate your design. But this is uncommon among design tests – typically, there’s a whole ton of very specific details they want you to follow.

“Design a level with one unique platforming element, two visually distinct areas, and three enemy types. The enemies must fulfill requirements X, Y, and Z. The platforming elements must do A, B, and C. The player can move at speed G, jump at height H, and has abilities M and N. Introduce ability O halfway through the level.”

That’s a made up summary, but you get the idea – tests can get very specific. Sometimes a person hands in a test and the applicant made the most awesome level… but instead of one unique mechanic, they added three, and instead of an outdoor level, it’s a cavern.  If they can’t work within the guidelines for a test, how are they going to work within scope on a 50-person team? Or, if it’s an indie or mobile studio, they may be thinking about budget right there. In practice, a designer can be told “you can have ONE new thing in your level, but you got to make it worth the work.” That’s part of what design tests are going for – they want to see you take on these restrictions and still surprise them.

Mind you, no one likes a rules lawyer. I suggest you follow the intent of the rules, and don’t try slipping anything in under a technicality. If you realize you’ve been fudging the rules, then either scale back or admit it and address it in your documentation – give alternatives that cut down the scope if your initial proposal can’t work.

Space, Scale, and Metrics

This advice is specific to level design tests.

Designing levels can be hard unless you have, and follow, a set of metrics. Know how fast a player can move, how high they can jump, what the optimal range for combat is, how wide a hallway is, how many steps make up a realistic staircase.

Most game companies put all their metrics in meters so if you’re an American you should get used to this.It’s also a lot easier to design spaces for humanoid characters in meters – a person 2m high (6ft), a nice even number. 2D sidescrolling games are a bit different – you may measure things in tiles instead. Below is an example of the kind of metrics you’d want to take into account when designing a 3D space:

The player is 2m high and about .5m wide and can move at 8m/s. Low cover is .5m high, and high cover is 1m high or larger. Roofs are at least 4m tall. Hallways are 6m wide at minimum. Stairs and ramps can rise at a rate of 1m over 4m horizontally. Optimal combat distance for assault riffle like enemies is around 30m, and snipers around 60m. Combat focus should change no more than 90 degrees from the player’s current heading.

Now, don’t follow those metrics exactly – it changes for every game, and every genre, and there are major considerations for singleplayer vs. multiplayer (the latter, of course, needing a lot more space). The sooner you get into the habit of following metrics, the better.

When creating maps, make sure you’re accounting for these metrics and scale. Create a set of objects or symbols in your layout tool of choice (photoshop, etc.) that represent reuseable chunks of your level – floors, walls, pieces of cover (if applicable), doors, interactive objects, etc.

Some things to think about when you’re designing a space on paper, especially a 3D space mapped to a 2D layout:

  • Check the height of ceilings and make sure the player won’t bump their head, have difficulty moving around in, has room for a camera to float around in if this is a third-person game, or that it doesn’t seem too massive or tiny.
  • Think about what the player can see at any given point. Look at the level through their eyes. Take into account what may be occluded or revealed as the player moves through the space.
  • Use a variety of scales to create different moods – claustrophobic spaces and giant open spaces feel very different. When navigating through an environment, switch these up.
  • Clearly identify the boundaries of the gameplay space, especially in outdoor environment. If the player decides to wander away, what stops them from leaving the area?
  • Use a variety of different shapes. Most pieces of geometry are built off of rectangles, but don’t be afraid to add curves, circular rooms, or structures with many sides (hexagons, octagons).
  • Take into account verticality, especially in 3D level design layouts. Balconies, bridges, staircases, pits, hills, elevators, ziplines – all of these can add interesting elements for the player, whether it’s combat, traversal, exploration, or puzzle-solving. All good 3D games make use of these elements, so learn to design with them and how to illustrate them on a 2D layout.

Story, Drama, and Character

In any test where you are designing something with a narrative, you should take into account the overall story and feeling of the level or mission. On the job, you may not be writing the story itself, but you might be responsible for deciding what the player’s moment-to-moment goals are, the pacing of the level as tension rises and falls, and what makes the level (or mission) thematically tied together and stand out in the player’s mind.

One tool I recommend is to create a small pacing chart. This is a graph of the intensity of the level over time, so you’ll see a line that rises and falls and spikes at certain moments. On this line, you mark out major events – new mechanics, combat encounters, boss battles, cinematic or story moments, new visually distinct areas, etc.

If you have 20 minutes of gameplay, then at about 15 minutes you should hit the ‘boss battle’ or the major end climax. At about minute 5 the introduction should be over and real challenge arise, About halfway you might want to surprise the player (i.e. the objective reveals a new goal, they’ve reached a new area, etc.). You want to have highs and lows of intensity and mix where story development goes (low intensity moments) and where the action takes place (often high intensity moments). Obviously, what a “high” and a “low” are depends on the genre – is it a puzzle game or a first-person shooter? (Don’t ask me about pacing in roguelikes – if that’s what’s on your design test, good luck!).

When you’re doing a level design test, I highly recommend you make one of these – even if it’s a thumbnail size – and use it to keep a birds-eye-view on your content.

Here’s the kind of questions you can ask yourself while you’re designing:

  • What are the highs – the most intense points – and lows? Is there too much non-stop action, leading to player fatigue? Is it too slow without enough action or reveals? What surprises the player?
  • What is the mood of a specific space or area? Haunted and suspenseful, or Hollywood Action Film? This kind of information informs art, lighting, audio, fx in that area (explosions going on in the background? Low-level fog everywhere?).
  • What are the major cinematic moments?
  • Do you have allies with you or NPCs that can contact the player? Are there intel drops, notes, or other written information in the level? If so, what kind of information do they give the player?
  • Did you design a boss or enemy? What kind of motivations do they have? Does the environment they are in and their abilities match the enemy design? Does the space need different considerations based on the enemy, such as a flying or swimming enemy, or one many times the size of the player?
  • Is the ending satisfying, narratively? Did the player succeed, or did the villain get away? Does it both satisfy the player (give them something they feel they accomplished) and leave them with a cliffhanger (inviting them to continue playing)?

Presentation Matters

Hand in a highly polished presentation. As a fellow designer said, “Pretend you’d submit it as a walkthrough published in a magazine.” That seems like a high bar but… you are competing against a lot of people who want the same job. Do the best work you can do, but present it nicely too. One of the reasons presentation is important is that it’s a reflection of the quality of work you do and your commitment to polish.

Some tips for improving presentation (mostly applying to level design layouts):

  • Unless you are a professional illustrator, don’t hand-draw level designs. Use software like Illustrator or Visio or Photoshop and it will be much easier on you, and you can fix mistakes faster.
  • Use color and icons, and include a key. I want to be able to scan your map and find all enemies, all objectives, or all pickups at a glance (for example, enemies are red circles, objectives are yellow, pickups are blue).
  • Include annotations and callouts for key events or moments for the player throughout the level, and number them so I know the order in which the player encounters them. You can do annotations with just numbers as a second sheet that says what they are, but I think putting them into the map itself as description bubbles (and keeping the text short!) is more effective.
  • Use side diagrams as needed, even if they are thumbnail size, to help communicate the 3D environment when you’re drawing it on a 2D page. Don’t worry about isometric layouts – they are notoriously hard and I don’t think anyone expects them.
  • Check for spelling and grammar. If you don’t have someone else to proofread, then read your work aloud to yourself.
  • Ask someone to look over your work and give you feedback, particularly another designer or someone with good design sense.
  • Look at video game walkthroughs for examples of concise, clear instructions and ideas on how to layout, color-code, and communicate content in your map.

One thing I would suggest: if you’re making a 2D layout, and the design test doesn’t ask for it to be printable, don’t worry about fitting it into several 8.5″ x 11″ sheets of paper. My experience is that people in the industry all look at layouts on the computer anyway, usually as a .PDF, so it can be any size or shape needed to fit all the content into it, with the viewer zooming and panning for additional details.

Complete, Thorough, & Concise

The ability to write clearly and concisely is a skill honed from years of practice. (When it comes to concise, based on the length of my articles, I am certainly not there yet). One thing I’ve seen on friends’ design tests is a lot of words to say relatively simple concepts – long paragraphs, not much use of white space, too many long sentences that lose sight of the original goal. It can be hard, but really try to pare down what you’re saying into short manageable chunks.

If you have to detail out a level or a new game, make good use of headings, bullet points, and lists to help separate content and make it more readable. Images can say a lot, so think about adding small sketches to illustrate your points – sometimes it’s easier to explain the pacing in a level with an image than with several paragraphs. Imagine that someone needed to take your document and know everything possible about a single element – how easy is it for them to get that info?

Remember, treat anything you write as though it needs to be used by others (leads and peers at your studio, in and out of the design department). One of the ‘truths’ of game development is that no one reads documentation – the reality is that most documentation is bloated and written poorly and hard to keep up to date. Write your document and then imagine putting it in a time capsule and pulling it out a year later to update it. How easy will it be to make the relevant changes? Will you need to read (and re-read) the whole thing? Can you scan it to find the details that you need to change? Are all the details there or are there things missing? This gets into what I referred to early as water-tight – taking into account “what if the player does X”.


When To Refuse a Design Test

Sometimes it’s worth your time to do a design test, and sometimes it isn’t.

I would advise against doing a design test if you haven’t already talked with someone qualified to hire you (i.e. a lead or director, not HR). I don’t think studios should ask applicants to invest the time in a design test if they aren’t already serious about hiring them. But there are many studios that send out tests blindly, so it’s your call as to whether to engage.

Remember, you are interviewing the studio as much as they are interviewing you. If a studio sent me a design test via an automated response immediately after applying, I would say they failed the interview. (This has happened. I decided I did not want to work for that studio).

Not all design tests are created equally. Of those I’ve seen, I think most of them are fair and several of them ask much too much of applicants. I probably wouldn’t do a design test that had me implement a level with scripting in an engine from scratch, no matter how cool the job. But I may be willing to do a lot more work for a highly desirable and competitive studio (like, say, Epic Games) than a new mobile startup with a short history.

There are conflicting opinions on the usefulness of design tests for judging applicants, and whether they are potentially exploitative by asking people to do unpaid work in exchange for the chance to get a job. The latter is known as “spec work” and you’re more likely to run across it in art and graphic design roles in entertainment and advertising. There are also exploitative companies out there that may ask an applicant to do a ‘test’, turn them down for the job, and then go on to use their work in the final game anyway (with questionable legality). Some people have valid worries that if a studio asks you to do a ridiculous amount of work for a design test, then they may be equally exploitative to their own employees (crunch hours, poor quality of life).

For some further reading, I recommend the blog post “Just Say No To Employment Tests” by Stephen Dinehart – you should definitely read the comments for the variety of responses and opinions.

Personally, I think design tests are useful, and I don’t resent doing them and I find the results very insightful. If you’ve never had a job in the game industry, you may not be able to afford to be as picky as someone with several years of experience because job opportunities are much rarer. But that doesn’t mean you have no choice in the matter. Keep that in mind when you’re balancing the need for a job with the amount of work a company asks you to do.

Artifact Hunt, A Board Game Design Workshop

I haven’t been blogging much right as we race to finish Sunset Overdrive at work, so now seems like a good time to talk about and share a cool board game design workshop that I’ve run with Molly Jameson (@UltraRat), a fellow gameplay programmer, and Lisa Brown (@Wertle), a fellow designer. I’ve run this workshop three times for girl scout troops, and once for a young girls game coding after school class.

You can download the materials here:


(Full credit goes to Anthony Ortega and Juancho Buchanan, who created the workshop at Harrisburg University, who passed the lesson plan to Lisa Brown, who passed it on to me.)

It requires:

    • A large poster-sized printout of a very simple board / team
    • A rules handout / team
    • 4 token pieces / board
    • 2 player pieces / board
    • 2 dice / board
    • Pens or pencils

The first step is to set up the boards with all the pieces. I’ve found that teams of four are good for this, but it works well with anywhere from 2-5 students. We’ve run this workshop for 10-18 year olds and it’s worked out really well each time with minimal fuss.

The first thing you do is have the teams play the board game. If you look at the rules, you’ll notice that there are some major flaws in the game’s design. It’s incredibly easy to get a stalemate so that it’s impossible for either player to win. It’s easy to end up in a tie, where both players reach the finish with the same number of points. Almost every single group will one into these problems.

While teams are playing, walk around and make sure that if they have questions about the rules that you can explain them (especially for younger students). Play usually takes 5-10 minutes. We usually wait til everyone has played one full round, and a couple groups have usually played a second by then.

When all the teams finish the first round, that’s when you start to solicit feedback. Some good questions to ask:

    • Did you like the game? Did you not like it? Why?
    • Who won?
    • Did you think it was fair?
    • Did anyone do any battling? How was it?

Usually that’s all the questions we need in order to get teams to open up and talk about their experience. The important thing is to get them to express why they liked, or didn’t like, the game and to think about the mechanics and rules.

The next step is to have the team go back and, together, choose ONE rule that they will change. They can remove a rule, replace a rule, or add an entirely new rule. But they can only change ONE! After they have changed it, they will play it again as a team. This process usually takes about 10 minutes, sometimes a little longer.

I usually offer students extra dice, players, and tokens at this point if they want to involve those in their rules. Wile they are hammering out their ideas, walk around and ask them if they know what they are going to do, and encourage them to play the rules. Some groups will take a long time figuring it out, but we’ve never run into any that didn’t come up with something eventually.

When they are done, and everyone has changed a rule and played their games again, we stop them and ask them a series of questions:

    • What rule did your group change?
    • Did it make the game more fun? Why?
    • Did it cause any new problems? How would you fix that?
    • To the rest of the class, did anyone else change the same rule or do something similar?

You can do a second round, but this is usually where we end it. I sometimes bring handouts on free game-making software for students to take home.

Some of the changes we see are: added tokens to create asymmetrical play, the ability to ‘steal’ tokens from each other, changes in how score is calculated, changes in dice are rolled and calculated during battling, disallowing diagonal movement, allowing movement outside of the play space, removing or changing the movement penalty for carrying tokens.

At the end I usually talk a little about what design and iteration are, and how they are involved in making games. It’s important to only change one thing at a time because every change has cascading effects. If you change too much and the game is better or worse, you won’t necessarily know which change brought about that new dynamic. On top of that, this lesson gives students a chance to design without worrying about the technical or artistic skills involved in game development.

One of the great things is this lesson really runs itself. The kids – and young adults – are always engaged, they are having fun, and they are thinking critically when challenged to talk about the mechanics and how they make the game fun or not fun. I feel like it’s a very good introductory lesson to have at the beginning of a game design class or otherwise introduce students to design.

If you have any questions, feel free to leave a comment or contact me at my email – lizengland07 @ gmail.com