Home   >   Features

So... You Want to Make Video Games? Part 2: Design

Got your new game concept down? Now it's time to start designing
So... You Want to Make Video Games? Part 2: Design

Previously, author and game designer Nick Pendriis walked us down the tricky path of dealing with new game ideas, as we bring you a serialisation of his book, So... You Want to Make Video Games?

That was phase one of Pendriis's process, which today brings us to phase two - design.

In this chapter he gives us a case study (being Space Invaders) that illustrated how to take your ideas and turn them into something a computer can actually deal with.

We've a few more chapters to bring you yet, as we work our way through the multi-step program and take your from newcomer to working game maker.

  1. CONCEPT: Find a strong idea.
  2. DESIGN: Make test versions and create a blueprint.
  3. PLAN: Organise the project carefully.
  4. BUILD: Create the computer code.
  5. ASSETS: Create visuals, audio and words.
  6. TEST. FIX & PUBLISH: Look for problems, resolve them, release the game to the public.
  7. PROMOTE and SUPPORT: Announce the game and respond to feedback.

Here's Nick Pendriis to tell you more.

Our ideas mean nothing to computers. Computers know exactly two things: on and off. That's it. They are simple boxes full of tiny on-off switches. No feelings. No emotions. No conscious thought. Computers just follow instructions, precisely. They use cold, clear logic.

So if we want a computer to do something, we need to give it clear, logical instructions. This can take a little while to master but learning to think logically is the most fundamental skill in software design. It really doesn’t matter how creative you are – without clear logic, your project will fail.

"Fail fast. Test cheaply. Your instincts are probably right 95% of the time and your ideas 25%, so fall in love with instincts and kill ideas."

 - Mark Pincus, Zynga co-founder.

#1: Mechanisms and game logic

So the first thing to know about game design, is what games are actually made of. You might think they’re made from program code but that’s not it. There were games long before computers were invented. They were made from sets of logical rules. Game logic.

Between the 1930s and the 1960s, arcade games were entirely mechanical. Then electro-mechanical games appeared, such as Sega’s Periscope and Moto Champ, or Taito’s Crown Soccer Special. These games used physical switches to create game logic. In the seventies and eighties, video games pretty much took over.

In a video game, the mechanisms are electronic, with switches and systems made from software code. We’ll get to the specifics of code later. First, we need to take a closer look at game logic because that’s what game design is really all about.

Every game has a system at its heart. This is true for card games, dice, dominoes and board games, right through to whichever smartphone app is currently topping the charts. Each one needed careful system design.

Before translating anything into computer language, we need to know exactly what we’re going to say. What, precisely, does the game do?

To answer this, try breaking your game idea down into four key parts like this:

  1. Components: What are the pieces that make up the game?
  2. Rules: How exactly is it played?
  3. Win scenario: How do players succeed?
  4. Lose scenario: How do players fail?

#2: Case study: Space Invaders

I’ll give you an example from back in the day. Let’s head into an amusement arcade somewhere at the tail end of the 1970s, which smells of cigarettes and male body odour. It’s unpleasant, I freely admit, but that’s just the way things were. Anyway, if you peer through the eye-watering haze, you’ll notice a Japanese game cabinet that’s going to change the world.

Space Invaders was not the first ever video game. It was, however, the machine that truly brought games into the mainstream.

Here's the official Space Invaders homepage, and this article makes really interesting reading.

The original Space Invaders cabinet had a “monochrome raster” screen, which means it had a black and white display. Thin strips of coloured plastic were stuck to the glass to create the illusion of coloured graphics.

At the time, Space Invaders was a revolutionary game but by today’s standards it’s pretty simplistic, therefore it makes an ideal case study. The game mechanism breaks down as follows:

1. Components: Space Invaders contains the following elements:

  • Player (cannon).
  • Multiple enemies (invaders).
  • Destructible shields.
  • Missiles.
  • Lives.
  • Score.
  • High score.

2. Rules: The basic structure of play:

    • Player controls a moveable cannon.
    • Player begins with 3 lives.
    • Player can move cannon left and right (stopping at screen edges).
    • Player can fire one missile at a time.
    • Enemy space ships advance steadily (across and down the screen).
    • Enemies fire randomly.
    • Enemies kill player on contact.
    • Enemy mother ship appears randomly for bonus points.
    • Shields block missiles but deteriorate with each hit.
    • Missiles move in a straight vertical line.
    • Player missiles kill enemies, increasing score.
    • Enemy missiles remove one player life.

3. Win scenario: Conditions for beating the game:

  • Game is wave based and continuous. There is no “win” per se, only achieving a better high score.

4. Lose scenario: Conditions for failure:

  • Player has zero lives.
  • Player or player’s parents run out of coins.

We can pare any game down to these essential ingredients and it’s a vital part of the design process.

So at this point we have a high-level concept and a simple set of rules but they could be much easier to read. It would be really useful if we had a way to display our game in logical steps. Like a method for drawing diagrams maybe.

#3: Flow charts

As far back as 1920, flow charts were used to show plans for movement. In those days, they were plans for moving goods and people. For example, a shipping company would use flow charts to plan their business operations.

These days, flow charts are commonly used for planning electrical circuits and movement of data. A game is like both of these things, containing logic and data, so flow charts are ideal for working out game logic.

Traditional flow charts are very technical and precise. They have a language of symbols and shapes, each with a defined meaning. My flow diagrams, on the other hand, are much more fluid and flexible. OK, they’re much more primitive. However, they’ll show you the basics of mapping out your game flow and you really won’t need to study anything. This is all about keeping things simple!

Blocking it out

All we do is break the game down into obvious pieces, blocking out the overall shape of the game first and then going back later to add detail. Flow of play diagrams usually follow the same general pattern.

Of course a flow diagram should contain a little more information than this. Let’s take a look at the basic flow of play in Space Invaders.

That gives a good general view of the game. It can then be broken down in more and more detail, in further diagrams, until there is a really clear template for exactly how the game will work. Having this is crucial, as later, when we come to programming the game, the code will follow this flow diagram very closely.


#4: Prototyping

Once you’ve planned your game out and everything seems logical, it’s time to make some test versions, or “prototypes”.

Play it on paper

The easiest and most obvious way to test a game, is to play it through on paper or using models. If you are making a board game for tablets, start by making it out of real things, like paper, dice and coins. Card game? Make it from paper or playing cards first. A lot of games were designed this way!

Use whatever you have available to test how the game will behave. Once you can feel the game, not just imagine it, you’ll know if the idea is likely to work. It’s much cheaper and easier to play with bits of paper than to program the same experience.

Play it in ASCII

Typically though, the next step is to make crude prototypes on a computer. These are programs that test out different aspects of a game idea, like playable sketches.

Developers of the game Skate (published by Electronic Arts) tested their idea without any graphics. They had fun playing with just numbers on the screen (weird), so they knew it would work with all the bells and whistles.

This is pretty extreme but testing your idea in some way is absolutely necessary. Of course, for your first ever game, you may not know anything about programming.

It’s ok, I’ll cover that in a later section. For now, just knowing the correct steps is enough.

"The advice I'd give to my younger self would be to play more games! And also: Get good at prototyping. Ideas or games don't need to be finished before you unveil them. You learn a huge amount more by getting your creations in front of people super early rather than waiting until something is perfect."

- Michael Acton Smith OBE, CEO at Mind Candy.

#5: 'I can just get someone to program for me.'

An awful lot of people have ideas for “amazing” games but have no idea how to make them. They think someone will magically appear and really want to spend time and effort creating their game. Sadly, it doesn’t work that way in the real world. You can’t simply expect others to make your dreams for you. They have their own dreams to build!

(Unless you have a serious amount of money to spend. Then you can hire a programmer. Although you should still have first-hand experience of programming or you’ll waste a lot of cash!)

Even if you’re planning to be a designer or an artist and not a programmer, learning the fundamentals of coding is essential. You’ll be able to communicate better with programmers and being able to test your own ideas is a massive advantage. Moreover, showing a prototype to someone is the best way to prove that your idea works.

Enjoy making it. Enjoy playing it.

Basically, if you ever want to see your games and play them, you need to program. Don’t worry, it’s very rewarding and can be a lot of fun!

Revise and refine

After playing with your game in prototype form, you may find it doesn’t work as you expected. Or at all.

“I have not failed. I’ve just found 10,000 ways that won’t work.”

- Thomas Edison, prolific inventor.

If your idea isn’t what you hoped for, go back and try again. Keep tweaking it until everything seems right, or even scrap it and try something else. Being able to let go of an idea is hard but you’re just trading it for a better one.

Tweaking 101:
Make it better or leave it alone.

"Say ‘no’ when you feel it’s ‘no’. You tend to love the product/service you're involved with more than anything else in the world, like your own kids -- sometimes that makes you feel hesitant to give negative feedback and that can lead to tragedy!"

- Toshio Murouchi, Senior Director, Community & Service Division at Square Enix.

#6: Game ingredients check list

Always remember that you’re making an experience for people. Design everything for that single purpose.

Here are some important things to consider:


Some games just seem to be magnetic. The idea screams “play me” and it looks exciting right from the name. Fresh ideas or completely new takes on existing ideas are especially attractive.

Immersive-ness and engagement:

Give the player reasons to feel pulled into your world and story. Create an emotional response. Give them fun things to do.

Intuitive to play:

Do players automatically understand what to do and how to do it? If not, why not?

Style and individuality:

Give the game its own look and feel. Define that style clearly and stick to it throughout.

Internal cohesion and logic:

Be sure that both your game world and its internal logic make sense. Even fantasy worlds need rules and laws of physics. Define the rules, make them obvious to players and stick to them.

Stickiness and retention:

Give players a reason to come back and keep playing. The “Just one more go” effect.


If it’s not fun, it’s not a game. Keep making sure you don’t lose the fun when you’re tweaking the design or creating challenges for players. Get fresh people to play it during development, because when you’ve spent months making something, you can lose perspective.

Eventually, all the testing and tweaking result in a solid-looking game idea. The prototypes are fun. The revised flow charts are clear and logical. What next?

#7: Design document

Before building a house or an office block, it’s necessary to draw up a design diagram, or blueprint. Starting with a clear and detailed guide is incredibly important because it helps to avoid costly mistakes later on. It’s exactly the same with games.

The blueprint for a game is called the “design document” and it guides every aspect of the development process. It might be a few pages of scribbled handwriting for one person to follow. It might be a massive encyclopaedia for a team of hundreds. Whichever is the case, the game design document holds every important fact about the game and acts as a map for the project.

Above is a small part of the design document for a board game prototype, showing step-by-step explanations, diagrams and tables. Written in Microsoft Word, the table of contents contains three pages of links for quick and clear navigation to the relevant sections. This is just a simple game. The design documents for blockbuster games can have many hundreds of pages.

Generally, design documents are evolving creations, starting as an “educated best guess” and getting more detailed over time, acting as the official repository for game information. It is quite normal to revise the document regularly.

At this point a producer or project manager will ensure that everyone works from the latest documents, so the project team is literally reading from the same page. It’s important that changes are logged and everyone is alerted when updates occur. For this reason, electronic design documents are far more common than printed ones. Some teams even use a wiki-style website or software to keep the game design document organised.


Game developers create an experience and players are the audience that participates in that experience. Beyond all the rules, the mechanics and the set dressing (characters, locations, style), a game is an experience that allows players to immerse themselves in another world. The developers introduce the player to their world and then guide them through the adventure.

User experience is the journey, user interface is the vehicle.

One of the hardest aspects of game design is balancing so many different factors. A game must have the right blend of careful hand-holding, player freedom, engaging challenges and satisfying rewards. This is crucial to a good game – and the only way to understand these ingredients is to play a lot of games and learn from them. No amount of technical knowledge can make up for having finely tuned instincts. This is something that only comes with time and practice.

Storyboards and pre-vis

Part of designing any experience is to think it through step-by-step and sketch things out. How will the game look and feel to the players at any given point? In many ways the process is like plotting out a movie and luckily we can borrow a technique from film directors called “storyboarding”. Creating a storyboard helps to break the experience down blow by blow. A storyboard is essentially the comic of your game.

Storyboarding software

Designer myths

The most common misconception I hear is “Oh, you make games? Does that mean you play games all day?” to which the answer is “If everyone in the games industry played games all day, there would be no more games.”

The second most common misconception is really a whole bunch of them, surrounding the subject of game designers and what they actually do. Few people seem to know and a lot of aspiring designers have completely the wrong idea.

This situation is dangerous, as it has given game designers an almost mythical aura which obscures the facts. So let’s establish those facts and remove the misconceptions for good.

#8: The game development hierarchy

Clearly, every development team is unique and everyone involved will have lots of opinions about what should or should not be in the game. However, opinions and ideas don’t run the show. While every company or team structure is different, there is always a chain of command. Having a hierarchy is necessary, as I’ll explain.


At the top sit the management. It’s always best if someone actually calls the shots. Usually it’s those investing money or those with legal responsibility for the company. The ones that have the most responsibility are generally the people who steer the process.

Regardless of the way a team or company is set up, a system absolutely must be put in place in order to settle any disputes. There will always be disputes but they should be resolved quickly and cleanly, in favour of a common goal.

Disputes and unresolved issues will damage the project if they are allowed to linger. Having management to make executive decisions is vital. They make those decisions for various practical reasons, taking a broader business strategy into consideration, beyond the goals of the project, department or any individual.

The director

Next in terms of authority, comes the director. Just like movies, the director is the one who carries the vision and has the role of ringmaster in the development circus. Ultimately, what the director says is what happens although the director must answer to the management.

The producer

We move on down the line to the producer. In the movie industry, there are many kinds of producer, so it’s important to note that video game producers are not the same thing.
The producer at a game company is a project manager, keeping the team on track. Producers usually have qualifications in scheduling and both team and project management. They coordinate the various aspects of the project and liaise with everyone, within the team and outside.

Department heads

From this point on, the power to influence the game disseminates amongst the different disciplines. There is usually a lead artist, a lead programmer, lead tester, etc. These guys are in charge of their respective teams and their respective areas of the game. All are of equal importance.


Which leaves the designers and there are many kinds:

Lead designer.

  • Game designer
  • User Interface designer
  • Character designer
  • Level designer
  • Monetisation designer
  • Sound designer
  • Puzzle designer

Each has a different task and not one of them is entirely responsible for the overall project. The designers have their parts to play, just like everyone else. For the game designer, one important part is the role of book keeper.

Custodian of the magic book

A game system is like a clockwork machine, with many intricate, technical pieces all clicking around each other in unison. Implementing the technical elements of the director’s vision and keeping a record of design decisions is a demanding job. That’s what a general-purpose game designer does.

If everyone can change the game design, or if everyone keeps their own notes, the project quickly turns to mush. So a game designer’s first job is to maintain the central design document, implementing requested elements while making sure the game’s logic system doesn’t get broken.

In Japan, game designers are more commonly known as “software planners”. This term is both modest and accurate. Designers must combine an artistic or inventive flair with far more practical skills, such as logical organisation, clear communication and detailed planning.


And for extra points:

In the next phase, we’ll look at incorporating the game design into a production plan.