El primer salto de un prototipo: observar antes de explicar

El personaje llega al borde de una plataforma y se queda quieto. Quien lo ha programado conoce el salto; quien acaba de sentarse ante el teclado, quizá no. Si el equipo dice enseguida «pulsa espacio», la partida continúa, pero se pierde una pregunta útil: ¿el prototipo enseñaba esa acción por sí mismo?

En una game jam, donde queda poco tiempo para decidir qué cambiar, ese primer atasco merece una observación precisa. No demuestra todavía que el nivel sea difícil. Puede señalar un control que nadie ha descubierto, una distancia mal calculada o un fallo que impide saltar. Cada explicación lleva a una modificación distinta.

Los encuentros de creación que hemos descrito al hablar de Game Island Jam y sus prototipos ponen en común ideas y equipos. La prueba con alguien ajeno al desarrollo añade otra perspectiva: comprobar qué comunica el juego cuando sus autores dejan de narrarlo.

Dejar espacio para que aparezca el problema

Antes de comenzar, acuerda una tarea pequeña: llegar desde el inicio hasta la siguiente plataforma. Explica que se está probando el juego, no la habilidad de la persona. Si el prototipo necesita instrucciones iniciales, ofrece las que recibiría cualquier jugador; no añadas un recorrido verbal exclusivo para esta sesión.

La persona que observa se coloca a un lado, con la pantalla visible, y deja el teclado a quien juega. Conviene anotar acciones concretas: se acerca al borde, prueba una tecla, retrocede, vuelve a intentarlo. «No entiende nada» es una valoración demasiado amplia para decidir qué cambiar.

La orientación de Unity sobre las sesiones de prueba recomienda observar y registrar lo que sucede, además de preparar las preguntas. Ese silencio inicial tiene un límite razonable: si la persona quiere parar o necesita ayuda para continuar, se la das y apuntas en qué momento intervino el equipo.

El mismo hueco, tres decisiones distintas

Imaginemos que el personaje cae varias veces. El resultado visible es parecido, pero estos tres relatos no son intercambiables:

«No sabía que podía saltar». Antes de ensanchar plataformas, revisa cómo se presenta la acción. Puede faltar una indicación, una oportunidad segura para descubrirla o una respuesta visible cuando se pulsa el control. La siguiente prueba debe comprobar esa comunicación.

«Sabía cómo saltar, pero llegaba tarde». Aquí sí tiene sentido observar la distancia, el momento del salto y la recuperación después de caer. Cambiar una de esas condiciones permite explorar la dificultad sin rehacer todo el nivel de golpe.

«Pulsaba la tecla y a veces no pasaba nada». Antes de atribuirlo a la destreza, intenta reproducir la situación. Anota desde dónde salta, si el personaje acaba de aterrizar y qué controles mantiene pulsados. Es información para investigar un posible fallo, no una prueba de que exista uno.

Al cerrar la sesión, pregunta qué esperaba que ocurriera en el punto donde se detuvo. Una pregunta sobre ese instante aporta más que pedir una nota global al juego. También ayuda a separar lo observado de la explicación que el equipo había supuesto.

Conserva una decisión pequeña para la siguiente versión: aclarar una acción, ajustar un salto o investigar una respuesta irregular. Después prueba el mismo tramo con otra persona. El objetivo de esta primera sesión no es conseguir que todo el mundo termine, sino saber qué merece la siguiente hora de trabajo.