Internal Hazards #693
Replies: 4 comments 2 replies
-
|
Hazards feel like something that should be managed through what I've called the "narrative engine". Not only can it handle all the proposed scenarios here, it's far more flexible in how it delivers the next unit of action, registering any listeners for actions taken, and dynamically reacting to action or inaction in narrative appropriate ways. Hazards don't feel like something that ought to be tightly coupled to narrative, rather you might have the ability to say "there is a fire on deck 7 in this location" and that shows up somewhere. Damage could be simulated strictly or it could be driven by narrative events (wait 10 minutes, if a team hasn't been sent then break system X). This leaves the door open for creative storytelling that's not tightly bound to hard mechanics. For example, if you can place fire anywhere, you could have some added that doesn't cause damage and use that as the effect of some space ghost or something (a la Canada). #So, the ECS mechanics might be "we can place hazards in places, and they might influence some system in a deterministic way" but the narrative bits of "Officer foo is feeling sick after hanging out in the Torpedo room" don't have to be deterministic. They'd be drawn out of the pile of narrative events or scenarios played at any given time. |
Beta Was this translation helpful? Give feedback.
-
What isn't obvious to me is how the system knows to pull a narrative event out of the pile. I suggest it's something that the ECS mechanics handle semi-randomly by looking at what second storyline timelines are already active, how long it's been since a second storyline was activated, the activity/boredom of the crew, the current hazards, and whatever else might be going on in the system. |
Beta Was this translation helpful? Give feedback.
-
|
I think you're right. I had thought that a second "narrative engine" was the best fit here, and it might be worth looking at, however ECS could be made to get this working in some way. The difference is that unlike physics components, narrative components change slowly if at all. Once you know that the pirates are going to be at location X, that will be set for the rest of the game. Kicking it off, Someone is going to hit the "start" button when a mission begins. That would kick off the first timeline event, and that would kick off whatever parallel timelines. Preconditions and actions (including waiting for other stuff to happen, changing game state, etc.) should give you what you need for all of this. One action could be "grab the next possible outcome based on game state and play it". I do think that explicitly modeling parallel timelines might be a mistake. Rather, timeline behaviors emerge from the patterns embedded in the ECS systems. There shouldn't be a list of timelines running or, if there is, it's because you see certain components in the ECS simulation. This makes it far easier to tell dynamic stories that weave together or recurse on top of themselves. Too rigidly linear and it can't really do that. The hard part is tracking game narrative state. ECS is good for things that only need to remember one step back. Kinematics equations are like this. Narrative is built out of long running threads of state, where earlier states can influence stuff at the end of a long storyline. Ink LIST data structures are uniquely suited to this. They are like Enums and Sets at the same time. You can see if a current state is between two states, check list membership, and do intersections/unions. Having data that is infrequently updated but maintained in the ECS simulation that supports those properties would be helpful. |
Beta Was this translation helpful? Give feedback.
-
|
A hazard is going to
whatever system is used can generally use those as overarching factors as to how the ship is going to be affected during the mission. Even searching for a lost pet might occupy the equivalent of a repair crew - or are internal sensors sufficient to locate unexplained movement/heat signatures? All potential hazards should be evaluated on that basis - is there a future sci-fi methodology that will minimize or eliminate the impact of a given hazard. Especially radiation leaks, shouldn't there oughta be detectors everywhere? Some other thoughts - hazards and not-quite-hazards
Some of these suggestions could be engaging for the Science officer In addition to repair crews, you may have one or more security teams on board who would be appropriate responders for some of these emergencies. They would have a different impact on resource usage. If a security team responded to a food fight, then you would not have your repair crew depleted. Not sure if you want to differentiate that much. If there were a food fight at the same time as an intruder alert, you could then have a resource management problem. Suppose the enemy had some means of inciting a food fight as a diversion to cover their incursion? just spitballing here. |
Beta Was this translation helpful? Give feedback.
-
|
Those hazard examples you came up with absolutely fit the spirit of what I'm going for here. Great thoughts. |
Beta Was this translation helpful? Give feedback.
-
|
Here’s a few more hazards I could think of: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
This discussion just deals with hazards that happen inside the ship, though we might add another type of hazard for outside the ship later.
Hazards are localized events at a specific location which affect the NPC crew. NPC crew will have different attributes - these haven't been codified yet, but think of things like "health", "despondence", "bravery", and "excitement" as examples. When an NPC crew is in the area around the hazard, it affects those attributes.
Hazards can be generated automatically as part of a system being damaged or losing efficiency. They can also generate spontaneously.
Hazards can trigger timelines which start a second storyline of sorts for the bridge crew to address. Ideally, these begin as messages to bridge crew from NPC crew members talking about the hazard in a vague way, like a message coming to the medical bridge officer saying "Officer Stevens just came to his post and seems a little out of it. She says she came from the Torpedo control room. I wonder what's going on over there." In this example, it's a radiation leak in a torpedo that can be investigated by a security team and resolved by launching a torpedo or having a damage team fix it (and hopefully they think to equip the damage team with radiation protection suits).
After some time, if the medical officer doesn't attempt to address the problem, a more explicit message can be sent to the damage control bridge officer explaining the situation and telling them to do something to fix it.
Hazards can have a single way to address them, or there could be multiple ways to address them, each with their own risks and effectiveness. For example, if a fire has broken out in a room, it would be more effective to send a damage team than a medical team, and even more effective to send a team proficient in fire suppression. But it depends on what resources the crew has at their disposal.
Hazards can spread according to an algorithm, causing more harm to crew members.
Hazards can affect other systems, decreasing their efficiency.
Hazards can have a severity value, which determines how much they affect the NPC crew, as well as how serious the generated second story timeline is.
More examples of hazards
- Fire
- Mess hall fight
- Radiation sickness
- Broken water pipe
- Leaking coolant
- Escaped pet
- Oxygen leak
- Temperature spike
- Atmospheric contamination
- Turbolift malfunction
- Door lock malfunction
- Virus outbreak
- Food poisoning from contaminated rations
- Intruders
- Stolen equipment
- Missing crew members
What you should comment on:
Beta Was this translation helpful? Give feedback.
All reactions