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.
Andrew Kelley, el creador del llenguatge de programació Zig, va obrir una xerrada amb una pregunta incòmoda: a qui serveix realment el programari que escrivim? La xerrada es titula “Don’t Take the Black Pill” i estava pensada per a una audiència de desenvolupadors, no de game designers. Però és exactament la pregunta que hauríem de fer-nos cada vegada que dissenyem un sistema de progressió.
Un criteri més honest que la “diversió”
La Self-Determination Theory de Deci i Ryan diu que una persona està bé, en un joc com a la vida, quan sent satisfetes tres necessitats: autonomia (les meves decisions compten), competència (estic millorant, i ho veig) i relació (no estic sol). Un sistema pot tenir mètriques de retenció impecables i tot i així negar les tres. Això també té nom: coercive retention. La progressió hi és, però el jugador torna per un temporitzador que expira o una notificació que el crida de tornada, no perquè tingui ganes de reprendre el joc.
Coercionware, també fora dels jocs
Kelley anomena aquesta categoria coercionware: programari l’objectiu del qual no és servir qui l’usa, sinó manipular-lo. Els exemples que posa no vénen dels jocs —notificacions push no sol·licitades, tests A/B que optimitzen el clic i no l’experiència, algoritmes de recomanació que persegueixen l’engagement en lloc del valor. El que em va colpir és que descriu tot això com una decisió de disseny, no com un efecte col·lateral. Algú, en una reunió, va decidir que estava bé fer-ho així.
El mateix problema, un altre nom
Als jocs l’anomenem d’una altra manera: gacha, esdeveniments a temps, season passes que fan pressió. Però és el mateix mecanisme: es treu autonomia per garantir un retorn. En vaig parlar la setmana passada a propòsit de la dopamina i l’oxitocina —la relació de la Self-Determination Theory és, al cap i a la fi, el mateix discurs que l’oxitocina. Un jugador que torna per estar en un món o amb altres persones no necessita ser retingut amb un temporitzador.
L’hàbit que ajuda
Hi ha un hàbit senzill que faig servir quan avaluo una nova funcionalitat: fer d’advocat del diable amb mi mateix. Assumir que fracassa, i preguntar-me per què. Normalment la llista de motius inclou coses com “confon el jugador” o “no converteix prou”. Val la pena afegir-n’hi un: fracassa perquè manipula en lloc de servir. No és una pregunta que aparegui sola en una reunió de roadmap. Cal fer-la expressament, abans de llançar.
La propera vegada que una funcionalitat millori els números, la pregunta correcta no és si funciona. És si el jugador la tria, o si hi ha quedat atrapat.