6.4 Sobre el jugador
9. Gestión Económica
9.1. Coste del proyecto
Para el coste del proyecto se van a calcular las horas/programador y horas/diseñador de manera muy aproximada. No se va a tener en consideración costes de hardware ni software por lo que el cálculo puede ser irreal, por las siguientes razones:
- El uso de licencias de estudiante (Adobe Photoshop y 3D Studio Max) o directamente licencias gratuitas (Unity3D) para el desarrollo del juego. - El uso de equipos de hardware antiguos (2012-2014) para el desarrollo
del juego.
En caso que se requiriese un nuevo equipo, se podría calcular en un equipo estándar valorado en 900€:
- Procesador: AMD Ryzen 5 2600 3.9 Ghz - Placa Base: Asus B450M
- Discos duros: SSD 240GB SATA3
- Memoria: DDR4 3000 PC4-24000 16GB 2x8GB CL15 - Gráfica: GTX 1650
- Otros elementos (torre, fuente de alimentación) - Pantalla, teclado, ratón y tableta Wacom.
Para subir la aplicación a Google Play, se debe contar con una cuenta de desarrollo que cuesta 25$ (23€ aprox) en un pago único.
La compra de Assets mediante la plataforma Humble Bundle (varios conjuntos de Assets de gráficos y sonido) ha tenido un valor aproximado de 42€ en un pago único.
El tiempo de desarrollo del motor de juego y diseño ha sido 6 meses a media jornada cada día (excluyendo fines de semana) por lo que 123 días laborables a 4 horas cada día son un total de 492 horas. A 25 €/hora de programación y diseñador se calculan un total de 12300€ brutos (por lo que se debería descontar impuestos).
El tiempo de desarrollo de los modelos 3D y animaciones ha sido de 2 meses a media jornada cada día (excluyendo fines de semana) por lo que 42 días laborables a 4 horas cada día son un total de 168 horas. A 20 €/hora se calculan un total de 3360€ brutos (por lo que se debería descontar impuestos).
El coste del proyecto da un total de 16625€. Cabe remarcar que es un coste aproximado ya que el precio/hora y el valor del equipo de hardware son orientativos.
9.2. Monetización
Para la monetización del producto se plantean varias posibilidades:
● Un único pago. Según los resultados de la encuesta, un 25% pagaría entre 3 y 5€ por una versión finalizada del mismo, un 19% entre 1 y 3€ y un 13% por menos de un 1€. El resto (43%) dependería del producto resultado o directamente no pagaría. Aunque visto así el pago único parece una buena opción, la muestra de la encuesta no es significativa (unas 15 personas) y, aunque haya interés en un único pago, no se puede asegurar que estos resultados sean del todo reales. ● Publicidad in-game. Añadir anuncios usando las librerías de Google Ads en puntos clave del juego, como por ejemplo antes de bajar a la mazmorra. Esta es una de las opciones más plausibles para el diseño del juego actual. Aun así, existe el riesgo de cansar al usuario debido a la saturación de anuncios.
● Free-to-play. El jugador tiene acceso a todo el contenido, pero de manera limitada. En este caso, se podrían limitar las exploraciones a la mazmorra según un parámetro (energía) y que se pudiera comprar pociones de energía para poder seguir jugando, o esperar 8 horas a que el personaje descanse. Este modelo, parecido al pay-for-win, es muy criticado por los jugadores pues no permite jugar y corta muchísimo el flujo del juego.
Para realizar alguna de las 3 opciones propuestas, se podría añadir algún edificio nuevo en la Villa que resultara muy atractivo para las mecánicas del juego:
- Quiosco donde comprar sobres que contienen cartas al azar. - Poder mezclar 2 cartas para que salga 1 nueva y más poderosa al
azar.
- Disponer de potenciadores (power-ups) para la próxima aventura en la mazmorra: más vida, más ataque, ...
Estas acciones estarían limitadas 1 vez al día, o siempre que se quiera si: - Se visualiza un anuncio.
- Se paga una única vez entre 3€ y 5€, pues es el valor más seleccionado entre los usuarios de prueba, desbloqueando el edificio sin limite de tiempo alguno.
Logrando así una mezcla entre pago único y publicidad in-game.
Esta decisión ha de tomarse sin riesgo a que el juego quede desbalanceado entre la gente que haya pagado como la que juegue de manera gratuita, así que posiblemente la mejor opción sea la idea de mezclar 2, cartas ya que se pueden controlar las recetas de la mezcla mediante un algoritmo.
10. Conclusiones
Realizar este proyecto ha sido muy enriquecedor tanto a nivel personal como profesional. No solo se ha terminado el trabajo con una versión bastante definida publicada en Google Play sino que además se ha recibido feedback del juego por parte de usuarios reales. El juego es, como se ha propuesto desde buen principio, un producto para usuarios asiduos (y consolidados como jugadores) adaptado a la interfaz móvil y los límites que ésta ofrece.
Una de las primeras lecciones aprendidas es que la realización de un prototipo y extraer conclusiones de él resulta muy útil. Aunque pueda parecer una pérdida de tiempo inicial, ahorrará tiempo en el desarrollo de elementos que añaden poco o nada al proyecto o que deban modificarse desde buen inicio. Así pues, se ha seguido con la planificación al detalle, desviándose en contadas ocasiones y, es más, añadiendo puntos extra durante el desarrollo que han aportado calidad al producto.
De cara al final del proyecto, uno de los trabajos más costos ha sido la realización de un sistema multiidioma y adaptar todos los campos de interfaz a este sistema. Fueron días de trabajo que podrían haberse repartido durante el inicio del desarrollo, pero que no se tuvo en cuenta. En este sentido, debería haberse planificado durante el desarrollo del mismo y no como hito opcional.
Por parte de las pruebas de usuario, quizá ha sido una de las partes más enriquecedoras del proyecto, pues en algunos puntos es importante ver donde el juego falla y si se puede solucionar de una manera fácil, rápida y eficaz. En realidad, ha habido dos grandes grupos de beta testers: los 10 iniciales que jugaron a versiones entre v0.94 y v0.96 y los nuevos con la versión v0.96 y superiores, con cambios como el multiidioma o ayudas y videos en puntos donde los primeros se sentían más perdidos..
Lo que está claro es que como desarrollador, se acaba con unas malas prácticas y conocimientos que el nuevo usuario A ello se le suma que el sistema y algunas mecánicas son nuevas, no recuerdan a “nada” (no es un plataformas, no es un FPS, ni un juego de estrategia o construcción), por lo que jugar por asociación o saber que cartas aparecen o desaparecen es algo que el juego debe enseñar y el jugador debe aprender.
Pienso que el producto final es robusto, tiene posibilidades y, lo mejor de todo, es que algunos usuarios de test también lo piensan. En este punto se abren muchas posibilidades y, como muchos usuarios indican, llenar el juego de cartas, niveles, enemigos y, en general, contenido, hará que el juego sea una evolución de la vertical slice presentada. Al final, el objeto es generar un producto lo suficientemente atractivo como para que la gente lo adquiera.
11. Glosario
Asset: Elemento de Unity3D que tiene valor por sí mismo y es independiente del motor de juego actual, por lo que se puede usar en distintos proyectos: elemento audiovisual, base de datos, ...
Frame: Fotograma o imagen que se repite un número de veces por segundo en un videojuego, entre 30 y 60 frames por segundo. Implica la velocidad de refresco y sensación de fluidez en el juego.
GameObject: Elemento estructural de Unity3D que puede contener distintos subelementos o componentes y que describen su comportamiento: scripts, sprites, sonido, ...
IDE: Integrated Development Environment, entorno de desarrollo integrado. NPC: Non player Character, personaje no jugador.
Prefab: Conjunto de GameObjects almacenado como un único objeto para poder ser utilizado o instanciado y que se usa como plantilla para generar otros objetos.
RPG: Role Playing Game, juego de rol.
Rigging: Añadir un sistema de control en un modelo 2D o 3D, normalmente conocido como huesos y su influencia en modelo, para su futura animación.
Singleton: patrón de diseño de programación, se genera una instancia única de un objeto y permite que todos los elementos tengan un acceso global a ella.
Script: fichero de código, en el caso de Unity3D en lenguaje C#. Sprite: imagen en formato mapa de bits.
XML: Siglas de eXtensible Markup Language. Lenguaje con marcas que facilita la estructura y lectura del mismo fichero.
12. Agradecimientos
Primero de todo me gustaría agradecer a la gente que me ha ayudado a realizar este proyecto de una manera directa: A Héctor Ariza y Kepa Izeta por su trabajo, así como los usuarios de test, tanto los conocidos (Jesús Escribano, Alberto Hidalgo, Adriana Fernández, Andrea Sospedra y muchos otros) como los desconocidos. A mis compañeros de trabajo de la UPC que están y han pasado por el lab, Marc Mateus, Fede Guede, Sergio Guerrero, Víctor Ferrer y Antonio López, que también han probado el juego y me han dado feedback, y que a veces han echo la vista gorda cuando me documentaba.
A mis compañeros de La Universitat Invisible, por aguantarme, muchos ya nombrados, pero que me dejo a Enric Garriga, Joan García y David Cruz.
A mis betatesters más roleros, Toni Garí y Joan Segovia.
A mis amigos de toda la vida que han hecho difusión del proyecto y me han regalado algunas ideas de manera consciente o inconsciente, Chema Peral, Jaime Agramunt y Adrià Castillón.
Finalmente, y mucho más importantes, agradecer a mi padre Ramón y mi hermana Elisabeth, también a mi pareja Gema Terol, por aguantarme y estar siempre ahí para mi cuando los necesito, y que a pesar de todo me siguen queriendo. Agradecer a los perros de la casa, que fueron como familia para mi aunque ellos no lo supieran, y que he intentado homenajearlos de la mejor manera posible. Agradecer a los familiares que no están ya conmigo, pero que me han ayudado a ser quien soy: os echo mucho de menos.
I. Bibliografía
Literatura
[1]. Afilias Technologies Limited, (2019)[En línea] Most used smartphone screen resolutions in 2019 [Consultado en Marzo de 2019]
<https://deviceatlas.com/blog/most-used-smartphone-screen-resolutions >
[2]. Quora; Ryan Toh, (2017) [En línea]. When did smartphones become popular?. [Consultado el Abril de 2019]
<https://www.quora.com/When-did-smartphones-become-popular>
[3]. UX Matters; Steven Hobber Toh, (2013) [En línea]. How do users really hold mobile devices?. [Consultado el Marzo de 2019]
<https://www.uxmatters.com/mt/archives/2013/02/how-do-users-really-hold-mobile-devices.php>
Tutoriales y Software de interés
[4]. Atlassian, (2011-2019)[En línea] Trello [Consultado en Enero - Junio 2019]
<https://trello.com/b/daWDj5gK/tfm-deckgeon >
[5]. GameDev Network Limited, (2019)[En línea] GameDev Marketplace. [Consultado en Marzo de 2019]
<https://www.gamedevmarket.net/ >
[6]. Humble Bundle Inc., (2018)[En línea] Humble Bundle Store. [Consultado entre Enero y Abril de 2019]
<https://www.humblebundle.com/>
[7]. Youtube; Brackeys, (2018)[En línea] Unity tutorial:Animate 2D characters in Unity [Consultado en Junio de 2019]
<https://www.youtube.com/watch?v=eXIuizGzY2A>
[8]. Youtube; Brackeys, (2017)[En línea] Unity tutorial: How to make a dialogue system [Consultado en Mayo de 2019]
<https://www.youtube.com/watch?v=_nRzoTzeyxU>
Juegos
[9]. Nintendo EAD (1986). The Legend of Zelda.
[10]. Square Enix(1986). Dragon Quest.
[11]. TinyTouchTales(2018). Card Crawl.