Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.
Andrew Kelley, el creador del lenguaje de programación Zig, abrió una charla con una pregunta incómoda: ¿a quién sirve realmente el software que escribimos? La charla se titula “Don’t Take the Black Pill” y nació para una audiencia de desarrolladores, no de game designers. Pero es exactamente la pregunta que deberíamos hacernos cada vez que diseñamos un sistema de progresión.
Un criterio más honesto que la “diversión”
La Self-Determination Theory de Deci y Ryan dice que una persona está bien, en un juego como en la vida, cuando siente satisfechas tres necesidades: autonomía (mis decisiones importan), competencia (estoy mejorando, y lo noto) y relación (no estoy solo). Un sistema puede tener métricas de retención impecables y aun así negar las tres. Eso también tiene nombre: coercive retention. La progresión existe, pero el jugador vuelve por un temporizador que expira o una notificación que lo llama de vuelta, no porque tenga ganas de entrar al juego.
Coercionware, también fuera de los juegos
Kelley llama a esta categoría “coercionware”: software cuyo propósito no es servir a quien lo usa, sino manipularlo. Los ejemplos que pone no vienen de los juegos — notificaciones push no solicitadas, A/B tests que optimizan el clic y no la experiencia, algoritmos de recomendación que persiguen el engagement en lugar del valor. Lo que más me impactó es que describe todo esto como una decisión de diseño, no como un efecto secundario. Alguien, en una reunión, decidió que así estaba bien.
El mismo problema, otro nombre
En los juegos lo llamamos de otra manera: gacha, eventos de tiempo limitado, season passes que aprietan las tuercas. Pero es el mismo mecanismo: se quita autonomía para garantizar el regreso. Lo escribí la semana pasada hablando de dopamina y oxitocina — la relación de la Self-Determination Theory es, en el fondo, el mismo argumento que la oxitocina. Un jugador que vuelve para estar en un mundo o con otras personas no necesita que lo retengan con un temporizador.
El hábito que ayuda
Hay un hábito sencillo que uso cuando evalúo una feature nueva: hacerme de abogado del diablo conmigo mismo. Asumir que falla, y preguntarme por qué. Normalmente la lista de motivos incluye cosas como “confunde al jugador” o “no convierte lo suficiente”. Vale la pena añadir una más: falla porque manipula en lugar de servir. No es una pregunta que aparezca sola en una reunión de roadmap. Hay que hacerla adrede, antes de lanzar.
La próxima vez que una feature mejore los números, la pregunta correcta no es si funciona. Es si el jugador la elige, o si ha caído en la trampa.