Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

How do you stop interconnected simulation systems becoming impossible to manage?

A topic by t0m_ok created 27 days ago Views: 123 Replies: 2
Viewing posts 1 to 4

I've been building a fairly detailed emergency department simulation, and I've reached the point where one of the hardest parts isn't adding new systems. It's stopping those systems from accidentally destroying each other ๐Ÿ˜ญ

The basic patient flow originally sounded fairly simple:

arrival โ†’ triage โ†’ assessment โ†’ investigations โ†’ treatment โ†’ discharge/admission

But then I added staffing, different clinical areas, deterioration, ambulances, investigations, ward beds, boarding, exit block, shift changes, configurable departments, emergency scenarios, saving/loading, etc.

Now almost everything affects something else.

One recent example was allowing clinical areas to be disabled.

The UI knew Resus was disabled.

The department configuration knew Resus was disabled.

The arrival system did not.

So RED patients happily continued arriving for a Resus that technically no longer existed ๐Ÿ˜ญ

Another involved additional staff.

Extra staff requests needed to survive shift changes, but instead of remembering the existing request, part of the system effectively added it again at every handover.

So you could get:

3 โ†’ 6 โ†’ 12 โ†’ 24 โ†’ 48 โ†’ oh no

After enough simulated time this could turn into thousands of staff records.

I've also had patients deteriorate after an admission decision and accidentally restart parts of their clinical journey, causing repeated assessments, investigations and referrals.

Saving has probably been the most interesting problem.

There can be hundreds of patients at different stages, future events waiting in a queue, investigations due back later, staff working shifts, ambulances arriving, patients waiting for beds, etc.

The player can then close the browser and return hours later, at which point the simulation has to rebuild all of that and work out what happened while they were away.

It's made me realise that every new interconnected system potentially increases the number of weird interactions between all the existing ones.

I'm curious how people working on simulation/management games deal with this.

  • Do you try to keep systems deliberately isolated?
  • Do you have really strict interfaces between systems?
  • Do you rely heavily on automated tests and simulation runs?

Or is a certain amount of "why are there suddenly 4,000 nurses?" just an unavoidable part of making this sort of game? ๐Ÿ˜ญ

We hit the disabled Resus kind of bug a lot in our own simulation games, and two rules fixed most of it.

First, give every fact one owner and make everything else ask. Instead of the arrival system keeping its own idea of which areas are open, it calls the same isAreaOpen() the UI calls. A copy of a fact is a second fact, and the two drift apart.

Second, put each state change behind one door. In one of ours a wreck could happen two ways, and only one path charged the fine and counted it. Moving that settling into the transition itself, so every path runs it exactly once, fixed the whole class.

A cheap test for what's left: for every piece of state something reads, check that something writes it.

(We build our games with AI tools. These come from bugs in our own sims.)

(1 edit)
I'd try two handovers with and without saving and reloading, then compare the extra staff count. A request for three extra staff shouldn't turn into six or twelve. That could help narrow down whether the duplication comes from handover itself or from restoring the saved state.