From 4211611cf5917e7be380bb702c3ecae6343619c9 Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Tue, 31 Mar 2026 13:52:29 -0600 Subject: [PATCH 01/14] Design Pillars --- src/SUMMARY.md | 3 ++- src/development/design-doc-main.md | 16 ++++++++++++++ src/development/design-pillars.md | 34 ++++++++++++++++++++++++++++++ 3 files changed, 52 insertions(+), 1 deletion(-) create mode 100644 src/development/design-doc-main.md create mode 100644 src/development/design-pillars.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 9af789a..7453d99 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -15,7 +15,8 @@ Development =================== ---------------------- -- [todo](404.md) +- [Design Pillars](development/design-pillars.md) +- [Design Documents](development/design-doc-main.md) Rules and Policy =============== diff --git a/src/development/design-doc-main.md b/src/development/design-doc-main.md new file mode 100644 index 0000000..f0257dd --- /dev/null +++ b/src/development/design-doc-main.md @@ -0,0 +1,16 @@ +Design Documents +================ + +A design documents are meant to be a way of proposing changes or reworks to a large or important part of the game. It is a way of laying out the reasoning, effects, consequences, and goals of a change, and ensuring it aligns with our [design pillars](design-pillars.md). + +A well-crafted proposal will be reviewed by maintainers for feedback. The rest of the community can also speak to provide feedback on the proposal as well. + +## Proposal Guidelines + +A good proposal should include the following: +- A detailed explanation of the changes intended to be made +- Why the changes are positive and how they align with our design goals +- The potential consequences of the change and how they will be addressed +- Should be well written and thought out + +Even if a proposal follows these guidelines, it does not guarantee its acceptance. It is up to the maintainers to decide whether the changes fits within the Moffstation project. \ No newline at end of file diff --git a/src/development/design-pillars.md b/src/development/design-pillars.md new file mode 100644 index 0000000..fb3d543 --- /dev/null +++ b/src/development/design-pillars.md @@ -0,0 +1,34 @@ +Design Pillars +============== + +Listed here are the design pillars for **Moffstation**. These pillars are intended to give Moffstation a unique vision for SS14 that can be tangibly worked towards. + +Every feature, mechanic, design, and change made to Moffstation should abide by these pillars. + +## Social Interaction +All elements of the game should be social in some manner. There should not be elements which exist sole to engage individuals playing in an isolated manner. Even if mechanics are not inherently social, they should still prompt meaningful social gameplay through their interaction with other systems. + +## Round Investment / Event-Driven Pressure + +Players should become invested in the station and it's continued existence over the course of the round. This can be integrated into the job gameplay loop, and can be done by creating accomplishments that are not easily repeated across rounds, and feel fulfilling to players. While there should be downtime, no job should feel like their role on the station is "over", there should be a wide array of things for them to work towards. + +The disaster aspect of a round should not all hinge on a single event. Disasters should be reoccurring events and interface with the mechanics of the various departments across the station. The round should end when the effects of these disasters compound and create a situation that is difficult to overcome. + +``` admonish note +The station should have a decent amount of vitality, there should not be parts of the station which warrant ending the round upon their destruction alone, they should be able to be reconstructed, substituted, etc. + +Additionally, the recovery effort should be made fun where possible. +``` + +## Story Generator + +The game is not about winning or losing, its about creating an interesting story. + +No round should feel the same as the last; there should be a large amount of variety and randomness, both impactful and small, to give each round an authentic feeling. + +Similarly, features should be designed to encourage players to treat every situation with nuance. For example, a single event could have many variations, which influence how the crew responds. Avoid creating events which have consistent outcomes or solutions. + +## Credits +Some ideas taken in part, whole, or conceptually from the following: +- [Ephemeral Space](https://ephemeralspace.github.io/docs/design/pillars.html) +- [Funky Station](https://docs.funkystation.org/design/design-principles.html) \ No newline at end of file From 1686d78c5a66ee20d437dc5a40935465c803b73d Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Tue, 31 Mar 2026 13:56:59 -0600 Subject: [PATCH 02/14] grammar change --- src/development/design-pillars.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/development/design-pillars.md b/src/development/design-pillars.md index fb3d543..0d80986 100644 --- a/src/development/design-pillars.md +++ b/src/development/design-pillars.md @@ -15,7 +15,7 @@ Players should become invested in the station and it's continued existence over The disaster aspect of a round should not all hinge on a single event. Disasters should be reoccurring events and interface with the mechanics of the various departments across the station. The round should end when the effects of these disasters compound and create a situation that is difficult to overcome. ``` admonish note -The station should have a decent amount of vitality, there should not be parts of the station which warrant ending the round upon their destruction alone, they should be able to be reconstructed, substituted, etc. +The station should have a decent amount of vitality, there should not be parts of the station which warrant ending the round upon their destruction alone, infrastucture should be able to be reconstructed, substituted, etc. Additionally, the recovery effort should be made fun where possible. ``` From 97f6ffbd57e6466293546c1275e8b83624ef0688 Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Tue, 31 Mar 2026 13:58:15 -0600 Subject: [PATCH 03/14] another grammar --- src/development/design-doc-main.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/development/design-doc-main.md b/src/development/design-doc-main.md index f0257dd..cef489f 100644 --- a/src/development/design-doc-main.md +++ b/src/development/design-doc-main.md @@ -1,7 +1,7 @@ Design Documents ================ -A design documents are meant to be a way of proposing changes or reworks to a large or important part of the game. It is a way of laying out the reasoning, effects, consequences, and goals of a change, and ensuring it aligns with our [design pillars](design-pillars.md). +A design documents are meant to be a way of proposing changes or reworks to a large or important part of the game. It is a way of laying out the reasoning, effects, consequences, and goals of a change, and ensuring they align with our [design pillars](design-pillars.md). A well-crafted proposal will be reviewed by maintainers for feedback. The rest of the community can also speak to provide feedback on the proposal as well. @@ -13,4 +13,4 @@ A good proposal should include the following: - The potential consequences of the change and how they will be addressed - Should be well written and thought out -Even if a proposal follows these guidelines, it does not guarantee its acceptance. It is up to the maintainers to decide whether the changes fits within the Moffstation project. \ No newline at end of file +Even if a proposal follows these guidelines, it does not guarantee its acceptance. It is up to the maintainers to decide whether the changes fit within the Moffstation project. \ No newline at end of file From 3d7acef361f78f331313d193ff1db311f648f5ba Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Tue, 31 Mar 2026 13:59:18 -0600 Subject: [PATCH 04/14] More grammar --- src/development/design-doc-main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/development/design-doc-main.md b/src/development/design-doc-main.md index cef489f..bdfef68 100644 --- a/src/development/design-doc-main.md +++ b/src/development/design-doc-main.md @@ -1,7 +1,7 @@ Design Documents ================ -A design documents are meant to be a way of proposing changes or reworks to a large or important part of the game. It is a way of laying out the reasoning, effects, consequences, and goals of a change, and ensuring they align with our [design pillars](design-pillars.md). +Design documents are meant to be a way of proposing changes or reworks to a large or important part of the game. It is a way of laying out the reasoning, effects, consequences, and goals of a change, and ensuring they align with our [design pillars](design-pillars.md). A well-crafted proposal will be reviewed by maintainers for feedback. The rest of the community can also speak to provide feedback on the proposal as well. From c52d1e666fd1b592f760939c18ab43ef310db057 Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Tue, 31 Mar 2026 14:16:46 -0600 Subject: [PATCH 05/14] Some additions --- src/development/design-doc-main.md | 6 +++--- src/development/design-pillars.md | 15 ++++++++++----- 2 files changed, 13 insertions(+), 8 deletions(-) diff --git a/src/development/design-doc-main.md b/src/development/design-doc-main.md index bdfef68..4810c0d 100644 --- a/src/development/design-doc-main.md +++ b/src/development/design-doc-main.md @@ -3,14 +3,14 @@ Design Documents Design documents are meant to be a way of proposing changes or reworks to a large or important part of the game. It is a way of laying out the reasoning, effects, consequences, and goals of a change, and ensuring they align with our [design pillars](design-pillars.md). -A well-crafted proposal will be reviewed by maintainers for feedback. The rest of the community can also speak to provide feedback on the proposal as well. +A well-crafted proposal will be reviewed by maintainers for feedback. The rest of the community may also constructive feedback. ## Proposal Guidelines A good proposal should include the following: - A detailed explanation of the changes intended to be made -- Why the changes are positive and how they align with our design goals +- The reasoning behind the change, and it aligns with our design goals - The potential consequences of the change and how they will be addressed -- Should be well written and thought out +- Proper grammar Even if a proposal follows these guidelines, it does not guarantee its acceptance. It is up to the maintainers to decide whether the changes fit within the Moffstation project. \ No newline at end of file diff --git a/src/development/design-pillars.md b/src/development/design-pillars.md index 0d80986..7702453 100644 --- a/src/development/design-pillars.md +++ b/src/development/design-pillars.md @@ -8,14 +8,14 @@ Every feature, mechanic, design, and change made to Moffstation should abide by ## Social Interaction All elements of the game should be social in some manner. There should not be elements which exist sole to engage individuals playing in an isolated manner. Even if mechanics are not inherently social, they should still prompt meaningful social gameplay through their interaction with other systems. -## Round Investment / Event-Driven Pressure +## Round Investment / Event-Driven -Players should become invested in the station and it's continued existence over the course of the round. This can be integrated into the job gameplay loop, and can be done by creating accomplishments that are not easily repeated across rounds, and feel fulfilling to players. While there should be downtime, no job should feel like their role on the station is "over", there should be a wide array of things for them to work towards. +Players should become invested in the station and it's continued existence over the course of a round. This should be integrated into the job gameplay loop, and can be done by creating meaningful accomplishments that are not easily repeated across rounds. While there should be downtime, no job should feel like their role on the station is "over", there should be a wide array of things for them to work towards. -The disaster aspect of a round should not all hinge on a single event. Disasters should be reoccurring events and interface with the mechanics of the various departments across the station. The round should end when the effects of these disasters compound and create a situation that is difficult to overcome. +The disaster aspect of a round should not all hinge on a single event. Disasters should be reoccurring and interface with the mechanics of the various departments. The round should end when the effects of these disasters compound and create a situation that is difficult for the crew to overcome. ``` admonish note -The station should have a decent amount of vitality, there should not be parts of the station which warrant ending the round upon their destruction alone, infrastucture should be able to be reconstructed, substituted, etc. +The station should have vitality, there should not be parts of the station which warrant evacuation upon their destruction alone, infrastucture should be able to be reconstructed, substituted, etc. Additionally, the recovery effort should be made fun where possible. ``` @@ -26,7 +26,12 @@ The game is not about winning or losing, its about creating an interesting story No round should feel the same as the last; there should be a large amount of variety and randomness, both impactful and small, to give each round an authentic feeling. -Similarly, features should be designed to encourage players to treat every situation with nuance. For example, a single event could have many variations, which influence how the crew responds. Avoid creating events which have consistent outcomes or solutions. +Similarly, features should be designed to encourage players to treat every situation with nuance. For example, a single event could have many variations, which influence how the crew responds. + +``` admonish warning +Avoid designing events which have consistent outcomes or solutions. +For example, yelling "nukies!!" on the radio, followed by the crew arming up and responding may be interesting the first couple times, but becomes repetative, and doesn't make for an interesting story. +``` ## Credits Some ideas taken in part, whole, or conceptually from the following: From 4509cf36fc2f55a33e706e683e0653428ce5eaeb Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Tue, 31 Mar 2026 14:25:35 -0600 Subject: [PATCH 06/14] Event Actors --- src/development/design-doc-rotating-ghosts.md | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 src/development/design-doc-rotating-ghosts.md diff --git a/src/development/design-doc-rotating-ghosts.md b/src/development/design-doc-rotating-ghosts.md new file mode 100644 index 0000000..199035c --- /dev/null +++ b/src/development/design-doc-rotating-ghosts.md @@ -0,0 +1,32 @@ +Event Player Recycing +=============== + +The concept of having ghosts which will persistently come in as events for the players. + +This specific pool of players will act in the role that NPCs would normally play in most video games, playing as characters from random events that befall the station. These can be ostensibly crew-aligned events such as wandering shuttles, or hostile events like pirates. + +These will replace the existing system for antags as well as the majority of ghost roles, as this system ensures theyre taken, and incentivizes their interaction with the round, and ensures the round has persistant threats even after antags are removed from play. + + +## Roundflow +A ratio of players will be set aside to fill the roles of the round events. Ideally these are broken up into groups of 3-4 people. + +- These people will then get to vote on a limited list of spawns they can come in as, as well as what their objective will be (both for friendly and antags). + + +- They will also be given a timer to indicate when they will spawn, ideally they will either be spectating, in a bar, or something to keep them entertained while they wait. + +- After they spawn in, they will be given a timer to complete their objective and leave the map, or extracate in some other form. + +- If all or some of them don't extracate in some form before their timer runs out, different actions will be taken depending on whether they are antag or crew-aligned + - If they are crew-aligned, it can be assumed they have joined the crew in some capacity, and their slots will be opened up. + - If they are antags, their slots should be opened up for people to steal, additionally a heavy disadvantage should be forced upon them, encouraging them to withdraw or risk losing their spot. + +## Advantages + +I view this as an improvement over the dynamic gamemode by itself, as this ensures the consistancy of events throughout the round, whereas dynamic relies heavily upon people taking ghost roles. Additionally this gives the opprotunity for roles that arent explicitly hostile to have a larger impact on the round, and make things more interesting. + +## Considerations + +- This relies upon antags taking decisive action to drive the round, so it will likely require altering existing antags to dissuade them from protracted conflict + - for example, traitors could be forced to select all their gear at the same time, in order to make them \ No newline at end of file From 7571aafbfb9c55c78edb65234fe06cfcf86330fd Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Wed, 1 Apr 2026 11:12:19 -0600 Subject: [PATCH 07/14] suggestions applied Co-authored-by: Centronias --- src/development/design-doc-main.md | 6 +++--- src/development/design-pillars.md | 11 +++++------ 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/src/development/design-doc-main.md b/src/development/design-doc-main.md index 4810c0d..cff98cb 100644 --- a/src/development/design-doc-main.md +++ b/src/development/design-doc-main.md @@ -3,14 +3,14 @@ Design Documents Design documents are meant to be a way of proposing changes or reworks to a large or important part of the game. It is a way of laying out the reasoning, effects, consequences, and goals of a change, and ensuring they align with our [design pillars](design-pillars.md). -A well-crafted proposal will be reviewed by maintainers for feedback. The rest of the community may also constructive feedback. +A well-crafted proposal will be reviewed by maintainers for feedback. The rest of the community may also contribute constructive feedback. ## Proposal Guidelines A good proposal should include the following: - A detailed explanation of the changes intended to be made -- The reasoning behind the change, and it aligns with our design goals -- The potential consequences of the change and how they will be addressed +- The reasoning behind the change, and how it aligns with our design goals +- The potential negative consequences of the change and how they will be addressed - Proper grammar Even if a proposal follows these guidelines, it does not guarantee its acceptance. It is up to the maintainers to decide whether the changes fit within the Moffstation project. \ No newline at end of file diff --git a/src/development/design-pillars.md b/src/development/design-pillars.md index 7702453..3f581ad 100644 --- a/src/development/design-pillars.md +++ b/src/development/design-pillars.md @@ -10,19 +10,18 @@ All elements of the game should be social in some manner. There should not be el ## Round Investment / Event-Driven -Players should become invested in the station and it's continued existence over the course of a round. This should be integrated into the job gameplay loop, and can be done by creating meaningful accomplishments that are not easily repeated across rounds. While there should be downtime, no job should feel like their role on the station is "over", there should be a wide array of things for them to work towards. +Players should become invested in the station and its continued existence over the course of a round. This should be integrated into the job gameplay loop, and can be done by creating meaningful accomplishments that are not easily repeated across rounds. While there should be downtime, no job should feel like their role on the station is "over", there should be a wide array of things for them to work towards. -The disaster aspect of a round should not all hinge on a single event. Disasters should be reoccurring and interface with the mechanics of the various departments. The round should end when the effects of these disasters compound and create a situation that is difficult for the crew to overcome. +The disaster aspect of a round should not all hinge on a single event. Disasters should be reoccurring and interface with the mechanics of the various departments. The round should end when the effects of these disasters compound and create a situation that is too difficult for the crew to overcome. -``` admonish note -The station should have vitality, there should not be parts of the station which warrant evacuation upon their destruction alone, infrastucture should be able to be reconstructed, substituted, etc. +The station should have vitality, there should be no small part of the station which warrants evacuation upon its destruction alone, infrastructure should be able to be reconstructed, substituted, etc. Additionally, the recovery effort should be made fun where possible. ``` -## Story Generator +## Collaborative story Generator -The game is not about winning or losing, its about creating an interesting story. +The game is not about winning or losing; it's about creating an interesting story. No round should feel the same as the last; there should be a large amount of variety and randomness, both impactful and small, to give each round an authentic feeling. From ec825aaf9d47af7f1201014652327c34f1273581 Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Wed, 1 Apr 2026 15:36:53 -0600 Subject: [PATCH 08/14] maybe clarifying --- src/development/design-pillars.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/development/design-pillars.md b/src/development/design-pillars.md index 3f581ad..d44c435 100644 --- a/src/development/design-pillars.md +++ b/src/development/design-pillars.md @@ -14,21 +14,25 @@ Players should become invested in the station and its continued existence over t The disaster aspect of a round should not all hinge on a single event. Disasters should be reoccurring and interface with the mechanics of the various departments. The round should end when the effects of these disasters compound and create a situation that is too difficult for the crew to overcome. +```admonish note The station should have vitality, there should be no small part of the station which warrants evacuation upon its destruction alone, infrastructure should be able to be reconstructed, substituted, etc. Additionally, the recovery effort should be made fun where possible. ``` -## Collaborative story Generator +## Collaborative Story Generator The game is not about winning or losing; it's about creating an interesting story. -No round should feel the same as the last; there should be a large amount of variety and randomness, both impactful and small, to give each round an authentic feeling. +Good stories happen when players are emerged in unfamiliar situations, and are able to create interesting, bizarre, or unique outcomes. When situations are predictable or solved the same way every time, players stop engaging with the scenario and instead follow learned patterns. + +This is to say, every round should feel unique and different from the last. +- Variation and randomness should play a big role in defining each round. +- Avoid designing systems which have consistent outcomes or solutions. +- Players should have to use discernment when engaging with what's happening to the station. -Similarly, features should be designed to encourage players to treat every situation with nuance. For example, a single event could have many variations, which influence how the crew responds. ``` admonish warning -Avoid designing events which have consistent outcomes or solutions. For example, yelling "nukies!!" on the radio, followed by the crew arming up and responding may be interesting the first couple times, but becomes repetative, and doesn't make for an interesting story. ``` From c1c37a193176f338dc7ff6d909517a0fda6ffa5c Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Thu, 2 Apr 2026 11:18:34 -0600 Subject: [PATCH 09/14] typo --- src/development/design-pillars.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/development/design-pillars.md b/src/development/design-pillars.md index d44c435..4f70387 100644 --- a/src/development/design-pillars.md +++ b/src/development/design-pillars.md @@ -24,7 +24,7 @@ Additionally, the recovery effort should be made fun where possible. The game is not about winning or losing; it's about creating an interesting story. -Good stories happen when players are emerged in unfamiliar situations, and are able to create interesting, bizarre, or unique outcomes. When situations are predictable or solved the same way every time, players stop engaging with the scenario and instead follow learned patterns. +Good stories happen when players are immersed in unfamiliar situations, and are able to create interesting, bizarre, or unique outcomes. When situations are predictable or solved the same way every time, players stop engaging with the scenario and instead follow learned patterns. This is to say, every round should feel unique and different from the last. - Variation and randomness should play a big role in defining each round. From 64808c33a9148c01914e7098d5bbcbeae5369168 Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Sun, 5 Apr 2026 17:00:34 -0600 Subject: [PATCH 10/14] big update --- src/development/design-doc-event-actors.md | 62 +++++++++++++++++++ src/development/design-doc-rotating-ghosts.md | 32 ---------- 2 files changed, 62 insertions(+), 32 deletions(-) create mode 100644 src/development/design-doc-event-actors.md delete mode 100644 src/development/design-doc-rotating-ghosts.md diff --git a/src/development/design-doc-event-actors.md b/src/development/design-doc-event-actors.md new file mode 100644 index 0000000..61952cf --- /dev/null +++ b/src/development/design-doc-event-actors.md @@ -0,0 +1,62 @@ +Event Actors +=============== + +Event Actors are a role where players are assigned to pools to play multiple events over the course of a round, rather than just one. Additionally, players can vote from a limited list of events to spawn as, as well as the objectives and variations to choose from. + +For example, in a traditional random shuttle event, players choose a ghost role, fly to the station, and then effectively become part of the crew (if anyone picks them at all). + +In the new system, a group of event actors will be preassigned to the event, they choose what they want to spawn in as, arrive at the station with an objective in mind, and whenever they get bored they can leave the station, making themselves available for future events. + +This would replace the current system of antags, as well as ghost roles to an extent. + +## Roundflow +- A ratio of players will be set aside to fill the roles of the round events. + +- This pool of players will get to vote from a list of events that they can come in as. They will also get the chance to vote about various details of their event, such as what their objective will be. + +- The players will then play out their event, leaving their impact on the round + +- Through creative means, these players will end up, or be encouraged to remove themselves from the round. To which they will be given the opportunity to continue playing more events. + - If a player for whatever reason doesn't end up being rotating themselves back out, an opportunity will be given for ghosts or players on station to be added to the pool to compensate. + +## Advantages/Reasoning + +- Rounds no longer hinge upon on the success or failure of antags, there will be persistent threats so long as the round goes on. + +- Removes much of the pain from being caught as an antag or being round removed. + +- Round variation is improved, as there is no longer a preset gamemode but a series of random events. + +- Allows for an easier and wider design of midround events involving players. + +## Considerations +- Events designed around this will likely require: + - Some sort of objective involving the station, to prompt interaction. + - A limiting factor which prompts them to leave, such as a time limit. + - A means of leaving the station, such as a shuttle, or dying permanently. + +- There should be contingencies in the case of people not leaving an event, we do not want to run out of available event actors, or have antags cascade more than intended. + +### The Antag Question +Many of the existing antags may require reworks of varying degrees, if they are to use this system. +- Round-ending antags such as nukies may need to be tuned down, or have the scope of their objectives be limited. + +- Antags will need a way to "leave" the station, in order to be shuffled back into the pool. Similarly, security should have the means to do this to certain antags as well. + +- Antags will need to be designed to have a shorter preparation phase and act decisively, rather than engaging in protracted conflicts over a long period of time. + +### Keeping the Pool Full +There are a couple decent methods that can be employed to ensure players can return to the pool, or put new ones in when necessary. +- Round removal, simple as. + +- Flying away on a shuttle, they would likely hit a button once they're far from the station. + +- Timer locking, if they don't leave by the time the timer is up, they give up their slot to other people + +- Ghost volunteers, I don't want to open this to any ghost so we don't encourage spectating, but an easy way to refill slots that have been emptied. + +- Selecting people already part of the crew, so that on-station antags can be in the mix as well + +### Optimizing for Time +With a time limit in mind, its important that people are able to make the most of their time. +- Repurposing Arrivals: After everyone is off arrivals from the initial wave, we could disable arrivals altogether. Any passive (or maybe even hostile) events would have the option to FTL directly onto the arrivals airlocks to reach the station as quickly as possible. diff --git a/src/development/design-doc-rotating-ghosts.md b/src/development/design-doc-rotating-ghosts.md deleted file mode 100644 index 199035c..0000000 --- a/src/development/design-doc-rotating-ghosts.md +++ /dev/null @@ -1,32 +0,0 @@ -Event Player Recycing -=============== - -The concept of having ghosts which will persistently come in as events for the players. - -This specific pool of players will act in the role that NPCs would normally play in most video games, playing as characters from random events that befall the station. These can be ostensibly crew-aligned events such as wandering shuttles, or hostile events like pirates. - -These will replace the existing system for antags as well as the majority of ghost roles, as this system ensures theyre taken, and incentivizes their interaction with the round, and ensures the round has persistant threats even after antags are removed from play. - - -## Roundflow -A ratio of players will be set aside to fill the roles of the round events. Ideally these are broken up into groups of 3-4 people. - -- These people will then get to vote on a limited list of spawns they can come in as, as well as what their objective will be (both for friendly and antags). - - -- They will also be given a timer to indicate when they will spawn, ideally they will either be spectating, in a bar, or something to keep them entertained while they wait. - -- After they spawn in, they will be given a timer to complete their objective and leave the map, or extracate in some other form. - -- If all or some of them don't extracate in some form before their timer runs out, different actions will be taken depending on whether they are antag or crew-aligned - - If they are crew-aligned, it can be assumed they have joined the crew in some capacity, and their slots will be opened up. - - If they are antags, their slots should be opened up for people to steal, additionally a heavy disadvantage should be forced upon them, encouraging them to withdraw or risk losing their spot. - -## Advantages - -I view this as an improvement over the dynamic gamemode by itself, as this ensures the consistancy of events throughout the round, whereas dynamic relies heavily upon people taking ghost roles. Additionally this gives the opprotunity for roles that arent explicitly hostile to have a larger impact on the round, and make things more interesting. - -## Considerations - -- This relies upon antags taking decisive action to drive the round, so it will likely require altering existing antags to dissuade them from protracted conflict - - for example, traitors could be forced to select all their gear at the same time, in order to make them \ No newline at end of file From e0415faba29f2e2b99db1eb6ed9cfe6c982d3931 Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Sun, 5 Apr 2026 17:01:55 -0600 Subject: [PATCH 11/14] grammar --- src/development/design-doc-event-actors.md | 44 +++++++++++----------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/src/development/design-doc-event-actors.md b/src/development/design-doc-event-actors.md index 61952cf..e7f0705 100644 --- a/src/development/design-doc-event-actors.md +++ b/src/development/design-doc-event-actors.md @@ -3,60 +3,60 @@ Event Actors Event Actors are a role where players are assigned to pools to play multiple events over the course of a round, rather than just one. Additionally, players can vote from a limited list of events to spawn as, as well as the objectives and variations to choose from. -For example, in a traditional random shuttle event, players choose a ghost role, fly to the station, and then effectively become part of the crew (if anyone picks them at all). +For example, in a traditional random shuttle event, players choose a ghost role, fly to the station, and then effectively become part of the crew (if anyone picks them up at all). -In the new system, a group of event actors will be preassigned to the event, they choose what they want to spawn in as, arrive at the station with an objective in mind, and whenever they get bored they can leave the station, making themselves available for future events. +In the new system, a group of event actors will be pre-assigned to the event. They choose what they want to spawn in as, arrive at the station with an objective in mind, and whenever they get bored, they can leave the station, making themselves available for future events. This would replace the current system of antags, as well as ghost roles to an extent. ## Roundflow -- A ratio of players will be set aside to fill the roles of the round events. +- A ratio of players will be set aside to fill the roles of the round's events. -- This pool of players will get to vote from a list of events that they can come in as. They will also get the chance to vote about various details of their event, such as what their objective will be. +- This pool of players will get to vote from a list of events that they can come in as. They will also get the chance to vote on various details of their event, such as what their objective will be. -- The players will then play out their event, leaving their impact on the round +- The players will then play out their event, leaving their impact on the round. -- Through creative means, these players will end up, or be encouraged to remove themselves from the round. To which they will be given the opportunity to continue playing more events. - - If a player for whatever reason doesn't end up being rotating themselves back out, an opportunity will be given for ghosts or players on station to be added to the pool to compensate. +- Through creative means, these players will end up leaving, or be encouraged to remove themselves from the round, at which point they will be given the opportunity to continue playing more events. + - If a player for whatever reason doesn't end up rotating themselves back out, an opportunity will be given for ghosts or on-station players to be added to the pool to compensate. ## Advantages/Reasoning -- Rounds no longer hinge upon on the success or failure of antags, there will be persistent threats so long as the round goes on. +- Rounds no longer hinge on the success or failure of antags; there will be persistent threats so long as the round goes on. -- Removes much of the pain from being caught as an antag or being round removed. +- Removes much of the pain from being caught as an antag or being round-removed. - Round variation is improved, as there is no longer a preset gamemode but a series of random events. -- Allows for an easier and wider design of midround events involving players. +- Allows for easier and wider design of mid-round events involving players. ## Considerations - Events designed around this will likely require: - Some sort of objective involving the station, to prompt interaction. - - A limiting factor which prompts them to leave, such as a time limit. + - A limiting factor that prompts them to leave, such as a time limit. - A means of leaving the station, such as a shuttle, or dying permanently. -- There should be contingencies in the case of people not leaving an event, we do not want to run out of available event actors, or have antags cascade more than intended. +- There should be contingencies in case of people not leaving an event; we do not want to run out of available event actors, or have antags cascade more than intended. ### The Antag Question -Many of the existing antags may require reworks of varying degrees, if they are to use this system. -- Round-ending antags such as nukies may need to be tuned down, or have the scope of their objectives be limited. +Many of the existing antags may require reworks of varying degrees if they are to use this system. +- Round-ending antags such as nukies may need to be tuned down, or have the scope of their objectives limited. -- Antags will need a way to "leave" the station, in order to be shuffled back into the pool. Similarly, security should have the means to do this to certain antags as well. +- Antags will need a way to "leave" the station in order to be shuffled back into the pool. Similarly, security should have the means to do this to certain antags as well. - Antags will need to be designed to have a shorter preparation phase and act decisively, rather than engaging in protracted conflicts over a long period of time. ### Keeping the Pool Full -There are a couple decent methods that can be employed to ensure players can return to the pool, or put new ones in when necessary. +There are a couple of decent methods that can be employed to ensure players can return to the pool, or to put new ones in when necessary. - Round removal, simple as. -- Flying away on a shuttle, they would likely hit a button once they're far from the station. +- Flying away on a shuttle; they would likely hit a button once they're far from the station. -- Timer locking, if they don't leave by the time the timer is up, they give up their slot to other people +- Timer locking: if they don't leave by the time the timer is up, they give up their slot to other players. -- Ghost volunteers, I don't want to open this to any ghost so we don't encourage spectating, but an easy way to refill slots that have been emptied. +- Ghost volunteers: I don't want to open this to any ghost, so we don't encourage spectating, but it's an easy way to refill slots that have been emptied. -- Selecting people already part of the crew, so that on-station antags can be in the mix as well +- Selecting people already part of the crew, so that on-station antags can be in the mix as well. ### Optimizing for Time -With a time limit in mind, its important that people are able to make the most of their time. -- Repurposing Arrivals: After everyone is off arrivals from the initial wave, we could disable arrivals altogether. Any passive (or maybe even hostile) events would have the option to FTL directly onto the arrivals airlocks to reach the station as quickly as possible. +With a time limit in mind, it's important that people are able to make the most of their time. +- Repurposing Arrivals: After everyone is off arrivals from the initial wave, we could disable arrivals altogether. Any passive (or maybe even hostile) events would have the option to FTL directly onto the arrivals airlocks to reach the station as quickly as possible. \ No newline at end of file From df81fd6c0265bba7f660258dea6d892a3358c156 Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Sun, 5 Apr 2026 17:33:13 -0600 Subject: [PATCH 12/14] grammar --- src/development/design-doc-event-actors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/development/design-doc-event-actors.md b/src/development/design-doc-event-actors.md index e7f0705..df6356b 100644 --- a/src/development/design-doc-event-actors.md +++ b/src/development/design-doc-event-actors.md @@ -3,7 +3,7 @@ Event Actors Event Actors are a role where players are assigned to pools to play multiple events over the course of a round, rather than just one. Additionally, players can vote from a limited list of events to spawn as, as well as the objectives and variations to choose from. -For example, in a traditional random shuttle event, players choose a ghost role, fly to the station, and then effectively become part of the crew (if anyone picks them up at all). +For example, in a traditional random shuttle event, players choose a ghost role, fly to the station, and then effectively become part of the crew (if anyone picks them at all). In the new system, a group of event actors will be pre-assigned to the event. They choose what they want to spawn in as, arrive at the station with an objective in mind, and whenever they get bored, they can leave the station, making themselves available for future events. From 7912e547e61995c73f1d3cf56587ebadf8b2220d Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Sat, 11 Apr 2026 15:35:41 -0600 Subject: [PATCH 13/14] Update design-doc-event-actors.md --- src/development/design-doc-event-actors.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/development/design-doc-event-actors.md b/src/development/design-doc-event-actors.md index df6356b..69cd963 100644 --- a/src/development/design-doc-event-actors.md +++ b/src/development/design-doc-event-actors.md @@ -16,7 +16,7 @@ This would replace the current system of antags, as well as ghost roles to an ex - The players will then play out their event, leaving their impact on the round. -- Through creative means, these players will end up leaving, or be encouraged to remove themselves from the round, at which point they will be given the opportunity to continue playing more events. +- Through creative means, these players will end up leaving the station, at which point they will be given the opportunity to continue playing more events. - If a player for whatever reason doesn't end up rotating themselves back out, an opportunity will be given for ghosts or on-station players to be added to the pool to compensate. ## Advantages/Reasoning @@ -59,4 +59,4 @@ There are a couple of decent methods that can be employed to ensure players can ### Optimizing for Time With a time limit in mind, it's important that people are able to make the most of their time. -- Repurposing Arrivals: After everyone is off arrivals from the initial wave, we could disable arrivals altogether. Any passive (or maybe even hostile) events would have the option to FTL directly onto the arrivals airlocks to reach the station as quickly as possible. \ No newline at end of file +- Repurposing Arrivals: After everyone is off arrivals from the initial wave, we could disable arrivals altogether. Any passive (or maybe even hostile) events would have the option to FTL directly onto the arrivals airlocks to reach the station as quickly as possible. From 10b4fe2e60165c6b32febf623cc7499f3364b5c2 Mon Sep 17 00:00:00 2001 From: DuckManZach <144298822+DuckManZach@users.noreply.github.com> Date: Sat, 11 Apr 2026 23:28:49 -0600 Subject: [PATCH 14/14] rewording... maybe its better maybe its not --- src/development/design-doc-event-actors.md | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/src/development/design-doc-event-actors.md b/src/development/design-doc-event-actors.md index df6356b..72ea9f3 100644 --- a/src/development/design-doc-event-actors.md +++ b/src/development/design-doc-event-actors.md @@ -1,23 +1,14 @@ Event Actors =============== -Event Actors are a role where players are assigned to pools to play multiple events over the course of a round, rather than just one. Additionally, players can vote from a limited list of events to spawn as, as well as the objectives and variations to choose from. - -For example, in a traditional random shuttle event, players choose a ghost role, fly to the station, and then effectively become part of the crew (if anyone picks them at all). - -In the new system, a group of event actors will be pre-assigned to the event. They choose what they want to spawn in as, arrive at the station with an objective in mind, and whenever they get bored, they can leave the station, making themselves available for future events. - -This would replace the current system of antags, as well as ghost roles to an extent. +Event Actors as a system are intended to overhaul mid-round events, by allowing a pool of players play multiple events over the course of the round. Traditional mid-round events suffer from inconsistency; players often don’t take the roles, and even when they do, events with multiple roles are rarely fully staffed. Event Actors address and expand on this by ensuring mid-round events are filled consistently, allowing them to become an important driving force of a round. ## Roundflow -- A ratio of players will be set aside to fill the roles of the round's events. - -- This pool of players will get to vote from a list of events that they can come in as. They will also get the chance to vote on various details of their event, such as what their objective will be. -- The players will then play out their event, leaving their impact on the round. +Event Actors work by assigning a certain ratio of players as Event Actors. These players can vote on which event they want to spawn as, what their objectives will be, and miscellaneous variations surrounding their role. Once everything is voted on, they are entered into the round by the event scheduler. They then play out their role in the round before exiting, returning them to the pool for future events. -- Through creative means, these players will end up leaving, or be encouraged to remove themselves from the round, at which point they will be given the opportunity to continue playing more events. - - If a player for whatever reason doesn't end up rotating themselves back out, an opportunity will be given for ghosts or on-station players to be added to the pool to compensate. +Events based on the event actor system differ from normal events mainly in that they're designed to interact with the station for a limited period of time, this is so that once an event has reached its natural conclusion, the people involved can leave the station and move onto new events which keep the experience fresh for both them and the crew. +- There should be contingencies for when the actors do not rejoin the pool, their spots can be given to either ghost roles or even other players still on the station. ## Advantages/Reasoning