Overall Design Direction
Note that this is subject to constant change, it is very hard to state why something works or why something doesn't work, so some things in here may be not fully completed. If you disagree with something or want to bring it up to further discussion, feel free to bring it up on discord. Every PR will be looked at on a case-by-case basis.
Proposed changes may be provided for some options, however alternatives are available and discussion about them is always open in either discord for ideation and github discussions for full-scale design documents. Changes that are close to the proposed changes are likely to be accepted and prioritised as PRs.
The general design direction section is simply a basis to provide an understanding for how we want the game to look and feel, the design rulings are specific rules that must be adherered to in order for a PR to be considered. If you wish to go against the design rulings, then discuss it with the head-developer on discord.
SS13 is not a typical game where players are given a goal to complete and must work towards it, the only objective specified is to survive with players making their own goals throughout a round. SS13 functions more like a story engine rather than a game, making interesting events through the interactions between players and mechanics.
There should be a main storyline, the actions and decisions of players should influence this story and the storyline should influence the players.
Interactions are the core of what makes SS13 so unique and interesting. 2 rounds will never be the same since while a player can control their own actions, their experience is also affected by the actions of other players. This is very important to remember and consider!
As a whole, feature design should encourage roleplay and create interesting stories as oppossed to a competetively viable environment where skill is more important than character.
-
Job roles should never encourage staying in a single room for extended periods of time. Any job should have the need to leave their department every once in a while.
- In order to create engaging and meaningful interactions a few things generally help:
- Variety (Requiring the same thing constantly can become tedious)
- A reasonable level of demand (Botany unstable mutagen was so high that chemists would have to be making it constantly)
- Taking a long time to get something you need often promotes people to just do it themselves, anything that takes a long time may work better as an upgrade/higher level with a basic resource allowing functionality but at a less effective rate.
- In order to create engaging and meaningful interactions a few things generally help:
-
Threats and antagonists should take a significant amount of time and effort to deal with. On the flip side, threats and antagonists should have a hard time dealing with the people trying to stop them. Anything that results in instant wins in combat should be heavilly discouraged. Both antagonists and security should have a hard time dealing with each other and one side should not be significantly more powerful than the other (Maintain the balance).
-
The station should be aware that a threat exists, but should have to work in order to uncover what/who that threat is related to.
-
The goals of the players should always be one that encourages the things stated above and below. Player goals should never be narrow and have a single path to completion, resulting in meta strategies. Instead they should be obscure or subject to change as things happen.
-
Features that are strictly references to other games are disliked. Taking inspiration from other sources is fine, but there should be some work to make it fit within the SS13 universe and gameplay style.
-
Non-antagonists interacting with systems should lead to drama. Consider the risk and reward of the things that you are adding. Is there a risky way to do something that provides greater rewards? Can non-antagonists create drama from your feature without being banned for self-antag? If the answer to these questions is no, then consider if it is possible to make this new feature interact with the game more.
-
Antagonists are best when their precense is obvious, but their identity is hard to uncover. If you are creating new antagonists, make sure to play into this. Some other general tips for creating antagonists are:
- Consider their objectives carefully; do you need objectives? An antagonist whose mechanics push them to perform antagonistic actions will be far better than an antagonist with OOC-provided objectives. (An example of more diagetic objectives could be changelings requiring the consumption of blood, or flesh, in order to stay alive and keep their powers but as they get more powerful they get hungrier encouraging hunting in maints.)
- Open objectives mean that roleplay can change the outcome of the interaction, compared to fixed objectives (assassinate X) which cannot be reasoned with via roleplay.
- While balance is important, antagonists that are not very powerful or require a high-skill to play are generally perceived more poorly. Your antagonist needs to have powerful abilities that help them survive and get away, even if these don't make them a monster in combat.
- Consider the weaknesses of your antagonist, how obvious is it that someone is using one of these weaknesses.
- For conversion antagonists, consider the effects that snowballing will have on your balance. If they get spotted 10 minutes into the round, is it a pointless battle?
- Consider their objectives carefully; do you need objectives? An antagonist whose mechanics push them to perform antagonistic actions will be far better than an antagonist with OOC-provided objectives. (An example of more diagetic objectives could be changelings requiring the consumption of blood, or flesh, in order to stay alive and keep their powers but as they get more powerful they get hungrier encouraging hunting in maints.)
-
Content that may widely be considered offensive to a reasonable person is not allowed.
-
Any content added to the repository must follow the discord and game-server rules. The rules should be applied more strictly to the repo, and anything that could be considered to be in a 'grey area' should not be allowed (Names that would be fine if someone called themselves it, but are likely to cause accidental rule violations in certain circumstances should not be default names).
-
Content that directly references players of the game, or in-game characters created or used by players of the game, will be rejected. (For the sake of freedom, references may be added for particularly influential people/events in a minor way, such as on Centcom, but this is up to the Beestation head's discretion.). You may create new characters for the sake of story, but these shouldn't be references to characters that are played in the game server.
- Maps must use the supermatter engine as their primary engine and solars as a backup power generation source. This is because standardising the engines is necessary for when we want to expand engineering into having greater risk/reward.
- Anything that provides non-cosmetic impacts across rounds is strictly prohibited. The game is about what your character is doing on this copy of the universe and not about what the player has been doing for their last 200 hours. A character controlled by someone who is brand new should be in the same situation as a character controlled by a player who has 2000 hours, excluding any IC differences such as job-rank.
-
Jobs must have a mechanical reason to exist. They must have at least 1-2 external interactions with other departments or job roles either in the form of dependencies, or another job that depends on them.
- In order to avoid 'bad-dependencies' (botany-chemistry relation) consider these things:
- Does the dependency involve a choice being made? (Botany only ever need unstable mutagen and nothing else, there are no riskier but more rewarding chemicals that can be made, and no other alternatives available from other departments)
- Is the frequency of this interaction reasonable? (I shouldn't need to visit the chemist every 2 minutes to get more unstable mutagen)
- Can the job still function at a reduced capacity without the dependency? (It may be much slower or have some limitations without the dependency, but the job should still be able to have some basic function while they wait for it to be completed)
- How long will the dependency take to be completed? (If it takes 20 minutes to get something, then most people will end up doing it themselves, espeically if there are no parallel tasks to be completing)
- In order to avoid 'bad-dependencies' (botany-chemistry relation) consider these things:
-
Job mechanics should be able to be completed without interacting with other departments, although these methods should always be suboptimal compared to working with other departments.
- Gameplay mechanics must align with the rules, and should encourage a reasonable player to play in a way that would be following a rule even if they were not aware of said rule.
- For example: It is against SOP to build mechs without permission, however mechs are almost never a danger to produce and always an advantage to the crew. DNA locking was removed from mechs to make them more inherently dangerous to have around, and more open to exploitation from antagonists.
- Another example: Giving antagonists access to items that can only be used for murderbone, and then having anyone who uses those items getting banned.
- Another example: No powergaming rules but then giving players roundstart access to powerful weapons if they open a closet. If players are going to have items that may be considered powergaming, they need to be pushed towards having a roleplay reason to obtain them.
- Another example: If you want to push non-antagonists towards being able to commit some minor crimes for their own benefit, then you need to have an IC reason for them to be committing that crime, and a reasonable level of accessibility to be performing that crime. If crewmembers have to do some advanced hacking techniques in order to unlock an intended illegal activity then it may be considered self-antag by the admins and be bwoinked; if it was reasonably accessibile to all people then it won't be.
-
Controls should be well communicated and easy for new players to understand.
-
Game mechanics should be able to be figured out in game, either through experimentation or communication (Using the wiki books doesn't count). You should be able to figure out the basics of a job/mechanic in game, and be able to figure out any advanced concepts/interactions via experimentaion.
-
Mechanics should never be such that an experienced player is the only person capable of utilising them.
- Virology is an example of a job role that encourages saving powerful diseases across multiple rounds; is so complicated and poorly communicated that only an experienced player or coder could understand how to make it work.
Note that this section is largely TODO and needs a significant amount of discussion and work from anyone with sufficient writing skills.
- Occult related features should tie in with the current state of magic/cult and not introduce an entirely new and opposing lore elements.
- Advanced AI are still an experimental technology and are difficult to control.
- Long range teleportation is still an experimental technology that Nanotrasen is trying to focus on
- Shuttles/Ships can move between galaxies at a relatively high speed, but long-distance travel is still quite slow (leading to the reason why the sector SS13 is located in is so isolated)
- Nanotrasen should primarily utilise energy weapons.
- Syndicate factions should only use ballistic weapons and doesn't manufacture energy weapons.
Players should be encouraged to build up stories for their characters, or be provided with some context about their situation in order to allow for roleplaying that situation (Traitors could be provided with a reason for their employment with the syndicate for example).