Unser Flaggschiff-Multiplayer-FPS mit einem Schlachtfeld, das Spieler in jedem Match zerstören, ausheben und neu errichten können. Vollständig vernetzte Voxelzerstörung, dynamische Kontrollpunkte, Bau und Befestigung, mobile Spawn-Netze, prozedurale Karten, taktische Unterstützung und ein breites Arsenal erzeugen bewegliche Frontlinien. Der spielbare Early-Access-Build wird aktiv für den geplanten Steam-Start im Dezember 2026 entwickelt und regelmäßig gemeinsam mit der Community getestet.
Ein Schlachtfeld, das sich mit jeder Entscheidung verändert.
Bad Goons ist ein teambasierter Multiplayer-Shooter nach einem einfachen Prinzip: Die Karte soll nie statisch bleiben. Spieler können Gräben ausheben, Verteidigungspositionen zerstören, neue Routen schaffen und die Frontlinie während des gesamten Matches verändern.
Unity-Client, Voxel-Simulation, Multiplayer-Modell, dedizierte Server und Cloud-Deployment sind als getrennte Systeme entworfen, die über eine gemeinsame technische Architektur verbunden sind. Das aktuelle Design zielt auf Schlachten mit 64 Spielern entlang einer sich verschiebenden Frontlinie.
IN-GAME
DIE ZENTRALE HERAUSFORDERUNG
Eine Welt synchronisieren, die jeder Spieler verändern kann.
Bewegung und Kampf müssen reaktionsschnell bleiben, während Terrainzerstörung, Aushub, Bau, Projektile und taktischer Zustand über viele verbundene Clients synchronisiert werden.
SPIELERNAHE ENTWICKLUNG
Das Erlebnis, das Spieler sehen, fühlen und steuern.
First-Person-Bewegung, Kampf und Waffenhandling
Dynamisches Voxel-Terrain, Graben und Erstellung von Schützengräben
Zerstörbare Deckung und platzierbare Befestigungen
Team-Spawn-, Ressourcen- und Versorgungssysteme
Taktisches UI, reaktives Audio und Schlachtfeld-Feedback
Performance-Profiling und Produktions-Tooling
MULTIPLAYER & BACKEND
Die Systeme, die den Kampf autoritativ und verbunden halten.
Client/Server-Prediction und State Reconciliation
Autoritative Dedicated-Server-Simulation
Replikation von Terrainänderungen sowie Spieler- und Teamzustand
Session-Lebenszyklus, Reconnect- und Recovery-Workflows
Headless-Linux-Builds und containerisiertes Deployment
Diagnostik, Monitoring und versionskontrollierte Releases
TECHNISCHE ARCHITEKTUR
Ein Produktionssystem mit expliziter Verantwortung auf jeder Ebene.
01 · CLIENT
Unity 6
Input, Präsentation, Rendering, Audio und vorhergesagte Spieleraktionen.
02 · ECHTZEIT
FishNet
Authority, Prediction, Reconciliation und synchronisierte Gameplay-Systeme.
03 · WELT
Voxel-Simulation
Von Spielern angelegte Gräben, veränderte Deckung und sich entwickelnde Kampfrouten.
04 · SERVER
Linux Headless
Autoritative Spieler, Kampf, Terrain und gemeinsamer Weltzustand.
05 · DEPLOYMENT
Docker
Konfigurierbare Serverpaketierung, Releases, Regionen und Runtime-Einstellungen.
06 · BETRIEB
Cloud-Infrastruktur
Health Monitoring, Diagnostik, Automatisierung und nachfragegesteuerte Kapazität.
Als Produktionsspiel gebaut, nicht als technisches Showcase.
Bad Goons befindet sich aktuell in aktiver Entwicklung. Zu den Kernarbeiten gehören Multiplayer-Kampf, dynamisches Terrain, Dedicated-Server-Deployment, taktische Spawn-Systeme und Produktions-Tooling. Es ist sowohl ein originales kommerzielles Spiel als auch ein realer Prüfstand für unsere Unity-, Multiplayer-, Server- und Cloud-Fähigkeiten.
CAPABILITY MAP
Von der Entscheidung bis zur Produktion.
01
Unity 6
Randbedingungen, Erfolgskriterien und technische Grenzen klären.
02
Groß angelegter Multiplayer-FPS
In sichtbaren Schritten bauen und die Verantwortung nah am Code halten.
03
Vernetzte Voxelzerstörung
Performance, Recovery und reale Betriebsbedingungen testen.
04
Bau und Befestigung
Dokumentation, Observability und einen wartbaren nächsten Schritt hinterlassen.
05
Dedizierte Linux-Server
06
Prozedurale Karten
07
Cloud-Bereitstellung
FAQ
Fragen speziell zu diesem Pfad.
Wie beginnt bad goons ?
Wir beginnen mit aktuellem Stand, Randbedingungen, Erfolgskriterien und der Annahme mit dem höchsten Risiko, bevor wir die Umsetzung festlegen.
Könnt ihr ein bestehendes Team verstärken?
Ja. Wir erfassen Verantwortungsgrenzen, Zustand der Codebase und Delivery-Risiko, bevor wir Produktionssysteme verändern.
Was passiert nach der Auslieferung?
Übergabe, eingebettete Kapazität oder Managed Operation stimmen wir auf Produkt und internes Team ab.