Thanks for playing Condition Unknown! This is an in-depth post that explains the tech behind the game and discusses some design issues that are too spoiler-dependent to go in the developer notes. I strongly recommend playing the game before reading this. You may not want to read it at all if you prefer to keep things a mystery!

How It Works

Before we delve into discussion, let me give you a rundown of how I simulate research station RX-83 and its fate. The original idea was to simulate a sci-fi horror scenario, where something terrible happens somewhere remote, and you as the player stumble in later, riffing off games in the *Shock genre, games like Return of the Obra Dinn, and also films like Alien and The Thing (although I explicitly aim for a bad ending here, and then let you enter much later). My plan was to have many different catastrophe templates: an experiment goes wrong, someone betrays the crew, an invasion of government soldiers. In the end, I focused on just one: an alien artifact causes an unknown force to appear ("the anomaly"), it attacks the crew, and after attempting to escape or fight it, they all die.

We begin by generating the layout of the lab - very basic stuff here, I slap down an entrance room, then several corridors, and then rooms that attach to the corridors. We then assign room types to each - ensuring we always have one lab, and normally one security office, one residence area and one mess hall. Remaining rooms default to being extra labs, numbered to disambiguate them. Each room then gets decorated using patterns, so the security office has guns in and the mess hall has kitchen stuff in. The framework I built would've allowed me to extend a lot of these with extra behaviours and affordances, but in practice only a few elements matter, because time. Most important are research terminals, which appear all over the station, and fuel barrels, which appear in corridors. Once that's done we place 5-6 researchers (we randomly assign one to be the logistics supervisor, and one to be the security guard) and then place the Anomaly randomly too.

From here, we run a turn-based simulation. Each turn, anything in the world that needs to can update itself or act. Fire spreads, or might extinguish itself, for example. The Anomaly has relatively simple behaviours, for example if it sees someone, it'll chase them and try to kill them. The crew, however, have an incredibly messy web of overlapping behaviours and priorities. I decided not to build a Finite State Machine at the beginning of the jam, thinking it'd be overkill, and I was probably right to do this, but I lost six hours on the last day of the jam debugging an edge case that was making everyone stand still when they met the anomaly. If I was building a proper, game-sized thing, I'd definitely build a lot of tools for designing and debugging these behaviours.

In the end, I structured the behaviours so that they were somewhat flexible and could trigger in any situation, to give a little bit of emergence and system overlap, but the overall trajectory of the behaviours is actually designed to tend towards a particular narrative for the station. The rough arc everyone goes through is as follows:

• Initial phase: not alerted, everyday business (e.g. researchers work in labs).
• Alerted: something is wrong in the lab. Seek safe rooms, hole up in them.
• Endgame: most of the crew are dead, formulate a plan and act on it.

These phases are approximate, and are mixed up mostly by unpredictable factors like the anomaly or fire spread. Lots of things overlap and override these phases - for example, if you're fleeing for a safe room and come across a dead body and a corridor on fire, you'll trigger a bunch of reactions and adjust your plan. But broadly speaking the simulation will move through these three phases, kind of like a three-act play, not because there's a drama manager but just because the simulation has a certain gravity pulling it there - the more the anomaly does, the more likely someone will see it, thus triggering alerts and moving to phase 2, and so on. When everyone is dead, we erase the anomaly and put out all the fires and anything else needed to simulate the passing of time, and then before we spawn the player we do one final important thing: we populate the research terminals.

Along with a long list of behaviours and reactions, many events will also cause the crew to send messages to one another or comment on the situation. Each of these messages are logged, and then at the end they get distributed out to the research terminals, so the player can read them as they explore the station. These messages range from just exclamations of surprise or panic all the way to conversations about an explicit plan with names and locations. They're also all timestamped and all include at least one person's name (the sender) which can be vital information for solving the game. Each reaction usually has a few (3-4) variants, with keyword replacement to customise them, but it's a fairly basic system (with appalling writing) as I was in a bit of a rush. Serviceable, though.

The Benefits of Simulation

In Nothing Beside Remains we used very abstract simulations to model the village, and then tried to render a real version of it. Condition Unknown, as you can tell by now, uses much more detail in its simulation and thus doesn't actually need to render anything - we just show the player the simulation. Many games use simulation as a way of generating spaces for the player to inhabit, but both NBR and CU have explicit emphases on creating worlds where the player can or must learn something about the process that led to this point, which puts an extra twist on the use of simulation. Here are some things I observed from using a more detailed simulation for CU compared to NBR, and how it changed that process of creating a space the player could learn and intuit things from:

1. No Guesswork

On paper, an abstract simulation is great, because we get lots of artistic license. If we need 4 farms but we don't care where they are we could create farms outside town, scatter them around the village, put them near the church, make them community owned in the middle, loads of options. Except this is quite a creative decision and we don't have any particular reason to choose, so we'd probably do something boring like place them randomly, which isn't fun to make, and doesn't actually add anything for the player. But with a finer-grained simulation we don't need to do this: the fire spread to these tiles exactly, not even these rooms but exactly these parts of these rooms because we simulated it and that's where the fire went. The simulation is an automatic 'witness' - it specifies exactly how the events in story could have happened.

2. No Hidden/Overlapping Constraints

I really hate generating to constraints, testing every angle to make sure I've not missed something. Abstract simulations are full of this kind of thing. For instance, suppose we were using an abstract, high-level simulation for Condition Unknown and we add an event where someone spots their colleague injured in another room, and rushes in to help them. Great, exciting. Except now we need to make sure their colleague is actually visible from the corridor outside, which means raycasts and making sure there's space on the floor. And then it means making sure that doesn't violate any previous constraints, like where they were when they got attacked, and so on. With a direct simulation, if something happens - like someone shooting at the anomaly, missing, and hitting a fuel barrel  - we've already met all the constraints for it to happen, we know they could see the anomaly and the barrel and we know where they were standing. This is super convenient as a designer because we don't need to figure it out, but it's also amazing for a player because they can calculate their own sight lines and figure out possible shot trajectories. We encourage the player to trust the evidence in front of them because it's a 1:1 representation of the system the game used.

3. More Organic Events/Emergency

Related to the previous point, but suppose we want to have an event where someone notices the body of a crew member through a doorway again. In our high-level abstract simulation we're not tracking things like exact location or line of sight, we just record whether people are in a room or not. So in order to have this event happen we have to script more of it and add fudges in - if someone is in a room adjacent to a room with a body in, there's a percentage chance they notice the body, and so on. This not only is more of a burden to author, but it's also more likely to be identified as a single chunky event by players, as it's more and more likely to play out the same way each time. 

By contrast, finer-grained simulations also allow for finer-grained events, which lead to more emergence and event overlap. Because we simulate the precise location of people, we don't need to roll dice to see if the 'Notice Dead Colleague' event fires - we just check if they can see their dead colleagues or not. This lets smaller events build up into more unusual combinations (like not realising the anomaly is hiding behind the corner, and charging in to check on the person who's been hurt!)

Other Observations

Generative Forensics Games Are Absurdly Robust

I've never really built a game about agent simulations before, like a Sims-like or a Dwarf Fortress-like. I was a bit worried that my bad and quickly-written behaviour code would result in really weird behaviours, and that would create an immensely unsatisfying puzzle to solve. Because of the nature of the game and how it presents the simulation to the player, the weird things that the agents do are almost entirely undetectable by the time the game begins. Things like pathing in a stupid way, trying to walk past the anomaly, or getting too close to fire aren't visible to the player, because they only see the final resting place of the crew, and past events are only experienced through a select few messages. There were still some occasions where the game was sending contradictory messages (in one amusing bug the security officer misfired, the simulation decided he'd shot himself, and then had him report on how sad he was about this - that had to be fixed!) But these were easy to figure out and fix on the whole, whereas other issues like occasional weird pathing decisions were simply never fixed because they can't be detected in the final result.

I really like this because procedural generation really benefits from systems that can mask over rough edges and mistakes. This design format, of filtering and limiting the parts of the simulation the players gets to see rather than showing them everything a la Dwarf Fortress' Legends mode, means the player sees many fewer mistakes. Which also leads us to...

They Invite Generous Readings

When I made Nothing Beside Remains I was amazed at how deeply people engaged in the world and how much they read into the generation, even though the procedural generation was very basic. With Condition Unknown I found the same thing again, except it was even more powerful and actually began to fool me. For a long time I didn't notice many bugs in the game because if you only look at the end result it's really hard to tell if anything has gone wrong. And because we drop in little messages at defined points, we can add little bits of flair that imply a lot, leaving the player to guess what happens in the gap between messages. In one example, the last two crew members may formulate a plan to flee the station, and they discuss meeting up to do it together. In reality, this doesn't happen - they both individually try to escape and don't co-ordinate, but players can't tell this and are invited to guess at exactly how far they got before their plans were scuppered.

Leave Small Clues, Often

In the Developer Notes I mentioned how many attempts to procedurally generate mysteries rely heavily on fully proving a line of reasoning from start to finish. We explicitly don't do that here, but because our simulation is more direct we know that we could leave perfect information if we wanted to (as an extreme example, we could just leave a nametag on every crew member, which would make the game instantly solvable). The question here is how to make sure the mystery is solvable without doing a big long reasoning chain or similar. Our approach is to liberally sprinkle lots of small details, which individually do not give concrete proof about identity, but if enough accumulate they allow things to be narrowed down. For example, people will casually (and sometimes not so casually) remark on their location, who they are with, or where they hear sounds coming from. This combines nicely with the flattened end state of the simulation - for example, all barrels look equally exploded to the player when the game begins, but the messages allow them to guess at which ones exploded first, which might help illuminate part of the story.

The current version is a little more generous than the original version. In particular, we added fairly big clues indicating who the security officer and the logistics officer are (they're the two people not described as wearing lab coats). This is mostly to make the jam game more satisfying to play, but often this information wasn't technically needed to disambiguate. However, in some cases the game definitely wasn't solvable - at one point, the safe room policy led the crew to congregate in the same room when seeking refuge, which typically led to them all being killed simultaneously by the anomaly, which made it hard to distinguish who died when. This can still happen, so our approach is definitely not perfect compared to the more rigorous logic-backed approaches, but we like the tradeoff we get in a more organic feeling mystery.

Systems vs. Drama

By far one of the biggest challenges I encountered was building a simulation of how people would react in a crisis and having that contrast with what is interesting to uncover from a narrative standpoint. Some aspects of the system naturally gave rise to drama - people going to investigate noises, never coming back, people getting trapped in by fire. But a big problem I had was the ending: it's too dangerous to go outside, so people would find a safe room and just wait there until the anomaly killed them. This was a perfectly rational response to an alien ball of lightning, but it wasn't very interesting to come across later.

I solved this by injecting a bit of artifice - once there are only two crew members left, there's a chance the game will descend into an "endgame". The endgames are scripted triggers that set off a new chain of events to bring the story to a climax. There are two in the current simulation: one in which the crew try to run outside and escape, and one in which they raid the security office for guns and fight the anomaly. Both are guaranteed to get everyone killed, but they also add unique artifacts to the final simulation and create more interesting messages. In the escape case, players might actually discover bodies frozen in the snow before even entering the facility, which is a great dramatic moment. In the fighting case, this is the only way non-security crew can become armed, which is rare and leaves guns lying on the ground.

In my longer-term project plan, this actually won't be as necessary, and in fact I want to lean more on the banality of these simulations. Like in Nothing Beside Remains, my long-term goal is to create fairly soft simulations that just dwindle to a close, but it didn't feel appropriate for a scenario as catastrophic and condensed as Condition Unknown. So it was a bit of an extreme solution, but I like how it worked out (finding people outside in the snow is actually my favourite feature of the game's output space).

Things I Forgot To Write About

This post is already super-long, but even so I forgot to mention so many small details about the game's development, so I'm going to quickfire them in here as I remember them.

Telling A Story You Didn't Write

So at the end of the simulation we have a bunch of messages in chronological order, but one of the hallmarks of this kind of story is that this information is not received all at the same time, or in order. Games like Bioshock carefully place audio logs and notes so stories are told in a particular way, and information and twists are revealed at a particular time. Other games like Her Story have a looser structure, but there's a likely path the player might go down. In CU we have a list of messages, and a list of computers we can put the messages on - what do we put where?

There's a bunch of answers for this, but the one I ended up doing was a depth-chronology pairing, with a bit of handwaving in the mix. This means that as you go deeper into the station (i.e. further away from the entrance room) you find messages that were sent later in the simulation. This works partly because, well, anything would work to some degree - the player is totally free to explore anywhere, we don't gate progress or anything. But I also think it's quite good here because the simulation doesn't have twists or surprises. In Return Of The Obra Dinn one of the most important pieces of information is chronologically placed very early in the timeline, but in CU things pretty much get more revealing and desperate as time goes on, so it makes sense to put later messages deeper into the station so the player theoretically finds them later.

Next Steps

I got some great feedback from my playtesters on things they'd like to add - some of my favourite ideas include people tripping and stumbling as they run through the corridors, or finding artifacts like photographs of the crew to give the player information on what one particular person looks like. I'd also hoped originally to have anomaly variants that do different things, like telekinetically throw people around (which I deemed to be too confusing for the player) or mind control people into attacking their friends (plausible, but required too much writing). I might do another update later that adds some of these features in.

I'm also still slowly walking towards the really big thing I want to make with these ideas, probably a few years into the future. It would be the biggest thing I've ever made by a long margin, so I don't want to enter into it until I have a fairly good plan fleshed out. I look forward to make more of these small prototypes on the way there! In the meantime, you can keep in touch and up to date with my plans on Twitter or on my personal website (where you can also find my AI and creativity research).