Hey guys, my first game, Polymer, released today.

I did all the programming, music,

and art, and I'm super proud of myself. It's already rising pretty quickly in multiple
countries' charts. Also, it's 50% off for launch!

Screenshot
Trailer

I thought you might be interested in my journey from someone who literally knows
nothing about programming to a published game developer. I know that this type of
post would have been really helpful for me when was just getting started. Hopefully I
can inspire someone in a similar situation!

THE STORY

About a year and a half ago, I decided that I wanted to make a game. There was a
problem though. A big problem: I hadnt programmed a day in my life.

I always thought it would be pretty sweet to be a game developer but it was so out of
reach that it never felt like a realistic goal. But one day in October of 2010 I just decided
to go for it. I had nothing to lose so why not?

I learned bits and pieces of a bunch of languages, including C, Python, ActionScript,

and Objective-C. Honestly though, I really dont think it matters too much what
languages you learn on. If there is one piece of advice that I can share about learning to
program, it is this: PROGRAM A LOT. There really is no other way to learn besides
doing, doing, doing, doing, and doing again. Every time you make something new, you
find a thousand things that you did wrong before. Every time, you chisel away at your
horrible programming skills until youre finally able to make something that you can be
proud of.

Along the way I made a ton of stupid, fun, and weird mini-games to help me learn. I
made:

A game about a man-rodent hiding in a town, attacking the townspeople

A text-based minesweeper clone with a custom-sized board and mine-count
A game called Pizza Guy, about a guy who had to (you guessed it) deliver a
pizza while trying to jump over an endless barrage of pipes of varying heights.
The only result was loss. There was no win.
A game called Party Man, in which the the protagonist is driving along a grid,
trying to reach a party. The problem was that my programming was still pretty
bad at that point, so he kept literally crashing the party.
An app where you could create sequences of musical phrases in the pentatonic
scale
A flash clone of the classic snake game
A flash clone of those driving-through-an-ever-shrinking-tunnel games

Finally, I decided it was time to make a real game. Pretty much all of Polymers
creation was iterative design. I never had an overall plan. I kept thinking, I dont know
how to make a complete game. I just know how to make basic gameplay, as if there
were one way to make a game. But I realized I just need to make it however I could,
even if it wasnt necessarily the right or best way.

When I sent the game to beta testers, I was convinced that all I really needed to do was
polish it up a bit. Oh man was I wrong. I had so many amazing suggestions from my
testers that I just had to implement. I probably said, Ive only got one or two more
things to add, then Im done! a thousand times.

Submitting to the app store was terrifying. I was so paranoid that I would forget
something huge. Something that could break the game or get it rejected. But at the same
time, it felt amazing. I finally did it. My creation, my baby, was done. I went from not
knowing a thing about programming to finishing a game that I was very, very proud of.

Its already gotten some awesome previews on Touch Arcade, Indie Game Mag and
Gamezebo.

Of course, I hope Polymer sells well. But even if it doesnt, Im proud of myself for
actually carrying this whole dream through. Ive had trouble in the past making the
journey from start to finish on big projects. Starting is easy. Finishing isnt. Plus,
programming Polymer has taught me so many amazing things. Theres a lot of really
messy spaghetti code, but I honestly dont care too much because it works. Next time I
make a game Ill be able to build upon what Ive learned, and hopefully make
something even more awesome. Until then though, Im hoping for the best with
Polymer. And I hope you enjoy it!

TLDR:

A year and a half ago, I had no clue how to program

Today my first game, Polymer, was released to the iTunes app store
I did all the programming, music, and art
It's 50% off for launch!
Screenshot
Trailer
App Store
Facebook
Site
Twitter

Hello guys, I have finally published my first game Head 'n' Trails after working about
4 months on it. Before telling you about this game, let me walk you guys a little through
my background. I am a Mechanical Engineer and I have completed my bachelors in
2015. I was always a gamer, but more than that i was a thinker. I always keen to figure
out whats happening in the back end of the games I've been playing. So, after
completing the degree, I took a chance in the learning mobile game development, since
more attention is given on the gameplay that catches user attention for a while rather
than the graphics. I tried to focus myself in learning the code at first but to be honest,
everytime after a day or two, I called it a quit. The coding was my nightmare. I couldn't
figure out what to do, how to start, which language to learn,how to learn? So, I started
searching the internet about the games that can be made without coding. I was amazed
on how many of these popped out in the searches. The first one, I tried was this drag
and drop app-building software called mobincube. Even though the software was only
for apps but it did taught a little about the basic functionality of the smartphones like
button click and image view etc. I used mobincube for fun for couple of weeks. During
which, I released a pretty basic app called Animal sounds and facts. It got roughly 40
downloads but i was pretty happy with the fact that i have created this.

After creating my first app, I realized that i gotta be serious this time. So, I again
searched internet about the softwares for building cross platform games without code
and are cheap. This time, after reading several reviews, I stopped my search at
Gamesalad . This was again drap and drop game building engine that requires no
coding. However, you should be aware of using logics in order to put functionality in
your game. I started learning the gamesalad through bunch of tutorials. To be honest, It
just took me a week to figure the entire scenario of the game development through this
software. There were blocks of code and all you have to do is to figure out how to use
these three statements - 'If,While,For' and when you figured it out, just put your logic
around it. I know many of you guys will not agree on this but I do say that these three
statements is the heart of any game coding. I am really thankful to the Gamesalad that
taught me these in a pretty easy way. Now that i had a little experience with the engine,
I began brainstorming ideas for the game. I came up with a bunch. There was a problem
with developing on gamesalad and that was its limited functionality. Always, there
would be one or two things that you need to sacrifice if you wanted your game to be
completed through these no-code game engines. After arguing with my own mind, I
finally gave up. I decided that i have to learn code in order to create a game of my
choice.

I always heard of unity3d as one of the best engines for game development and the dev
team have recently updated the engine for 2d development too. Though nervous at first,
I downloaded it through their site. Looking at the interface first time, my reaction -
'Woah dude, this looks too professional. I don't think this is for me.' There were so
many components and functions. I couldn't even find where to write the code. So, I quit
the software and began searching for tutorials on internet. I asked around and a bunch of
my friends told me to look for Brackey's Tutorials. I followed the tutorials alongwith
the documentation as well as video tuts given by the unity3d team on their official
website. It took me a month to get through the basics of the engine and further, a month
more to understand the implementations of the scripts.My experience with gamesalad
really helped me to get through some of the important aspects of coding in C#. As I
progress in learning the engine, I started realizing how easy is it to use this product.
Furthermore, the cross platform build is just a click away.

On new year's eve, I committed to resolution that I have to create a game this year no
matter what. I can't quit. The main objective was to complete it all by myself without
outsourcing any of the part. On 3rd Jan 2017, I started this project having a little
knowledge of Unity3d alongwith C#. I had a bunch of games that I downloaded from
playstore on my ASUS Zenfone Max. Most of these games were having little to no
graphics, great gameplay and ability to engage users for hours, Which was exactly what
i was looking for my game. Five games were responsible for the inspiration for my
game. I collected all the unique factor in all those games,created a prototype and started
working on a unique gameplay. Since the beginning , I knew I had to learn photoshop,
illustrator, after effects for graphics, UI and video trailer. In a month (Upto 5 Feb 2017),
I almost completed 65% of all the game which included, the gameplay, obstacles, home
screen UI. I put 10 hours daily in the development in which I gave 8 hours to game
development and 2 hours for learning and practicing Photoshop as well as Illustrator.

I got a job in my field (Which I am not satisfied at all with, but have to do for a living )
on 15 feb 2017 which really hindered my pace. At that time, I only had around 5-6
hours for project. Due to this, It took me 1.5 months to just create remaining rest of UI,
gameover screen, title and a bunch of improvements in the gameplay. On 7 April 2017,
I got a decent looking game. I , then started looking for my options in the game sounds.
I used free online resources for my sound effects.However,I couldn't find a decent
background music that would matches my game. So, I decided to do it by myself. I
began looking for the music creating softwares online. To my luck, I came across
Soundtrap . This is pretty easy for composing music. There are already several free
music samples available that you could use for free in composition. After a week of
trials, I finally able to came up to create a music that could somehow relate to the
gameplay.

After finishing the game, I looked up for tutorials of After effects in order to create
video trailer for my game. I coupled some of my gameplay recordings (AZ Recorder
App) and implemented basic transitions to them. Further, I shortened the gameplay
music on soundtrap to make it for video trailer. I may sound like a cheap guy who don't
want to spend even a single penny but trust I am not at all like that.

The reason for not spending any money was to not rely on someone if you wanted to
create a game in future. I may not develop something that good right away but all it
takes a little practicing to achieve the desired results. So, if you ask me now that if i am
a developer. Well, I would proudly say, 'I am'. I wrap it up for now but i do want to
suggest new developers that don't worry if you unable to get your code right, or unable
to achieve desired results. The fact that you are trying already proves that you are
willing to grow. If I can do this, I believe you can do this too.

Here my game link on playstore - Head 'n' Trails. Thank you guys and sorry if my
english was bad.

tl;dr A mechanical engineering student who wanted to develop games.Complete

beginner in this field. Tried different no-code required softwares to make the game but
gave up due to limited functionality. Finally, ended up making the entire project on
unity3d after watching tutorials. Learnt adobe softwares like photoshop,illustrator,after
effects during the development. Created background music on soundtrap. Took 4
months to complete. Here's the game.

Gaining experience by making games in a short period of time

People have been making games in shorter periods of time for a long time now. In fact,
my Vlambeer co-founder Jan Willem Nijman started most of his career at the
Poppenkast, a community that would often push itself to make games with three hours
or so without proper warning. Someone would just post a message with a theme and a
deadline, and dozens of little experimental games would pop up.

When Im recounting Vlambeers history at events, Ive often been heard saying that
most of the hundreds of games Jan Willem would make were terrible. Its true. Of Jan
Willems impressively prolific history (which includes pre-Vlambeer titles like
COPTRA, 10800 Zombies, Pro Killer Man, The Gutter and Atomic Super Boss), most
of the games he made are failures only seen by a few, often only by himself. He carried
that process with him into Vlambeer, where well often glance through a folder with
hundreds of prototypes we made discussing what to focus on next.

One of the most common requests for help I get is people asking me how to deal with
their dream game failing. Jan Willems approach seems best to me, a giant folder full
of failed little prototypes, a folder in the back of another folder with interesting
prototypes. Its a repository of knowledge, one level deeper into his mind, of what
doesnt work and what does work, but needs to be fleshed out.

Jan Willems superpower is a solid understanding of interaction, impact and values.

When we just started, he would simply blurt out a magic number to fill in for a certain
parameter when Id ask. Being a programmer, Id program a slider to play around with
the value, and without fail end up exactly at the value I was told in the first place. I
thought of it as a superpower at first, until I realised this wasnt some magical
understanding of numbers - it was hundreds of projects worth of experience.

Thats when i realised that design experience isnt in the size of your games, or even in
the scope of it - its in the number of projects youve been through. That sounds like a
ridiculous claim to some, but lets run through the mental stages of developing a game
the way I see them: conceptualisation, identification, development, polish and release.
Everybody has a different expression of these stages, but everybody goes through them
for each released project.

Conceptualisation, or: how about we try doing something like this?

The first moment of any creative project is a spark of inspiration - a thought, an

interesting thing youve seen or heard, a system you thought of, a story you want to tell
or a world you want to create. It can be anything, in any context - you might be at a
game jam or staring out of a window on the train (or both). Either way, theres an idea.

Games are infinitely complex, and a game idea cant be caught with words. Its like
sheet music - you can catch a shell of what it has to be, but it takes the execution of the
piece - the experience of the conductor and the orchestra bring it to life. Two orchestras
performing the exact same piece can give really different interpretations of the same
work. Games are no different.

Thats why it is important to put your game into a playable state as soon as possible.
Work on the core interactions, the things people will be doing most. Make sure you can
communicate that by letting people interact with it, rather than explaining it.

If you dont know how to make games, download something like Game Maker, Unity,
Stencyl or Construct. The PixelProspector repository has an amazing website with
amongst others, a list of game development tools.

Identification, or maybe we should go with this idea.

It takes making a whole lot of those little prototype to get better at the second
milestone of development: identifying a game with potential. Theres no real way to
explain in words what the thing is you should be searching for - its a sense of wonder
or intrigue or just enthusiasm for a game. Its experience thatll make you better at this
stage, though. Its the constant failure of games based on a certain feeling, and the
relative success of those based on another feeling. At some point, you start to recognise
which responses are valuable and which are less so.

This is the stage in which you decide which prototypes become projects to work on, but
this process also takes place on a smaller level with design decisions. While a lot of
major design decisions should be conscious, informed decisions, a lot of micro-
decisions you make on a project tend to be more automatic. Theyre based on
experience, rather than theoretical knowledge and argument.

Its the thing Jan Willem got really good at when it comes to values, and the thing I
focus on when selecting projects for Vlambeer to focus on. Identifying what is worth
investing your valuable time in is extremely important, and getting better at that means
you have to spend a lot of time in conceptualisation. It also means you have to take
enough projects through this phase to see how they pan out.

During this phase, your eyes shouldnt be on the ball - you should not be headed for a
destination, but wandering aimlessly until you find a direction you enjoy. Toy around
with ideas, take the game in interesting directions, dont be too set on what youre
making yet. Thatll come later.

At Vlambeer, we spend about two weeks in this stage for our large projects, and less
than four hours for game jams in general. If by the end of that period, were not still
having fun creating the game, we drop it. If we cant keep ourselves motivated for just
two weeks, were not dedicating months of our lives to it. Well just be miserable if we
do that, and wed rather be happy.

Development, or thisll take only two weeks.

Theres a golden rule in development that you can only learn through practice. The rule
is that every given task take two weeks. However, if you subdivide those tasks that take
two weeks into smaller tasks, those smaller tasks will also cost two weeks each.

Development has an interesting progression. At first, the project is new and exciting -
everything you add has a significant and notable effect on the game. Youve created a
blank world, and youre defining things as you go. This doesnt feel like work to most
people. Its also the phase in which a lot of projects waste a lot of time. A lot of a
projects scope is organically defined in this phase, and this is where you slowly start
progressing from wandering to moving towards a destination.

After that, the production phase of development occurs. Production is hard work, but
the good news is that hard work is easy. You simply sit down and do it. This is where
motivation and discipline become extremely important. When you started this project,
you had something that caught your attention. That mightve changed, or evolved, but
youre still moving forward. Keep moving. Dont lose sight of the end of the tunnel,
even if you cant see it yet. Keep moving. Start cutting things that dont work, or that
contradict the message of the game. Keep. Moving. Dont forget to take care of
yourself, to find little distractions if your mind gets filled up and upset with the
monotony of what youre doing, to keep learning and to stay happy. Stay happy and
keep moving. Dont crunch, dont exhaust yourself, but keep moving.

Polish, or did I actually fix that one bug in the main menu?

At this point youve got a game thats playable. You can sit down and let somebody else
take place behind the controls, and if youve been doing it right you already know what
kind of experience theyll have with it through playtesting. Regardless, theres usually a
lot to clean up still - remnants of ideas that didnt work out, terrible UI decisions made
early on and never fixed, little confusions and tiny bugs from fixes made right before
you shut down one of those days a while ago.

This is where you take your game and make sure people can enjoy it optimally. You
created this thing for people to play with, and you owe it to the game to make sure they
can. That doesnt mean to dumb it down, or to add birds to it - it means to think about
what youd need yourself to enjoy the game if you had never heard of it. It means to
think about who youd want to play this game and how they need to be instructed (or
not) and to make sure things are where theyd look for certain things (or not).

This is where you write your little pitch for on your website, and where you start
wrapping up. The main menu gets a last overhaul and you suddenly realise that your
pause menu still looks horrible.

Release, or I hope people dont think its terrible.

You hit the button and the game is out there. Thats it. Youve poured a lot into it (or
you made it really quick) and now people can play it. The way developers react to that
varies a lot depending on their personality, their emotional state, the amount of time and
emotion they poured into the game and the reception of the game.

Releasing a game is not the end of it. You deal with feedback and criticism, or a
complete lack thereof. You end up wondering what you couldve done differently and
you will immediately think of at least a dozen things that you shouldve done better or
differently.

If the game is a success, this is where you deal with press and feedback and if its
commercial, you deal with the finances and legal aspects of making a successful game,
and the emotional impact of making something people seem to like. If your game is a
failure, this is where you deal with the emotional impact of making something people
seem to ignore and in some cases, the financial troubles that come with not earning any
money through your work.

Either way, you learn to deal with feedback, and you get better at reflecting and finding
ways to improve yourself and your title. Releasing your game to the internet invariably
shows you things youve missed, things you assumed wrongly and things that fail to
communicate - but it also shows you what worked and what didnt. Take some time to
take it all in.
The story of the pottery school
Now, the above applies to every game. It applies to KARATE as much as it does to
Ridiculous Fishing. We learned more from Ridiculous Fishing, obviously, but we had
the experience at that point to sit down and make that game. Things changed along the
way, goals shifted and our idea of what the game was evolved over time, but we knew
we could tackle it if we pushed hard enough.

For people starting out, the amount of experience you need to be able to create a dream
game is overwhelming - and I believe the best way to gain that experience isnt to work
on your dream game (which is in itself a problematic concept, but thats also for another
time). It is to make a lot of games to learn, and then deciding whether your dream game
is worth working on at all.

Theres an anecdote which I cant for the life of me find a source for, but it is a simple
idea and backed by many creatives. An old pottery school asked students to create
vases, and the teacher split the group up in two groups. One group was allowed to work
on thinking up and creating one perfect vase for each semester, and the other group
could only work on a vase for a week at most before destroying it. At the end of the
year, they compared the vases created by both groups and found the vases made by the
group that made a vase a week much more refined, stable and aesthetically pleasing.

The reasons for that are simple: one has more experience with success, and more
experience with failure. Not just on a project level, but also on the level of tiny
decisions made, of how long to bake the vase, what type of glass or clay to use and what
material doesnt mesh well with what.

That story of people being extremely successful on their first game? That doesnt exist.
Fullbrights Gone Home is a debut game, but it is the debut game of people that have
been working in AAA for a while. Hyper Light Drifter is a debut game for Heart
Machines Alex Preston, but he spent years years making little failed prototypes to
consolidate his dream game into the highly successful Kickstarter.

When I found myself - five or six years ago - being a programmer with a reasonable
amount of theoretical design knowledge, but without a lot of practical design
knowledge, I sat down I drafted a simple challenge for myself. For a period of time, I
would make a little game every week next to my normal work. If theres a reason I can
hold myself in a design argument nowadays, its because of a combination of reading
books, attending talks, listening to smarter people talk and making thirty-some games
that were terrible.

A Game A Week
Ive been recommending people asking me how to get into making games to do the
exact same thing, with a single update for the social media age. The longer you maintain
the challenge, the more experience you have.

Make a game every week. Start the project after Monday 12:00AM and finish it before
Sunday 11:59PM. It does not matter whether the game is digital or analog. It does not
matter what you use to create the game. The only rule is to make a game.
 Release the game every week. Whatever you make, whether it is complete, stable,
polished or good, release it to the world through a website you specifically set up for
this goal. Spread the link to the page of the game of the week on every social medium
you own. Ask people to give you feedback. Wordpress or itch.io are quite capable of
handling this.
Do not revisit a game. You can go back and revisit games after youre done. You
cannot work on previous weeks game or idea again the next week. This is not about
exploring specific games, this is about gaining experience. If a game is so special it
sticks for a while, you can work besides Game A Week or after youre done. You still
have to complete something else each week.
Try and avoid patterns in your work. Try and do something completely different each
week. Instead of making digital games, try making an analog game. Instead of making
an action game, make a puzzle game. If you find yourself in a pattern, take note of that
pattern and break out of it for a week or two before deciding to head back. Make
patterns a conscious choice, rather than an accepted and unquestioned reality.
Reflect. Spend each week talking to some people that played your game. Write down
your findings in a journal (or in a blogpost, like Adriel Wallick does at her excellent
blog). Write down what you made, what went right, what went wrong and what was
interesting.

Whats next?

Game A Week is a challenge that forces aspiring developers to create a high volume of
games. That is not the only valid way to gain experience, and it is definitely not
reflective of the only type of games you can make. Regardless of what you want to
make, going through the full development cycle frequently will make you better at
making games.

As soon as you feel your games are interesting, try and find people to work with on
these tiny games. Dont be disappointed when people dont want to help out: see it as a
solid piece of feedback indicating that you still have a way to go.

If you want to be a game developer, start making a lot of games. Make awful games,
make games that disappoint you, make games that make you doubt your ability, clone
games that you like within a week and even fail at that. Theres one difference between
people that want to make games and game developers. It has nothing to do with failure
or success, good games or bad games. The only difference is that game developers are
making games.

Before I left to work on Enhanced Wars, I was a producer and manager at BioWare's
San Francisco office. The majority of my time at BioWare was spent as a producer
leading the Dragon Age Legends game team. During my most crunched state I had a
team of 25, 19 of whom I managed directly. Hiring truly takes a team to do right (and I
was lucky to have a strong team at EA between the fantastic HR department and my
colleagues at BioWare) but one of my primary responsibilities during that time was to
serve as hiring manager for a number of positions across game design, art and
engineering.

Since I left BioWare, I have turned to community participation on Reddit and forums to
fill the hole in my life where co-workers used to be. Since my two partners in crime on
Enhanced Wars are in different time zones I don't have a lot of water cooler
conversation. So, I hang out on threads trying to add value by lending my advice to
current and prospective game developers.

I find myself repeating a few pieces of advice over and over again about how to break
into the industry as a game designer. I thought it would be valuable to take my
perspective as a hiring manager and turn it into a series of articles about how to position
yourself best to land that first gig.

A big caveat - I am just one hiring manager with one perspective. Each company you
are trying to work for and person you are trying to impress is different. These tactics
would definitely work if you were trying to land a job on my team. Personal mileage
may vary.

Step 1 - find your mountain In 2012 one of my favorite authors, Niel Gaiman, gave a
commencement speech at The University of Arts in Philadelphia. It was filled with
incredible advice for guiding your creative career. The first step in any game designers
journey can taken directly from that speech:

"Something that worked for me was imagining that where I wanted to be ... was a
mountain. A distant mountain. My goal.

And I knew that as long as I kept walking towards the mountain I would be all right.
And when I truly was not sure what to do, I could stop, and think about whether it was
taking me towards or away from the mountain."

This is important because game design is a broad profession. In any given day working
on Enhanced Wars I might write a design document. I might wireframe some UI or spec
out a UX flow. I might tweak tuning values in a spreadsheet all day long or lay out
levels. I might do narrative work or write copy for menu screens. I might spend all day
fixing bugs in scripting files. I might plan out a monetization strategy.

This list doesn't come close to defining all that goes into the bucket of game design.
Even more important than tasks is genre and platform of game you want to work on. For
instance, if Enhanced Wars folded and I wanted to get a full time job, I would feel
confident applying for monetization design jobs on mobile games tomorrow. But if I
decided it was time to build 3D levels for AAA games on the PS4 and Xbox One, I
would need to spend a minimum of 6 months preparing before I could apply for that job
from a space of confidence.

Your mountain will change many times over the course of your career. New
opportunities will arise, new platforms will take shape and new genres will be invented.
But it is important to pick an early goal. Because applying for a level design job on Tom
Clancy's The Division is fundamentally different from applying for a UX design job on
Battlefield 4 is fundamentally different from applying as a generalist designer with a
small mobile startup company.

Do your research and figure out what sort of job you will want to pursue as a designer.
My best advice - look at job postings on Gamasutra and the websites of companies you
admire. Read about the actual requirements, roles and responsibilities for real design
jobs. Invariably you will find yourself saying "that sounds like a lot of fun" or "I would
hate to do that every day for the next 3 years."

And a word of advice, don't set your mountain as Creative Director. Not at first. I know
it is everyone's dream to be The Guy or The Gal leading a game's creative vision. But if
you find that the only jobs that appeal to you are those with a fancy title and 10+ years
of experience required, you are in for a rude awakening. If the years of backbreaking
work it will take to climb the mountain are not inherently rewarding, you will never
ever make it to the top.

Once you have found your mountain, you will be ready to start building your design
portfolio.

Although I do not review as many resumes now that I'm an indie developer working on
Enhanced Wars as I did when I was at BioWare San Francisco, I still review the odd
resume here or there as a result of a Reddit or forum post. When I do, my top line
feedback is almost always the same: "You need to work on your portfolio website."

At BioWare San Francisco, we had a strong affinity for interns and co-op students (who
would work a full semester at the studio for credit). In a very real sense, we would not
have launched Dragon Age Legends on time without the contributions from our co-op
team members. As such, one of my favorite times of the year was when the fantastic
university relations team at EA would deliver the resumes of potential interns they were
bringing to campus for interviews.

It was not unusual for me to review 50 resumes in one marathon session to pick out the
prospects that I thought would fit a need on my team. Whether I was reviewing a stack
of resumes for intern candidates or a single resume from a recruiter for a full time
position, my process was almost always the same. Open a resume and scan it for about a
minute to look for highlights. Open the portfolio website link and spend a significant
amount of time reviewing (if possible). If a portfolio was great, I would request a phone
interview. On more than one occasion, I called someone instantly because the portfolio
was so good I didn't want to waste any time lest the candidate be snatched up by another
studio. Sometimes the candidate already had. A high quality portfolio was the single
biggest factor in landing a phone interview.

Tangible proof

If your professional experience is minimal or non-existent, the challenge you face is that
you have no credibility that you will be capable of fulfilling the job requirements. When
I'm looking to fill a job, I don't care about your mission statement, your extracurricular
activities or your summer job in a completely unrelated industry. I only care about proof
of your design abilities.

It can be difficult to know what to put in a design portfolio, as there are no standards for
what a good design document is or how a game economy should be laid out. The best
possible thing to have in your portfolio is shipped games. With tools like Unity and
Game Maker Studio and the ease of self publishing, it is my opinion that a prospective
game designer should exit college with one game on the app store for each year in
school. There is no stronger proof that you are a capable designer than being able to
show that:

*You know how to finish a game and release it to the world *You took the time to listen
to your players, either through metrics, comments, reviews or other feedback *You can
tell a meaningful story about how you improved your game based on player feedback

Being able to tell me that story in the initial phone interview is an instant ticket to a full
team interview.

Building a proper portfolio will take months, if not years. In college, I tried on multiple
occasions to assemble a team to make a game. I got plenty of interest from programmers
or artists who wished to talk about a game and collaborate, but when it came time to
start working on the game they did not deliver. Unless you have a team you truly trust,
my advice is to start out by making small but completed and polished games that you
can build on your own. If you don't know how to code, it's time to learn!

Feature portfolio material

What you build for your portfolio is highly dependent on your mountain. No matter
what type of design job you have, the tools exist to prove you are capable of doing high
quality design work. If your mountain is to work on open world RPGs, then dive into
the Dragon Age or Skyrim mod tools and make quests. If you want to work on
multiplayer FPS, then dig into Unreal Engine 3 or Hammer and release levels to the
world. If you want to work on a MOBA, then get cozy with the WarCraft III or Starcraft
II editor and prototype a new MOBA style gameplay mode.

No matter what your mountain is, you cannot wait till you "land that gig" before you
start learning how to design content. Only by proving you can finish content, release it
to players, listen to their feedback and improve your content based on feedback will you
be able to land that first professional gig. And if your goal is as targeted as working on a
specific game or at a specific company, if they have publicly available tools you better
invest time in mastering them.

Other portfolio material

A designer's job is much more dynamic than simply creating levels or quests. There are
a number of other documents or types of content you can create and share as part of a
portfolio. Here are some suggestions based off the varied types of work I do on
Enhanced Wars and other projects:

Game Treatment - no one is going to read a 75+ page game design document when
evaluating you for a position. But they will scan a 5-7 page game treatment that outlines
a game, its market and its core features at a high level.

Feature Brief - a detailed document that explains the full implementation of a single
feature for a game, including UI wireframes and flow, goes a long way to impress.
Design a new feature for an existing and well known game in the genre you wish to get
hired in. Make sure that in the early part of the brief, you have a section explaining why
this feature needs to be added to this game.
Game balance evaluation - much of a designer's job is tuning and balancing game
variables. Pick a game and write a report evaluating balance of a particular system or
economy. Take detailed notes on multiple play sessions, compile and summarize fan
and review feedback and come up with a series of recommendations on how this
system's balance can be improved.

UI/UX redesign - most of my work in mobile/tablet games involves designing or

evaluating UI. Designing UI is a difficult task, especially if you've never done it before,
but it is critical to a modern game's success. Pick a screen or flow from a popular game
that you think is broken or unintuitive, and propose a detailed redesign.

System balance spreadsheet - most of my time as a designer is spent in spreadsheets or

JSON files tweaking values. If you have followed the earlier advice and built some
games, you will likely have a system values spreadsheet to share. Clean it up and add
annotations so that another human can read it.

Pen & Paper prototype - many games start as simple ideas prototyped on pen & paper.
Although you cannot easily share the results, you can share your process. Fully
document with text and pictures the process of building a pen & paper prototype
complete with your final rule set. Explain the design problem you are trying to solve
and show the steps you took to solve it, pointing out what does and does not work.

These are just a few examples based off my experience. If you've done your homework
and spent time identifying job postings you would like to apply to, you may have other
design deliverables you would want to build to prove one requirement or another.

People are busy

The hiring managers who will be evaluating your portfolio are likely to be some of the
busiest people on the game team. They will not have a lot of time to review all the
materials that you have spent months or years preparing. They will probably not install
your game. They will probably not read your full document. They will probably not
open your spreadsheet.

If you really want to shine, then for each piece in your portfolio you should create a 90
second or less video on YouTube. In this video, show the piece of work, whether it is a
level, design document or UI flow. Talk about the process of designing the work. What
were your design goals? How did you achieve them? What feedback have you gotten
from players or peers and how have you reacted to that feedback?

Now that youve built a strong portfolio filled with tangible design works, you may
think it is time to write your resume and start applying for jobs. But the same way that
when designing features on Enhanced Wars I always set a design goal before writing the
actual spec, there is groundwork you need to do to figure out what you want to achieve
with your resume before you start writing it.

When I was deeply involved in the hiring process at BioWare San Francisco, I spent a
lot of time working with our HR partners on identifying candidates. Although I would
spend time on LinkedIn searching for candidates, this may be one hour or less a day
because I had responsibilities on my game team. The majority of the searching was
done by HR.

It is hard to explain to someone who does not have hands on experience developing a
game the difference between a content designer and a systems designer. Or to explain
that you need a systems engineer who may have previous jobs listed as a system
administrator, but you dont want anyone with traditional sysadmin experience you only
need someone who works with cloud services like AWS. These are very complex,
specialized requirements and there are no standards or guidelines around job titles and
seniority levels in our industry.

So you end up telling the HR partner about the types of experiences you are looking for.
You may write a list of studios to look at, job titles to search for or explain a number of
types of tasks you want to see on a resume. I need a designer with experience creating
quests and scripting levels on an RPG. But he or she has to be well rounded. Ideally the
candidate has experience creating user experience flows and designing new features on
a live game.

I explain all this to help you understand what is happening on the other side of the
hiring process. HR partners will forward the hiring manager resumes that come in
through online postings, but will also spend time crawling the internet looking for
candidates (mostly on LinkedIn). If they find someone that they think fits the
requirements, they will send that person on to the hiring manager to ask if this is a
candidate worth reaching out to. In general people on the hiring side are looking for key
experiences on your resume that will convince them you are worth reaching out to for a
phone screening. In order to prepare yourself to pass through this first hurdle, you must
figure out how to sell yourself.

Hero stories

Part of the reason to build an extensive portfolio is to gain a number of design

experiences to talk about. You need to think through those experiences and figure out
what your unique selling points are as a designer. Everyone applying for a game design
job is passionate, so dont try and sell yourself on passion. Dont sell yourself with
unrelated skills or activities. You need to figure out what are the things you want to talk
about when you get that hiring manager on the phone. You need to find your hero
stories.

Hero stories are the stories of a real world experience you had that highlights why you
are uniquely qualified for this job. The conversations you will have with people looking
to hire you will be driven by the content of your resume, so you need to seed that
resume with lead ins to your most heroic deeds as a designer. For instance, let us
imagine that I am applying for a lead design position on a mobile team. I would want to
prove that I am capable of taking an idea from initial idea all the way through the
process to execution and launch. I think that pen and paper prototyping is one of my
core skills as a designer so I want to make sure I highlight it with a hero story:

We started prototyping Enhanced Wars by first laying out our design goals. These were
a list of bullet points that started with We will know we are done prototyping Enhanced
Wars when then listed out things like we have a game with no stalemating and we
have played at least 3 full games with the final rule set. My colleague and I did 22
iterations of Enhanced Wars within 24 hours. Quite late at night, around iteration 16 we
thought we had the magic build and called it a night. In the morning, we started the day
by reading our design goals. When we tried to verify our magic build, we discovered
gaping holes in the design and kept prototyping until we finally had a version that fit all
our requirements with iteration 22.

Now, I dont expect you to actually fully write out all your stories like this; I certainly
never have. But what I do expect is that you think about the many design experiences
you have had and put together a list of bullet points for your hero stories. Figure out
how you want to sell yourself to fit the position.

Write your failure resume

Another important aspect of interviewing for a job will be showing how you have
learned and grown from past experiences. In order to sell yourself with a level of
introspection and acknowledgement of past mistakes, I suggest you write a failure
resume. This is an idea I learned listening to a lecture from Tina Seelig, the Executive
Director of the Stanford Technologies Venture Program.

The failure resume is a summary of all your biggest screw ups and the lesson you
learned from those mistakes. These stories will be just as powerful as your hero stories,
if not more so, when you are selling yourself as a candidate for a job. For example:

At PlayFirst, I was given the role of Lead Designer on my second game at the
company, Mystery of Shark Island. Although I may have had the raw design skill to do
the job, I did not realize till many years later that I simply did not have the maturity
level to lead the design of the game when I was so fresh out of college. One of the
biggest areas of difficulty I had was in listening to feedback from the senior people in
the company I would often shut down their ideas (with poor body language and tone
of voice) and make them feel like I thought their ideas where stupid. This negative cycle
meant people did not like to work with me. From my perspective, I felt like the game
was failing because other people did not understand my vision and I had to compromise
it past the point of fun.

Years later, I learned to find the why behind the what. This realization came to me
when working on Dragon Age Legends and getting feedback from literally the top
people in the company. What I learned then that I wish I had known at PlayFirst is that
other people are not as close to your project as you are. You know every intimate detail
so it is easy for you to instantly see why other peoples ideas will not work within the
framework of the game. But when the CEO has taken time out to sit at your desk
because he enjoys playing your game, you cant tell him hes wrong. And in fact hes
not wrong, he just doesnt know the project as intimately as you do. So what I did was
to listen to feedback then try and identify the reason why the game was failing to deliver
that led to a specific feature request. So, if someone would say I want feature X I
would reply I think you are suggesting this feature because you are having problem Y,
is that correct? Now were having a discussion about root cause and motivation that the
game team can solve, instead of talking about the merits of a specific feature.
By writing your failure resume, you will be able to sell yourself at a much deeper level.
When you get difficult questions or are asked about past failures, you will know how to
take a story about a negative experience and turn it into a positive experience.

Now that youve identified all the stories you wish to use to sell yourself, you are
prepared to write your resume.

Now that Im devoting my energies to Enhanced Wars, I do not see nearly the quantity
of resumes as when I was part of the hiring process at BioWares San Francisco office.
But I still review the occasional resume for someone who has reached out on Reddit or
forums, or for a former colleague asking me to pass it on to someone in my network. If
you have read my earlier post about how to build your portfolio, you should have plenty
of meaningful material to put on your resume even if you are trying to land your first
full time job (or internship) in game design. But learning how to write that resume is a
skill unto itself.

The 4 hurdles

Before writing a resume, it is important to understand the purpose of the document

beyond the high level goal of getting hired. A resume passes through many hands and
must be targeted at a number of different audiences within a single team or
organization. For the purposes of this post, imagine that you are applying for a job at a
larger company like EA or Ubisoft that will have a dedicated HR department. Although
each studios processes are different, the general principles outlined below will be a
rough guide regardless of if you are trying to join the Battlefield 4 team or a 3 man start
up like Quarter Spiral making its first hire.

When you apply for a job your resume will be screened by someone on the HR side.
This person has probably had a conversation with the hiring manager or members of the
team about what they are looking for in the position and in team members in general.
This screener probably does not have hands on game development experience and will
be reviewing you at a keyword level. If you look like a good prospect, the screener
may call you up to verify your potential, or may pass you directly on to the hiring
manager to ask would you like to phone screen this person? This is your first hurdle.

The next step will be convincing the hiring manager (who is probably your prospective
boss) that you are worth talking to. She will review your resume and portfolio to
determine if your skills match the position. She will almost definitely look at your
LinkedIn profile, and if you have any common contacts may do preliminary checkups
on you. Assuming you seem like a good prospect, she will set up a phone interview.
This is your second hurdle.

Once you get on the phone, your resume will frame the conversation with the person on
the other end. She will likely ask a mixture of questions about your experiences, as well
as hypothetical questions about various job scenarios, to get a feel for your working
style and thought processes. You may have one phone interview or several, depending
on geography, seniority of position and dev team process.

All steps up till now have been fairly low cost for the company, but from here on out it
will get more expensive. In the phone interview your resume must help guide a
conversation that convinces the interviewer you are worth bringing in for a half to full
day worth of interviews. This may or may not involve flying you in and putting you up
in hotel depending on geography. In-person interviews will definitely involve diverting
the attention of a number of team members which is very expensive from a development
perspective. Convincing the interviewer she should bring you in to the studio for a full
interview is the third hurdle.

Once you get to the studio, you will interview a range people on the team. This will
probably include the hiring manager who was the first to phone screen you, peers of
hers in leadership roles in other departments, people on the team who report to her and
potentially the people she reports to. In most instances these interviewers will have
spent 5 minutes or less looking at your resume and portfolio before stepping in to the
room. It is safe to assume that they have not read the job description you are applying
for. It is likely that these interviewers will simply pick a bullet point or position on your
resume and ask you to tell them about it.

This series of interviews are to determine if you are the right candidate for the job. The
team is trying to determine not only if you have the skills and experience to fulfill the
role, but also if your personality and temperament will be a good fit for the team. If you
have the skills to do the job but no one wants to work with you because of the attitude
you give off in the interview, you will not get the job. This is the fourth hurdle.

In all these instances, your resume guides a conversation with an interviewer who has
varying degrees of knowledge about you, the position you are trying to fill, the team and
the project. The resume is a conversation starter.

The razor

Your goal with a resume is to have a single page which frames a conversation around
why you are the best candidate for the job. There is no need to clutter it with details of
summer jobs in unrelated industries, leadership positions in social clubs from college or
lists of obscure programming languages you kind of used for one semester. With each
element you put on the resume you should consider if you can talk about it in a
meaningful way. If not, cut it.

For instance, in college I wrote electronic music. I had a DJ show on the college radio. I
was the co-president of the swing dance club. One time I (technically) opened for the
Black Eyed Peas. If I was applying for a job as a designer at Harmonix, all of these are
valid points that help me explain my lifelong love of music and why I am the right
mixture of designer and musician for their studio. If I am applying as a multiplayer
systems designer on the Enhanced Wars team, these points are meaningless.

In my opinion, you need your name and contact information, a link to your portfolio site
and possibly social presence like twitter, a section on education and a section on work.
Everything else is optional.

Hero stories

If you read my last post on selling yourself, you should already have a good idea of the
content of your resume. Assuming you are trying to get your first full time game job,
you may not have job titles or company roles to list. But you should have a number of
pieces of tangible design work you can list and explain your role on.

Instead of grouping bullet points by job, group them by project or course. Each job
should have two to three bullet points that highlight a different hero story about your
experience. For instance, in college I made a game called Refuse of Space that won a
game design competition. If I was applying for my first job, I would list Refuse of
Space and dates worked on it as though it were a job on my resume, then include one
bullet point highlighting its award and one highlighting that I did all the design,
programming and art myself. If I were to rewrite my resume today, I do not think this
project would be included in my one pager.

Avoid title inflation

A common effect I have seen on resumes for those early in a career (and one I have
been guilty of in the past) is title inflation. On one hand, there is nothing to say that you
cannot list yourself as Executive Producer of your semester long game project that
resulted in an unpolished demo. On the other hand, when a hiring manager works
somewhere like Electronic Arts with Executive Producers like Casey Hudson who is
responsible for all things Mass Effect it is hard to take this title seriously and may
count against you.

Instead of giving yourself lofty titles (or multiple titles per project) go with a more
humble approach. Instead of Executive Producer just say Team Lead. Instead of Lead
Designer just say Designer. Being aware of the size of your team and the scope of your
role within it will go much further than a flashy but ultimately overblown title.

Miscellaneous sections

Depending on the online template you started with, you may feel the need to include a
mission statement, skills section, hobbies & interests, coursework or some other type of
section on your resume. In my opinion, more is not always better and you should take a
minimalist approach when it comes to your resume. Go back to your razor: is this
something you want to be asked about? Does it allow for you to discuss a unique aspect
of your past and why you are an ideal candidate? If not, cut it.

When it comes to a mission statement, I generally advise against them. Unless your
mission statement is tailored for the specific job you are applying for, it is probably
meaningless. The fact that you want to use your wide range of skills to create
compelling experiences for players was implied when you sent in your resume.

For skills, do not list them unless you can intelligently answer a question about them. I
know I used to list Fortran and Lua on my resume because of some college coursework.
If anyone had asked me a meaningful question about either language while I was
interviewing, it would have tanked me as a candidate. Remember that the goal of your
resume is to frame a positive conversation about yourself, so avoid anything that will
detract from the overall impression that you are the best possible candidate for a specific
role.

The cover letter

I am a bit torn on cover letters. Speaking from my experience on hiring teams, I can
comfortably say that a cover letter has never meaningfully impacted my decision on a
candidate. But even if I expect that no one on the other end is reading your cover letter,
I still believe it is worth writing.

Part of applying for a job is applying for that specific job, and not just any job with the
word designer in the title. So writing a cover letter (or intro email) will force you to take
your abstract resume and weave a compelling story about why you are the right
candidate for a specific job with a specific company.

With that in mind, I believe it is a worthwhile exercise to write a two to three paragraph
cover letter style email tailored specifically for each job you apply for.

Exotic portfolios

Since you are a game designer you are likely compelled to create an exotic portfolio or
resume. You might think it is a good idea to create a 3d level in Unity that is itself the
resume. This is not a good or bad idea, it is an interesting one. If you can build an exotic
portfolio that actually goes above and beyond a piece of paper to show why you deserve
a job, then by all means go ahead. But too often these exotic portfolios detract from
your application. Only invest in an exotic presentation of your resume if it is truly
impressive to a professional game designer.

If you take all this into account when crafting your resume, you will likely jump over
the first few hurdles and land several interviews. I will cover preparation for these
interviews in my next article in the series.

If you've followed the series of articles up till now, then you've sent your resume and
portfolio out to the world and are landing some interviews. The previous article on
writing your resume covered the general process of phone and in person interviews that
you can expect, so I will not reiterate. Suffice to say that if you've made it this far you
will likely have to pass through a gauntlet of interviews to land that job.

An interview is about three things. The team is assessing if you have the skills to
complete the job requirements, so you must sell your skills and experience. Beyond just
skills, the team will also try to determine if you are a good fit in terms of personality
and culture, so you must sell yourself as a colleague. Finally, if you are a candidate the
team would want to hire you probably have some options, so the team will be selling
themselves to you as the ideal place invest the next few years of your life.

For instance, if you were applying to join me in designing Enhanced Wars, as an

interviewer I would prepare a series of questions (and probably some written tests) to
get a feel for your skills in not only multiplayer balancing and feature design, but also
UI/UX work and using metrics and player feedback to iterate on a live game.
Personality wise, I would need to make sure you are self-directed and motivated enough
to work on a virtual team and I would not constantly question if you will complete your
tasks or are too busy watching Hulu in your pajamas. If I liked you, I would prepare to
talk about the virtues and autonomy of working on a small, virtual team as well as the
incredible growth potential of joining a new studio at such an early stage.
But Quarter Spiral is just one team. Each studio or game team you will be applying to
will have unique requirements and culture, so they will be looking for different qualities
in prospective candidates. If you have made it this far, have built your portfolio, written
a killer resume and landed that all day interview session for your dream job, then you
need to make sure to go that extra mile and prepare properly for your interview.

Play the games

This should be obvious, I know. But I was surprised by the number of times I would get
on the phone with a candidate about a design position on Dragon Age Legends (which
was live at the time) only to discover that they had not played the game, or in fact many
free to play games. Or to talk with someone applying for jobs in different departments
in our studio who had not played any of our live web games. In most instances, this
would instantly disqualify someone in my mind. If they did not make an effort to play
the games we had poured our blood, sweat and tears into, how could we trust that they
would devote themselves to our games?

If you are interviewing with a studio, play any games they have made for at least 20
minutes (hopefully more). Do some research on the team and find out what games
people you are interviewing with have worked on in the past. The importance of being
knowledgeable about the work of the people you are trying to impress cannot be
overstated.

Do your homework

In all likelihood, you will know the names of the people who will be interviewing you.
If you have not been given a list, it does not hurt to ask your HR contact for one.
Research anyone on the list. Read any interviews by members of the team (even if they
were related to past games or studios). Check LinkedIn profiles and look for any blogs
or social presences. You may not always find material, but in most instances you will be
able to find something that will give you insight into the team and potential colleagues
you are interviewing with. This preparation work may or may not come into play during
the interview, but it can give you a reasonable first impression of the studio and its
culture to determine if this a place you will truly fit in professionally.

Prepare questions

Most interviewers will end by asking if you have questions for them. Sometimes this is
just to fill time in the schedule (as I said previously, interviewers do not always do a lot
of preparation work before getting in the room with you). But your questions can also
help a team get a feel for your personality, preparedness and overall ambitions.

Prepare a decent list of questions based on the job description, anything you know about
the studio and anything that is extremely important to you. But also be cognizant of
what the questions you ask say about you. For instance, let us imagine you are applying
to a junior design position on Enhanced Wars but all your questions are, at their core,
about how quickly you can become a lead designer. I would intuit you have unrealistic
expectations about the work you will be doing, that you are more interested in title and
control than the actual work, and you will generally be resentful of being asked to do
the many unglamorous parts of game design. Unless your portfolio and resume where at
a true rock star level, this line of questions would be a major red flag.

Also, during the course of a day of interviews you may feel like you have run through
your full list and have nothing left to ask. There is no harm in asking the same questions
to different people. You may get different answers that reveal new things about the
game team and its culture.

Persevere

If you've made it this far into the article series, then you should be fully prepared to start
applying for a job in game design. I know it all sounds so easy on paper, but the realities
of applying and interviewing for jobs are brutal. You will face rejection in all its forms.
You will feel like you are throwing your resume down an endless series of bottomless
pits. You will nail a phone interview only to never hear from a recruiter or studio again.
You will flub questions. You will make it through the gauntlet of in person interviews
feeling like the team loves you only to get turned down. You will be told verbally you
have the job only to wake up the next day to an email stating it has been given to an
internal candidate. These are the unfortunate realities of the job market.

All the preparation I have outlined in these five articles will only get you so far.
Landing a job is equal parts luck, skill, experience and random circumstance. Don't take
the rejections personally, learn from any application mistakes you make and persevere
in the face of the many setbacks you will undoubtedly face. Before long you'll be
emailing me with a link to a launched game asking for feedback.

The Checklist
These are the basics. I really think you need to have all of these if you are a student,
because you cant point to a game on the shelf of Gamestop and say I made that. Once
youre in the game industry, its a lot easier and you dont have to prove yourself as
much. But until then, you are untested and a risky hire.

Website
Resume
3-5 game design projects, showing breadth and depth of your experience
Videos, documents, demos, downloads, and/or supporting content

When I look at a students portfolio, I ask myself, Could I hire this person and
immediately put them to work? Do they have experience in the genre I am making? Do
they have experience with our tools or tools very similar to ours?

Sadly, the first question I have is not Is this person a good designer? That is the
follow-up question and definitely needs to be answered. But when I go over someones
portfolio and resume for them, I am usually looking for reasons to rule them out and
the fastest way to rule out a design application is to see if they have any relevant
experience with the kinds of tools and content the studio actually uses. You can be the
best undiscovered board game designer, but if you know nothing about first-person
shooters and have never made anything in a 3D level editor and youre applying to work
on the next Call of Duty, I think your chances are a bit slim.

YOUR WEBSITE
The purpose of your website is to showcase your skills and work related to the job you
are applying for. It should be easy to use and navigate, and I should be able get to all the
information I need in just a couple clicks, and not get bogged down or distracted by
content unrelated to game development.

Generally, website design is its own beast and hard to get right. Unless you have
experience, I really recommend trying to design a website from scratch. Grab a couple
people to go use your website after you make it and give you feedback (much like you
would when playtesting a game). Below are a pile of mistakes/suggestions that Ive
seen come up, or questions people have asked me:

Try to purchase firstnamelastname.com or something very similar for your

website url. Alternatively, if that is not an option, you could use something that
is fun and easy to remember (example: tomtomtom.com). This is one of the few
things that I think is worth spending money on.
Do not use a URL that is difficult to remember, misspell, is unprofessional, or
can turn people off (xxxHardCoreCha0s.weebly.com is a no-no).
Use a simple WordPress theme or similar popular packaged template that is
simple, clear, efficient, and easy to use and navigate. Check that it works on
mobile, too, if you plan on going to GDC or another career fair
Do not try to make the website from scratch if you have no web design
experience. Web design is hard, and a poorly designed website can turn some
people off. Im personally pretty picky about this because I used to do web
design before I found games, though I know others will overlook it.
I should be able to reach your resume in just one click.
It should be clear from your home page what game development role you are
looking for. I dont want to be confused about whether you are a level designer,
programmer, writer, or environment artist.
I should be able to quickly find all of your major portfolio work from your
main page. I should have a good idea of how many portfolio pieces you have.
Before navigating to one of your projects, I should have an idea of whether its
2D or 3D, and/or what engine it was created in.
Your design work should be the most important thing on your
website. Dont clutter it up by adding a whole bunch of unrelated or non-design
work. I recommend using a separate page and dumping all this stuff there, but
make sure its set aside and clearly labelled as separate from your design work.
Dont rely on icons, thumbnails, or images with no text, especially if these
are supposed to be links. I need more information before clicking them, and a lot
of times I dont even realize they are links so I never see the content behind
them.
Dont use a lot of flashy stuff like sliding image galleries. It makes it hard to
find what I am looking for when images disappear moments after I see them.
Sometimes I want to link someone directly to a page with an image on it and
many of those plug-ins prevent that.
No auto-play videos or audio please.
 Dont use a contact form just share your email address. Most people do not
use or skip contact forms it can be a turn off, and extra hassle. If youre
looking for a job, a contact form ends up being an extra barrier. Just post your
email on your website for people to use.
If English is your second language, ask a native speaker to proofread your
website for you. Misspellings and improper or unusual grammar give people an
easy (and lazy) reason to dismiss you, which is totally not fair for non-native
speakers. Find someone or ask twitter or facebook or reddit to proofread it for
you.

YOUR RESUME
Think of your resume as a list of qualifications, rather than a complete history of your
education and experience. You probably have details in your history that arent related
to games (the so-called Starbucks barista job) that you can skip because they arent
really relevant to the job. A lot of advice Ive read online says that you should tailor
your resume for each and every job you apply for separately. I think that goes a bit
overboard (I never did it), but a couple selective edits may be useful if theres
something in your history that is irrelevant to everyone except that ONE studio you are
about to apply at.

Formatting:

I want to be able to read your resume on your website, AND download a .pdf
or .docx (or both) copy to my desktop.
I should be able to easily print your resume without requiring color ink or text
cut off because it bled too much into the margins. So try not to make the
background black or add a ton of images. I think that sort of thing is better suited
to graphic design jobs rather than game design jobs.
Dont have a multi-page resume unless youve shipped games and worked
professionally (paid) in the game industry. Students normally have to add more
information than is really relevant in order to get to two pages. I think editing
down a resume to one page almost always makes it stronger.
Try to pay attention to white space and avoid big blocks of text. Make sure
your sections (Skills / Experience / Education / Etc.) are clearly separated. I
want to be able to scan it and immediately pick out your education background,
or your list of skills, with no effort.
If you are applying for a job internationally, learn the resume standards of the
country you are applying at. In the US, you do not include your picture or your
parents occupation. This is true vice-versa if you are applying for a job in
South Korea, you might need to include a photo with your resume.

The Basics of a Resume

I think most resumes for student designers should follow this general format at the
very least, its a good place to start.

Header with your name, contact info, website URL, and job title (Designer is
fine)
 Objective Statement (though honestly I always skip these)
Skills section that focuses on, in order of importance:
Game engines (Unreal, Unity, Hammer/Source, Skyrim/Fallout Creation
Kit, and many other programs)
Design skills that you have done extensive work in (3D level design,
combat design, first-person shooters, documentation, 2D level design,
economy balancing, creative writing)
Scripting languages (Lua, Python, Kismet, Javascript, C#, C++,
Java) should clearly identify what level of skill you have (basic
scripting experience vs. programming knowledge).
Supplemental game development skills: (Maya / 3D modelling,
Perforce). This section is optional and supplements not replaces other
skills. I would only include skills that are relevant to the jobs you are
applying for, and include any tools that are industry standard.
Games section that lists major game projects completed as a student or on the
side. (Yes, side projects count as experience! I care that youve made games (or
levels for games), no matter where you gained that experience.)
Education section that includes all degrees youve earned (or expected to earn).
If you did not attend college, then I would include high school diploma / G.E.D.
/ other certifications, but if youre a college grad I dont think you really need it.
Previous Work Experience: I think this section is optional for students but
your mileage will vary. Its a good place to call out military service, substantial
jobs (if you are switching careers, for example), game industry work like
journalism, internships, related jobs like technical writing or a freelancer that
made flash games for an advertising firm (that kind of thing). I dont think you
should include working as a cashier at Gamestop or shelving books at your local
library because they are not relevant to the job, but theres no rule against it. I
would include any jobs where you worked in design, art, or coding roles since
those share a lot with the skills you need in games.

Content
If you include an objective statement, be specific. Dont go into how much
you love games (thats usually a given). If you include an objective, Id keep it
to one line. If you are a current student and sending out resumes with a specific
start date in mind, then you can use this space to include the relevant
info (Looking for a full-time entry-level design position starting May 2014).
Like I said before, I honestly skip objective statements because I dont think
they are that important.
Skip references. I am pretty sure the standard in most industries is that if they
want references, they will ask for them. Just make sure to have them on hand
(and always ask your references ahead of time if they are okay with it!)
Avoid listing basic computer skills or experience with Microsoft Word,
PowerPoint, or Excel.
Avoid hobbies. I would not include things like being on varsity sports teams,
earning awards for debating, being president of the anime club, or similar
supplementary experience. I dont think they add anything since they dont
qualify you for the job, but, then again, if you played football and the person
looking at your resume used to play football, that could be a good opener. I
usually leave that informal stuff to bring up in interviews.
 If you have hobbies that are relevant to specific companies (ex: you play
soccer in college and are applying for a job on the next FIFA), you should
totally selectively edit your resume for those companies, or include it in your
cover letter. Actually, you should definitely include stuff like this in your cover
letter, but Ill get to that later.
You can include really important game-related activities and achievements
on your resume. If you are a competitive gamer whos played ranked matches
(League of Legends, Street Fighter, Starcraft, DOTA, Magic: The Gathering,
and more), Id love to know about it on your resume. If youve done Lets Plays,
video game podcasts, contributed to games journalism, or taught games at a
kids summer camp, let me know. I dont think being a guild leader in World of
Warcraft or starting a gaming club at school is not that interesting or unique, so
be judicious about what experience you include.
Do not list C++ as a skill unless you can really code. A single class on C++
does not count. I would list these as some experience with as a qualifier, and
lump them together as scripting languages, or skip it. Remember that a lot of
designers have programming backgrounds, and a lot of entry level jobs also have
programming tasks, so try not to misrepresent yourself here.
You should have experience with a 3D level editor! Top picks are Unreal and
Unity other people in the industry I talk to universally pick those as examples.
There are lots more out there, and some studios have favorites (for example,
Blizzard often suggests making Starcraft maps on their job positions).
Experience with Maya is good to have, but not necessary. You probably
dont need to mention specifically that you can model, unwrap, and texture art
assets designers dont usually do this work these days, though that changes
with smaller studios, mobile, and indie startups. You can just say you have
experience with Maya (or another 3D modelling tool) and leave it at that.
You dont need to include every project youve worked on. I would
only include large undertakings that required a lot of work things you would
consider major milestones. I suggest that any projects or games you list in your
resume should also be in your portfolio somewhere if I want more information.
Game jams, prototypes, unfinished projects, and short school assignments
do not belong on your resume. If you picked up skills from these projects, Id
expect to see them in your Skills section, but they are usually too small and
not polished enough to really act as a substantial project. (Ill get into better
definitions of what unfinished or prototype means later).
Do include any shipped game youve worked on. Shipping a game, or
working on a game for an internship, makes a students resume stand out from
the rest.
Clearly label your game projects so I know what tools you used, what genre it
is, when you created it, and how much time you spent creating it (3 months,
6 months, 2 years, etc.). I like this because I can get a better feel for your
experience.
Dont list student projects as though they are industry experience (ex: lead
designer on Tales of Nartharathia at DarkDev Inc.) unless this was your
professional job title and a real business. This is another one of my pet peeves,
and Ive spoken to a few other designers who get annoyed by this. It certainly
wont tank your resume but its pretty transparent.
Do list student projects clearly labeled as student work, and include your
role, highlighting any leadership experience (ex: lead designer on student game,
 Tales of Nartharathia). Make sure the game was finished, and that you put it on
your portfolio when I want to see more information.
You do not need to list every single thing you did on a student project that can
get long and unwieldy. Go with the 80-20 rule: 80% of your details should be
core design skills, but 20% can be supplemental skills (sound design, art,
writing).
If you can code, I want to know. Like, really code. Video games are still
software development, so while you do not need to know how to program to be
a designer, its a huge boon especially for students.
You should be general enough about your responsibilities/experience so that if I
never heard of your game I can still get an idea of what you did. If you say
Created level 3, Into the Ice Kings Lair I actually dont know what that
means. Id prefer seeing something like, Level design, documentation, &
puzzle design for 10 minutes of gameplay.
Shipped is a really nebulous term these days. In my opinion, you shipped a
game if the game was sold for money at a retail outlet or online game store.
If you put a game on the AppStore or sold it for Android or got it on Steam, I
would consider it shipped, but I cant really speak for others. Some sites are still
pretty new like itch.io and gumroad and most developers will not have heard
of them, so they fall into questionable territory. The important thing, though, is
that you do not seem like you are intentionally misleading employers.
You can list additional coursework under education even if it did not grant a
degree (ex: additional coursework in economics, playwriting, film, and Japanese
language studies). I like seeing this, but then again I have a pretty high esteem of
academia. I would only list coursework that is relevant- no one cares that I did
additional coursework in Spanish or Social Work when I was in college.

So thats my advice. Some of this came from others when I asked what they thought
were common mistakes, and others are just things Ive seen when I volunteered time to
review resumes for students. Obviously, youll run into some conflicting ideas I think
the most contentious part is which games/projects to include, how to label them (work
experience? student projects?), and exactly how to describe your role for each. That is
something I leave students to figure out on their own. Like always, I recommend getting
a few different people to look over your resume and website before you send it out to
get different opinions. Think of it like playtesting.

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 thats
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 theyve shipped games anyway). Until
youre 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:

o Do they have the technical skills to work in AAA editors?

o 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?
o Can they communicate about design clearly and intelligently, using industry
terminology and common design concepts?
o Is their work interesting, with good, clever gameplay, and maybe a bit
ambitious?
o Can they iterate on something with a high degree of polish? Can they finish
something they started?
o 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. Theres design portfolios out there that exist in
.PDF format and I think thats 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, theres 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
Ive gotten from other designers. I do see a lot of portfolios, but thats 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.

o 3-5 projects that show the breadth and depth of your design experience
o 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
its similar to many AAA toolsets and its also used in a lot of mobile and indie
development.
o At least one project that displays iteration and polish work. The idea here is to
show that you can bring something to completion.
o Clear explanation of your role on the projects and key design elements
o 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.
o 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 youll be judged on your design skills, not your art
skills.

What Id Like
Outside of the major elements, theres 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.

o 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.
o 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.
o 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.
o 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.
o 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 Id love
to see that kind of thing in a portfolio.

What I Dont Want

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

o 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.
o 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 its a hard one to master.
o Requiring me to purchase your game in order to evaluate it. Now, its okay if
youre 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.
o 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.
o 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 (Ive heard some complain more that its uncreative than
insulting), but since youre a designer you should be able to avoid this.

GOOD & BAD PORTFOLIO PIECES

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

Safe Projects
Heres 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 arent so great at displaying your
creativity. Obviously this is not a comprehensive list! Consider these suggestions as the
equivalent to writing prompts.

o 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.
o 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.
o 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.
o 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!)
o 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.
o 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. Thats because theres a
different level of complexity in designing for a 3D game environment, and thats what
youre 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. Dont 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 wouldnt 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
dont forget that familiarity with certain tools is really important.

o 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.
o A board game or pen-and-paper game that youve 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.
o 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, theres an entire industry devoted to hardware
and toy design, and its 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.
o A game that uses unusual control schemes or hardware, such as Kinect or
Oculus Rift. Alternatively, Ive seen a few 2D games that have used the guitar,
dance pad, piano, the move controller, and similar peripherals. Id be careful that
these are actually interesting (and make me interested in them!) rather than
gimmicks.
o 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 youve 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 youre applying for, say, a job at Sifteo or at an indie incubator.
But it doesnt 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 dont really have an excuse not to
get some experience in one!

Projects to Avoid
Theres a bunch of projects that I think are too simple, not complex enough, dont show
off your skills or knowledge as a designer, or dont 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.

o 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.
o 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 doesnt 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.
o Games that are entirely about environment art and ambience. Imagine your
game is set in a graveyard and theres 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 dont know the difference between a designer and an environment
artist.
o 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.
o Projects based on tutorials or classroom assignments. A lot of people do these
tutorials. All your fellow classmates do the same classroom assignments. I dont
think these help you stand out. Ive even seen a project based off of a tutorial I
also went through myself, which unfairly made me compare my results to the
students.
o Prison or sewer levels. Okay, maybe its alright to include them, especially
since every AAA video game has a prison or sewer level. But its kind of a joke
Ive 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 its called Dear Esther, you bet that I want to know about it. And if youre
REALLY proud of your 2D platformer or creative writing sample or prison level, go
ahead and include it. Dont say I didnt 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, Ive 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 youve 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 youve 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 youre done throwing out all your current portfolio pieces (I kid dont 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:

o Engine it was created in (Unity? Unreal? Custom?)

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

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

Next, you should summarize the piece and tell me why its 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.

Heres some supplementary material that will give me details about the project:

o Screenshots that show off the gameplay. Taking pictures of gameplay can be
hard, but its important. Make each screenshot show off something different in
the game, rather than several angles of the same thing.
o 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.
o 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 doesnt need to be long a paragraph may be enough,
depending on how much detail you want to go into.
o Any 2D maps, or overhead screenshots with overlay diagrams, identifying key
gameplay elements like the critical path or pickups or interactive elements.
o Design documentation youve 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, its a bit more free form depending on the project youre showing off. A
lot of designers Ive 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 dont want to drown someone with a ton of reading.

COVER LETTERS
Im going to start off this article being honest I actually dont see many cover letters,
and theres 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. Im 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 youre applying
to you really cant 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 Schafers 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, its 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. Dont 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 its 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
doesnt mean youve 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].

Ive [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 dont recommend that. Instead I think its very useful for a
rough draft. Lets take apart each section.

Greeting
Dear Hiring Manager,

Use a persons name if you have one maybe from a business card, from a career expo
or networking event, or from browsing Linkedin. If you dont 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 havent found a better alternative.

Dont overthink this. Definitely dont misspell someones 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 youre 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 youre experienced, I recommend sticking to applying to open positions.

Otherwise I hope you have a lot of free time on your hands.)

Sometimes its good to also mention location large publishers have many studios, so
its important to name the specific studio and not just the parent company (Sony vs.
Sony Santa Monica). Most of the time youll 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 its might be good to be
clear about your willingness to relocate and so they dont think youre 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 its true!

Wherever possible, I would give specific examples such as shipped games youve
worked on, certifications, or degrees. Just make sure that its 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 studios 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 its 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 youre applying to a company that only makes sports
games and you dont like sports? Dont 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,
Ive 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 Ive written cover letters, this is the section that ends up being the longest.

Where They Can Find More Information

Ive [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 dont beg!

Sign-Off
Thank you for your time,
[Name]

This is simple. Dont overthink it. You can go ahead and use exactly what I just wrote
up there, or whatever your favorite variation is. I dont 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 dont
have enough experience (so you have nothing to talk about), or you just dont
know how to market your skills.
Too long much, much too common. Do you remember what I said about 350
words? If its long, I hope theres a reason.
Not being specific this reads as a generic letter that could be sent to any
company, and makes me think you dont care about this specific position. You
wouldnt (shouldnt!) do this on a dating website, so dont do it here.
Being too specific reads like an FBI brief!
Not talking enough about your qualifications says you dont 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 dont 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 theres exceptions but Ive never seen a
justification for it.
 Applying for a job you are clearly unqualified for This tells me you dont
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.
Theres a balancing act here between imposter syndrome and the Dunning-
Kruger effect that only you can answer.
Applying for a job youre 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 isnt really a relevant qualification for making games its 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 dont know.
Fawning over the studio like a fan rather than a peer Making games is a
job its work, and sometimes its hard, frustrating, and imperfect. Hero
worship for a creative director, or being the worlds 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 peers 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 studios games before they started
working at that studio.

CONCLUSION
Thats it. Thats all my advice and obviously its advice and not a formula for success.

Cover letters are stressful because every single one is unique and there arent 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.

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.

Ive 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 wont since thats 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 its 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.

Theres 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 youre 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 youre 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 studios 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). Ive still summarized and anonymized
them since its bad practice to share design tests verbatim (its kind of like sharing exam
questions during finals week). This also means I changed a bunch of key details so, no,
dont 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.

Its 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 Ive 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 studios 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 competitors 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 studios existing game and identify a feature you would cut, and
explain why.
Design a new feature for the studios 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: theres a bunch of design tests easily within reach if you use
google. Tests are normally a lot more specific Ive 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 Assassins 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 Im 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, dont 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, theres 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.

Thats 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,
its a cavern. If they cant work within the guidelines for a test, how are they going to
work within scope on a 50-person team? Or, if its 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. Thats 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
dont try slipping anything in under a technicality. If you realize youve 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 cant 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 youre an American you
should get used to this.Its 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 youd 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 players
current heading.

Now, dont 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 youre 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 youre designing a space on paper, especially a 3D
space mapped to a 2D layout:

Check the height of ceilings and make sure the player wont 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 doesnt 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 dont 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 its 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 players
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 players
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 youll 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, theyve 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? (Dont ask me about pacing in roguelikes if thats whats on your design test,
good luck!).

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

Heres the kind of questions you can ask yourself while youre 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 youd
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 its
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, dont 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 youre drawing it on a 2D page. Dont
worry about isometric layouts they are notoriously hard and I dont think
anyone expects them.
Check for spelling and grammar. If you dont 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 youre making a 2D layout, and the design test doesnt ask
for it to be printable, dont 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 Ive 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 youre
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 its 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 its worth your time to do a design test, and sometimes it isnt.

I would advise against doing a design test if you havent already talked with someone
qualified to hire you (i.e. a lead or director, not HR). I dont think studios should ask
applicants to invest the time in a design test if they arent already serious about hiring
them. But there are many studios that send out tests blindly, so its 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 Ive seen, I think most of them are fair
and several of them ask much too much of applicants. I probably wouldnt 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 youre
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 dont resent doing them and I find the
results very insightful. If youve 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 doesnt mean you have no choice in the matter.
Keep that in mind when youre balancing the need for a job with the amount of work a
company asks you to do.

THE PROCESS
Interviews and design tests and all that jazz are really nerve-wracking for a lot of
people, like a first date with someone youve admired at a distance for so long and now
finally you have their attention and all you can think about is if theres food in your
teeth. My goal with this article is to demystify the interview and hiring process mainly
for students who have never gone through it before. Along the way, Ill give you some
tips on what to do.

Typically, the process of getting a job as a designer at a game studio goes like this:

Resume, Cover Letter, & Portfolio submitted

Interview over email
Informal Interview
Phone Interview
Design Test
On Site Interview
Offer Letter

Many studios skip steps or change the order of them. This isnt some kind of formula
that companies follow, but rather common sense.

(You can always count on the offer letter being the last step though.)

Resume, Cover Letter, & Portfolio submitted

See my previous advice for resumes and cover letters, and for design portfolios for more
details! Below Ill go over all the different ways I know of where a resume ends up in a
studios hands.

Fill out an application, usually through a website form. These can feel impersonal
(they are) and as though your resume will just end up in the trash (they wont). These
are common at big studios and publishers that get thousands of resumes for a single
job opening.
Use an email provided by the studio (such as [email protected]) to send your
resume, using the email content as a cover letter, and any other information theyve
requested. More common at smaller studios.
 Get recommended personally by someone already working at the studio for an open
position.This is why networking is so important, but remember that most people will
only recommend those theyve worked with in the past, which doesnt really help
entry-level people.
Visit a career booth at a convention (like GDC, PAX, ComiCon) or at a career fair set up
by your school. Often theyll still have you submit your resume via email or through an
application, but sometimes they accept them.
Get laid off from a high-profile studio is not a technique a recommend. When a
studio has a large number of layoffs or closes down, such as Irrational Games after
Bioshock: Infinite wrapped up, other studios go in to snap them up (starting with leads
and working their way down). Sometimes theres actually a career fair organized in the
former offices.
Get recruited directly by studios who find your information on LinkedIn, any social
media presence or blogging you do, or even word-of-mouth. Unlikely for students
(though this is actually how I got my first job back at 5TH Cell). Pretty common among
people with lots of experience.
Get recruited by external recruiting agencies who look for individuals that qualify for
job postings, and then connect the applicant with the employer. They take a slice of
your income, or the studio pays extra on top to the agency. I would not use recruiting
agencies if youre a student. Probably never use them, but thats a separate topic.

Interview Over Email

I dont think email interviews are particularly common phone interviews mostly cover
this. But I have run into it before with a studio, where they asked me some general
questions to see if I was a good match. I didnt do any email interviews with any others,
so no idea how prevalent this is. However, remember that any email correspondence
you have with someone at the company, even if its with a receptionist, is basically an
interview. Always be polite and professional.

Informal Interview
These arent exactly real interviews. I call them sanity checks because their goal is to
mostly check that you seem smart, know your stuff, and are the kind of person the
interviewer might want to work with in the future. It acts as a convenient pre-screen for
a real interview.

You can find informal interviews at networking events or conferences like GDC where
a bunch of people from different parts of the world are suddenly in one place so it
makes total sense to just talk to those you might want to hire. I dont think anyone is
exempt from this possibility, but usually they are arranged ahead of time and not really
spontaneous. Ive done probably a dozen informal interviews as the interviewee some
pretty bad (as in, obviously not a good fit for either of us) and some with more
traditional follow-up interviews.

Ive conducted a couple informal interviews, which is the limit of my experience as an

interviewer. Normally I ask general design questions, games they admire, whether they
are into systems or level design or what, and just get them talking about design and an
idea for what they are looking for job-wise The stakes arent particularly high and you
arent going to get a job offer directly from one of these, but they can feed into future
opportunities.

Phone Interview
The first phone interview I ever had was for an internship and I had a chest cold so bad I
was afraid to fall asleep because Id stop breathing. It cant get any worse than that and I
still got the internship. So just remember, as long as you can breathe then you can do it.

Phone interviews are the real deal. Youll talk to either one person, usually a lead or
director, or several in a conference call. Theyll ask you questions about design, about
your career goals, and about why you want to work there. They may ask you some
questions that require you to design on the fly. Sometimes youll have a pre-screen
phone interview with a recruiter or HR personnel employed by the company. That is
different not a real interview (so to say), but rather another gut check.

Phone interviews and on-site interviews are very similar, with similar types of
questions, so scroll down to my interview tips section for an idea of what you might
talk about.

On-Site Interview
By the time you get an on-site interview, the studio is probably pretty sure they want to
hire you and this is just the last test. Exceptions are when you already live near the
studio and they decide to take a chance and ask you to come in. But if they are flying
you in from out of town and putting you up in a hotel they are probably serious no one
will spend that money on someone they arent sure about.

This also means the stakes are really high for on-site interviews.

Typically (and remember, theres always deviations!), these are full-day affairs that
involve interviews with lots of people, not just your direct head. Almost everyone I
talked to shared the same experience at big studios: youll start in the morning, have
lunch with some subset of the team, and then continue through the afternoon.
Sometimes the morning or the afternoon is taken up by an on-site design test, and the
team takes you out to dinner. I know a couple people who had multi-day interviews
when they were flown out pretty far (think: US -> Europe). You may have one-on-one
interviews, or with a few people at a time, and theyll rotate in new people designers,
leads, directors, and developers in other departments that you would be working closely
with. Smaller studios might have people spend longer with you since they have smaller
teams and more of a chance to get to know you personally.

If you end up in an assembly-line style of interviews, you may get a lot of repeat
questions since interviewers arent going to compare notes until after the whole process
is over. Remember that none of these people are professional interviewers so some of
them will have awesome or difficult questions, and some might be a bit more lukewarm
or adversarial. You just never know.
There is usually only one on-site interview, but some studios may call you back for
another interview with new people. (Im looking at you, Riot Games and your 6+ on-
site interviews I keep hearing about.)

Design Test
Not all studios have design tests. Not all design tests are the same (they vary wildly
between studios). Theres not much to talk about here since Ive covered the bulk of
design tests in a previous article. Design tests may appear at any time on-site,
remotely, before or after interviews (though, obviously, they wont show up after the
offer letter).

I personally would not do a design test unless a studio has already interviewed me, in
person or over the phone. Most studios seem to follow this out of respect for your time
and their own since it takes effort to conduct and evaluate a design test.

Offer Letter
Some time after having an on-site interview, you should get a response: yes or no.
Sometimes the response might take a few weeks if they still have interviews they want
to conduct for position to narrow down their list because, remember, you are competing
with others for the same job opening. It may also take longer if they offer the position to
someone else and they turn it down, leaving you second or third in line. (If they are
nice, they wont tell you that you werent their first pick.) If you dont hear anything
back, well, thats kind of unprofessional but could also be an oversight, so my rule of
thumb is to wait a week before emailing a followup.

Offer letters come with a job title and brief description of your duties, a starting date,
and a salary offer. Youre expected to sign it and send it back if you accept the offer.
This is the point where you can negotiate salary, ask for details on their benefits, what
kind of support they give for relocation, visa/international worker issues (which I dont
know much of personally), and if you need to change the starting date. They are usually
really flexible about all this stuff, though salary negotiations are always hit or miss. If
you have more than one offer from a company, you can use that to help negotiate.

Offer letters typically come with an expiration date! They dont want you hoarding an
offer letter while applying to another studio solely as a bargaining chip, and they dont
want to wait too long only to find out you dont want the job. If you find that you need
more time, you can always ask.

Basic Interview Tips

So now that you know the process, Im going to go over basic interview tips specific to
games.

Dress casually. Jeans are FINE. Sneakers are FINE. Game-related tshirts are FINE. If you
want to dress up a bit, then swap out jeans for slacks or a skirt, sneakers for nicer
shoes, and making a button-up shirt. Do not wear ties or full suits to your interview.
Wear something comfortable first, good-looking second.
 At a traditional game studio, dont worry about neon hair, piercings, or tattoos. It
may be worth toning it down if youre interviewing at a studio thats not part of the
tradition games industry or tech (such as educational games and government-funding
training sims), but this is really your call.
If you have no real interview experience, mock interviews with a friend might help
you, where they pretend to be an employer and ask you questions. Personally, I did
really poorly in mock interviews compared to the real ones but I think it got my
nervousness out of the way.
Bring a couple copies of your resume. Ive never had to use them, but they make me
feel more prepared. Dont worry about printing or bringing physical copies of any
portfolio pieces, but if you want to be extra prepared you could put some of your work
on a USB drive.
Know about the studios games and its history. Some studios require you to be a
regular player of their games (Blizzard and Riot come to mind), while other studios just
ask for a passing familiarity. Its good practice to be able to talk about the studios
games if youve asked about them.
If you know what game the position is for, make sure to read as much as you can
about that game. If there are prequels or other games in the series, try to get your
hands on them (even if its just a demo). Arm yourself with knowledge about other big
games in that genre.
If you were a student, if someone asks about your experiences make sure to talk about
what you did personally, not what your student team or class accomplished. Try to
isolate your contributions because they should want to hire you, not your classmates.
Dont pretend to know an answer. Dont lie about a game you havent played
or fake your way through part of an interview. These are terribly transparent,
especially since a lot of questions (see below) actually lead to more in-depth
discussion. Instead, be honest if you dont know the answer or if you havent played a
specific game.
Be a little humble, even though you are there to try to impress people. One of the
goals of the interview process is how you would work well within the team. Some
team structures are kind of antagonist, but most of them are very cooperative and
developers want people that are easy to work with.

Questions THEY Ask

I categorize questions people may ask you at an interview as: general interview
questions (not specific to games), general games talk, and design on the fly.

One secret? Sign up at Glassdoor.com, look up your favorite companies, and read the
comments people leave. Some wonderful unscrupulous souls love to leak interview
details there. Heres 32 pages of interview questions for game designer positions.

General Interview Questions

Youre going to run across some number of these and I dont think they are all that
interesting for the most part (I prefer design-specific questions). For an extra resource,
check out this list of the 50 Most Common Interview Questions (with some advice on
how to approach them).

Some examples:
 Why do you want to work here?
What was your experience at [previous studio] and why do you want to leave?
What is your greatest weakness? (Correct answer: attention to detail)
What is your greatest accomplishment?
If you dont already live in the city, what do you think of it? (And similar easy, chatty
questions, including the weather).
Where do you see yourself in five years?
Can you give me an example of a problem you had with a team member, and how you
solved it?

General Games Talk

These are mostly questions that will delve into the types of games you play, what you
think about them, and whether you can communicate interesting insights into other
games. A lot of times they are questions that lead into design-on-the-fly questions.

Heres a smattering of questions I would prepare to answer:

What games have you been playing lately?

Whats the last game you played? What did you like about it?
Whats your favorite game of all time? Why? What would you change about it?
Whats your favorite genre? What games do you feel epitomize the best practices in
that genre?
Whats your most hated genre? (Dont say the genre the company specializes in)
What are some cool trends in games that are interesting? Or, heres [trend], what do
you think about it? (examples: free-to-play, esports, virtual reality games, next-gen
consoles, etc.)
You worked on [game]. What was that like? What was your process? What would you
have changed?
Tell me about a time when you had to [fill in the blank].
Can you give me an example of a design problem you had, and how you solved it?

Now, when they ask you about games, dont be afraid to be honest. There is no wrong
answer here and no one is going to judge your tastes in game so long as you can back up
why you liked it and whether you know enough of the medium to compare it with other,
similar games.

If someone asked me what games Im playing lately in an interview, Id probably start

off mentioning that I am playing through some cool indie interactive fiction at the
moment. But if I am interviewing at a AAA studio, Id also follow it up with the fact
that Im playing FarCry 3 for the first time. Since I know that they are fishing for a
game in common, mentioning obscure games doesnt really help beyond giving them an
idea of my range of tastes or perhaps introducing them to a new game they havent
heard of (obviously, with an intent to see if you can explain a games mechanics to
others).

Really, all these questions are created to get you talking about games and talking about
design with fellow designers. They want to know if you can speak their language and
have insights to share with them.
Design on the Fly

These questions are pretty devious, but also really powerful tools. They want to know
your thought process as you go through it on the spot. They want to know how you
solve problems, and if you can solve hard problems (or, at least, tackle them) or if you
freeze up.

The important thing is to talk through the problem they give you and not just go silent
and try to deliver them a perfect response.

Heres a few examples of design-on-the-fly.

If you had a billion dollars, what game would you make? These types questions are
open ended on purpose, asking you to just brainstorm away. (I dont like these
questions and I think interviewers should stop using them.)
How would you redesign a given game for a different control scheme? For
example, talk me through adapting a third-person shooter for a touch screen. (Kind of
similar to some of the design test questions, but more manageable)
So you said youve been playing [game]. How about you talk me through a new
mission youd design for it?

A friend I cannot remember who! told me my favorite story for tricky interview
questions. The interviewer asked them about an example of a problem they had with a
team member and how they solved it. So they described an artist who made a clock
tower centerpiece that just did not conform to the needs of design. So, the interviewer
stood up, walked to the white board, and proceeded to draw a pine tree. This is my
clock tower. And then they waited for the interviewee to explain the problem.

As you can tell, these questions are pretty context specific it really depends on what
your common frame of reference is, or what the interviewer is interested in at the time,
or what topic is just floating around the room. I dont believe you can cheat these
questions by practicing answers, or even prepare all that much for them in advance.

Questions YOU Ask

A lot of people tend to forget that the interview process is a two-way street. You have as
much right to interview them as they do you. Ask them questions that show you are
interested in the company, how it functions, and making sure its a good fit for you.

I think most people have a few key questions they learn to ask. My personal choice has
always been to ask, What is your crunch policy? This puts some people off-guard,
since no one likes crunch or likes admitting how much they crunch but, seriously,
everyone crunches. Others may let slip that the studio has awful amounts of crunch
(useful information, whether or not youre willing to crunch like that). But good studios
dont have a problem answering this question and showing that theyve thought about it.
This is my pick, but you may not agree (some designers I mentioned this to said they
would never ask that).

Some ideas for questions you can ask (if you want!):
 What game is this position for? This is in case its a studio that hires for multiple
projects, and didnt specify. Sometimes the game is under NDA and they arent willing
to discuss it, unfortunately, but at least thats information that youd be working on a
new unannounced project.
What is the size of the team? How is the department structured (one lead, multiple
leads, etc.) Probably a better question for smaller studios that have nontraditional
hierarchies than larger studios.
Do designers fill specialist roles or are they generalists? Are they responsible for very
specific content or do they take on multiple responsibilities? If you are applying for a
level design job, for example, you may want to ask them what the workflow is like,
whether you are involved in mission or combat setups or just world building.
What kind of scripting, if any, are designers responsible for? Do designers do any work
in 3D modeling tools (like Maya or 3D Studio Max) or do they whitebox content
directly in the engine tools?

A piece of advice Ive heard is to get the interviewer talking as much as possible, rather
than the other way around, and theyll leave thinking youre awesome. Dont be afraid
to let the interview derail Ive talking to people about travelling, hiking, delicious
Thai food, and how awful Frank Herberts Dune series gets after the second book. This
is fine, and a welcome diversion for people who dont really like interviews (who
does?). The next person or the next break will get the interview back on track anyway.

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 Ive 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
arent? 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 arent
qualified (lack of side projects, modding work, personal games, etc.)
aspiring designers dont 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 its 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: its 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, Ive 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. Its by no means an exhaustive collection I only spent
about an hour and found 24 openings.

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, theres 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 dont feel so bad now for my portfolio advice being
so heavily biased in favor of implementing levels and gameplay in a 3D engine.

Theres 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.
Theres 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
arent 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, its 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 doesnt 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? Theres 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 Ive written above but, mostly, Im
hoping that some people feel a bit more comfortably finding and applying to entry level
jobs, and if they dont at least realize what skills they need to work on to break in.
Please note that my examples I included and pulled from arent 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.

Quick Introduction:

Four years ago I picked up Unity and began tinkering with it as a hobby project. Three
weeks later my business was robbed, forced to close, and instead of letting it break me I
took a huge gamble and became determined to make my dream game. If I made the
game a success then I could always look at the robbery as a positive event in my life.

That game is now finished and will be leaving Early Access in a few weeks.
 I'd like to share the many tips and lessons learned over the course of those 4
years to help other solo developers and small teams who are looking to follow a
similar path to myself.
I'll start at the beginning by discussing the importance of prototyping.

The Core Game Loop:

Before we even consider prototyping we must first understand what we are trying to
prototype and to do that we first need to discuss the principle of game loops.

The vast majority, if not all games, revolve around a 10-30 second loop of gameplay
which repeats endlessly. I first ran into this nugget of knowledge while reading an
interview with the Halo developers in Edge magazine over a decade ago.

So what is a 'game loop'?

Let's take look at the game loop in Halo. It goes something like this:

See enemy, engage enemy, kill enemy, loot, repeat

When we think of Halo, or now Destiny, this is the driving force behind the whole
game. Bungie polish their game loops to perfection and as a result their games always
feel amazing to play and keep players endlessly engaged.

Deeper analysis:

In Halo there are many variations of this loop. Maybe we are fighting on foot, maybe
with a pistol, or a rocket launcher. Maybe we are fighting in a tank, or banshee, or
ghost. Each of these different game loop variations need polishing to perfection because
the player's overall experience of the game relies on them.

Sure, Halo has a great story, but in reality it plays a secondary role to the quality of
these repeating game loops. Destiny proved to be a huge success even though, for most
gamers, the original story failed and that's because the game's core game loop was still
Bungie at their finest, doing what they do best.

Imagine if your core game loop has a minor frustration in it. Your poor player is going
to run into that frustration every 10-30 seconds and they will soon put your game down
and give it a bad review due to a single seemingly small mistake.

Naa, What about...

But, what about a game like Sid Meier's Civilisation. Where the heck is the game loop
in something like that?

Select unit, move unit, combat/gather, repeat.

The player repeats this same game loop thousands of times so it must be as engaging as
possible. Even if we look back at the very first versions of Civilisation we can see that
this game loop was on point. The grand strategy of the game is surely important, and
plays a role in this move-unit game loop, but the actual process of moving each unit is
still engaging and feels good.

It's extremely difficult to find any game on the market that doesn't have some form of
core game loop.

Your game's prototype:

By now you probably know what I'm about to say. We must prototype our core game
loop before we waste our time on anything else.

Don't waste time:

Forget everything else. Forget your UI, your big features, your art style, your grand
story, and make a prototype of your core game loop before you do anything else. Polish
it, iterate it, perfect it, obsess over it. It has to be as engaging as possible.

Don't worry about graphics. At the very early stage of prototyping they are irrelevant.
Untextured blocks and the simplest flat environments are more than enough.

Test it:

Play your prototype.

Is it fun?
Is it engaging?
Does it feel right?
Is there something you can tweak to make it better?
If so, do it now.

Never forget that this is essentially your game. If this part sucks your whole game is
going to suck no matter how many fancy bells and whistles you throw on top of it.

Share it. Get feedback:

Get it into the hands of others to play.

Do they enjoy it?
Do they have suggestions to improve it?
Are they frustrated by anything?
Is it intuitive to play?
If you can make it fun and engaging to move some boring cubes around then you are
likely on to a winner. If you can't then don't expect that adding more features to your
game is going to fix its core problems.

Graphics and sound:

Although your first prototype doesn't require fancy graphics, your next job is likely
going to be prototyping some fancier graphics. Game's like Mario feel as good as they
do not only because of the intuitive controls and the feel of the core game loop (moving
mario around) but also due to the way that the sound effects, and delightful animations
Mario has, build on the feel of that game loop.

Shooting your gun in Halo is a visceral experience. The game loop of moving, pointing,
shooting and looting needs to feel great but it can be even better by adding nice
animations and graphical effects to the experience. Add in great sound effects and we
can bring the engagement level of our core game loop up to a new level. It can feel even
better.

Test it again:

Get others to play it.

By this stage, if you are failing to engage other gamers, then your game is going to fail
and you should probably give up on the project and try another idea.

Fail Faster:

There is absolutely no point creating a fantastic story, or complex overarching game

mechanics, if we can't first create an engaging game loop prototype. Too many new
developers fall into this trap and spend months and even years planning out their games
in intricate detail before they know for sure that the core of their game is even good.

Prototyping allows us to spot a dud early. It's part of the principle of fail faster that
every game developer should know. I won't go into discussion about fail faster. Extra
Credits made a great video on this concept a couple of years ago and you should
definitely check that out. You can find it here.

The Wrap Up:

If you are interested to know more about my personal story, you can find that
info on reddit here along with answers to the most common questions about my
game.
 With that said, might I suggest that we keep the discussion here on the topic
of prototyping and game loops so that we may create a handy resource for
others in the future.
Finally, I don't profess to be any type of expert. I'm simply trying to share the
knowledge I've gained and hopefully learn a thing or two myself from the
ensuing discussions along the way.

This time we'll talk about planning our games and how to go about executing the
hundreds, more likely thousands, of seemingly endless little jobs.

Don't worry, I'll explain at least one method to overcoming that overwhelming feeling
of "Where do I even start?"

I should point out that these tips are aimed at solo developers or small teams who are
starting out on their game dev journey. Experienced devs from larger teams will
hopefully share their own techniques.

The Master Plan:

Without a plan, you will be working randomly. You'll fly off on tangents working on
your latest cool idea and you'll never get your game finished. We need some structure
and a schedule if we are to have any hope of reaching the finishing line.

Avoid the mistake of making detailed plans that take weeks or even months to think
through and prepare. Our game is likely to change significantly, as we test out ideas,
and we must be flexible to change at every stage.

Instead we create our master plan in an hour or two - less if it's a small game.

By this stage we should have an engaging prototype and a head full of big ideas. So
what's next?

Quickly List the main jobs

Do this in very broad strokes. The list will be things like:

UI
Feature 1
Feature 2
Save game functionality
Modelling
Animation
Art assets

Include behind the scenes stuff like:

 Website
Greenlight Campaign
Kickstarter
Forums
Trailers
Dev blog
Marketing

Don't worry about how you will achieve any of this yet. If you are anything like me, you
won't even know how you are going to do most of it.

Don't go into any detail at this stage. Broad strokes, remember.

Calculate Total Development Time:

Next, go back over your complete list and write down, next to each job, a rough
estimate of how long you think it will take you to complete each job. Total it all up.

Do not shrug off this next piece of advice.

Take your total and at least double it!

You are going to run into endless jobs you never thought about. Seriously! Even tripling
your estimate isn't overkill.

Need convincing? Let's take a look at the time sink that a seemingly small job like
playtesting entails:

Finding playtesters
Interacting and replying to their comments
Thinking through their suggestions
Testing their suggestions
Finding more playtesters because they naturally move on to other things
Creating a forum for playtesters to communicate
Writing dev blog posts to keep your playtesters in the loop
Wasting hours trying to recreate a bug that isn't really a bug but a confused playtester
Creating a solution to prevent further confused playtesters
Taking screenshots and making gifs to keep playtesters interested during the long
journey
Spending hours chatting with playtesters over various new ideas
Reworking/improving chunks of your game based on feedback
Setting up a download source
Uploading new builds constantly
Writing update notes
Writing articles to entice new testers again
Watching twitch streams of playtesters for hours to see how they interact with your
game
Fixing bugs found by playtesters
 The list could go on and on.

As you can see, playtesting is a much bigger job than we could anticipate if we had
never been through the process before. When it comes to game development, every job
ends up being far bigger than we ever expected and in ways we could never imagine.

Do you have what it takes?

So now you've doubled or tripled your estimate, and you have a rough idea how long
the entire project will take.

Are you willing to invest that much time?

Are you disciplined enough to stay 100% productive over that amount of time?
Have you ever worked on such a large project before?
Are you sure you won't give up?

If you are uncertain to any of those questions then you should probably reconsider the
scale of your project until you have a Master Plan that you KNOW you can complete.

It's better to realize the enormity of what you are getting into now and scale it back
before you waste months developing a project that never gets finished.

Instead, you would have been better off finishing a very small game in those months
and you would have learned far more valuable lessons.

Can you make Pacman? If not, what makes you think you can build the next MMO?

Breaking it down

So your master plan is a broad stroke list at the macro level and the massive job of
implementing your game's user interface is nothing more than the word 'UI' in a list
right now.

It's time to break your list down into smaller pieces. Our UI, breakdown list might look
something like:

Start Menu
Gameplay UI
Gameplay mechanic interfaces
Options UI (Video, Audio, Gameplay, Difficulty etc)
Credits

Go through your Master Plan list and break each entry down into smaller, yet still not
too detailed, sub lists like above. At this stage we shouldn't be spending time imagining
how all of these things will look or interact. We're simply doing the first stage of
breaking things down into smaller parts to get a better overall picture of what needs to
be done.

Immediate Job List

Now we have a master plan broken down into smaller but still fairly macro sized jobs.
It's time to start working on those jobs.

Below I'll discuss the 'Extended Prototype' which we'll be working on next, but for now
let's keep things generalized to discuss the approach we take to actually implementing
jobs from our growing job list.

Take a look at your list of jobs, and pick one that makes the most sense to work on next.
Break it down. For this example we'll choose 'Gameplay UI' and break that down.

Player Shield bar

Player Energy bar
Enemy Shield bars
Radar UI

That's enough for now. Later we could be adding a bunch of other UI elements, but we
are only interested in the most important parts right now. We want to get them working
in a rudimentary way so the coding is all in place and we can test how it feels in action.

Creating the final amazing look for our UI design comes later once we know all the
interface elements we'll need to incorporate into that design.

Getting to Work

Now pick a job off our immediate job list. We'll choose Player Shield Bar. Break that
down into a daily job list.

Search google for ways to make a shield bar (yeah, I had no idea)
Plan/imagine the code structure for implementing the shield bar
Implement the shield bar
Playtest

Okay, so that's easy right? A few minutes ago we had this big list of seemingly
overwhelming jobs, but now we've got something super bitesized that we can hopefully
solve and have working in a couple of hours.

Once it's working, we already know what will come next. We move up our immediate
job list and implement enemy shield bars and then eventually the radar.
Once that's all done, we move back up to the next most important job in our Master Plan
and break that down into an immediate job list and get to work again.

The advantages of this method

It's structured with timescales in place to get it all done.
It's extremely time efficient with no time wasted thinking and planning big ideas that
never happen.
The plan is all broad strokes that shouldn't take long to list initially.
It breaks down massively complex systems into tiny, easy, bite-sized pieces.
No sooner have we planned the details than we are implementing them while the
problem is still fresh in our mind. This keeps motivation levels high and saves time. We
aren't trying to remember something we dreamed up six weeks ago or motivate
ourselves to do something that doesn't seem so interesting any more.
We get to strike jobs off our list quickly. Don't underestimate how motivating this is.
We see progression happening in a visual way constantly. There is nothing better than
seeing a job list disappear.

So, now you've got a good idea how you are going to approach your game's
development in a bite-sized way.

What should we be working on immediately after our initial small prototype?

The Extended Prototype

So our initial prototype was very simple.

It focused on our core gameplay loop which might have been nothing more than our
main character running around, jumping on things, and shooting his gun. Or maybe
we're making an RTS and we have unit selection and movement of those units feeling
slick.

But our game is so much more than that. We have big ideas. It's now time to start
prototyping those big ideas to make sure they hold up under real world conditions. Like
our initial prototype we will begin by adding these larger game features in the simplest
way possible.

Getting Started:

Go back over your big job list, and highlight anything that is essential to testing out our
bigger gameplay ideas. These are the jobs we'll be working on next.

An Example:
I'll use my game as an example. My initial prototype focused on the feel of movement
and the controls of the player's spaceship, along with the ability to shoot and kill other
ships. I polished that core loop until it felt really great.

However, my plan was always to have a deep upgrade system and loot. To me this was
the next fundamental feature of my game and it needed to be in my extended prototype.
So I implemented a very basic upgrade UI with nothing but text and buttons, added the
ability to see and select the upgrades as cubes inside each ship, and then the systems
that dropped parts of those upgrades as collectable loot into the world after ships were
destroyed.

Here's a pic of that old prototype interface, with a prototype environment that would
eventually be scrapped entirely.

Iterate and Improve

Your game is going to be very different to mine, but you will surely have bigger
features in mind. Prototype those. Make sure they work, iterate them, make them more
engaging, and don't be afraid to start over and try implementing them in new improved
ways. It's easier to do that now than later.

Only once our advanced prototype has convinced us that our bigger features are
engaging should we even consider properly fleshing them out. It's likely that many of
our wonderful ideas don't translate so well into real gameplay and we'll need to re-
evaluate and try other things until we find the best solutions.

Playtest:

Once we're satisfied, we must get our advanced prototype into the hands of other
gamers again. They are going to find problems and frustrations that we never imagined
and we should address those now while it's still easy to do so.

Eventually, you will have an advanced prototype that likely looks like crap but plays
great. It will include all of your major features in a very raw but highly playable state.

Our advanced prototype will contain everything our players will spend most of their
time doing.

We get to test if our big ideas translate well into real gameplay, tweak them if they
don't, discard things that suck, and ultimately we end up with the core of a great game.

Avoid Manky Cakes:

If the core is good everything else is going to be icing on a tasty cake. If our core is bad
we'll have a disgusting cake that nobody wants to eat hiding under too much icing that
we used to hide our manky cake.

_
Onwards:
Game development continues from this point forward in a very similar way.

We steadily improve and polish our game's best existing features, while prototyping and
adding new ones. We discard what adds nothing significant, and improve what works
best.

We work through our Master Plan's list of jobs and eventually the list is empty and we
have ourselves a finished game.

Wrapping Up:
The goal of this article was to show how we can efficiently take the monumental task of
making a game and turn it into bite-sized easy chunks.

Ultimately the secret of making a great game is time and hard work, but as long as we
have a simple plan, and plenty of determination to stick to that plan, it doesn't need to
feel overwhelming.

One step at a time. One job off our list at a time.

Coming soon:

I'll be discussing how to stay motivated through this long journey and how to prioritize
the various tasks in subsequent articles along with tips for avoiding burnout and how to
best manage our most precious resource: time.

On Topic:

As with the previous prototyping article, can I suggest that we keep the discussion here
on topic. If you have questions about my personal game you can likely find those
answers here or here. This is not the best place for them.

How do I stay motivated?

Let's stop right there because that is not really the best question; motivation is a fleeting,
transient emotion. It invariably burns out quickly.

If we give up on developing our games simply because we lose motivation then we will
never finish anything but the smallest of games. We all lose motivation sooner or later
and it's usually sooner. It can sometimes become hard to keep motivation levels high for
a day never mind months or years.

Luckily, motivation is a symptom of other emotions that we can control.

So what are those emotions?

Passion and Determination

If we have utter determination, it doesn't matter if we lose motivation; we will work on
our game anyway.

Determination will push us through the darkest of times. We build up Nike's slogan
mentality of 'Just Do It'.

This is the one of the secrets to completing any long-term project. There are going to be
huge stretches of time when we are really not in the mood to work, but our
determination will force us to keep going and we will never use a lack of motivation as
an excuse to give up.

So the real question is...

How can we stay determined?

This is going to be different for everyone but one of the very first jobs, when starting
out on a big project, is to create our source of determination. It's our safety net.

However, we'll first be talking about how to create passion.

Passion:

Determination goes hand in hand with passion. When we start out on a project we feel
passionate about it - at least we should - but we can exaggerate our passion by thinking
things like....

We are going to be the next great game developer.

Our game will be amazing.
We are going to live out our dream.
I love games and can't think of anything better than to make games for a living.
We can create the lifestyle we've always wanted.
We are going to turn our life around and make something to be proud of.
We will get to play the game we always dreamed of.
We will show those who didn't believe in us what we are really made of.

These are the types of thoughts that generate passion, and we need to fuel that fire. We
need feed it until that fire is an inferno because that fire will slowly dwindle and the
bigger we make it at the start of our project, the longer it will last.
When our fire of passion is burning low, we can return our thoughts to those original
aspirations and get a quick jolt of much needed energy. We stoke our fire again. We
remind ourselves why we started making our game and the fire will burn strong again.

NB: The passion goals we set for ourselves should be deliberately exaggerated for
maximum effect but we should be careful not to delude ourselves into believing they
will happen. That can lead to disappointment and other bigger problems. Nevertheless,
if we don't reach for the stars we have no possibility of reaching them.

Let's discuss techniques to keep that fire burning indefinitely.

List your sources of passion.

Losing sight of those powerful original reasons for making our game is a common cause
of losing motivation. The hard work, the long hours, and the many months or years of
hard work ahead can easily drag us down and overwhelm our more positive thoughts.

Make positive thoughts a habit, not negative ones.

Don't entertain those negative thoughts. The moment they pop into your head, push
them out so that they don't become a bad habit, and instead remind yourself why you
started making your game in the first place.

If we have made a list of those sources of passion, then we can easily look at that list
again whenever our energy levels are flagging. This creates a habit of positive thoughts
rather than debilitating negative ones.

Simply looking at our list will fire off all the same positive emotional responses we
originally had when we wrote it.

The longer we look at it, and the more time we spend refueling our fire, the more
passionate we will become again.

Imagine your future in vivid detail

Imagine what life will be like once your game is finished and a success.
Exaggerate this imagination.
Don't worry if it seems unrealistic; it doesn't matter.
Make it full of powerful uplifting emotions.
Fill your imagination with over bright colors, sounds, feelings and even tastes.

The more areas of our brain that we connect to this vision of our future, and the more
exaggerated we make our imagination, the stronger and more permanent our drive and
passion to get there will become.

The longer we spend doing this the stronger this future version of ourselves will become
in our minds and our drive to move in that direction becomes stronger and stronger.
Magic:

There's even a little bit of magic that happens once we go through this process.

Even when we forget about it, our subconscious will remember. We will have created a
specific goal and connected it to all areas of our brain. Without consciously thinking
about it we will find ourselves making all of our day to day, and work related, decisions
based on which choice takes us in the direction of our ultimate goal.

Instead of thinking something like "Wow, I'm really not in the mood today, maybe I'll
play some DOTA", our subconscious will naturally instead fire the neurons that make
us feel like working in order to once again feel those the positive feelings that we've
associated with working on our game.

We end up feeling great when we are doing things that help us to move in the direction
of our goal.

Loss aversion and determination

We are strange beasts. Psychology has proven that we are significantly more
motivated to avoid losing something than we are towards gaining something.

We can use this knowledge to empower our determination. Rewording our goals can
make them infinitely stronger.

I have no choice but to keep working. If I stop...

I'll be back in the same hole I was in before.

I'll lose the sense of pride and satisfaction I've had for the last month while working
hard
I'll lose my self respect
I'll be a nobody again
I'll let those who doubted me win
I'll let those who robbed me win (this was my personal source of endless
determination)

Those types of thoughts feel horrible and we naturally find it easy to make choices that
help us avoid having to feel them.

Our subconscious soon connects the thoughts of not working, when we should be
working, with loss and we try to avoid that at all costs.

Loss aversion is more the source of determination than passion.

We don't feel passionate about avoiding something but we do feel determined not to let
it happen.
Build up your source of unwavering determination and it will always be there to catch
you even when your passion starts to waver.

List your sources of determination, in the same way you did for passion, and it's always
there as a quick reminder when you need it.
_

How our brain works and why the above

techniques work:
In it's simplest form our brain is little more than a bunch of neurons connected to other
neurons via association.

Fire off neuron 1 at the same time as neuron 1000, and we create a physical electrical
connection between the two. At first it's tiny and it will soon die out.

The longer we think about two things simultaneously, the stronger that physical
connection gets. The stronger it gets, the more effective it becomes, the easier it
becomes to slip back into that mindset, and the longer it will last.

How to use this knowledge:

Our job is to make that connection as big and fat and dominant as possible. We must
spend lots of time thinking about our future goal, and the journey that gets us there,
while simultaneously thinking about how amazing it will feel to do it.

On the flip side, we should also spend time connecting thoughts of not working, and not
finishing our game, with negative feelings of loss.

It's best to separate these sessions by a few hours so as not to cause the wrong
associative connections.

We can initially set all of this up in as little as two thirty minute sessions, but it won't
last.

How to make it last:

Remember at school when we must learn something for a test. We create the
connections in our brain to store that knowledge, and initially those connections are
strong, but those connections very quickly fade and we forget the knowledge. To keep
the connection strong we must return to those thoughts periodically and solidify those
connections for knowledge that we've made in our brain.

Learning through repetition:

We can learn something in a few minutes, but if we don't think about it again for a
couple of days it's likely forgotten. So we need to think about it again after a few hours
to teach our brain that it's important. Then we must think about it again after a day, then
after a couple of days, then after a week, then again after a month, then after a few
months. This is the process most of us use to remember someone's name.

Doing this teaches our brain that the information is important and it will naturally create
strong enough connections to retain it.

Enforcing emotions through repetition:

This same technique is true not only for knowledge but also emotional reactions. The
emotional core of the brain is the amygdala. It's job is to deal with emotions and
decision making and we can train it very easily.

We talked above about connecting thoughts of working on our game with uplifting
emotions, and not working on our game with negative emotions of loss. If you want to
test these techniques, you should not only do this at the start of your project but
periodically throughout the entire project to keep those emotional connections strong
and dominant.

He's a madman:

If this information is new to you, it could sound like mumbo jumbo and the preachings
of a delusional madman, but it's not. It's simply how our brains work and it's very easy
to use the knowledge to manipulate ourselves to reinforce certain behaviors.

Don't rush this process:

One important final point. Whenever you need to repeat the above process, spend at
least 15-30 minutes doing it. You have to fire all of those neurons up to a certain level
before they will begin to increase the size of the connections and doing it for just a
couple of minutes isn't very effective.

Spend half an hour vividly imagining your future, and why you are working on your
game again, and you will not only come out of that thirty minute session buzzing with
enthusiasm but you'll have increased the strength of the connections so that they will
last exponentially longer than they did since the last time you went through that process.

Alternatively, if you don't do it often enough, or for long enough, it becomes less
effective and takes longer each time you try.

Summing it all up:

Create an exaggerated positive vision of working on your game, your future and your
goals
Connect that vision with exaggerated uplifting emotions
Connect thoughts of not working on your game with negative feelings of loss
Do this often at the start of your games development to initialize and strengthen those
connections in the brain
 Do it again after a couple of days, then after a week, then again after a month, then 2-
3 months, then after 6 months, then a year.

Do this and your determination and passion will never burn out.

Or will they?

Actually yes. It's possible to use the above techniques to create so much passion and
drive that we overwork and burnout.

Most of us have done this without having used these techniques deliberately. We will
have used the techniques described above to create massive levels of passion accidently
by spending enough time thinking about a cool game we want to make. Then we rush
off and start to make that game, work crazy hours on it for a few days or weeks, before
we eventually burnout and give up.

So I'll be discussing time management and how to avoid burnout in detail in the
next article. It's actually quite easy.

Wrapping Up:
Using the word passion instead of motivation could be argued as being nothing but
semantics. In many ways it is, but for most people motivation is a side effect of passion.
Use whichever one works best for you.

Time Management:
As game developers, and especially solo game develoeprs, time is likely our most
precious resource. There's never enough of it and so it's important to use it as wisely as
possible.

Solo developers, and members of small indie teams, must wear many hats. We don't
have a boss to keep us in line, a weekly paycheck, nor co-workers to keep us motivated.
Instead, we must be self-disciplined in our approach to work.

One of the easiest ways to create discipline is by creating a regular work schedule that
we can stick to.

The Benefits of a schedule:

It creates a natural habit to work during work hours.

It prevents procrastination
It allows us to monitor productivity and tweak our schedule to maximize it.
It gives us essential time away from work to rest, unwind and have a regular life
It helps to create a sustainable work ethic that avoids burnout
Ideally we want a schedule that is as productive as possible. If time is our most precious
resource then we don't want to be wasting any of it.

Over the 4 years of my game's development I did a lot of experimentation with

schedules and productivity to find the perfect balance. This will vary from person to
person, but I'll share the lessons I learned.

Experimenting with work schedules and

productivity:
During early development I was excited by the prospect of my game. I wanted to work
on it all day and to a large extent that's what I naively did.

For the first two months I was averaging 60-80 hours of work each week. I felt proud of
myself but I was being stupid.

That work load was unsustainable and this soon became apparent. Relatively easy
problems soon became intangibly difficult and frustrating to solve. I was tired. My mind
was wandering. I was working too much. I was making bad decisions. Motivation levels
were dropping. I was wasting precious time.

The 40 hour week:

Over the course of the next few months I experimented with different schedules.
Eventually I discovered that the typical 40 hour working week was ideal for me. I'd start
at 10am, take a 30 minute break for lunch, and work through until 6pm - 6.30pm.

By 5pm, my natural motivation levels would usually start to waver, but that was fine. I'd
use the final hour to make a rough plan of what I'd be doing the following day, write up
my daily devlog, answer emails and wrap up any other odd jobs.

Time away from work:

In the evenings I learned it was best to totally switch off from work and not think about
it. I had so much work to do, and such limited time, that initially this was difficult for
me. I was inexperienced and didn't know better, but after experimentation I discovered
that my productivity levels increased if I gave myself a proper break and didn't think
about my game in the evenings.

I soon discovered that it was equally important to take weekends off. Productivity levels
increased again once I started doing that. Perfect. I wanted to be as productive as
possible, but I also wanted to maintain a healthy life outside of work. It was comforting
to confirm that the most productive schedule was an even balance of the two.
Regular week long breaks:

The next scheduling lesson I learned was to take regular full weeks off from work. I
would take a week off once every three months. This helped to keep motivation up but
after monitoring this schedule for the first couple of years I had hunch that it might not
be the best.

I would work for 12 weeks and then take a week off, but I found that my productivity
from around week 8 onwards was consistently less than during the first few weeks of a
work cycle. I would slow down. My eagerness to work would be lower, problems would
seem harder and take longer to solve, and I'd find the last couple of hours of each day to
be dramatically less productive.

Eventually I discovered, through experimentation, that it was actually better to take a

week off closer to every 2 months, rather than 3 months. With the 3 month schedule my
productivity in weeks 10-12 was as low as 50% of what it was in weeks 1-6. A little
basic math suggested that it would be equally productive to work at my full potential
over an 8 week schedule rather than push past that and eventually slow down.

Late into my third year of development, I tested the idea and it proved to be true. This
was a pleasant surprise. I enjoyed my work more. I was more naturally motivated, I did
better work, and I found myself with more free time to unwind and enjoy life. It was a
win win scenario, and I suggest all solo game devs at least experiment with this
schedule.

Short breaks each hour:

Once an hour take a 5-10 minute break. Get up and walk around. Both the exercise and
giving your thoughts a break are essential to increasing productivity. I wish more
professional working environments realized this.

Concentration becomes increasingly difficult the longer we need to sustain it. I

personally found my concentration would start to waver after 45-60 mins, but a quick
walk around and a change of scenery would soon fix that and I'd be ready to get stuck in
again for another hour.

Regularly moving around helps to prevent back problems and other issues caused by
sitting in one position for too long.

Another benefit is that the additional visual and mental stimulous helps us to solve
problems. I'd often find myself solving a problem and then planning what I'd be doing
for the next hour during those walk-around breaks.

Productivity increases, concentration levels improve, and work becomes easier.

Sleep:
Don't underestimate how essential getting enough rest and sleep is.

Game development is a taxing process full of problem solving. Solving problems

becomes exponentially harder and slower the more tired we become. What would
normally be a simple ten minute job can easily turn into a wasted day of going round in
circles when we are tired.

If you are genuinely tired it should be your highest priority to fix that as soon as
possible. I'd occassionally find myself taking a nap for an hour in the middle of a work
day because I knew my increased productivity for the rest of the day would far
outweigh that lost hour.

This seems like fairly obvious advice, along with eating well and taking care of
ourselves, but I would be remiss not to stress it in an article like this.

You will hear this same advice everywhere but that's because it's essential: lead a
healthy lifestyle.

If you aren't resting properly, and taking care of yourself, you are making both work and
life considerably harder than they need to be.

Avoiding Burnout:
If this article had been written in a different order, the discussion around burnout could
be a much longer one but by creating a sustainable schedule we've all but eliminated the
possibility of burnout.

Burnout is essentially nothing more than over working. The further we push ourselves
past our natural limits the more rest we will need to recover. Push too far, for too long,
and we can break. It's not worth it.

If you burnout, you'll feel terrible and assossiate all of those terrible feelings with
working on your game. This can be so severe that you may never want to go near your
game again. Avoid burnout at all costs. Never let it happen. It's a game breaker.

I soon learned that even when I was super motivated and eager to work, I should still
stop work at a scheduled time. Whenever I continued working enthusiastically into the
late evening my energy levels and productivity would invariably suffer over the coming
days.

So my advice is stick to your schedule. Even if you are feeling full of energy, it's better
to save that energy and enthusiasm for another day. In the long run your productivity
will be higher and you'll get more done.

_
Time Management and Planning:
We discussed making a master job list in the second article. That list contains the
backbone essentials for your game. Stay focussed on completing these in a timely
manner.

However, if you are anything like me, you will be constantly dreaming up cool new
ideas that would improve your game. They can come at any time but if we were to
implement every cool idea then we'd never finish our games.

So, create a list of those ideas. Note them down as they come to you but leave them in
your list for now.

New ideas always seem so much better than old ones. It's easy to feel like we must
implement a new cool idea immediately but that isn't good time management.

Stick to the job at hand. If you get distracted by a new idea, even if it's something that
should definitely be in your game, don't stop what you are doing to implement it. You
will only be wasting time if you do that. Note down the new idea but finish what you
are working on while it's still fresh in your mind. You'll be more productive that way.

We'll come back to this 'new ideas' list soon.

Planning what to do next:

After taking a week off, my first job would always be to spend a day planning what I'd
be doing over the course of the next few months. I'd make a list of the jobs that I'd like
to complete. Then I'd think through those jobs to get rough idea of what the next couple
of months would be like. This type of mental preparation is very productive.

To do this I'd start by looking at my master plan list. I'd pick the jobs that made the most
sense and add them to a new list. Sometimes there wouldn't be an obvious choice, so I'd
simply pick the jobs that I was most enthusiastic about.

I'd also make sure to throw in at least one or two of the more boring or tedious jobs.
Nobody enjoys adding things like save-game functionality but eventually it has to be
done. Spreading these more tedious jobs out over the course of development prevents
the scenario where all the cool stuff is done but we are left with months of tedious
boring work at the end. I've heard many tales of game devs quiting because they made
that mistake.

Next I'd go through my list of new ideas. This was usually pretty big. I'd scan through
the list and there would always be a couple of ideas that stood out from the crowd.
Many of the ideas that I'd enthusiastically added in the past would suddenly seem
terrible in hindsight, or I'd realize that the time investment required to implement them
simply wasn't worth it compared to other better ideas in the list.
Choose the ideas that you believe would improve your game the most compared to the
time investment required to implement them. Add those to your job list for the coming
couple of months.

Now, you have a rough plan for what you will be doing next. Scan over your list and
spend the rest of the day considering each job in turn.

The idea here is to get the mental ball rolling on these new jobs. If we start thinking
about them now, we will naturally find ourselves thinking about them again over the
coming weeks so that when the time comes to start implementing them, we already have
a good idea how we are going to do it.

Planning Tomorrow:

Here's a similar, simple, but effective routine.

At the end of each day, spend fifteen minutes planning what you will be doing the next
day.
Consider what jobs you will be doing and what those jobs will entail.
Make some brief reminder notes and read them again in the morning to kick-start your
day.

Doing this has many benefits:

You get the mental ball rolling

Ideas and solutions to potential problems will often come to you without any
conscious effort during the evening.
You will be more eager to dive in to work the next day because you are already
prepared.
You do better, more productive, work yet it feels much easier.

I can't recommend this simple routine enough. Try it and you'll immediately see the
difference it makes.