On the first things that we talked after deciding that we wanted to create a development team was the direction that our products would be given and the philosophy of our own team. Granted, this was the first time we would be working on the video game industry as a team, but we had experience on creating start-ups on another fields. With all that prior experience and failures (hence the name), we knew that we needed a central idea to follow, to not lose that direction.

“To deliver story driven games, with full atention to details, background story and obviously, gameplay”

So we came up with our central idea, our cohesive glue, and we were a team now, a new one obviously, but eager to start the development of our first game.

Then it came the dreaded pre-production, something we all knew we had to employ all our energies to get right, mess, and retry over and over until we had something that met our standards. Some of our guys came with this crazy idea “Well… let’s have a magician guy travel on a forest that grow hats on their trees, because hats are awesome”. With this we had a starting point for our pre production.

Obviously the original idea mutated onto what became the basis of our first game, mantaining the character, but swapping the idea of magic hats for magic feathers.

Original Concept Art.

Adapted Concept Art.


Careful consideration went into giving all our characters as much background story as possible. As fans of story driven games, this was a must for us, each character was made with so much backstory so that each and every character was important in some way or another for us. A good example is the good ol’ captain, a personal favorite of mine.

Captain Concept Art.


We decided to make a puzzle plattformer, something we are confortable doing, but adding a twist: The Mage cannot attack on any way, and enemies are scarce and level oriented. This means our player needs to overcome obstacles by cleverly using the tools at their disposal, the enviroment and the backstory provided on the stage itself. The enemies on itself would be the puzzles and the special monsters that are tightly integrated with the scene, being “another puzzle”, albeit a dangerous one.

Early concept of stage.


We wanted to give our game the feeling of old tales, beautiful but with lingering danger. This contrast is important and something we wanted to show a lot on our game. The pacifist side of a character that can’t kill, versus a forest that is actually trying to hunt you down.

Concept of “Beautiful” side

Concepts of the Danger Side of the Forest.


This pre-production went on for a good while, and we are not done with it totally, but the changes that will be made, are always thought to enhance the experience. We are happy to start the development of our game, and we will soon have a small demo for visual purposes.


2 Responses

  1. Christian Reyes A dijo:

    Excelente articulo para comenzar, tambien creo que la.historia detrás del juego es muy importante, la pre-producción es una tarea que no se evalúa correctamente, quisiera saber si aplican algún mecanismo.para dividir las tareas y los procesos, ya que eso tambien sienta las bases de un buen desarrollo, quierase o no al final se esta desarrollando software. Gracias por la info

    • HeavyBullets dijo:

      Por supuesto!… hemos variado hasta encontrar la “mejor” forma de dividirnos los trabajos (la que más nos acomoda a decir verdad) y hasta ahora hemos usado mucho la metodología tipo POD (aunque algo modificada a nuestro mini grupo).
      Para darte una idea, se define una tarea a seguir y se discute entre un grupo de gente (en nuestro caso 2 personas app), para luego ser validada por otro externo, el cual tiene una mirada un poco menos encariñada del tema. Si pasa de ese filtro, se crea una maqueta y se vuelve a validar, finalmente si se logra todo, se “produce” la escena y se entrega a post produccion.

      Esto es equivalente a hacer un “iterativo-incremental” en programación.

      Muchas veces también nos encontramos con problemas de produccion o post produccion que debemos resolver adelantadamente (como el agua, luces y cosas así) que se delegan al programador (yo) junto a nuestro artista técnico (rodrigo).

      Cualquier otra duda que tengas me la comentas… esto lo vamos variando pero hemos encontrado que la mejor forma de crear esto, es no seguir el concepto de GDD tipo WATERFALL, y hacerlo más iterativo, para hacerlo más dinámico y acorde a los ajustes que se deban dar.


Agregar un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *