Dungeons and Honor, multiplayer hecho en Cuba

 Y además, indie, trabajo de un solo desarrollador. 

En estos días subiré otra partida. Les debo (y les deberé) el stream en vivo porque acá la velocidad de subida es más falsa que un dólar con la cara de Tutankamón y es insuficiente para esos lujos.

Reporte de progreso, devlog

 O como quieran llamarlo.

El master está más o menos usable según lo que quieras hacer. No recomiendo que intenten nada que tenga que ver con gráficos y creación de escenas, pero tirar líneas y ver si funcionan no los matará de una rabieta. Lo que he hecho en los últimos días es armar parte de la base del sistema RPG y probar números.
Casi todo el trabajo se lo han llevado los ítems. Es bastante básico y lo implementado hasta ahora es muy poco: las armas dañan, las armaduras protegen y cualquier objeto puede proveer algún tipo de bonificación por su uso. Armas y armaduras pueden equiparse, o en este caso, escudo, porque no tengo armaduras para probar. Lo de montar objetos sobre el personaje requiere un pulido a fondo, pero me sorprendió que me resultó muy fácil. La vez anterior me encontré todo tipo de problemas de escala y cometí errores enormes debido al desconocimiento. Ahora es posible crear objetos complejos, que incluyan, por ejemplo, un sistema de partículas, porque cada objeto es una escena. No estoy muy seguro de que esto funcione bien en un móvil de gama media baja, por eso no lo considero una funcionalidad definitiva.

 

Hice un pequeño experimento para crear una escena grande con carga progresiva por secciones. Nos preocupaba mucho el impacto que tendría en el rendimiento un escenario muy grande y complejo, pero en lo personal, me opongo a sacrificar el espacio y limitarnos a pequeñas salitas. Por tanto, me dediqué a comprobar qué tan factible sería particionar la escena. La prueba no salió mal: la carga era imperceptible (de nuevo, el resultado podría variar según el móvil), quizás porque los elementos de la escena ya estaban en memoria. El método que utilicé fue un poco burdo: instanciar las escenas cuando el jugador se aproxima a ellas, eliminarlas cuando el jugador se aleja, todo eso fuera del área visible. Quedan un montón de incógnitas (digamos, qué hacer con los NPCs de una sección al eliminarla), pero no quiero ni pensar en eso ahora.

El trabajoso asunto de los números

 Mientras nos llega Godot 4, he estado trabajando en la base del sistema RPG: objetos y habilidades. Ambas cosas requieren probar y afinar las fórmulas, que después tendrán que ser reajustadas cuando se implemente el combate real, y vuelta a reajustar cuando los jugadores las pongan a prueba. Pero ahora mismo, es solo la fase de sacar cuentas. O como dice un colega: el papeleo. He tratado de no enredar mucho porque mis matemáticas no son buenas y para que el jugador no tenga que echar números sin necesidad. En teoría, un punto invertido en cualquier atributo tendrá un efecto perceptible en los cálculos que incluyen dicho atributo. Un punto invertido en Fuerza, por ejemplo, produce varios puntos de daño adicional, en dependencia del arma.

Aún en un sistema RPG simple como el que estoy creando, el trabajo conlleva muchas pruebas y tiempo. En primer lugar tengo que descubrir qué es implementable con mi actual dominio del motor, que está muy lejos de un sistema como el de Diablo 2 o DOTA 2. Lo que he podido hacer hasta ahora es algo más simple: cuatro atributos, de los que derivan cosas como esquiva y precisión, y algunos bonificadores/penalizadores que pueden afectar esos atributos y las habilidades. Estas últimas también pueden afectar los atributos, o en caso de las pasivas, el daño de las armas y habilidades, estadísticas derivadas, o cualquier otra cosa que pueda crear por el camino. 

En estos días he logrado implementar los daños básicos (aunque solo he probado el de tipo normal) y una armadura que protege al objetivo. El siguiente paso es agregar un uso más realista introduciendo el temporizador de las acciones, en dependencia del cooldown del objeto o habilidad, y sincronizar eso con una animación. Por suerte, tengo un modelo con animaciones que puedo utilizar. 

Poniendo a prueba Godot 4

 Pretendía traer un video comparando Godot 4 antes y después de su optimización, pero en el momento de grabar las comparaciones me encontré con un problema: aún desactivando VSync el proyecto no pasaba de 60 cuadros. Lo atribuí a algún error en Godot, en definitiva ni siquiera estaba en fase alfa, miles de cosas no funcionan como debe ser. 

Hace dos días me dediqué a revisar la configuración del proyecto, buscando los cambios recién implementados. Noté que no había tocado la configuración multihilo, que por defecto viene a Single Thread. Al cambiarlo a Multi Thread el rendimiento se disparó, alcanzando los 90 FPS, con picos de más de 100, aunque lo normal es que varíe constantemente. El por qué de los saltos entre 80 y 120 FPS de un segundo para otro escapa a mi comprensión. He tomado prestado un modelo de otro proyecto, con alta calidad y texturas PBR, además he subido al máximo todas las opciones de calidad y GI, excepto FXAA porque afectaba la textura de la cota de malla (se volvía borrosa).

En caso de que piensen que 100 FPS con una escena casi vacía no es gran cosa, yo también pensé lo mismo, hasta que recordé que estoy usando los drivers libres, no los propietarios de AMD. Es lógico que el rendimiento no sea el máximo posible.

Hasta el domingo pasado, el master sigue (y seguirá) en un estado no apto para el trabajo. Ha sido corregido un problema que me molestaba: la serialización de las variables export, que nos e guardaban, y junto a eso, el detalle que no me permitía exportar un String porque el editor no dejaba modificar. Ahora ya puedo hacer ambas cosas. Persiste el error de indexado de diccionarios, es imposible usar la sintaxis [] para leer el valor de un miembro. En cambio, sí puedes usarla para escribir el valor. O sea:

a = dicc["miembro"]  #No funciona, hay que usar a=dicc.get("miembro")

dicc["miembro"]=valor  #sí funciona

Curioso. 

En otro orden de cosas, Juan Linietsky, uno de los fundadores de Godot y ahora mismo el desarrollador principal, afirma que su última gran tarea será la implementación del renderizador GL ES 3. Luego de eso seguirá involucrado, pero con cosas más sencillas. Pero que no cunda el pánico, que afirma que hay contribuyentes capacitados para hacerse cargo.

El tamaño (del lag) sí importa

 He vuelto a jugar Dota. No es que la vez anterior jugase mucho, porque casi todo el tiempo estaba en proceso de actualizar y con una conexión lenta es para morirse. No es que yo sea un gran fan, ni un jugador profesional, pero me divierte y de hecho, lo descubrí cuando aún era un mapa de Warcraft 3.
O sea, que no se las den de listillos conmigo, que yo estaba ahí cuando empezó.

 

Pero nada, como les decía, no soy un as jugando. A decir verdad, me dan unas buenas palizas, a menos que juegue con un equipo bueno contra otro malo. Tampoco me sé con exactitud los builds por héroe, yo tiro de lo primero que me apaezca en la tienda. Algo que no ayuda en nada es que si estás en Cuba ya partes con desventaja.
El primer día tenía una latencia más o menos aceptable, sobre los 100ms. Me lucí con el Sniper, en las partidas de aprendizaje.  Miren qué cosa más chula:

El segundo día ya las cosas no fueron tan fáciles en las partidas normales. Las regiones con mejor latencia no bajaban de 350 ms. Y  eso, lamentablemente, se siente. No llega a medio segundo, pero marca una diferencia sustancial. Es la diferencia entre acertar un toletazo con el Rey Mono y fallarlo (los fallé casi todos). Es la diferencia entre apartarte a tiempo y que te atizen en toda la cabeza. Sumen a eso mis errores de principiante contra gente que ya sabe jugar, con eso basta para evitar tenerme en el equipo porque soy la garantía de la derrota.
Es un mal que padecemos los cubanos. Incluso dentro de la red nacional, los pings a los nuevos VPS de ETECSA son de 300 o 400. No sé para qué carajo tenemos un cable de fibra de una punta a la otra del país. Con esa latencia es imposible crear un MMO al estilo de For Honor, o algo parecido. Nada de combates en tiempo real. Por eso, la próxima vez que te quejes de que tus 20 mbps y tu latencia de 90 ms, recuerda que aquí estamos mucho peor.