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

Serie: Antes de que existiera el videojuego

Tenemos algo.

Después de varios días haciendo pruebas, eliminando ideas y cambiando reglas, nuestra pequeña nave funciona.

Transportar la fuente de energía mientras atravesamos una estación peligrosa genera tensión. Los jugadores prueban diferentes rutas, pierden la carga, vuelven a recogerla y quieren intentarlo otra vez.

Incluso comenzamos a entender qué queremos proteger: vulnerabilidad, riesgo y decisiones.

Hace unos días solamente teníamos una idea.

Ahora tenemos un prototipo divertido.

Y precisamente aquí comienza uno de los momentos más peligrosos de un proyecto indie.

Porque resulta muy fácil pensar:

“Ya tenemos el juego.”

No.

Todavía tenemos que demostrar algo completamente diferente.

Un prototipo puede demostrar que una idea es divertida. No demuestra que podamos convertirla en un videojuego terminado.

Hasta ahora podíamos cambiar prácticamente cualquier cosa

Durante los últimos días hemos disfrutado de un privilegio extraordinario.

Podíamos equivocarnos barato.

Si una mecánica no funcionaba, la eliminábamos. Si una habitación resultaba aburrida, cambiábamos su tamaño. Si una regla generaba un comportamiento inesperado, podíamos reescribirla sin preocuparnos demasiado por aquello que rompíamos.

Eso es precisamente lo que queremos durante el prototipado.

Pero imaginemos ahora que tenemos veinte niveles, enemigos animados, diálogos, música, interfaces, tutoriales y un sistema completo de progresión.

Cambiar una regla fundamental ya no cuesta una tarde.

Puede afectar meses de trabajo.

Por eso necesitamos tomar una decisión antes de construir todo lo demás:

¿estamos suficientemente seguros de los fundamentos como para empezar a construir encima?

Divertido todavía no significa viable

Nuestro prototipo dura diez minutos.

Y funciona.

Pero ahora imaginemos que queremos convertirlo en un videojuego de seis horas.

De repente aparecen preguntas que el prototipo nunca tuvo que responder.

¿La mecánica seguirá siendo interesante después de dos horas? ¿Cuántos escenarios necesitamos? ¿Cómo introduciremos variaciones? ¿Necesitamos nuevos tipos de amenazas? ¿Habrá historia? ¿Quién realizará el arte? ¿Cuánto tiempo tardaremos?

Ninguna de estas preguntas demuestra si la idea es divertida.

Pero todas pueden decidir si el proyecto termina existiendo.

Para un estudio grande, una mala estimación puede significar aumentar presupuesto, retrasar una fecha o reorganizar equipos.

Para un desarrollador indie puede significar simplemente no terminar el videojuego.

Es hora de construir algo que sí se parezca al juego

Hasta ahora defendimos nuestros cuadrados, bloques y gráficos provisionales.

Hoy podemos permitirnos avanzar.

No necesitamos construir seis horas de contenido. Necesitamos construir una pequeña sección capaz de representar aquello que pretendemos conseguir.

Aquí aparece un concepto habitual en desarrollo: el vertical slice.

Podemos imaginarlo como una pequeña porción del videojuego que intenta conectar sus diferentes capas con un nivel de calidad mucho más cercano al objetivo final.

Nuestra nave finalmente puede tener un modelo. La estación puede recibir iluminación. Podemos trabajar en sonido, interfaz, animaciones y efectos mientras conservamos las mecánicas que ya hemos validado.

La pregunta cambia nuevamente.

Ya no estamos preguntando únicamente:

“¿Esto es divertido?”

Ahora queremos descubrir:

“¿Podemos producir esta experiencia con la calidad, el tiempo y los recursos que tenemos?”

Y quizá descubramos que todavía es demasiado grande

Construimos nuestra pequeña sección.

Funciona.

Pero tardamos seis semanas cuando imaginábamos que tardaríamos dos.

Eso también es información.

Si necesitamos seis semanas para producir una zona y nuestro diseño contempla veinte zonas similares, tenemos un problema que ninguna cantidad de entusiasmo resolverá.

Podemos contratar ayuda si tenemos presupuesto.

Podemos buscar herramientas que aceleren el proceso.

Pero también podemos tomar una decisión mucho menos emocionante:

hacer un videojuego más pequeño.

Reducir alcance no necesariamente significa reducir calidad.

Puede significar concentrar nuestros recursos en aquello que realmente hace especial al proyecto.

El alcance también forma parte del diseño

Existe una tendencia natural a pensar que diseñar consiste en decidir mecánicas, niveles y sistemas, mientras que el presupuesto y el calendario pertenecen a otra conversación.

Para un desarrollador independiente, separarlos demasiado puede ser peligroso.

Si solamente podemos crear cinco escenarios realmente buenos, diseñar un juego que necesita cincuenta no es una visión ambiciosa.

Es una contradicción.

Nuestros recursos también son una regla del proyecto.

Y, curiosamente, las limitaciones pueden ayudarnos a encontrar mejores soluciones.

Quizá nuestra estación no necesite veinte zonas completamente diferentes. Tal vez podemos hacer que un espacio conocido cambie dependiendo del estado de la energía. Puede que regresar por lugares anteriores bajo nuevas condiciones produzca exactamente la tensión que buscamos.

Acabamos de transformar una limitación de producción en una decisión de diseño.

Mito o realidad

Mito: cuando encontramos una mecánica divertida debemos comenzar inmediatamente a construir el videojuego completo.

Realidad: una mecánica divertida demuestra solamente una parte del problema. Antes de comprometernos necesitamos entender si podemos convertir esa experiencia en suficiente contenido con los recursos disponibles.

El prototipo reduce el riesgo de diseño.

Una prueba de producción empieza a revelar otro riesgo:

si somos capaces de terminar aquello que estamos imaginando.

¿Cuándo dejamos entonces de experimentar?

Quizá nunca completamente.

Incluso durante producción aparecerán ideas nuevas y descubriremos problemas que obligarán a cambiar algunas decisiones.

La diferencia es que ya no queremos cuestionar todos los días la razón fundamental por la que existe el proyecto.

Sabemos qué experiencia estamos intentando construir.

Sabemos cuáles son sus mecánicas centrales.

Hemos observado a otras personas jugar.

Y hemos construido una pequeña parte que empieza a mostrarnos cuánto cuesta producirla.

Ahora nuestras preguntas son diferentes.

Ya no estamos buscando desesperadamente el juego.

Estamos intentando terminarlo.

Hay una última tentación antes de comenzar

Podríamos seguir prototipando.

Una semana más.

Quizá aparezca una idea todavía mejor.

Después otra.

Siempre existe algo que podemos probar.

Y esto revela que el prototipado también puede convertirse en refugio.

Mientras experimentamos, no tenemos que enfrentarnos a algunas de las partes menos emocionantes de producir un videojuego: crear contenido, corregir errores, repetir procesos, optimizar, probar y terminar.

En algún momento necesitamos aceptar que nuestro juego probablemente nunca será perfecto.

Pero puede ser terminado.

Comenzar producción significa dejar de buscar todas las versiones posibles del videojuego y comprometernos con una que realmente podemos construir.

Hace cuatro días nuestra nave era solamente una idea.

Después se convirtió en un cuadrado que podía transportar otro objeto.

Descubrimos una interacción interesante. Evitamos esconderla demasiado pronto detrás de producción costosa. Eliminamos mecánicas que nos alejaban de aquello que queríamos conseguir.

Y ahora sabemos algo más.

No solamente queremos hacer este videojuego.

Empezamos a entender cómo podríamos terminarlo.

Esa diferencia es enorme.

Porque muchos proyectos pueden tener una buena idea.

Algunos consiguen un prototipo divertido.

Pero un videojuego publicado necesita algo adicional: decisiones suficientes para convertir posibilidades infinitas en un proyecto finito.

Nuestra nave sigue sin nombre.

Mañana tendrá que ganárselo.

Mañana cerramos esta serie en CodeAndPlay

Durante cuatro días hemos acompañado una idea desde aquella primera conversación hasta el momento en que podría comenzar producción.

Mañana no quiero simplemente resumir lo aprendido.

Vamos a utilizarlo.

Viernes: Tenemos una idea para un videojuego: vamos a ponerla a prueba.

Tomaremos nuestro pequeño proyecto y lo someteremos a las preguntas que hemos descubierto durante toda la semana.

¿Existe realmente una mecánica central? ¿Sobrevive sin producción espectacular? ¿Sabemos qué debemos dejar fuera? ¿Tenemos una escala razonable? ¿Podríamos convertirla en un videojuego terminado?

Y solamente entonces tomaremos la decisión que hemos pospuesto desde el lunes:

¿este videojuego merece existir?