Full-Stack Game Development / Multiplayer Infrastructure
A large-scale Unity multiplayer FPS where players reshape a dynamic voxel battlefield through destruction, excavation and construction.
We begin with the experience that must work, make ownership and failure paths explicit, then choose the smallest architecture that can be operated responsibly. Every recommendation is evaluated against player impact, delivery risk, team capacity and run cost.
PROJECT OVERVIEW
Bad Goons is a team-based multiplayer shooter built around a simple principle: the map should never remain static. Players can dig trenches, destroy defensive positions, create new routes and reshape the frontline throughout the match.
The Unity client, voxel simulation, multiplayer model, dedicated servers and cloud deployment are designed as separate systems connected through one shared technical architecture. The current design targets 64-player battles across a shifting frontline.
THE CORE CHALLENGE
Movement and combat must remain responsive while terrain destruction, excavation, construction, projectiles and tactical state are synchronized across many connected clients.
TECHNICAL ARCHITECTURE
Input, presentation, rendering, audio and predicted player actions.
Authority, prediction, reconciliation and synchronized gameplay systems.
Player-created trenches, altered cover and evolving combat routes.
Authoritative players, combat, terrain and shared world state.
Configurable server packaging, releases, regions and runtime settings.
Health monitoring, diagnostics, automation and demand-led capacity.
TECHNOLOGY STACK Unity 6 · C# · FishNet · FMOD · URP · Voxel systems · Client prediction · Reconciliation · Linux headless servers · Docker · CI/CD · Cloud infrastructure
CURRENT STATUS
Bad Goons is currently in active development. Core work includes multiplayer combat, dynamic terrain, dedicated-server deployment, tactical spawn systems and production tooling. It is both an original commercial game and a real-world proving ground for our Unity, multiplayer, server and cloud capabilities.
CAPABILITY MAP
Clarify constraints, success criteria and technical boundaries.
Build in visible increments with ownership close to the code.
Test performance, recovery and real operating conditions.
Leave documentation, observability and a maintainable next step.
FAQ
We begin with current state, constraints, success criteria and the highest-risk assumption before defining implementation.
Yes. Ownership boundaries, codebase condition and delivery risk are mapped before production systems change.
Handover, embedded capacity or managed operation are agreed around the product and internal team.
RELATED PROOF & PATHS
NEXT STEP
A technical lead will review the current state and recommend the smallest useful next step.
Start a project