Editing User:Anarchid/OmniCommanderDesign

This is my attempt to figure out a design for an unified commander chassis.

= Why =

Historically ZK has had several commander chassis to provide variety for a bunch of reasons:
* Initially it was the only way to provide commander variety (because procedural generation of unitdefs was not available)
* Later, because while <code>unitdefs_post</code> solved the former problem, the models existed, and provided some, albeit limited, visual feedback on what the commander was 
* Even later, as commanders became mostly "dynamic", for the same legacy reasons
* No model that would display more useful information than the current system exists.

This is bad for several reasons:
* Significantly initially different chassis are pregame RPS in several situations - such as Recon commander's jump available at level zero, or Support commander's build range
* This provides useful visual representation only for one important commander ability - jump - while all other abilities are essentially hidden. Especially guns all look exactly alike.

= Design Design  = 
Before approaching the design of this thing, it is useful to approach the design of designing this thing.

# As with current commander design requirements, this design should not have degenerate, overpowered or useless paths.
#* Commanders should not be significantly stronger than same fair cost in units at any point, but should not be that much worse either
#* A single build or a series of builds should not be always better than the others
#* It's also a good idea to avoid as much lock-in as possible; branching systems that prohibit modules further down the line are boring (but "this module goes in the helmet slot, which is already occupied" is fine).
# For a transition from chassis to modules entirely, the first level-up should be important enough to encompass all of the variety in current chassis and first-morph modules
#* A significant part of this is chassis passive bonuses and specialization - there should be modules to imitate this
#* With the following criterion, this also means that the first morph should make commanders very *visibly* different as well.
# As much interesting information about the commander as possible should be meaningfully visible on the commander body.
#* This intrinsically suggests tying commander modules to their respective body parts, and maybe even have body part based equipment slots
#* Current stackable or weapon modules are insufficient to encompass this. A "subsystem module" approach like in Aquanim's draft may be useful.
#* The important qualitatively difference items should take priority. Guns and jump ability are first tier; everything else is secondary or tertiary.
# The technical considerations of the omni-commander model should be considered at every step 
#* The model should be reasonably easy to modify and generally as low-maintenance as possible
#* Replacement or refund of current commander skins should be considered and made as easy as possible 
#* Additional types of "hats" could be considered

= General Stuff = 
# The omni-commander model  is at least partially an atlas/lego system. The texture provides various materials to be splatted onto various geometry bits, with few of it strictly dedicated (except for core geometry). Weapons have their own dedicated mini-zones and can share materials.
## Weapons and important abilities are emissive and color coded; some may be animated
# Every module is visually represented on the model.
## Important modules are called **subsystems** and take equipment **slots**. They completely take over a given body part, and more than one module cannot use the same body part. Advanced versions of a subsystem can replace a weaker version. The following slots are available:
### Head (helmet, crown, antenna, etc) - intel, aura abilities like shield, cloaker, radar
### Chest (torso front, breastplate, etc) - armor, regeneration
### Forearms (left, right) or whole arms - weapons. These should be huge and prominent as the most important things ever.
### Shoulders (left, right) - secondary weapons, construction abilities
### Back - active abilities (jump, float?)
### Legs - passive movement-related abilities (jump? climb? hover? goomba stomp?).
## Subsystem module _choices_ in the UI have to somehow show which slot they occupy 
## Stackable modules, as much as they exist, are represented as small bits on or near the things they affect.
### Armor modules - rivets or small plates on chest
### Damage modules  - small glowy bits on upper arms
### Speed modules - small bits on upper/lower legs
### .. etc
## Stackable module choices need to show their stacking limits in the UI.
## Enhancement modules are treated as new modules. E.g. a longer-stun version of a lightning gun simply has a different lightning gun model.

= Draft Bucket List Of Modules = 

{| class="wikitable sortable" style="text-align: center"
! Name 
! Type
! Slot
! Level 
! scope="col" class="unsortable" | Description
! scope="col" class="unsortable" | Comments
|-
! Jetpack
| System
| Back
| 1
| Allows commander to jump
| Large, bulky, visible
|-
! Beam Laser
| Weapon
| Arm
| 1
| Kills things
| Long teal/blue emissive line along top
|-
! Combat Drone Kit
| System
| Back
| 2
| Launches Fireflies
| Moving mechanical stuff. Possibly can also dock drones if drone tech advances? 
Conflicts with jump, but not with shield/cloak.
|-
! Personal Shield
| System
| Head
| 2
| Provides a small shield
| Crown that reminds an Aspis. Incompatible with cloak.
|-
! Personal Cloak
| System
| Head
| 2
| Cloaks commander
| Teal glowing halo, like Scythe/Iris backpacks. Incompatible with shield.
|-
! Advanced Nanolathe
| System
| Shoulder
| 1
| More nano range, slightly more build power
| Replaces default nano, bigger. 
|}