Aquest article va ser escrit originalment en italià per Paolo Gambardella. Ha estat traduït per un agent d’intel·ligència artificial i pot contenir inexactituds.
Quan parlem de game design document, de documentació de disseny, sovint passem directament als templates i formats estàndard. Al meu parer, així perdem l’oportunitat de veure el quadre general. El format, de fet, és només un aspecte d’una de les cinc parts d’una bona documentació de disseny.
Fa uns mesos vaig escriure sobre la diferència entre document i documentació. Aquest post continua des d’allà: un cop aclarit que estem documentant alguna cosa concreta, què ha de contenir el document?
Cinc punts de vista
Per fer-ho més tangible faré servir un exemple senzill: el boost en un joc de curses.
Coneixements. Primer de tot, un document de disseny s’estructura al voltant d’una sèrie de coneixements que el joc, o la feature en qüestió, hauria de transmetre als jugadors. En el passat he parlat de la player experience narrative, és a dir, el relat del joc o de la feature escrit des del punt de vista d’un jugador apassionat. Això ens ajuda a identificar els components del que anem a descriure, i per tant els skill atoms, els coneixements que transmetrem. La diversió sempre neix d’un procés de descoberta, semblant al creatiu: jugar és aprendre.
En el cas del boost, els skill atoms podrien ser: entendre quan la barra és plena, descobrir que fer el boost en corba fa perdre adherència, aprendre a guardar-lo per a la recta final. Cadascuna d’aquestes és una petita descoberta, i cadascuna s’ha de descriure.
Objectius. En segon lloc, el document conté els objectius que tenim des del punt de vista del joc. Aquests es concreten en comportaments específics que esperem dels jugadors i, de vegades, també en emocions que volem despertar. Normalment es parteix dels game pillars (si en tenim) i s’explica així la fita que hem d’assolir.
Per al boost, l’objectiu podria ser que el jugador el faci servir com a mínim una vegada per volta i que noti una descàrrega d’adrenalina a la recta. Un pillar només val la pena si ens obliga a renunciar a alguna cosa: si el pillar és “velocitat”, el document ha de dir també a què renunciem per mantenir-la, per exemple cap menú durant la cursa. I si esperem un comportament concret, escrivim també com el mesurarem. Un objectiu que no podem observar en un playtest o a les dades no és més que una esperança.
Gameplay. Després toca planificar el gameplay, concretant els objectius del jugador, els continguts, les activitats i les possibles estratègies que pot seguir per superar els obstacles. En aquesta secció és molt habitual trobar-hi diagrames de flux, llistes de punts i coses per l’estil.
Aquí és on entra en joc el format. La manera de presentar el gameplay ha de servir a qui el llegeix. Per al boost, un diagrama amb els estats (buit, carregant, ple, actiu) li diu al programador més que tres pàgines de text, mentre que una taula amb velocitat i durada és més útil per a qui s’ocupa del balanç. El format es tria en funció del contingut i del lector, i pot canviar de secció en secció.
Sistemes. Un bon document de disseny no pot deixar de tenir en compte els sistemes. Un sistema és un grup de mecàniques que, juntes, ensenyen alguna cosa al jugador: per això jo ho veig com un conjunt d’experiències d’aprenentatge. També hi ha dinàmiques no planificades, que de vegades aconseguim identificar i que després passen a formar part del metagame.
Scott Mercer explica en un breu vídeo com va dissenyar Gruul the Dragonkiller, un boss de World of Warcraft: Burning Crusade. Volia recrear l’emoció de les cadires musicals, quan la música s’atura i tothom corre a buscar lloc. La primera mecànica, Shatter, infligeix dany a qui està a prop dels altres, i així els jugadors aprenen a escampar-se. Mercer preveu de seguida una dinàmica no planificada: el raid podria assignar a cadascú un punt fix, i la gràcia desapareixeria. Afegeix llavors Ground Slam, que llança cada jugador en una direcció aleatòria i l’obliga a improvisar. Després hi ha la latència: el 2007 molts jugadors encara anaven amb mòdem, i cadascú veia els altres en posicions lleugerament diferents. Arriba llavors un alentiment progressiu, que dóna temps als clients per sincronitzar-se i, com a bonus, afegeix tensió. Finalment, com més jugadors moren, més espai queda per escampar-se, i per tant l’enfrontament es tornaria massa fàcil. Un augment gradual del dany manté tothom motivat per sobreviure.
Cada mecànica tapa el forat de l’anterior, i cadascuna canvia el que el jugador aprèn. Per això, si la feature que estem documentant forma part d’un sistema més gran, o si afecta altres sistemes, hem de demostrar que hem entès el quadre general i intentar preveure’n el funcionament. Tornant al nostre exemple: si el boost es recarrega recollint objectes a la pista, canvia també la manera com el jugador tria les trajectòries, i el level design ho ha de saber.
Producció. Finalment, una bona documentació de disseny ajuda a resoldre problemes i reptes de disseny, i guia programadors i artistes en la realització de tots els assets necessaris per a l’èxit de la feature o del joc en qüestió. Per al boost, això vol dir llistar efectes visuals, sons i moviments de càmera, i assenyalar les preguntes que encara estan obertes: què passa si el jugador activa el boost durant un salt?
Els templates tenen els seus límits
Quan ens centrem massa en el format final, correm el risc de perdre la visió general i d’ometre parts que potser un format inclou i un altre no.
Agafem el document d’una pàgina, el one-pager. És fantàstic per alinear l’equip o presentar una idea a un publisher, però els sistemes i les seves interaccions no hi caben. Molts templates clàssics de GDD, al contrari, tenen seccions interminables sobre el gameplay i cap sobre els coneixements que el jugador ha d’adquirir. Quan trio un format, ja sé quin dels cinc punts estic sacrificant, i el documento en un altre lloc.
Per això faig servir les cinc parts com una checklist, abans fins i tot d’obrir cap template: coneixements, objectius, gameplay, sistemes, producció. Si en falta un, el document té un forat, sigui quin sigui el format.