PROPOSAL: Weapon & Gun organization by DVD

docs/Proposals/gun-overhaul.md

@@ -0,0 +1,100 @@
+---
+authors: [mqole]
+tags:
+- proposals
+---
+
+# Gun Overhaul
+
+| Designers | Coders | Implemented | GitHub Links |
+|---|---|---|---|
+| DVD Player, mqole | DVD Player, iaada | :x: | TBD |
+
+## Introduction
+
+Guns in SS14 have a medium-high barrier of entry. 
+
+Most guns in game take specific forms of ammunition, some can toggle between different modes, have different stats, most of which are conveyed using the examine menu. However, unless the player has experience with gun terminology, there is a lot of mental overhead required to memorize all of these statistics for each individual entity. Which gun takes shotgun shells, and which gun takes .35 precision ammo? What is the difference between a Drozd and a Lecter? And why do all these guns look so similar?
+
+To ease the learning burden, the design of guns should prioritise:
+- **Glance value.** Visual designs should be distinctive and signal the gun's properties.
+- **Minimal examine text.** Provide only the information that the player needs - no need to focus on the details at first blush.
+- **Distinct categories.** Sorting every gun into player-facing boxes can quickly clue a player in to what to expect from how a gun handles.
+- An optional **advanced stat viewer.** Keep all the numbers and details on a seperate tab so those who are interested in combat can still get into the weeds.
+
+## Sorting Guns
+
+Here is the proposed categorisation system for guns:
+
+### Categories
+
+All guns should fit into exactly one of the following **categories**, determined by the type of ammunition they accept and their general identity.
+
+```mermaid
+flowchart LR
+    A(Ammunition) --> B(Handheld)
+    B --> C["`**Pistol**
+    Small size. Low capacity and damage, but easily concealable.`"]
+    B --> D["`**Revolver**
+    Heavier-hitting than a pistol, but a chore to reload.`"]
+    A --> E(Precision)
+    E --> F["`**Rifle**
+    All-rounder with a focus on accuracy and DPS.`"]
+    E --> G["`**Sniper**
+    Slow rate of fire and low ammo capacity, but hits hard.`"]
+    A --> H(Wide Spread)
+    H --> I["`**Machine Gun**
+    Sacrifices accuracy in favour of a huge magazine capacity.`"]
+    H --> J["`**Shotgun**
+    Shoots several bullets in an arc that fans out.`"]
+    K(Energy) --> L(Lethal)
+    L --> M["`**Laser**
+    Shoots a single beam that goes through glass walls and deals heat damage.`"]
+    L --> N["`**Blaster**
+    Shoots several heat projectiles in an arc that fan out.`"]
+    K --> O(Non-Lethal)
+    O --> P["`**Disabler**
+    Deals stamina damage.`"]
+    Q(Other) --> R["`**Launcher**
+    Loadable with explosives. Slow fire rate.`"]
+    Q --> S["`**Fuel**
+    Loadable with reagents.`"]
+    Q --> T["`**Special**
+    Anything that doesn't fall into one of the other categories.`"]
+```
+
+### Qualities
+
+From this base category system, each gun then has two *qualities*. Qualities should give a general overview of the gun's unique characteristics, and serve as an at-a-glance description of the gun's stats. For example:
+
+- An Mk 58 as a *balanced*, *back-up* **pistol**
+  - Generally balanced stats, but more of a sidearm than a main weapon
+- A Drozd as a *rapid-fire* **machine gun**
+  - Extremely fast rate of fire
+- An Enforcer as a *wide-spread*, *balanced* **shotgun**
+  - Balanced stats, and fans bullets out in a wide arc to increase area of effect
+- A China Lake as an *aggressive*, *demolition* **launcher**
+  - It's scary, and it will explode things
+- A Kammerer as a *precision* **shotgun**
+  - A smaller arc of bullets makes it harder to hit a target, but those bullets do more damage
+- A Musket as a *precision* *haymaker* **sniper**
+  - Heavy hitting ammo, and it doubles as a melee weapon
+
+While **categories** are static identifiers that exist to denote a gun's accepted ammunition and general purpose, *qualities* are more flexible and subjective. These two systems of categorisation combine to provide a lot more glance value to guns.
+
+Categories and qualities should be **player-facing**. This may be done through highlighted examine text, or some other means. The priority is ensuring that players are able to quickly recognize and understand a gun's function.
+
+Visual design of guns should also be considered. Gun sprites and designs should intuitively convey to players the gun's category and some signifier of its qualities or overall identity.
+
+It's vital to note that categories are intended to **intuitively provide information to players**. As such, subverting these categories (by designing a rifle which has the functions of a shotgun, for example) is confusing and muddies the information this system intends to provide. This kind of subversion of categories should be avoided as a general rule.
+
+## File Structure
+
+In order to comprehensively organize all the gun entities in the game, the YAML entity files will need to be cleaned up as follows:
+
+- A file `base-guns.yml` containing base entities (eg. `BasePistol`, `BaseShotgun`) for each gun category.
+  - The base entities should be parented from `BaseItem` and given a 'baseline' indication of what that gun's average stats are in terms of reload speed, fire rate, ammo capacity, etc.
+- Individual files (`pistols.yml`, `shotguns.yml`, etc.) for each category containing all the gun entities that fit that category.
+  - In these files, users may also define additional base prototypes in order to create guns which have a shared identity but differ in aesthetics- for example, creating entity `BasePistolLight` in `pistols.yml`, which becomes the parent of both `WeaponGunMk58` and `WeaponGunViper`.
+
+These new entities may be selectively overwritten by downstreams of Macrocosm. It may be useful to use a naming scheme such as `MACROGunViper` to ease the process of editing Macrocosm entities.

docs/Proposals/template.md

@@ -0,0 +1,67 @@
+This is the Wizard's Den feature proposal template. If you wish to PR a feature proposal or design document, consider following this template.
+
+# Short, Properly Capitalized Title
+
+Your title should convey the basic jist of your proposed changes. It should be short because the text will be linked in the sidebar.
+
+| Designers | Coders | Implemented | GitHub Links |
+|---|---|---|---|
+| your names here | coder names here | :white_check_mark: Yes or :warning: Partially or :information_source: Open PR or :x: No | PR Links or TBD |
+
+`Designers` should be the names that you, the authors of this document, use on GitHub and/or Discord. This is optional but strongly recommended, since:
+
+- This acknowledges credit where it is due
+- People who are confused about the written intent can use this information to contact the authors
+
+`Coders` should be the names of the contributors who plan on implementing this feature. To get a design doc approved you will need either
+- have the technical knowledge to be able to implement the proposed feature yourself.
+- have someone else who agreed to do this for you.
+- already have an existing implementation elsewhere that just needs to be ported.
+
+In either case you will have to write an outline on how you plan to implement this feature in the **Technical Considerations** section to show that is technically sound and feasible.
+
+`Implemented` is the status of the feature.
+
+Github links can include multiple PRs, if relevant.
+
+## Overview
+
+A very short, maybe three sentence summary of what this proposal is about. A high level "overview" or "what this adds".
+
+## Background
+
+Summarize any information that is needed to contextualize the proposed changes, e.g. the current state of the game.
+
+Also link any relevant discussions on Discord, GitHub, or HackMD that are relevant to the proposal.
+
+## Features to be added
+
+Give a description of what game mechanics you would like to add or change. This should be a general overview, with enough details on critical design points that someone can directly implement the feature from this design document. Exact numbers for game balance however are not necessary, as these can be adjusted later either during development or after it has been implemented, but mention *what* will have to be balanced and what needs to be considered when doing so.
+
+## Game Design Rationale
+
+Consider addressing:
+- How does the feature align with our [Core Design Principles](https://docs.spacestation14.com/en/space-station-14/core-design/design-principles.html) and game philosphy?
+- What makes this feature enjoyable or rewarding for players?
+- Does it introduce meaningful choices, risk vs. reward, or new strategies?
+- How does it enhance player cooperation, competition, or emergent gameplay?
+- If the feature is a new antagonist, how does it fit into the corresponding [design pillars](https://docs.spacestation14.com/en/space-station-14/round-flow/antagonists.html)?
+
+## Roundflow & Player interaction
+
+Consider addressing:
+- At what point in the round does the feature come into play? Does it happen every round? How does it affect the round pace?
+- How do you wish for players to interact with your feature and how should they not interact with it? How is this mechanically enforced?
+- Which department will interact with the feature? How does the feature fit into the [design document](https://docs.spacestation14.com/en/space-station-14/departments.html) for that department?
+
+## Administrative & Server Rule Impact (if applicable)
+
+- Does this feature introduce any new rule enforcement challenges or additional workload for admins?
+- Could this feature increase the likelihood of griefing, rule-breaking, or player disputes?
+- How are the rules enforced mechanically by way the feature will be implemented?
+
+# Technical Considerations
+
+- Does the feature require new systems, UI elements, or refactors of existing ones? Give a short technical outline on how they will be implemented.
+- Are there any anticipated performance impacts?
+- For required UI elements, give a short description or a mockup of how they should look like (for example a radial menu, actions & alerts, navmaps, or other window types)

docs/tags.yml

@@ -12,7 +12,7 @@ microcosms:
   label: 'Microcosms'
   permalink: '/microcosms'
   description: 'Members of Macrocosm.'
-  
+
 proposals:
   label: 'Proposals'
   permalink: '/proposals'