Editing User:Anarchid/OmniCommanderDesign
Jump to navigation
Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
− | |||
− | |||
− | |||
− | |||
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 | + | * Later, because while `unitdefs_post`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 | * 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 11: | Line 7: | ||
This is bad for several reasons: | 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 | * 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. | + | * This provides useful visual representation only for one important commander ability - jump - while all other abilities are essentially hidden. |
+ | |||
+ | This is my attempt to figure out a design for an unified commander chassis. That requires the model problem to be solved, but fortunately, models are not primordial words of god; they can be made just like the current four models were. | ||
= Design Design = | = Design Design = | ||
Line 17: | Line 15: | ||
# As with current commander design requirements, this design should not have degenerate, overpowered or useless paths. | # As with current commander design requirements, this design should not have degenerate, overpowered or useless paths. | ||
− | + | # For 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 | |
− | + | ## With the following criterion, this also means that the first morph should make commanders very *visibly* different as well. | |
− | |||
− | # For | ||
− | # | ||
− | # | ||
# As much interesting information about the commander as possible should be meaningfully visible on the commander body. | # 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 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 |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |