Un juego de espadas por rondas, rehecho desde cero.

Advertencia

Sword Masters quedó abandonado en octubre de 2024. La mayoría de sus animaciones, sonidos e imágenes son del grupo dueño del juego, así que no se puede correr como antes, y los artículos de abajo describen los sistemas a partir del código. Hay un clip corto del juego de 2024.

Resumen. Sword Masters es un juego de espadas para Roblox construido alrededor de rondas. En el lobby los jugadores votan el siguiente mapa, y cada ronda es uno de tres modos: último en pie en PvP en tres mapas, cacerías de zombies con una meta de muertes en dos, y una pelea contra un jefe en uno. Cada jugador lleva una espada (de 13), un skin (de 18) y una habilidad de siete. Un grupo de Roblox me contrató en 2024 para rehacerlo desde cero, reemplazando su versión original, que estaba llena de bugs y problemas de estructura. Terminé la reescritura en septiembre de 2024. En octubre el dueño dejó el proyecto, el juego quedó abandonado y los derechos quedaron conmigo. No todo lo que hay en el repositorio es mío: la pelea contra el jefe y parte de la infraestructura de habilidades venían de código anterior que integré y adapté, y cada artículo dice qué parte es cuál. Esta página es un índice. Cada sección resume un sistema en pocas líneas y enlaza al artículo donde explico cómo funciona, la matemática detrás y lo que cambiaría.

1. Mi rol

Fui el programador principal de la reescritura. Escribí los servicios y controllers de Knit que mueven el juego: el ciclo de rondas, los datos del jugador, las espadas, los zombies, la iluminación de los mapas, la música y el modo espectador, y en el cliente los controllers que dibujan todo eso. También escribí las habilidades, un módulo cada una, y adapté el código heredado que valía la pena conservar: la pelea contra el jefe, la base del sistema de habilidades y la rotación de la tienda.

Mirando hacia atrás, los artículos hablan tanto de lo que no funcionó como de lo que sí. Es código de 2024, y al leerlo hoy encuentro bugs que entonces no vi. Los describo donde aparecen, porque entender por qué algo falló fue de lo que más aprendí.

2. Cómo está construido

El juego usa Knit, el framework de sleitnick, que divide el código en servicios en el servidor y controllers en el cliente. El punto de entrada del servidor, ServerBegin, registra los servicios y providers y arranca Knit. Si alguno no logra arrancar, el servidor expulsa a todos los jugadores con un código de error en vez de correr a medias. El punto de entrada del cliente es ClientBegin, y el ciclo de rondas no arranca hasta que el primer cliente avisa que terminó de cargar. Los datos se guardan con ProfileService y los remotes se crean con Net, también de sleitnick. El contenido vive como datos en ReplicatedStorage.Classes: mapas, zombies, habilidades, espadas y skins son tablas, y agregar uno es agregar una entrada.

Tres ideas aparecen una y otra vez en los artículos de abajo.

Lo que depende del modo es un gancho. El ciclo de rondas es el mismo para PvP, zombies y el jefe, y cada modo solo aporta funciones pequeñas indexadas por su nombre.
Todas las habilidades siguen el mismo contrato. Cada una es un módulo con cuatro funciones y la misma firma, y el manager despacha por nombre sin saber nada de ninguna.
Cuando algo puede fallar sin avisar, hay un temporizador. Los zombies relanzan su camino si pasa un segundo sin noticias, y un dash termina a los 0.4 s aunque nunca llegue a su destino.

3. Rondas y enemigos

Rondas. Una máquina de estados finitos con cinco estados y una tabla de handlers, un tick por segundo, que corre dentro de una promesa que se reinicia una vez antes de cerrar el servidor. Cubre la duración de un ciclo completo, una votación de mapa que abre a mitad del intermedio y cómo se engancha cada modo al ciclo.
Zombies. Cada zombie persigue en saltos de 12 studs sobre SimplePath y vuelve a planear al final de cada uno, lo que cuesta uno o dos caminos por segundo por zombie. Un watchdog de un segundo convierte cualquier falla silenciosa del pathfinding en un reintento, y las oleadas salen por rareza de ocho tipos.
Jefe. El Mountain Guardian venía de la versión anterior del juego, y yo lo integré. Decide con varios bucles en temporizadores independientes y banderas en su modelo, y elige sus ataques con una cadena de Markov que nunca repite un movimiento. El artículo también cubre lo que la integración dejó a medias.

4. Habilidades

El sistema de habilidades. Siete habilidades, un módulo cada una, con las mismas cuatro funciones y seis remotes entre cliente y servidor. Habilidades instantáneas, una que se carga, y habilidades largas que le piden input al cliente a la mitad.
Dash. Un AlignPosition que tira del personaje 50 studs hacia adelante, un AlignOrientation que fija hacia dónde mira, y dos formas de parar: un marcador invisible en el destino o 0.4 segundos.
Fireball. Un objetivo limitado a un cubo de 150 studs, un arco definido por medio seno que el jugador dobla con el mouse, y un vuelo que avanza un punto por frame hasta explotar contra el mapa.
Laser beam. Ocho segundos de rayo apuntado con la cámara mediante el shift lock. Un blockcast mide su largo y una caja alineada con él encuentra los golpes, los dos desde el mismo CFrame, así que lo que se ve y lo que daña siempre coinciden.

5. Economía

Tienda de habilidades. Tres ofertas sorteadas por rareza que rotan según un reloj y se sincronizan entre servidores con un DataStore y MessagingService. Las probabilidades reales ponen a la Legendary al nivel de la Rare, y el artículo describe dónde pueden quedar en desacuerdo los servidores y por qué la oferta rota cada hora mientras la cuenta regresiva dice cuatro.