Con tantas plataformas, stores y minijueguicos no damos abasto. La democratización del desarrollo ya es una realidad, y publicar nuestros juegos está tan sólo a una pequeña inversión de tiempo de distancia. Hoy tenemos el privilegio de recibir a Ludipe, un diseñador y desarrollador primerizo que comparte la creación y publicación de un pequeño juego de puzles, Simplicity. Lean a continuación el primer capítulo de su experiencia en palabras del propio protagonista.

Simplicity es un juego minimalista de puzles para Android. Lo diseñé para que los jugadores desconectasen un rato de todo y pudiesen relajarse mientras piensan en encontrar la solución a cada reto (aunque resulta que los usuarios lo disfrutan pero no lo encuentran muy relajante, qué le vamos a hacer). En cada pantalla hay cuadrados, algunos rojos y otros verdes. Cuando tocamos uno cambiamos su color y el de los cuadrados adyacentes, y el objetivo es conseguir que todos los cuadrados sean verdes. Durante el desarrollo quise introducir otras mecánicas de juego pero algunas personas lo encontraron muy complicado, así que me quedé con la idea inicial.

Fue desarrollado durante la Ludum Dare October Challenge, para que nos entendamos todos, en un mes. El objetivo era desarrollar un juego, llevarlo a un mercado y ganar al menos 1$. Aunque en primero en lo que pensé fue en dejarlo pasar, me acordé de cómo había sido mi primera Ludum Dare, de lo mucho que me había costado decidirme a participar, y de cuánto me cambió. Al igual que antes no terminaba nada, ahora sólo hacía prototipos que ni pulía ni publicaba en ningún sitio, así que terminé apuntándome. Una vez más la Ludum Dare estaba ayudándome a dar un paso adelante. No puedo desarrollar a tiempo completo (¡ya me gustaría a mí!) así que para hacer todo en 30 días me tocaba ir haciendo brainstormings por la calle, y luego siempre conseguía sacar un rato antes de acostarme para ir trabajando en el ordenador.

El resultado ha sido mi primer juego para Android, funcional y con más de 50 niveles. Lo primero que me pregunta la gente a la que le enseño el juego es cómo acabé diseñando esto en lugar de otra cosa. Cuando empezó Octubre yo sabía que quería hacer un juego para el evento que he mencionado antes, pero no se me ocurría nada. Me puse a ver una conferencia de Jonathan Blow (creador de Braid) donde hablaba de The Witness; en él mostraba como partió de una mecánica simple que no tenía por qué ser revolucionaria —ni nada parecido— y jugó con ella hasta conseguir algo más interesante. A mí me pareció una idea muy buena. Todos hemos visto mil mecánicas en aventuras gráficas que se usan para un puzle y luego caen en el olvido. Sería interesante coger alguna de ellas y construir un juego alrededor de dicha mecánica. Anoté un par de mecanismos que me vinieron a la memoria y terminé decantándome por el que se ha convertido en el núcleo de Simplicity.

Al comienzo estaba completamente en blanco. No tenía muchas ideas y Octubre ya había empezado. Le estuve dando vueltas un tiempo y acabé decantándome por hacer algo para Android, en tanto a primera vista me pareció una plataforma donde es más fácil vender una aplicación a un público general. Claro, esto traía otro problema: nunca había desarrollado algo teniendo en cuenta las distintas resoluciones de pantalla y otros problemas que conlleva este sistema. Ya que sabía que iba a tener dificultades a nivel técnico tenía que buscar un diseño simple, pero no me sentía cómodo con un juego arcade típico que fuese a ser mero entretenimiento; un juego de puzzles de corte minimalista parecía una buena idea.

Ya no sé como se me ocurrió la mecánica básica, supongo que fue una idea sin más que vino en un momento de inspiración. Hice un prototipo muy rudimentario y empecé a juguetear con las posibilidades que ofrecía. Los primeros niveles que hice no seguían ningún criterio en particular, sólo quería probar un poco la idea. Luego empecé a inspirarme en formas geométricas y objetos comunes; muchas veces es difícil reconocerlos porque están dibujados en una cuadrícula de 5×5, pero todos están inspirados en algo. El problema es que siguiendo este proceso no sabes si tiene solución, planteas un puzzle e intentas resolverlo, pero cuando llevas varios minutos intentándolo sin conseguir finalizarlo te toca dejar de lado ese nivel porque no sabes si es apto para que sea incluido en el juego. Este sistema no era muy viable dada la cantidad de tiempo que se perdía.

Llegados a este punto se me ocurrieron dos posibles caminos a seguir: usar otra forma de diseño o encontrar alguna forma de verificar que existe solución. Terminé diseñando los niveles de otra forma, no por ocurrencia mía, sino por mera casualidad. Le estaba enseñando a un amigo el juego y después de pasarse un par de niveles me dijo: «Vaya, los niveles están muy bien, para diseñarlos has partido de la solución y has hecho un par de transformaciones que los usuarios tienen que revertir para completarlo,¿no?». Ni por asomo se me había ocurrido algo así, pero tenía mucho sentido, es como cuando de pequeño hacías trampa en los pasatiempos donde tenías que recorrer un laberinto y empezabas por el final.

Me puse a diseñar niveles usando este método, pero el resultado no terminó de convencerme. Los niveles parecían perder cierto encanto, y además, había un problema muy grande. Al hacer todo así yo no conocía bien mi juego. Una cosa son las mecánicas iniciales que rigen el juego, pero luego los usuarios desarrollan ciertas estrategias avanzadas a partir de ellas, y me parece muy importante que esto esté presente en cualquier juego. La única forma de estudiarlo es ponerte a jugar muchísimo hasta que tú mismo experimentes cambios en tu forma de entender todo. Es como el ajedrez: una persona puede conocer todas las reglas necesarias para jugar, pero hasta que no juegue mucho y empiece a estudiar la teoría no va a comprender realmente el juego. De eso se trata al final, le proporcionamos al usuario una serie de desafíos y su objetivo es llegar a entender todo hasta el punto de que ya no suponga un reto.

Yo no soy informático, ni artista, pero soy estudiante de matemáticas, y lo de buscar la existencia de solución es algo con lo que trabajamos a menudo; probé cuándo un nivel era resoluble de dos formas. Ya había asimilado el funcionamiento del juego así que lo planteé de la siguiente forma:

Todo se reduce a saber qué botones hay que pulsar. Si pulsamos dos veces el mismo estamos deshaciendo un turno anterior, luego las soluciones óptimas no pueden tener ninguna repetición. Los niveles están dibujados sobre una cuadrícula de 5×5, luego en las ocasiones donde hago uso de todo el espacio hay 25 botones. Tengo que decidir si pulso o no cada uno, eso me lleva a que, cuando hay 25 botones, hay un total de 2^25 posibles estrategias que pueden (o no) ser solución.

Lean la primera parte aquí.

También pueden seguir a Ludipe en Twitter, o prueben Simplicity.