Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
The Silent Revolution of Playtests, Part 2
View All     RSS
September 21, 2020
arrowPress Releases
September 21, 2020
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

The Silent Revolution of Playtests, Part 2


April 9, 2009 Article Start Previous Page 2 of 3 Next
 

Organizing the Sessions

I shall address three aspects of playtest organization: the composition of the team, the preparation of the playtest protocol, and its logistics.

Recruiting must start at least four or five days before the session itself. At this stage, the playtest manager already has access to a database of candidates that have already been evaluated or, at least, identified. He can thereby choose his playtesters according to the session's theme. Invites are sent by e-mail.

At this point, we realize the importance of having a great number of candidates, since most are not available at will. We must therefore engage in mass-mailing to ensure sufficient availability of playtesters come session day.

It is also best to invite at least one more playtester than necessary, since last minute withdrawals are commonplace. It is also usually a good idea to ask playtesters to confirm their presence via e-mail.

Protocol setup is an important part of session preparation. Some playtests are organized near the end of the development cycle, to tune up maps or the game system. The protocol for this type of playtest is often straightforward: we must allow the playtesters to play for a maximum of time, note game statistics, and organize open Q&A sessions.

The time when playtests are most useful, however, is during earlier stages of the development cycle, when the game system and maps are still in gestation. Let us not forget that the earlier we detect any issues, the easier and cheaper it will be to correct them.

During the development of maps for the multiplayer version of Splinter Cell: Chaos Theory, I had organized playtests to evaluate the structure of the then still-embryonic maps.

I specifically remember the Aquarius map: By having it tested by highly experienced playtesters, we -- including the level designer who had built the map -- quickly realized that the map was far too large.

Having noticed this problem, he immediately rebuilt his map, which took little time as the map was still just a prototype. It took him a few iterations to downsize his map to the optimal size. In the end, Aquarius became one of the game's most popular maps.


Ubisoft's Splinter Cell: Pandora Tomorrow

Playtests allow us to shed light on many problems and to validate (or invalidate) hypotheses set by the design team. During the development of the multiplayer version of Splinter Cell: Pandora Tomorrow, specific playtests were undertaken with the purpose of tweaking the characteristics of certain pieces of equipment, such as the smoke grenade.

The latter is one of the most-used accessories by the spies, since its cloud slows down the spy's opponents (the mercenaries), and it can even put them to sleep if they stay too long in its area of effect.

Tuning the smoke grenade's parameters was not so simple -- if its range was too wide, it would be an unstoppable weapon for the attackers (they would simply need to employ a single grenade in a corridor to block any access by their opponents).

On the other hand, if the grenade's effect zone were too small, the weapon would be completely useless (defenders have vision modes allowing them partial visibility through the cloud). Finding the right values took us a lot of time.

Lastly, to be relevant, protocols must adapt to problems encountered in previous sessions as well as to the test requests put forth by the design team. This commensurability with the development team's needs is one of the hallmarks of a successful playtest. I shall address this point later on.

Let us now talk about logistics. Good playtests require a stable build of the game without too many bugs. When directing playtests in the middle of the development cycle, this may be easier said than done. Regardless, the game must be sufficiently stable, and maps must be rid of the most detrimental bugs (such as the inability to climb a ladder, for example).

A game delivery protocol must be set up with the development team. The latter must deliver a playtest-ready version of the game to the internal debug team, which will rapidly review the game to ensure that the version is playtestable.

When issues arise, cooperation between the debug and development teams will allow for swift corrections of issues, and subsequently the production of a stable version suitable for playtests.

Such organizational finesse requires a lot of discipline from all of the teams involved. Another good practice is to prepare a checklist for the level and graphic designers, so that they can make sure that their own maps are free of blocker bugs. Finally, the playtest session manager himself must make sure that the version is indeed playable.


Article Start Previous Page 2 of 3 Next

Related Jobs

Visual Concepts
Visual Concepts — Agoura Hills, California, United States
[09.18.20]

Camera Designer
Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[09.18.20]

Development Director
Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[09.18.20]

Senior Development Manager (Xdev Team)
Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[09.18.20]

Senior Cinematic Scripter





Loading Comments

loader image