Por si aún no os habéis enterado, me encuentro ahora mismo en fase de concepción de un juego que quiero sacar para Game Boy (con su cartucho y todo) y en este blog quiero ir compartiendo mis avances y reflexiones sobre el diseño y desarrollo del juego, así como lo efectivas o desastrosas que van siendo las metodologías que voy utilizando. Y bueno, ya han pasado 6 meses desde la última entrada que dediqué a mi “Proyecto Isekai” (nombre provisional).
Lo primero que quiero compartiros es que a nivel de planning ha sido un completo fiasco: Ya han pasado 9 meses desde que anuncié el nacimiento del proyecto y no tengo siquiera un prototipo que mostrar. Y bueno, no buscaré excusas, pero se me hace complicado conciliar mi vida laboral con la personal; Y en lo que respecta a la personal, se me hace tremendamente difícil dedicarle tiempo a mi familia y a mis aficiones.
Pero bueno, vamos a hablar de lo guay: Como bien dije en entradas anteriores, me puse a desarrollar un POC (“probe of concept”) para ver si varias de mis teorías podían aplicarse en el punto de vista técnico y los resultados fueron muy reveladores:
- Encontré el trozo de código fuente que limitaba el número de variables que podemos asignar en GB Studio y compilé una versión de éste que permitía trabajar con unas 4.000 variables; Después, hice un proyecto vacío donde editaba la variable número 3999, usé comandos de guardado y recuperación y el “juego” funcionaba perfectamente emulado y en hardware original. Sobre el papel la batería podría darme unas 32.000 variables, pero preferí hacer pruebas más reducidas al no saber cómo gestiona el framework la memoria RAM: La consola tiene 8KB y en esa memoria debemos de almacenar el binario de ejecución, las 4000 variables y hay que reservar otro número considerable de variables internas asociadas al framework (ID de la escena a cargar, gráfico de los actores, posición de estos, etc); Vamos, que aunque una pila me permita almacenar 32.000 variables, pero la consola sólo puede tener en memoria unos 8.000 bytes de los cuales reservé un 50% sólo para variables.
- También vi que GB Studio permite trabajar con “medias” variables. Es decir, por defecto el framework ya te permite coger un byte y dividirlo en dos, de forma que una variable de tipo byte pueda ser usado como dos variables de 4 bits.
- En ese sentido está bien saber que podemos superar la barrera de las 512 variables (1024 si jugamos con medias variables), pero conviene pensar un valor que no sature la RAM de la consola. Trabajar con 1024 variables (o 2048 “medias” variables) parece una opción viable.
- Me llevé una sorpresa al comprobar que no existe ningún sistema de combate implementado. No es cupla de los desarrolladores, pero es algo que mucha gente da por hecho cuando le dan a entender que estamos ante un clon del RPG Maker. Esto implica dos cosas: La primera es que el programador debe de construir todo el sistema de combates desde cero; La segunda es que hay que reservar un rango de variables (que no había previsto) para poder hacer uso del sistema.
- Pero no sólo eso, el framework carece de sistemas de “party”, ítems o posadas. Básicamente, tienes que "programar” todo eso a base de scripts. Pero los scripts a su vez son un conglomerado de acciones “reutilizables” en distintas escenas. Vamos, que al final lo único común con RPG Maker es la vista desde arriba y las acciones básicas de los actores. El resto te lo tienes que cocinar de forma rudimentaria y haciendo uso de mucha mañana e imaginación.
- Y cuando aún no había acabado de probar todo lo que quería probar, sale por sorpresa y sin previo aviso GB Studio 3.0. Lo que implicaba tener que estudiar los cambios en limitaciones entre el 2.0 y el 3.0 (sí, más que fijarme en las mejoras, me fijo en las limitaciones).
Lo primero que quiero compartiros es que a nivel de planning ha sido un completo fiasco: Ya han pasado 9 meses desde que anuncié el nacimiento del proyecto y no tengo siquiera un prototipo que mostrar. Y bueno, no buscaré excusas, pero se me hace complicado conciliar mi vida laboral con la personal; Y en lo que respecta a la personal, se me hace tremendamente difícil dedicarle tiempo a mi familia y a mis aficiones.
Pero bueno, vamos a hablar de lo guay: Como bien dije en entradas anteriores, me puse a desarrollar un POC (“probe of concept”) para ver si varias de mis teorías podían aplicarse en el punto de vista técnico y los resultados fueron muy reveladores:
- Encontré el trozo de código fuente que limitaba el número de variables que podemos asignar en GB Studio y compilé una versión de éste que permitía trabajar con unas 4.000 variables; Después, hice un proyecto vacío donde editaba la variable número 3999, usé comandos de guardado y recuperación y el “juego” funcionaba perfectamente emulado y en hardware original. Sobre el papel la batería podría darme unas 32.000 variables, pero preferí hacer pruebas más reducidas al no saber cómo gestiona el framework la memoria RAM: La consola tiene 8KB y en esa memoria debemos de almacenar el binario de ejecución, las 4000 variables y hay que reservar otro número considerable de variables internas asociadas al framework (ID de la escena a cargar, gráfico de los actores, posición de estos, etc); Vamos, que aunque una pila me permita almacenar 32.000 variables, pero la consola sólo puede tener en memoria unos 8.000 bytes de los cuales reservé un 50% sólo para variables.
- También vi que GB Studio permite trabajar con “medias” variables. Es decir, por defecto el framework ya te permite coger un byte y dividirlo en dos, de forma que una variable de tipo byte pueda ser usado como dos variables de 4 bits.
- En ese sentido está bien saber que podemos superar la barrera de las 512 variables (1024 si jugamos con medias variables), pero conviene pensar un valor que no sature la RAM de la consola. Trabajar con 1024 variables (o 2048 “medias” variables) parece una opción viable.
- Me llevé una sorpresa al comprobar que no existe ningún sistema de combate implementado. No es cupla de los desarrolladores, pero es algo que mucha gente da por hecho cuando le dan a entender que estamos ante un clon del RPG Maker. Esto implica dos cosas: La primera es que el programador debe de construir todo el sistema de combates desde cero; La segunda es que hay que reservar un rango de variables (que no había previsto) para poder hacer uso del sistema.
- Pero no sólo eso, el framework carece de sistemas de “party”, ítems o posadas. Básicamente, tienes que "programar” todo eso a base de scripts. Pero los scripts a su vez son un conglomerado de acciones “reutilizables” en distintas escenas. Vamos, que al final lo único común con RPG Maker es la vista desde arriba y las acciones básicas de los actores. El resto te lo tienes que cocinar de forma rudimentaria y haciendo uso de mucha mañana e imaginación.
- Y cuando aún no había acabado de probar todo lo que quería probar, sale por sorpresa y sin previo aviso GB Studio 3.0. Lo que implicaba tener que estudiar los cambios en limitaciones entre el 2.0 y el 3.0 (sí, más que fijarme en las mejoras, me fijo en las limitaciones).
¿Limitación de textos?
Aún no tengo claro cómo están almacenados los textos en la ROM o cómo se gestionan los scripts o la lista de acciones y eventos de los escenarios. Me da miedo que todo eso se traduzca al código del binario del juego (el lenguaje máquina que contiene las instrucciones a ejecutar). Para poneros en contexto, los cartuchos de Game Boy ocupan desde los 32 KB hasta los 4 MB, pero el código del binario debe de cargarse al encenderse la partida y se carga en la RAM de la consola, la cual está limitada a 8 KB, donde para más inri también tenemos que cargar las variables en ejecución.Ahora bien, en los foros de la comunidad veo que hay usuarios que han llegado a hacer más de 400 escenas sin tener problemas, por lo que entiendo que a nivel de la ROM los scripts, acciones, actores, strings, etc... se almacenan como si de un fichero de recursos se tratara y que el binario recupera esos recursos y los interpreta en función de una serie de reglas básicas. Esto implicaría que, sobre el papel, no tendríamos una limitación clara acerca de la cantidad de texto que podemos añadir al juego y que la limitación estaría más bien ligada a la capacidad del cartucho final y no a la memoria RAM de la consola.
Problemas para testear
He visto varios usuarios que comentan que el tiempo de compilación de la ROM depende mucho del número de escenas y que para generar un cartucho de varios megas el framework puede tirarse unas horas compilando, lo cual dificulta mucho poder testear determinadas condiciones (imaginad corregir algo, esperar dos horas, probar, ver otro error, corregir el otro error, esperar dos horas, volver a hacer la prueba...).
En vista que este framework no permite la elaboración de tests unitarios y que la forma de testeo es bastante rudimentaria, habrá que estudiar bien cómo podemos probar las modificaciones sin tener que esperar X horas cada vez que hagamos una modificación (la creación de un “debug-room” parece imprescindible). ¿Sería viable hacer algún tipo de script en bash que permita analizar el fichero del proyecto (está escrito en formato json) y analizar una a una las reglas y acciones?
Creación de herramientas externas
He observado que el fichero de proyecto está escrito en formato JSON y éste parece muy inteligible. No me parecería descabellado crear alguna aplicación con un par de formularios básicos que permitiera gestionar datos del juego al estilo RPG Maker. Estoy pensando por ejemplo en la pantalla donde definimos la totalidad de los personajes y sus stats, en la pantalla donde definimos los enemigos y sus grupos, en crear una pantalla donde gestionar la totalidad de las tiendas, etc.Cambio en el sistema de mecánicas
Durante todo este tiempo he ido meditando sobre las mecánicas del juego. Para daros el contexto, me asusta la idea de hacer un juego y que éste no sea divertido y para evitarlo he estado jugando a varios juegos clásicos de 16 bits y a bastantes juegos indies hechos con el RPG Maker.En lo que se refiere al RPG Maker, he notado que hay bastantes juegos que se dedican a crear un mapa extenso (algo que yo aspiro a hacer), pero ofreciendo muy poco contenido... Y es que ir descubriendo ciudades en las que no se te dan quests, los NPC no te dan conversaciones de interés y los objetos que te venden en sus tiendas no son nada especiales, pues no aporta nada al usuario salvo hacerle perder el tiempo. Pero también me pasó el caso contrario: Me sorprendió ver un montón de juegos donde la historia gira alrededor de una única zona (una ciudad, una casa, una isla...) y que a pesar de ello ofrecían un montón de contenido, en plan metroidvania.
Y bueno, con respecto a los clásicos de 16 bits (y alguno de 32), me quedo con dos títulos que me han llamado bastante la atención: Slayers y Romancing Saga 2 de Super Famicom (la SNES japonesa), dos grandes desconocidos en Occidente (aunque el Romancing Saga 2 fue relanzado al inglés en 2017 en la mayoría de tiendas digitales de consola y PC).
El primero, Slayers, me llamó la atención porque ofrece gran cantidad de detalles que de normal no vemos en muchos JRPG: Cuando vas a un restaurante y pides un menú los personajes van a una mesa libre, el camarero les trae la comida y podemos incluso si decir si nos ha gustado o no el plato; Al reservar una habitación en una posada ves cómo los personajes se dirigen a ésta; Al guardar la partida se nos muestra una caricatura burlesca de lo que Lina ha hecho durante el día; Se muestran muchas imágenes estáticas que ayudan a pasar por alto el débil apartado gráfico del juego; Y tiene muchos detalles de sentido común, como que la gente se enfada si entras en sus casa y te pones a abrir un cofre;
Y Romancing Saga 2... Me tiene enamorado. Un JRPG donde existe la muerte permanente (tienes un sistema de HP (Hit Points) y LP (Life Points): Cuando los HP de un personaje caen a 0 se resta 1 a los puntos de LP; Si los LP de ese personaje llegan a 0, el personaje muere para siempre); Y bueno, el personaje principal es el emperador del reino y si éste muere pasamos a manejar a su heredero e incluso hay saltos en la historia de más de 150 años donde manejamos a los sucesores de nuestro héroe; Y parte de la gracia de la historia es que vamos expandiendo el imperio, entablando alianzas, haciendo favores a otros pueblos, tomando decisiones políticas que impactan en el presupuesto de la nación... Y todo eso en un cartucho de 16 Mbits (2 MB) que salió a la venta en 1993. No se trata de un juego perfecto, pero es muy loable ver lo que han conseguido viendo las limitaciones del hardware.
Y en estos meses también he visto mucho ánime y leído bastantes mangas y hay varias ideas que me gustaría tomar prestadas: Me gusta el concepto de “regreso por muerte” de Re:Zero, donde a cada vez que el protagonista muere la historia vuelve a un save-state anterior en el que el protagonista es el único conocedor de los sucesos venideros, dando lugar a nuevas ramificaciones de la historia (si sabes que tomar una decisión A lleva a un punto B, puedes tomar entonces cambiar la decisión y ver dónde te lleva). Me gustaría implementar esto y mezclarlo con el sistema de Romancing Saga 2, de forma que la party del personaje esté formada por NPC que sean reemplazables, pero que si los LP del prota llegan a cero volvamos a viajar al “pasado”. ¿Te gusta la hechicera Ramona y ésta muere en combate? Oye, suicídate y vuelve a reclutar a Ramona... pero perdiendo todos los items y dineros que habías ido acumulando; O bien pasa de Ramona y ve dónde la contrataste para pedir los servicios de Jacinto, el cual sospechosamente tiene los mismos stats que ella.
Otra cosa chula de “Re:zero” es que todos los conocimientos y habilidades que va aprendiendo, no las pierde después de morir. No sé si os dais cuenta, pero llevar esto a un videojuego aporta un plus a la hora de realizar backtrackings (volver a visitar mazmorras o poblados al inicio del juego) o metroidvanias. De normal en un juego, cuando mueres, pierdes todas las skills y perks que has ido aprendiendo desde el último save-state. Imaginad que durante un evento os sale una tirada de “negociación” y que cuando la jugaste tu personaje tenía que sacar más de un 5 con un dado de 6... Pero más tarde hacemos un máster de economía, morimos y que al encontrarnos con el mismo desafío sea sacar un 5 sobre 3 dados de 6... Y encima nos encontramos con la gratificación de que pasar esta prueba nos aporta una nueva ramificación en la historia. Pues este tipo de detalles me interesa llegarlas a implementar.
Otra serie que me ha gustado bastante es “Aquella vez que me convertí en Slime”, donde Rimuru (o Rimur, el nombre varía si ves el ánime en Crunchyroll o si lees el manga en España) construye desde cero toda una ciudad poblada por monstruos. Me recuerda bastante a la idea de Breath of fire II (1994 SFC, 1995 SNES USA, 1996 SNES EUR), donde Ryu va creando una ciudad desde cero. Además, tiene otro punto que me gusta bastante y es la evolución de Rimuru (aviso, spoiler): El protagonista pasa de ser una adorable slime pacifista a un rey demonio y para llegar a serlo decide matar a unos 20.000 soldados humanos. Y ese tipo de evolución (manejamos a X y puede variar a Z) me gustaría plasmarlo en mi juego.
Y bueno, uniendo el mundo del ánime y de los juegos, me gustaría mezclar la idea del espíritu tortuga vista en la segunda temporada de “The rising of the shield hero” con la idea de casa tortuga del “Proyecto patas” de Rhomita y hacer que las ciudades del juego estén en gigantescas tortugas móviles. Parte de ello es porque quiero que las ciudades se encuentren en lugares distintos del mapa cada vez que el usuario haga una partida nueva y esto permitiría dar un contexto de por qué pasa eso. Ahora bien, la idea de ciudad tortuga no es nueva y ha aparecido ya en series como Avatar y ya hay una tortuga gigantesca en Final Fantasy XV... Por lo que seguramente tenga que seleccionar otro animal para evitar problemas legales.
Y otra mecánica que me gustaría añadir es un sistema de “agenda”. No sé si habéis hecho gestión de proyectos alguna vez, pero cuando trabajas en una consultaría acabas con una agenda de Outlook bastante llena de confcalls y eventos. El caso es que quiero que en mi juego se pueda grindear (hacer acciones repetitivas para tener más dinero o subir de nivel), pero no quiero que el usuario se aburra haciendo tareas repetitivas durante horas delante de una pantalla enana de Game Boy, por lo que había pensado que una vez que desbloqueas una zona, puedas automatizar tareas. Por ejemplo, permitir al usuario abrirse una agenda tipo Outlook y anotarse en él qué desea grindear y dónde hacerlo... y cuando llegue el momento se muestre una corta animación carituresca, se diga en pantalla los resultados obtenidos y la línea de tiempo avance.
En resumen, me gustaría implementar:
Y bueno, uniendo el mundo del ánime y de los juegos, me gustaría mezclar la idea del espíritu tortuga vista en la segunda temporada de “The rising of the shield hero” con la idea de casa tortuga del “Proyecto patas” de Rhomita y hacer que las ciudades del juego estén en gigantescas tortugas móviles. Parte de ello es porque quiero que las ciudades se encuentren en lugares distintos del mapa cada vez que el usuario haga una partida nueva y esto permitiría dar un contexto de por qué pasa eso. Ahora bien, la idea de ciudad tortuga no es nueva y ha aparecido ya en series como Avatar y ya hay una tortuga gigantesca en Final Fantasy XV... Por lo que seguramente tenga que seleccionar otro animal para evitar problemas legales.
Y otra mecánica que me gustaría añadir es un sistema de “agenda”. No sé si habéis hecho gestión de proyectos alguna vez, pero cuando trabajas en una consultaría acabas con una agenda de Outlook bastante llena de confcalls y eventos. El caso es que quiero que en mi juego se pueda grindear (hacer acciones repetitivas para tener más dinero o subir de nivel), pero no quiero que el usuario se aburra haciendo tareas repetitivas durante horas delante de una pantalla enana de Game Boy, por lo que había pensado que una vez que desbloqueas una zona, puedas automatizar tareas. Por ejemplo, permitir al usuario abrirse una agenda tipo Outlook y anotarse en él qué desea grindear y dónde hacerlo... y cuando llegue el momento se muestre una corta animación carituresca, se diga en pantalla los resultados obtenidos y la línea de tiempo avance.
En resumen, me gustaría implementar:
- Un JRPG clásico no lineal, con toques de metroidvania, donde las distintas ramificaciones muestren evoluciones mentales del personaje.
- Un sistema de muerte permanente donde los compañeros que mueran puedan ser reemplazados por otros mercenarios con estadísticas similares.
- Un sistema de “regreso por muerte” donde el protagonista vuelve a un “save-state” o “check-point” anterior en caso de alcanzar los 0 LP y que cada vez que volvemos a ese check-point perdemos los ítems adquiridos (tendríamos los que había en nuestro inventario al momento de hacer “la foto”), pero que todas las skills aprendidas siguiéramos teníendolas.
- Un sistema de ciudades móviles que vayan cambiando de lugar según la estación o la situación política.
- Un sistema de agenda que evite aborrecer al jugador con grindeos excesivos.
- Un sistema de eventos por horario: Dependiendo de la hora habrá más o menos gente en la calle, los comercios estarán abiertos o no, e incluso podremos ser atracados con mayor facilidad por las noches.
- Un sistema de passwords que permita, por ejemplo, intercambiar items con otros amigos.
- Un sistema de mazmorras aleatorias. No se generarán al azar, pero habrá una lista de X templates por mazmorra y a cada nueva partida se definirá qué template corresponde a cada mazmorra.
Entradas
No hay comentarios:
Publicar un comentario
Si te ha gustado la entrada o consideras que algún dato es erróneo o símplemente deseas dar algún consejo, no dudes en dejar un comentario. Todo feedback es bienvenido siempre que sea respetuoso. También puedes contactarme por estas redes sociales https://linktr.ee/hamster_ruso si lo consideras necesario.