¿Cuánto debe explicar un videojuego? El arte de confiar en el jugador

Imagina que un jugador entra por primera vez en nuestro videojuego.

No conoce los controles. No comprende nuestras reglas. No sabe qué objetos son importantes ni qué peligros encontrará más adelante.

Como desarrolladores sentimos inmediatamente una tentación:

explicárselo todo.

Una ventana describe los controles. Otra explica la primera mecánica. Una flecha señala el camino. Un personaje recuerda el objetivo y un marcador indica exactamente dónde debemos llegar.

El jugador difícilmente podrá perderse.

Pero quizá también acabamos de quitarle algo importante: la posibilidad de descubrir.

Durante esta semana analizamos cuatro videojuegos muy diferentes —Portal, Left 4 Dead, Subnautica y Return of the Obra Dinn— que comparten una característica: sus diseñadores saben que no toda la información debe entregarse de la misma manera.

La pregunta que queremos descubrir hoy es: ¿cómo encontrar el equilibrio entre enseñar, orientar y permitir que el jugador descubra las reglas por sí mismo?

El problema no es explicar

Eliminar todas las explicaciones tampoco produce automáticamente un mejor diseño.

Si el jugador no comprende los controles básicos, probablemente sentirá frustración. Si no puede identificar información esencial de la interfaz, el problema no es misterio: es comunicación.

Por eso la pregunta correcta no debería ser:

“¿Debemos explicar esto?”

Sino:

“¿Cómo debería aprender esto el jugador?”

Algunas cosas necesitan explicarse claramente. Otras pueden enseñarse mediante una situación. Algunas pueden sugerirse y otras deberían permanecer ocultas hasta que el jugador las descubra.

Diseñar esa diferencia forma parte de la experiencia.

Portal: enseñar mediante situaciones

Esta semana comenzamos con Portal.

Valve tenía que enseñar una mecánica espacial poco habitual: dos portales conectados capaces de transformar la forma en que entendemos el movimiento y el espacio.

Podría haber explicado todas sus reglas mediante textos.

En cambio, sus cámaras de prueba aíslan conceptos, permiten experimentar con ellos y posteriormente los combinan.

El nivel se convierte en profesor.

La enseñanza que podemos extraer es sencilla:

si una regla puede comprenderse utilizándola, quizá no necesitamos describirla antes de que el jugador pueda experimentarla.

Left 4 Dead: algunos sistemas no necesitan ser visibles

Después analizamos Left 4 Dead y su AI Director.

El jugador no necesita conocer todos los cálculos que determinan cuándo aumenta la presión, cuándo aparecen determinadas amenazas o cuándo el juego permite respirar al grupo.

Simplemente experimenta sus consecuencias.

Esto introduce una segunda categoría de información:

cosas que el jugador necesita sentir, pero no necesariamente conocer.

Mostrar cada sistema puede incluso destruir parte de su efecto.

Si pudiéramos ver un indicador diciendo que dentro de veinte segundos llegará una horda porque nuestra tensión actual es demasiado baja, buena parte de la incertidumbre desaparecería.

La transparencia no siempre mejora una experiencia.

Subnautica: orientar sin revelar

Con Subnautica encontramos un problema diferente.

El jugador necesita alguna dirección. Sin ella, un océano enorme podría convertirse simplemente en desorientación.

El juego proporciona señales, objetivos, recursos y pistas que nos empujan hacia nuevas regiones.

Pero no explica todo lo que encontraremos durante el camino.

Existe suficiente información para crear una intención y suficiente incertidumbre para despertar curiosidad.

Ahí aparece un tercer principio:

orientar no significa revelar.

Podemos decirle al jugador dónde podría existir algo interesante sin explicarle exactamente qué encontrará.

Obra Dinn: entregar evidencias, no conclusiones

Return of the Obra Dinn lleva esta confianza todavía más lejos.

Su mecánica fundamental consiste precisamente en evitar entregar conclusiones.

El juego proporciona escenas, conversaciones, rostros, posiciones y documentos. El jugador debe construir relaciones entre esas piezas.

Si una interfaz identificara automáticamente cada pista importante, resolvería precisamente aquello que hace interesante al juego.

Pero Obra Dinn tampoco abandona al jugador.

Proporciona un libro que organiza la enorme cantidad de información disponible.

Y ahí encontramos una diferencia fundamental:

ayudar al jugador a manejar información no significa interpretar esa información por él.

Entonces, ¿qué debemos explicar?

Los cuatro casos permiten construir una regla práctica.

Antes de añadir una explicación podemos clasificar la información según su función.

  • Necesita saberlo: información esencial para controlar y utilizar correctamente el juego.
  • Necesita aprenderlo: reglas que pueden comprenderse mejor experimentándolas.
  • Necesita sentirlo: sistemas que funcionan mejor cuando sus mecanismos permanecen detrás de la experiencia.
  • Necesita descubrirlo: información cuya búsqueda forma parte de la recompensa.

Esta clasificación cambia completamente nuestra forma de diseñar tutoriales.

No toda la información merece una ventana.

El peligro de explicar demasiado

Cuando explicamos una solución antes de que exista un problema, el jugador todavía no tiene una razón para recordarla.

Cuando marcamos constantemente el camino, dejamos poco espacio para observar el escenario.

Cuando identificamos automáticamente cada elemento importante, reducimos el valor de prestar atención.

Y cuando respondemos inmediatamente cada pregunta, eliminamos la curiosidad que podría haber impulsado al jugador hacia adelante.

Explicar demasiado puede producir una experiencia perfectamente comprensible pero sorprendentemente pasiva.

El peligro contrario: confundir confianza con abandono

Pero también podemos equivocarnos en la dirección contraria.

Ocultar información esencial no significa confiar en el jugador.

Un objetivo incomprensible, una interfaz ilegible o una mecánica sin feedback pueden generar frustración, no descubrimiento.

La diferencia puede detectarse observando qué pregunta se hace el jugador.

Existe una enorme distancia entre:

“¿Cómo puedo resolver esto?”

y:

“¿Qué quiere el juego que haga?”

La primera pregunta puede ser exactamente la experiencia que buscamos.

La segunda puede indicar que todavía no hemos comunicado correctamente el problema.

La prueba más importante para un desarrollador indie

Existe una herramienta extraordinariamente barata para comprobar este equilibrio:

observar a otra persona jugar.

Sin ayudarla.

Si no comprende algo, resistamos la tentación de explicárselo inmediatamente.

Observemos dónde miró, qué intentó hacer y qué conclusión obtuvo.

Después debemos preguntarnos si necesitamos añadir texto o si podemos modificar el escenario, el feedback, la secuencia o la presentación para comunicar mejor la idea.

Muchas veces el problema no necesita otra explicación.

Necesita mejor diseño.

¿Cuánto debe explicar entonces un videojuego?

Lo suficiente para que el jugador pueda tomar decisiones con intención.

Pero no tanto como para tomar esas decisiones por él.

Portal nos enseña a permitir que experimente.

Left 4 Dead demuestra que algunos sistemas funcionan mejor cuando permanecen invisibles.

Subnautica utiliza información incompleta para convertir curiosidad en movimiento.

Obra Dinn demuestra que una respuesta puede convertirse en una recompensa.

Cuatro juegos diferentes y una misma idea:

confiar en el jugador no significa dejarlo solo. Significa darle las herramientas necesarias y permitirle hacer el resto.

Quizá antes de escribir el próximo tutorial deberíamos preguntarnos:

¿qué necesita saber realmente el jugador y qué sería mucho más interesante que descubriera por sí mismo?

¿Tú qué opinas? ¿Qué videojuegos recuerdas por confiar en ti como jugador y cuáles sentiste que explicaban demasiado?

En CodeAndPlay seguimos estudiando las decisiones detrás de grandes videojuegos para convertirlas en ideas que podamos aplicar en nuestros propios proyectos.