🦍 El trabajo habitual de un equipo de control de calidad consiste en impedir que los jugadores rompan el juego. En Donkey Kong Bananza ocurrió lo contrario: había que garantizar que se pudiera destruir absolutamente todo y, después, lograr que los escombros siguieran siendo un lugar habitable. En la CEDEC 2026, dos programadores de Nintendo explicaron cómo funcionó esa inversión y hasta dónde llegaron a conservar los errores que encontraron.

Un juego sobre destruir se destruye a sí mismo

Donkey Kong Bananza salió a la venta el 17 de julio de 2025 para Nintendo Switch 2. Es el primer título original de la serie desde Donkey Kong Country: Tropical Freeze (2014) y el primer plataformas en tres dimensiones desde Donkey Kong 64. Su promedio de crítica en OpenCritic es de 91. En los premios CEDEC AWARDS 2026, el equipo de desarrollo se llevó los galardones máximos en Ingeniería, Diseño de Juego y Artes Visuales, y como el equipo de Nintendo Music ganó la categoría de Sonido, Nintendo acabó copando las cuatro.

CEDEC es la mayor conferencia de desarrolladores de videojuegos de Japón y la organiza CESA, la asociación del sector. Este año se celebró del 22 al 24 de julio en el recinto Pacifico Yokohama North y en formato en línea. Bananza tuvo cuatro sesiones dedicadas a su concepto central desde ángulos distintos: tecnología, arte, diseño de juego y control de calidad. La sesión de QA se impartió el 24 de julio a cargo de Tatsuya Kurihara, responsable de la programación técnica principal y del trabajo con vóxeles, y de Fukuhei Hamazaki, encargado de la programación de objetos y del QA.

La base técnica son los vóxeles, es decir, píxeles tridimensionales. El terreno, los enemigos y hasta los personajes secundarios están construidos con ellos, y por eso un puñetazo arranca solo la parte que ha golpeado. También por eso se puede desgajar un trozo de suelo y lanzarlo a otro sitio para fabricar una plataforma.

Entonces se le entrega eso a un equipo de evaluadores y todo empieza a fallar. Basta con colarse por una grieta estrecha abierta al excavar para que las colisiones cedan y Donkey Kong atraviese el mapa en una caída infinita. Destruir demasiado a la vez castiga la tasa de imágenes por segundo. Los polígonos se rompen y dejan repisas invisibles flotando en el aire.

No evitar la fuga, sino diseñar lo que viene después

La solución que elegiría casi cualquier estudio es una norma. De hecho, en Super Mario Odyssey, obra en buena medida del mismo equipo, existía una: todo terreno con forma de uve debía taparse para que ningún personaje quedara encajado en el pliegue.

Ese método se viene abajo en cuanto los jugadores pueden generar terreno por su cuenta. Por mucho cuidado que pongan los diseñadores de niveles, quien fabrica la geometría problemática es el jugador. Y limitar la deformación del terreno equivaldría a vaciar el juego de su razón de ser.

Así que el equipo dejó de intentar evitar las fugas y pasó a diseñar qué ocurre después de ellas. Si el personaje va a atravesar una superficie, lo importante es por qué lado sale. Caer a través del suelo es catastrófico; salir por el techo es recuperable. Si queda atrapado entre un muro móvil y uno fijo, se le expulsa por el lado móvil. Si queda entre un vóxel y un objeto que no lo es, sale por el lado del vóxel. Y en cuanto aparece donde no debería, los vóxeles que lo rodean se destruyen de forma automática y abren espacio suficiente para que la física vuelva a estabilizarse.

El error no se evita. Simplemente se le prepara un aterrizaje.

Construir dando por hecho que se saltarán tu juego

La misma lógica se aplicó al avance. Bananza plantea una progresión por fases, pero quien puede arrancar terreno y lanzarlo es capaz de tender un puente hasta una plataforma lejana, pasar de largo ante un jefe y aterrizar directamente en la zona siguiente.

La respuesta evidente sería un muro invisible, y se descartó por ser una restricción más: encontrar una ruta y que el juego te diga que no cuenta es justo lo contrario de divertirse. El equipo de QA decidió que los saltos de secuencia eran aceptables mientras resultaran divertidos, y que su verdadera tarea consistía en evitar que algo se rompiera más adelante. Si se esquiva a un jefe, se puede combatir después y la recompensa sigue estando ahí. Si se salta un evento, lo que se cambia es el diálogo que daba por visto ese evento, para que nadie que se haya adelantado sin querer se quede con la duda de haber estropeado algo.

El caso extremo afectaba a las propias transformaciones Bananza. El diseño contempla aprender cinco a lo largo de la partida, pero jugando con habilidad se puede llegar al final con solo dos. El problema era que el contenido posterior a los créditos daba por supuestas las cinco. En lugar de cerrar el atajo, el equipo añadió un evento en el desenlace que entrega de golpe las transformaciones que falten. El diálogo que lo acompaña hace que se perciba más como una recompensa oculta que como un parche.

En las comunidades de speedrunning hay una broma recurrente: cada vez que un juego aguanta una ruta que nadie habría anticipado, alguien pregunta si los desarrolladores lo habían previsto. En este caso, al menos, la respuesta quedó dicha en voz alta.

La destrucción, por lo demás, es permanente, y el paisaje conserva el registro de lo que se ha hecho con él. Hay excepciones. Al pelear contra un jefe que destroza el suelo, la arena acaba siendo irreconocible y reintentar resulta injustamente difícil. Por eso en esos lugares, incluidos los puentes derrumbados, se restaura solo lo imprescindible cuando el jugador vuelve, y ese comportamiento lo configuran los diseñadores en el editor de niveles.

Meter a los evaluadores dentro del equipo

Con el rendimiento se procedió igual, renunciando a sacrificar la destrucción. Como romper cosas sale caro, todo lo demás tenía que abaratarse. Cada fase contó con su propio equipo de optimización formado por programadores, artistas y diseñadores de niveles, apoyado por esferas colocadas en el escenario que muestran dónde se dispara la carga, listados de carga por objeto legibles sin conocimientos de motor y un boletín interno con el ranking de las fases más pesadas y su evolución. El avance se volvió visible y las fases empezaron a compararse entre sí de forma productiva.

La decisión sobre el personal es quizá la parte más aprovechable de la charla. Las pruebas de Nintendo las realiza Mario Club Co., Ltd., filial al cien por cien fundada en julio de 2009, con sede en el barrio de Higashiyama, en Kioto, y 432 empleados a fecha del 16 de septiembre de 2025. Bananza, en cambio, se desarrollaba en Tokio. Los evaluadores principales fueron trasladados allí en comisión de servicio e integrados en el equipo como miembros de pleno derecho, no como proveedor externo.

Eso cambió la naturaleza de las pruebas. Los evaluadores asistían a las reuniones de desarrollo y entendían por qué existía cada especificación, no solo qué decía. Las dudas iban directamente a quien había implementado algo, en lugar de acabar en una incidencia. Con el editor de niveles a mano podían ver qué tipo de juego se había previsto y salir a cazar los puntos con más probabilidad de romperse, y construían y mantenían sus propias fases de prueba.

Las herramientas de depuración llegaron pronto: añadir, excavar, restaurar o borrar vóxeles, cambiar los materiales de superficie y controlar a Donkey Kong mediante scripts para reproducir errores demasiado precisos como para lograrlos a mano. Una batería automática recorría el juego entero mediante saltos, destruía el terreno donde hacía falta, reproducía las escenas y completaba los objetos coleccionables; los errores detectados se corregían ese mismo día. Parte de ese instrumental terminó incorporándose a DK Artist, el modo de creación dentro del juego.

El concurso: ¿corregir o conservar?

Kurihara y Hamazaki cerraron con tres casos reales planteados como concurso.

El primero, un puente de hielo fino pensado para cruzarse a toda velocidad con la transformación Zebra Bananza. Un evaluador arrancó la nieve cercana, la lanzó sobre el puente y cruzó por encima de la plataforma improvisada, sin transformarse. Se conservó, porque encontrar una solución propia resulta más interesante que ejecutar la que escribieron los diseñadores.

El segundo, un jefe al que se combate desde una vagoneta lanzándole bombas al núcleo. Un evaluador arrancó trozos del terreno, se fabricó una plataforma, se acercó y lo derrotó a corta distancia. También se conservó, aunque generó un efecto colateral: el viaje rápido está desactivado mientras se va en la vagoneta, de modo que quien no la usara podía teletransportarse antes de que terminara la secuencia de victoria. El equipo no eliminó el atajo, solo bloqueó el viaje rápido durante los instantes posteriores a la derrota del jefe.

El tercero, una fase de carreras en la que ganar te sube a un trofeo gigante y abre el camino. Con la transformación adecuada se puede volar directamente hasta el trofeo. Se conservó igualmente, con el argumento de que saltarse la carrera en el nivel de carreras tiene su gracia. Lo único que se retocó fue el diálogo posterior, que celebraba con entusiasmo una carrera que el jugador no había corrido. Ahora pregunta si de verdad no quería ganarla antes.

Restar lo negativo y ampliar lo positivo

Los tres principios que el equipo fijó al principio fueron: que destruir resultara seguro y divertido, que las restricciones no se acumularan y que todo lo que fuera genuinamente entretenido se mantuviera. Kurihara y Hamazaki lo resumieron como un control de calidad que no se limita a restar lo negativo, sino que amplía lo positivo. Es una descripción del puesto bastante distinta de la que redactan casi todos los estudios.

También es una filosofía que los desarrolladores de fuera de Japón rara vez pueden leer completa. Las sesiones de CEDEC se imparten sobre todo en japonés y la cobertura en otros idiomas suele quedarse en los premios. La distancia es una lástima en este caso, porque el argumento de fondo no va de vóxeles, sino de a quién pertenece un error. Cuando un evaluador encuentra algo que nadie había planeado, casi todos los procesos lo tratan como un informe de defecto. Aquí se trató como una propuesta.

En Japón, la discusión en torno a esta charla tiene menos que ver con Donkey Kong que con si algo así sobrevive fuera de un estudio con los recursos de Nintendo y con una relación tan estrecha con su propia filial de control de calidad. ¿Hacia qué lado se inclina la balanza en tu país? Los equipos que conoces, ¿publican los accidentes afortunados o los archivan como incidencias?

参照