Fernando Sansberro

14 ago23 Min. de lectura

El Proceso de Game Design de Slidemagi

La idea de este artículo es explicar el proceso de diseño que usamos al diseñar Slidemagi, un juego de estrategia por turnos con algunas mecánicas originales, y mostrar cómo podemos conseguir ideas y cómo trabajar con ellas. También se muestra la evolución de las ideas, de forma tal que el lector se pueda sentir identificado, inspirar a los aspirantes a diseñadores de juegos, y mostrar que el diseño de juegos es un proceso, y no algo mágico que viene del cielo.

Slidemagi [1] es un juego de estrategia por turnos desarrollado por Batovi Games [2], en el que las unidades se mueven deslizando las líneas del tablero. En este juego eres un mago que, usando tu mazo de cartas, puedes invocar hechizos o crear unidades con habilidades únicas para luchar bajo tu control.

Fig 1: La mecánica de deslizar líneas de Slidemagi.

Las Primeras Referencias

Slidemagi comenzó como un intento de hacer un puzzle casual con alguna mecánica innovadora. En los años de la decada del 2010 nos dedicábamos a hacer juegos casuales, y estudiando game design fue que me llamó la atención el “gameplay emergente” de juegos tipo merge como Triple Town [3], y con el auge de los juegos match-3, surgían muchas mecánicas y formas de jugar interesantes. En ese momento queríamos inventar un puzzle con alguna idea innovadora.

Investigando ese tipo de juegos y sus mecánicas, se llegó a la primera regla a prototipar. Usar la mecánica de desplazamiento de líneas (slide) de Chuzzle [4] para lograr juntar dos objetos y que eso ocasione alguna acción.

Fig 2: Chuzzle (izquierda) y Chaos: The Battle of Wizards (derecha).

Por otra parte, tambien siempre quisimos hacer un juego de estrategia por turnos como Chaos: The Battle of Wizards de Jullian Gollop [5], que es juego táctico por turnos, un duelo de magos en el cual se crean unidades usando hechizos.

Durante esta etapa siempre estaba en duda si el juego sería un puzzle para resolver situaciones o si el juego sería de estrategia. Entonces, en lugar de hacer un puzzle, se resolvió la idea de hacer un juego de estrategia por turnos, un duelo de magos, pero con mecánicas originales tomadas de los juegos casuales. La mecánica principal iba a ser mover las líneas, y de ahí su nombre: Slidemagi.

Nota: Las mecánicas principales del juego formarán lo que se conoce como High Concept o Pitch. Esto es, la descripción abreviada del juego que comunicaremos en todos lados, y a cualquier persona que nos pregunte cómo es el juego. En este caso el high concept se compone de: 1) mover líneas del tablero, 2) duelo de magos que crean unidades y disparan hechizos.

Evolución y Búsqueda de las Mecánicas

Cuando se diseña el juego, tomamos los elementos o mecánicas que más nos gustan de otros juegos o géneros, y los combinamos, modificamos, simplificamos o exageramos para lograr la jugabilidad que queremos (al menos solamente en una idea, en esta etapa).

En el caso de Slidemagi, el juego toma principalmente la mecánica de Chuzzle, más algunos elementos de los juegos tácticos como Chaos: The Battle of Wizards, y ciertos elementos del Ajedrez [6].

En la etapa de brainstorming podemos pensar en cualquier idea o mecánica, pero luego al momento de diseñar realmente cómo es el juego, debemos pensar en cómo se alinea cada mecánica con las premisas que nos ponemos para el juego.

Las premisas que nos pusimos son: 1) El juego tiene que tener una barrera baja de entrada, 2) Tiene que ser simple. No puede ser complicado de entenderse las reglas, y 3) Es un juego de pensar, pero tiene que ser dinámico e intuitivo (por no decir “casual”).

En los juegos tácticos, las unidades tienen las mecánicas clásicas: rango de movimiento, puntos de acción, atributos varios, hay cartas de hechizos para usar en cualquier momento, etc. Como dijimos que queremos un juego simple, no queremos memorizar diferentes rangos de movimiento, o tener unidades con muchos atributos, o con reglas de combate complicadas.

Fig 3: Ajedrez. Un juego perfecto.

La otra referencia es Ajedrez (siendo un jugador que he competido en Ajedrez en mi juventud, se bien cómo funciona y qué es lo que lo hace adictivo, al grado de que hasta da placer el hecho de estudiar en libros sobre el juego).

Ajedrez es un juego maravilloso, y hasta perfecto, podríamos decir. Pero tiene dos barreras de entrada bastante grandes: 1) Aprenderse el movimiento de todas las piezas y algunas reglas “raras” como el enroque, el peon que come al paso y la regla de los 50 movimientos para las tablas (empate), y 2) Una vez que aprendemos a mover, no sabemos que hacer. Tenemos que aprender a “pensar”. Esto implica poder visualizar combinaciones de movimientos “hacia adelante” (poder visualizar el tablero en la cabeza). Esto lleva tiempo, pero se convierte en la parte más divertida del juego (recordemos que “diversión” es un concepto que es diferente para cada persona).

En Batovi Games hace años desarrollamos Ajedrez y Leyendas [7], un juego para el Plan Ceibal (proyecto One Laptop Per Child) en Uruguay, que enseña a pensar en el ajedrez, y el juego se usó para realizar una competencia Nacional. Slidemagi se diseñó con mucha experiencia previa sobre el ajedrez y su proceso de aprendizaje, al igual que la experiencia adquirida en el mundo casual.

En Slidemagi todos esos conocimientos confluirían.

Fig 4: Ajedrez y Leyendas de Batovi Games.

Desarrollando el juego de Ajedrez, recibímos una llamada de unos chicos que estaban haciendo un “Ajedrez 2”, denominado Ajedrez Omnia [8] que querían hacernos un pitch para convencernos de su producción. Los recibimos en la oficina y nos explicaron que el juego era en un tablero de 10x10, y que incluía piezas nuevas: una catapulta, una pared, un dragón, etc. Nada fuera de lo común, y no me animaba a decirles “no voy a programar un prototipo para ver si me gusta”. Pero, había una pieza, que era muy interesante: un Mago, que podía teletransportarse a cualquier casilla, y a las piezas adyacentes, ¡las inmobilizaba! El mago no podía capturar, su función era solamente esa. A mi esa pieza me pareció fantástica, y fue un disparador para pensar “que tal si muchas piezas hacen algo así, único”. Sería un excelente juego. Cambiaría muchímo la estrategia. Ahí había algo para explorar… Pasó mucho tiempo desde ese momento, pero la idea quedó dando vueltas en mi cabeza. Y luego eran frecuentes las visitas al sitio de Chess Variants [9] para buscar piezas con mecánicas nuevas.

Todo esto fue la semilla para sentar las bases de las mecánicas principales (core mechanics) de Slidemagi: Chuzzle+Chaos+Ajedrez.

Nota: Es muy importante tener definidas las premisas principales, porque luego cada mecánica que se piense, debe descartarse si no se alínea con las mismas, y debemos trabajar solamente en las mecánicas que refuercen las premisas principales.

Resumen del Proceso de Desarrollo

El proyecto comenzó con varios prototipos para validar y (sobre todo) descartar ideas, en “modo hobby” (en las noches, por fuera de la producción diaria del estudio). El juego tiene bastante tiempo de trabajo personal en el game design, y luego ya en producción con el aporte de todo el equipo que mejoró el juego considerablemente.

Tiempo más tarde, en 2015 se desarrolló un prototipo de ocho meses (un programador y un artista). Ese prototipo sirvió para validar la idea general, pero quedaron muchas reglas abiertas. Luego de eso fue continuado en mi tiempo libre (en las noches) durante varios años (algún día dedicando unas horas, otros días unos minutos, y otros días nada, con períodos muy largos en medio en los que me dedicaba a otros proyectos). Pero siempre con este juego en la cabeza. Era un juego que realmente quería hacer en algún momento.

En los años siguentes, también en “modo hobby” lo reprogramé desde cero, refactoreando todo y descartando cosas que no funcionaron en las pruebas del prototipo. El juego lo convertí a pixel art, porque era el arte que podía hacer solo.

En 2023, hablando con mi socio, Roque Papa, y planteando la necesidad que tenía de “cambiar de aire” y descansar un poco de los juegos de fútbol (veníamos de años intensos de desarrollo de Pixel Cup Soccer [10] y Charrua Soccer [11]), decidimos poner en producción el juego en el estudio. Roque me pidió que el juego tuviera arte 3D prerenderizado (algo en lo que Roque es experto produciendo), que fuera isométrico (porque visualmente se vería mejor), y me pidió que estuviera receptivo a cambiar reglas.

El proyecto final llevó un año completo de desarrollo, comenzándose su desarrollo desde cero. El resultado realmente es asombroso. Mucho mejor que lo que me imaginaba tener cuando trabajaba solo.

Nota: El game designer debe tener la capacidad de escuchar ideas y sugerencias y tratar de interpretar qué es lo que hay atrás de las mismas, para mejorar el juego, en lugar de intentar defenderse y explicar porqué algo es así y que no se puede cambiar.

Primer Prototipo

El primer prototipo fue desarrollado en Flash muy rápidamente (usando los assets de Oryx Design Lab [12] para enfocarnos solamente en las reglas). En ese momento los magos creaban unidades y solo se podían mover las líneas de los magos (las unidades no se movían). La idea era intentar colocar una unidad al lado de un enemigo para que lo ataque. Al hacer el desplazamiento de la línea, se podía pasar la unidad para el otro lado del tablero (desplazamiento cíclico).

Fig 5: El primer prototipo de Slidemagi desarrollado en Flash.

Este prototipo lo probé con mi hijo (un chico en ese momento) y me miró como diciendo “Papá, porqué haces este juego?”. Me senti tonto. Obviamente esto no funcionaba, era imposible colocar una unidad donde se deseaba.

Nota: Es mejor prototipar rápido y fallar, de forma tal de no perder mucho tiempo. Se puede prototipar en papel, para no programar, pero si se cuenta con la capacidad de programar, esto es bastante mejor, porque se pueden probar alternativas rápidamente, que a veces no se pueden hacer tan bien en papel. Depende del juego obviamente.

Evolución de las Reglas

Luego de la prueba del primer prototipo, era obvio que las unidades tenían que caminar. Analizando alternativas, y como definimos que no se quería una barrera de entrada alta, descartamos cualquier idea que involucre rango de movimiento, o tipos de movimientos diferentes para cada unidad. Además, había que diferenciarse del resto de los juegos de estrategia existentes, ya que hay cientos y muy buenos haciendo esto.

Entonces se definió una regla que iba a tener el grado de contraint: “todas las unidades se van a mover en línea recta”. Una regla de constraint es algo que definimos que tiene que ser así, y no la volvemos a considerar (es decir, no podemos poner en duda su existencia). Esto se basa en la teoría de que el juego puede ser divertido con esta regla, a pesar que aún no sea tan claro este hecho. Obviamente esto no siempre funciona, y hay que tener mucho criterio e intuición para definir una regla de este tipo.

De esta forma, si todas las unidades se mueven en línea recta, se elimina la barrera de entrada de cómo mover (caso del Ajedrez). Se descartaron movimientos y ataques en diagonal, movimientos con rango de acción, etc.

La idea era que el juego si bien tuviera la profundidad de un juego de estrategia, fuera muy fácil de manipular para eliminar la barrera de entrada.

Segundo Prototipo

El segundo prototipo tenía las siguientes reglas: El mago desplaza su línea, y todas las unidades de la línea movida, atacan (esto le da más poder al movimiento del mago). Las unidades podían caminar, y solo se frenaban cuando se topaban con algo (mecánica tipo Tilt Maze [13]). Este prototipo fue desarrollado en Unity [14].

Fig 6: El segundo prototipo de Slidemagi desarrollado en Unity.

Por supuesto, esto tampoco funcionó. No había forma de que las unidades quedaran donde el jugador quería. Fue un fracaso.

Entonces se decidió que las unidades iban a caminar (siempre en línea recta) hasta la casilla que se quisiera. La forma de mover es: se hace click en la unidad, aparecen las casillas a donde puede caminar y camina hacia ahí. En teoría, en dos movimientos se puede llegar a cualquier casilla del tablero.

Estas reglas iban a constituír la base del diseño en este punto: 1) Los magos desplazan las líneas y todas las unidades de esa línea movida, atacan, 2) Las unidades caminan en línea recta y cuando llegan al destino realizan su acción.

Fig 7: El prototipo modificado con las unidades caminando.

Cómo Obtener Ideas de Game Design

Durante todo este proceso, que podemos llamar de preproducción del proyecto, se realizaron varias sesiones de brainstorming, que puede ser desde simplemente unas horas trabajando solo y pensando, hasta organizar sesiones de juego en donde escuchamos las opiniones del equipo. Con este juego también se han realizado ejercicios en clases de game design, donde se les plantea a los alumnos “crear una unidad y un hechizo” para Slidemagi.

Nota: Una sesión de brainstorming, debe llevarse a cabo trabajado receptivamente y colaborativamente en un proceso creativo, en el cual se deben escuchar las ideas o mecánicas sugeridas y analizarlas. Para cada idea (por más descabellada que sea), intentar obtener la razón por la cual alguien da esa idea, tratar de incorporar esa idea a la idea general del juego, y lo mas importante, para cada idea o mecánica presentada, pensar en ideas alternativas (combinarlas, modificarlas, pensar en sus opuestos, exagerarla, simplificarla, etc.).

Fig. 8: Una sesión de brainstorming con alumnos de la carrera de videojuegos.

A la hora de sugerir mecánicas, o ponerlas en la lista para ser evaluadas, no todo vale, de forma tal de simplificar el trabajo de depuración luego. Cualquier desarrollador es una persona creativa, y seguramente debe haber leído bastante sobre game design y entender porqué funciona cada mecánica, entendiendo sus pros y contras. A veces esto se sabe intuitivamente por haber jugado muchos juegos. Entonces, hay que lograr cierto criterio a la hora de sugerir cosas.

Por ejemplo, no todo vale en el juego. Si por ejemplo tenemos como premisa que el juego tiene que tener una barrera de entrada baja, queda descartado todo lo que tenga que ver con rango de acción, atributos complicados, y cosas del estilo. Estaba en nosotros filtrar eso de modo de no afectar susceptibilidades.

En Slidemagi, las mecánicas se convierten en una lista de unidades, hechizos y tipos de casillas, a definir. Durante el tiempo dedicado a encontrar ideas, se examinaron muchísimos juegos de estrategia y juegos CCG (collectible card games), a veces recorriendo todo el listado de sus cartas, tratando de buscar inspiración de unidades o hechizos que funcionen en el juego.

En este juego no fue sencillo encontrar unidades o hechizos, dado que el juego no tiene atributos complicados, ni rangos de acción, o los elementos clásicos de los juegos de estrategia. Cualquier hechizo del tipo “amplía su radio de acción”, o “le sube su defensa”, de los cuales hay miles en los juegos, no sirve. Por otro lado, lo que se buscaba eran mecánicas “un poco diferentes”, por ejemplo: Araña que dispara telaraña y atrapa el enemigo, mientras que una unidad amiga adyacente la puede liberar.

Depuración y Testeo de las Ideas

Luego del proceso de brainstorming, con el paso de tiempo y luego de varias iteraciones sobre las ideas, se decantó en las siguientes mecánicas a ser consideradas:

Unidades con acciones especiales. Por ejemplo: Elemental de Hielo congela a quien golpea, Araña dispara telaraña y atrapa, Escorpión envenena al golpear, y la unidad envenenada pierde energía por turno si no se cura, Medusa petrifica al enemigo, Hypnotist convierte las unidades adyacentes a nuestro bando, etc.
Cualquier unidad atrapada o congelada es más vulnerable a los golpes (x2).
Unidades que se paran al lado de una unidad amiga atrapada, la libera.
Cuando una unidad muere, deja un cráneo (como si estuviera su alma ahí) y ésta tranca la fila movida, limitando los movimientos posibles si hay muchos muertos. Nigromante puede revivir los muertos, y las unidades pueden romper de un golpe a los cráneos si desean.
Golem es immune a las flechas, y funciona como un obstáculo movible, a la vez que tiene un gran ataque.

Varios hechizos comunes como curar, incrementar ataque, envenenar, etc..

Las unidades tienen un lado a donde miran (facing), y al pegarles por atrás el golpe vale doble. Cuando se mueve una línea, las unidades se dan vuelta y miran a ese lado.
Tener varios layers que agreguen complejidad para los jugadores expertos: Por ejemplo, 1) las unidades tienen una alineación mágica con el mundo, o un ciclo de luz/oscuridad que las hacen funcionar mejor en cierto momento, y peor en otro, 2) algunas unidades son immunes a otras, por ejemplo, unidades vivas vs. muertas o naturales vs. mágicas, etc.
Puntos de accion para mover en cada turno. Puede ser una cantidad de movimientos en general, o por unidad, etc.
Hay gemas para tomar en el tablero que dan nuevos hechizos.
Casillas con símbolos especiales que dan poderes al pararse ahi.

Fig.9: Checkman (Zilec-Zenitone, 1982).

Nota: Cualquier mecánica que se haya visto en otro juego puede servir si se alínea con las premisas definidas del juego. Por ejemplo, cuando una unidad muere, y deja el cráneo que tranca las líneas, fue inspirada por el juego Checkman [15], un arcade de 1982, que no tiene nada que ver con el género de nuestro juego.

Tercer Prototipo

En el prototipo que teníamos en este momento (realizado en 2015), habían varias cosas sin resolverse, que fueron detectadas en los testeos. La idea era hacer un prototipo desde cero, en parte porque el anterior era viejo, había pasado mucho tiempo y las reglas iban a cambiar bastante. Por otra parte, estaba trabajando en modo hobby, en el tiempo que podía, fuera del trabajo del estudio (que lleva prácticamente todo el tiempo de la semana), básicamente en las noches, o los fines de semana, si se podía.

Decidí usar un estilo pixel art, porque era el estilo que como programador podía hacer para el arte placeholder, y de esta manera podríamos enfocarnos solamente en el gameplay.

Fig.10: El tercer prototipo de Slidemagi.

El objetivo de este prototipo era tener las reglas finalmente validadas para poder comenzar la producción del juego en algún momento.

Uno de los problemas principales que tenía la versión actual, era que habían varios puntos de acción (varios movimientos) dentro de cada turno. De esta forma, un jugador que pensaba bien, podía hacer una serie de movimientos letales (por ejemplo, mover una unidad a una casilla que aumentaba el poder de ataque, y luego un desplazamiento para colocarla al lado del mago enemigo y matarlo). Esto hacía muy frustrante el juego para las personas que pensaban menos, y además se daba que habían partidos muy parejos, de decenas de minutos, y terminaba de golpe por una combinación de este tipo.

La UI era complicada. Habian movimientos para darse vuelta que no consumian puntos de accion y los jugadores giraban las unidades antes de mover. Esto hacía el juego insoportable, esperando que al inicio de cada turno se ajuste a donde mira cada unidad.

Otra cosa a resolver, era que cuando una unidad se movia a una casilla, había que definir si se dejaba realizar cualquier acción, o se iba a dejar realizar una sola acción según algunas reglas. En el prototipo actual, cuando una unidad se movía a una casilla, aparecia un menu para elegir que se quería hacer (si pegarle al enemigo o no, si disparar, etc.) Esto era muy complicado de manejar.

Como queremos un juego simple de manipular, se decidió que solo harían una acción, pero las reglas deberían estar claras para que el jugador sepa de antemano que acción sería esa.

Cuando una unidad camina y llega al destino, donde puede hacer varias acciones, ¿cual realiza? Esto llevó a incontables horas de dibujo analizando reglas, tratando de que sean intuitivas, y finalmente se llegó a algo entendible. Con estas reglas se escribió un documento de diseño (GDD), especificando el orden de los ataques.

Fig.11: El GDD mostrando las reglas de acciones de las unidades.

Relacionado al movimiento, también habían cosas a resolver. Las unidades al caminar, ¿pueden atravesar los objetos? Las unidades voladoras, ¿pueden disparar por encima de los árboles? ¿Pueden volar hasta atrás de un enemigo atacándola por la espalda?

Para simplificar el juego, se decidió que ninguna unidad puede atravesar a otra, incluido objetos. Obviamente los objetos no pueden ser chicos, porque daría la idea que se puede caminar por encima de ellos, pero estamos hablando de juegos, entonces una gema, tendrá el tamaño de una unidad. Ya estamos acostumbrados a este tipo de cosas en los juegos.

En el prototipo actual, cuando el mago deslizaba una línea, las unidades aparecían por el lado contrario. Esto para algunos jugadores era imposible de visualizar, y muy frustrante cuando alguien hacía ese movimiento y le atacaba. Esto fue descartado y se hizo que las unidades tranquen el movimiento (al igual que los cráneos).

Nota: Al evaluar descartar ideas, o realizar cambios, no conviene pensar en cuanto tiempo de desarrollo o líneas de código se van a tirar a la basura. Todo tiene que ser con el objetivo de mejorar el juego. Obviamente no es particularmente fácil esto para quienes tienen perfil de programador. Relacionado con esto, es aconsejable tratar de escribir código flexible a los cambios de reglas, y por supuesto, escribir código sumamente prolijo y documentar absolutamente todo.

Cuarto Prototipo y las Reglas Finales

En 2023, decidimos poner en producción el proyecto en Batovi. Siendo también más maduros, comenzamos a reever todas las reglas. Mi socio, Roque Papa, está muy influenciado por los juegos casuales. Entonces lo primero que me dijo es “¿porqué el mago desplaza las líneas y las unidades caminan?, ¿porque no todas las unidades desplazan las líneas?”.

Ese día pensé en salir corriendo y tirar todo, dado que yo habia pensado en “los magos son poderosos y por eso mueven las líneas, las unidades caminan”, pero como ya era más maduro, apliqué la regla de constraint y dije: “¡tiene razón!, si todo se mueve igual es más fácil de manejar” (y con eso la mitad de las líneas de código desaparecían, pero como las había programado yo, solamente yo iba a llorar).

Nota: En algun momento, debemos dejar ir ideas que nos parecen brillantes (y posiblemente lo sean), en pos de afianzar las reglas de constraints que nos pusimos para el juego y con el objetivo de mejorar el mismo. Hay que intentar analizarlas, defenderlas si se quiere, pero tambien saber dejarlas ir. A veces conviene ver el juego desde lejos, como si no lo conociéramos.

Naturalmente eso implicaba tirar mucho trabajo, y muchas cosas no iban a funcionar (por ejemplo, ir a atacar a una unidad en la misma línea, o pararse en casillas especiales). Al plantear este problema, Roque sugirió una idea espectacular que mejoraría totalmente el juego: que cuando se desliza una línea, y una unidad se tranca en el borde, todo se aprete. Las casillas pasan por abajo de los pies una vez que las cosas se apretan contra el borde. De esta forma, una unidad en la misma línea puede acercarse para atacar, o puede ponerle una casilla mala debajo de los pies a un enemigo.

Fig 12: La mecánica de apretar al deslizar la línea.

Esto a su vez solucionaba el hecho de que las unides voladoras ya no tenían sentido si las unidades no caminaban. Ahora que se pueden apretar unidades y colocarles una casilla mala debajo, las unidades voladoras serían immunes al piso, y con eso volvieron a cobrar sentido.

También se discutió mucho si los cráneos u unidades debían trancar el movimiento, porque no se entendía el porqué lo hacían. Y tampoco se entendía porqué si un cráneo trancaba el desplazamiento de la línea, porqué no lo hacían los árboles, o las unidades.

Como ya se había decidido que el desplazamiento no iba a ser cíclico, las cosas en los bordes, o bien trancaban o bien caían. Por otra parte, si se podía tirar una unidad por el borde, ¿porqué no se podrían tirar todas?. Decidimos probar con versiones de prototipo rápido, haciendo constantes en el código para probar toda combinación de reglas (un gran logro de los programadores del equipo).

Luego de algunas partidas, las cosas quedaban apretadas contra los bordes, entonces decidimos que las unidades no se podian tirar del tablero, pero los objetos sí (solo uno).

Esto siempre fue una fuente de debates en el equipo, porque no era uniforme, porque se podia tirar una unidad, pero no un objeto, y ¿porqué se podia tirar uno solo y no todos?. Se hicieron animaciones para los personajes a punto de caer, para mostrar que no se podían caer, pero el problema seguía ahi latente.

Tambien quedaba dificil poder contar casillas y saber a simple vista (o sea, sin tener que pensar demasiado), hasta donde podia llegar un movimiento de apretar. No se podia visualizar mentalmente las posiciones hacia adelante, cosa que es absolutamente necesaria en los juegos de estrategia de este tipo.

En el prototipo anterior, cuando una unidad moría, el Nigromante la podía revivir, recuperándola tal cual era. Esto hacía que el jugador tuviera que recordar que unidad era cada una. Para simplificar, Roque sugirió que se revivan solamente zombies, de forma de simplificar el juego. El zombie, una vez muerto, desaparece totalmente, dejando libre esa casilla.

Fig 13: El Nigromante reviviendo muertos en zombies.

Luego de muchísimas pruebas, se decidió que ninguna unidad u objeto se caiga por el borde del tablero. Como las unidades caen en agujeros, agua o casillas de este tipo, y los muertos una vez revividos no vuelven a dejar el cráneo (luego cambiado por una tumba), el tablero se va limpiando.

Al tirar una unidad por el borde, la carta volvía al mazo. Era una forma de poder deshacernos de un enemigo. Si el enemigo era debilitado por golpes, se mantenía con su energía al volver al mazo. Todo esto al final hacía difícil de entenderse, no se sabía si una unidad se creaba con la energía completa o era una que había vuelto al mazo. Además, en los testeos realizados, los jugadores abusaban de esa mecánica. A mí particularmente me parecía una idea brillante que la unidad volviera al mazo, pero la dejé ir y a cambio se decidió que todas las unidades trancaban los bordes. Ninguna unidad se iba a poder tirar por el borde, para que todo sea finalmente más claro, y se pueda previsualizar bien el movimiento (si la unidad iba a caer por el borde era mucho más difícil de previsualizar).

Otro gran cambio con respecto al prototipo anterior, fue sugerido por Mathías, programador del equipo, que sugirió que en lugar de que solamente las unidades de la línea movida realizaran la acción, lo hicieran todas nuestras las unidades del tablero. Esto hizo al juego mucho más estratégico, haciendo que las unidades combatan más. Esto también solucionó el problema que había que movíamos una línea, colocando un enemigo a tiro de otro (por ejemplo, un arquero arriba), que como estaba en otra línea, no disparaba. Ahora con este cambio, sí dispara. Cada unidad al final del turno realiza su acción para los cuatro costados.

Tambien discutimos mucho sobre la cantidad de unidades y hechizos que debía tener el juego para funcionar. De la manera que está pensado, cada unidad tiene sus pros y contras, por lo cual algunas unidades o hechizos funcionan mejor contra otras. Esto hace infinito el juego, o la necesidad de hechizos. Pero había que definir un “set mínimo” con el cual el juego fuera igual de divertido, y luego definir que unidades se desbloquearían.

Nota: Se debe definir la jugabilidad principal (el core gameplay) lo antes posible. El resto de las ideas a producir debe estar en función a eso. El juego tiene que funcionar tanto con pocos elementos, como con muchos.

Otra de las discusiones e idas y vueltas se dieron en torno a si los hechizos se pueden usar en todo el tablero, si afectan a todo el tablero, o a un área, o si se disparan en línea, etc. Por ejemplo, cuando se define un hechizo (por ejemplo, tirar fuego), aplicando las formas posibles, tenemos la posibilidad de dispararlo en línea recta, o de que afecte a un área.

Luego de multiples testeos que duraron meses, se decidió que todos los hechizos a futuro van a tener las dos formas, con diferentes costos. Sin embargo, por el tipo de hechizos elegidos para la primera versión del juego, en sus primeros niveles, tiene disparar fuego en línea recta, y el resto de los hechizos en área (envenenar, curar, etc.).

Nota: En este tipo de juegos es bastante difícil lograr una uniformidad de criterios y simetría (por ejemplo cantidad de hechizos de líneas o de área). La solución es pensar en que eso se resolverá a futuro (agregando otros hechizos con todas las combinaciones posibles y diferentes costos). Hay que trabajar bastante en lograr lo mejor posible para el momento actual.

Los puntos de acción por turnos fueron eliminados completamente, con la idea de tener un juego dinámico. De esta forma, cada turno es un movimiento de una unidad, o disparar un hechizo. De esta forma se logra un juego dinámico (esto puede incluso introducir modos muy divertido de mover en pocos segundos, intuitivamente, como es el caso del Blitz Chess [16]).

Finalmente, otras discusiones fueron el uso o no de aleatoriedad (random), los diferentes tipos de casillas, los hechizos y unidades a incluír en la primera versión del juego, y el armado del mazo de cartas y su funcionamiento.

Random y Chance

Tener aleatoriedad en el juego es una forma de introducir incertidumbre, que hace que un jugador no dependa solamente de su habilidad para ganar. Cuando un jugador es competitivo, y mejor domina el juego, menos desea que hayan cosas aleatorias en el mismo.

En el tercer prototipo, cuando una unidad atacaba, la chance de golpear exitosamente se calculaba con la clásica función: Si ataque + RND(1,5) > defensa + RND(1,5), el golpe es exitoso. Esto tenía dos problemas en nuestro juego. El primero era que había que comunicar esta fórmula, y los jugadores necesitaban andar calculando chances de golpear con éxito. El segundo era que si se realizaba un movimiento, y el golpe no era exitoso, se sentía frustrante.

Decidimos entonces eliminar esta chance de los ataques, y hacer que la unidad siempre acierte el golpe, de forma tal de favorecer a quienes realizan el movimiento de ataque. Esto da incentivo para mover las unidades por el tablero y hacer ataques.

De todas formas, la idea de que haya cierta aleatoriedad en el juegos se mantuvo, con el concepto de la mano del mazo. De las dieciseis cartas que podemos llevar a la partida, se reparten cinco que son las que podemos usar en todo momento. Cuando se usa una, se reparte otra. Esta aleatoriedad debe ser compensada con habilidad si no nos favorece la mano. Si la mano que nos toca es muy mala, se puede descartar un hechizo y perder el turno. Tener una mano de cinco cartas, favorece la rejugabilidad de la partida.

Apretar, Atrapar y Liberar

En el tercer prototipo, habían casillas con símbolos, y cuando una unidad (que en ese entonces caminaba) se paraba encima, objtenían algun poder (por ejemplo, curarse, fuerza, inmunidad, etc.). Como en la versión actual, las unidades deslizan su fila, no pueden decidir ir a una casilla que le de beneficios. Este fue un punto que debatimos mucho, porque era parte importante de la estrategia.

Como ahora estaba la mecánica de apretar, y se podía lograr poner determinado piso por debajo de los enemigos, tuvimos que pensar en tipos de casillas que tuvieran mecánicas que afecten negativamente a los enemigos. La idea de esto es, lograr posicionarse en filas con este tipo de casillas, y dominar la línea, de forma tal que si un enemigo se coloca en ella, podemos ponerle la casilla especial abajo. Los enemigos voladores son inmunes al piso.

Luego de un brainstorming breve, obtuvimos los siguientes tipos de casillas: agujero (la unidad cae y vuelve al mazo), agua venenosa (la unidad queda hundida y se envenena, perdiendo energía en cada turno hasta ser liberada o morir), arena movediza (la unidad se va hundiendo de a poco hasta desaparecer, a no ser que sea liberada), pinchos (la unidad muere), etc.

Cualquier unidad atrapada en una casilla de estas es vulnerable a los ataques, y para liberarla hay que volver a hacer un movimiento de apretar, moviendo otra unidad nuestra y apretando la unidad a liberar, colocándole un piso normal para sacarla de ahí.

La Forma Sigue a la Función

Para realizar la lista de unidades y hechizos, generalmente se piensa en una acción, por ejemplo, “envenenar”, y luego pensamos en una unidad, y en los hechizos.

Por ejemplo, la unidad que envenena es el escorpión, el hechizo Poison Cloud lanza un veneno afectando el área, y el hechizo Poisoned Arrow lanza un disparo de veneno en línea. Pensando en todas las combinaciones, armamos una tabla en una hoja de cálculo donde vamos llenando esto.

Fig: 14. Una unidad para todas las posibles combinaciones de atributos.

Como siempre, las planillas son el mejor amigo del game designer. Se arma una planilla para colocar todas las combinaciones de atributos. De esta forma, algunas unidades serán naturales de hacer, por ejemplo una unidad que dispara será el arquero.

Siguiendo con el ejemplo de “envenenar”, necesitamos una unidad normal (escorpión), una unidad que dispare veneno: una víbora. Luego habran algunas que serán más dificil asignarle forma (por ejemplo, unidad que vuele y envenene al atacar, otra que vuele y dispare veneno). Podria ser una serpiente voladora, o un insecto.

Nota: Al definir las mecánicas, es bueno seguir la regla “la forma sigue a la función”, mencionado en el libro Level Up! de Scott Rogers [17] (esto es, primero definir las cualidades y luego pensar en la forma que tendrá). De esta manera es mucho más sencillo obtener las ideas en forma abstracta. Es bastante más fácil encontrar una representación que ejecute la mecánica definida, que tratar de hacer lo opuesto.

Llevando estas combinaciones posibles de unidades y acciones en una planilla, nos obliga a pensar en el balance general, antes que andar haciendo unidades que no aporten a la estrategia del juego.

Durante el desarrollo se evaluó si del mazo que armamos para llevar a la partida, podemos elegir cualquier carta, o si las cartas tienen costos para usarse, o necesitan gemas de colores, etc. Todas estas ideas fueron descartadas, y la idea inicial del mazo con una mano actual de cinco cartas sobrevivió, siguiendo la premisa de que el juego fuera lo más simple posible de entender (aunque complejo de dominar).

A la hora de seleccionar las cartas para armar el mazo con el que jugamos la partida, decidimos limitarlo a dieciseis cartas, de modo de limitar el tiempo de duración de la partida. A las cartas se le puso un costo para evitar llevar las mejores, y tener que balancear al elegir. También se puso una limitación de limitar la cantidad de cartas repetidas a cinco, para no hacer el juego monótono (sobre todo, pensando que de inicio el juego es online multiplayer, y hay que cuidar la experiencia de los usuarios).

Conclusiones

Todos los prototipos realizados y las sesiones de brainstorming para pensar las reglas y encontrar mecánicas interesantes, y asignarlas a unidades y hechizos, funcionaron. Obtuvimos un juego de estrategia bastante original, con algunas reglas muy poco vistas en estos juegos.

Naturalmente, este proceso de iteraciones continuas llevan mucho tiempo y esfuerzo, y solamente se justifican si buscamos mecánicas originales. La idea de “iterar hasta encontrar el juego” no se aplica a desarrollos con tiempos fijos.

El consejo aquí es que el game designer debe intentar hacer todo este camino de prototipación e iteración de mecánicas, fuera de lo que es la etapa de producción, o incluso preproducción del proyecto. Se debe lograr trabajar en un ambiente totalmente libre de presiones, que fomente la creatividad (esto puede ser, incluso en las horas nocturnas, en casa, relajado), antes siquiera de considerar poner el proyecto en producción (con sus costos y presiones de tiempo relacionadas). Esta es la mejor forma de conseguir mecánicas innovadoras.