Sirenstead: From an Idle Idea to Mobile Emergency Command

The first version had a different working title: Idle Emergency. We imagined a city that would keep growing in the background while its numbers and resources increased. As we spent more time with the incidents, though, something became clear. Waiting for a number to rise was rarely the interesting part. Understanding an uncertain call and responding with the resources at hand was.

That change of focus became Sirenstead. We are now developing a mobile emergency management and strategy game in which the player directs fire, medical and police services across a growing city. A vehicle can only be in one place. New information can overturn an initial assessment. Sometimes a decision has to be made before the full picture is available.

Depth without a mountain of admin

Each new system raises a question: does it make a response decision more interesting? We could model staff rosters, salaries, fuel and every responder's individual equipment in detail. For Sirenstead, much of that would become administrative work. We want the depth to come from priorities, vehicle capabilities, travel times and reserves. The useful question is which unit to send now, and where it will be missed later.

The original idle concept has a smaller role as well. A break from the game can produce a limited amount of budget. Incidents do not secretly continue while the player is away; patients do not die, and reputation and research do not accrue offline. Putting down the phone should not be punished. Sirenstead finds its rhythm during active play.

One incident, not five tasks

Early calls were fairly simple: receive a report, send a vehicle, wait for an outcome. Several services and vehicle roles now work together. Units make actual journeys, remain occupied while working, return and may need recovery time. Ambulances can transport patients and hand them over at a hospital. Station locations, coverage and help from beyond the player's own fleet also affect the response.

Consider a road collision. The initial call says little about its severity. Fire crews arrive and assess the scene. Only then do they discover someone trapped in a vehicle. Technical rescue and medical support are needed. Treatment and transport follow the rescue; vehicle recovery may be required later. These are not five disconnected jobs with five artificial rewards. They are one incident whose needs change as the situation becomes clearer.

That chain is what makes dispatch interesting. The first unit must suit the information available, but the organisation also needs room to respond to surprises. Commit every reserve too early and the next call becomes harder to handle.

When the city applies pressure

Incidents do not simply arrive on a fixed timer. A system shaping the city's workload moves through calmer periods, a gradual build, periods of pressure and recovery. There is time to bring vehicles home and prepare for what comes next, as well as moments when everything cannot be solved at once.

If every ambulance is busy when another medical call arrives, prioritisation becomes the decision. The pressure should be real. At the same time, the game should not deliberately demand a solution that the player has not yet unlocked at all. Limited capacity creates meaningful choices; an impossible requirement rarely does.

A good result is not guaranteed. An incident can succeed, partially succeed or fail. Ignored calls do not remain in a list forever; an appropriate severe medical case can end in a death. Outcomes affect the organisation's reputation, which can fall below zero. That is not a game over. Command levels already reached, vehicles, research and districts remain in place. Better work on later calls can rebuild a damaged reputation.

An organisation that grows with the city

Progress has three separate parts. Reputation and Command Level represent responsibility and unlocks. Budget pays for vehicles, bays, stations and expansion. Research opens capabilities and operational options. Keeping these distinct makes each choice easier to understand: a good reputation cannot buy an ambulance, while a large budget cannot replace a capability the organisation lacks.

The current development range covers Command Levels 1 through 20. It gradually adds medical and police response to early fire calls, then technical rescue, incidents involving several services, doctor response vehicles, towing, a second station, an aerial ladder and simultaneous calls. Level 20 is a development boundary, not a promised final endgame. The pace and balance across that range still need to be tested in longer play sessions.

At first, it is possible to dispatch almost every vehicle by hand. In a larger city, that same routine would become cumbersome. This is why we are building response plans, plans for common calls and multiple services, recommendations, and tools for reserves and coverage. The longer-term direction is to let player-configured routines take on more everyday incidents. Unusual situations, shortages and decisions about locations and capacity can then take more of the player's attention. Manual intervention should remain possible at any point.

As the city grows, the player's role changes too: from dispatching one vehicle at a time towards directing an entire response organisation.

A city with its own time

Sirenstead now has its own clock and calendar. In the current development build, 15 minutes of active real time equal one game day. A season lasts 25 game days, and 100 days make a game year. A full cycle therefore takes roughly 25 active hours. These are current development values and may change as we balance the game.

Spring, summer, autumn and winter give the city a longer rhythm. Conditions can be clear or cloudy, with rain or snow; operational weather can also include storms, icy roads and heat. Day and night already change the presentation. Rain and snow have first functional visual versions, though neither is the final weather look.

We wanted the city's systems to work independently of any one visual effect. Weather and calendar can drive play while their appearance continues to improve. Better snowfall, for example, should be possible without rebuilding the clock or the response rules.

Designed for a small screen

The mobile interface is one of the larger areas of work right now. The compact HUD must show budget, reputation, Command Level, city time and weather without hiding the city. Station screens bring together service selection, fleet, readiness and expansion. Incidents have an overview, details, dispatch and plans; Research has its own main area.

This is a functional reorganisation, not a finished visual pass. We are still deciding what needs to be visible immediately and what is more useful when a particular decision arises. Touch targets, readability on different displays and both the English and German text matter just as much as the later art work.

The city itself is still largely a functional development world. Its current visual direction takes cues from Synty/POLYGON, with a more extensive world and art pass still to come. Over time, we are considering residential and mixed-use areas, commercial and civic centres, industry, coastal areas and larger transport routes. Different districts should do more than change the backdrop: routes, risks, incident types and station placement could all change with them.

Other ideas, such as roadworks, blocked streets, weather disruptions, major emergencies or a blizzard with advance warning, are possible directions rather than confirmed release features. The interesting part would be what preparation they allow: repositioning a reserve, reassessing a route or changing a routine for a while.

The next proof comes from playing

Many core systems are implemented and have been checked in the development environment. That does not mean they have been proven under every condition on real phones. Before substantial external testing, we need longer natural play sessions, balance across the current Command Levels, more weather cycles, and stress tests for major incidents and reserves. We also need Android and iOS device checks, different display sizes, safe areas, touch controls and both languages.

Everyday interruptions matter too: leaving the app briefly and returning, closing and resuming it, moving offline and back online. Saves and cloud accounts need checks for conflicts, account changes, reinstalls and play across devices. Implemented code, a check in the editor and a successful device test are three different claims. We do not want to confuse them.

Sirenstead is unfinished. It is also well beyond a collection of buttons for individual calls. The original idle idea has become a connected response organisation in which one decision can affect the rest of the city. The next important step is to spend more time with that whole system on real devices, and change what does not yet hold up.