Difference between revisions of "User:Anarchid/OmniCommanderDesign"

From Zero-K
Jump to navigation Jump to search
(animated parts should be empties)
 
(One intermediate revision by one other user not shown)
Line 5: Line 5:
 
Historically ZK has had several commander chassis to provide variety for a bunch of reasons:
 
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)
 
* 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  
+
* 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
 
* 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.
 
* No model that would display more useful information than the current system exists.
Line 34: Line 34:
 
= General Stuff =  
 
= 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.
 
# 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
 
## Weapons and important abilities are emissive and color coded; some may be animated
 
# Every module is visually represented on the model.
 
# Every module is visually represented on the model.

Latest revision as of 06:10, 20 March 2019

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

Why[edit]

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 unitdefs_post 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[edit]

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

  1. 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).
  2. 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.
  3. 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.
  4. 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[edit]

  1. 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.
    1. Animated parts should be empties, with the swappable visual models parented to those empties.
    2. Weapons and important abilities are emissive and color coded; some may be animated
  2. Every module is visually represented on the model.
    1. 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:
      1. Head (helmet, crown, antenna, etc) - intel, aura abilities like shield, cloaker, radar
      2. Chest (torso front, breastplate, etc) - armor, regeneration
      3. Forearms (left, right) or whole arms - weapons. These should be huge and prominent as the most important things ever.
      4. Shoulders (left, right) - secondary weapons, construction abilities
      5. Back - active abilities (jump, float?)
      6. Legs - passive movement-related abilities (jump? climb? hover? goomba stomp?).
    2. Subsystem module _choices_ in the UI have to somehow show which slot they occupy
    3. Stackable modules, as much as they exist, are represented as small bits on or near the things they affect.
      1. Armor modules - rivets or small plates on chest
      2. Damage modules - small glowy bits on upper arms
      3. Speed modules - small bits on upper/lower legs
      4. .. etc
    4. Stackable module choices need to show their stacking limits in the UI.
    5. 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[edit]

Name Type Slot Level Description 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.