Ausgewählte Arbeiten heutiger Teammitglieder von Backend Alchemist aus früheren Studio-, Führungs- und Auftragsrollen.
Wir beginnen mit dem Erlebnis, das funktionieren muss, klären Verantwortung und mögliche Fehlerpfade und wählen dann die kleinste Architektur, die sich verantwortungsvoll betreiben lässt. Jede Empfehlung wird anhand ihrer Auswirkungen auf Spieler, des Auslieferungsrisikos, der Teamkapazität und der Betriebskosten bewertet.
Ein Schlachtfeld, das sich mit jeder Entscheidung verändert.
Bad Goons ist ein teambasierter Multiplayer-Shooter mit einem einfachen Grundprinzip: Die Karte soll nie statisch bleiben. Spieler können Gräben ausheben, Verteidigungspositionen zerstören, neue Routen schaffen und die Frontlinie im Verlauf der Partie umformen.
Der Unity-Client, die Voxel-Simulation, das Multiplayer-Modell, die dedizierten Server und die Cloud-Bereitstellung sind als getrennte Systeme konzipiert und durch eine gemeinsame technische Architektur verbunden. Das aktuelle Design ist auf Schlachten mit 64 Spielern entlang einer sich verschiebenden Frontlinie ausgelegt.
DIE KERNHERAUSFORDERUNG
Eine Welt synchronisieren, die jeder Spieler verändern kann.
Bewegung und Kampf müssen reaktionsschnell bleiben, während Geländezerstörung, Aushub, Bauwerke, Projektile und taktische Zustände über zahlreiche verbundene Clients hinweg synchronisiert werden.
SPIELERORIENTIERTE ENTWICKLUNG
Das Erlebnis, das Spieler sehen, fühlen und steuern.
First-Person-Bewegung, Kampf und Waffenhandhabung
Dynamisches Voxel-Terrain, Aushub und Anlage von Gräben
Zerstörbare Deckung und platzierbare Befestigungen
Team-Spawn-, Ressourcen- und Versorgungssysteme
Taktische Benutzeroberfläche, reaktives Audio und Schlachtfeld-Feedback
Performance-Profiling und Produktionswerkzeuge
MULTIPLAYER & BACKEND
Die Systeme, die das Gefecht autoritativ und vernetzt halten.
Client-/Server-Vorhersage und Zustandsabgleich
Autoritative Simulation auf dedizierten Servern
Replikation von Geländeänderungen sowie Spieler- und Teamzuständen
Abläufe für Sitzungslebenszyklus, Wiederverbindung und Wiederherstellung
Headless-Linux-Builds und containerisierte Bereitstellung
Diagnostik, Monitoring und versionierte Releases
TECHNISCHE ARCHITEKTUR
Ein Produktionssystem mit klarer Verantwortung auf jeder Ebene.
01 · CLIENT
Unity 6
Eingabe, Präsentation, Rendering, Audio und vorhergesagte Spieleraktionen.
02 · ECHTZEIT
FishNet
Serverautorität, Vorhersage, Zustandsabgleich und synchronisierte Gameplay-Systeme.
03 · WELT
Voxel-Simulation
Von Spielern geschaffene Gräben, veränderte Deckung und sich wandelnde Kampfrouten.
04 · SERVER
Linux Headless
Autoritative Simulation von Spielern, Kampf, Gelände und gemeinsamem Weltzustand.
05 · BEREITSTELLUNG
Docker
Konfigurierbare Serverpakete, Releases, Regionen und Laufzeiteinstellungen.
06 · BETRIEB
Cloud-Infrastruktur
Zustandsüberwachung, Diagnostik, Automatisierung und bedarfsgesteuerte Kapazität.
Als Produktionsspiel entwickelt — nicht als technische Demonstration.
Bad Goons befindet sich derzeit in aktiver Entwicklung. Zu den Kernbereichen gehören Multiplayer-Kämpfe, dynamisches Gelände, die Bereitstellung dedizierter Server, taktische Spawn-Systeme und Produktionswerkzeuge. Das Projekt ist zugleich ein eigenes kommerzielles Spiel und ein realer Prüfstand für unsere Kompetenzen in Unity, Multiplayer, Servern und Cloud.
LEISTUNGSÜBERSICHT
Von der Entscheidung zur Produktion.
01
Analyse von Kontext und Rahmenbedingungen
Rahmenbedingungen, Erfolgskriterien und technische Grenzen klären.
02
Technische Verantwortung
In sichtbaren Schritten entwickeln, mit klarer Verantwortung nahe am Code.
03
Architektur- und Produktionsentscheidungen
Performance, Wiederherstellung und reale Betriebsbedingungen testen.
04
Betriebliche und Performance-Aspekte
Dokumentation, Beobachtbarkeit und einen wartbaren nächsten Schritt hinterlassen.
FAQ
Fragen speziell zu diesem Projektweg.
Wie beginnt bad goons ?
Wir beginnen mit dem aktuellen Stand, den Rahmenbedingungen, den Erfolgskriterien und der riskantesten Annahme, bevor wir die Implementierung definieren.
Können Sie in ein bestehendes Team einsteigen?
Ja. Wir erfassen Verantwortungsgrenzen, den Zustand der Codebasis und das Auslieferungsrisiko, bevor wir Produktionssysteme ändern.
Was geschieht nach der Auslieferung?
Übergabe, eingebettete Kapazität oder Managed Operations werden passend zum Produkt und zum internen Team vereinbart.