Category Archives: Production

Some Rules for Games Production

Before I leave the world of work-for-hire games production for something a little different, I thought I’d jot down a bunch of guidelines I’ve encountered over the years that help with making games.  These are especially true when making games for publishers or similar clients and whilst I’d imagine anyone out there with a lot of experience does these anyway, they might just jog a few new thoughts.

51 Random Guidelines for Making Games

1)      Hit your milestones.

2)      I’m serious, hit your bloody milestones.  Get the work done with a good 20% of the milestone left for bug fixing and ephemera.  Plan with these deadlines in mind.

3)      Start every project with the belief that you can make a great game.

4)      Start every project with the goal of getting it out on time and under budget.

5)      Great games and on-time delivery aren’t mutually exclusive if you make careful decisions and employ good production methods.

6)      Prioritise your work.  Take into account your design team and your stakeholders’ wishes here.  They’re both right, they’re both wrong, you need to help them find accord.

7)      Mediate.  Your most important job is preventing talented teams from tearing each other apart.

8)      Don’t forget about audio.

9)      Budget and schedule for the pitch process

10)   Understand your game’s vision and sell it to the rest of the team at all times.

11)   Understand your game’s vision and sell it to your stakeholders at all times.

12)   Manage your relationships.  Be courteous to all the people you work with or work for.

13)   If you’re working with a publisher, get in contact with the brand manager on your game and get them on your side.  They have the capacity to torpedo you in the final stages of dev.

14)   Aim for a healthy profit in everything you do but don’t be short sighted.  A well-executed but barely profitable job can extend your company’s portfolio and be just as valuable as a result.

15)   Remember that it’s okay to ask for more money when your stakeholders ask for more stuff.

16)   Make sure you’re developing your team. Personal reviews are important two-way conversations between you and the folk who keep you in a job.

17)   People like to be rewarded with control over their work. Give people goals but let them work out how to achieve them.

18)   Use pre-production to build something, even if you throw it away.  If you finish pre-pro with nothing but a bunch of beautiful documents you’ve done it wrong.

19)   Documents are not very useful if you don’t keep them up to date.

20)   Keeping documents up to date is an absolute bitch so make fewer documents.

21)   Prepare.  For meetings, for conversations, for the start of every day.

22)   Sometimes you need to micromanage stuff. Do it for as short a time as possible or it will kill you and your project.

23)   Be prepared to pivot when things need to move in a new direction.

24)   If you’re making a big change be prepared to spend a vast amount of time convincing the team that it’s the right thing to do.  It’s vital you bring them with you.  Do this with one-to-one’s, email, IM – do this with your general presence on the team.

25)   Be aware of the wider market – your job goes beyond the current game you’re making and the games you like to play.

26)   Be aware of your team’s limitations and guide your project accordingly.  Aim to push your team but don’t rely on unrealistic expectations.

27)   You are primarily a facilitator.

28)   Don’t rely on new tech until it’s proven out.

29)   Talk, and encourage your team to talk. I’ve never seen a team that’s buzzing produce work that’s late or subpar, EVEN IF ALL THEY’RE BUZZING ABOUT IS A FUNNY CAT ON THE WEB.

30)   Get QA on board as early as you can afford them

31)   Don’t ignore the bug list.

32)   Understand your game’s brand.

33)   Asking for help is okay.  You are at your weakest to your team when it becomes clear you don’t know what you’re doing, NOT when you’re asking for help.

34)   Get really good at listening.

35)   Ignore the haters on the Internet (unless they’re right).

36)   Become a great storyteller.

37)   Make mistakes and make them early.  You’re not trying if you don’t fuck something up.

38)   Learn from your mistakes.

39)   Keep your word.

40)   Remember that there are times when your stakeholders are NOT actually trying to screw you.

41)   Become a sales person.

42)   Admit it when you’re wrong.

43)   The little stuff matters.

44)   If someone asks you a question and you don’t think you know the answer, remember that it’s okay to say that you’ll get back to them.  Just make sure you do get back to them.

45)   Understanding the personal motivations of your stakeholders is important. It helps you get to the bottom of the why, which is important for when you start to work on the how.

46)   Work on your presentation skills.

47)   Tell the people above you what’s happening on a regular basis.

48)   If you work for a bunch of dicks, make sure you log these conversations by email

49)   Sometimes, any decision is better than no decision.

50)   Sometimes thinking things through first makes more sense.

51)   Enjoy it, you’re making games ffs.

Leave a comment

Posted by on June 15, 2011 in Management, Production, Project Management


Who is your game aimed at?

This post follows on from this one about defining your game’s personality and making sure you sell that to your team and your stakeholders.  Selling a vision to a team is all well and good, but if you want to make sure the vision you’re selling is on point, you need to spend some time working out who your game is aimed at.


You already know that this is important to your game.  Everyone does.  It doesn’t take a design genius to know that a game aimed at teenage girls probably shouldn’t focus on tight Street Fighter timing and controls.  It’s worth remembering however that while the ‘who’ you’re aiming your game at clearly has an impact on what you make it also has a distinct impact on how you make it.

Who’s Actually Going to Play This?

So often in development this is something that the people selling your game don’t actually, fully know.  They’re either waiting for stats about hardware sales to come through or they’re hedging their bets while they gather data on other, similar titles.  That’s fine to some extent but developing a game with absolutely no idea to whom it’s going to be sold can absolutely wreck your game in later stages of development.  Publishers do focus tests some time after alpha and end up saying things like:

“It turns out that soccer moms really, really dig the basic concept but hate the main character.  I know! It’s crazy, we weren’t even targeting them with this title.”  Then there’s an awkward pause.  “It’s fine to change the main guy right?”

Extreme example maybe (or maybe not…) but even small changes at a late stage can kill a project by a thousand little cuts; heading off as many of them as possible at the beginning of a project by knowing EXACTLY who you’re selling this game to is a worthwhile thing to do.  So if the people selling your game don’t know exactly who they want to sell it to yet, you need to work with them to define a target audience you can all agree on as soon as possible.  You also then need to spend a good deal of effort throughout the lifecycle of the project making sure that they understand that design decisions are being made based on this audience.

Take control

If you’re publisher or sales team has no clear idea who they want to sell to, there are a couple of things you can do.

  1. Use your experience as a developer to work out an acceptable target audience for the general game idea (if the publisher are looking for a WWII FPS this is pretty straightforward, if they want a golf game featuring wizards and orcs it’s less so).
  2. Develop the game whilst budgeting and scheduling for a lot of focus and usability testing.

The first point is relatively straightforward but still comes with the risk that the publisher changes their mind later on in development (although by agreeing age groups and target audiences up front you’ve minimised this to some extent).

The second option is the ideal line to take.  If you’ve got independent facts about who liked what about your game, whether it’s something as general the concept art for the main character or something really specific like the number of people who prefer clicking and holding the thumbstick to duck, you can always rely on metrics.

A Note about Testing

The trick with testing, as someone I once worked with sagely said, is to “never listen to anything anyone has to say in usability tests”.  You need to make sure you’re information is coming as much from measurement as possible.  People lie, people misunderstand questions and very often people get carried away with being in a focus group and tell you anything as long as it seems like it’s what you want to hear.  You can attach metrics to almost any aspect of your game if you design the tests.  Want to measure whether people like a certain character design over others?  Measure length of time they spent looking at conceptimage4.jpg when compared to images 1,2 3 and 5.  Even better go to a proper testing facility and measure their biometric reaction to it.  You can interview people about the designs on top of this but getting a measure of something as simple as time spent looking at the image can assist you in filtering these interviews.

Design for your market and test it

If you’re in the business of making games that are intended to be sold, you’re making them to a market.  Sometimes this market is simply people who like fun new things and you can go ahead make the next Limbo but often the reality is that you’re making something where your vision holder needs to work with a variety of stakeholders and here understanding and testing the market you’re aiming at is key.  A good designer’s gut instinct about something should never be ignored but testing a hypothesis out either with up-front focus testing or with user testing a prototype can help you make an informed call about whether or not you want to devote a portion of the game’s budget to a new feature or not.  You don’t even have to go to the trouble of focus testing some ideas, building up a good competitive analysis of similar titles and checking their reviews for clues as to why it scored well or badly is a hugely valuable task for designers or production assistants at the start of a project.  Just make sure this data is searchable, either by being properly tagged in a wiki or in a well-specced spreadsheet.

In Conclusion

So over the last few of posts, we’ve looked a little at the idea that it’s important to be able to define your game’s personality but also why it’s important to make sure that personality matches up with a target audience.  Test, research and confirm with your stakeholders what you’re making and then make sure you sell that game to your team and your company.  It’s vital that people work towards the same goal and that’s staggeringly difficult to ensure with a game, something that takes years and tens (often hundreds) of people to do.

Leave a comment

Posted by on March 1, 2011 in Design, Process, Production


Who is your game and who is it aimed at?

These are two key questions that need to be answered right at the start of development.  They need to be understood and agreed upon by whoever has the job of selling your game and they need to be thoroughly and absolutely communicated to your team by your vision holder.   I’ll look at both questions over the course of a couple of posts, looking first at the concept of a game’s identity.

It's a question

Who is Your Game?

Whether a dev team intends it or not, every game ends up having a personality.  It’s in how the game feels, how the game plays and how the game communicates with its audience.  You find it in the dialogue, the animation, the way the game punishes and rewards you, the environments, the characters, the audio and the GUI.  It’s the first thing a player will sense and it’s often the only thing they’ll remember when the game is back on the shelf or sitting in a second hand bin in GameStop.  The best developers spend a lot of time honing this personality, this vision and then make sure every aspect of the game oozes with it.  The worst don’t even acknowledge its existence and their game comes out confused and weak; built by committee.

Coming up with a vision is a process that is particular to individual teams and designers.  It can come by divine spark, from boardroom discussions or from great brainstorming sessions but it’s not the subject I’m interested in here and now.  What I want to look at comes after you nail this vision; it’s about how you make sure it runs through the life of your game and how everyone involved in the game’s creation stays true to it.

Get the Vision Out There

Once your vision holder has the vision in their head, they need to get these out there to everyone else.  Everyone on the game team should know the game vision.  How is the game supposed to feel? Why is that important?  What is the game’s personality?  I wouldn’t expect everyone on the team to be able to answer those questions as succinctly as the vision holder or producer but I would expect them to be able to get the key points across.

My preferred method of communication here is to boil your design down to two key words, then work up a key phrase and branch out to some key images and rules.  Once you have these, get them on a wall somewhere in the team area and make sure everyone sees them.

Key Words

Nailing two key words is hard.  You want more.  You want sentences.  You’ll argue about them with everyone if you’re brainstorming it and you’ll argue about them with yourself if you’re going it alone but keeping it to two words is a really good way of ensuring that you know the absolute top priority, nitty gritty elements of how you want a user to feel when they play your game.  The last game I worked on ended up with two words only after a five hour meeting between the project leads, the vision holder and the studio design director.  It was a nasty meeting – at one stage featuring only the word FUCK in block capitals on a whiteboard but we came out with something rock solid that we referenced right up until the dying days of bug fixing before release.  Does this feature/art/bit of polish magnify one of the two key phrases?  No?  Then have another think about it.

Key Phrase

Once you have your key words, you can move onto a key phrase.  The most useful part of doing this is that it can be attached to the branding side of your game from an early stage.  Brand people like a strong phrase because it attaches emotion to a product in the same way a strong image does – you can use this to help others get their heads around how your game will feel.  Where the two key words are used as ideals to hold all project work up against, the key phrase is used to sell the emotion of your game.  It can describe the game or it can be something a little more abstract, it depends on who you’re dealing with.  Descriptions at this stage can be risky because they can start to list content and that’s something you want to leave until a little later in the process but likewise if you’re dealing with fairly literal people, they can be the most succinct method of communicating the game’s feel.  Try to fill it with powerful words and active verbs and try to keep it short too, 50 – 70 words should be plenty.

Key Images

Words are good but visual references are by far the quickest way of accurately selling an idea to others.  If you’re lucky enough to have a vision holder who can wield a Wacom tablet, you’ll do well.  If not, then Google Image Search and understanding concept artists are your only options.  The vision holder needs to reference anything from games, TV, film, graphic design etc. that they feel helps get the game vision out of their head.  These can serve as precise visual targets to hit or simply inspiration but images are so easy to point to and discuss that they can save hours of explanation during the development of a game.

It’s also worth noting that there are usually a few visual or character traits that people commonly attach to your game that aren’t relevant and it’s just as important to pick these out and make them public.

Vision Presentation

Once you’ve got these images, words and phrases picked out, do a PowerPoint and ideally present this to your team somewhere.  I know, PowerPoint presentations are for sales people and marketing assholes but I’m a huge fan of what a well crafted PowerPoint can do.  At their best, they provide a simple, lean message that cuts out the fluff of a Word document.  Fewer words mean more eyes will read them all and that’s exactly what you need here.  If you haven’t got a boardroom or area to present it, email it around and spend time with people making sure they’ve seen it and understand it.

Vision Wall

This is by no means a new concept but it backs up your presentation beautifully.  A vision wall is a tried and tested way of getting key images and ideas front and centre and gives anyone who visits your team area a clear idea of what you’re trying to make.  Your vision holder should put up their key images and these should be grouped by game areas if necessary (GUI, level 1, boss encounters) and updated regularly to keep it valid.  Your key words and key phrases should be up and you should also put regular screen captures from the game to highlight areas that are working well and strongly support the game vision.

Some words from this blog post in a cloud

We’ll deal with ‘who’s going to play your game’ in the next post.

1 Comment

Posted by on February 9, 2011 in Design, Production, Project Management