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 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 | + | * 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 | * 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 20: | Line 20: | ||
#* A single build or a series of builds should not be always better than the others | #* 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). | #* 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 | + | # 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. | #* 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. | # As much interesting information about the commander as possible should be meaningfully visible on the commander body. | ||
Line 34: | Line 33: | ||
= 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. | ||
− | |||
## 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. | ||
Line 52: | Line 50: | ||
## Stackable module choices need to show their stacking limits in the UI. | ## 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. | ## Enhancement modules are treated as new modules. E.g. a longer-stun version of a lightning gun simply has a different lightning gun model. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |