Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
To fully integrate into a team and thrive, a game designer must develop soft skills and new skills that are not systematically offered in school training. This publication series aims to better prepare future game designers for their missions. I draw on my experience as a game designer, lead designer, and trainer.
Many schools offer quality training in game design, but being trained in game design is not enough to become a game designer.
To fully integrate into a team and thrive, a game designer must develop soft skills and new skills that are not systematically offered in school training.
This publication series aims to better prepare future game designers for their missions. I draw on my experience as a game designer, lead designer, and trainer.
If there is one aspect that differentiates veterans from novices, it is mastery of soft skills. What is it about?
Soft skills correspond to an individual's personal qualities and behaviors within a team. Called soft skills in English, they become more and more important when recruiting a future member of a development team.
You will easily find generalities on essential skills in the studio, such as being a team player, respecting requests to the letter, or being very demanding regarding your own work. But today, I would like to share with you other very concrete soft skills that are the fruit of my 28 years of experience as a game designer.
Just because you have written a design document does not mean it will be developed to the letter. The reasons may be multiple: The programmer or artist may misunderstand your design intentions and not ask you for an explanation, a technical requirement may prevent its implementation exactly as you envisioned, your design document may be missing of clarity, or quite simply, not to be read! I have personally experienced all of these situations.
In such circumstances, your most conscientious colleagues will ask you questions or seek instructions, but not all will do so. It is, therefore, your responsibility to ensure that your design is correctly understood and implemented. Never forget that you will be blamed if the gameplay is mediocre, not the team members who put it in place, even if they did not respect your specifications!
To avoid this type of problem, the best practices are as follows:
Write design documents that are as precise as possible AND easy to read
Don't develop a huge design document; no one will read it. Instead, write several design documents, each focused on a game experience, and implement them one after the other.
Don’t just send your design documents to the appropriate team members; present the main lines of your design to them orally and with diagrams.
Check that the functionality developed corresponds to what you have defined
Spend a lot of time testing, testing, and testing the game again.
To illustrate my point, I will share situations I have witnessed or experienced with you. Of course, the names are fictitious to preserve each person's anonymity.
Luigi is a game designer for an action-adventure game in which the main character is accompanied by a teammate. He designs the mechanics that manage the teammate's behavior, the places he goes, the attitude he adopts, and the actions he takes. This mechanic is based on the positioning of waypoints by the level design team.
Luigi simply wrote a detailed design document and trusted the rest of the team to correctly implement his design.
But the artistic team goes after the level designer and modifies the map's topology: Certain passage points are found under the ground or hidden by added decorative elements.
As a result, the functionality works poorly, and the gameplay seems inconsistent. Luigi doesn't realize what happened because he doesn't spend enough time testing the new content. Poorly highlighted, the functionality is ultimately abandoned.
If a meeting is well organized, it has an agenda and a list of topics to be discussed. If you are invited to a meeting, it is because your contribution is considered valuable. Your ideas and opinions are, therefore, expected.
If, during the meeting, a subject is put on the table and you have not had time to think about it beforehand, your contribution will be superficial or even counterproductive. You risk coming across as someone who “counts for nothing”, a simple performer who brings no added value. And if you improvise a response to show presence, you risk saying something without any point, something which will ultimately tarnish your image.
If you are invited to a meeting, here are the best practices to follow:
Read the meeting agenda carefully. If there is none, ask the meeting organizer to specify the topics that will be covered; you will then be able to prepare yourself and give yourself the image of a good professional.
Take some time to think about the themes that will be covered, and that fall within your expertise. The simple fact of thinking with a clear head will allow you to make more relevant proposals but, above all to construct an argument to defend them.
Here is a new illustration of what to do...and not to do:
John is invited to a meeting organized by the project's creative director. Other game designers will also be present. The agenda specifies that we will discuss a feature in the game that is not satisfactory: cooperative action between two players from the same side.
When the creative director puts the subject on the table and asks the game designers present for their opinion, John, who has not really thought about the problem, is uncomfortable and settles for a very general proposal. But Emma, the other game designer, makes another proposal and illustrates it with a diagram. A drawing is much more understandable than a speech, and she reinforces her proposition by citing games that use the solution she proposes.
John weakened his position on the team, while Emma emerged as making a better contribution to the project. His solution is chosen not because it is better but because it is presented in a more convincing manner.
A game designer is always attached to his work to his ideas. It's normal. But a game mechanic remains a mere figment; we can never be sure of its interest until it has been developed and integrated into the game. In other words, an idea may seem very good on paper but may turn out to be disappointing once implemented.
This situation is common.
Indeed, the quality of the player's experience results from the interaction between many aspects of the game: its mechanics, settings, rhythm, the player's objectives, complexity, etc. A mechanic can effectively contribute to a quality experience in one game but be detrimental in another.
Therefore, a game designer must demonstrate modesty and develop a spirit of self-criticism. He must objectively analyze the relevance of his design choices. He must listen to the opinions of other members of his team. Above all, he must take into account the feedback from the playtests.
Therefore, he must be ready to start from scratch if a game mechanic is not satisfactory. Experience shows that if a game mechanic does not work, simple improvements may not be enough; it is often preferable to start again with a new mechanism.
Some young game designers tend to defend their ideas against all odds; they make it a personal matter. They are wrong. Their interest is that their name is associated with a published and effective game rather than their ideas being retained in a mediocre or never-published one.
Common sense advice? This is not the case for everyone. Here is a new illustration of the consequences when a designer persists in defending “his” vision of the game.
Igor is the lead-level designer on a multiplayer game for home consoles. The first playtests, carried out with players from outside the studio and representatives of the targeted audience, validate the game mechanics but point out problems in the maps: They are too large in relation to the number of players, the latter get lost easily, and they have too many bottlenecks.
The playtest sessions follow one another. Each session comprises players who have never played the game and all report the same problems related to level design. The problems cited by the playtesters are nevertheless systematically reported to Igor after each playtest session, but the modifications made to the maps are minor and do not change the feedback from the playtesters.
After several months, faced with Igor's reluctance to fundamentally change the maps, the studio management removed him from his position and replaced him with another team member.
In the next part of this publication, I will discuss the other essential skills, in my eyes, for a game or level designer.
Pascal Luban
Game designer & creative director, freelance
28+ years of experience serving game developers and publishers
Photo credit: Poca Wander Stock
You May Also Like
