-
Notifications
You must be signed in to change notification settings - Fork 166
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Setup templates for department design docs (#230)
Added design doc templates for department design docs and added a description for what a department is in the department doc
- Loading branch information
Showing
20 changed files
with
374 additions
and
58 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
# Accessibility | ||
|
||
```admonish warning "Attention: Placeholder!" | ||
This section is a placeholder, pending a design-doc being created by the related work-group | ||
``` | ||
``` | ||
|
||
# Accessibility |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
# Admin Tooling | ||
|
||
```admonish warning "Attention: Placeholder!" | ||
This section is a placeholder, pending a design-doc being created by the related work-group | ||
``` | ||
``` | ||
|
||
# Admin Tooling |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
# Character/Species | ||
|
||
```admonish warning "Attention: Placeholder!" | ||
This section is a placeholder, pending a design-doc being created by the related work-group | ||
``` | ||
``` | ||
|
||
# Character/Species |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
# Combat | ||
|
||
```admonish warning "Attention: Placeholder!" | ||
This section is a placeholder, pending a design-doc being created by the related work-group | ||
``` | ||
``` | ||
|
||
# Combat |
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,19 @@ | ||
```admonish warning "Attention: Work in Progress!" | ||
This section is a work in progress, additional detail will be added | ||
``` | ||
|
||
# Departments | ||
|
||
```admonish warning "Attention: Placeholder!" | ||
This section is a placeholder, pending a design-doc being created by the related work-group | ||
``` | ||
a department is a series of tubes | ||
Departments are categories that represent a specific type of gameplay. Each department has a clear area of relevance, for example: Engineering's gameplay focuses primarily on maintenance, repair and construction while security focuses on maintaining station order and responding to threats to the station/crew. | ||
|
||
|
||
|
||
## Gameplay Fantasy/Role | ||
|
||
Departments have a clear "fantasy" when it comes to gameplay, for engineering this might be working as an engineer and solving practical problems related to the powergrid while for service it might be running a texas style bar on the frontiers of space, serving drinks and racking your shotgun at troublemakers. | ||
|
||
## Department Mechanics | ||
|
||
A department's core mechanics should reinforce/enable this fantasy while also allowing for fun interactions with other departments and players. Each department has it's own design doc complete with gameplay pillars to outline what sort of gameplay is the focus of that department. | ||
|
||
There can be some level of overlap between game mechanics between departments (such as with medical treatments), but a department-specific mechanic should primarily be interacted with by players of that department during regular gameplay. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,43 @@ | ||
# Atmos | ||
|
||
```admonish warning "Attention: Placeholder!" | ||
This section is a placeholder, pending a design-doc being created by the related work-group | ||
``` | ||
``` | ||
|
||
# Atmos | ||
The life-blood of the station | ||
|
||
## Concept | ||
> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game. | ||
## 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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,44 @@ | ||
# Cargo/Salvage | ||
|
||
```admonish warning "Attention: Placeholder!" | ||
This section is a placeholder, pending a design-doc being created by the related work-group | ||
``` | ||
``` | ||
|
||
# Cargo/Salvage | ||
~~cargonia~~ shipping and receiving | ||
|
||
|
||
## Concept | ||
> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game. | ||
## 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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,43 @@ | ||
# Command | ||
|
||
```admonish warning "Attention: Placeholder!" | ||
This section is a placeholder, pending a design-doc being created by the related work-group | ||
``` | ||
``` | ||
|
||
# Command | ||
the ~~highly incomponent~~ people in charge | ||
|
||
## Concept | ||
> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game. | ||
## 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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,43 @@ | ||
# Engineering | ||
|
||
```admonish warning "Attention: Placeholder!" | ||
This section is a placeholder, pending a design-doc being created by the related work-group | ||
``` | ||
``` | ||
|
||
# Engineering | ||
The powerhouse of the ~~cell~~ station | ||
|
||
## Concept | ||
> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game. | ||
## 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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,43 @@ | ||
# Medical | ||
|
||
```admonish warning "Attention: Placeholder!" | ||
This section is a placeholder, pending a design-doc being created by the related work-group | ||
``` | ||
``` | ||
|
||
# Medical | ||
Responsible for causing patient's skeletons to disappear | ||
|
||
## Concept | ||
> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game. | ||
## 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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,43 @@ | ||
# Science | ||
|
||
```admonish warning "Attention: Placeholder!" | ||
This section is a placeholder, pending a design-doc being created by the related work-group | ||
``` | ||
``` | ||
|
||
# Science | ||
THE SCIENCE TEAM | ||
|
||
## Concept | ||
> A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game. | ||
## 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. |
Oops, something went wrong.