Crear un videojuego desde cero con un nuevo equipo
Durante el mes de Octubre de 2017 a enero de 2018 algunos miembros del grupo de usuarios de unity de Hermosillo Sonora México nos planteamos la idea de comenzar a desarrollar videojuegos por parte de la comunidad, esto involucra varios desafíos, en este post tratamos de narrar los puntos claves que tener en cuenta cuando se busca desarrollar un videojuego con un equipo de trabajo con el que nunca se ha trabajado antes.
El videojuego que desarrollamos fué Hmoman Run, un juego del género runner para dispositivos móviles, disponible para iOs y Android. El equipo que trabajó en el proyecto fueron 10 personas, 2 de ellas se dedicaron a la música, 1 a los efectos de sonido, otros al diseño de los modelos 3D y arte, otros colaboraron con la experiencia de usuario y diseño de la interfáz de usuario, yo colaboré con las mecánicas básicas del juego.
Definir el alcance
En una pequeña reunión entre los interesados a crear el juego, nos encargamos de hacer una lluvia de ideas acerca de lo que queríamos lograr, el consenso general fue “Hacer un juego sencillo, pulirlo y publicarlo”. En esa lluvia de ideas se definió una terminación del proyecto, ya que todos los involucrados tenían un trabajo de tiempo completo y proyectos personales en los que trabajar, así que decidimos establecer firmemente el tiempo del fin del proyecto para no abusar del tiempo de los involucrados y a la vez, no terminar con un proyecto eterno, el tiempo del proyecto sería de 3 meses.
En cuanto al género, en esa misma reunión se decidió tras varias ideas. Las opiniones de todos eran igual de válidas, si alguien tenía una idea para un juego (que generalmente, siempre se tiene) las exponía al grupo y se analizaba entre todos su viabilidad para el tiempo que se quería alcanzar, tras varias opciones optamos por un runner, y sobre ese runner se definió cuáles serían las mecánicas básicas que debería de cumplir.
Durante la definición de las características básicas del juego, se escucharon todas las ideas, pero se fueron descartando las que excedían la complejidad del proyecto, dado que pese a ser muy buenas ideas, ya sea por la falta de experiencia del equipo, o por que no le agregaba el suficiente valor para justificar el desarrollo, no podríamos seguir adelante con esa idea.
Definir la fecha de entrega
Al final de la reunión, antes de que todos salieran del lugar, quisimos recalcar la fecha de entrega, ya teníamos definidas las mecánicas básicas del juego, como íbamos a trabajar, pero quisimos sacar la cuenta de los días que faltaban para que se acabara el proyecto, con el fin de que la fecha les fuera más real. Definimos la fecha de entrega como el 14 de diciembre del 2017, justo antes de que todo el mundo saliera de vacaciones navideñas.
Definir las tareas
Después de definir el alcance teníamos una idea general de cuáles serían las posibles acciones que podría hacer el jugador y hasta donde llegaría el proyecto, en una reunión no presencial a través de Google Hangout platicamos acerca de las tareas que deberíamos de completar para terminar el juego y las anotamos en Trello.
Empezamos desde las tareas más sencillas y las describimos con nombres generales o a manera de lista de deseos del tipo “El jugador puede moverse de izquierda a derecha”, “El jugador puede saltar”, “El jugador puede recolectar artículos”, “El jugador puede ganar”, “El jugador puede perder”. Conforme delimitamos cuales eran las actividades básicas que debía de cumplir el juego, pudimos continuar con las actividades que no eran necesarias pero queríamos implementar, cuidando siempre el no salirse del alcance como “Agregar música al ganar”, “Agregar música al perder”, “Diseñar el menú principal”, “Guardar el progreso del jugador”.
En este paso, si alguien mencionaba alguna tarea que se saliera del alcance inicial, los otros miembros debían de procurar escuchar la propuesta y evaluar el valor que agregaría al proyecto, por ejemplo, se aceptarían tareas nuevas del tipo “Procurar que la experiencia de usuario del jugador sea cómoda al desplazarse por el menú de inicio”, mientras tanto “Que el jugador pueda disparar” se saldría del alcance y sería negada, ya que una nueva dinámica para el videojuego impactaría en distintas fases del desarrollo y áreas específicas como las mecánicas del juego, nuevos modelos para disparar, programación de los controles, pruebas, etc.
Seguimiento de las tareas
Una vez que las tareas fueron creadas, y debido a la naturaleza del proyecto (Todos los miembros del equipo tienen un trabajo fijo de 8 horas por día y trabajan en sus tiempos libres en el proyecto) se decidió que cada quién se auto-asignara las tareas que le gustaría trabajar en ella y/o tuviera más habilidad para apoyar el proyecto. Esto nos permitió llevar el proyecto en un ambiente más relajado y auto-manejable en el que los miembros del equipo producían según su capacidad y disposición, así no hubo problemas sobre qué actividades debía de hacer quién ni tampoco se visualizó a algún integrante en particular como “líder del proyecto” lo que motivó de manera muy positivo a todo el equipo.
Pruebas
Se eligió un repositorio en Github en el que todo el proyecto se alojaría, así mismo, cada que una nueva implementación de una mecánica en particular se terminara, se creaba un build del proyecto y se ponía a disposición de manera interna entre el equipo de trabajo para escuchar la retroalimentación de todos, a su vez, algunos de estos builds los compartimos con amigos y familiares para escuchar las opiniones de personas que no estuvieran involucradas en el proyecto, las opiniones frescas son sumamente valiosas durante todo el ciclo del desarrollo de un videojuego.
Fin del proyecto
Se llegó la fecha final del proyecto, el 14 de diciembre de 2017 y el proyecto estaba completo, sin embargo, un miembro del equipo (Sergio) superó las expectativas del equipo al integrar una herramienta que facilitaba enormemente el proceso de crear niveles, por lo que decidimos extender la fecha de culminación de lanzamiento por un mes más, para dar oportunidad de crear nuevos niveles para el juego lo que le dió mucho valor adicional a Hmoman Run.
La regla de los niveles era de que pudieran ser posibles pasarlos con 3 estrellas por la persona que los creó, tarea en la que colaboraron varias personas, después se acomodaron los niveles por la dificultad y al final logramos tener un videojuego mucho más profesional.
Lanzamiento
El 17 de enero se lanzaron las versión para iOs y Android. Se le dió una promoción local entre amigos, conocidos y familiares, por parte de la comunidad de Unity User Group HMO, ya que el proyecto no se pensaba monetizar y funcionaba como un ejercicio de desarrollo entre los involucrados en su tiempo libre, no se consideró el pagar por publicidad ni tener un plan de marketing que iniciara antes del lanzamiento.
Feedback
El videojuego fue bien recibido, el buen trabajo de los involucrados se hizo notar y las personas que lo jugaban se daban cuenta de ello, no se sentía como un juego hecho por hobby (que lo era) ni por aficionado (que lo somos), pero gracias al esfuerzo de los artistas alcanzamos un nivel de calidad muy superior del que nos habíamos imaginado al inicio del proyecto.
Hermografia, una página local de infografías se puso en contacto con un miembro del equipo para realizar una imagen publicitaria para Hmoman Run, en ella y sin que nosotros lo supiéramos, se hacía una relación con el nombre del personaje Hmoman (que fué el nombre de la mascota del Unity User Group HMO) con la ciudad de Hermosillo (donde vivimos) y el pésimo estado de las calles de ésta, en dicho post se hacía referencia a que Hmoman tenía que saltar los baches de la ciudad de Hermosillo en este futuro apocalíptico, al equipo le pareció graciosa la relación que se hizo ya que en el diseño del juego no se había planteado una ciudad en específico, fue básicamente “Una ciudad del futuro, con carros descompuestos como obstáculos y agujeros donde el jugador se caiga”.
Ese post fué la mejor publicidad que pudimos haber tenido.
Debido al alcance que tiene Hermografía en la localidad, nuestro juego fué visible para personas de la ciudad, poco tiempo después, los medios de radio y televisión hicieron contacto con el Unity User Group HMO para hacernos una entrevista y a su vez, publicar esa nota en sus redes sociales.
Post mortem
Con más de mil descargas entre iOs y Android, Hmoman Run superó las expectativas que teníamos sobre nuestro primer juego en conjunto, cumplió la función de aprendizaje de un equipo de trabajo descentralizado, remoto, y con poca experiencia en el desarrollo de videojuegos, y cumplió con creces la principal razón por la que decidimos hacerlo,dar a conocer el Unity User Group de nuestra ciudad.
This is the basic attack of the Player on Witch Tower, it’s an animated beam of energy with some simple energy surrounding it, as it happens so fast, it’s rarely noticiable, but I like the result.
For some enemies, that beam is inverted on the Y axis and tinted of another color so it looks different.
Added a Parallax Scrolling Backgroun in a vertical Position, so it looks like the camera is always going up, and the player needs to keep on certain position while defeating enemies.
In this gif you can see the image And little by little we are replacing the placeholder art for current art. Also in this image, we can see the “Bomb” item, that defeats every enemy on screen but has no effect against bosses on Boss battles.
Been working on replacing the placeholder art with the original art of the game, in this image, I have added the art of the main character, a Good Witch with no name yet, and her Fairy Friend, also, the coins have its own art an animation.
In this gif we can see the core mechanics of the game, you defeat enemies by shooting magic at them, the enemies give the player some points, the player collects items, and have to defend the fairy of danger.
When the Score bar is full, and the stage is one “Boss Stage” a Boss will appear, this boss is a special kind of enemy that the player will have to defeat in order to pass to the next level.
While the Boss is still alive, enemies of that level will keep spawning and the score bar will not go further. Once the boss is defeated the Fairy pick up the Player and carry it to the next stage.
In this update, I introduced a new kind of enemy, a shooter, in this stage of development, all the art is still a placeholder and in order to identify enemies from one kind to other, I change the tint values to red.
Shooters can spawn objects, and all the mechanic of going upwards and damage the fairy is all from the bullet code.
If you pay closer attention to this gif, in middle of the screen, ath the right of the score bar, there is a brown arrow, that is also a placeholder of a new mechanic.
The player will be able to collect items to use agains enemies, in this case, it’s a bomb that clears all the enemies in the screen, including projectiles.
In this particular gif, I had some issues implementing that feature, and found the result hilarious so I had to share it with you dear reader.
Made an update about the flow of the game, every time you defeat an enemy you get a random reward from the flying fairy, in this scene, with help of a mana boost, you get a triple attack, and defeat two enemies at the same time, because of that, the fairy drops you two random rewards at the same time, in this case, those rewards were coins.
Added a “Win state”, every enemy you defeat gives you certain points, and every level have a certain amount of points that the player must reach in order to beat that level.
Once the player reaches the goal of certain score, the fairy friend will pick up the player and carry it to the next level.
When the player is waiting to be picked up, it can not move, this was decided because it could be problematic for the fairy friend to reach the player if it was keep moving.
Besides Coins there are “Mana Bottles”, that gives the player the ability of shooting multiple attacks at once, the mana is increased by the mana bottle item, and is spend every time the player press the attack button, a triple attack only spends 1 Mana point.
In this update, I added a respawn feature, if the player dies by reaching the botom of the screen, it will respawn at the top of the platforms, always in the middle, that is the safer place I think.
Added a mana meter, one of the items that the flying totem that the player must protect can randomly throw when you defeat an enemy is a mana bottle.
Also, added a “Game Over screen”
In every level certains variables can be set as “rules” of that level. Those variables can be:
-Current and max player’s health.
-Current and max Totem to protect health.
-Current and max player’s mana.
-How mant points is neaded to pass to the next level.
-If the current level has a boss at the end.
-Global speed of the game (which affects platforms, enemies and spawn rates of game objects).
Added some enemies to the game, as you can see is still the same sprite of Ropemania but with different tint, this is because I like to implement features and mechanics first and once they are polished, draw the game art.
The basic behavior of the enemies is:
-Spawn at certain point.
-Every Enemy has it’s own Health points.
-Every Enemy has it’s own experience points that once defeated, will increase the player’s score.
-Start moving upwards.
-At certain height, move towards the Totem that the player is protecting.
-Once the enemy has reached the totem (in this case, the yellow kid) it will inflict damage on the totem.
The totem has certain Health points, and once it reaches 0, it’s game over.
Also, if the player falls from the platforms to the void multiple times, each time will take a life from it, and once it reaches 0, it is also game over.
In order to win the game, the player must defeat enough enemies so it can reach that stage “max score”, that will take the player to the next stage.
Started playing with the idea and core mechanics of this game, and infinite “upscroller” with enemies coming up from the bottom of the screen and you can only shoot downwards.
I’m still using the placeholder art of ropemania and made some basic UI buttons to start shaping the way the game will feel like.
In order of save time making new assets the projectile that the player shoots are the same sprite as the “action” button.
Also, added a coin counter and some coins (also with a sprite of a UI button) so the player can collect coins and later on it will be able to spend it in a way.
This mechanic was quite useful because it let me explore others options for new items of different kind that will trigger new game mechanics.
I put a ground at the botom of the screen because it's easier to prototype and debug features without falling and loosing the game. In the final version there will be no ground so the player will have to use the platforms im order to win the game.
During the global game jam 2017 we pitched a lot of ideas during brainstorming, I pitched the idea of a wave that rise above the ocean in wich the player will be avoiding jumping upwards in platforms in a tower.
That game mechanic stick with me while we were developing Tsunami Adventure, and once the global game jam was done, I decided to make a proper game out of this idea.
The first thing I would do was reuse old art as placeholder from my game ropemania and use a gray brick tile that ended never using in a game until today.
I decided to make it in Unity and make a little game in 2D, I started working in the player movement and make that it could step on platforms and jump between those.
Tsunami Adventure was the name of the game my team developed during the Global Game jam 2017.
You can see the info of the game here:
http://globalgamejam.org/2017/games/tsunami-adventure
And you can find a stable build on github:
https://github.com/Ucamo/GGJ17_Tsunami
This year the theme was “waves” and the challenge was to make a game with that theme in 72 hours.
My team took the theme quite literally and decided to make an infinite runner in a city in the process of being hit by a Tsunami, you can help civilians while running from a giant wave and doing so will give you a little boost forward, you can also collect coins but it will not help you at all.
gummygunk
blakekathryn
theartofmadeline
janainaart