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