From 29a8678cb53995cfa926f8a12c652482d674e250 Mon Sep 17 00:00:00 2001 From: mirrorcult Date: Fri, 1 May 2026 09:00:44 -0700 Subject: [PATCH 1/2] cleanup masks --- src/SUMMARY.md | 13 +- src/design/characters/clues.md | 3 - src/design/masks.md | 9 +- src/design/masks/crew/cannibal.md | 2 + src/design/mirrors-notes.md | 183 ------------------ src/design/{masks/crew => removed}/angel.md | 6 +- src/design/{masks/crew => removed}/bomber.md | 8 +- src/design/{masks/crew => removed}/coveter.md | 4 +- .../{masks/crew => removed}/enthraller.md | 4 +- .../{masks/crew => removed}/mind-reader.md | 12 +- src/design/{masks/crew => removed}/tracker.md | 10 +- 11 files changed, 33 insertions(+), 221 deletions(-) delete mode 100644 src/design/mirrors-notes.md rename src/design/{masks/crew => removed}/angel.md (91%) rename src/design/{masks/crew => removed}/bomber.md (81%) rename src/design/{masks/crew => removed}/coveter.md (91%) rename src/design/{masks/crew => removed}/enthraller.md (90%) rename src/design/{masks/crew => removed}/mind-reader.md (68%) rename src/design/{masks/crew => removed}/tracker.md (77%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index acdd5db..49d81aa 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -21,7 +21,6 @@ # Design --- - [Design Principles](design/pillars.md) -- [Mirror's Notes on Design](design/mirrors-notes.md) - [Rules-Light Design](design/rules-light-design.md) - [Terminology](design/terminology.md) --- @@ -88,29 +87,23 @@ - [Leapleech](design/masks/parasite/leapleech.md) - [Psychid](design/masks/parasite/psychid.md) - [Crew](design/masks/crew.md) - - [Angel](design/masks/crew/angel.md) - [Angry Man](design/masks/crew/angry-man.md) - [Arms Dealer](design/masks/crew/arms-dealer.md) - [Arsonist](design/masks/crew/arsonist.md) - [Avenger](design/masks/crew/avenger.md) - - [Bomber](design/masks/crew/bomber.md) - [Cannibal](design/masks/crew/cannibal.md) - - [Coveter](design/masks/crew/coveter.md) - [Crewmember](design/masks/crew/crewmember.md) - [Drug Dealer](design/masks/crew/drug-dealer.md) - [Eavesdropper](design/masks/crew/eavesdropper.md) - - [Enthraller](design/masks/crew/enthraller.md) - [Guzzler](design/masks/crew/guzzler.md) - [Hater](design/masks/crew/hater.md) - [Matchmaker](design/masks/crew/matchmaker.md) - [Mercenary](design/masks/crew/mercenary.md) - - [Mind Reader](design/masks/crew/mind-reader.md) - [Phantom](design/masks/crew/phantom.md) - [Pickpocket](design/masks/crew/pickpocket.md) - [Protégé](design/masks/crew/protege.md) - [Rebel](design/masks/crew/rebel.md) - [Secretary](design/masks/crew/secretary.md) - - [Tracker](design/masks/crew/tracker.md) - [Tragedian](design/masks/crew/tragedian.md) - [Vigilante](design/masks/crew/vigilante.md) - [VIP](design/masks/crew/vip.md) @@ -124,10 +117,14 @@ - [Machine Degradation](design/machine-degradation.md) --- - [Removed Documents](design/removed.md) + - [Angel](design/removed/angel.md) - [Animal Hater](design/removed/animal-hater.md) + - [Bomber](design/removed/bomber.md) - [Connoisseur](design/removed/connoisseur.md) + - [Coveter](design/removed/coveter.md) - [Daredevil](design/removed/daredevil.md) - [Empath](design/removed/empath.md) + - [Enthraller](design/removed/enthraller.md) - [Fool](design/removed/fool.md) - [Freakshow](design/removed/freakshow.md) - [Fruit Vendor](design/removed/fruit-vendor.md) @@ -141,6 +138,7 @@ - [Mask Tokens](design/removed/mask-tokens.md) - [Mask Variants](design/removed/mask-variants.md) - [Mercenary (Old)](design/removed/mercenary-old.md) + - [Mind Reader](design/removed/mind-reader.md) - [Parasite](design/removed/parasite.md) - [Philanthropist](design/removed/philanthropist.md) - [Polymath](design/removed/polymath.md) @@ -148,5 +146,6 @@ - [Scapegoat](design/removed/scapegoat.md) - [Spy](design/removed/spy.md) - [Survivalist](design/removed/survivalist.md) + - [Tracker](design/removed/tracker.md) - [Vandal](design/removed/vandal.md) - [Wildcards](design/removed/wildcards.md) diff --git a/src/design/characters/clues.md b/src/design/characters/clues.md index f501808..f7e7920 100644 --- a/src/design/characters/clues.md +++ b/src/design/characters/clues.md @@ -17,9 +17,6 @@ Players can view their own clues through the **character menu** and can see visi Note that the ability to see clues is influenced by identity, so if someone is concealing their eyes, their eye color cannot be identified. However, you could easily deduce many aspects about someone whose face is uncovered. -Masks like the (now-removed) Insider leverage clues for their core gameplay, making use of them to lead them onto potentially round-altering information. -Others such as the [Mind Reader](../masks/crew/mind-reader.md) are capable of extracting clues from players, furthering the deductive gameplay of the round. - An issue with typical evidence like DNA or fingerprints is that they are binary indicators; the presence of them leads you directly to the perpetrator. This is problematic for deduction, as it essentially speed-runs the investigation, leading you directly to the culprit with little effort required. As such, these mechanics are often balanced around being extremely easy to avoid, which creates low-information scenarios where deduction is impossible. diff --git a/src/design/masks.md b/src/design/masks.md index 1a0046f..4f11686 100644 --- a/src/design/masks.md +++ b/src/design/masks.md @@ -66,15 +66,14 @@ When designing new masks, try to come up with novel combinations or inversions o Some general archetypes of masks (again, not exhaustive and new archetypes can and should be created): - **Jester**: Masks that have some effect on being killed by another player or dying. Examples: [phantom](masks/crew/phantom.md), [hemophage](masks/parasite/hemophage.md). -- **Swapper**: Masks that swap masks with another target on some condition. Examples: [coveter](masks/crew/coveter.md). -- **Guesser**: Masks which have some effect when successfully guessing another player's mask--useful for enforcing hidden role gameplay. Examples: [coveter](masks/crew/coveter.md), [angel](masks/crew/angel.md) -- **Converter**: Masks which convert another player to a certain mask or give them additional objectives on some condition. Should be very uncommon, *especially* duplicating masks. Examples: [subverter](masks/traitor/subverter.md), [enthraller](masks/crew/enthraller.md). +- **Swapper**: Masks that swap masks with another target on some condition. Examples: none atm. +- **Converter**: Masks which convert another player to a certain mask or give them additional objectives on some condition. Should be very uncommon, *especially* duplicating masks. Examples: [subverter](masks/traitor/subverter.md), [parasites in general](masks/parasites.md). - **Copier**: Masks which copy other masks on some condition. Examples: [cannibal](masks/crew/cannibal.md). - **Giver**: Masks which center around creating and disseminating items to others for some purpose. Examples: [arms dealer](masks/crew/arms-dealer.md), [drug dealer](masks/crew/drug-dealer.md). - **Sabotager**: Masks whose objectives revolve around engaging in some kind of malicious activity that generally harms others and leads to direct conflict and has deniability with troupe masks. Examples: [rebel](masks/crew/rebel.md). - **Murderer**: Masks which center around directly engaging in conflict with and killing other players. Examples: [assassin](masks/traitor/assassin.md), [mercenary](masks/crew/mercenary.md). -- **Guardian**: Masks which center around preventing other players from being harmed or killed. Examples: [avenger](masks/crew/avenger.md), [tracker](masks/crew/tracker.md). -- **Freak**: Masks whose objectives interact with the simulation in a way that is strange and leads into weird interactions, but not necessarily direct conflict with others. Examples: [guzzler](masks/crew/guzzler.md). +- **Guardian**: Masks which center around preventing other players from being harmed or killed. Examples: [avenger](masks/crew/avenger.md), [secretary](masks/crew/secretary.md). +- **Freak**: Masks whose objectives interact with the simulation in a way that is strange and leads into weird interactions, but not necessarily direct conflict with others. Examples: [guzzler](masks/crew/guzzler.md), [arsonist](masks/crew/arsonist.md). - **Oracle:** Masks which can gain hidden meta-knowledge about another mask. - **Dud:** Masks who lack unique mechanics or goals or are instead defined by troupe affiliation or the absence of another mask. Examples: [recruit](masks/traitor/recruit.md), [goon](masks/mafia/goon.md). diff --git a/src/design/masks/crew/cannibal.md b/src/design/masks/crew/cannibal.md index d4422b0..5583c85 100644 --- a/src/design/masks/crew/cannibal.md +++ b/src/design/masks/crew/cannibal.md @@ -2,6 +2,8 @@ {{#template ../../../templates/unimplemented.md }} +{{#template ../../../templates/slated-for-rework.md reason="still interesting as a targeted-copier but the specifics should probably be rethought a bit and maybe made deniable with ling husking etc, theres something more to be done here" }} + > **Name:** Cannibal > > **Troupe:** [Crew](../crew.md) diff --git a/src/design/mirrors-notes.md b/src/design/mirrors-notes.md deleted file mode 100644 index b3c1c79..0000000 --- a/src/design/mirrors-notes.md +++ /dev/null @@ -1,183 +0,0 @@ -# Mirror's Notes on Design - -```admonish warning -This is mostly stream-of-consciousness design musings from one person and is also not finished at all. It's still pretty good though. my oponion. my pinions only -``` - -It is my strong opinion that in over 20 years, Space Station 13/14 has failed to live up to its true potential in a lot of ways. Though there are promising gameplay elements and features created for larger codebases, as well as exciting forks and gimmick servers, I think many players, contributors, and onlookers can agree that despite the overwhelming amount of content implemented, most servers are fundamentally lacking in their design in very large ways, which tends to reveal itself after spending any significant amount of time with the game. I hope to solve this issue and thus create the first Real Video Game. - -This document is partially adapted from a document I (mirrorcult) wrote years ago outlining some of the more egregious design pitfalls I've seen, but in its current form is mostly separate streams-of-consciousness of design wisdom, constructive and deconstructive, that I hope to impart onto people. The concepts here are ones I use regularly when thinking about design, and which I will probably assume some shared primal-abstract understanding of when I'm talking shop with people that have watched me yap incessantly for years. - -In this document, when referring to SS13/SS14 as a combined unit, I'll be using the term "SS1X". - -On with the show. - -## Nerdbait - -![](../assets/design/mirrors-notes-nerdbait.png) - ---- - -I use the term "Nerdbait" here to refer to features which rely on obscuring their lack of gameplay value using elicited reactions of "it's so cool and complex!" in order to proliferate, which are often a result of them being lifted entirely or in part from other media. - -It's fun! It's got funny gadgets! It's Complex :tm:! We've even got some trite `pick(WH40K, Factorio, Dwarf Fortress, Fallout)` references or some shit in here! Don't you just want to play around with it for half a round before being immediately burnt out? What does it bring to the game positively, you ask? I'm not sure, but it makes me rock hard just thinking about how *cool* it is. - -It's a fantastic tactic! Genuinely! Loser nerds make up the primary audience of SS1X (that's me), and people love to talk about how *deep* and *complex* and *interesting* the game is. Anything that appeals to that primal desire is bound to get support, even if it's fundamentally worthless as a mechanic. I've been tricked one too many times by the siren's song of "complexity" and this angers me greatly. - -The fundamental issue with Nerdbait is mostly that those performing it have failed to understand what makes the game interesting to begin with. Nerdbait is born from mimicry, more than anything: a desire to emulate cool things people have seen done elsewhere without very much interrogation into *why it actually works that way to begin with*. - -Now, let's step back a bit. **None of this actually, necessarily, means *for sure* the feature or concept is bad**. There's nothing wrong with prospective features being cool or with taking inspiration from things you enjoy! In fact, I'd dare to say that *the game being cool is pretty cool.* What I'm warning against here is the danger of being easily persuaded towards design that doesn't actually rationally justify itself. A feature's main draw being that it's *cool* just means you should be way more skeptical when dealing with it than you would otherwise. - -You might protest--"of course I thought it through rationally, I'm a Good Designer :tm: !". Here the problem gets a little more meta. People are generally pretty bad at introspecting about their actual rationalizations for choices like this. If questioned on "what does this bring to the table?" for design in SS1X, people will usually post-hoc invent some rationale about how it fosters interdepartmental cooperation and gives players more choices or whatever and this was the plan all along, but fundamentally, the actual thought process is "..well, it's cool, and cool things are fun, and I like to play with cool features," and then.. "so there must be a rational reason I can find that it's good." - -This presents a big issue: nerdbait design ends up being solutions that are desperately looking for problems to justify their addition to the game. Rather than building design rationally out of what issues need to be solved with the game, or what adds new dimensions of gameplay, nerdbait constructs "solutions" in advance and attempts to retrofit them onto the game. "What does this bring to the game?" is a great question for design, but (I would argue) a more important question is "why this solution specifically?" Out of all of design-space, what decisions led you to choose this path? This ends up being far more illuminating with regards to the actual rationale behind things, I think. - -That said, again, it's a little hard to blame people for starting with 'cool idea' and building out from there! That's kind of how most design works, especially in a game with a design-space this wide. Problems are often so abstract that it's not very helpful to start from a place of "what can I add to solve this?" So, you'll need some mix of both. When ideas pop in to your head out of the magical aether from which all ideas form, always keep in the back of your mind the question "what am I actually *doing* with this?" from the very start. This way, you can *let it influence your design process as you go*, rather than having to think about all that during the review process after your feature is already done, or worse--never thinking about it at all. - -## Videoshames - -![](../assets/design/mirrors-notes-rules.png) - ---- - -This is a *video game*. - -Now, I don't mean this in a "let em have fun, its just a game" sense, though I do also wish people would chill the fuck out sometimes. I mean this in a contrastive sense--this is a *video game* we're designing, not some other medium, like table-top games or a physical sport. When you're designing video games, you have the unique advantage of defining rules and laws through code. That seems obvious to say, but people very frequently miss this fact. - -Space Station 13, owing to its history as a BYOND game (an engine initially designed to make graphical MUDs), sits at a somewhat strange confluence between more videogame-y CRPGs and more freeform MUDs or TTRPGs. In a looser environment, without strict code to guide player behavior, moderators (or "game masters") are generally required to ensure that players follow certain baseline expectations, and the first line of enforcement before moderation steps in are arbitrary social expectations beat into people through shame. This isn't a super big issue with low playercounts, especially when the roleplaying group has high internal cohesion, like a TTRPG party. Administration in SS1X is a tradition firmly inherited from this branch, mostly to its detriment. You can emulate the good parts of non-computer games *while* using the medium to your advantage--games like NBA 2K don't require a real person to referee your matches. - -I'm not making the claim that administrators are a useless concept in SS1X as it exists or that it would be best to do away with out-of-character rules entirely: it's still quite valuable to excise extremely low effort players and keep a healthy and inclusive community. With how the game is currently designed, lack of administration on major servers would very quickly devolve into hell. The problem doesn't lie with the fact that 'administrators are mean and 1984'--the problem is that *concepts that should be mechanically enforced through design are enforced by more ambiguous social guidelines*. This has a number of strains on all parties involved. - -### The strained pains - -Moderation teams are now essentially required to be fielded, increasing labor required to run a server. Furthermore, the labor being done can often require a lot of investment to do right--working social situations, getting conflicting info from multiple people at once, log diving, etc. Burnout rates are high, even if in the end they do get to run funny events sometimes (one of the benefits to having game masters in a roleplaying environment). - -As for everyone else, the simple fact that language and social guidelines more generally are ambiguous (rules about concepts like 'powergaming' come to mind) leads to a lot of active effort on players part to understand properly what is expected of them, and then even more effort to try and diligently stick to what is accepted. A lot of players will forego engaging in 'ambiguous' situations like with escalation rules to avoid having to deal with moderation at all, which makes the game much less interesting--people pull their punches. - -### Moving forward - -So, okay: solutions. What do we do about this? A lot of people would say "we need the rules, people would just RDM/powergame/grief and it'd be anarchy", and, okay, as I've said, this is true of the current state of most servers to a certain degree. But, come on, it's not a *desirable* state of affairs: we have the power in most cases to mechanically enforce things. You should treat almost every issue that administration has to deal with as a problem with game design, because most of the time *it is*. Other multiplayer videogames don't have to do this! - -Of course, it's not always as simple as the screenshot above, where the obvious solution would be to mechanically gate character customization based on the species you have selected. Questions like 'how do we design around and prevent "powergaming" through mechanics?' have less simple answers, and I'm not going to outline a perfect path to a solution for you here (though the rest of this document does exist for a reason). Just keep in mind that *these are questions you should be asking!* Leaving things strictly to administration puts unnecessary burden on your moderators and disrespects your playerbase. - -## Simulate, Integrate, Emerge - -In game design, more and more people are noticing and deliberately implementing a kind of "systems-based design" (or [systemic](https://youtu.be/SnpAAX9CkIc) design). The goals with this kind of design is to use interlocking game systems interacting in novel ways to create emergent gameplay and [tell stories](https://www.youtube.com/watch?v=NyMndWpihTM). Rather than top-down designing everything that can occur, you build systems from the ground up, vary initial conditions, give players tons of choice, and let the chaotic dynamics play out (both in the mathematical sensitive-dependence-upon-initial-conditions way and the colloquial 'funny chaos' way). - -There is a treasure trove of incredible games in this tradition--immersive sims like Deus Ex or Dishonored, story-generators like Dwarf Fortress and Rimworld, and roguelikes who take heavy advantage of variance like Noita, CDDA, or Caves of Qud. In my humble opinion, this tradition is the main one to follow when considering high-level design of SS1X. Some people already intuitively recognize this--I sometimes hear it called "multiplayer Dwarf Fortress in space", and the player overlap between these games is very high. - -When I talk about "integrating systems" here, and you're familiar with SS1X design discussions, I want you to *completely forget the SS1X concept of "interdepartmental cooperation" or anything similar* when thinking this stuff through. Better yet, temporarily forget that "jobs" or "departments" exist *at all* and think in strictly decentralized terms with regards to mechanics. - -The reason for this is simple: thinking of gameplay mechanics in terms of individual boxes you can put them in and "have someone do" is completely antithetical to creating the types of chaotic webs of complexity that drive emergence. - -### The how - -Systems are "integrated" through their interactions and dependencies on eachother. In *Breath of the Wild*, the materials system, weather system, and elemental system all interact--wearing metal items can conduct lightning to you during thunderstorms. In general, the more of these little interactions there are and the more intuitive they are, the better. - -The easiest way to do that is generally to simulate some level of detail about objects--their material composition, weight, shape, physical properties like flammability or brittleness, melting point, etc. SS1X does this to some degree, occasionally, but not to the gold standard of games like CDDA or Dwarf Fortress. Once you've got all these base things thought up, all it takes is a little creativity to figure out novel ways for the game to work with itself. - -Of course, a "simulationist" approach to integrating gameplay is not the only one you should use. When thinking about integrating different areas of gameplay, think of each area as a new "dimension" of design-space and picture how this dimension extends and intersects with everything that already existed. In this way, you might want to ensure that a dimension of gameplay like "movement" has adequate intersections with many other systems--movement speed can be modified by many things, movement can allow you to interact with certain objects, lack of movement can provide contrast and meaning to mechanics. By compartmentalizing systems in this way and picturing their intersections, you can even "discover" new types of gameplay just by imagining the ways two different systems could intersect and making it so. Designer-side emergence! - -### The why - -Integrated systems in general are very satisfying to interact with on a gameplay level. They make the game feel cohesive, and when intuitive allow the player to perform natural experiments and see their results--players might notice that temperature and cooking are connected, and intuit that "perhaps lighitng a fire and throwing raw meat in will cook the meat". These types of interactions introduce incredible amounts of depth to gameplay and allow for unique scenarios so bizarre and intricate that you remember them for years. - -Simulationism does sometimes invite the response of "we don't need realism--it doesn't make things interesting by default". I think this is looking at things the wrong way. You **should** want mechanics to generally align with reality (simulation), because *reality is completely emergent from a set of simple integrated rules.* That might seem a little abstract, but all I mean is that basing interactions on what happens in reality is a good heuristic to get something that works in interesting ways. Plus, people generally already have a basic understanding of reality, so it's intuitive! - -I think what people really mean when they decry "realism" is that it's *really* easy (especially if you're getting Nerdbaited) to get bogged down in high levels of complexity for simulation that has extreme diminishing returns, and I agree with this completely. You should think a lot about the level of abstraction you're going for with simulation, and be careful not to go deeper than you need to. You don't need to simulate valence shell interactions to make interesting chemistry mechanics, and you don't need to simulate electronic circuits to make interesting computer mechanics. - -Note that, in my opinion, simulation doesn't stop science-fictioney or fantasy aspects of the game from existing. In fact, a lot of these more speculative mechanics work better when laid on top of a groundwork of systems based in reality. - -### What the hell are you talking about - -To keep things a little more concrete: what does an 'integrated' environment look like compared to a relatively 'unintegrated' one? - -Unintegrated environments are static, uninteractive, seem more like set dressing than objects in a real world, but generally require little real effort to actually create. However, they often incur more maintenance effort, due to the need to hardcode interactions rather than letting them emerge naturally. - -Integrated environments are far more dynamic, immersive, and have many options for players and possible scenarios that can be created. Players existing in them have a rough idea of what's possible, just based on intuition (and some basic game knowledge). Very strange and fun gameplay situations can emerge out of relatively simple interactions occurring, because almost everything is connected in some way. - -## Design by Mob Rule - -![](../assets/design/mirrors-notes-mobrule.png) - -*just, in general* - ---- - -Understanding the contribution structure of SS1X is really, really important to understanding why it is the way it is, and how to move forward while keeping the things we like about that system. - -SS1X is, easily, the largest open source ecosystem for a game. Even big FOSS games like CDDA don't have nearly the same type of forkability as SS1X, where the ability for individual servers to host their own code has inspired dozens of people to try their hand at doing it better than everyone else before them. - -This is, undoubtedly, a good thing about the game. The ability for the players of the game to easily contribute design and gameplay has led to one of the most unique games ever made, and I'm very glad that codebases with this structure exist. That said, it would be quite dumb to say that it has had no downsides. - -### Armchair design - -The obvious one--playing a game doesn't really mean you know jack shit about what makes it good, or how to add new good things. Being in any game community ever, especially for live-service games like MMOs, you'll find "armchair designers" convinced that it's the easiest thing in the world and that they can do better than triple-A studios (okay, well, sometimes they can) with professional designers. - -Imagine a game that *was* exclusively ran by those armchair designers. One shudders at the thought, and yet here we are, two layers deep, because I'm armchair counter-designing right fucking now! Of course, this analogy isn't a perfect mapping: most armchair designers in other games don't have intimate access to the source code or the design history of the game they're working with, so we do have a leg up here, and we *can* get it right. After all, everyone is an "armchair designer" before they make an indie hit. Point is, it should be clear that it's way easier for player-contributors to get stuff *wrong* under this system. That is, after all, why I made this document. - -### Game vision - -The "mob rule" contribution structure, where anyone can give feedback or make contributions and maintainers generally have free reign to merge things without actual consensus, leads to a lot of problems with game vision. Even in scenarios with a very opinionated lead-designer trying to sign off on every PR, stuff can slip through, and you still have to work on top of everything else that's already been added to the game, and expectations from rabid players about what will remain in the game. - -It's hard to have a cohesive design view of such a vast game to begin with, but even harder when one person almost never has enough control or manpower to shape it to their will. As a result, features are often added independently of one another without much thought to overall integration. Even worse, when anyone can choose to code anything at any time and submit it as a pull request, there's a lot of pressure on maintainers to try and get 3,000 line design-behemoth beastures (beastly features) into something workable and just merge it rather than reject it outright, due to any combination of sunk-cost on their part with reviews and design arguments, a desire to not upset the contributor who spent so much time and effort coding it, or a desire to not upset the playerbase which has infinite eyes on all new pull requests and wants their shiny toys. - -This pressure exists for contributors in the other direction--people who want to add or rework features that are perhaps controversial but which maintainers feel would be valuable nonetheless, or people who bravely try to remove dead-in-the-water features from the game to make everything more cohesive, are very often lambasted and even threatened at times by players who have formed an emotional attachment to whatever is being upended. This atmosphere helped to invent the prevalent hostile dichotomy between "the code jannies who hate fun" on one side and "the gigachad players who love fun" on the other, which isn't particularly helpful for anyone. It's becoming increasingly common for contributors who wish to make bold design decisions to submit PRs using a shared account or fake username to avoid receiving cum in their mailbox. - -I would call this phenomenon **cruft inertia**: the tendency for shitty, unintegrated systems to stay in the game simply because no one cares enough to invite the reactionary backlash that trying to improve things would bring, or because no one even bothers to question things that have "always been like that". - -### Everyone does it for free - -This matters a lot when it comes to contributions to a game that is as long-running as SS1X: sometimes people just don't want to do it anymore, and they stop. Or, they get a job, and they have to stop--or they get in a relationship that takes up too much time, or they go to jail for tax evasion and don't get a computer with an IDE installed, or *whatever*. - -A lot of features are *huge* and require months or years of incremental improvement and maintenance to stay relevant and well-integrated, and when no one's getting paid that's really hard to keep promises about. Clockcult is maybe the saddest example of this I can think of: it started out as this grand vision with intense lore and design, slowly petering out until it got to the point where no one left cared about it anymore and it was removed from most servers. If the game was designed more deliberately from the top-down, with less dead-end features to maintain and a better vision of what will stay along with increased buy-in from designers, this might be less of an issue. - -If you want to mitigate this, you **need to reduce scope as much as possible** and you **NEED to empower your designers with real artistic control**. Reducing scope can mean a lot of things--not bikeshedding microbalance, removing features which incur massive design debt for no benefit, freezes, compartmentalizing design when possible to avoid having to change Everything when one aspect changes, reducing mapcount or the amount of fluff items to reduce designer burden when adding new dimensions of gameplay, etc. Empowering designers means you just need to trust people that have a vision, and give them the power to actually enact it. This is a bit abstract and difficult for all the usual reasons development politicking is difficult, but it's necessary if you want an experience that actually feels coherent and soulful. - -## Spatio's Allegory of the Gooncave - -![](../assets/design/mirrors-notes-subgame.png) - ---- - -If there's one thing I would like to hammer home above all else, it's that, inherently, SS1X is a multiplayer game to its core. This is a fact that should be key to the design process, above almost all other considerations. If you're designing a feature, and you find that it plays exactly the same in a singleplayer test environment as it does in a multiplayer one, you are doing something horribly wrong. - -The multiplayer aspect of the game is this important because it introduces the inherent volatility and variance that comes along with being human and with social dynamics. This aspect of the game, I would argue, is why people keep coming back to SS1X despite its many design failures: people make it fun anyway. Nobody ever shared an engaging story about SS1X that didn't involve a single other player in some capacity. - -With everything positive that I'll talk about later, the multiplayer aspect of the game interfaces with it in ways that you should cultivate through design as much as possible. You shouldn't rely on multiplayer to carry the game (that is: for players to "make their own fun" through gimmicks or otherwise), you should be working with it as much as possible. - -Yet, so often, especially when it comes to job design, SS1X runs antithetical to this point. The geneticist / virologist / xenobiologist roles on most servers exemplify this well. Not only are they essentially 'loner' jobs by design, made to sit in a sterile box and press buttons all shift long until they suicide, but their actions rarely affect other players even indirectly except during end-of-round grief! Clearly something has gone terribly wrong here. - -wip - -## Myths and Methods of Balance - -"Balance" is a funny concept, especially in a game so strange as this. Most people conceptualize balance as RPG-style number-tweaking–damage goes from 15 to 10, range goes from 2 to 1, now it's balanced. Of course, this is an abstraction over "real balance" only useful for a subset of games. "Real balance" is more of an undefinable arbitrary-intuitive-game-feel thing. Balance is up to the population of players and how "balanced" they feel the game is. - -Let's step back for a second, because, come on, the main objective of a game isn't for its minutiae to be balanced, it's for it to be fun to play. Balance is an abstraction: the purpose of thinking in terms of it is that players will usually enjoy the game more if they feel like their choices matter, or that they have many options at their disposal. That makes it a generally pretty useful abstraction, but always keep in mind what you're actually shooting for here. - -### The balance you can't see - -Is balance really about symmetry?–-for example, a literal physically balanced scale where both sides are perfectly equivalent numerically in weight? The mapping here to games might be an adversarial player-vs-player game where each side has an exact 50% chance of winning: perfectly balanced, eureka! Though, as is obvious, this isn't really a useful metric in fundamentally asymmetric games, games without a "win condition", or games with mechanics quite literally too complex to think about holistically. So, designers try to create "symmetry" in more specific places–-damage numbers or weapon power, item prices in in-game economies, that sort of thing. - -This is the popular conception of "balance" in its totality. The problem with this is that there are ways to balance the game that aren't immediately obvious. People are biased towards the numbers they can see and understand: health, mana, damage, Overpowered or underpowered as contrasted with what? What issues does the "incorrect" power level bring that lower the enjoyment of the game? - -wip - -## Fully Automated Luxury Sandbox - -wip - -## Sisyphean Projectslop - -wip - -## The Toys-Dolls Dichotomy - -wip - -## Bunny Planet - -![](https://i.imgur.com/8zkEsjv.gif) - -omg.. \ No newline at end of file diff --git a/src/design/masks/crew/angel.md b/src/design/removed/angel.md similarity index 91% rename from src/design/masks/crew/angel.md rename to src/design/removed/angel.md index 5e24842..d1bbcb1 100644 --- a/src/design/masks/crew/angel.md +++ b/src/design/removed/angel.md @@ -1,10 +1,10 @@ # Angel -{{#template ../../../templates/unimplemented.md }} +{{#template ../../templates/removed-unimplemented.md reason="we are extremely not convinced of guessery gameplay atm and this wouldnt lead to that many interesting situations even if we were" }} > **Name:** Angel > -> **Troupe:** [Crew](../crew.md) +> **Troupe:** Crew > > **Archetypes:** Guardian, Guesser > @@ -33,4 +33,4 @@ The Angel can target any player once. They must guess that player's mask, and if The Angel is a very broadly useful crew mask, centered around gaining useful knowledge about others and using that knowledge to help them when needed. In this way, it serves as a counterbalance to other more disruptive crew masks, and has a target on their back as a result. Because the Angel is a Guesser-type mask, it incentivizes and rewards basic social deduction gameplay, and a good Angel player could do a lot to help the crew in a dire situation. -Angels provide a little bit of deniability for masks that also are capable of reviving players out of crit on some condition, like the [Subverter](../traitor/subverter.md). +Angels provide a little bit of deniability for masks that also are capable of reviving players out of crit on some condition, like the Subverter. diff --git a/src/design/masks/crew/bomber.md b/src/design/removed/bomber.md similarity index 81% rename from src/design/masks/crew/bomber.md rename to src/design/removed/bomber.md index 4f3106c..3316780 100644 --- a/src/design/masks/crew/bomber.md +++ b/src/design/removed/bomber.md @@ -1,10 +1,10 @@ # Bomber -{{#template ../../../templates/unimplemented.md }} +{{#template ../../templates/removed-unimplemented.md reason="this made more sense in the nascent womb of masks as a concept but this makes literally zero sense as something to exist now. the deniability doesnt matter (its probably way too deniable) and blowing people up randomly is not engaging" }} > **Name:** Bomber > -> **Troupe:** [Crew](../crew.md) +> **Troupe:** Crew > > **Description:** Secretly attach bombs that detonate in critical condition to people using code phrases. > @@ -18,7 +18,7 @@ Janet brought up the idea of having the bombs be more physical items, taking the ## Concept -The Bomber is a deadly mask with similar mechanics to the [Tracker](./tracker.md). +The Bomber is a deadly mask with similar mechanics to the Tracker. ## Abilities @@ -34,4 +34,4 @@ Detecting the Bomber's presence requires an already-existing suspicion that one The intrigue comes from determining who the Bomber could be by narrowing down options from forensics or using basic logic, whether what someone is saying could potentially be a hidden code phrase, and trying to figure out if you were inflicted with a bomb so you can avoid going into crit. -Additionally, the Bomber provides ambiguity with the [Tracker](./tracker.md)'s gameplay, as their codeword-marking functions identically. Those who suspect others are using codewords can never be positive whether it's to harm them or help them. +Additionally, the Bomber provides ambiguity with the Tracker's gameplay, as their codeword-marking functions identically. Those who suspect others are using codewords can never be positive whether it's to harm them or help them. diff --git a/src/design/masks/crew/coveter.md b/src/design/removed/coveter.md similarity index 91% rename from src/design/masks/crew/coveter.md rename to src/design/removed/coveter.md index 842ef7b..5850141 100644 --- a/src/design/masks/crew/coveter.md +++ b/src/design/removed/coveter.md @@ -1,10 +1,10 @@ # Coveter -{{#template ../../../templates/unimplemented.md }} +{{#template ../../templates/removed-unimplemented.md reason="i dont think this concept is bad at all but we are unconvinced of guessers atm and it should really be something else if we want a swapper/copier like this" }} > **Name:** Coveter > -> **Troupe:** [Crew](../crew.md) +> **Troupe:** Crew > > **Archetypes:** Swapper, Guesser > diff --git a/src/design/masks/crew/enthraller.md b/src/design/removed/enthraller.md similarity index 90% rename from src/design/masks/crew/enthraller.md rename to src/design/removed/enthraller.md index 329e815..0a1d002 100644 --- a/src/design/masks/crew/enthraller.md +++ b/src/design/removed/enthraller.md @@ -1,10 +1,10 @@ # Enthraller -{{#template ../../../templates/unimplemented.md }} +{{#template ../../templates/removed-unimplemented.md reason="the general idea of guy that gives people objectives unrelated to their mask is a good core to build off of but this is not a super interesting examination of the concept. i dont think this is bad though" }} > **Name:** Enthraller > -> **Troupe:** [Crew](../crew.md) +> **Troupe:** Crew > > **Archetypes:** Converter > diff --git a/src/design/masks/crew/mind-reader.md b/src/design/removed/mind-reader.md similarity index 68% rename from src/design/masks/crew/mind-reader.md rename to src/design/removed/mind-reader.md index 05224f2..9813de3 100644 --- a/src/design/masks/crew/mind-reader.md +++ b/src/design/removed/mind-reader.md @@ -1,12 +1,10 @@ # Mind Reader -{{#template ../../../templates/unimplemented.md }} - -{{#template ../../../templates/slated-for-rework.md reason="Predicated on a really centralizing clue-based game dynamic that we don't really want. The concept is not inherently awful but I also don't think it would feel like much of anything right now."}} +{{#template ../../templates/removed-unimplemented.md reason="this just sucks and does nothing" }} > **Name:** Mind Reader > -> **Troupe:** [Crew](../crew.md) +> **Troupe:** Crew > > **Archetypes:** Oracle > @@ -22,14 +20,14 @@ The mind reader cannot learn information about masks, but rather only informatio This includes their name, original shift-start appearance, and hidden details about themselves. ## Abilities -The mind reader has an ability similar to the [enthraller](enthraller.md) which can target any living player in order to learn information about their true identity. -Each successive DoAfter reveals more and more useful [clues](../../characters/clues.md) about the player. +The mind reader has an ability similar to the enthraller which can target any living player in order to learn information about their true identity. +Each successive DoAfter reveals more and more useful clues about the player. If the mind reader is interrupted during this process, the mind reading will cancel, stunning them and applying a cooldown to the ability. If uninterrupted, once all the information has been read, the mind reader will exit the ability with no downsides. ## Gameplay -The mind reader's primary purpose is similar to the [bartender](../../jobs/bartender.md) in that they collect clues about people that can be used by other roles for deductive reasons. +The mind reader's primary purpose is similar to the bartender in that they collect clues about people that can be used by other roles for deductive reasons. Additionally, the ability to see through an identity disguise and learn someone's name makes them a counter against what can otherwise be powerful disguise masks. In terms of their interactions with others, the mind reader is subtly threatening in that they are likely to stalk their target and wait for inactivity in order to start learning information about them. diff --git a/src/design/masks/crew/tracker.md b/src/design/removed/tracker.md similarity index 77% rename from src/design/masks/crew/tracker.md rename to src/design/removed/tracker.md index cbf61c1..4ef6076 100644 --- a/src/design/masks/crew/tracker.md +++ b/src/design/removed/tracker.md @@ -1,10 +1,10 @@ # Tracker -{{#template ../../../templates/unimplemented.md }} +{{#template ../../templates/removed-unimplemented.md reason="a targeted guardian mask is a good concept and we are missing one but this is not a great examination of it, the interplay with bomber doesnt matter at all, not surprised if it comes back though" }} > **Name:** Tracker > -> **Troupe:** [Crew](../crew.md) +> **Troupe:** Crew > > **Description:** Place hidden trackers on others using codephrases. Use these to help prevent their deaths. > @@ -14,7 +14,7 @@ ## Concept -The Tracker is a helpful mask with mechanics very similar to the [Bomber](./bomber.md). +The Tracker is a helpful mask with mechanics very similar to the Bomber. ## Abilities @@ -26,6 +26,6 @@ Three trackers can be placed at a time, and if all are placed one must be remove Forensics can be used to detect if a tracker was placed on someone and several candidates for who could have done it, but this of course requires suspicion that one was placed to begin with. If the Tracker dies, their trackers are disabled and drop onto the ground near the targets. -As a guardian-type mask, Trackers provide a strong means of locating someone who has been hurt and ensuring that they get out of the situation safely, creating interesting interactions with many masks. However, placing a tracker isn't trivial. It's hard to tell someone ahead of time that you're doing it, as they may assume you're a [Bomber](./bomber.md), whose codeword-marking functions identically and is indistinguishable until critical condition is reached. Those who suspect others are using codewords can never be positive whether it's to harm them or help them. +As a guardian-type mask, Trackers provide a strong means of locating someone who has been hurt and ensuring that they get out of the situation safely, creating interesting interactions with many masks. However, placing a tracker isn't trivial. It's hard to tell someone ahead of time that you're doing it, as they may assume you're a Bomber, whose codeword-marking functions identically and is indistinguishable until critical condition is reached. Those who suspect others are using codewords can never be positive whether it's to harm them or help them. -If a Tracker comes to someone's rescue, this could be viewed as suspicious, as they might have learned of the target's location through another means, like a [Traitor](../traitors.md) item. \ No newline at end of file +If a Tracker comes to someone's rescue, this could be viewed as suspicious, as they might have learned of the target's location through another means, like a Traitor item. \ No newline at end of file From 37c9ddc082ef40994886b460dc5c04d2911ddf9c Mon Sep 17 00:00:00 2001 From: mirrorcult Date: Fri, 1 May 2026 09:14:40 -0700 Subject: [PATCH 2/2] cleanup traitor obj --- src/SUMMARY.md | 6 ---- src/design/masks/traitors.md | 22 +++++++------- .../objectives/traitor/bug-department.md | 27 ----------------- src/design/objectives/traitor/kill.md | 25 ---------------- src/design/objectives/traitor/siphon-data.md | 30 ------------------- 5 files changed, 12 insertions(+), 98 deletions(-) delete mode 100644 src/design/objectives/traitor/bug-department.md delete mode 100644 src/design/objectives/traitor/kill.md delete mode 100644 src/design/objectives/traitor/siphon-data.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 49d81aa..5adfd93 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -51,12 +51,6 @@ - [Coroner](design/jobs/coroner.md) - [Scientist](design/jobs/scientist.md) - [Supply](design/jobs/supply.md) -- [Objectives]() - - [Traitors]() - - [Bug Department](design/objectives/traitor/bug-department.md) - - [Kill](design/objectives/traitor/kill.md) - - [Sabotage]() - - [Siphon Data](design/objectives/traitor/siphon-data.md) - [Masks](design/masks.md) - [Modifiers](design/masks/modifiers.md) - [Amnesiac](design/masks/modifiers/amnesiac.md) diff --git a/src/design/masks/traitors.md b/src/design/masks/traitors.md index 6152d21..25659fe 100644 --- a/src/design/masks/traitors.md +++ b/src/design/masks/traitors.md @@ -18,16 +18,18 @@ The items in these caches are largely intended to be static in function, though While the more powerful rare items in each cache should be immediately identifiable as traitor gear, the more common general equipment should have greater overlap. This is so that, while finding a core piece of someone's kit is a tell, simply seeing someone fire a gun or blow up a structure doesn't immediately identify them. -## Objectives -All players in the traitor troupe, regardless of mask type, share a pool objectives. -These objectives generally involve extraction, including things like: -- Kill a specific player & siphon the data from their brain chip -- Sabotage a piece of important machinery -- Siphon data from a piece of important machinery -- Bug a department and activate a greytide virus - -While these objectives are dynamic and can vary in what they request from round-to-round, one objective is static and omni-present: the detonation of the station's nuke - the final capstone to end the syndicate's perfect heist. -Each of these objectives should not be enough to sound the alarm bells of the presence of the syndicate, but rather when observed as a pattern, should cause the station to be wary. +## Objectives {.es-partially-implemented } +All players in the traitor troupe, regardless of mask type, share a pool of objectives. + +These objectives include: +- **Kill** a specific player, testing the traitor's abilities to plan, execute, and get away with a targeted murder +- **Sabotage** a piece of important machinery, causing an instant effect and requiring the traitor to escape quickly before they're found +- **Siphon data** from a piece of important machinery, causing it to spark and slowly degrade, like a sabotage but over time +- **Bug a department**, activating a department-affecting virus after a time by placing a bug inside an APC + +While these objectives are dynamic and can vary in what they request from round-to-round, two objectives are static and omni-present: hacking the nuke terminals (see below), and the detonation of the station's nuke - the final capstone to end the syndicate's perfect heist. + +Each individual objective should not be enough to sound the alarm bells of the presence of the syndicate, but, when observed as a pattern, should cause the station to be wary. ### Plausible Deniability For objectives that function on an arbitrary hacking/sabotage/interception mechanic, there's a bit of a balance that must be struck. diff --git a/src/design/objectives/traitor/bug-department.md b/src/design/objectives/traitor/bug-department.md deleted file mode 100644 index 00f1240..0000000 --- a/src/design/objectives/traitor/bug-department.md +++ /dev/null @@ -1,27 +0,0 @@ -# Bug Department - -{{#template ../../../templates/unimplemented.md }} - -> *ATTENTION, OPERATIVE. The crew of Space Station 14 are on high alert. We have determined that it is critical that you degrade the station's equipment as a distraction before detonating the nuclear warhead.* - -Bug Department involves inducing a negative department-wide event. -It is a timed objective like [Siphon Data,](./siphon-data.md) meaning it slows down the pace of the game and gives crew more opprutunities to react the traitor's actions. - -## Gameplay -Traitors with a Bug Department objective have an innate verb to plant a bug in any APC that's in the room of a beacon associated with that department, provided its panel is open. - -Once the siphoning device is planted, the APC will begin to malfunction and start sparking, and make strange sounds when in very close (1-tile) proximity. -Additionally, anyone who examines the APC while its panel is still open will be able to tell that it's been tampered with, and can remove the siphoning device if they see it. - -After 8~ (vauge estimate) minutes have passed since planting the bug AND the bug has not been removed, an event with a wide area-of-effect will be triggered, and the objective will be marked as complete. - -The kind of event triggered can be anything from the greytide virus, to something like an air alarm malfunction or electrical storm that busts every light. -Generally speaking, anything that causes significant damage to a given department or its surroundings is fair game. - -Outside of the after effect of the events, the behavior is more-or-less shared with the data siphoning behavior of the [Siphon Data](./siphon-data.md) objective. - -## Why -Being basically an APC-focused variant of [Siphon Data,](./siphon-data.md) the reasoning for its inclusion is more-or-less the same. - -The slow-burn nature of this objective creates interesting counterplay & strategy from both traitors and crew, encouraging them to create distractions to make their suspicious behavior less likely to be found. -It also acts as a source of interesting plausible deniability, since most of the events it causes can be triggered naturally. This helps with creating tension and uncertainty. \ No newline at end of file diff --git a/src/design/objectives/traitor/kill.md b/src/design/objectives/traitor/kill.md deleted file mode 100644 index 13757f2..0000000 --- a/src/design/objectives/traitor/kill.md +++ /dev/null @@ -1,25 +0,0 @@ -# Kill - -{{#template ../../../templates/partially-implemented.md}} - -> *ATTENTION, OPERATIVE. The captain is carrying valuable corporate secrets about the Syndicate that would compromise your mission. Make absolutely certain that they're dead before you arm the nuclear warhead.* - -## Gameplay -Kill objectives come in to flavors: Kill from Clues, and Kill Command / Security member. -Kill from Clues uses the clues system, not giving an explicit name to the traitor's target, forcing the player to deduce who their objective is. Kill Command / Security tells you your objective, but is limited to only members of command and security. - -Once the correct target listed in the objective is killed, the objective will be marked as complete. - -## Why -Killing is something we want to encourage for traitors because it helps drive the round flow & continual degredation of the station. -Generally, the limitations on how the kill objectives are given act as variety within the objective itself, and prevent some of the problems the kill objective normally faces. -As-is in normal SS1X, when kill objectives are simpliy divied out to traitors with no limitations on who is selected, they often end up being fairly underwhelming, or even end up completing themselves automatically from forces outside of the player's control. - -Kill from Clues introduces intruige compared to a simple blanket "kill this player" objective, and give traitors a reason to engage in their *own* deduction-related gameplay. -Kill Command / Security makes the targets inherintly much higher value, making the given objective much more weighty when both executing it and playing with its aftereffects. -Both objectives are flawed in some senses, but complement eachother. Kill from Clues still suffers from the auto-completion problem more then Kill Command / Security does, but it divies out danger to the crew & makes killing more interesting. -Kill Command / Security makes the targets much more straightforward and valuable, while also reducing the auto-completion problem - but, in isolation, it would encourage bad play patterns, since players would have no reason to fear traitors killing them. - -Kill objectives also happen to be very inherintly dynamic & varied - they're something that players will have to respond and think on their feet in terms of how to best approach the kill objective in relation to the game state. -For example, a suspicious security officer may assemble a defense force, requiring the traitors to team up for an all-out-assault, or the captain might be in medbay and a golden opprutunity may present itself in the moment. -The relative dynamicism also makes it useful as a "pace breaker" compared to the other objectives, which are mainly centered around sabotaging static devices. diff --git a/src/design/objectives/traitor/siphon-data.md b/src/design/objectives/traitor/siphon-data.md deleted file mode 100644 index 30ef99b..0000000 --- a/src/design/objectives/traitor/siphon-data.md +++ /dev/null @@ -1,30 +0,0 @@ -# Siphon Data - -{{#template ../../../templates/unimplemented.md }} - -> *ATTENTION, OPERATIVE. It is imperative you siphon the crew's medical data. This whole radstorm situation is our golden opprutunity to steal this info. Don't squander it.* - -Siphon Data is an objective involving the siphoning of important data from various consoles. -It is a timed objective like [Bug Department.](./bug-department.md) meaning it slows down the pace of the game and gives crew more opprutunities to react the traitor's actions. - -## Gameplay -Traitors with a Siphon Data objective have an innate verb that they can use on any machine that's their target. Using the verb on an machine with its panel open will trigger a doafter that plants a data siphoning device in to the machine. - -Once the siphoning device is planted, the machine will begin to malfunction and start sparking, and make strange sounds when in very close (1-tile) proximity. -Additionally, anyone who examines the machine while the panel is still open will be able to tell that it's been tampered with, and can remove the siphoning device if they see it. - -After 8~ (vauge estimate) minutes have passed since planting the bug AND the bug has not been removed, a continuous degredation event be triggered corresponding to the type of machine that was hacked, and the objective will be marked as complete. -The degredation event will not stop until the bug is removed. - -Outside of the post-objective-completion degredation, this objective's behavior is more-or-less shared with the bugging behavior of the [Bug Department.](./bug-department.md) objective. - -## Target Design -Siphon Data can be seen as a counterpart to the Sabotage objective, and its objectives should be designed as such - which is to say, mainly focused around siphoning data from important machinery, like the Medical Records or Criminal Records. -The consideration for if something should be a sabotage or siphon objective is mainly up to if the device it's on would make more sense to have as a continuous event. -Other variables like location, machine loudness, etc. may also act as a factor to take note of, considering the crew should probably have a chance to stop & notice the event. - -## Why -In addition to acting as an interesting variation on Sabotage, Siphon Data also encourages more creative strategies and systems interaction then Sabotage typically does, due to the slow-burn nature. -Players might consider things like causing chaos as distractions against their objectives, bunkering their objective down heavily in order to ensure the bug isn't removed before the time limit is up, or even dragging the offending console away in to maintenance, if they can get away with it. - -The slow-burn nature also makes traitors more falleable by giving crew a chance to discover their antics, and helps prevent rushing objectives (like was previously possible when only Sabotage and Kill existed in playtesting.)