Energy Up: Como hacer un juego sin recursos para no iniciados

Todos los que nos dedicamos al mundo de los juegos nos preguntamos alguna vez cual es el objetivo de nuestro trabajo. Evidentemente el primer objetivo es hacer un producto lúdico que sea divertido, pero detrás de estas palabras creo que hay mucho más.

Es demasiado fácil hacer la secuencia de acontecimientos mental pensando que si lo conseguimos una cosa llevará a la otra… si es divertido los jugadores se lo descargan,  tendremos buenas críticas, el boca oreja nos hará conseguir más descargas... y más usuarios significará más ingresos… y los que llevamos un tiempo en esto sabemos no es así. 

Hacer un juego es una cuestión de equilibrio… y hacer un juego en solitario o con un grupo pequeño de personas aún más. Es muy importante saber dosificar los esfuerzos y ser consciente que aunque nos saltemos algunos pasos, que los estudios si hacen y tienen recursos para ello, lo que hagamos vaya en la dirección correcta… dicho de otra manera, se pueden obviar pasos pero se debe ser consciente de ello… 

Como podéis imaginar el primer paso es hacer una buena planificación y diseño. En resumidas cuentas, ser capaz de cuantificar el volumen de trabajo para estar seguros que terminaremos el proyecto. A partir de ahí hacer dibujos, esbozos, mapas y definir las mecánicas.

En general es bueno poner objetivos cada cierto tiempo para ir cerrando cada etapa del desarrollo. Los estudios usan SCRUM u otras metodologías Agiles para trabajar en equipo e ir visualizando el trabajo etapa a etapa. Haced algo parecido adaptado a vuestra realidad. Yo utilizo Trello para apuntarme todas las acciones que tengo que hacer.  

En segundo lugar hacer un prototipo. Podemos poner cubos en vez de personajes e implementar las mecánicas básicas. Sólo eso… no intentéis ir más allá. Si probamos el prototipo y creéis que funciona… Adelante… y no os de pereza rectificar… mejor ahora que más adelante.

Si el prototipo funciona… haced el motor del juego con las demás mecánicas. Pensad bien en las estructuras de datos que vais a necesitar. ¿Cómo guardaremos los datos (PlayerPref, XML, JSON…)? ¿Las guardaremos en local o en un servidor externo?

Es muy importante que sepáis definir en valores numéricos los niveles o avances del jugador en el juego. Números, números y más números… esto nos permitirá balancear el juego más adelante. Un estudio tiene gente especializada para ello… pero aunque sea a pequeña escala es muy importante ya que afecta a la sensación lúdica del jugador… ya sabéis… fácil de jugar, difícil de dominar.

Después de trabajar en ello haced una buena UI/UX. El jugador debe sentirse a gusto con nuestra interfaz. Aunque de pereza… poned brilli, brilli… a los jugadores les gustan estos efectos que refleja que la interfaz ha sido trabajada. 

Definid bien las recompensas. Si lo habéis hecho bien seguro que las habréis definido en la fase de diseño, sino no avancéis más y ponedle atención a ello. A los jugadores les gusta ser recompensados por sus avances en el juego. Además es un elemento muy importante en la economía interna del juego. ¿Usareis algún tipo de moneda interna? ¿Podéis comprar/vender con dicha moneda? ¿Recompensas a cambio de ver anuncios? ¿Podéis comprar objetos o power ups? ¿Regalos al volver al juego para fidelizar al jugador? Estos elementos deberían estar integrados dentro de las mecánicas del juego si es que deben existir y no ser un elemento añadido artificialmente para retener o ganar algo más de dinero, porque a la larga no funcionan. 

La economía del juego también consiste en poner valor a las cosas con las que interactúa el jugador y tiene mucho que ver con el diseño económico del juego en general y el balance del juego. Podremos definir una buena economía si previamente hemos puesto números a los avances del jugador en las etapas del juego. Lo he dicho hace unos párrafos más arriba… combinado con las recompensar y los coste de cada etapa del juego. Aunque parezca mentira habrá que trabajar en MS Excel y hacer algunos cálculos.

Una vez definidos los elementos clave os propongo definir los niveles, haceros una herramienta para genéralos y poder hacer cambios con facilidad si lo necesitáis y en todo caso definid las estructuras de datos para que sean fácilmente flexibles por si tenéis que retocar aspectos que hasta ahora no habíais tenido en cuenta. Con la experiencia uno aprende a definir las estructuras de datos lo más modulares posibles, clases abstractas, herencia, polimorfismo y estas cosas del mundo de la programación… y a poder ser pensadas en la etapa de diseño para ahorrarnos tener que rehacer código.



Con los datos de balanceo del juego y la definición económica del juego deberíamos poder hacer los niveles compensados, divertidos y con dificultad ajustada para tener al jugador en el área diversión el máximo tiempo posible.


Una vez terminado el juego… invertid un poco de tiempo a poner algo más de efectos a todas las partes del juego… aquellos pequeños detalles que el jugador no ve, pero si se perciben y dan al juego un aspecto profesional. Cuidad los detalles, son la diferencia entre un buen trabajo y un trabajo excelente. Haced buenos tutoriales integrados en el juego y aseguraros que le jugador entiende que tiene que hacer.

Probad, probad y probad vuestro juego… y a poder ser por gente ajena a vosotros. Escuchad las críticas y aprended a diferenciar lo que es una opinión a lo que es una crítica objetiva. Estas últimas son las importantes.

Añadid algún sistema de obtener KPI’s de vuestro juego. GameAnalytics, Google Firebase… son buenas herramientas para saber más de User flow de los jugadores y aprender de como usan el juego. Que no os de pereza invertir unos días a diseñar un buen sistema de análisis ya que en el futuro os servirá para aprender mucho de cómo han salido las cosas.

Por ultimo dejad descansar el juego unas semanas… si, lo que habéis leído. Yo recomiendo dejar el proyecto terminado un par de semanas y retomarlo con la energía renovada. Cuando uno ha hecho tantas cosas es muy fácil sentirse abrumado por el esfuerzo realizado y perder la perspectiva. Dejad el proyecto en fase beta y centraros en recoger la opinión y apuntad lo más relevante. Una vez pasado el tiempo… rectificad todo lo que consideréis esencial y lanzad vuestro proyecto.

Una vez lancéis vuestro juego sólo habéis llegado a la mitad del proceso. Haced un lanzamiento suave (pocos países y analizad los datos estadísticos), haced cambios y analizad los resultados de los mismos y cuando estéis seguros lanzad vuestro juego a lo grande… bueno, tan grande como un desarrollador indie puede permitirse… pero con el orgullo de haber hecho las cosas bien. 

Una vez lanzado el proyecto analizad los KPI’s y haced los cambios que puedan mejorar la retención de usuario, aumentar las ventas internas del juego o aumentar el tiempo de juego. Localizad el juego a varios idiomas y si es necesario añadid contenido. En un estudio las LiveOp son muy importantes y tienen un equipo para ello, vosotros pensad si os sale a cuenta en función de la relación coste/beneficio o si el objetivo del proyecto era sólo económico, formativo o para haceros un portafolio. 

Una vez lanzado el juego debemos centrar nuestros esfuerzos en diseñar una campaña de lanzamiento, usar las redes sociales, decidir si queremos invertir en publicidad o no y gestionar las opiniones de los usuarios... ver los resultados, leer las opiniones y aprender de todo el proceso para que el próximo proyecto sea mejor… 

Proyecto: Energy UP
Plataforma: Android
Descarga gratuita: Goole Play

No hay comentarios:

Publicar un comentario

Como hacer copias de tu código de Unity con GitHub

Podriamos escribir un libro entero de las bondades de Git para el trabajo colaborativo y la gestión de versiones en un entorno como Unity. D...