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-event-actors.md b/src/development/design-doc-event-actors.md new file mode 100644 index 0000000..7e285c9 --- /dev/null +++ b/src/development/design-doc-event-actors.md @@ -0,0 +1,53 @@ +Event Actors +=============== + +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 + +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. + +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 + +- 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. + +- Round variation is improved, as there is no longer a preset gamemode but a series of random events. + +- 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 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 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 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 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. + +- 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 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. + +### 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. diff --git a/src/development/design-doc-main.md b/src/development/design-doc-main.md new file mode 100644 index 0000000..cff98cb --- /dev/null +++ b/src/development/design-doc-main.md @@ -0,0 +1,16 @@ +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 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 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 new file mode 100644 index 0000000..4f70387 --- /dev/null +++ b/src/development/design-pillars.md @@ -0,0 +1,42 @@ +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 + +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 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 + +The game is not about winning or losing; it's about creating an interesting story. + +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. +- Avoid designing systems which have consistent outcomes or solutions. +- Players should have to use discernment when engaging with what's happening to the station. + + +``` admonish warning +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: +- [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