Es casi imposible imaginar el juego Ape Out sin un simio. Y, a pesar de eso, así fue exactamente como tomó vida. De acuerdo al desarrollador Gabe Cuzzillo, se suponía que iba a ser un juego de sigilo con bucles temporales donde podrías usar mecánicas de empuje y agarre para escabullirte por las paredes. Pero, si iban a haber guardias en el juego, naturalmente deberías poder usar esas mismas mecánicas en ellos, lo que llevó a gameplay que te deja tener a los guardias como rehenes y arrojarlos a las paredes. Ésto resultó ser la parte más interesante del juego, así que Gabe decidió cambiar la dirección salvajemente y construir el juego alrededor de este concepto central. Eliminó todo lo que no tenía que estar ahí, como el sigilo y los bucles temporales. E hizo lo que fuera para enfatizar esta idea —más notoriamente, cambiando al tipo calvo por un furioso gorila de 140 kilos—. Esto es un ejemplo de una metodología de diseño de juegos llamada "Sigue la diversión". Es la engañosamente simple idea de que los diseñadores deben ingnorar sus planes e ideas preconcebidas y, en su lugar, observar el juego para encontrar hacia donde debe orientarse el desarrollo. Así que toma a la gema de tácticas microscópicas, Into the Breach. La vida de este juego empezó como un juego estilo Advance Wars bastante estándar, donde los enemigos escogían atacar al azar y ocultar sus intenciones hasta su turno. Pero un enemigo en el juego mostraba exactamente lo que estaba por hacer en su turno al resaltar el cuadro al que iba a atacar. Los desarrolladores en Subset se dieron cuenta que esto era la parte más disfrutable, así que decidieron enfocar el resto del juego casi exclusivamente a estos ataques telegrafiados. Y, de hecho, esto ayudó a guiar el resto de decisiones de diseño que el estudio tuvo que hacer. Porque, si sabes lo que los enemigos van a hacer, ¿no o puedes sólo mover tus unidades fuera de su zona de ataque? De acuerdo, quizá el juego es en realidad acerca de proteger edificios estáticos. Y, así, ahora se trata de empujar a los enemigos alrededor para que sus ataques fallen. Pero, de hecho, puedes usar ésto para engañar a los enemigos para que se maten entre ellos. Probablemente puedes ver por qué los diseñadores que usan este método a menudo dice que su juego, hasta cierto punto, se diseña a sí mismo. Aquí está Sam Coster del desarrollador de Chrashlands, Butterscotch Shenanigans. SAM COSTER: "Nos gusta pensar en este proceso como el juego mismo descubriéndose en el tiempo. "Porque como iteradores, en lugar de diseñadores, es nuestro trabajo simplemente jugar el juego, "esucharlo, sentirlo, y, de algún modo, tantear lo que parece que quiere convertirse "y sólo seguir las huellas de lo que es divertido." Ahora, la idea de un juego que se diseña a sí mismo es más bien emocionante para aquellos que buscan hacer el siguiente gran éxito. Pero no es como si grandes ideas de juego sólo aparecieran de la nada. Así que, ¿de dónde vienen? Bueno, miremos los orígenes del roguelike basado en ritmo, Crypt of the Necrodancer. El diseñador, Ryan Clark, quería ver si podía poner la rápida toma de decisiones de Spelunky en un dungeon crawler por turnos más tradicional. Así que hizo un rápido prototipo de un roguelike donde sólo tenías un segundo para hacer tu siguiente movimiento. Cuando lo jugo, Ryan se dio cuenta que tenía una cualidad casi rítmica, y se volvió obvio que el juego debía acompañarse con música. O quizá debemos echar un vistazo al icónico movimiento en el aire de Rocket League. Cuando Psyonix estaba trabajando en el predecesor del juego, Supersonic Acrobatic Rocket-Powered Battle-Cars (han aprendido mucho sobre mercadotecnia desde entonces), habían construido un juego sobre carros peleando, pero querían agregar una mecánica de aumento de velocidad. Así que los desarrolladores aplicaron una fuerza física a la parte trasera del auto. En las pruebas, descubrieron que los jugadores podían usar esa fuerza en el aire para propulsarse por la arena. Este no era el plan, pero los desarrolladores se dieron cuenta que añadía una enorme profundidad y una dimensión extra al juego, así que lo conservaron. El estudio dice: "desarrollamos esta mecánica casi por accidente." De hecho, hay una historia completa de juegos donde bugs , glitches y accidentes durante el proceso de desarrollo, fueron convertidos en características. Por ejemplo, Hideki Kamiya encontró un bug en Onimusha: Warlords que te dejaba malabarear enemigos en el aire al acuchillarlos repetidamente. Fue arreglado en Onimusha, pero Kamiya lo desarrolló más y lo volvió la mecánica de juego principal de Devil May Cry. El punto es, el proceso involucra tomar una idea inicial — por más floja, confusa o poco original que pueda ser— y convertirla en un prototipo funcional. Y es aquí, durante el proceso de codificar y jugar, que nuevas ideas pueden brotar. Así que depende del desarrollador ser abierto y atento a lo que el juego está diciendo. Para darse cuenta de qué es interesante y estar dispuesto a explorar esos aspectos... incluso si no se alinean del todo con lo que originalmente tenías en mente. Así es como Gunpoint pasó de tratarse acerca de un robot en el espacio que dejaba caer refrigeradores sobre gente, a ser un juego de acertijos acerca de un espía que reconecta edificios. Esa mecánica de reconectar fue sólo una idea posible de un mini juego de hackeo en un juego de desplazamiento lateral inspirado en Deus Ex. Pero tan pronto como el diseñador, Tom Francis, empezó con el prototipo, el juego que eventualmente se convertiría en Gunpoint, comenzó a emergir. Aquí está Tom: TOM FRANCIS: "Es sólo que se volvió de inmediato obvio que éste debía volverse un juego de acertijos. "Era sólo una mecánica de acertijos. "Y así, Gunpoint como que sólo me contó qué quería ser. "Sólo quería ser un juego de acertijos, obviamente, "y yo sólo me deje llevar por eso, sólo expandí la mecánica de hackeo a un grado loco. "Construí todo el juego alrededor de eso." Así que este proceso generalmente causa los cambios más significativos hacia el inicio del desarrollo de un juego, que es el punto que Sam Coster al describir al juego como una caliente bola blanca de magma maleable. Pero aún puede ser manipulada mientras el desarrollo sigue y el juego empieza a formarse y asentarse en piedra. Como para la generación de contenido, Jonathan Blow ha dicho que los acertijos en Braid eran sencillamente una muestra de las inesperadas consecuencias de su motor de juegos para viajar en el tiempo. Blow dice: "tenía un papel de curador, quitando las respuestas y presentándolas en una manera que pudieran ser disfrutadas por los jugadores." Más sobre eso en este video. O puede ser usado para escuchar la retroalimentación del jugador. Cuando Chris Hecker hizo SpyParty, los jugadores encontraron todo tipo de exploits y formas no intencionales de jugar el juego. En lugar de arreglar estos "bugs", Chris se apoyó en ellos y los hizo una parte oficial del juego: empujando la experiencia hacia ser más sobre juegos mentales y trucos psicológicos. Y puede ser usado simplemente para ayudar a guiar el desarrollo general de un juego. Aquí está el desarrollador de Subnautica, Charlie Cleveland: CHARLIE CLEVELAND: "De algún modo crees saber hacia dónde vas. "Tienes algún lugar en el horizonte, "y hay muchos caminos y no sabes cómo llegar ahí. "Pero si escuchas al juego, te dirá a dónde quiere ir." Así es cómo su estudio hizo un juego de horror, sin que esa fuera la intención al inicio del proyecto. Ahora, obviamente, este tipo de proceso de diseño puede hacer muy difícil predecir cuánto tomará hacer un juego. Esta es una razón por la que esta metodología es más popular en el mundo independiente (en lugar del ferozmente reglamentado mundo de grandes producciones blockbusters).