The 5 biggest problems game designers have to overcome to create a successful game.
Every game has its problems in development. Some are genre-specific: the difficulty of telling a rich story within the confines of a game, for example, isn’t going to concern you if you’re creating a simple match-3 puzzle game. In this post I’ll focus on the obstacles that crop up almost every time: the 5 biggest problems that every game designer must overcome with every project they’re involved in.
Which problems feature most prominently depends on the nature of the project and the people involved in it, so the list is in no particular order:
“How can we compete with other games like ours if we don’t offer everything they do, plus some extra features?”
Many novice designers – myself included – have bitten off more than they can chew when first given a shot at designing a brand new project. It takes considerable experience to get a feel for how much a team of a given size can get done in a defined period; the only reliable answer is “less than you’d think”.
If in doubt, cut.
Collaborating with experienced developers on your team will help you avoid overscoping, but you can’t just rely on gut feeling – you need actual time estimates from each team for each feature you plan to include. When estimating times for any task, I recommend you think how long you’d expect it to take you, and then at least double it. This helps to account for time spent on iterating, fixing bugs, technical issues, feature creep (see point 5), etc.
Then, when you find you’ve planned too much, take a deep breath and cut stuff. Which brings us to problem 2.
2) Attachment to Ideas
Some things are easy to cut; being tacked onto the concept as extras, they fall away cleanly, leaving the core intact. Co-op mode? Gone. 15 levels? Make it 10.
Where it gets hard is when there’s nothing left but great ideas working seamlessly as a whole – and they still don’t fit the schedule. “Kill your darlings” is the oft-used phrase, and it applies just as much to game design as to writing. A designer has to be willing to drop a cool idea that just doesn’t fit in with the rest of the project – whether because you don’t have the budget for it or because it doesn’t play well with other components of the game.
Clinging to good ideas that aren’t working isn’t always healthy for your game.
How do you identify what to cut? It’s a simple rule: identify the core of your game – the key mechanic(s) or feature(s) that make it unique, interesting and fun – and consider cutting anything that doesn’t enhance that.
If you want people to play your game, you need to teach them how. The more complex your game is, the more of it you’re going to have to devote to tutorials. Tutorialisation is a critical aspect of game development, yet it’s often neglected until rather late in the development process.
Problems arise when you haven’t designated sufficient space in your game to teach everything you need; when you’ve left things so late that your options are limited to awkward pop-up dialogues; and when you fall into the trap of trying to teach everything when players can easily figure some things out for themselves. (The best way to find out what you actually need to teach is via extensive external playtesting.)
A critical learning moment early in Portal – with no words required.
The very best tutorials are incorporated seamlessly into the gameplay: learning through doing (Portal is a famous example). To achieve this, you need to have planned them in the game design from the get-go. You have to think carefully about pacing: too many new concepts in a short space of time kills the game’s momentum and leaves players confused. Too few, and they will be chafing at the bit to get to the “meat” of the game.
4) Balancing and the Problem of Familiarity
A lot of indie games earn a reputation for being rock-hard. For some players, this is a selling point, and games like Don’t Starve and Super Meat Boy wear it as a badge of honour. But in some cases, the game designer may not entirely have intended it that way.
There’s nothing wrong with a tough game – as long as that was the intention.
Most developers are – or were at some point or another – pretty hardcore gamers. Someone who plays a ton of games is always going to make lighter work of a challenge than a novice or casual player. But the bigger problem with balancing your own games is familiarity: nobody knows your game like you do. When you play, you’re subconsciously using all the tricks and patterns you’ve learnt from playing it day in, day out for months or years.
Listen to your QA team, especially the new guys on the project. Get members of the public – family or friends – to playtest your game, and watch them do it. You’ll be amazed at what they get stuck on – things that seem perfectly easy or obvious to you.
5) Feature Creep
While overscoping happens mainly in the design phase, the problem of feature creep occurs throughout development. It’s insidious, and can be hard to deny:
“This possession feature will make the game 50% better, and only take me a couple of hours to implement!” cries the lead coder.
“Look, can we just add one more variant on this monster? I’ve got a really cool idea…” muses the lead artist.
“It would be a cheap win to allow upgrading your weapons, look, it wouldn’t even need any new art!” announces the lead designer.
And at the end of the project, after the second negotiated deadline extension, in the third month of crunch, everyone stares at each other with feral gaze over strong coffee and half-eaten pizza. In silent communion, they swear that next time, next time they’ll keep a lid on it.
Too many small improvements add up to a lot of extra hours.
The only time I’ve ever seen feature creep successfully reined in was at the hands of a competent, well-respected project manager willing to put their foot down (and even then, it was tight). If you find such a person, be sure to appreciate them, even as you hate them for stomping on your perfectly reasonable ideas.