Andrew Kelley, il creatore del linguaggio di programmazione Zig, ha aperto un talk con una domanda scomoda: a chi serve davvero il software che scriviamo? Il talk si intitola “Don’t Take the Black Pill” ed è nato per una platea di sviluppatori, non di game designer. Ma è esattamente la domanda che dovremmo farci ogni volta che progettiamo un sistema di progressione.
Un metro più onesto della “fun”
La Self-Determination Theory di Deci e Ryan dice che una persona sta bene, in un gioco come nella vita, quando sente soddisfatti tre bisogni: autonomia (le mie scelte contano), competenza (sto migliorando, e lo vedo) e relazione (non sono solo). Un sistema può avere metriche di retention pulitissime e comunque negare tutti e tre. Ha un nome anche questo: coercive retention. La progressione c’è, ma il giocatore torna per un timer che scade o una notifica che lo richiama, non perché ha voglia di rientrare nel gioco.
Coercionware, anche fuori dai giochi
Kelley chiama questa categoria “coercionware”: software il cui scopo non è servire chi lo usa, ma manipolarlo. Gli esempi che porta non vengono dai giochi — notifiche push non richieste, A/B test che ottimizzano il click e non l’esperienza, algoritmi di raccomandazione che inseguono l’engagement invece del valore. Il punto che mi ha colpito è che descrive tutto questo come una scelta di design, non un effetto collaterale. Qualcuno, in una riunione, ha deciso che andava bene così.
Lo stesso problema, altro nome
Nei giochi lo chiamiamo con altri nomi: gacha, eventi a tempo, season pass che fanno pressione. Ma è lo stesso meccanismo: si toglie autonomia per garantire un ritorno. Ne ho scritto la settimana scorsa parlando di dopamina e ossitocina — la relazione della Self-Determination Theory è, in fondo, lo stesso discorso dell’ossitocina. Un giocatore che torna per stare in un mondo o con altre persone non ha bisogno di essere trattenuto con un timer.
L’abitudine che aiuta
C’è un’abitudine semplice che uso quando valuto una feature nuova: fare l’avvocato del diavolo con me stesso. Assumere che fallisca, e chiedermi perché. Di solito la lista dei motivi include cose come “confonde il giocatore” o “non converte abbastanza”. Vale la pena aggiungerne uno: fallisce perché manipola invece di servire. Non è una domanda che appare da sola in una riunione di roadmap. Va fatta apposta, prima di spedire.
La prossima volta che una feature migliora i numeri, la domanda giusta non è se funziona. È se il giocatore la sceglie, o se ci è rimasto intrappolato.