¿Quién decide qué se queda? El difícil arte de eliminar buenas ideas de un videojuego

Serie: Antes de que existiera el videojuego

Tenemos un problema.

Y, curiosamente, es una buena señal.

Nuestro pequeño prototipo de la nave y la fuente de energía funciona. Los jugadores recogen la carga, intentan atravesar la estación y esquivan a las criaturas que quieren arrebatársela.

Pero durante las pruebas comenzaron a ocurrir cosas.

Alguien preguntó si podía soltar la energía para escapar más rápido. Otro quiso lanzarla contra un enemigo. Después imaginamos puertas que necesitarían parte de esa energía para abrirse. Y quizá podríamos permitir que la nave mejorara sus capacidades dependiendo de cuánta energía consiguiera conservar.

Todas parecen buenas ideas.

Ese es precisamente el problema.

Uno de los momentos más difíciles al crear un videojuego llega cuando debemos eliminar algo no porque sea malo, sino porque el juego puede ser mejor sin ello.

Las buenas ideas también pueden destruir un proyecto

Es fácil rechazar una mecánica aburrida.

La probamos, descubrimos que no funciona y seguimos adelante.

Pero imaginemos que programamos la posibilidad de lanzar nuestra fuente de energía contra los enemigos.

La probamos.

Es divertida.

Ahora podemos calcular trayectorias, golpear criaturas e incluso hacer rebotar la energía contra las paredes.

De repente empezamos a imaginar diferentes tipos de enemigos, superficies especiales y habilidades para modificar los lanzamientos.

Acabamos de encontrar una buena mecánica.

Pero también acabamos de abrir la puerta hacia otro videojuego.

¿De qué trata realmente nuestro juego?

Esta pregunta parece sencilla hasta que necesitamos responderla.

Nuestro prototipo comenzó intentando descubrir si transportar algo valioso mientras alguien intenta quitárnoslo puede generar decisiones interesantes.

Eso produce tensión.

Queremos llegar al destino, pero cargar la energía nos hace vulnerables. Podemos elegir rutas distintas, arriesgarnos o quizá abandonar temporalmente aquello que intentamos proteger.

Si convertimos esa energía en un arma extremadamente poderosa, algo cambia.

Quizá el jugador deja de pensar:

“¿Cómo consigo proteger esto?”

y empieza a pensar:

“¿A quién puedo golpear con esto?”

Las dos preguntas podrían producir juegos divertidos.

Pero no necesariamente producen el mismo juego.

Ahí empieza a aparecer la identidad

Hasta ahora nuestro prototipo era una herramienta para hacer preguntas.

Pero después de suficientes pruebas empieza a responder algunas.

Descubrimos que aquello que más nos interesa no es combatir.

Es la vulnerabilidad.

Nos gusta ver al jugador cargando algo importante mientras evalúa el peligro. Nos interesa ese momento en que debe decidir si continuar, cambiar de ruta o abandonar temporalmente aquello que intenta llevar hasta el final.

Acabamos de encontrar algo que puede convertirse en una regla para nuestras siguientes decisiones.

No una lista de características.

Una intención.

Queremos que transportar la energía genere tensión y decisiones.

Ahora podemos regresar a cada nueva idea y hacerle una pregunta mucho más útil:

¿fortalece esa experiencia o empieza a convertir el proyecto en otra cosa?

Eliminar una mecánica no significa perderla

Supongamos que finalmente decidimos eliminar el lanzamiento ofensivo.

Duele un poco.

Funcionaba.

Incluso podemos imaginar a alguien diciendo: “era mi parte favorita”.

Pero eliminarla del proyecto actual no convierte la idea en basura.

Podemos conservar el experimento, documentarlo y quizá utilizarlo en otro proyecto. Incluso podría regresar más adelante si descubrimos una forma de integrarlo sin destruir aquello que estamos intentando proteger.

Lo importante es no confundir dos decisiones diferentes.

“Esta idea es buena” no significa automáticamente “esta idea debe estar en este videojuego”.

Esa distinción puede ahorrar meses de desarrollo.

Cada mecánica nueva trae amigos

Aquí aparece algo especialmente importante para un proyecto indie.

Una mecánica casi nunca llega sola.

Si añadimos combate, probablemente necesitaremos enemigos capaces de responder a él. Después tendremos que equilibrar daño, resistencia y dificultad. Quizá necesitaremos animaciones, efectos, sonidos, interfaz y tutoriales.

Y todo eso tendrá que probarse.

Una pequeña decisión de diseño puede convertirse silenciosamente en semanas de producción.

Por eso el costo real de una idea no debería medirse únicamente por cuánto tardamos en programarla.

También debemos preguntarnos cuánto contenido exige, cuántos problemas nuevos introduce y cuánto trabajo añadirá durante el resto del proyecto.

Para un equipo pequeño, esa pregunta puede decidir si el videojuego termina existiendo.

El jugador también puede pedirnos el juego equivocado

Probamos nuevamente nuestro prototipo.

Uno de los jugadores insiste en que deberíamos recuperar el lanzamiento de energía. Otro quiere armas. Alguien más propone multijugador.

Son comentarios valiosos.

Pero escuchar al jugador no significa implementar literalmente cada cosa que solicita.

Lo interesante está detrás de la petición.

Quizá quien pide lanzar la energía realmente quiere más formas de reaccionar cuando queda atrapado. Entonces el problema que debemos resolver no es necesariamente “necesitamos combate”.

Podría ser:

“el jugador necesita una decisión interesante cuando no puede escapar”.

Eso abre soluciones completamente diferentes.

El feedback nos ayuda a encontrar problemas.

El diseño decide cómo resolverlos.

Mito o realidad

Mito: eliminar contenido significa que desperdiciamos el tiempo utilizado para crearlo.

Realidad: si una prueba nos permite descubrir qué juego no queremos construir, ese trabajo también produjo información.

El verdadero desperdicio puede ser mantener durante meses una mecánica solamente porque ya invertimos tiempo en ella.

Un prototipo existe precisamente para permitirnos tomar estas decisiones cuando todavía son relativamente baratas.

Ahora nuestro juego es más pequeño... pero sabemos más sobre él

Al terminar el día tenemos menos cosas.

Eliminamos el combate.

Descartamos algunas mejoras.

Dejamos varias ideas guardadas para otro momento.

Pero algo extraño ocurrió.

Nuestro videojuego empieza a resultar más fácil de explicar.

Controlamos una pequeña nave que debe transportar una fuente de energía a través de un lugar peligroso. Mientras la llevamos somos vulnerables y debemos decidir constantemente cuánto riesgo estamos dispuestos a aceptar para avanzar.

Ya no estamos describiendo veinte características.

Estamos describiendo una experiencia.

Un videojuego empieza a encontrar su identidad no solamente cuando decidimos qué agregar, sino cuando entendemos qué estamos dispuestos a dejar fuera para protegerla.

Crear produce una sensación agradable.

Eliminar rara vez la produce.

Por eso es tan fácil que un proyecto crezca.

Cada nueva mecánica parece una mejora. Cada sistema adicional parece acercarnos a un videojuego más completo.

Hasta que un día descubrimos que tenemos muchas cosas funcionando, pero ya no sabemos exactamente qué estamos intentando construir.

El criterio no consiste únicamente en reconocer buenas ideas.

También consiste en saber cuáles pertenecen aquí.

Y algunas de las mejores ideas que tendremos durante un proyecto quizá necesiten convertirse en el comienzo de otro.

Nuestra nave sigue sin nombre.

Pero después de tres días acaba de conseguir algo bastante más importante.

Empieza a tener identidad.

Continúa esta semana en CodeAndPlay

El lunes descubrimos que una idea necesita sobrevivir a un prototipo. El martes evitamos esconderla demasiado pronto detrás de gráficos y producción. Hoy empezamos a eliminar aquello que distraía de la experiencia que realmente queremos construir.

Y eso nos deja frente a una nueva decisión.

Mañana: De prototipo a videojuego: el momento en que una prueba divertida necesita convertirse en un proyecto real.

Porque nuestro pequeño experimento ya funciona, alguien quiere volver a jugarlo y empezamos a entender su identidad.

Pero todavía falta responder la pregunta que puede costarnos meses —o años— de trabajo:

¿cómo sabemos cuándo debemos dejar de experimentar y comprometernos realmente a terminarlo?