Tagged in: intro to games

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.

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

From Student to Designer: Part 3 – Cover Letters

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 



I’m going to start off this article being honest – I actually don’t see many cover letters, and there’s really nothing that qualifies me to give advice on them. I think I write them well and often review them for my friends and the occasional student, so I am going to write about them anyway. I’m sure there are other articles out there that will contradict me, so, like always, try to use your best judgment!

A cover letter is the first thing most companies read, before they even look at the resume. It should be written specifically for that studio and the position you’re applying to – you really can’t get away with using the same cover letter at multiple places.  Cover letters should be about communicating important and necessary information, not for showcasing your wacky humor and unique personality. You can show off your personality in your portfolio, your projects, or even in interviews, but I would keep it out of your cover letter.

Of course, some people get away with wackier takes, like Tim Schafer’s infamous cover letter. But you are probably not Tim Schafer. Creative cover letters are more likely to turn people off because tone and humor are hard to pull off, especially with strangers..



Your cover letter is 350 words or less.

The reason I put this first is that the biggest mistake I see in cover letters is that they are too long.  So, so long. A cover letter is not the story of your life, it’s not you justifying why you deserve the position, or how much you like games, or why this is your favorite studio working on your favorite games.

Put that stuff in an “about me” section of your website or on your Linkedin profile or a blog post. I would not put it in your cover letter.

To repeat: your cover letter is 350 words or less. Don’t forget the “or less” part.

If your cover letter is longer than that, then start cutting. 350 words seems like an arbitrary number, but really it’s slightly longer than a traditional print page (250 words) so I am giving you guys some leeway. Obviously, if you are over this word count that doesn’t mean you’ve made a grave error – just that perhaps you need an editor. If you are seriously over this number than I think you should stop and re-read this article before committing to such a grave sin.

Everything you put in your cover letter should have a purpose. Every sentence should be delivering new and relevant information to a potential employer. Everything else can be cut.

350 words. Remember that!

Now that this is out of the way, I can get to the bulk of my advice.



There are a few key things I think you should have in your cover letter.

  • Greeting
  • What job you are applying for
  • What makes you qualified for the job
  • How YOU can bring value to THEIR company
  • Where they can find more information
  • Sign-off

That is, incidentally, the formula I use and recommend for people when writing a cover letter. I make each of these a separate section.

Dear Hiring Manager.

I am applying for [position] at [studio].

My relevant experience is [degree] and [shipped games]. I also have experience with [tool/engine] and have [relevant skill].

Your studio excels in [field/type of game]. I can bring value to your studio because I also have experience in [field/type of game], as you can see in [games/projects] in which I used [relevant skills].

I’ve [attached/submitted] my resume and you can find more of my work at [portfolio website]. Feel free to contact me with any questions.

Thank you for your time,

Now, this hypothetical cover letter is awkwardly worded if you were to just fill in the blanks and send it in, so I don’t recommend that. Instead I think it’s very useful for a rough draft. Lets take apart each section.


“Dear Hiring Manager,”

Use a person’s name if you have one – maybe from a business card, from a career expo or networking event, or from browsing Linkedin. If you don’t have a name, I would go ahead and use “Dear Hiring Manager” or “To Whom It May Concern”. Those always feel old-fashioned, but I haven’t found a better alternative.

Don’t overthink this. Definitely don’t misspell someone’s name or address the letter to the wrong person.

What Job You Are Applying For

“I am applying for [position] at [studio].”

This should be one of the first things you write. It tells the reader why you are writing them so they can immediately pull up the job listing, or pass the cover letter on to the person handling that position, or even to just put your email in context. You really only need a single sentence to get this across.

You should know the job title you’re applying for at that company – you get this from the job posting.  If you have to, I would use Linkedin to find the proper title. If you are applying without any open positions advertised, you could write something like, “I am applying for a position in the design department at [studio].” I would not apply to more than one position at once, except at a large publisher that usually fields applications for multiple studios.

(Unless you’re experienced, I recommend sticking to applying to open positions. Otherwise I hope you have a lot of free time on your hands.)

Sometimes it’s good to also mention location –  large publishers have many studios, so it’s important to name the specific studio and not just the parent company (Sony vs. Sony Santa Monica). Most of the time you’ll be sending your resume and cover letter to that specific branch, but if you are applying to an international job – where you, for example, live in the US and are applying to a job in France – it’s might be good to be clear about your willingness to relocate and so they don’t think you’re applying without realizing the distance involved.

What Makes You Qualified For the Job

“My relevant experience is [degree] and [shipped games]. I also have experience with [tool/engine] and have [relevant skill].”

A translation for this is, “I can prove that I read and understood the job description.”

I fill this out by going to the job posting and writing down all the key words. Most postings are great about detailing them out with bullet points and letting you know which details are necessary skills and which are supplemental skills that are nice to have. I would mention as many of those necessary skills as possible here. If the job is looking for a C++ programmer with experience in networking and mobile development, this is where you;d say, “I have extensive experience with C++ in networking and mobile development.” Of course, only do that if it’s true!

Wherever possible, I would give specific examples – such as shipped games you’ve worked on, certifications, or degrees. Just make sure that it’s relevant to the specific job you are applying for.

How YOU can bring value to THEIR company

Your studio excels in [field/type of game]. I can bring value to your studio because I also have experience in [field/type of game], as you can see in [games/projects] in which I used [relevant skills].

This is the section where I get a bit more free form. This is where I show how my interests and the studio’s interests align. Think of it as your way to show them that you are valuable specifically to them by telling them what YOU can bring to the table.

This is also where you could lay down a little flattery. Not a ton, mind you – no one wants to hire a rabid fan. But it’s nice to let the studio know that you are applying to THEM because THEY are your ideal place of employment (rather than just one studio on a list of 50 that you are writing cover letters for…). But I would rather you be honest about your interests than lie, so if you’re applying to a company that only makes sports games and you don’t like sports? Don’t lie about that. I would just neglect to mention it (though, I probably would opt out of applying in that case).

If the studio focuses on narrative games and that is why you are applying, say that, and show them you experience in this subject. If the studio focuses on multiplayer games, hype up your experience in multiplayer level or system design. If it creates free-to-play iOS games, talk about that. I would make it clear that your passion and goals as a developer is an ideal match with the direction of that studio.

Fro example, While above in qualifications you may have written, “I have level design experience in the Source engine,” here is where you can expand to say something like, “I’ve created several multiplayer maps for Team Fortress 2, focusing on asynchronous competitive gameplay.  I would love to bring that knowledge over and continue developing similar experiences on Evolve.” Here, I am showing that I understand the nature of the position, have knowledge about (and admiration for) the types games the studio makes,  and show that this position is part of my career goals (and not just a last-ditch desperate attempt to land a job!).

Whenever I’ve written cover letters, this is the section that ends up being the longest.

Where They Can Find More Information

“I’ve [attached/submitted] my resume and you can find more of my work at [portfolio website]. Feel free to contact me with any questions.”

This is called a “call to action” in creative writing. Once someone has your cover letter in hand and has read it to the end, tell them what to do next. This leads people to find out more information – your resume, your portfolio, your projects. Make it inviting for them to respond – but don’t beg!


“Thank you for your time,

This is simple. Don’t overthink it. You can go ahead and use exactly what I just wrote up there, or whatever your favorite variation is. I don’t think you should sign off with, “Love,” but you get the idea.



Many of the cover letters I see and proofread for friends or others who ask the favor seem to suffer from a few main problems. I wrote them down and canvassed a few other people who have experience looking at cover letters to get an idea of what the common mistakes are. There are probably more than the ones I listed, and some of them may not be too big of a deal with some people.

  • Too short – This is rare, but I have seen it. Usually it means either you don’t have enough experience (so you have nothing to talk about), or you just don’t know how to market your skills.
  • Too long – much, much too common. Do you remember what I said about 350 words? If it’s long, I hope there’s a reason.
  • Not being specific – this reads as a generic letter that could be sent to any company, and makes me think you don’t care about this specifiposition. You wouldn’t (shouldn’t!) do this on a dating website, so don’t do it here.
  • Being too specific – reads like an FBI brief!
  • Not talking enough about your qualifications – says you don’t value yourself and what you have to offer. Like I mentioned before, think of the cover letter as an opportunity to market yourself.
  • Talking entirely about yourself non-stop – This makes me think that while you value yourself, you don’t actually know much about the company. Again, think about how you can help them and try making that part of the cover letter.
  • Applying for more than one job – I recommend making one cover letter for multiple open positions because to me it implies you are either unfocused or desperate for a job. I am sure there’s exceptions but I’ve never seen a justification for it.
  • Applying for a job you are clearly unqualified for – This tells me you don’t follow instructions. Unqualified really means you are a junior level person and apply to a lead position, or you are an artist applying to a programming job. There’s a balancing act here between imposter syndrome and the Dunning-Kruger effect that only you can answer.
  • Applying for a job you’re qualified for, but not communicating this – Try looking at that job posting and make a Venn diagram of “what you know” and “what they want”. I would put any items that overlap into your cover letter.
  • Talking about your passion for games, how young you were when you started gaming, how much you like games, etc.I think some people appreciate this, but I (and others I talked to) have seen whole paragraphs dedicated to this. Loving games isn’t really a relevant qualification for making games – it’s a given.
  • Being jokey, tongue-in-cheek, self-deprecating, or writing a “unique” letter. It can be hard to get jokes across in such a short letter, and harder to entertain an unknown stranger whose tastes you don’t know.
  • Fawning over the studio like a fan rather than a peer – Making games is a job – it’s work, and sometimes it’s hard, frustrating, and imperfect. Hero worship for a creative director, or being the world’s biggest fan of a game, sets off a red flag for me that you may not be objective and critical of your work or your peer’s work. If you want to mention it, its a fine line to walk – but I do know a lot of people who were fans of a studio’s games before they started working at that studio.



That’s it. That’s all my advice – and obviously it’s advice and not a formula for success.

Cover letters are stressful because every single one is unique and there aren’t a lot of examples out there.  Once I started treating cover letters like technical documentation, it became a lot easier. Since every cover letter is context sensitive, I recommend finding at least one buddy who will help proofread for you – not just to catch spelling errors, but also to gut check whether your cover letter and the job description seem like a good match. Remember to keep it simple, keep it short, and keep it to specific and relevant information.