Mise en page du blog

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.


By Pascal Luban May 31, 2024
My blog Training the game designers of tomorrow (Part 4/5)
By Pascal Luban May 23, 2024
My blog Training the game designers of tomorrow (Part 3/5)
By Pascal Luban April 16, 2024
My blog Training the game designers of tomorrow (Part 2/5)
By Pascal Luban March 22, 2024
My blog Training the game designers of tomorrow (Part 1/5)
By Pascal Luban April 1, 2022
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
Share by: