Short introduction: I’ve been a Game Designer in various sized teams (from 3 to 30) since 2008 and everything written here I’ve experienced a lot.

A Game Designer has their hands full all the time. They have to create something cool, keep the player in the flow, trying to prevent boredom while fending off too much information. The Game Designer is the only person who is utterly and completely in charge of the game experience, so to make the impressions seamless and thorough they have to meet compromises and make sacrifices. In this article, I want to show you five working issues that Game Designers (well, me) experience like a nightmare in a B-movie.

1. Everything that can be invented has been invented

Here is a paradox: the videogame industry is more than 40 years old but still considered a dynamic and hi-tech trade. Every day hundreds of games release on platforms and if you suddenly become enlightened with a great idea, try searching the archives. Most likely, your thought has already been developed into a game – somewhere, sometime. And here’s another paradox: in the videogame industry your wildest fantasies are not worth a dime. So what is to be done?

The books tell us that stealing is wrong, but in terms of game development, NOT taking a good concept is quite difficult – or, rather, proving that it was your idea and not something you noticed on reference screenshots. As soon as the Game Designer stands up for a task, the first thing he has to think over is “where did they implement this thing already?” There is nothing to be ashamed of in such way of thinking: programmers use libraries that were written by someone else, so Game Designers have about a million games full of wisdom and experience.

By the way, that is why I think that sheer game experience is more important for Game Designer than a certificate of enrollment in using mockup software. Do not hesitate to search your memory vaults but note this: it is not as important to where and how you found your idea as it is to implement your findings.

2. Beauty vs Function

Let’s say you are developing a classy user interface with buttons. You have different screens of the same layout: there are four buttons, they are placed in the lower part, they are of the same size and they are equally important. Why do this? Because it’s stylish and your GUI specialist recommends you building the screen with the equally important buttons since you adopted unification. Everything went well for a significant number of screens until one day you realize that the next screen you are working only has two more functions. You can add another one that is of less importance in comparison to the other buttons, but that’s just lame.

This is a classic Game Designer conflict: you can either do something that is visually neat, but demolish the “unification” experience by adding unnecessary buttons, or dismiss the whole concept and place as much functions as you need for this screen.

Generally, the solution is somewhere in between. Sometimes you have to invent new screen types (“standard” with four buttons, “pop-up” with three, “confirmation” with two etc), sometimes you adjust buttons size to whatever current functionality requests.

There are no preemptive measures that could be taken. Planning a good game does not assume writing everything A to Z and questions of that kind will rise here and there. The process is iterative – it’s not a pictorial phrase, but a savior cross for Game Designer, a cross he has to bear.

3. Loose ends

The bigger the development team, the less chance that a Game Designer knows the project architecture good enough to speak with programmers on their language and write documentation not only for Game Designer’s intentions, but also for programmer’s capabilities. Even the most thorough design document will not be final – one moment programmer will come to designer and start asking questions.

By the way, take a note: if programmer reads documentation and does not come to clarify details after that he will code it “as is” and you will definitely get the feature done in the simplest way and most probably won’t be able to make any adjustments to it in future.

At the same time, a Game Designer has no point in doing an excessively detailed documentation. Some algorithms might become obsolete by the time that functionality finally gets the development opportunity. Some part of the documentation will be reworked upon at another team members’ request. Even the Game Designer himself might feel the urge to rewrite here and there. So the main point is – picture key algorithms first and the details – discussed and approved by every participant – will follow.

A reflection of this problem is the counter-offer. Seeing Game Designer’s efforts of creating not the algorithm by itself, but a definite user experience, the programmer can come up with his solution. But beware of Greeks bearing the gifts! Think it over; estimate its value for the Flow; get in your player’s shoes and make sure this solution does not break the balance and holds no barrier to future development. Part of this problem is that the programmer already threw the ball to Game Designer forcing him to make decision as soon as possible.

You can’t really foresee all these obstacles, both small and big. On one hand, you won’t be able to write the documentation to a dot (the process is iterative!), but on the other hand – you will never solve a question that crosses out the whole documentation in several minutes. Just be ready to compromise. Always.

4. Late for release

The clingiest nightmare of Game Designer is the urge to update and upgrade everything, including those that already work perfectly. From the very start, we are killing bores and perfectionists. In spite of endless hours spent on documentations, very important enlightenments (no kidding) strike us in the last moment. You can find whatever scientific explanation there is to explain why it comes from the shadow of your mind so untimely, but it doesn’t help – you’ve got to do something with it, and do it NOW.

A compromise here is to improve something that you can without distracting the programmers and artists. Alas, the less tools a Game Designer has, the less probability of completion this mission has. Besides, the great thought usually takes more than changing variables in balancing a formula or adding new entities to the database.

The development paradox is that a Game Designer can set a task of any complexity and longevity and project manager will add it to the schedule, but even if you allow for a change or two and come up with them later, you will hear many bad words and something like “you had to plan it ahead”. Well, it depends upon the team, of course, but be ready to inhibit your spontaneous desires at any time.

5. You are the only savior

Sometimes it happens otherwise: for financial, humanitarian or legal reasons you have to remake this feature right here, right now. No time to explain, get to your computer and think on how to convert platforming action with ponies to air simulator with the Great War planes. Deadline is yesterday. And consider yourself lucky if you’ll be able to retain winged pony to model physics of flight.

Jokes aside. Feature reworking starts with archiving of the original documentation without trying to reread or save a thing from it. It sounds harsh, but it really helps Game Designer to school his temper and become critical quotient to his work. This job is just about writing texts, filling table cells and drawing sketches. Also, we put our souls in it.

That is why reworking or cutting features should be considered a work from scratch. It helps not to think about saving favorite or hard-earned features that took some serious time to work on in the past. This is a philosophy of the same level that various couches and advisors use – “consider denials, failures and errors as new opportunities”. Do not fear – open a blank sheet and start working.

TL;DR

A Game Designer has a lot of challenges before him (especially sudden ones), but they all can be overcome if you are communicative, adequate, ready for compromise and you never give up.

About author: I’ve been a Game Designer in various teams of different size (from 3 to 30) since 2008 and everything written here I experienced a lot.

At this moment I am lead Game Designer at Creative Mobile, working on f2p drag racing MMO Nitro Nation.

I’ve been in the worldwide videogame industry for more than 15 years and I share unique and rare facts about it on my Twitter account Videogame Fact Daily @vgf365