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.
