A game designer and a programmer have a totally different approach to their work. While the designer comes up with a variety of ideas, it is the programmer who has to understand them thoroughly and translate them into code, which can ultimately mean changing the original idea. Problems usually arise on two levels: communication and scaling ideas. But let’s start from the beginning. 

Who, in fact, is a game designer?

Game design is a creative profession with no strict rules—only a general framework designers work within. We start from abstract concepts such as “cool,” “funny,” or “pleasant,” and we translate them into game rules, looking for a common language with the player to provide them with the holy grail of game design—FUN.

When someone not connected with gamedev asks me what I do at work, I often reply: “I make up the rules”—and I believe this is the simplest definition of my profession.

We game designers have a difficult task—firstly, we have to get to know the players and their behavior: what motivates them and what bores or discourages them. Here, analytics and trusted Excel come to the rescue. Yes! You read that right. So if you imagined yourself sitting comfortably in your armchair and coming up with new titles, I have to disappoint you. Part of a designer’s job is analyzing data in Excel or other programs made for this purpose!

Additionally, a game designer needs to navigate data efficiently and know where else to look for answers: how do players think or how to create the perfect experience for them? You have to have knowledge of psychology, pop culture, and much stranger and surprising areas, such as interior design or fishing. It is all this information that the game designer has to process to design the best version of the game. And it’s important to remember that we do not create the game for ourselves, but for our users! Everyone has different needs and a different idea of FUN.

Of course, that’s just one side of the coin. Apart from the previously discussed issues that we meet in the creative process, we also need to ensure proper communication within the team and with each professional group that is supposed to put our ideas into practice. One of these groups, extremely different from us, are developers. Apart from the difference in thinking, we usually encounter a barrier resulting from not knowing the rules of programming and its limitations. There are also many other differences—and we’ll try to cover them here. 

How does a developer create?

Developers always strive to make their code transparent, scalable, and flexible. This is most easily achieved when the code is “abstract,” i.e., it does not implement any specific version of the functionality literally, but only allows you to choose what exactly is going to happen. This usually means creating a configuration file where the designer can choose what is supposed to happen in the game. A simple example of such an approach can be a tournament where players compete against each other by collecting elements in a match-3 module. The designer’s original idea was for players to collect red chips. From the programmer’s point of view, however, this would look like players can collect any element. The designer, in the included configuration file, will determine whether they should be red, yellow, or blue chips—or maybe rockets or perhaps something else. The code should support all these possible options.

Is it possible to reach an understanding?

It’s not an easy task, but no one ever said that everything in life comes easy. You need to remember one thing—everyone on the team strives to make the best game in the world. This is clear as day: our ultimate goal is to create a perfect product—a game most enjoyed by millions of players. Unfortunately, this doesn’t mean that our intermediate goals are the same. 

Game designers want to create perfect game rules so that the gameplay is as best as it can be and well-suited to its theme. If we assume that “dynamics” are one of the key features of the game, everything that will be created should support this assumption from the designer’s perspective. We’ve mentioned before that we need to speak a common language with the players. This will be sought on many levels, such as mechanics, the visual aspect of the game, or animations. 

On the other hand, developers strive to optimize the game, with as few errors as possible. They want their code to be scalable, simple, and flexible. 

Ultimately, we all remember that we share the same goal, so to work together, we need to understand what motivates us and find a common language. This is where tools such as language, GDD documentation, and user stories come in handy.

Terminology and language

When presenting their ideas, designers sometimes use general or vague terms, often inconsistently, and define behaviors imprecisely. However, programmers need specifics, as it is challenging to start working on a functionality without them. If a new idea is confusing and complex, we recommend creating a flow diagram or a simple mock-up. These tools illustrate how the game should work and how it relates to existing systems.

Documentation

The principal tool designers use to communicate their visions is documentation. You can read about various forms of GDD (game design document) online, and based on my experience, I can discuss a few of them.

GDD in Google Docs

I have nothing against the Google Docs tool itself, but the lack of limitations and the free form often encourage people to write way too much. Let’s face it—some designers are great story-tellers, and they could create extensive scenarios for Dungeon & Dragons. It’s their creativity and ability to see the whole picture that helps them create excellent games, but working with programmers requires completely different skills. So what makes documentation good? 

Documentation that is easy to read and understandable should be:

–       Concise

–       Specific

–       Visual

Concise—the keyword! I remember how, at the very beginning, we tried to describe everything in as much detail as possible. We added mock-ups, diagrams, and extensive descriptions of various extreme cases. Unfortunately, this resulted in illustrated stories that were over 30 pages long. When programmers sat down to read such a document, and even “forced themselves” to read our little “story,” it took them over an hour. And after they finished reading it, there was no guarantee that they would know what to do. Translating our prose into their language and prioritizing individual tasks took even more time. It wasn’t easy, so we tried another approach.

User Stories

User Stories are a standard in the IT industry. If you ask Google about “user story,” you’ll find a straightforward definition. “User story is an informal, natural language description of one or more features of a software system.”

It comes down to the fact that designers start working on the specification with a key question: What does the player want?

As a player, I want to compete in the tournament to win prizes.

This one sentence allows us to precisely define the player’s need. If some design element does not support this or is not crucial to achieving this goal—we can easily scrap it. The next step is the creation of visual diagrams similar to flow diagrams but mainly based on mock-ups. With this tool, we show which “lucky path” the player can follow. We try not to dwell on so-called edge cases. It is crucial to focus on what is most important. A concise form often forces us—designers—to be more meticulous and get straight to the point. 

At the same time, appropriate tasks for the team are also created and prioritized. Here you can use a specific task management tool, such as Jira. It allows for the easy organization of teamwork from the very beginning. An additional advantage is a fact that everything is divided into the right tasks. It enables implementing changes and so-called iterations (and we don’t need to edit our story anymore, yay!). 

The art of compromise — or how not to kill each other

A new idea is always verified in a brainstorming session within the entire team. Apart from gathering suggestions a timeline is usually also prepared: the programmers say how much time it will take to implement each part of a given functionality. If any of them turns out to be too time-consuming, they may suggest a simplification or if it’s insignificant – removal. The designer may reject such a suggestion if they believe that such a part may be crucial because it communicates some vital message to the player or provides other value. This approach illustrates the differences in priorities on both sides because what is vital for a designer may seem redundant to programmers. It is therefore necessary to work out a compromise together—for example, to postpone some complex elements into another iteration.

Role reversal — the Game Designer is not the only one writing documentation

It often happens that tools for designers make it easier to create or configure a game element. If they are complicated and not particularly user-friendly, writing documentation is a good idea for them. As a programmer, I’ve realized that my documents were too technical and included concepts that were obvious to me but unfamiliar to the designers. Therefore, when writing documentation, you should avoid technical jargon and write as clearly and concisely as possible. This way, a game designer cooperating with us will not be forced to google some unknown technical terms all the time. 

Stability versus constant change — how to work together

Designers’ work is very flexible and involves constant changes. They are not afraid of crazy ideas—after all, they are not the ones who implement them into the game 😉 Programmers prefer more structured tasks because changes can often be very troublesome for them.  Modifying the code (or even worse, rewriting it) is extremely time-consuming and frustrating. It indicates a communication problem or implementation error and results in a massive waste of time. That’s why it is necessary to show the designer the results of the work regularly. It helps catch flaws in the concept or implementation as soon as possible. A great tool supporting this process is planned prototypes, i.e., basic versions of functionalities. They are subject to constant evaluation and, most importantly, you can prepare them quickly, so changing or rewriting them is overly painful for the programmer.

To sum up, the most important thing is to decide on the right form of communication—to satisfy both parties and take the nature of their work into account. The designer will talk to graphic designers, testers, and programmers quite differently. The latter are usually the most demanding.

As designers, we should respect other people’s time—provide the team with specific details and be prepared to present our idea visually. A quick prototype to verify the idea in the beginning can save time for both the team and the project. And remember: in game design, time is equally valuable in the production phase as in the following stages of the product (the game) life cycle. 

At the end of the day, it’s worth making compromises. Be aware that compromises are when each side sacrifices something for the other. Is it not possible to make beautiful animations for all the functionalities at once? So let’s just decide on the key ones. This way, we’ll avoid an eternal conflict, and the atmosphere in our team will be more friendly. We need to understand that if the programmers decide not to implement all the designers’ ideas, it’s not because they want to give them a hard time. And the two main factors that can limit the ideas are time and technical constraints.

Sometimes, it’s worth walking a mile in each other’s shoes. Programmers don’t always want to brainstorm; sometimes, they prefer to focus on writing code. Designers are usually not programming experts, but they will often learn from you, the programmers. If you share your knowledge in the right way, they will soon find their way around the maze of technical issues. Such an approach will allow them to write even better specifications in the future. And a proper specification is half the battle of communication between designers and programmers! 

Eliza Chyży & Michał Szynal