The A-Z of Game Development

At the end of 2011, seven game developers from six different studios sat together to record a podcast. The theme they were given was the top tips for game development, and over the course of the recording they pooled together their experience to come up with 26 pieces of advice that every developer should at least consider. I realised that there was a wealth of knowledge being shared, and that someone should write it down in an article. This is that article.

Special thanks to Andrew Bittman, Dan Graf, Paul Gray, Saul Alexander, Tim Grants and Tim Taylor, my co-hosts for the podcast and the co-authors of this list.

So without further ado, here are the A-Z of Game Development Tips (it’s seriously a coincidence that there were 26 of them).

A. Communication in teams is paramount

This one kinda speaks for itself. When you’re working in a team, even a small team, making sure that your internal communication works smoothly is one of the most important things you’ll do as a game developer.

B. Always focus on your audience (a.k.a ‘The User Experience’)

Know who you’re making your game for: their age, gender, likes, dislikes, what other games they play, what they like and why they like it. Then, make sure you’re thinking about the experience you’re creating for these people. As HalfBrick’s Luke Muscat put it in a talk at GCAP, “it’s how the player perceives it” that’s important.

C. Networking

The number of really supportive groups of game developers is somewhat ridiculous (the IGDA and TIGSource are a couple of examples), and the people in these communities will give you some amazing advice. So ask them.

D. Culture is more important than skills

You can have a team with the most amazing set of skills ever, but if you don’t have a studio culture where they gel, work well together, and most importantly trust each other (and themselves), you’re gonna have a hard time making a game.

E. Know What’s Involved (a.k.a ‘Learn the Boring Stuff’)

There are so many aspects to making a game (art, music, programming and design are the big four), not to mention making a game studio (leadership, legals, marketing, accounting) that it’s a little overwhelming. You can’t know everything, but you really don’t want to go in blind. Make sure you go in equipped – being aware of the logistics of game development will put you ahead by miles.

F. 48 Hours

Linked to the previous point, this is just saying that you should make games, and make them quickly. For me, 48 hour competitions such as Game Jam and Ludum Dare were a way to learn a bit of everything in the development process. The result is a greater ability to communicate with other developers.

G. Don’t Forget the Words (also, Cinematography)

This point started out about words alone: too many games have bad writing, and the industry’s been at it for long enough to know better and hire writers who know both how to write and how to deal with interactivity.

The fact is that writing isn’t the only form that gets lost in games. Cinema has learnt and now knows how to compose a shot (ie. cinematography) incredibly well, and yet we continue to see shoddy cinematography in games. Getting these aspects right can make a massive difference in your audience’s perception in your game.

H. Version Control

Every so often you hear a story of an awesome indie team whose work is utterly ruined because a hard drive failed/laptops were stolen/their home planet was demolished by a death star. In two out of three of these cases, their work would have been saved if they’d used version control.

Version control is simply a way of keeping track of changes to a software project over time. Typically, all team members commit changes to a central (ideally remote) server, ensuring not only that everything you do is backed up, but that conflicts between programmers working simultaneously are easily resolved. As a bonus, this means that if you screw up your entire codebase with bad refactoring, you can easily revert to your last working version.

As an extra measure, I like to put my source repositories inside a dropbox account for super-extra-backup goodness.

I. Dissect your Competition

Know your enemy. Know your friends. Hell, know your loose acquaintances. If you’re able to rip apart and examine the games that are out there, you can find all of the things that bug you about certain games, whether those annoyances are within the game mechanics, the art or the menus. And then you can make sure you don’t make the same mistakes.

J. Capture and Use Ideas well

This one’s a 3-parter: 1. Write down all your ideas No matter how ridiculous, obscure or simple, you really should be writing down all your ideas. You never know when that stupid idea from yesterday, last week or last year will suddenly become important, relevant or simply great.

2. Make Lots of Prototypes Prototyping is the only real way to figure out which ideas are worth pursuing and which parts of an idea are most important. By prototyping, you can quickly and easily figure out whether a game is working and whether to continue development on it.

3. Kill/Neglect your babies If it’s not working, can it. It’s incredibly important to be able to recognise when an idea or game isn’t working, and it’s something that can be incredibly hard to do when the idea is yours. Letting go of an idea, or even just shelving it for a while, is the best way to make room for new ones.

K. Anchor your Processes

When you’re developing, it’s important to be constantly updating your processes, whether they be your basic work practices, the scope and design of your game or your development tools themselves. However, when you’re doing this, you’ve got to be careful not to have too many things in flux at once, or you will quickly lose your direction.

A counter to this is to anchor parts of your process: don’t allow your requirements to change for a few weeks at a time and lock down versions of your tools for your designers to use.

L. Set your Scope (a.k.a Stop Scope Creep)

Scope Creep is a pretty awful thing. It leads to project delays and large requirements, which lead to more project delays and larger requirements, which lead to… you get the gist. The best way to prevent this is to set your scope near the start of the project, so that you have a clear boundary within which requirements can change. Once you’ve done this, the magic words are “That’s a great idea! We’ll put it in the sequel!”.

Note that you shouldn’t set your scope too early: your first steps with a game idea should be to brainstorm with unlimited scope to find the ‘golden feature’ - the feature that makes your game unique.

M. Learn to Produce

There’s currently a lack of good producers in the game development community, and it’s a role that’s rather important. The producer’s is in charge of the entire production, meaning that they need to a) figure out what needs to be done, b) find the right people to do it, c) delegate tasks and d) monitor progress. In addition, the producer acts as the decision-maker: a person who is able to make tough calls and deal with conflicts.

N. Playtest

Every game needs to be playtested. You cannot know how a fresh player will react to a game. Unless you playtest. So playtest.

O. Don’t tell your Playtesters what to do

When you run your playtests, your testers are giving you really important data about how a new player will react to your game. If you tell them how to play, however, you lose all that important feedback. Unless you have a specific reason not to, it’s generally important to let the tester play the game without external influences.

P. Learn to let go

Perfectionism can be a wonderful thing, but it can also be a curse. It’s vital that you let go of development and release your game at some point: as the saying goes, ‘Art is never finished, only abandoned’. Each game has a different balance of perfection and development speed, and finding where your game lies on that scale will help ensure that you actually finish with the desired quality level.

Q. Failure is Good

Failure is incredibly important in how we learn: you’ll notice that games themselves are designed to help the player learn from failure (death usually has a price, but is almost never actually fatal). The same applies to game development itself. It’s only by putting your games out there that you can learn what works, and while the amount you can fail is limited, possible success is limitless.

R. Deep People, Shallow Management

In general, it’s a good policy to have as shallow a management structure as possible, to ensure that decision-making doesn’t have to move up and down a long chain of command. This can help a lot with horizontal communication - that is, communication between different departments (art and programming, for instance).

S. Learnability and Curiosity

Anyone who thinks that they’ve learnt everything they need to before they start making games (whether it be through self-study, university, a college or other) is deluding themselves. One of the most important things about being a game developer, or any other profession, is your curiosity and ability to continually learn new things. You’ll never be done learning, and that’s a great thing.

T. Reflect on Everything

Everything you do as a game developer can be improved on, and its only by understanding this, reflecting on what you do and learning from your experiences that you’ll move forward. Writing postmortems is a great way to do this, as they force you to externalise the things that went right and wrong in your development process.

U. A prototype is better than a Game Design Document

A lot of people write game design documents, some of which are of ridiculous lengths, as a way of initially specifying their game. The simple fact is that a playable prototype of the game is far more useful at the early stage of development. It not only demonstrates rather than explains the design, but it allows you to test which parts of the design are working. A design document can be invaluable once a prototype is made, but a prototype is a much more valuable first step.

V. Play on your Brand

When marketing your game, it’s always fun (for both you and your audience) to play upon your brand and what you stand for (for example, Convict Interactive are currently looking at using mugshots for their business cards). Games are supposed to be fun, and giving your audience a good chuckle is always a good start.

W. Work out your Zeitgeist

This tip involves looking at games in a particular way: as machines carefully designed to produce emotions in the people who play them. Working out what emotions your game is going to produce and how you might produce them in specific people will help you answer all of the detailed design and development questions you’ll encounter.

X. Find Business People, Meet Entrepreneurs

Starting a game development studio requires you to know as much about business as it does about game development, and it’s easy to overlook this half of the equation. Finding business-minded people for your team can be invaluable in helping you with this aspect, as can becoming involved in the entrepreneurial community, both locally and globally.

Y. You need OPM (Other People’s Money)

As a part of this business aspect, it’s important to realise that self-funding your project can really only get you so far (and not very far at that). You need to get OPM, or Other People’s Money, as soon as possible, whether it be through pre-sales, venture capital, incubators or other avenues.

Z. There are no Rules

Finally, a reminder that these are tips, or guidelines, and not hard-and-fast rules. It’s just as important to understand them thoroughly so that you know where, why and how to break them as it is to follow them.

So ends our alphabetical journey through game development tips. Be sure to check out the podcast episode that inspired this article and other episodes of The Game Engine Podcast, and good luck with all of your game development endeavours!