774e2b3789b34a1a8af949011726b5f3

Training the game designers of tomorrow (Part 5/5)

Mon, 10 Jun 2024 13:44:06 GMT

My blog

Training the game designers of tomorrow (Part 5/5)

In the final part of this series of publications devoted to the training of game and level designers, I address a little-taught aspect of the game design process: Playtests. However, they constitute the best quality assurance for the gameplay of a game.

The playtest paradox

Today, everyone agrees on their importance. And yet, many studios do not pay enough attention to them!

The reasons are multiple: Lack of time to organize playtest sessions, lack of know-how, but above all, lack of vision of the project managers who, most often, have never had the opportunity to benefit from good playtests. You have to have tasted the playtests to really understand their potential.

What makes playtests so relevant, so effective, is that they must be conducted with players, that do not belong to the development team and representative of the audience you are targeting.

You also need to follow a good methodology. The latter is not complicated but it is not always known or well understood.

But if these two conditions are met, the playtests will have a significant impact on the project. They make it possible to improve the game system, to adapt it to its audience, to make the game more understandable, to improve onboarding and long-term retention, to refine tunings, to balance them. for multi-player modes, to build a more “readable” and richer level design.

This is why game and level designers must be aware of their importance, must understand how to integrate them into their work and must have the skills to implement them if the need arises.

Case study

To illustrate the impact of playtests on the quality of a game, here is a concrete situation that I experienced during my mission on the multiplayer version of Splinter Cell - Pandora Tomorrow .

The multiplayer mode of this game was developed at the Ubisoft studio in Annecy while the single-player mode was the responsibility of the Shanghai studio. I joined the Annecy team to set up and manage the playtest structure; It was only later that I also became lead level designer. However, I continued to take care of the playtests in parallel.

This multiplayer mode was absolutely unique because it offered asymmetrical gameplay: The two sides did not have the same gameplay.

The players from the attackers' camp, the spies, had an infiltration type gameplay: They could hide in the shadows and move silently, climb all over the place, they had access to specialized equipment, they used third-person view for a better understanding of their environment. On the other hand, it was very difficult for them to kill their opponents.

Players on the defenders' side, the mercenaries, had access to first-person shooter-style gameplay: They had an impressive arsenal, detection equipment and mines of all kinds but they were slow and they could only use stairs and floors.

The victory conditions were simple: The attackers had to neutralize X consoles on Y within a limited time and the defenders had to prevent them.

The equipment was plentiful and all had real value. Tuning these gave us a lot of trouble and without the playtests, we would never have succeeded.

A good example is the smoke grenade, one of the attackers' accessories. This grenade could only be thrown at the feet of the attacker who activated it; it had been designed as a means of defense in the event of an encounter with a mercenary. Once on the ground, the grenade produced a cloud of smoke which blocked the visibility of the defenders and slowed them down if they decided to pursue the attacker.

Faced with such powerful equipment, the defenders had "counters": With the gas mask, they could pass through the cloud of smoke without being slowed down and the thermal vision allowed them to see their target through the cloud. That said, as players could only carry four pieces of equipment in their loadout, not all defenders systematically equipped the gas mask. As for thermal vision, the narrowness of its cone of vision limited its use when facing a target moving in a zig-zag pattern.

The smoke grenade was therefore a popular accessory for attackers because it was effective in the event of a chance encounter.

But we realized, during playtests, that the attackers had found a new use for this defensive accessory: Making it easier to take objectives.

To take an objective, an attacker simply had to hack a console while remaining around for a short period of time. This delay was short but the operation was very dangerous because the defenders were immediately informed of the attacked console. And since, the attackers did not have a lethal weapon, they became a target.

But, as our maps were mainly interior, access to the objectives was via corridors. Our playtesters then quickly realized that they could seriously slow down the arrival of defenders, and therefore take the objectives, by throwing smoke grenades into the access corridors!

There was no question of removing the slowing effect associated with smoke grenades because the latter was greatly appreciated by the attackers, but these grenades must not unbalance the game in favor of the latter.

The solution was to play on the “lifespan” of the smoke cloud but finding the right setting proved very tricky: A few seconds too long and the smoke grenade unbalanced the game, a few seconds less and it became almost useless to the attackers !

The right setting, down to the second, was finally found after numerous playtest sessions where experienced players played a good hundred games with different settings.

For the record, the multiplayer mode of Splinter Cell - Pandora Tomorrow was a huge success. It was also present in the following two opuses: Chaos Theory and Double Agent . For my part, I continued my mission at Ubisoft Annecy until the end of the development of Chaos Theory .

Good practices

Explanations on the organization of the playtests would require a full publication. Based on the principle that a game designer is above all the “client” of playtests, its recipient, I will share some best practices for you, the beneficiaries of playtest sessions.

Use playtest sessions to assess specific aspects of your design

Today, many teams seek to implement short and iterative development cycles: Design - development - test - design modification - development - test - Etc.

With this in mind, use playtest sessions to assess your work in progress. This means that it is you, the game or level designer, who must inform the playtest manager of your needs in terms of player feedback. This will allow him or her to adapt the content of playtest sessions to the needs of the moment.

Generally speaking, playtest sessions that follow an immutable, standard protocol are not of much use.

Attend the sessions

By attending the sessions yourself, you will be able to observe the playtesters. You will see the choices they make, their hesitations when faced with a menu, their good or bad use of features, their difficulty in using them, their navigation patterns in a map, etc.

But, above all, you will see what they DON’T do. A game or a level designer imagines the behavior of the players but they play as they want and often do things that were not anticipated. By observing their behavior, we understand much better what players expect from their game, which will make it less frustrating and more engaging.

And, of course, you will be able to ask them your own questions.

If you settle for debriefs from the playtest manager only, you will miss these valuable lessons.

Encourage your project management to organize playtests

Finally, if your project management is slow to put playtests in place, a situation I witness frequently, push them to do it... and insist! Resistance in this area is significant... and I know what I'm talking about.

Remember that if the game design is not satisfactory, you will be the one to blame. Playtests will allow you to identify weaknesses in your gameplay or levels and remedy them before it is too late.

The final word

In France, we are fortunate to have excellent schools training in the different professions present in a development studio. Having had the opportunity to work with young game designers from these schools, I was able to appreciate the quality of their training. But I wanted to share with you lessons resulting from my experience in the field.

Even today, I am learning.

The human being is an eternal apprentice.

Thank you for reading my posts.

Training the game designers of tomorrow (Part 4/5)

Fri, 31 May 2024 12:27:58 GMT

My blog

Training the game designers of tomorrow (Part 4/5)

In the previous part of this series of publications devoted to the training of game and level designers, I explained why a game designer must integrate marketing considerations from the concept phase of a game. I continue today with two other marketing issues to keep in mind when developing a game concept.

Know your audience

When game designers develop a concept, their first reflex is to draw inspiration from their own tastes and desires. It’s human because the intensity of the emotions felt is a powerful spur. But we are not always representative of the audience our game is intended for. Developing a concept based on our tastes is dangerous; we don't make a game for ourselves, we develop it for an audience, an audience.

Identifying your audience and taking the time to get to know them are therefore good reflexes to have during the concept phase. The following case study is a good illustration of this.

Case study

A few years ago, I contributed as a game designer in the development of Wars and Battles , a portal offering several turn-based wargames, intended for digital tablets such as iPads. As part of the Battle Factory development team, I saw how the precise definition of the audience had an impact on the design of the game.

The targeted platform was the iPad because it offered almost no turn-based wargames. But which audience should we target: Traditional wargamers accustomed to complex turn-based simulations, or “digital” gamers who favored real-time games offering simpler mechanics?

Our choice fell towards traditional wargamers due to the expected widespread use of digital tablets. We therefore made design choices designed to meet their expectations: turn-based gameplay, care given to historical credibility, game mechanics directly inspired by those used in "paper" wargames, detailed description of the results of the battles, historical facts, choice of the most popular battles among wargamers such as the battle of Normandy.

But for gamers who discovered the game, we added a 3D viewing mode and animations for combat.

For fans, the game is no longer available in the App Store but can be found on Steam. Two battles are proposed: The Battle of Normandy and the Israeli-Arab War of 1973. Play them, they are real simulations but easy to learn and well-crafted.

Good practices

How to identify your audience and know their expectations? Here are some best practices.

Identify games similar to the one you plan to develop.

This is the simplest method, and accessible to everyone, to identify your audience. What if your game has no equivalent because it mixes two different gameplays? Assume that one of the two gameplays will always be more prevailing than the other. Then stick to that “dominant” gameplay.

Connect with gaming communities.

Once you have identified your reference game, go to the forums dealing with this game or genre. A simple method is to present yourself as a developer looking for player opinions. You should receive lots of responses. Sort through and identify contributors who seem to know your reference game well and who have the best analytical skills. You will then learn a lot about the “must-haves” and the mistakes to avoid.

When I designed the CTF-Tornado multiplayer map for Unreal Tournament 3 's Extrem PhysX mod, I relied heavily on the gaming community to define key features of the map such as its main game mode, its size , the number of players and its topology. It was through the forums that I was able to do this.

A variation of the previous method is to organize focus groups.

Called focus group in English, this method is used by major publishers. While I was working on the multiplayer mode of Splinter Cell - Chaos Theory as lead level designer, Ubisoft conducted such focus groups to better understand the improvements to be made to our game.

A focus group is not an informal meeting; it is a codified method which requires the presence of a facilitator trained in this method. If the participants are well selected, that is, if they are representative of the target audience, and if the group discussion is properly conducted, you will learn a lot.

Watch Your Back – Know Your Competitors

How can I have any idea which games will compete with the one I'm working on since it will be released in a year or two?

The task seemed illusory. And yet, we can already get a good idea of the games that will be your direct competitors by identifying your competitors today. Indeed, games tend to have longer and longer lifespans. Publishers are pushing to develop games designed to keep their players for many years. If a game is a benchmark today, there's a good chance that game will still be around in one, two, or even three years. In addition, you can also bet that its developers will have taken advantage of the years to enrich it and therefore make it even more competitive.

To know your future competitors, start by identifying games already published, or which will soon be published, and which are likely to interest the same audience.

Why is it useful, when working on the concept of a game, to know your competitors?

There are basically two reasons.

First, we can get an idea of the density of its direct competitors, games that are similar to the one you plan to develop. If these competitors are numerous, this means that you will be hitting the mark in terms of audience but it also means that you absolutely must differentiate yourself with a good USP. But, on the contrary, if you have no competition, it can mean two things: Either you had a good intuition before the others, or the audience for your game is non-existent. Such an observation should prompt you to exercise caution.

The second reason to know your competition well is to better identify what your audience expects from this type of game: What functions are they popular with? What should the level of difficulty and rhythm construction be? How high are production values? What are the main complaints from players?

Case study

I worked, as game designer, on Alone In The Dark - The New Nightmare , the fourth opus in the series. Launched by Infogrames , this franchise marked the industry because it invented the premises of horror-survival games.

After the first three episodes, the series had gone dormant but the arrival of Resident Evil had reawakened Infogrames ' ambitions. The latter entrusted the French studio Darkworks with relaunching the franchise.

As we thought about the concept of our game, we quickly asked ourselves the following question: Should we start with the mechanics that Alone In The Dark players were accustomed to or take inspiration from the model developed by Capcom ?

We only had one competitor at the time, Resident Evi l, but what a competitor! Capcom 's title included many of the features that made the success of the first games published by Infogrames but modernized them and, above all, adapted them to the Playstation.

Resident Evil having become the new benchmark in terms of control and inventory management, we decided to take inspiration from it in order not to disturb players accustomed to the standards put in place by Capcom .

But, in order to differentiate ourselves, we placed emphasis on storytelling. Antoine Villette, one of the founders of Darkworks , wrote a scenario of rare quality at the time in video games. And in order to offer a USP, we built the scenario around two characters, each experiencing the adventure from their own point of view.

The analysis of our main competitor allowed us to limit the risks on the game system while differentiating ourselves from Resident Evil on a key aspect of its success: Narration.

The game was released on Playstation, PC and Dreamcast and sold more than two million copies, a very good performance for the time.

Best practices

Develop a competitive matrix.

This tool allows you to position your game project in relation to its competitors. In the example below, Sea Hunter is the game project; the other games are the identified competitors.

The axes are defined according to the most salient characteristics of the game genre. In the example above, these are the number of game modes and the level of complexity of the gameplay.

We can deduce that most of the competition offers a gaming experience for one player only, while Sea Hunter differentiates itself with its multiplayer mode. Additionally, compared to its closest competitor, WarGroove , Sea Hunter offers less complex gameplay. Its only real competitor is Her Majesty’s Ship.

In addition to this competitive analysis, identify one or two similar games and play them a lot.

The goal is not just to list the features offered and gameplay mechanics. The main objective is to identify what will bring pleasure to the player or, on the contrary, what will frustrate him. Don't focus on the mechanics; listen to your emotions!

To be continued …

In the last part of this series of publications dedicated to the training of future game designers, I will deal with the practice which is certainly the most relevant to guarantee the quality of a game. Those of you who know me know what I will speak; for the others, all you have to do is wait!

Photo credit: Poca Wander Stock

Training the game designers of tomorrow (Part 3/5)

Thu, 23 May 2024 12:22:10 GMT

My blog

Training the game designers of tomorrow (Part 3/5)

In the first two parts of this series of publications devoted to the training of game and level designers, I addressed the importance of soft skills, an essential complement to know-hows. Let's now address a topic that seems far from design but which a game designer must be concerned with: Marketing and communication.

State of play

A very common mistake among game designers is to underestimate the importance they should give to marketing.

« Why should I care about marketing? How am I affected by the communication strategy? My responsibility is to design a fun game! Marketing and communication are the responsibilities of the publisher. »

Yes but no.

It is true that it is the marketing teams of the publisher, or of the studio if it self-publishes its game, who are responsible for setting up communication campaigns. But they are not responsible when design choices weaken the interest of the game in the eyes of the media and players.

The very large-scale distribution of media and social networks has led to hyper-abundant information and it is no longer enough to communicate about a good game to attract attention.

The situation is made even more difficult by the plethora of games on offer, many of which are free and easily downloadable.

A game designed without marketing in mind runs the risk of being a commercial failure. The design team must therefore ask the right questions, right from the concept phase.

What are they ? Let's start with the most important: What is the USP, the Unique Selling Point, of my game?

Sniper Alley

The USP is the feature of the game concept that must be original enough to attract attention. Developing a concept around its USP is probably the best advice we can give to a game designer, junior or senior.

The USP can apply to any aspect of the game: Its gameplay or mix of gameplays, its game modes, its aesthetics, its narrative theme, its control interface, its atmosphere, its use of an IP, its distribution platform, etc.

The USP has two functions:

First, to differentiate your game from the countless other titles that saturate the media and social networks. Nothing is more attractive than the promise of a new experience. This is how a USP works: It promises players new sensations, it stimulates their curiosity, it offers them unknown challenges.

The second function of the USP is to become the pillar of the communication strategy that will be implemented during the marketing campaign. A basic rule in communication is to develop a strong, distinctive and simple “message” concerning the product you wish to communicate about. “Strong” means talking about something likely to generate a lot of curiosity. “Distinctive” means that the product must not be confused with any other. Finally, “simple” tells us that the message must be understandable through an image, a title or a slogan.

It now becomes clearer why game designers are concerned with marketing from the concept phase: They must design it around a real USP.

So what advice can we give for finding a good USP?

Good practices

The answer varies depending on the profile of the studio: Is it a small indie studio or a large structure developing a game around an IP?

In the case of the indie studio, here are the best practices:

Define a USP that will be immediately visible; Just by looking at a screenshot, players must understand that your game is going to offer them a different experience. Never forget that it is through an image or video that your future players will discover your game and decide, in a fraction of a second, if it is worth playing. A powerful publisher can do without a visual USP to draw attention to a game; it has a high-profile IP or a significant communication and player acquisition budget. But this is not the case for an indie studio that can only rely on its USP to get noticed.

Do some research to make sure the USP is truly unique. You might then discover that another game is already using it. If the latter is a success, change the USP; your USP is no longer one! But if this game was a failure, that does not call into question the relevance of the USP: Try to understand why this game was a failure and learn from it.

Ensure that the development of your USP is within the skills and resources of your team. Never oerestimate the difficulties and time needed to develop something new.

Build your game entirely around its USP, even if it means reducing your ambitions in terms of content.

Case study

To illustrate my point, here is the case of Timecode Studio and its game, Twist and Pop , a match 3 type game for which I did the level design.

In 2015, Timecode studio decided to develop a Match-3 mobile game to ride on the global success of this genre. But the market was crowded with many Candy Crush clones. The designers then had the idea of differentiating the game by offering traditional match-3 gameplay but in a completely different format: Players had to align three objects, no longer on a grid, but by rotating two circles.

The result was stunning; it was exactly the same gameplay as traditional match-3 but in a completely new graphic style. The graphic differentiation was accentuated by the simplicity of shapes and colors, very far from the garish style of many match-3 games. The game stood out visually from its competitors, which was the USP that Timecode was looking for.

In the case of a large structure developing a game around an IP, my recommendations are different.

Indeed, the IP itself is often the USP but the latter is perhaps not enough to make the game exciting: The IP will attract the attention of players and the media but if the gaming experience appears is too classic, you will then have to innovate.

Good practices

Make sure that your innovation is not central to the gameplay of your game. Indeed, games developed around IPs must often be published on a date scheduled well in advance. However, if your innovation requires much more time than expected for its development and it is central to the gaming experience, you risk “missing” the release date for your game.

Propose an innovation directly related to the IP. You will thus be able to “surf” on the intrinsic force of attraction of the latter. In addition, you will prevent the owner of the IP, who often has the last word, from refusing your proposal altogether, a situation which I witnessed directly on Duck Dynasty, a PS4 and Xbox One game, published by Activision, where I acted as a consultant. The IP owner refused our scenario on which our entire level design was based.

Case study

I was confronted with these issues during my contribution to Wanted - Weapons Of Fate , as creative director.

Published by Universal, the producer of the eponymous film, Wanted - Weapons of Fate was to be released alongside the feature film; deadlines were particularly tight. We therefore took little risk on the core gameplay which was based on third-person shooter mechanics. But to bring a touch of novelty, and to stick to the specificities of the franchise, we added a complementary curved shot mechanic. It provides a challenge, it is very rewarding to use and it fits the film perfectly. But, it is not central to the gameplay, it is not essential to confront enemies. If this mechanic had proven too complicated to develop, we could have easily “taken it out” of the game.

To be continued …

In the next part of this publication, I will discuss two other aspects of marketing that game designers must include in their thinking.

Photo credit: Poca Wander Stock

Training the game designers of tomorrow (Part 2/5)

Tue, 16 Apr 2024 12:28:20 GMT

My blog

Training the game designers of tomorrow (Part 2/5)

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.

Soft skills 3 - Know how to explain your ideas and promote them

Salesmanship

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.

Good 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.

Case study

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.

Soft skills 4 - Be kind

The boomerang effect

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.

Good practices

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.

Case study

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.

To be continued …

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.

Photo credit: Poca Wander Stock

Training the game designers of tomorrow (Part 1/5)

Fri, 22 Mar 2024 14:10:51 GMT

My blog

Training the game designers of tomorrow (Part 1/5)

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

How to respond well to an RFP (request for proposal)

Fri, 01 Apr 2022 09:15:28 GMT

Many studios develop games on behalf of publishers who entrust them with the task of designing and developing a game for one of their franchises. Publishers start by selecting a list of studios likely to develop this project and send them an RFP, a request for proposal.

The reply to an RFP is different from a pitch deck. The purpose of this publication is to share best practices for preparing it correctly, increasing your chances of being selected by the publisher and entering into exclusive negotiations with the latter.

The content of an RFP response document

There is no standard format, model that everyone uses. The studios are therefore free to put whatever they want in it. The content template that I offer you is therefore based on the best practices that I have observed among my clients.

1) Introduction

If there is a part that must seek to seduce, it is this one. The introduction is intended to seduce a possible senior official who will not read the entire document but who will want to make sure that the RFP is consistent with the franchise.

The few pages of the introduction should therefore only include a few key points that will seek to demonstrate that the game project respects the main traits of the franchise. As an option, you can add a page listing the main features of the game.

2) Marketing summary

It is a summary table that allows a marketing manager to position the game project in relation to the market. The main headings of this table are as follows:

Genre
Game world
Platform(s)
Game mode(s) and number of players
Target audience
Languages
USP (unique selling point)
Economic model
Age rating
Game structure
Rendering
Camera type(s)
Type(s) of control
Main actions of the player.

3) A comparison with competing titles (optional)

Such a comparison takes a time to prepare, which is why it is optional, but it is interesting because it demonstrates that your studio knows the competitive environment of the game that it is required to develop on behalf of the publisher.

4) Gameplay

In this part, all game mechanics should be explained and illustrated. Artwork must show what the player will see on their screen.

For games with a strong narrative dimension (action-adventure, action, RPG, adventure, etc.), I recommend developing a walkthrough describing the beginning of the game. Indeed, the simple description of the game mechanics does not always make it possible to understand what the player will experience. A walkthrough should be written like a novel. It can also describe what the player feels, thus making its reading more thrilling. Of course, a walkthrough must also be properly illustrated.

5) Monetization strategy

Today, we can no longer content ourselves with proposing a game concept without proposing a monetization strategy. The representative of a major freemium publisher once told me that he was desperate to find that half of the game projects he received didn't even mention monetization... although he kept saying that it only publishes freemium games.

As a reminder, a good monetization strategy does not consist in defining what we will sell in the game; it consists of explaining how the gaming experience will convince players to spend money on a free game.

The monetization strategy also describes retention mechanisms - short and long term - and possible in-game viralization mechanisms.

6) The artistic letter of intent

This section must show your artistic choices. If possible, it should include illustrations of backgrounds, characters, and even menu screens.

If you don't have the time or resources to develop so many assets, come up with mood boards.

7) Technical choices

List the technical solutions you plan to use: Game engine, software suites, but also project management and versioning software.

If you plan to use your own game engine, present its advantages, list the games using it and add screenshots.

8) Presentation of your team

This part is one of the most important. It is useless to present the best game project if you do not reassure your interlocutor on your ability to carry it out.

Display the past achievements of your studio but above all, individually present the key members of your team. They are the ones who will make your offer credible. Promote their accomplishments, including at other studios.

9) Additional content (optional)

Today, many publishers are integrating additional content into the life cycle of their games. It serves to retain players, maintain media interest and, eventually, generate additional revenue.

Submit a list of additional content to the publisher. Your interlocutor may not include it in his initial budget, but it allows him to demonstrate that your game project has potential in this area.

10) "Game-as-a-service" dimension (optional)

If your game is a "live game", a game designed to support events, plan a section entirely dedicated to this theme. Some publishers, for certain game genres, place a lot of importance on this.

11) Budget

Present a relatively detailed budget. At this stage, it is useless to break it down by month; just give the overall amounts by line of expenses as well as your estimate of the number of man-days, by department (art, coding, etc.).

Finally, do not try to minimize the overall budget in the hope of seducing the publisher. Too low a budget will do you a disservice because it will make you look like amateurs who are unaware of the implications of full development.

In conclusion …

Fellow editors, help me improve this summary. Send me your comments or suggestions for improvement (pluban@gamedesignstudio.com) or share them as a comment to this publication.

Photo credit: elnavegante