Moving Fundamental Design Principles into core design and general des…

…ign link cleanup (#153)

src/SUMMARY.md

@@ -37,7 +37,7 @@ General Development
   - [YAML Crash Course](en/general-development/tips/yaml-crash-course.md)
 - [Feature Proposals](en/general-development/feature-proposals.md)
   - [Expected Team Decorum & Usage](en/general-development/feature-proposals/expected-feature-proposal-decorum.md)
-  - [Fundamental Design Principles](en/general-development/feature-proposals/ss14-fundamental-design-principles.md)
+  - [Core Game Design](en/space-station-14/core-design.md)
 
 
 SS14 By Example
@@ -100,8 +100,8 @@ Space Station 14
 ================
 
 ----------------------
-- [Core Design](en/space-station-14/core-design.md)
-  - [Gameplay Pillars](en/space-station-14/core-design/pillars.md)
+- [Core Game Design](en/space-station-14/core-design.md)
+  - [Gameplay Principles/Pillars](en/space-station-14/core-design/principles-pillars.md)
   - [Antagonists](en/space-station-14/core-design/antagonists.md)
 - [Mapping](en/space-station-14/mapping.md)
   - [Mapping Checklist](en/space-station-14/mapping/mapping-checklist.md)

src/en/general-development/feature-proposals.md

@@ -5,12 +5,14 @@ If you are considering adding or reworking some major component of the game it's
 ## How do I make a proposal?
 
 1. Make a copy of the design proposal template located at `src/en/proposals/proposal-template.md`.
+
+3. Read through [SS14's Core Design Documentation](src/en/space-station-14/core-design.md) (for gameplay-related proposals).
 
-2. Write your proposal (see [guide to editing docs](../meta/guide-to-editing-docs.md)).
+4. Write your proposal (see [guide to editing docs](../meta/guide-to-editing-docs.md)).
 
-3. When you are ready for your proposal to be reviewed, make a pull request.
+5. When you are ready for your proposal to be reviewed, make a pull request.
 
-4. Your proposal is approved when a maintainer merges it. This is a green light for you or someone else to go ahead and implement it. A maintainer will then link your proposal to the side bar. *Note to maintainers: edit `src/SUMMARY.md`*
+6. Your proposal is approved when a maintainer merges it. This is a green light for you or someone else to go ahead and implement it. A maintainer will then link your proposal to the side bar. *Note to maintainers: edit `src/SUMMARY.md`*
 
 ``` admonish tip "Unfinished Proposals"
 If you don't think that your proposal is ready for maintainer scrutiny, but still want feedback on it you can PR it as a draft. Drafts are less likely to attract people looking to get down to brass tacks, but still let people comment and give advice.
@@ -44,7 +46,7 @@ A good rule of thumb if the new feature or rework you have in mind would require
 No idea! What design proposals do or do not get in is determined by maintainer approval like normal PRs. If you can get at least one maint to decide that it sounds like a good idea then there's a good chance that it will get accepted. Pretty much any idea is going to need at least some critiquing before it gets merged so don't get discouraged!
 
 ``` admonish tip "Design Principles"
-If you want to improve your chances, it's recommended that you read the [SS14 Fundamental Design Principles](./feature-proposals/ss14-fundamental-design-principles.md) document to get a high-level overview before you start writing, as it'll provide context for why things are the way they are.
+If you want to improve your chances, it's recommended that you read the [SS14 Core Design Documentation](/src/en/space-station-14/core-design.md) document to get a high-level overview before you start writing, as it'll provide context for why things are the way they are.
 
 PR'd design documents should also follow the [Decorum Guidelines](./feature-proposals/expected-feature-proposal-decorum.md).
 ```

src/en/general-development/feature-proposals/expected-feature-proposal-decorum.md

@@ -8,7 +8,7 @@
 
 Any documents proposed:
 
-- Should conform to the basic [SS14 Game Design Principles](./ss14-fundamental-design-principles.md) as well as this document obviously.
+- Should conform to the basic [Core Game Design](/src/en/space-station-14/core-design.md) as well as this document obviously.
 - Should contain sufficient justification for their existence,
 - Can be closed or drafted at maintainer discretion,
 - Are a reflection of SS14 to others that may be interested in how the game is designed. Take note of that.

src/en/proposals/notafet-atmos.md

@@ -12,7 +12,7 @@ Most atmos players currently agree that atmos is not very fun to play, for some
 
 2. Atmos can't actually rectify atmos problems in a reasonable amount of time. For example, if there actually is a plasma leak, scrubbers typically work too slowly resulting in the plasma inevitably being lit before it can be cleaned up.
 
-3. Atmos techs don't play with the rest of the station, preferring to isolate themselves to produce a funny green gas that is only particularly useful for shuttle bombing. Mechanics like this violate the [fundamental design principles](../general-development/feature-proposals/ss14-fundamental-design-principles.md). While these mechanics shouldn't be removed per-se, more focus should be given to mechanics that increase interactions with the station, like making sure the air is breathable and well-heated.
+3. Atmos techs don't play with the rest of the station, preferring to isolate themselves to produce a funny green gas that is only particularly useful for shuttle bombing. Mechanics like this violate the [fundamental design principles](/src/en/space-station-14/core-design.md). While these mechanics shouldn't be removed per-se, more focus should be given to mechanics that increase interactions with the station, like making sure the air is breathable and well-heated.
 
 ## Proposal
 

src/en/space-station-14/core-design.md

@@ -13,6 +13,25 @@ Questions around Core Game Design should be directed towards the Design Group on
 - Forks and other communities may have different ideas and directions which they want to take the game, which is fine and something we want to encourage!
 - This is primarily intended to serve as a direction for upstream Spacestation 14 development, but forks can use these design documents as a base if they so choose.
 
+
+# What is Spacestation 14?
+ Spacestation 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 features for SS14. When creating features or changing balance you should be actively thinking about how these concepts relate to your design or change. 
+The pillars serve as guideposts for creating a cohesive design for SS14. Further detail about each can be found in: [Design Principles](core-design/principles.md).
+
+## Chaotic
+- 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.
+## Seriously Silly
+- aka "The clown has put space lube all over the halls, armed the station nuke and is throwing cream-pies filled with acid at security officers", a situation like this on its face is completely ludicrous but should be taken seriously by players.
+## Dynamic Environment
+- The gameworld should be malleable, letting players build, deconstruct, or modify anything. It should be *possible* to build an entire separate station and continue the round there if players put in the effort.
+## 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. Systems should interact with each other as much as feasible to create new emergent gameplay opportunities.
+## Player Interaction/Agency
+- Players should be encouraged to interact with each other as much as possible to create opportunities for conflict or cooperation. Mechanics should reinforce the player's ability to make impactful decisions while mitigating those decisions' effects on the agency of other players.
+
  ## Categories:
- - [Gameplay Pillars](core-design/pillars.md)
+ - [Design Principles](core-design/principles.md)
  - [Antagonists](core-design/antagonists.md)

src/en/space-station-14/core-design/principles.md

@@ -0,0 +1,69 @@
+```admonish warning "Attention: WIP!"
+This doc is actively under development and is not fully complete. Things may change!
+```
+
+# Design Principles
+Here we go into more detail about each of SS14's Core Desgin Pillars breaking them down further into design principles. Once again these are not hard requirements, but expect to recieve heavy scruitiny on your design if you aren't following these. 
+
+## Chaos
+
+The inherent complexity of Space station 14's sandbox combined with the unpredictabiltiy of human players creates a truely chaotic environment where anything can happen. This should be embraced when designing mechanics to fit SS14, especially with regards to giving players opertunities 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 plently of opertunities for players to intentionally or unintentionally screw up while interacting with your mechanic.
+
+It's also important to differentiate between potential chaos and guarunteed chaos. Mechanics should generally introduce potential chaos in the form of the choices players make while interacting with them. Mechanics that guaruntee a chaotic situation will always occur should be avoid since this negatively impacts 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 it's heart is a horror comedy: on one hand you have a souless megacorp that cares nothing of 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 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 a 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 occured 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 being a horror comedy, then SS14's soul is 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 indepth atmospheric and power simulation. 
+
+Part of the unique experience of Spacestation 14 is interacting with its indepth 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 realisticly 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/mechanic will interact with them. Inter-connected systems also help create more opertunties 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 player's 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**.
+