5 Mistakes I’ve Made as a Game Designer

As a young designer working in a small startup, I’ve had the privilege of making many mistakes with not much harm done. Nobody really knew what responsibilities fell under the role of a game designer when we were just starting out.

Today I know that a huge part of a game designer’s job is to successfully communicate her vision to her peers and colleagues. We just want to be understood!

Hopefully this short list of mistakes and possible solutions will help you communicate better with your colleagues, peers, and players.

1. Long GDD (Game Design Document)

One of the first things I’ve done as a young game designer was to download a GDD template off the web. It was love at first sight. The template was exhaustive, inspiring, and, most importantly, reassuring. All I had to do was fill in the blanks. From that day on, my work was measurable. Every passing day my GDD grew bigger and for me it was the best indication of a good job done right.

The problem was, of course, that very few people read my GDD. Those who did read it went completely lost in a sea of words not necessarily related to their role.

Solutions

A game designer has to share her vision with many stakeholders coming from different backgrounds and disciplines. It makes no sense to squeeze this vision into a “one doc fits all” kind of spec. Therefore, different teams get different specs.

Management and marketing teams would get a storyboard that takes them on a player journey from the opening page through the onboarding process, up until the end of the first game loop.

I love using Google slides to rapidly mock up storyboards and game design ideas that everyone can understand and comment on.

The art team would get an extensive list that I call “design list.” Made in Google spreadsheet, all that art and UI need is listed, and their page is connected to the related page in the storyboard.

Developers would get a navigation flowchart (I use Lucidchart), a spreadsheet with all needed variables, and a Word doc made for developers. “Made for developers” means very strict, cut to the chase, numbered instructions.

This method of “lean documentation” helps me make sure that everyone is on board with my vision, as they don’t have to read a 90-page document which, although glorious, is sometimes inappropriate.

2. Investing too much time refining prototypes

This urge is a hard one to resist. What starts with some graphics being ripped off the internet to make your prototype look more alive ends with animation tweaks, sounds, and visual effects that have very little to do with the actual gameplay.

I used to embark on 3-week prototype journeys only to find out that what I was building was not working on a much higher level.

By the time of reckoning, I was already too much in love with my project, and letting go or pivoting was hard to do.

Solution

The thing that helped me most was setting a very hard deadline for myself.

No more than two or three days per prototype.

This forces me to focus on gameplay and not on everything else.

Although I admit that one out of three prototypes still go out of hand and I end up polishing them beyond proportion, it’s a part of the fun in making games. However, if that happens, I try hard not to fall over the next common mistake.

agario proves that a game can be successful despite of its graphics. So can your prototype.

3. Playtesting too late into production

Showing people a far-from-finished work and seeking feedback is a somewhat sadistic action. It is never fun to watch players struggle with your design ideas, and it is very hard to shut up and not shout, “Tap the screen!!” whenever your testers look baffled at a pop-up that doesn’t go away. (Because they have to tap it!!!!!!)

Like most unpleasant tasks, I tend to procrastinate playtesting as much as possible.

And by the time I show my game to people it’s already too late in production. Changes cost money and I agonize over every remark or sign of boredom.

Play testing with a paper prototype. A strong value for money approach to testing game mechanics!

Solution

Nowadays I try to get people involved as much as possible from the get-go.

I send colleagues the storyboard while still in presentation and send out very early builds to friends and potential gamers.

I carry a build of the game on my phone and force myself on innocent people, asking them to play my games.

Almost every piece of feedback is valuable.

I’m still working on how not to get too occupied by the feedback I get. If someone is coping well with that, let me know how you do it!

4. Not acting upon user’s feedback

Many times users do not play as expected when playtesting your game. I used to overlook negative feedback using two main excuses:

1. The game is not ready yet so my players do not fully understand it.
2. My playtesters are not familiar with my game’s genre/are not gamers.

As a result, the game would stay very much the same in each iteration. No real progress was made.

Solutions

First, I’d make sure to answer my two main excuses beforehand.

Even my very early prototypes have some kind of an onboarding, to make sure my playtesters understand the game without me telling them what to do.

I would also try to bring in players who are familiar with the game’s genre to get a more accurate feedback.

On top of that, I have a very simple rule. If three people or more pointed on a problematic feature, this issue have to be addressed and changed before the next playtest.

5. Being overly optimistic about development time

This always happens. After all, the prototype took us 5 days to complete, how much will it take for a full production? A couple of months maybe?

We are all optimistic by nature, even when past experiences show that no good production was ever made in two months. While evaluating, we tend to forget that game design is a dynamic thing. Ideas shift and change on a daily basis. Playtesting dictates iterations. Polish takes a whole lot of time.

After 2-3 months you find yourself with a 75% finished product, a full crew of people burning the midnight oil, and unsatisfied management/clients.

Solution

My rule for estimation is: Every day on a prototype equals a month of production.

7-day prototype =7-month production.

At the start of the project this projection seems too loose, mainly because the prototype is deceiving. It looks almost like a final product! But it is far from it. And you’ll have to explain that to whomever pays you to do the job.

My best way to communicate the gap between the prototype and the full-fledged product is always base rate. Ask around and read devlogs to learn how much time it took other teams that built similar products to release their game to the market. This is your time frame. Why? Because that’s the time needed to make games.

Summary

Communicating one’s ideas and the ability to listen are the two most important skills of a game designer. As you hone your craft, try to get better at those two traits. Try not to be over occupied though. The most amazing games started off as boring pieces of software.