In the first part of this series of publications devoted to training game and level designers, I discussed the importance of soft skills, essential complements to know-how. I presented two skills that are essential to me. In this second part, I present two others to you.
.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
In the first part of this series of publications devoted to training game and level designers, I discussed the importance of soft skills, essential complements to know-how. I presented two skills that are essential to me. In this second part, I present two others to you.
In theory, the game designer or creative director is responsible for designing the game mechanics. He or she is supposed to propose to them and develop the design documents. The rest of the team must develop the game based on these documents.
In an ideal world, things seem simple: The game designer, like Father Moses on his mountain, “dictates” the design, and the team carefully executes it.
But in the real life of a game designer, it doesn’t happen like that. He or she must constantly defend his or her proposals; these can be misunderstood or questioned at any time, including months after being presented to the team!
For what? The causes can be multiple.
As shocking as it sounds, the truth is that only some on a team read design documents correctly or pay attention during presentations. The consequences can then be multiple: A mechanism can be poorly implemented, a design error “goes under the radar” when it could have been corrected immediately, team members can develop assets on their own, or features can be incompatible with the design team's intentions.
A final cause is the arrival of new members in the team during its development. Indeed, it will take a lot of time for them to familiarize themselves in depth with the project. Some have preconceived ideas or want to remake the game according to their tastes! It’s even worse when the newcomer is an executive, a project manager, for example, because they have significant decision-making powers. Re-explaining the game to them is not always enough.
To prevent these unwanted situations, here are some best practices.
Introduce a new mechanism to the team orally, not by sending them a document and asking them to read it.
If you simply send the description of a new mechanism through a written document, some people will postpone reading it until later; others will only understand some things or even read it! On the other hand, an oral presentation will be much more effective because you may be asked for explanations.
Introduce a new game mechanic to the team in a simple way.
If you present all the mechanism details, you will “drown” your interlocutors, and they risk not retaining the essentials. And if they do not understand your mechanism, they will not adhere to it. So, keep it simple!
Use as many diagrams as possible.
A drawing is always more effective than a text. Explaining your new mechanism with diagrams will take more preparation time, but it will be worth it.
Justify your design choices using facts.
Your game design title doesn't guarantee that the rest of the team will trust your choices with their eyes closed. To support your point of view, support it with examples from games that are benchmarks in their field.
Don’t hesitate to spell out the basics.
Many design choices are based on knowledge that only some share. For example, only some know that very long-term retention is one of the success factors of a free-to-play game. If you use such a mechanic for your game but people need to be aware of its importance, they may find your mechanic unnecessarily complex.
Prepare and maintain a document describing high-level design choices.
This document will be used when new members join the team.
Like my previous publication, I will illustrate the importance of mastering this skill by describing a situation I witnessed or experienced. Of course, the names are fictitious to preserve the anonymity of each person.
Terry is the sole game designer in a large team working on an action-adventure game. As the game experience focuses on narrative and level design, Terry is also in charge of writing the level design of each room.
Terry writes very detailed documents for each room, describing their content and all the actions that will occur there. But that's not all: Due to the storyline, most rooms will be visited several times by players, and each time, the room's contents change. As a result, Terry must write complex design documents that describe each room at different stages.
This represents immense work, indeed too much for one person. Terry, therefore, simply sends his level design documents to the new lead level designer who has just joined the team. After all, if he has the slightest question, she is convinced he will return to her!
But, the lead designer needs to gain experience. He misunderstands the documents sent to him and does not ask for explanations, either for fear of appearing incapable or for lack of professionalism.
After many weeks, the lead level designer complained to the new project manager that Terry's level design documents were unusable. The new project manager, too, is a newcomer; he was recruited to reorganize production, which was falling dangerously behind schedule. The young project manager, knowing little about the team and the project, looks no further; he withdraws his trust from Terry, who saw nothing coming.
Caring? But what does this have to do with professional success?
In short, professional success is often associated with “human” success, with the ability to create solid and authentic bonds with colleagues.
Why is this so important? After all, skills should come first. Much of the reason for this importance concerns the game development process.
Game development is never “a long, quiet river”; instead, it is the tumultuous descent of a mountain river. Indeed, development rarely goes as planned: Dissensions within the team, technical or design problems, poor communication, delays, work overload, fatigue linked to the length of development, lack of experience, etc.
In addition, a team is often made up of passionate people who invest heavily. If they have an oversized ego, they make development a personal matter.
All of this can generate a lot of tension and sometimes (often) lead to conflict.
In this context, the quality of your relationships with the rest of the team is essential.
If you have managed to create friendly ties with your teammates, if they know that you are honest, if they want to work with you, in short, if they have understood that you are a caring person towards them, the problems and misunderstandings will be much easier to overcome. Above all, they will not degenerate into an open crisis.
Treat everyone with the same respect regardless of their role on the team.
Take the time to greet everyone and chat with them regularly.
Make the effort to listen to what others tell you. It may not be relevant to you, but it is to them.
Be open to criticism and comments from others, and show that you take them into account.
Don't say bad things about one of your colleagues... even if it's deserved! Assume that everything you say is likely to be repeated.
Do not try to defend yourself by accusing others; they will remember it.
Sanjeev was one of two game designers on a team working on an RPG. When he joined the project, the team management was impressed by his performance: Sanjeev demonstrated good knowledge of games and excellent analytical skills. He was also very reliable, delivering on time and following instructions precisely. He was good at what he did…maybe too good.
The team members began to feel uncomfortable around him. Every day, upon entering the studio, Sanjeev would barely greet anyone crossing his path and head straight to his office. He didn't take the time to chat informally or say hello. He seemed distant.
During meetings, team members felt uncomfortable when Sanjeev was present: He rarely spoke, and when he did speak, he gave the impression that he was the only competent person in the room! And at the slightest comment on the results of the playtests relating to his design, he always found an argument to discredit the latter.
Team members started to run away from him.
Conversely, the other game designer was warmer with the team and demonstrated a great sense of listening. He defended his points of view and was frank, but the team felt he was constructive. The team members turned to him spontaneously.
When the project was redesigned, the other game designer was responsible for redefining the gameplay. Sanjeev was sidelined, not for lack of know-how but solely because of his attitude; for the team, he was an unsympathetic, contemptuous person who seemed little involved in the project.
In the next part of this publication, I will discuss an aspect of game designer work that is often overlooked: the role of design in marketing and communication.
Pascal Luban
Game designer & creative director, freelance
28+ years of experience serving game developers and publishers
You May Also Like
