Registrarse

La realidad del videojuego | Mi fracaso más reciente: Pokéstein

Jason

PkPower déjame poner tildes en mi nick ¬¬
La realidad del videojuego

Hace un tiempo atrás vi este vídeo de nuestro mesías el señor Doyo. Me pareció muy interesante y revelador de cosas de las que no era consciente. Además, como programador, doy completa fe de que el diálogo entre diseño y programación que expone es completamente real, además de que uno puede planificar y preveer que alguna [i[feature[/i] esté en la versión final, pero ocurren problemas imprevistos y...


Entra vídeo!


Al final es algo que le puede pasar a cualquiera y quiero complementar esto con mi fracaso más reciente: Pokéstein.

Para el que no se haya enterado, Pokéstein fue el nombre de mi intento por crear mi propio motor de pokémon en una game engine que se ve prometedora pero está tan verde que nunca debí plantearme el usarla para un proyecto serio. ¿Por qué la usé? Ignorancia.

Link al proyecto:
(Sí, los escuditos de mi firma son links a mi twitter y discord. Los followers de twitter se actualizan solos.)


¿Qué pasó?
TL;DR: demasiado optimismo y algo de ignorancia.

Voy a explicar primero cómo funciona la numeración de las versiones, un detalle que no sabía hasta hace un par de horas cuando le comenté a un amigo. Luego, contaré la historia de cómo colapsó todo en cuestión de días.

Numeración de las versiones.

Por lo general un número de versión consiste en tres números separados por puntos: major.minor.micro.

  • major: corresponde a versiones con cambios mayores y mejoras en las características.
  • minor: corresponde a versiones con cambios menores y correcciones de errores.
  • micro: corresponde a pequeñas correcciones de errores.

Hasta aquí lo sabía, pero, ¿entonces qué pasó? Cuando hablamos de librerías hay un par de detalles adicionales.

  1. Si una librería está en una versión 0.x.y quiere decir que aún no se han decidido por una interfaz y pueden ocurrir grandes cambios entre una versión 0.x y la 0.(x + 1).
  2. Recién cuando están en una versión 1.x por ejemplo, tienes asegurado que el código que escribas para esa versión va a seguir corriendo para todas las posteriores hasta que llegue la 2.0 donde sí pueden haber breaking changes.

Este conocimiento cambia mucho, aunque no lo crean.

La historia de Pokéstein.

La idea de hacer mi propio motor de pokémon viene desde hace bastante tiempo, la verdad. ¿Por qué? Interés de aprender y proponer una alternativa que como mínimo esté al mismo nivel que el RH tradicional y RPG Maker XP, pero que idealmente sea mejor.

Para ese propósito probé un par de alternativas antes de llegar a amethyst, la primera fue Löve2D, un engine para hacer videojuegos con Lua y llegué a tener algunas cosas hechas, la verdad (movimiento, colisiones, cosas así).

Tras mucho tiempo intentando barajar mecánicas + gráficos + historia, decidí centrarme únicamente en las mecánicas y hacer un "frankenstein" de ellas, para luego tomar las que me vinieran bien para un proyecto y ponerlo en marcha, de ahí el nombre del proyecto. Sé desde hace un tiempo que para programar videojuegos el paradigma predominante en el desarrollo de software (OOP: Object Oriented Programming o en español Programación Orientada a Objetos) es simplemente contraproducente. En un videojuego tenemos muchas entidades que se crean, destruyen e interactuan entre sí constantemente. Además, las referencias entre estas entidades son demasiado caóticas y la separación de responsabilidades no es sencilla. Por estas cosas estuve buscando un poco y un amigo me mostró un vídeo de otro modelo: ECS (Entity Component System o Entidad Componente Sistema), que es el realmente más idóneo para videojuegos. Unity lo implementa como algo opcional, sin embargo el ECS es el núcleo de Amethyst. De ahí mi idea de usar este framework (todavía no considero que esté al nivel de una game engine(primera señal de alerta).

La barrera de entrada de Amethyst es bastante grande, hay que utilizar Rust que tiene de por sí su propia barrera de entrada y cambiar el paradigma en el que uno está programando. Considero que la superé. La documentación inicial es bastante decente, por lo que pude sobrevivir, había usado sin problemas documentaciones peores, como la de Qt5 adaptándola a python (PyQt5). Conseguí un estado de Overworld, un persona, movimiento por casillas y colisiones con el mapa, renderizado simple y tenía que hacer que el movimiento fuera animado, es decir, entre que esté en una casilla y la siguiente, el sprite se desplazara poco a poco a lo largo del tiempo. ¿Qué pasó? La documentación de aquí en adelante es definitivamente la peor que he visto. Tuve que ponerme a leer el código fuente de Amethyst para intentar hacer funcionar las cosas pero es tan oscuro que ni así fue posible. Esa es la segunda señal de alerta.

Ojo, cuando digo que la documentación era mala, no solo me refiero a que sea vaga o extremadamente imprecisa, sino también a que los propios ejemplos que ponían no funcionaban y además uno se encuentra perlas como esta:





Por último, Amethyst está en la versión 0.13.2. Esto significa que la interfaz no es definitiva y con la rapidez relativa a la que se actualiza, definitivamente no renta tener que estar readaptando el código constantemente. Esta es la tercera señal de alerta.

Bonus: hay una feature que consiste en que te de más información cuando ocurre algún error y el programa se cae. ¿Cuál es el problema? Que es exclusiva de la versión inestable no solo de Amethyst, sino también de Rust. La vez que intenté compilarlo con eso no funcionó porque una de las librerías no estaba actualizada a los cambios de amethyst.


Conclusión

Con todos estos problemas tomé la decisión, tras lo que realmente fueron meses de aprendizaje, aparcar Amethyst por dos años. Durante todo este tiempo no lo tocaré ni con un palo. El objetivo es esperar a que madure y así ver en un futuro qué tan utilizable está. Tienían en su roadmap para el último cuarto de 2019:
  • Un editor con interfaz gráfica básico.
  • Poder compilar para android e iOS.
  • Integración básica con Atelier.
  • Mejorar el soporte para windows.
  • Aumentar la cobertura de los tests automáticos al 50%.

De los primeros 4 puntos, me consta que no cumplieron ni uno. No tenemos editor básico con interfaz gráfica como sí lo tienen Unity y Unreal, tampoco se puede compilar para celular. Para los últimos dos (para todos excepto el primero, en realidad) era necesaria una actualización cerca de finales de año, que no llegó. Esa vez que intenté compilar la versión futura me di cuenta de que había cambios rompedores por lo que no me consta que vayan a pasar a la 1.0 pronto.

¿Recomiendo Amethyst? Para un proyecto, definitivamente no. Si lo que quieres es probar cosillas, adelante.

¿Y qué pasa con Rust? Es un lenguaje de programación que, si bien nació cerca del 2011, ya está en un estado de madurez alto (1.40). Tiene una gran comunidad y buen soporte. Eso sí, olvídate de hacer cosas con interfaz gráfica usando Rust. No he encontrado ninguna librería ni framework que esté en un nivel aceptable de desarrollo (lo que más, quizás sea Web Assembly, por increíble que parezca). Cualquier cosa que quieras hacer en C++ y que no requiera una GUI, probablemente lo puedas hacer con Rust y sea más sencillo sin perder performace.


JSON out~
 

Jessie

What goes around, comes around
Si lo que deseas es hacer tu propia base, no es necesario que uses el 100% de los recursos que le motor te está ofreciendo.

Un ejemplo claro es en Pokémon Essentials, el RPG Maker XP trae un editor que te permite crear una lista de objetos y los efectos, estos objetos serán usados por el jugador durante la aventura.



Aunque la mayoría de proyecto que usan RPG Maker XP suelen usar este editor para definir los objetos que se usarán, esto no quiere decir que todos los proyectos deben verse obligados a usar esta parte del editor. Aquí es donde Pokémon Essentials entra en acción y crea su propio sistema de objetos, el cual ha sido adaptado para cumplir con las necesidades de la base, independientemente de lo que originalmente te marca el editor.

Este ejemplo puede ser aplicado en tu caso. Sí, es verdad, el motor que usas es básicamente nuevo y apenas está en desarrollo y le falta por completar varias cosas importantes en la documentación, pero esto no quiere decir que no puedas adaptarte a lo que si puedes usar, a lo que si puedes tener acceso y a lo que si puedes crear.

Ya has tomado una decisión al respecto, pero al final de cuentas el verdadero límite tu lo pones.
 
Última edición:

Jason

PkPower déjame poner tildes en mi nick ¬¬
Si lo que deseas es hacer tu propia base, no es necesario que uses el 100% de los recursos que le motor te está ofreciendo.

(...)

Este ejemplo puede ser aplicado en tu caso. Sí, es verdad, el motor que usas es básicamente nuevo y apenas está en desarrollo y le falta por completar varias cosas importantes en la documentación, pero esto no quiere decir que no puedas adaptarte a lo que si puedes usar, a lo que si puedes tener acceso y a lo que si puedes crear.

Ya has tomado una decisión al respecto, pero al final de cuentas el verdadero límite tu lo pones.
No te falta razón. Tenía una alternativa muy clara a usar los prefabs, el problema es que el trabajo que requería simplemente no compensa, era el equivalente a trabajar sin un framework y para eso la verdad es que uno se tiene que replantear las cosas antes de continuar. Pasada una dificultad base, hay formas más fáciles y otras mas difíciles de hacer lo mismo, en la forma difícil aprendes más, pero hay unas que están en lo "extremadamente difícil" que pasan a ser un despropósito según qué objetivos tengas, como por ejemplo hacer un juego enteramente en assembly x86_64. ¿Para qué? Si lo que quieres es hacer un juego, hay muchísimas alternativas mejores. Si lo que quieres es aprender específicamente eso, es la decisión correcta.

De todas formas, las prefabs son algo esencial del desarrollo de un proyecto, es básicamente declarar en archivos de texto plano información sobre los datos del juego en lugar del código. Es como que en essentials no pudieras tener todos los pokémon en un archivo aparte sino que tuvieras que describirlos en el código.

Igual no es una renuncia completa a Amethyst, doy un plazo de dos años ya que me parece razonable para esperar a que la engine madure. Y bueno, comparto esto ya que lo veo como una experiencia de la que otras personas pueden aprender y sacar algo en provecho.
 
Arriba