Sponsored By

Game Design - Into The Unknown

People from outside of the video game industry often don’t know what Game Designers actually do. Even people from the industry don’t always have a clear picture. But the most interesting part is when Game Designers themselves don’t know...

Leszek Gorniak, Blogger

November 27, 2020

7 Min Read

“Nobody knows what will succeed.”

Jordan Mechner, creator of Prince of Persia


THE UNKNOWN

People from outside of the video game industry often don’t know what Game Designers actually do. Even people from the industry don’t always have a clear picture. But for me, the most interesting part is when Game Designers themselves don’t know precisely…

Compared to other game industry roles, like Programmers, Artists or Sound Designers, Game Designers much more often have to deal with The Unknown. There are no “Game Design standards” as, for example, Programming standards. There are no objective indicators of Game Design quality, as there are for, for example, 3D models. As I already wrote in my blog post about Team Design, we lack objective criteria in the field of Game Design.

(Small disclaimer: this lack-of-standards issue doesn’t necessarily apply to mobile F2P market, where Game Design is often dictated by numbers, i.e. Big Data analysis. I focus on my experience, which is primarily single player games for PC and consoles.)

The uncertainty and ambiguity in the Game Design field is clearly illustrated by the unquestionable success of Dark Souls series. From a rational design perspective, its core principles shouldn’t work: the learning curve is brutal, players lack explanation of many gameplay mechanics, there is no clear guidance system (minimap, markers etc.). Yet it became one of the most remarkable phenomenons in the history of video games.

Nowadays, theoretical principles and rules for Game Design are much better defined than they were when Jordan Mechner was working on Prince of Persia. But they’re still only theory. And way too often, when we try to put that theory into practice, we encounter numerous unknowns. Here are a few examples.

1. Interest Curve

What we know: a narrative structure of a game (especially a story-driven game) should be built in a way resembling the diagram above: starting with raising the player's interest, gradually increasing tension and resolving with a memorable climax.

What we don't know: what would effectively raise an initial interest? How should we pace the increasing tension exactly? Which story event would be most suitable for culmination? An epic battle sounds just right, but maybe it’s a bit of a cliché?


2. Flow

What we know: a game's difficulty should rise proportionally to the player's skill, so the player will never be bored nor overwhelmed, remaining in a state called “flow”.

What we don’t know: How to measure the player’s skills? Would the applied difficulty be sufficient? For whom? How to accurately assess the state of flow during playtests?


3. Randomness

What we know: most games have some random elements. Implementing randomness in a game might enhance replayability and add more surprises and fun. For example, random encounters can add more dynamics and/or tension to cRPGs.

What we don’t know: How often should random encounters occur? If a Boss enemy has some randomly selected special abilities, what should be the exact chance for each of them to be drawn? If a weapon deals random damage between 10 and 20 hit points, why is it not 15-25 hit points?

 

4. Timing

What we know: proper timing of the gameplay events creates the right pace and, ultimately, the desired experience. A small delay before a human NPC’s reaction can make them feel more… human. An appropriate delay after a cutscene fades out can facilitate suspense.

What we don’t know: 

Would 2 seconds delay before spawning monsters be OK? Or maybe 4 seconds is better? What should be an exact cooldown time before a Boss enemy can use his area attack again? If the player is stuck somewhere, how long should we wait before displaying a helper hint?

 

In Game Design there are many, many, many more questions like that. And not nearly as many answers. However, while we cannot eliminate The Unknown completely, we can still deal with it and reduce it.

 

HOW TO DEAL WITH THE UNKNOWN

1. Accept The Unknown

An ultimate prerequisite. To properly handle The Unknown we have to accept it and embrace it as a natural element of the Game Design process. We need to learn to say “I don’t know”, the words many people are so terrified to use, much more often.

2. Clarify your design goals

I already wrote about the importance of clear design goals in my blog post about Team Design (Method #1: Set a “design compass” ASAP), so I’ll just repeat this: with lack of clear design goals comes a dreadful lot of uncertainty and ambiguity. Especially when there are many designers in a team there is very little chance that the low-level (or even high-level) vision is shared by everyone - which ultimately leads to chaos. Try to clarify the below four aspect ASAP:

  • Theme - what is the game about?

  • Overall mood - what emotions should the game evoke?

  • References - what games/films/books would be inspiring?

  • Target audience - for whom the game is being created?

Then, keep clarifying more and more aspects as the project develops, thus further reducing uncertainty.

3. Apply restrictions

Contrary to what many people think, restrictions boost creativity (if you don’t believe it, google it). They also allow us to eliminate certain challenges upfront, which provides more space for other elements and reduces uncertainty and risk. You may apply as many restrictions as you like, as long as they support your project, e.g.:

  • no multiplayer

  • no boss fights

  • no dialogue choices

  • no music

  • no manual saves

Less is more.

4. Define problems

Defining a problem should always be a first step to solve it. A clear problem statement significantly reduces uncertainty and ambiguity. I’d even say that: problems are seldom hard to solve! But they will often be hard to define. 

The importance of the problem statement is clearly visible in the QA field. When I was working as a QA, the most important skill I had to acquire was defining problems (in that case: describing bugs, of which I write a little more about here). Without proper bug descriptions programmers are not able to effectively analyze them and fix them. The same goes for game design problems. Analyze problems carefully, always look for the root cause, and plan solutions accordingly.

5. Check what works in other games

A simple (and, sadly, often overused) approach to validate a design solution is comparing it to existing, successful games. A most simple example: if we observe that in First Person Shooters players prefer to shoot with Right Trigger when using a gamepad, why change it? 

Nowadays, this approach is so popular that we actually have many game genres that originated from certain productions, such as Metroidvania, Souls-like or Battle Royale. Similarly, we ought to study bad games, analyze their reception and see what might not work.

7. Prototype-Test-Iterate

In my opinion, the most important rule. During the game development process Game Designers lose perspective and become really poor judges of their own design. Therefore, we should playtest our prototype, Alpha and Beta builds as many times as possible. By playtest I mean letting people from outside of the production process play our game. This is where knowing our Target Audience, mentioned in point no. 2, comes in handy. Before we playtest, we really don’t know much about our game.

Remember the rule of thumb: when playtesters say something in our design is wrong, they’re almost always right. But when they say how to fix it, they’re usually wrong. : )

7. Be brave

The final advice: when stepping into The Unknown, be brave. 

Brave to express your opinion and defend your ideas, but also brave to admit you’re wrong. Brave to decide on your design direction and move from pre-production to production. And finally, when the time is right (spoiler: no one will tell you that the time is right), be brave to decide that your game is finished and can be presented to the world.

Be brave, designers! 

Thank you for reading.

Read more about:

Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like