[DevLog] Planet Squad - El retorno del príncipe de los .io

Update 3

Tema del update:

Esta tarde me he dedicado a terminar la lógica de la cápsula del jugador. Inicialmente el jugador simplemente hacía spawn en un punto random en el radio del planeta. Ahora, la cápsula aparece en un radio muy alejado del planeta, y el jugador sólo hace spawn una vez ésta ha aterrizado.

Hay que decir que mejoraré todo a medida que avance, pero de momento, así ha quedado el modelo (junto al pupurrí de efectos que voy activando y desactivando según la cápsula va descendiendo):

Una vez teniendo el modelo, he escrito una nueva clase PlayerCapsule para controlar todo lo que pasa con las cápsulas del jugador. El ID de la cápsula es el mismo que el ID del jugador, para hacer aún más fácil el lookup cuando se necesite.

Aún me queda por implementar los efectos de sonido, que por alguna razón están bug, mañana me pondré a mirar el engine, ya con todo el tiempo de un sábado que pinta super lluvioso, perfecto para trabajar a full y pegarle un buen progreso al proyecto.

A medida que la cápsula desciende, he simulado la entrada a la atmósfera del planeta con un pequeño efecto como de impacto con el aire (rompiendo la barrera del sonido o yo que sé), seguido de un efecto de fuego que se verá reforzado por efectos de sonido acompañándolo además de un screenshake que empieza suave y acaba fuerte una vez aterrizados.

También he añadido un pequeño detalle al inicio, pero bueno, creo que no se nota demasiado.

Cuando pase a revisar la lógica de la cápsula haré que al aterrizar la cámara no pase de un modo a otro de sopetón, si no que sea suave.

Mañana, me pondré a arreglar el bug del sonido y muy probablemente a modelar el soldadito que controlaremos (o al menos el soldado base, ya que después habrá personalización de varios tipos), después de ello más sincronización de estados de jugador y después a hacer algún bicho con la excusa de poder empezar ya las mecánicas de tiros.

Salu2

Update 4

Tema del update:

Va a ser que me he dado cuenta de que escribir un devlog cada día o casi cada día es jodido. Así que nada, supongo que los escribiré cuando pueda.

El juego va viento en popa; Es cierto que me he ido encontrando con unos retos guapos guapos debido a la naturaleza esférica del mundo del juego, pero la verdad es que me lo estoy pasando como un niño solventando los puzzles y haciendo funcionar todo como debe ser.

La semana pasada, posteé #12, que no fue un update como tal, así que voy a extenderme en todos esos commits.

El fin de semana pasado, en concreto el sábado, me dispuse a diseñar un prototipo de modelo humanoide que poder usar para el jugador y enemigos en esta fase tan temprana del desarrollo. Todo eran florecitas de colores hasta que fui a importarlo al juego y me percaté de que aún no había pensado en cómo iba a orientar el modelo según el ratón del jugador.

En concreto, había que orientar el modelo del jugador sólamente en el eje Y (el vertical), para que el modelo mirase hacia el ratón pero se quedase "de pie", vamos, como en cualquier juego top-down.

El tema es que en un juego top-down normal y corriente en el que el mundo es plano (sí terraplanista), orientar el modelo hacia el ratón es tan fácil como obtener la dirección entre la posición del ratón en el mundo y la posición del jugador, aislar el eje Y y hacerlo igual para tanto el jugador como el ratón, y usar Math.atan2 para encontrar el ángulo de diferencia en el eje Z (forward) para orientar.

Estuve rompiéndome la cabeza literalmente todo el sábado porque básicamente no funcionaba, intenté aislar el eje Y de mil maneras, teniendo en cuenta que el eje Y en un mundo esférico en donde el jugador lo camina a sus anchas es básicamente relativo y cambia constantemente mientras te mueves.

En un debido momento me di cuenta de que los problemas sólo empezaban cuando la posición del ratón estaba bastante lejos del jugador, así que estuve intentando solventar, pero no hubo manera.

Al final desistí de usar Math.atan2 y le estuve dando vueltas a cómo podía hacerlo. Le expuse el caso a ChatGPT y amablemente me indicó que si Math.atan2 no funcionaba podías hacerlo con los productos cross y dot de los vectores de dirección. Me puse a probarlo y funcionaba prácticamente a la perfección, sólo tuve que pulir un par de cosas más y conseguí solventarlo. Lo malo es que no tengo más que esta screenshot:

Pero ojo que eso no termina ahí. Una vez orientado el modelo del jugador con éxito, todavía me quedaba orientar el brazo derecho a mirar al ratón.. sudores fríos invadieron mi cuerpo después de todas las horas invertidas en conseguir orientar bien el jugador.

Nah, al final no fue tan jodido, también tuvo lo suyo pero ya no tuve que estar todo el día para hacerlo, en una hora o dos conseguí tener el bracito apuntando al raycast del ratón, y quedaba guay, aunque no tengo imágenes de ello, estaba bastante quemado de haberme tirado tanto tiempo en la tarea anterior.

Después de eso decidí que no me gustaba el primer modelo humanoide que hice para el prototipo del jugador y enemigos, especialmente porque le puse un huevo de detalle y al final al ser un juego en el que los personajes se van a ver desde arriba, no hace falta tanto; Así que me puse a hacer lo que cualquier buen ingeniero haría: Simplificarlo hasta que todo vaya de lujo. Y así quedó:

Lo animé con dos estados básicos "quieto" y "caminar" y lo importé al juego, vi que todo guay.

Después me puse a seguir escribiendo el netcode del juego para sincronizar también la orientación del modelo y la del brazo.

Al final, terminé re-escribiendo mil cosas más y llegué a algo muy sólido. En un principio el netcode iba a simplemente actualizar todos los jugadores a la vez y mandar paquetes para que cada cliente lo interpretase. Pero se me ocurrió que.. para qué un jugador en la otra punta del planeta iba a necesitar sincronizar a otro jugador en la otra punta en donde ni siquiera podía verlo por la curvatura del planeta? Eso iba a costar muchos recursos de computación, no sólo a nivel netcode si no también de renderizado en cada cliente.

Así que me puse a diseñar un concepto que he llamado Awareness Bubbles, o "burbujas de conciencia".

La manera en la que funciona este concepto es que cada jugador, y cada NPC, tienen una burbuja de conciencia en el servidor. Todo lo que entra en esta burbuja de conciencia, emite un evento para que ese actor aparezca en el cliente con el que ha tocado, y cuando sale, igual, pero para desaparecer.

Al terminar, ahora todo lo que esté a 5 metros de un jugador, aparece como debe.

Después de eso, tocaba empezar a darle caña a algo divertido de verdad: Sistema y lógicas de tiros, poder sujetar un arma con tu personaje y poderla disparar. Para ello simplemente escribí una nueva clase para gestionar todo esto que se llama WeaponController, y que emite eventos al servidor cuando se quiere disparar, para que el servidor haga la simulación e informe a los clientes.

Qué pasa? Que iba avanzando yo muy rápido y al principio todo bien probando a disparar contra el planeta. Pero cuando quise disparar a los árboles o las rocas.. me di cuenta de que algo no iba bien:

Así que desactivé todo el código de proyectiles y en su lugar hice que al disparar, el jugador emitiese un Raycast al servidor, y éste lo simulase y devolviese el resultado de la simulación.

Pues nada, acorde a mis sospechas, la esfera del proyectil atravesaba los árboles y las rocas porque las mallas no estaban bien.

Tras mucho meditar y probar, encontré el problema en mi workflow para descargar datos del cliente (las mallas que usa PlayCanvas) y volcarlo al servidor, donde las físicas que rulan gracias a CANNONJS, se encargarían de simular todo igual que en el cliente (porque usan ambos el mismo motor de físicas).

Solucioné el problema, que simplemente era que estaba volcando datos de mallas escaladas en lugar de con escalas originales, y el servidor, al escalar de manera aleatoria para darle variedad al mundo, todavía la liaba más, terminando con colisiones y raycasts que no representaban lo que se veía en el lado del cliente.

Y ahora, por fin, todo va bien:

Lo siguiente es jugar un poco con tema de simulación de proyectiles y luego me pongo de cabeza a escribir la lógica que van a usar los NPCs y a solventar otro puzzle enorme, que va a ser, nada ni menos: cómo cojones hacer que un BOT/NPC sea capaz de encontrar puntos en el mundo esférico; rutas más cortas y navegarlas sin problemas para encontrar puntos de interés como, jugadores.

Update 6

Tema del update:

No va a haber ninguna imagen nueva del juego así que podéis ignorar, he tenido que invertir prácticamente 7 días en re-escribir todo el juego

El fin de semana pasado volvió a ser jodidamente duro. Pensé que lo tenía ya todo bien encarrilado y me puse de cabeza a meter el primer enemigo al juego.
Como todo buen RPG, iba a ser un Slime.

Así que me levanté bien temprano el Sábado pasado y me dispuse a extender la clase Actor que básicamente crea un actor en el mundo, con sus estados; Posición, orientación, cuerpo en físicas (rigidbody), etc, de manera que pudiese usar esta clase como base para cualquier tipo de NPC controlado por el servidor.

En cuestión de hora y media tenía una esfera que simulaba un Slime navegando el mundo con el sistema de waypoints que diseñé días atrás.

Todo iba de lujo (o eso creía yo).

Para realmente testar éste nuevo NPC que había diseñado para ser el primer enemigo en el juego, en lugar de crear uno al inicio, me puse a crear 100.

Y ahí.. empezaron los problemas. Me di cuenta de que el juego iba jodidamente lento, y después de indagar un poco en los problemas, me di cuenta de que el problema principal era CannonJS, la librería de físicas que estaba usando tanto en cliente como en servidor, parece ser que ésta librería es tan amateur que no puede soportar calcular las colisiones para 101 esferas (100 enemigos + 1 jugador) contra un trimesh de unos 5000 triángulos.

Me puse a probar todo tipo de cosas para evitar cambiar la librería de físicas porque tan avanzado ya en el prototipo iba a significar re-escribir absolutamente todo y no me apetecía nada, era sábado, joder y se suponía que iba a avanzar y tener el juego jugable para navidades!

Entre las cosas que probé, fue separar el mesh del planeta en 6 partes, pensando que así CannonJS tendría menos trabajo.

Pero.. no fue así, y además, splittear el planeta generaba otros bugs de colisiones que tampoco me apetecía ponerme a solventar..

Así que nada, me puse a buscar si alguien había tenido problemas con éste motor de físicas tan ligero y tan cuco que había elegido para simular toda colisión en Planet Squad.

Y voy y me encuentro con un issue cerrado en github, me alegré y pensé que simplemente tenía una versión desactualizada de la librería, me la volví a descargar y nada, mismo problema. Leí en más detenimiento el issue y veo que el creador de este motor de físicas sólo había testado el algoritmo de Esferas<->Trimesh estático con UNA sola esfera.

Así que nada. Desistí, eran como las 12 del mediodía, y pensé.. sé qué motor puedo usar como reemplazo y sé que no me va a dar estos problemas.. pero me apetece pasarme todo el sábado y probablemente también el domingo re-escribiendo todo e implementando el motor de reemplazo?

Y obviamente no me apetecía pero es lo que hay, si queremos sacar proyectos adelante hay que currar, ya tendré tiempo para relajarme cuando lo publique. Pero ponéos en mi piel.. toda la semana trabajando como un cabrón, para llegar el fin de semana y tener este problemón..

En fin, por eso el gamedev es lo que más calvas, ganas de morir y buenas barbas genera junto al culturismo.

Así que me dejé de tonterías y me puse a re-escribir todo el código de colisiones para implementarlo con Bullet Physics, reconocido mundialmente en nuestra industria como uno de los mejores motores de físicas Open Source, usado por nombres enormes como Rockstar o Psyonix con los GTA y Rocket League, diría que hasta Unreal Engine solía correr con ello, y iba a implementarlo tanto en cliente como servidor, que es lo que he terminado haciendo.

Al final, me tiré todo el sábado, todo el domingo, una buena parte del Lunes y del Miércoles, y hoy, por fin, he llegado a la paridad entre cómo estaba el proyecto con CannonJS, pero con Bullet Physics.

He realizado la misma prueba, con 100 Slimes y 1 jugador, y todo aguanta, y no sólo aguanta, si no que le puedo echar más leña al fuego si quiero y tener no 100 si no 200, 300 y quizás hasta 500 Actores en el mismo planeta y servidor.

Cabe recalcar, que a parte de cambiar el motor de físicas por Bullet Physics, también he separado el servidor del juego en 2 threads/hilos. El principal, simula todo el mundo, físicas, actores, sistema de waypoints, etc. El secundario, es el que se encarga del netcode, preparación y envío de paquetes.

He de decir que ha sido profundamente divertido re-hacer todo aunque no tenía putas ganas porque ha sido como volver al punto de partida, pero ahora el juego va de lujo, y de hecho ya lo he puesto en un VPS de 2 Cores y 2GB de RAM, con 101 entidades (Slimes y jugador), se sitúa el consumo de CPU y RAM muy tranquilito, así que me da margen para realmente hacer lo que me salga de los cojones. Va a salir un juego "muy guapo", como diría un famoso streamer.

Y sí, NodeJS puede ser multithreaded, aunque la gestión de memoria es bastante incordio, pero me he hecho una helper class que mantiene todo genial en SharedArrayBuffers y puedo escribir y descifrar actores a través de ellos, que es todo lo que necesito por ahora.

Ahora sí que sí, mañana empieza por fin, lo vistoso y divertido. Empezar a hacer más mecánicas y a repasar gráficos y demás. Sobra decir que no tendré el juego jugable para el Lunes, pero igual droppeo enlace con lo que haya. Veremos. Soy bastante partidario de ir desarrollando los videojuegos online en público.

PD: Nunca en la vida vuelvo a usar CannonJS para algo mínimamente complejo.
PD2: Viva Bullet Physics.