Bad Goons
A flagship multiplayer FPS built around a battlefield players can destroy, excavate and rebuild during every match. Fully networked voxel destruction, dynamic capture points, construction and fortification, deployable spawn networks, procedural maps, tactical support assets and a broad arsenal create shifting front lines instead of static cover. The playable Early Access build is in active development toward its planned December 2026 Steam release, supported by shared developer-and-community playtests.
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.
NEXT STEP
A technical lead will review the current state and recommend the smallest useful next step.
Start a project