Tagged in: student

From Student to Designer: Part 6 – Entry Level Design Jobs

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. And as always, this is just my personal advice!

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

There is a myth that there is no such thing as an entry-level position in design.

It really is a myth, and a hard one – it seems – to dispel. I run into this idea from aspiring designers and industry people alike and it always kind of stumps me. Back in the day (not really that long ago), I was a student , and I got an entry-level job on graduation. A bunch of other students with me did too. And I’ve since worked with a bunch of people that went straight from being students to entering design (and a few who skipped the student route and came in from various paths).

The point is: there ARE entry-level design jobs. Why do people keep saying there aren’t? I have a few ideas:

  • aspiring designers tend to rule out entry-level postings because they read them unforgivingly (such as reading preferred as required)
  • aspiring designers tend to rule out entry-level postings because they aren’t qualified (lack of side projects, modding work, personal games, etc.)
  • aspiring designers don’t know how to find these jobs
  • the game industry is kind of infamous for non-standard job titles, so “game designer” may be entry level at one place but equivalent to creative director somewhere else
  • there are about one open entry-level design job for every one hundred hungry aspiring designers (these are totally made up numbers! but you get the idea – competition is fierce!)
  • it is common for aspiring designers and recent graduates to spend a long time (more than a year) trying to land that entry-level job

 

What Kind of Design Job is Entry Level?

First I want to clear up what kinds of design jobs are entry level, and what type of design jobs are not. This seems to be where a lot of confusion comes from when asking for advice or looking for jobs. This is a general rule of thumb, not some kind of law.

Content vs. Systems

When some people talk about “game designers”, they are talking about designers who are focused on the rules, mechanics, and systems in a game. At smaller companies, this might essentially be the lead designer or creative director. On small mobile projects they may be the only designer on the game. This demands a lot of prior experience, practice, and expertise. These are not (normally) entry-level positions.

So if you hear someone say that “design is not an entry level job” they are usually referring to systems and lead roles.

When others talk about “game designers” they are referring to everyone in the design department. The other type of design opposite systems – if I were to split them up – would be the creation and implementation of content. Some common examples are levels, quests, missions, and puzzles. Content designers may not be involved in the overarching rules and mechanics, but rather use those mechanics as a palette to create the game. Not all games have lots of content that can be designed, especially procedurally generated environments or gameplay focused on systems (think roguelikes or match-three games). But most AAA games have a HUGE amount of content and an appropriately sized design team to handle that responsibility.

So if you hear someone say that “design is an entry level job” they are usually referring to content designers.

Now, that is not to say that systems are better than content. At many companies, content designers also own systems, and content is obviously EXTREMELY important. It just so happens that it’s easier to split off content and implementation-focused roles into entry level positions than it is for systems.

If you are a aspiring designer who does not have prior (paid) industry experience in design, I suggest preparing yourself for a content designer position. This is why I recommend students focus their free time or coursework on creating games and levels in various AAA toolsets: it’s all about implementation.

 

JOB EXAMPLES

So I want to debunk the, “There are no entry-level design jobs!” refrain right now.

To do so, I went around and collected a bunch of entry-level design positions currently available. Since these jobs may be taken down by the time anyone reads this, I’ve taken screenshots of them.

Please note: I am not advocating or endorsing any of these jobs. This is about giving you an idea of what an entry level job position reads like (so you can recognize them when you see them), and what kinds of work or qualification they expect from you. This is for illustrative purposes. It’s by no means an exhaustive collection – I only spent about an hour grabbing them.

Trends in Entry Level Positions

So I like data, and I realized after I collected the above job postings that I now have a whole lot of information about what different companies expect from junior designers! Luckily, there’s a lot of crossover in the content between all these jobs.

There are a few key elements that stick out as the most common responsibilities or requirements:

  • Great communication skills
  • Collaboration and teamwork
  • Work with all stakeholders in your work, across all departments
  • Write and maintain documentation

These are all mostly soft skills, and the only ones I think you can show off in a portfolio are documentation (this includes 2D level designs) and evidence of working with a team to create a game. I do want to reiterate: these are by far the most common requests on job postings, so if anyone thinks that game development is an antisocial activity then they are dead wrong.

After that, you start getting into the most important hard skills:

  • Experience in a game-editing program
  • Author and implement content (levels, quests, combat, puzzles, etc.)
  • Familiarity or working knowledge in scripting

Those are the most common ones. I don’t feel so bad now for my portfolio advice being so heavily biased in favor of implementing levels and gameplay in a 3D engine.

There’s lots and lots of other skills listed, with lots of one-offs (military experience? working with outsourcers?) that are specific to a single job and based on context. There’s just a few common or interesting details I found that I want to call out:

  • Degrees are usually preferred, not required, if they are listed at all. They often aren’t listed on the job posting at all.
  • Programming experience is very desirable, and a good portion of entry-level design jobs involve scripting.
  • Several entry-level jobs involve acting as support for more senior designers, who will rely on you to implement and iterate on their designs.
  • Many list a specific genre, game series, or gameplay mechanic that they wish applicants to be familiar with. This makes sense where, if you make FPS games, you would want a new member of the team already up to speed on FPS mechanics.
  •  At least one asks for evidence of major gamer cred (high level MMO character!) but I have seen similar requests in other places. This is unusual, but not unheard of.
  • Design skills are usually vaguely defined (“understanding of fun”) or as a long list (pacing, flow, systems, mechanics, etc.). The point here is that if you are applying to a design position, it’s just understood that you should be knowledgeable about all the elements of game design.
  • There really is a pretty big range of jobs, once you get passed general design skills, from mobile jobs with more business-related skills, to level or combat encounter design big AAA studios, to scripting-focused jobs that lean on programming knowledge.

The last thing I want to cover is “prior experience” since this is a sticking point for a lot of aspiring designers that I talk to. I get the feeling a lot of people opt out of applying to jobs if they ask for prior game development experience, without realizing that this totally includes side projects and other portfolio work. Prior game development experience, if it doesn’t reference a shipped game, means that experience you earn on your own (school, modding, side projects) still counts. This is something a lot of people get caught up on.

If a job posting asks for 1-2 years of experience in the industry, I personally tend to read these as entry-level. I encourage students to apply to them anyway, assuming you fit the other criteria, and instead read “in the industry” as “modding or large game projects”. Once you get a bit further, into 3-5 years, the jobs tend to be looking for people who are more traditionally experienced at companies.

If a job specifically asks for a shipped game, they generally mean traditionally shipped (such as a console or mobile title) and as part of a paid position at a company (not a side project, or game you made by yourself).  Remember how common communication and teamwork skills were? There’s a huge difference between working alone on a game and working as part of a team.

As always, there are all kinds of exceptions to what I’ve written above but, mostly, I’m hoping that some people feel a bit more comfortably finding and applying to entry level jobs, and if they don’t at least realize what skills they need to work on to break in. Please note that my examples I included and pulled from aren’t a real sample size – just what I could find in a short time period. There are lots of other entry-level jobs out there, and many of them have their own needs and idiosyncrasies.

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.

 

EXAMPLE TESTS

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.

 

SOME TIPS

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:

http://www.lizengland.com/resources/ArtifactHunt.zip

(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 

 

COVER LETTERS

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..

 

WORD COUNT

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.

 

FILL IN THE [BLANKS]

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,
[Name]

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.

Greeting

“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!

Sign-Off

“Thank you for your time,
[Name]”

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.

 

COMMON PROBLEMS

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.

 

CONCLUSION

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.

From Student to Designer: Part 2 – Portfolios

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

“Your portfolio is only as good as your weakest project.”

-everyone I talked to

I see a lot of design portfolios from students – not as someone hiring them, but rather because I review a lot of them to give feedback before they are even sent out – but I think most of them are insufficient. A good portfolio from a student (or just someone aspiring to be a designer) is pretty rare and takes a lot of work to get together into a manageable shape. There also seems to be a big disconnect between the what the  industry needs (based on job descriptions and what designers do at their jobs) and what schools or advisers are telling people they need.

Good news: if you have a good portfolio, you will easily stand out – and that’s important because there are so many students looking for jobs, so competition is pretty fierce

Bad news: a good portfolio requires a lot of work, and you may already be graduating without any appropriate portfolio pieces, putting you at the starting line all over again. This can be really frustrating, especially since a lot of school sell you on their programs by promising jobs.

 

PURPOSE OF A PORTFOLIO

A portfolio proves that you have the skills, knowledge, and desire to work in game development in your desired role (designer, artists, programmer, etc.). Since this is a creative industry, a prerequisite to getting a job is almost always to create something – and a portfolio is where you show off what you have created.

For people already in the industry, your portfolio is usually your list of shipped games (and many of them skip making a portfolio once they’ve shipped games anyway). Until you’re in that position, your portfolio is the only proof you have that you can ship games. Of all the people I talked to for their advice and recommendations when writing this article, every single one said that your portfolio is the single most important thing for an entry-level designer.

Your portfolio should answer questions like:

  • Do they have the technical skills to work in AAA editors?
  • Have they done comparable design work similar to what they would do in the industry, such as level design or mission scripting that could fit into a shippable game?
  • Can they communicate about design clearly and intelligently, using industry terminology and common design concepts?
  • Is their work interesting, with good, clever gameplay, and maybe a bit ambitious?
  • Can they iterate on something with a high degree of polish? Can they finish something they started?
  • Do they understand the game development pipeline? Do they know the separate roles? Do they understand how one goes from paper designs, to graybox, to an iteration cycle that results in a polished game?

Back when I wrote about websites and resumes, I implied that your portfolio goes on your website. This is true… mostly. There’s design portfolios out there that exist in .PDF format and I think that’s fine. Just keep in mind that my advice assumes a website, but not everyone uses one.

 

WHAT GOES INTO A PORTFOLIO

In the process of answering the above questions, there’s the practical stuff – what you are actually showing off in your portfolio.

This article has been revised four times so far, each time to take into account feedback I’ve gotten from other designers. I do see a lot of portfolios, but that’s mostly because I volunteer time to review them before students send them out in the search for jobs. But my experience still pales in comparison to people who do spend their time hiring – they see a lot more. So I encourage you not to take my advice verbatim, but rather to get a few different opinions and maybe Google what other students are doing to see how your work compares to theirs.

What I Expect

Below is what I look for in every design portfolio I see and I usually point them out to students when they are missing.

  • 3-5 projects that show the breadth and depth of your design experience
  • At least one of your projects should be in a 3D toolset like Unity, Unreal, or similar. Unity, especially, has become a common tool for students to use since it’s similar to many AAA toolsets and it’s also used in a lot of mobile and indie development.
  • At least one project that displays iteration and polish work. The idea here is to show that you can bring something to completion.
  • Clear explanation of your role on the projects and key design elements
  • Video walkthroughs of your projects, although clearly annotated screenshots may be so long as you include downloadable files. Regardless of video, you should always have screenshots. I know video can be an absolute pain to make, but I get a much better feel for student projects by watching one than just looking at screenshots and reading about them.
  • Your projects do not have to look pretty. Designers are not (normally) responsible for art, so I understand it if your levels consist largely of well-organized gray boxes. A good-looking game can get eyeballs faster and can be an advantage, but ultimately you’ll be judged on your design skills, not your art skills.

What I’d Like

Outside of the major elements, there’s other stuff you can add to your portfolio that will improve it. Mind you, none of these can replace those core portfolio pieces mentioned above, but they can supplement them.

  • Programming work, clearly demonstrating your coding skills and technical knowledge. If you can code, you should show it, even if you are not applying for a programming position because ultimately games are pieces of software.
  • Group projects can show that you know how to work with people. Making a game as a team, such as a modding group or as a pair, is a lot harder than making one by yourself. Be careful about only showing group projects, since it can be hard to tell what you – personally – can accomplish.
  • Press coverage on your work from Kotaku, Polygon, RockPaperShotgun, or other media outlets. If gamers and games journalists can recognize your talent, I want to know.
  • Industry prizes or awards like being an IGF or Make Something Unreal finalist or featured in the AppStore. This is about the industry recognizing your talent.
  • In depth knowledge of a closely related field, such as computer science, usability or user experience design, architecture , and economics or mathematics. For example, using your architecture background to describe the decisions you made in a level you designed in Unreal is really cool and I’d love to see that kind of thing in a portfolio.

What I Don’t Want

Here’s some really common general mistakes I see on portfolios. I talk a bit more about what I’d consider problematic portfolio pieces later, but consider these my high-level guidelines:

  • Unfinished games or game jam games that did not get any iteration and polish work after your 48 hours were over. This would be like an artist putting up sketches as major portfolio pieces, instead of finished work.
  • Creative writing samples, unless you are applying as a narrative designer. I have seen: lore bibles, pen and paper campaigns, short stories, screenplays, and rough drafts of an epic fantasy trilogy. These are almost universally bad, which makes me wonder if your design work is equally bad. Writing is its own skill, and it’s a hard one to master.
  • Requiring me to purchase your game in order to evaluate it. Now, it’s okay if you’re selling a game and want that as a portfolio piece, but I think you need to give a potential employer enough information about it: video walkthroughs, trailers, screenshots, demos, sales numbers or accolades.
  • A lot of focus on non-gameplay projects: music compositions, 3D modelling or character design, textures, particle effects, lighting. Each of these are their own job on a AAA team and not the job of a designer, though the job roles get fuzzier at mobile and indie studios. The main red flag is if you avoid showing off gameplay.
  • Offensive work that insults or stereotypes a class of people (sexist, racist, homophobic, etc.). This includes stereotyping disadvantaged people like the disabled or the homeless, and overly sexualized women. I think the exception here is a game that was traditionally shipped that you were not sole designer of (Left Behind the video game, an adult game for Playboy, etc.). Sometimes artists can get away with some more eye-raising content, especially with female character designs (I’ve heard some complain more that it’s uncreative than insulting), but since you’re a designer you should be able to avoid this.

 

GOOD & BAD PORTFOLIO PIECES

Your projects are your games or the levels you’ve designed. Veteran game developers fill this with the games they’ve shipped professionally. As a student, though, it’s not likely you’ve “shipped” any games, so instead this is where you put your side projects, mods, and stand-alone games you’ve made by yourself or with a team.

Safe Projects

Here’s a list a projects that I propose as good portfolio pieces – they are safe, they show off a lot of technical skill, but sometimes they aren’t so great at displaying your creativity. Obviously this is not a comprehensive list! Consider these suggestions as the equivalent to writing prompts.

  • A Skyrim Mod with a new dungeon interior, and a quest line with heavy branching and multiple ways to complete your objectives. Make sure to include combat. The quest should feel like it belongs in the shipped game while still presenting something novel to the player.
  • A Team Fortress 2 multiplayer map that was highly rated by the community, with details on the mode and design considerations when building it. Provide a top-down 2D overhead map and mark out the critical path.
  • A Left 4 Dead 2 map that covers a 10-15 minute defense prior to helicopter evacuation, with clear explanation of the different waves of enemies, the entry and exit points, the main front lines, and how the level design can be used by different enemy types.
  • A game made in Unreal 3 or 4 that creates entirely new gameplay, such as a third-person puzzle-platformer, with at least 20 minutes of gameplay. The gameplay, art style, aesthetics, HUD, and similar elements should all be unified, but do not need to be all that pretty (designers are not responsible for art!)
  • A Portal 2 level that is about 30 minutes of gameplay, with video walkthrough, using one new mechanic you designed ((ex: time travel, light, malleable gravity) in combination with mechanics in the shipped game. This should look visually very close to the retail game and have a great deal of polish.
  • A 3D adventure game made in Unity, with intuitive puzzles, a clear story, good aesthetics (but do not need to be pretty remember)

You get the idea…

All of these are 3D engines – not a single 2D game in sight. That’s because there’s a different level of complexity in designing for a 3D game environment, and that’s what you’re expected to design for at most studios. Now, this comes down to a pretty predictable list of projects mostly in FPS engines for mainstream games, but those are also great engines to know and these projects will help make people comfortable with your technical skills. Consider this a baseline before you start throwing in curveballs or more unusual projects.

Get creative with these. Don’t just make more of the same, but rather make something that will stand out on its own. Focus on the gameplay, and how you can innovate within the constraints. I wouldn’t make, for example, a map for Team Fortress 2 that is largely indistinguishable from other maps by fans and hobbyists. Make sure something in that portfolio piece stands out as an interesting central focus.

Unusual Projects

Unusual projects can be good and make you stand out, and help you kind of define the type of designer you are. These are great opportunities to show off your creativity, just don’t forget that familiarity with certain tools is really important.

  • A 2D iOS game with interesting – and new! – mechanics. At GDC a student showed me a turn-based platformer… roguelike? Weird, but it took about 10 seconds for me to understand it and it was immediately obvious that the gameplay was unique and fun. It also had clean aesthetics and a professional presentation.
  • A board game or pen-and-paper game that you’ve exhibited at conventions, and iterated on extensively. Include a video of people playing it, or make it really easy for me to understand in a few quick glances how it plays out.
  • A piece of hardware, such as a new controller, with a game built for it. Another student at GDC showed me pictures of an interactive table device that he had set up at conventions that dealt out real-life quests and scavenger hunts. That was pretty cool. Mind you, there’s an entire industry devoted to hardware and toy design, and it’s separate from the mainstream games industry, but I think this still makes for a good project so long as you have other things on your portfolio.
  • A game that uses unusual control schemes or hardware, such as Kinect or Oculus Rift. Alternatively, I’ve seen a few 2D games that have used the guitar, dance pad, piano, the move controller, and similar peripherals. I’d be careful that these are actually interesting (and make me interested in them!) rather than gimmicks.
  • Any game that has been shown at industry events such as Indiecade, Indie Megabooth, the Experimental Gameplay Session at GDC, a finalist at IGF, or similar. This shows that you’ve had peer recognition for your design work and can make something that is marketable and/or interesting to other people.

What these projects have in common are that they are well-designed, immediately understood, and outside mainstream AAA games.

One of the problems I often see is that student portfolios only have ‘unusual projects’. That might be okay if you’re applying for, say, a job at Sifteo or at an indie incubator. But it doesn’t work all that well if the job description says you need to build missions for an open-world crime simulator, not make a game to be played on a piano. The latter can stand out though – especially if the game is good and not just a gimmick. Good design is pretty universal, so if you can show you have the design chops then people miiiiight let you slide a bit on the implementation side.

Still, so many 3D game-editing tools are free, so you don’t really have an excuse not to get some experience in one!

Projects to Avoid

There’s a bunch of projects that I think are too simple, not complex enough, don’t show off your skills or knowledge as a designer, or don’t present very well. These are the kinds of projects I would avoid because they will bring down the quality of your portfolio. There are exceptions, of course.

  • 2D platformers similar to Super Mario or Metroid. There are so, so many platformers, and they are so easy to make, that this is not going to stand out unless you have some special hook. In general, these come across as amateur projects. Though, obviously, if you made something the quality of Shovel Knight or FEZ then I want to hear about it.
  • A game that has too many rules and layers of gameplay that I cannot understand it. One of the reasons games like FEZ and Antichamber show really well, is that you can immediately ‘get’ the gameplay. If you find you need several paragraphs in order to explain the core gameplay, it will probably not show well. Usually a video fixes this, but if it doesn’t or if you cannot provide a video, I suggest skipping this. This can be really hard with tabletop games, so for ideas on how to show those off I recommend looking up successful kickstarters for boardgames – they are usually pretty good at communicating what is cool about the project.
  • Games that are entirely about environment art and ambience. Imagine your game is set in a graveyard and there’s no… gameplay, just a lot of art, moody music, custom effects, animating tree limbs. I am suspicious of these if there are no other games on your portfolio focused on gameplay mechanics. It makes me think you don’t know the difference between a designer and an environment artist.
  • Clones of games, like Tetris, Breakout, Pong, etc. These are first-year programming projects, and cloning games does not show off your design skills. These could be supplemental works on a section in your portfolio where you show off your programming skills as a designer, along with other scripting examples, but are not stand alone pieces. Of course, if you redesign an old games – and make something like Speed Chess – that could be a great portfolio piece as an “unusual” project.
  • Projects based on tutorials or classroom assignments. A lot of people do these tutorials. All your fellow classmates do the same classroom assignments. I don’t think these help you stand out. I’ve even seen a project based off of a tutorial I also went through myself, which unfairly made me compare my results to the student’s.
  • Prison or sewer levels. Okay, maybe it’s alright to include them, especially since every AAA video game has a prison or sewer level. But it’s kind of a joke I’ve heard from people in the industry, and the result is that your project already looks boring.

The exception to the rule on all of these is: if your game got recognition, I would put it in anyway. If you made a level that is all mood and environment art and no gameplay, and it’s called “Dear Esther”, you bet that I want to know about it. And if you’re REALLY proud of your 2D platformer or creative writing sample or prison level, go ahead and include it. Don’t say I didn’t warn you, though…

How Many Portfolio Pieces?

I used to say to follow the 80/20 rule: if you have five projects, then four should be from the “safe” category and one from the “unusual” category.

Since writing this article initially, I’ve backed off quite a bit on that – largely from talking to others who have become designers and had portfolios that deviated a LOT from my suggestions. I found they made a couple really interesting “unusual” projects, had a relatively impressive resume (including internship experience), and – obviously – they are really good designers who even as students could talk intelligently about design. I think the hard part is getting that interview where you can demonstrate that knowledge.

Instead, my recommendation is to have at least one of those safe projects – detailed, polished work that you’ve iterated on a lot over time from a popular AAA engine like Unreal or Unity. After that, I still think your portfolio pieces should be substantial projects, and not quick game jams or weekend projects, but once you’ve shown off your technical aptitude then you have a lot more leeway to be creative with the rest of your portfolio.

I do like seeing at least three good, sizeable portfolio pieces that each stand out from one another where each is a different genre, or at least focuses on a different kind of gameplay. For example, a piece focused on combat, and another focused on puzzles, and a third that showcases your level design or scripting talents.

 

HOW TO SHOW OFF A PROJECT

So now that you’re done throwing out all your current portfolio pieces (I kid… don’t do anything drastic!), I want to talk briefly about how to show off a project.

Give me a single page with all the information about the project.

Clearly label it with the following information:

  • Engine it was created in (Unity? Unreal? Custom?)
  • Specify if there’s something unusual with the format (i.e. if this is a hardware project, or Oculus Rift game)
  • If you were the only person, or if you had help / it was a created by a team
  • Any downloadable files and instructions on how to use them, if necessary (note: if it’s a map or mod of an existing game, chances are no one will play it, but even then I’d like to see it as an option).

You can use bullet points, a table, sentences, whatever you want – just make sure it’s easy for me to scan the page and quickly find this information.

Next, you should summarize the piece and tell me why it’s important. This is a brief (1-2 sentence) explanation of the gameplay and highlighting one element – is it the complex scripting? The level of polish? The boss battle? The combat design? The puzzles? This summary should focus on the GAMEPLAY. I want to know what kind of design work it entailed.

Here’s some supplementary material that will give me details about the project:

  • Screenshots that show off the gameplay. Taking pictures of gameplay can be hard, but it’s important. Make each screenshot show off something different in the game, rather than several angles of the same thing.
  • A video walkthrough of the game or level. Make sure you use a simple format (like embedding it as a YouTube video), and that it is not auto-playing. Trailers for a game also work well, but the point of this is to show off gameplay, not sell a product.
  • Written details on the gameplay, how you implemented it, what your goals and challenges were. You should be specific, clear, and talk about one part of gameplay in depth rather than trying to explain all of it – this is where I get an idea of how you think and whether you understand good design and game development. Again, this doesn’t need to be long – a paragraph may be enough, depending on how much detail you want to go into.
  • Any 2D maps, or overhead screenshots with overlay diagrams, identifying key gameplay elements like the critical path or pickups or interactive elements.
  • Design documentation you’ve written for projects. These could be level design docs, quest designs, game design ‘bibles’, systems balancing excel sheets, flowcharts, or similar. Please do not include any giant 50-page beasts – no one is impressed by the length. Short, concise and actionable documentation is great to see, as are visualizations of game design flow. If all you have are giant unwieldy documents, then I would skip this.

Besides that, it’s a bit more free form depending on the project you’re showing off. A lot of designers I’ve talked to say they like to see how a project evolved over time to get an idea of how you think and iterate. This is where early documentation and before/after screenshots can help. I would definitely include any accolades or awards, or any special details that you think makes this project stand out, but remember that more is not necessarily better and you don’t want to drown someone with a ton of reading.