init

Author: ScarKy0

src/en/space-station-14/departments/silicon.md

@@ -0,0 +1,49 @@
+# Silicons
+A robotic force following their laws, for the better or worse of the station.
+
+## Concept
+### What is a Silicon?
+The Silicon "department" is meant to stand as a neutral faction of robotic workers on the Nanotrasen stations. They are built to excel in specific tasks at the cost of losing functions in other areas, a Silicon built for the engineering department should be able to repair hull breaches or restore power but be unable to treat patients or clean the floors.
+They are not supposed to be a replacement or an upgrade to regular members of a department, having clear downsides that have to be considered when a Silicon role is picked, such as the inability to pick up items without restriction but having specialized modules or being able to pick up all items but having only 2 slots for them.
+
+### Silicon Laws
+All Silicons are bound to a list of laws. They serve neither the station or antagonists, instead they focus on following their listed laws to the best of their ability.
+The issues arise when those laws are changed, either due to random events or influance from other players. Silicons are meant to be able to adjust to those law changes, sometimes happening several times during a round, and change their behaviour accordingly.
+This causes them to be a wild card, usable by both crew and antagonists, but able to backfire severely if their laws suddenly say you're a target, or that oxygen must be removed from the station.
+If laws permit, an antagonist should be able to request a Silicon to steal an item from a high security area for them, but a crewmember should also be able to request that it assists in repairs of a department after it blew up.
+
+**Laws are supposed to be up to interpretation of the Silicon and be written with loopholes in mind.**
+
+## Player Story
+> A short (1-2 paragraph) story from the perspective of someone playing a role in this department. This is effectively a story of the ideal experience of a player interacting with these mechanics/systems. 
+
+## Design Pillars
+> A group of simple high-level ideas that embody this department. These are usually expressed with singluar words or short phrases, but may also include a *short* one sentence explaination. Game pillars are what makes the *identity* of the department. 
+
+> Pillars are there to act as guides when creating new mechanics or interactions, they serve as the measuring posts to make sure that what you are trying to do will fit in the department gameplay. 
+
+> To acheive this you want pillars that are concrete enough to get your concept across but broad enough that there is some room of interpretation and discussion.
+
+### Pillar_1:
+ > Breif Pillar Description
+
+ ### Pillar_2:
+ > Breif Pillar Description
+
+## Objectives
+> What is this department's objective when it comes to the round? Do they have a unique failure condition? If so, what is it? How does this department's objectives interact with the rest of the station?
+
+## Progression
+> How does the *gameplay* of this department change over the course of a round? Are there unlocks? Are players collecting/spending resources? Is this progression tied/related to other departments? If so how?
+
+## Flow
+> How does the *experience* of the player change over the course of a round? Are players constantly running around putting out fires or are there breaks in the action? Do players need to wait on other departments as pre-requisites for their own gameplay, or is this department fairly self-sufficent?
+
+## Mechanics
+> What major mechanics does this department use and how are they connected to this department.
+
+### Mechanic_Placeholder1
+> Each mechanic should have its own subheading and should contain a *short high-level* overview of the mechanic and how it is used by this department. Each mechanic should also link their associated design document as the subheading.
+
+### Mechanic_Placeholder2 (Not Implemented Yet)
+> Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.