< Back 

Sword Masters

2024-09-15

Round-based Roblox sword game I was contracted to rebuild from scratch in 2024: PvP, zombie hunts and a boss fight, a map vote between rounds, seven abilities and a rotating shop. This page links to the technical article for each system.

LuauRobloxGameplayBackendAI
Go to quick view

A round-based sword game, rebuilt from scratch.

Warning

Sword Masters was abandoned in October 2024. Most of its animations, sounds and images belong to the group that owned it, so the game can’t run as it did, and the articles below describe the systems from the code. There’s a short clip of the game from 2024.

Abstract. Sword Masters is a Roblox sword game built around rounds. In the lobby, players vote for the next map, and each round is one of three modes: last one standing in PvP on three maps, zombie hunts with a kill goal on two, and a boss fight on one. Every player brings a sword (out of 13), a skin (out of 18) and one ability out of seven. A Roblox group contracted me in 2024 to rebuild it from scratch, replacing their original version, which was full of bugs and structural problems. I finished the rewrite in September 2024. In October the owner left the project, the game was abandoned and the rights stayed with me. Not everything in the repository is mine: the boss fight and part of the ability infrastructure came from earlier code that I integrated and adapted, and each article says which part is which. This page is an index. Each section summarizes a system in a few lines and links to the article where I go through how it works, the math behind it and what I’d change.

1. My role

I was the main programmer of the rewrite. I wrote the Knit services and controllers that run the game: the round loop, player data, swords, zombies, map lighting, music and spectating, and on the client the controllers that draw all of it. I also wrote the abilities, one module each, and adapted the inherited code that was worth keeping: the boss fight, the base of the ability system and the shop’s rotation.

Looking back, the articles are as much about what didn’t work as about what did. It’s code from 2024, and reading it today I find bugs I didn’t see then. I describe them where they show up, because understanding why something failed was what I learned the most from.

2. How it’s built

The game uses Knit, sleitnick’s framework, which splits the code into services on the server and controllers on the client. The server’s entry point, ServerBegin, registers the services and providers and starts Knit. If any of them fails to start, the server kicks every player with an error code instead of running half broken. The client’s entry point is ClientBegin, and the round loop doesn’t start until the first client reports that it finished loading. Data is saved with ProfileService and remotes are created with sleitnick’s Net. The content lives as data in ReplicatedStorage.Classes: maps, zombies, abilities, swords and skins are tables, and adding one means adding an entry.

Three ideas show up again and again in the articles below.

  • Mode-specific behavior is a hook. The round loop is the same for PvP, zombies and the boss, and each mode only contributes small functions keyed by its name.
  • Every ability follows the same contract. Each one is a module with four functions and the same signature, and the manager dispatches by name without knowing anything about any of them.
  • When something can fail without warning, there’s a timer. Zombies re-launch their path if a second goes by without news, and a dash ends at 0.4 s even if it never reaches its destination.

3. Rounds and enemies

  • Rounds. A finite state machine with five states and a table of handlers, one tick per second, running inside a promise that restarts once before closing the server. It covers the timing of a full cycle, a map vote that opens halfway through the intermission, and how each mode hooks into the loop.
  • Zombies. Each zombie chases in hops of 12 studs on top of SimplePath and re-plans at the end of each one, which costs one or two paths per second per zombie. A one-second watchdog turns any silent pathfinding failure into a retry, and the waves are drawn by rarity from eight types.
  • Boss. The Mountain Guardian came from the earlier version of the game, and I integrated it. It decides with several loops on independent timers and flags on its model, and it picks its attacks with a Markov chain that never repeats a move. The article also covers what the integration left half done.

4. Abilities

  • The ability system. Seven abilities, a module each, with the same four functions and six remotes between client and server. Instant abilities, one that charges, and long abilities that ask the client for input halfway through.
  • Dash. An AlignPosition that pulls the character 50 studs forward, an AlignOrientation that locks its facing, and two ways to stop: an invisible marker at the destination or 0.4 seconds.
  • Fireball. A target clamped to a cube of 150 studs, an arc defined by a half sine that the player bends with the mouse, and a flight that advances one point per frame until it explodes against the map.
  • Laser beam. Eight seconds of beam aimed with the camera through shift lock. A box cast measures its length and a box aligned with it finds the hits, both from the same CFrame, so what you see and what hurts always match.

5. Economy

  • Ability shop. Three offers drawn by rarity that rotate on a clock and are synchronized between servers through a DataStore and MessagingService. The real odds put the Legendary at the same level as the Rare, and the article describes where the servers can disagree and why the offer rotates every hour while the countdown says four.

This text by Mastedore. All rights reserved.