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).