Portal: cómo enseñar al jugador sin decirle qué tiene que hacer

Imagina que acabas de implementar una mecánica nueva en tu videojuego.

El jugador necesita comprender qué hace, cuándo utilizarla y cómo combinarla con otros sistemas. La solución más sencilla parece evidente: mostrar un mensaje en pantalla explicando los controles.

Pero existe otra posibilidad.

¿Y si el propio nivel pudiera enseñarle?

Cuando Valve publicó Portal en 2007, construyó buena parte de su experiencia alrededor de esta idea. Sus primeras cámaras de prueba introducen progresivamente las reglas del juego hasta conseguir algo especialmente difícil: que el jugador aprenda sistemas cada vez más complejos sin sentir que está leyendo constantemente un manual.

Para un desarrollador indie, entender cómo funciona este proceso puede ser mucho más útil que simplemente copiar una mecánica de Portal.

La pregunta que queremos descubrir hoy es: ¿cómo puede el diseño de niveles enseñar una mecánica sin depender constantemente de textos, tutoriales y ventanas de ayuda?

Enseñar una cosa antes de pedir dos

Portal gira alrededor de una idea aparentemente sencilla: dos portales conectan puntos diferentes del espacio.

Pero comprender realmente esa regla implica aprender muchas cosas.

El jugador necesita entender que puede atravesarlos, que conservan relaciones espaciales, que determinados materiales permiten colocarlos y otros no, que pueden utilizarse para transportar objetos y que el movimiento y la velocidad también pueden formar parte de la solución.

Explicar todo esto mediante una ventana de texto sería fácil.

Conseguir que el jugador lo comprenda utilizándolo es mucho más interesante.

Por eso Portal introduce sus conceptos progresivamente. Primero presenta una situación suficientemente sencilla para concentrar la atención en una sola idea. Cuando esa regla ha sido comprendida, aparece una nueva variable.

Esta técnica parece simple, pero contiene un principio fundamental del diseño:

antes de combinar mecánicas debemos comprobar que el jugador entiende cada una de ellas.

El nivel puede convertirse en profesor

Un buen tutorial no necesariamente necesita decir:

“Ahora debes utilizar esta mecánica.”

Puede construir una situación donde utilizarla sea la conclusión natural.

Portal utiliza sus cámaras de prueba precisamente para eso. El espacio limita las posibilidades del jugador, destaca determinados elementos y permite experimentar dentro de un entorno relativamente controlado.

Una puerta cerrada, un botón, un cubo o una superficie adecuada para colocar un portal dejan de ser simplemente objetos del escenario.

Se convierten en información.

El jugador observa una relación, prueba una hipótesis y descubre una consecuencia.

Cuando funciona, no siente que el diseñador acaba de explicarle la solución. Siente que la ha descubierto.

Y esa diferencia es enorme.

Observar antes de explicar

Una de las claves detrás de Portal fue el playtesting.

Valve comenzó a probar el juego desde etapas muy tempranas del desarrollo. Personas que nunca habían jugado recibían el proyecto y el equipo observaba qué hacían, dónde dudaban y en qué lugares se atascaban.

Eso permitió detectar una diferencia que cualquier desarrollador debería recordar:

que una mecánica sea evidente para quien la diseñó no significa que sea evidente para quien la descubre por primera vez.

El desarrollador conoce las reglas, las soluciones y la intención detrás de cada objeto. Después de trabajar meses con ellas puede resultar casi imposible experimentar el nivel como alguien que nunca lo ha visto.

Por eso observar jugadores reales es tan importante.

Cuando un jugador falla, quizá el problema sea el nivel

Durante el desarrollo de Portal, Valve encontró un ejemplo particularmente interesante.

Un puzzle requería redirigir una bola de energía utilizando portales más de una vez. Para el equipo, la solución tenía sentido.

Para varios jugadores de prueba, no.

Se quedaban bloqueados y la frustración aumentaba.

Valve podía haber añadido una explicación indicando exactamente qué hacer.

En cambio, modificó la progresión.

El concepto fue dividido en situaciones anteriores más sencillas donde el jugador solamente tenía que redirigir la bola una vez. Después de practicar esa relación, podía enfrentarse al problema más complejo con conocimiento previo.

El resultado es una lección extraordinaria:

si muchos jugadores no entienden una mecánica, quizá no necesitemos explicarla mejor; quizá necesitemos enseñarla mejor.

Aprender haciendo cambia la relación con el jugador

Cuando una ventana nos indica qué botón presionar, podemos obedecer sin comprender realmente el sistema.

Cuando necesitamos experimentar para avanzar, debemos construir un pequeño modelo mental.

• ¿Qué ocurre si hago esto?
• ¿Por qué funcionó?
• ¿Podría utilizarlo de otra manera?

Esas preguntas transforman una instrucción en aprendizaje.

Portal puede entonces aumentar gradualmente la complejidad porque las soluciones anteriores se convierten en conocimiento que el jugador lleva consigo.

Una mecánica aprendida deja de ser un obstáculo y empieza a convertirse en una herramienta.

El error también puede enseñar

Existe otra ventaja de los espacios controlados: permiten equivocarse.

Cuando el costo del error es pequeño, experimentar resulta atractivo.

Esto es especialmente importante en juegos donde queremos que el jugador descubra sistemas.

Si probar una idea equivocada implica perder veinte minutos de progreso, probablemente dejará de experimentar. Si puede probar, fallar, comprender el resultado e intentarlo nuevamente en segundos, el error se convierte en información.

Por eso diseñar un tutorial no consiste solamente en preguntarnos cómo enseñaremos la solución.

También debemos preguntarnos:

¿qué aprenderá el jugador cuando se equivoque?

La lección para un desarrollador indie

Los estudios independientes tienen una razón adicional para estudiar este enfoque: normalmente disponen de recursos limitados.

No necesitamos construir cámaras de pruebas como Aperture Science para aplicar sus principios.

Podemos empezar con preguntas mucho más sencillas.

• ¿Estoy introduciendo demasiadas mecánicas simultáneamente?
• ¿Puede el jugador experimentar con una mecánica antes de necesitar dominarla?
• ¿El escenario dirige su atención hacia los elementos importantes?
• ¿El error proporciona información útil?
• ¿Estoy utilizando texto porque realmente es necesario o porque el nivel no comunica suficientemente bien?

Y existe una prueba todavía mejor.

Entregar el juego a alguien que nunca lo haya visto y permanecer en silencio.

• No explicar.
• No señalar.
• No decir: “eso todavía no funciona así”.

Solamente observar.

Cada duda puede revelar un problema de comunicación entre nuestro diseño y el jugador.

Entonces, ¿cómo puede un nivel enseñar sin explicar?

No existe una fórmula única, pero Portal muestra varios principios que podemos reutilizar.

Aislar una idea. Permitir experimentarla. Crear una situación donde sea necesaria. Observar si el jugador la comprende. Después combinarla con algo nuevo.

La dificultad puede crecer sin que la cantidad de instrucciones crezca con ella.

Y aquí aparece quizá la enseñanza más importante del caso.

Un buen tutorial no consigue que el jugador recuerde nuestras instrucciones. Consigue que comprenda las reglas.

Portal no es interesante únicamente porque enseñe a utilizar portales.

Es interesante porque convierte aprender a utilizarlos en parte del propio videojuego.

Para quienes desarrollamos juegos, eso cambia completamente la pregunta.

Antes de añadir otra ventana explicativa, quizá deberíamos mirar nuestro nivel y preguntarnos:

¿podría enseñarlo el juego por sí mismo?

¿Tú qué opinas? ¿Prefieres que un videojuego explique claramente sus mecánicas o descubrirlas mientras juegas?

En CodeAndPlay seguimos estudiando las decisiones invisibles detrás de grandes videojuegos para descubrir qué podemos aprender de ellas y aplicar en nuestros propios proyectos.