Many schools offer quality training in game design. But being trained in game design is not enough to BE 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. The purpose of this publication series is to better prepare future game designers for their missions. I draw on my experience, as a game designer and lead designer, but also as a trainer. To be or not to be … If there is one aspect that differentiates veterans from novices, it is mastery of soft skills. What is it about ? Soft skills correspond to the personal qualities and behaviors of an individual 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 which are the fruit of my 28 years of experience as a game designer. Soft skills 1 - Always follow the implementation of your design 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 if the gameplay is mediocre, it is you who will be blamed, not the team members who put it in place, even if they did not respect your specifications! Good practices 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 to them, orally and with the support of diagrams, the main lines of your design. Check that the functionality developed corresponds to what you have defined Spend a lot of time testing, testing, and testing the game again. Case study To illustrate my point, I will share with you situations that I have witnessed or experienced. Of course, the names are fictitious in order to preserve the anonymity of each person. Luigi is a game designer on an action-adventure game where the main character is accompanied by a teammate. Luigi writes the design of the mechanics which manages the behavior of the teammate, the places he goes, the attitude he adopts and the action he takes. This mechanic is based on the positioning, by the level design team, of waypoints. 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 topology of the map: Certain passage points are found under the ground or are 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. Soft skills 2 - Prepare intelligently for the meetings to which you are invited If a meeting is well organized, it has an agenda, a list of topics that will 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, someone 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. Good practices 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 area of 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. Case study Here is a new illustration of what to do...and not to do: J ohn is invited to a meeting organized by the creative director of the project. Other game designers will also be present. The agenda specifies that we will deal with a feature present in the game but which 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 which 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. Soft skills 3 - Be humble and open to changes A game designer is always attached to his work, to his ideas. It's normal. But a game mechanic remains a mere figment; until it has been developed and integrated into the game, we can never be sure of its interest. 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, its settings, its rhythm, the player's objectives, its complexity, etc. A mechanic can effectively contribute to a quality experience in one game but be detrimental in another. A game designer must therefore 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 and above all, he must take into account the feedback from the playtests. He must therefore be ready to start from scratch if a game mechanic is not satisfactory. Moreover, 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 game or one that was never published. 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. Case study Igor is lead level designer on a multiplayer game for home consoles. The first playtests, carried out with players from outside the studio and representative 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 is made up of 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 member of the team. To be continued … In the next part of this publication, I will discuss the other essential skills, in my eyes, for a game or level designer. Photo credit: Poca Wander Stock

Many schools offer quality training in game design. But being trained in game design is not enough to BE 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. The purpose of this publication series is to better prepare future game designers for their missions. I draw on my experience, as a game designer and lead designer, but also as a trainer. To be or not to be … If there is one aspect that differentiates veterans from novices, it is mastery of soft skills. What is it about ? Soft skills correspond to the personal qualities and behaviors of an individual 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 which are the fruit of my 28 years of experience as a game designer. Soft skills 1 - Always follow the implementation of your design 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 if the gameplay is mediocre, it is you who will be blamed, not the team members who put it in place, even if they did not respect your specifications! Good practices 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 to them, orally and with the support of diagrams, the main lines of your design. Check that the functionality developed corresponds to what you have defined Spend a lot of time testing, testing, and testing the game again. Case study To illustrate my point, I will share with you situations that I have witnessed or experienced. Of course, the names are fictitious in order to preserve the anonymity of each person. Luigi is a game designer on an action-adventure game where the main character is accompanied by a teammate. Luigi writes the design of the mechanics which manages the behavior of the teammate, the places he goes, the attitude he adopts and the action he takes. This mechanic is based on the positioning, by the level design team, of waypoints. 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 topology of the map: Certain passage points are found under the ground or are 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. Soft skills 2 - Prepare intelligently for the meetings to which you are invited If a meeting is well organized, it has an agenda, a list of topics that will 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, someone 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. Good practices 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 area of 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. Case study Here is a new illustration of what to do...and not to do: J ohn is invited to a meeting organized by the creative director of the project. Other game designers will also be present. The agenda specifies that we will deal with a feature present in the game but which 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 which 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. Soft skills 3 - Be humble and open to changes A game designer is always attached to his work, to his ideas. It's normal. But a game mechanic remains a mere figment; until it has been developed and integrated into the game, we can never be sure of its interest. 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, its settings, its rhythm, the player's objectives, its complexity, etc. A mechanic can effectively contribute to a quality experience in one game but be detrimental in another. A game designer must therefore 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 and above all, he must take into account the feedback from the playtests. He must therefore be ready to start from scratch if a game mechanic is not satisfactory. Moreover, 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 game or one that was never published. 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. Case study Igor is lead level designer on a multiplayer game for home consoles. The first playtests, carried out with players from outside the studio and representative 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 is made up of 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 member of the team. To be continued … In the next part of this publication, I will discuss the other essential skills, in my eyes, for a game or level designer. Photo credit: Poca Wander Stock