Sirenstead: Von der Idle-Idee zur mobilen Einsatzleitung

Unter dem Arbeitstitel Idle Emergency sollte die erste Fassung vor allem ein Idle Game werden. Die Stadt hätte sich im Hintergrund weiterentwickelt, während Zahlen und Ressourcen wuchsen. Doch je länger wir an den Einsätzen arbeiteten, desto deutlicher wurde: Der interessante Moment liegt nicht im Warten. Er liegt darin, einen unklaren Notruf zu verstehen und mit den verfügbaren Mitteln darauf zu reagieren.

Aus diesem Richtungswechsel ist Sirenstead entstanden. Heute entwickeln wir ein mobiles Einsatzmanagement- und Strategiespiel. Die Spielerin oder der Spieler leitet Feuerwehr, Rettungsdienst und Polizei einer wachsenden Stadt. Ein Fahrzeug kann nur an einem Ort sein. Eine neue Meldung kann die Einschätzung einer Lage verändern. Und manchmal muss eine Entscheidung getroffen werden, bevor alle Informationen vorliegen.

Tiefe ohne Verwaltungsapparat

Mit jedem neuen System stellte sich dieselbe Frage: Macht es eine Einsatzentscheidung interessanter? Wir hätten Dienstpläne, Gehälter, Treibstoff und die Ausrüstung jeder einzelnen Einsatzkraft detailliert verwalten können. Für Sirenstead wäre daraus vor allem mehr Pflegearbeit geworden. Die Tiefe soll aus Priorisierung, Fahrzeugfähigkeiten, Fahrzeiten und Reserven entstehen. Man soll überlegen, welche Einheit jetzt gebraucht wird und welche dadurch für den nächsten Notruf fehlt.

Auch die ursprüngliche Idle-Idee hat heute einen kleineren Platz. Bei einer Pause kann begrenzt Budget hinzukommen. Einsätze laufen in der Abwesenheit aber nicht heimlich weiter; es sterben keine Patienten, und weder Reputation noch Forschung entstehen offline. Wer das Spiel weglegt, soll nicht für diese Entscheidung bestraft werden. Sirenstead entfaltet seinen Rhythmus während der aktiven Spielzeit.

Eine Lage, nicht fünf Aufgaben

Frühe Einsätze waren vergleichsweise einfach: Meldung annehmen, ein Fahrzeug schicken, Ergebnis abwarten. Inzwischen greifen mehrere Dienste und Fahrzeugrollen ineinander. Einheiten fahren tatsächlich an, bleiben während ihrer Arbeit gebunden, kehren zurück und brauchen gegebenenfalls Rüstzeit. Rettungsfahrzeuge können Patienten transportieren und an einer Klinik übergeben. Standort, Abdeckung und Unterstützung von außerhalb der eigenen Organisation spielen ebenfalls eine Rolle.

Ein Beispiel zeigt besser, warum das wichtig ist. Ein Notruf meldet zunächst nur einen Verkehrsunfall. Die Feuerwehr trifft ein und erkundet die Lage. Erst vor Ort wird klar, dass eine Person eingeklemmt ist. Nun werden technische Rettung und Rettungsdienst benötigt. Nach der Befreiung folgen Versorgung und Transport; möglicherweise bleibt später noch eine Fahrzeugbergung. Das sind keine fünf voneinander unabhängigen Aufträge mit fünf künstlichen Belohnungen. Es ist ein Einsatz, dessen Anforderungen sich mit neuen Erkenntnissen verändern.

Genau diese Kette macht die Disposition interessant. Das zuerst entsandte Fahrzeug muss zur anfänglichen Lage passen, aber die Organisation muss auch auf Überraschungen reagieren können. Wer alle Reserven früh bindet, hat bei der nächsten Meldung weniger Spielraum.

Wenn die Stadt Druck macht

Einsätze entstehen nicht einfach in einem starren Takt. Ein System für die Einsatzdynamik führt die Stadt durch ruhigere Phasen, einen Belastungsaufbau, Drucksituationen und anschließende Erholung. Dadurch gibt es Zeit, Fahrzeuge zurückzuführen und die nächste Lage vorzubereiten – aber auch Momente, in denen nicht alles gleichzeitig gelöst werden kann.

Sind etwa alle Rettungswagen gebunden und kommt ein weiterer medizinischer Notruf hinzu, wird Priorisierung zur eigentlichen Spielentscheidung. Der Druck soll spürbar sein. Zugleich soll das Spiel nicht absichtlich Anforderungen stellen, für die auf dem erreichten Entwicklungsstand grundsätzlich noch keine Lösung freigeschaltet ist. Knappheit ist interessant; eine von vornherein unlösbare Aufgabe ist es selten.

Nicht jeder Einsatz endet deshalb perfekt. Eine Lage kann erfolgreich, teilweise erfolgreich oder erfolglos abgeschlossen werden. Ignorierte Einsätze verschwinden nicht endlos in einer Liste; schwere medizinische Fälle können unter passenden Umständen auch tödlich enden. Solche Ergebnisse wirken sich auf den Ruf der Organisation aus. Reputation kann sogar negativ werden, bedeutet aber kein Game Over. Erreichte Führungsstufen, Fahrzeuge, Forschung und erschlossene Bezirke bleiben erhalten. Aus einem schlechten Ruf kann man sich durch spätere Arbeit wieder herausarbeiten.

Die Organisation wächst mit der Stadt

Für den Fortschritt trennen wir drei Dinge. Reputation und Führungsstufe stehen für Verantwortung und neue Freischaltungen. Mit Budget werden Fahrzeuge, Stellplätze, Wachen und Ausbau finanziert. Forschung eröffnet zusätzliche Fähigkeiten und operative Möglichkeiten. Diese Achsen sollen Entscheidungen verständlich halten: Ein guter Ruf allein kauft noch keinen Rettungswagen, und ein volles Budget ersetzt keine passende Fähigkeit.

Die derzeitige Entwicklung reicht von Führungsstufe 1 bis 20. Schrittweise kommen zum frühen Feuerwehrbetrieb weitere Dienste und Aufgaben hinzu: Rettungsdienst, Polizei, technische Rettung, gemeinsame Einsätze, Notarztfahrzeug, Abschleppdienst, eine zweite Wache, Drehleiter und parallele Lagen. Stufe 20 ist eine aktuelle Entwicklungsgrenze, kein angekündigtes endgültiges Ende des Spiels. Gerade über diesen Bereich hinweg müssen Tempo und Balance noch in längeren Spielverläufen geprüft werden.

Zu Beginn kann man die wenigen Fahrzeuge fast vollständig selbst disponieren. Mit einer größeren Stadt wäre dieselbe Handarbeit irgendwann unpraktisch. Deshalb entstehen Alarmierungs- und Routinepläne, Pläne für mehrere Dienste, Empfehlungen sowie Werkzeuge für Reserve und Abdeckung. Die langfristige Richtung ist, alltägliche Einsätze zunehmend einer vom Spieler eingerichteten Routine zu überlassen. Dann rücken ungewöhnliche Lagen, Engpässe und Entscheidungen über Standorte und Kapazitäten in den Vordergrund. Manuelles Eingreifen soll dabei jederzeit möglich bleiben.

So verändert sich mit der Stadt auch die Rolle des Spielers: vom direkten Alarmieren einzelner Fahrzeuge hin zur Leitung einer Einsatzorganisation.

Eine Stadt mit eigener Zeit

Sirenstead hat inzwischen eine eigene Uhr und einen Kalender. Im aktuellen Entwicklungsstand entsprechen 15 aktive reale Minuten einem Spieltag. Nach 25 Spieltagen wechselt die Jahreszeit; 100 Tage bilden ein Spieljahr. Ein vollständiger Jahreslauf dauert damit ungefähr 25 aktive Spielstunden. Diese Werte gehören zum jetzigen Entwicklungsstand und können sich beim Balancing noch ändern.

Frühling, Sommer, Herbst und Winter geben der Stadt einen zeitlichen Rahmen. Wetter kann klar oder bewölkt sein, Regen oder Schnee bringen; operative Lagen wie Sturm, Glätte oder Hitze können zusätzliche Auswirkungen haben. Tag und Nacht verändern bereits die Darstellung. Für Regen und Schnee gibt es erste funktionale visuelle Fassungen. Sie sind noch nicht der endgültige Wetter-Look.

Wichtig war uns, dass der Ablauf der Stadt nicht von einem bestimmten visuellen Effekt abhängt. Wetter und Kalender funktionieren als Spielsysteme, während ihre Darstellung später weiter verfeinert werden kann. So lässt sich etwa ein besserer Schneefall ergänzen, ohne die Zeitrechnung oder die Einsatzlogik neu aufzubauen.

Ein Spiel für den kleinen Bildschirm

Die mobile Oberfläche ist derzeit eine der größeren Baustellen. Das kompakte HUD muss Budget, Ruf, Führungsstufe, Stadtzeit und Wetter zeigen, ohne die Stadt zu verdecken. Wachen bündeln Dienstwahl, Fuhrpark, Bereitschaft und Ausbau. Im Einsatzbereich liegen Übersicht, Details, Alarmierung und Pläne; Forschung hat einen eigenen Hauptbereich.

Diese Ordnung ist eine funktionale Überarbeitung, kein fertiger visueller Endzustand. Wir prüfen weiter, welche Information sofort sichtbar sein muss und welche erst bei einer konkreten Entscheidung hilft. Touch-Flächen, Lesbarkeit auf unterschiedlichen Displays und die DE/EN-Texte gehören genauso dazu wie der spätere große Visual Pass.

Auch die heutige Stadt ist vor allem eine funktionale Entwicklungswelt. Ihre aktuelle visuelle Richtung orientiert sich an Synty/POLYGON; eine umfassendere eigene Gestaltung steht noch aus. Langfristig denken wir über Wohngebiete, gemischte Quartiere, Gewerbe, Innenstadt, Industrie, Küstenbereiche und größere Verkehrsachsen nach. Unterschiedliche Bezirke sollen mehr bedeuten als neue Kulissen: Wege, Risiken, Einsatzarten und die Frage nach geeigneten Wachen könnten sich dadurch verändern.

Weitere Ideen – etwa Baustellen, Straßensperren, Wetterbehinderungen, besondere Großlagen oder eine vorwarnbare Schneekatastrophe – sind mögliche Entwicklungsrichtungen. Sie sind keine zugesagten Releasefunktionen. Interessant wäre vor allem, wie viel Vorbereitung solche Ereignisse erlauben: eine Reserve verlegen, eine Route neu bewerten oder eine Routine vorübergehend ändern.

Der nächste Beweis liegt im Spielen

Viele Kernsysteme sind implementiert und im Entwicklungsumfeld geprüft. Daraus folgt noch nicht, dass sie auf echten Telefonen unter allen Bedingungen bestehen. Vor ernsthaften externen Tests brauchen wir längere natürliche Spielverläufe, Balance über die bisherigen Führungsstufen, mehr Wetterzyklen und Belastungstests für Großlagen und Reserven. Dazu kommen Android- und iOS-Geräte, verschiedene Bildschirmgrößen, sichere Flächen, Touch-Bedienung und beide Sprachen.

Ebenso wichtig sind Unterbrechungen des echten Alltags: eine App kurz verlassen und wieder öffnen, sie beenden und fortsetzen, offline und wieder online gehen. Bei Spielständen und Cloud-Konten müssen Konflikte, Kontowechsel, Neuinstallation und mehrere Geräte geprüft werden. Implementierter Code, ein Test im Editor und ein bestandener Gerätetest sind drei verschiedene Aussagen. Wir möchten sie nicht miteinander verwechseln.

Sirenstead ist damit noch nicht fertig. Es ist aber auch längst nicht mehr nur eine Sammlung von Einsatzbuttons. Aus der ursprünglichen Idle-Idee ist eine zusammenhängende Einsatzorganisation geworden, in der einzelne Entscheidungen Folgen für die ganze Stadt haben. Der nächste wichtige Schritt ist, dieses Zusammenspiel über längere Zeit und auf echten Geräten zu erleben – und dort zu korrigieren, wo es noch nicht trägt.