Battle Royale Systems Prototype

This project was an early-stage Roblox battle royale inspired by Fortnite. The objective was to establish the technical foundation for a complete match: players form parties, enter a cross-server queue, deploy from a moving bus, choose where to land, collect equipment, and survive inside a continuously shrinking zone.

Development was eventually placed on hold before the game reached its intended release scope. However, I completed many of the major systems required to prove that the core battle royale loop could work.

My work covered the multiplayer flow from matchmaking through combat, including cross-server parties, queueing, match deployment, skydiving, the storm zone, player survival statistics, healing, guns, and melee weapons.

This video demonstrates the battle royale prototype and some of the gameplay systems completed before the project was placed on hold.

A battle royale match begins before the player enters the map. Players need to form parties, remain grouped while moving between servers, and enter matchmaking without losing the party state.

I built a party and queue system designed to work across Roblox servers. The system tracked party membership, handled queue entry, and prepared matched players to be moved into an isolated game server.

• -Cross-server party state
• -Party leader-controlled queue entry
• -Matchmaking and queue handling
• -Reserved-server match deployment
• -Party-preserving teleport flow

Once a match began, players spawned into a deployment sequence inspired by Fortnite's Battle Bus. The bus followed a route across the map while players chose when to jump.

The system needed to coordinate the bus state, player deployment, and transition into skydiving without allowing players to spawn incorrectly or leave the playable sequence early.

• -Match-based bus spawning
• -Controlled bus route and movement
• -Player attachment during deployment
• -Server-validated jump requests
• -Clean transition from bus to skydiving

I implemented a custom skydiving system that gave players control over their descent after leaving the bus. Movement needed to feel responsive while still limiting how far and how quickly players could travel.

The controller also managed the transition between freefall, controlled descent, landing, and ordinary character movement.

• -Directional aerial movement
• -Controlled falling and forward momentum
• -Deployment-to-ground state transitions
• -Landing detection
• -Restoration of normal player movement

The shrinking zone controlled the pace of each match. Players outside the safe area received damage, forcing movement and preventing matches from remaining spread across the entire map.

I built the zone as a staged system rather than one continuous shrink. Each phase could define its own destination, radius, waiting period, shrink duration, and damage.

• -Multiple configurable storm phases
• -Randomized safe-zone positioning
• -Smooth radius interpolation
• -Server-authoritative outside-zone detection
• -Increasing damage across later phases

The player survival layer connected movement and combat. I implemented health and stamina systems that could be shared across weapons, melee actions, sprinting, healing items, and zone damage.

Stamina limited sustained high-speed movement, while health changes were resolved by the server to keep damage and healing authoritative.

• -Server-owned health state
• -Stamina use and regeneration
• -Sprint restrictions
• -Zone and combat damage integration
• -Player elimination handling

Healing items required more than simply increasing a health value. Different items could define their own use time, healing amount, usage restrictions, and interruption behavior.

The server checked that the player owned the item, was eligible to use it, and completed the required use duration before applying healing.

• -Timed healing actions
• -Item consumption
• -Maximum-health validation
• -Movement or damage interruption support
• -Server-authoritative healing results

I developed the foundation for ranged combat, including weapon activation, firing, ammunition, damage, and hit validation.

The client could provide responsive presentation and aiming information, but the server remained responsible for validating firing conditions and applying damage.

• -Weapon equipping and state handling
• -Fire-rate enforcement
• -Magazine and ammunition tracking
• -Reload behavior
• -Hit and damage validation
• -Weapon-specific configuration

Melee weapons used a separate combat flow built around short-range hit detection and timed attack windows. The system had to prevent one swing from repeatedly damaging the same target.

• -Server-validated melee attacks
• -Attack timing and cooldowns
• -Short-range target detection
• -Per-swing hit tracking
• -Damage integration with the shared health system

The individual systems were designed to connect into one continuous player journey rather than operate as unrelated prototypes.

This required shared match states so that party handling, deployment, player survival, zone phases, and combat all agreed on whether the match was waiting, active, or complete.

The project was placed on hold during its early development stages, so it did not become a complete public release. The work was still valuable because it established and tested the most technically significant parts of a battle royale game.

The prototype demonstrated that the cross-server match flow, deployment sequence, dynamic zone, survival systems, and combat foundation could operate together as one coherent experience.

Building this prototype gave me experience across almost every layer of a multiplayer match: distributed queueing, reserved servers, custom movement, match state, combat, survival statistics, and large-scale gameplay flow.

It also reinforced the importance of defining clear ownership between systems. The queue owns who enters the match, the match controller owns its current phase, the server owns damage and healing, and the zone owns the pressure that keeps the game moving.