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 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.
@@ Line 5: / Line 5: @@
 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
+* Later, because while <code>unitdefs_post</code> solved the former problem, the models existed, and provided some, albeit 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.
@@ Line 34: / Line 34: @@
 = 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.
-## Animated parts should be empties, with the swappable visual models parented to those empties.
 ## Weapons and important abilities are emissive and color coded; some may be animated
 # Every module is visually represented on the model.
@@ Line 52: / Line 51: @@
 ## 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.
-|}