The 10 most common mistakes made by Game Designers - Part 1

When you're designing a game, you've always got to keep in mind the poor player. Your poor player is the entire reason you're making a game. Sure, you could be making a game for yourself but that's a bit like writing a book or drawing a picture for yourself. You're already going to know how it turns out and there isn't any sense of discovery when you play it.

Today, we're going to get to know your poor player. We're going to take a look at the 10 most common mistakes made by Game Designers, and how to avoid them. These aren't just 10 mistakes I've seen teaching Kahootz in schools, or 10 mistakes I alone have made while designing games. These are the top 10 mistakes that are being made by even some of the best designers.

10. Making the game too hard
You've created an elaborate puzzle game where the player has to pit their wits against a series of fiendishly difficult riddles, math problems and logic patterns, but your player has just spent the last hour trying to work out the code to get in the front door.

High-Profile Sinners: Myst, The Castle of Dr. Brain, The Legend of Zelda

Why it happens:
You've got some great puzzles for a game. They're going to really confuse your player but they're obvious if you think about it, right? Unfortunately you aren't always going to be around if your player can't work out why the door knob won't turn, even though you know it's obviously because they need to pick the lock.

Hot to avoid it:
Simply put, your player might need a little bit more of a hint. Is there a way you could use sound and pictures to suggest that the door is locked? Maybe a thunking sound or an animation that shows the door getting caught on something just as it starts to open? This is called player-feedback, and it lets your player know what reaction they see whenever they try to do something in the game. Player-feedback is critical, it helps the player feel more involved in the game and teaches the player some of the rules of the game (such as, sometimes you have to pick the lock to open a door).

9. Making the game too easy
You've got another great puzzle, but if you make things too difficult you're going to end up with a frustrated player. You give them hints and make everything as clear as possible. Suddenly you find no one wants to play your game because it's too easy. What went wrong?

High-Profile Sinners: Red Faction: Guerilla

Why it happens:
It happens when game designers try to make their game easier, but accidentally go too far and take away all the challenge by giving the wrong kinds of hints. Players are very happy to play a game that is challenging or difficult if they have clear objectives. Hints and player-feedback should not patronise the player by giving away every little secret or lighting the way to each little hidden treasure. Learning and exploring is what makes a game fun, don't let the hints take away the fun.

How to avoid it:
Be careful not to give too much away when your giving hints. Game Designers have to be very careful to balance what hints they give out and when. Hints and player-feedback are important, but it's the way you give those hints that are the key. As any writer will tell you: show don't tell. Instead of using huge swathes of text to signpost every little part of your game, maybe you could use sounds or images. Let's say, for example, that your player walks into a toxic gas cloud and falls ill. A game might flash a warning text on the screen telling the player where to run to for medical attention, but a good game might make everything you see turn green and the character might start limping and struggling to walk in a straight line. This sudden change leads to a sense of urgency and forces your player to engage with your game, to remember where they last saw a first aid tent for example.

8. Teasing the player
Your player has just discovered a wonderful new magic power, or a fantastic new piece of equipment that suddenly makes even the most difficult enemy a mere distraction. It's fun playing with their new 'superpowers'. But then they're taken away, without warning, never to return.

Where did I put my black-hole anti-matter blaster? I had it just a second ago...

High-Profile Sinners: Half-Life, Splinter Cell

Why it happens:
It's cool when you get a new toy, especially when that toy is a powerful mega-robot with hover jets and invisibility.

There it is, hovering behind the other invisible mega-robot.

Game Designers love giving players new toys, and players love getting new toys. When done well getting a new 'toy' revitalises the game and gives the player more enjoyment out of familiar, predictable environments as the player effectively relearns how to interact with the game. The problem is that sometimes these toys are too powerful. Nothing is a threat to the player anymore. The game is no longer any fun without the threat of defeat. The Game Designer has realised that they've made a mistake by letting the player get so powerful. So the game pulls a swifty: a contrived reason is found for the player to lose these new-found toys - whether that be theft, betrayal or unexpected catastrophic meltdown. It's not clean and it's not pretty, but it happens.

How to avoid it:
Let me clarify that the problem isn't giving players these toys in the first place, in fact offering treasures and toys like this can be a great way to reward your player and keep them engaged in your game. The problem is the way in which these toys are suddenly yanked out from under your player. It's perfectly acceptable, and in fact quite fun, if there's a good reason for suddenly losing all your hard earned treasures. Good Game Design encourages a strong story. If you're going to give your player a toy, make sure they know why they're getting it and make sure they understand the limits you've placed on using it. For example, a catapult would be great fun to roll around a medieval battlefield in, reigning down unmitigated destruction. But once the battle is won, there's no use in a lumbering catapult when your actual job (monster-hunter) requires stealth and good aim. In fact, you only have such a machine because the King lent it to you, he may well order you to return his expensive contraption once you've saved the day.

We'll continue the list over the next few weeks until we reveal the number one most common mistake a game designer can fall foul of. Hopefully we'll see you all again soon.

Stay tuned!

Anthony

The Design Process

Making a game takes planning. In fact it takes a lot more planning than most people expect. Kahootz and Kodu allow people to jump on and start making a game straight away, but unless you've put some thought into it before hand, more often than not you end up with something that isn't very fun.

Don't get me wrong, when you're first learning to make games, jumping in head first may be the best learning tool you've got. You're just playing around, seeing what happens when you do this or that. It's the way I recommend when people ask how to make games. Problem is, once you start to get familiar with the game making tool you're using, and you start to get an idea of the type of game you want to make, it's time to step away from the computer and go back to basics.

And I do mean BASICS. Pen-and-paper is perhaps more important to game design than keyboard-and-mouse. The design process is a set of steps that are meant to maximise your efficiency through design. Basically, the design process means you know exactly what you're doing at each step of making your game and there's no time wasted to confusion.

The Design Process

The Design Process, also known as the Development Cycle, covers five basics stages. The Design Process is an old friend for any designer, and while the names of each stage might change depending on who you ask, their purposes remain the same. I prefer the cycle written as it is above because it better suits a learning environment and provides easily assessable outcomes. This cycle covers everything from start to finish in the game design process, or in any designed or creative endeavour. Keep in mind as we run through each stage that stages 1 and 2 are best done by pen and paper, and you shouldn't even look at a computer until stage 3.

Stage 1: Identify a Problem
Everything starts here, your problem - quite simply - is that you want to play a particular game but you don't have it. It doesn't exist yet, it's just a figment of your imagination.

Here you think about everything you want your game to be. Don't let anything hold you back at this stage, you can be as creative as you want. All too often I'll hear kids in this stage asking questions like "I want to make my character fly, swim, explode, etc. How do you make him do that in Kahootz/Kodu/etc?" I'll invariably tell them that at this point we don't even care about how we make our game work. We're just imagining the end product and writing down what we want it do to. We worry about the hard part of making it all work later in stage 3, otherwise we'd never get our game made because everything would seem too hard, or impossible to make.

At this stage we ask ourselves:
-Who is this game for? (Who is our audience?)
-What does our audience want our game to do? (What is the context?)
-What can I do that is fun and new?

Stage 2: Design a Solution
You've got a problem well thought out now. Let's start drawing! On a piece of paper, draw what your player will see on the computer screen. Draw up how some of your enemies will look, how some of your maps will look. Start writing down in dot points how your enemies act, points of interest in your maps or worlds, how your player interacts with the world.

This Design Stage is much to big to go into great detail at this point, but I will dedicate an entire blog to it in the near future. For the moment, a brief introduction to the entire process will suffice.

At this stage, we ask ourselves:
-How does my player interact with my game?
-What powerups or threats can change the way the player plays our game?
-How do I make my game suit my audience?

Stage 3: Build a Solution
We've made it past pen and paper. It's time to start actually making our game.

Of course, I can't tell you exactly how to make your game. Each one will be your own. However, I can give you advice. Start small and build outwards. This is called bottom-up programming. Divide your entire game into manageable portions. For example, you might want to focus first on getting the player to run and jump around your world. Then once that's done you can look at making the enemies run and jump around. Then, maybe we work out how to get the player to turn invisible, hang off ledges or fly around with parachutes.

Bottom-Up Programming (as opposed to Top-Down Programming) sees your game as blocks in a pyramid. Build the foundation first, the basics of your game, before working on the harder parts. Let your game come together from separate pieces rather than trying to make it all in one go.

Stage 4: Test and Refine the Solution
This stage, I would argue, is the most important stage of them all. If you've rushed through your game and haven't spent any time testing it you could have all sorts of bugs and glitches waiting to ruin the fun for your player. And if your game isn't fun for the player, it isn't a game at all.

You've got a working model of your game at this stage. So show it to your friends and family, watch them as they play around with it. Do they get confused or lost? Do they not know what to do sometimes? Of course everything seems perfectly obvious to you, but you made it. You have to take a step back and ask yourself why your testers are getting confused. Maybe you need to put in more instructions, or a hint or two. Maybe you need to use different colours and sizes to show stronger and weaker enemies of the same type, or maybe you need other visual or audio cues when the player is getting hurt, or when they're winning.

And don't forget to write down each time the game crashes, or does something it isn't supposed to do. This stage can take a long time. Every time you find a bug, you have to go back and fix it and then get your players to test it again and again. Just remind yourself, this is all making your game better.

Stage 5: Evaluate the Solution
The game is done. It's been tested, all the bugs have been ironed out, and the hard work has paid off. It's time to release your game to its intended audience. It's important to watch them play your game, get feedback from them, see what they like and didn't like. There's a reason that the Design Process cycles round back to stage 1. If your audience doesn't like a part of your game, or doesn't understand it we're back at stage 1 with another problem, and hopefully another solution to design.

Now that you've got an introduction to the design process. It's a powerful tool and it's something that all designers use. If there's any part of this blog you'd like more information on, or you'd like to suggest a topic for a future blog please feel free to drop me an email and I'll be happy to accommodate you.

Next we'll start to look at the types of games out there, and the games you'll commonly be making.

Stay tuned!

Anthony