diff --git a/src/en/space-station-14/combat.md b/src/en/space-station-14/combat.md index a309dec51f..6d4319960b 100644 --- a/src/en/space-station-14/combat.md +++ b/src/en/space-station-14/combat.md @@ -29,7 +29,7 @@ Combat should be possible at a range from low to high lethality, with the latter - Combat helps provide action to the game. Following [Bartle's Taxonomy of player types](https://en.wikipedia.org/wiki/Bartle_taxonomy_of_player_types), there isn't much in this game that otherwise caters to players in the *Killers* category. In other words, there are plenty of things which cater to the *Achievers*, *Socializers*, and *Explorers*, but the *Killers* out there would be missing a core part of what they look for in a gaming experience if not for combat. - The nature of combat having direct and indirect consequences for players means it provides a more intense experience overall. The bursts of combat is key point of immediate higher-risk action, even for roles that are not combat-focused. - For players who don't wish to engage in combat, the game has to provide options to offload engagements to those that do. This can be done through playing roles that don't emphasize combat or conflict, designing in areas where combat is less likely to occur/indicating where combat is more likely, and enabling avoiding combat as a valid strategy. It may not always be possible to completely disconnect combat from a player's experience due to being both core to the game and forceful by nature, but players must feel they have some control over the amount of combat they engage in. - - Without any combat in the game it acts more like a chatroom or requires the game to lean more heavily into its simulation aspects to make up for the lack of driving forces. While this may be enjoyed by some players, [the game is meant to feature elements of chaos](./core-design/design-principles.md#chaos) which combat handily provides. + - Without any combat in the game it acts more like a chatroom or requires the game to lean more heavily into its simulation aspects to make up for the lack of driving forces. While this may be enjoyed by some players, [the game is meant to feature elements of chaos](./core-design/gampleay-pillars) which combat handily provides. - Resource consumption - Combat (and moreso the consequences thereof) is a significant resource consumer, providing meaning to resource generators' gameplay. This includes the resources used to facilitate combat, but also fixing the consequences (e.g. Engineering repairs and Medical treatment). diff --git a/src/en/space-station-14/core-design.md b/src/en/space-station-14/core-design.md deleted file mode 100644 index fb944168cb..0000000000 --- a/src/en/space-station-14/core-design.md +++ /dev/null @@ -1,57 +0,0 @@ -# Core Game Design -These documents contain the Space Station 14's Core Game Design Princples and should be used to inform the design of any new designs or large balance changes. - -Questions around Core Game Design should be directed towards the #design-discussion channel on the Official Space Station 14 Discord (preferred) or, if you do not use Discord, by making a thread on the Space Station 14 Forums. - -## Caveats -- These documents are living documents and will change over time as the design of Space Station 14 evolves. -- Forks and other communities may have different ideas and directions that they want to take the game, which is fine and something we want to encourage! - -# Wizard's Den -Wizards Den intends to create a polished vanilla experience of Space Station 14. Primarily focusing on code quality and strong, well-designed systems over pure quantity. - -## Core Pillars - -### Vanilla -Wizard's Den aims to bring a vanilla Space Station 14 experience. This means a strict adherence to features and content that fit the design of Space Station 14. This is different from Wizden being a blank slate, and does not prevent the addition of content or balancing personalized for Wizden servers. - -### Stability -Wizard's Den is the upstream for the majority of forks. As such, code and content should be stable and maintained. Automated tests should ensure systems remain functional, and outright broken, unplanned, or unmaintained content should be removed. - -### Mechanics Over Rules -Wizard's Den prioritizes mechanical design over rules design whenever and wherever possible. Admins shouldn't be required for the game to work, and as much as possible, mechanics should prevent their involvement. - -# Space Station 14 -Space Station 14 is a game where disasters, enemies, and incompetence conspire to make each shift aboard the station a unique and hellish experience. - -## Core Pillars -These pillars serve as the guiding concepts for designing SS14's features. When creating features or adjusting balance, you should be actively thinking about how these concepts relate to your design or change. - -- These pillars and definitions are specific to Wizard's Den's vision of Space Station 14. - -### Unpredictability and Chaos -- No two rounds should play alike. The combination of antagonists, incompetence, and disasters should create situations where players have to deal with rapidly changing and escalating situations. -- There should rarely be guarantees. Problems should arise, and solutions may not always be immediately available. Players should be forced to adapt to rapid changes in their environment. -- Chaos should also be unpredictable. Some rounds may be slow, some may be blazingly fast; the variety of round flow is what keeps the game interesting. - -### Darkly Comedic/Surrealist -- The game's tone floats between a Surrealist Comedy and Dark Comedy, both defying expectations with absurd situations, such as the clown throwing acid pies at a mega-corporation's special forces team. -- The game should be able to balance this tone, never becoming so absurd that it breaks immersion, but never being so serious or grim that it becomes depressing. -- Mechanics should be designed with this tone in mind, silly mechanics shouldn't be so silly as to not be grounded, and grounded mechanics shouldn't be mundane, and all should play a part in a catastrophe. - -### Dynamic Environment -- The gameworld should be malleable, allowing for the dynamics of a station to change throughout the round. Walls may get blown open by explosions, and areas of the station may be totally renovated by a dedicated passenger. -- The station should avoid unique properties that cannot be replicated. Even abstract intangible player facing systems should still be tied to tangible objects whenever possible. - -### Intuitive and Inter-Connected Simulation -- Simulated systems should be complex enough to create engaging gameplay decisions while still being intuitive enough to learn without wiki-diving. -- Simulated systems should be interactive and reactive, not only with players but with each other. -- Systems should interact with each other as much as feasible to create new emergent gameplay opportunities. -- Systems should clearly communicate all necessary information a player needs to make actionable judgments. No player should require knowledge outside the game to interact with a mechanic; black boxes are bad. -- Players should be able to find optimal strategies and discover emergent interactions solely with what information is available to them in-game. - -### Player Interaction/Agency -- Mechanics and design should encourage players to interact with other players naturally. Players should feel like they have agency in these interactions. -- Interactions should not be an afterthought when designing mechanics. Player interactions should be part of the design rather than an extra step added arbitrarily. -- Players should never feel forced into a specific interaction or action. Avoid situations where players default to a specific choice because it is consistently better than other options. -- A player genuinely interacting with a mechanic should not end up completely isolated from the rest of the game. No mechanics should run parallel or tangential to the rest of the game. \ No newline at end of file diff --git a/src/en/space-station-14/core-design/design-principles.md b/src/en/space-station-14/core-design/design-principles.md deleted file mode 100644 index 426673dba6..0000000000 --- a/src/en/space-station-14/core-design/design-principles.md +++ /dev/null @@ -1,69 +0,0 @@ -```admonish warning "Attention: Outdated!" -This doc has been deprecated by a general "Core Design" doc. This doc exists for archival purposes only! -``` - -# Design Principles -Here we go into more detail about each of SS14's Core Design Pillars by breaking them down further into design principles. Once again, these are not hard requirements, but expect to receive heavy scrutiny on your design if you aren't following these. - -## Chaos - -The inherent complexity of SS14's sandbox combined with the unpredictability of human players creates a truly chaotic environment where anything can happen. This should be embraced when designing mechanics to fit SS14, especially with regards to giving players opportunities to cause mischief. - -One key mantra to use when making new mechanics is "nothing is perfect". Conceptually, this means that **your mechanic should not allow for "perfect" solutions**. Make sure to sprinkle plenty of opportunities for players to intentionally or unintentionally screw up while interacting with your mechanic. - -It's also important to differentiate between potential chaos and guaranteed chaos. Mechanics should generally introduce potential chaos in the form of the choices players make while interacting with them. Mechanics that guarantee that a chaotic situation will always occur should be avoided since they would negatively impact player agency. - -New mechanics should also be integrated with existing mechanics when possible to further increase variety in the potential outcomes players have when interacting with them. - -## Seriously Silly - -SS14, at its heart, is a horror comedy: on one hand you have a soulless megacorp that cares nothing for its employees while exposing them to the horrific dangers of unknown space, while on the other you have clowns and incompetent assistants causing all sorts of hilarious disasters. - -The situations that regularly happen in SS14 are absolutely unhinged, yet players generally take them seriously. When you are creating content or mechanics, you should lean into this dissonance and embrace the fact that something can be silly and serious at the same time. - -When creating a new mechanic, you should try to introduce ways that things can go horribly, horribly, and hilariously wrong (or right, depending on who you ask). Try to create situations that would be hilarious to hear told as a story but would be terrifying to be in as a player. - -## Dynamic Environment - -The environment of an SS14 round is as much a character as the players, and can dramatically change over the course of a round. Players have the complete freedom to shape the gameworld the way they wish, whether by building, destroying, or changing things on the station. - -SS14 is a game where it should be possible for players to decide to "make their own station with blackjack and hookers", and go do just that, or continue playing a round and rebuild the station after it was sliced in half (Both of these have occurred multiple times in the history of SS13 and SS14.) - -Because of this, **Mechanics *cannot* be location specific or require items that cannot be obtained after roundstart**. The decision to call the shuttle should never be made due to losing an uncraftable item or being unable to rebuild something required for a game mechanic. - -## Intuitive and Inter-Connected Simulation - -If SS14's heart is a horror comedy, then SS14's soul is a simulation. SS13/14 has come a long way from the simple atmospherics simulator that Exadv1 wrote all those ages ago, yet at its Core, SS14 features in-depth atmospheric and power simulation. - -Part of the unique experience of SS14 is interacting with its in-depth simulation gameplay while dealing with the chaos that comes from antagonists and random events. SS14's indepth simulation and numerous inter-system interactions work for the average player because "They just make sense." - -Realism is not important and may end up causing gameplay/readability issues for players. **It's far more important that a Mechanic/Simulation is Intuitive than Realistic.** If a system completely realistically models a subject but requires someone with a PhD to understand how it works, that is a major problem. - -Any simulation-based mechanic or interaction should be easy to learn from in-game information alone and not require wiki- or textbook-diving to understand. - -When designing simulation-based mechanics, try to think of the different ways that existing systems/mechanics will interact with them. Inter-connected systems also help create more opportunities for players to create unique situations stemming from how those systems interact. - -## Player Interaction - -Mechanics should seek to be pro-social and encourage interacting with other players. These interactions need not be strictly cooperative or competitive in nature. Humans are chaotic by nature, and provide depth and replayability to games that cannot fully be achieved through programmed mechanics alone. Thus, we should utilize that power to drive gameplay. - -Mechanics which incentivize players to do them entirely alone, or mechanics that are not affected by events that occur in a round and/or the actions taken by other players, **will very likely not be added to SS14**. - -These mechanics detract from the overall game by segmenting players into their own separate regions of play. Mechanics which are "simpler" but reward social gameplay will always be preferred to mechanics which are "deep" but are single-player. - -Parts of a whole gameplay loop or mechanic may be achievable by a single player. It's obviously not feasible to have everything forcibly involve multiple people, but care should be taken to try and incentivize social gameplay above singleplayer gameplay, even if something *can* be completed solo. - -An addendum to this principle is that, if a mechanic involves perceived NPCs or AI mobs, you should always try to find ways to put real humans in their place. For example, offering ghost roles to hostile mobs, or crafting an economy system that is player-motivated rather than externally-motivated. - -## Player Agency - -Players should always feel like they have the ability to choose what they should do in response to a situation or interaction. In some cases the effects of this choice may be minimal, but the important thing is that the player still feels like they have agency over the situation. - -When you design a mechanic, you should be very conscious of the choices and information you are giving players. If your choices are too simple or you give too much information to players, your choices become a "false choice" where there is only one "correct" answer. - -Another word for this is Metagame (Meta for short), or where a particular choice, item, ability, etc. becomes the best possible option and all others are ignored in favor of getting the best advantage. **Avoid designing mechanics in a way where a "Meta" may be developed.** - -Care should also be taken to make sure that player interactions do not overly limit other players' agency, especially when conflict is involved. If your mechanic involves conflict, both players should always be given some counterplay options, ideally in a way that can be learned as a skill. - -This also goes for non-combat interactions as well; avoid creating situations where players are "Railroaded" into a specific action either mechanically or by the metagame. **A player should never feel like they have no options in their situation**. - diff --git a/src/en/space-station-14/core-design/gampleay-pillars.md b/src/en/space-station-14/core-design/gampleay-pillars.md new file mode 100644 index 0000000000..aaada16ca6 --- /dev/null +++ b/src/en/space-station-14/core-design/gampleay-pillars.md @@ -0,0 +1,60 @@ +# Gameplay Pillars + +Gameplay pillars represent the “core identity” of Space Station 14 and the vision for the experience of playing on Wizden/”Vanilla” servers. These pillars are the foundation for making features or mechanics, when creating a feature/mechanic, you are expected to be able to justify and/or defend the design with these pillars. + +* *Designs that conflict with the core pillars will face much harsher scrutiny as they are unlikely to fit within the vision of the experience we are going for on Wizden servers.* + +Caveat for the above: If a design doesn’t fit within Wizden but may be implemented in a modular way, we can still add/support the functionality for Community Servers without directly using it on Wizden Servers. + +# Core Pillars: + +## Chaotic and Memorable *Storytelling* + +* Chaos should serve a greater narrative: ***Chaos without stakes or reason is just noise.*** +* The priority is to enable players to experience engaging and memorable stories while playing, rather than creating a tightly-tuned competitive experience. + + +* *Players should never feel forced into a specific interaction or action*. Avoid situations where players default to a specific choice because it is consistently better than other options. + + +--- + +## Be ~~whoever~~ ***whatever*** you want to be: + +* Encourage and enable player self-expression when it comes to characters and jobs. +* Space station at it's core is a lot like a Tabletop-RPG, lean into that to create immersive mechanics that reward players for getting into character. + + +--- + +## Teamwork is *fun*: + +* Group gameplay and progression should be incentive over solo activities/rewards as much as possible. More cross-department/group interactions create more opportunities for roleplay, shenanigans, and memorable movements. + + +* Antags, Objectives and Events should push players to work *together* to overcome the challenge as a group rather than put the fate of the station in the hands of a few individuals. +* Inter-dependence should be a mutually beneficial two-way street without feeling like an annoying limitation. + + +--- + +## An unpredictable world of Interconnected systems + +* Gameplay should be the result of emergent interactions between various gameplay systems rather than resulting from scripted outcomes. +* Players should be given the freedom to approach problems from any angle and use element's of the game's simulation as puzzle pieces to create their solution. + + +--- + +## A richly detailed, immersive experience in the frontiers of space + +* The world should feel deep, interesting and most importantly: internally consistent. Understanding lore should not be a requirement, but players who take the time to do so should be rewarded with engaging storytelling. + + +--- + +## Surreal Dark Comedy + +* An indifferent, but not cruel universe. There is light present in the universe, players just happen to be on the fringes of civilization where government oversight and laws have become more *“open to interpretation”.* +* The overall tone should be humorous and lighthearted, yet still convey a level of stakes and severity. Patently absurd and hilarious situations should still be taken seriously by the world and players. +* What I like to call the "Sseth effect", basically the game should create situations that are patently absurd when explaining to friends. \ No newline at end of file diff --git a/src/en/space-station-14/round-flow/antagonists/Wizard.md b/src/en/space-station-14/round-flow/antagonists/Wizard.md index 9089e56536..ad3976175c 100644 --- a/src/en/space-station-14/round-flow/antagonists/Wizard.md +++ b/src/en/space-station-14/round-flow/antagonists/Wizard.md @@ -208,7 +208,7 @@ It's important that the Wizard is not encouraged to just stay in their Den for t