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.

 

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.

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.

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