User:Anarchid/OmniCommanderDesign - Revision history

Darloth3: animated parts should be empties

2019-03-20T14:10:09Z

animated parts should be empties

213.35.139.72: /* Why */

2019-01-24T12:25:38Z

Why

Anarchid at 15:15, 28 December 2018

2018-12-28T15:15:54Z

Anarchid at 14:55, 28 December 2018

2018-12-28T14:55:19Z

213.35.139.72: /* Design Design */ a

2018-12-28T12:39:24Z

Design Design: a

213.35.139.72: shift radix

2018-12-28T11:37:45Z

shift radix

Anarchid at 15:48, 27 December 2018

2018-12-27T15:48:48Z

Anarchid: init

2018-12-27T15:40:04Z

init

New page

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 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.

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 =
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.
# 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.
# 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

@@ 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.
 ## Weapons and important abilities are emissive and color coded; some may be animated
 # Every module is visually represented on the model.

← Older revision		Revision as of 15:15, 28 December 2018
Line 51:		Line 51:
	## 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.
		+
		+	= 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.
		+	\|}

@@ Line 21: / Line 21: @@
 #* 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
 #* 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.

@@ Line 20: / Line 20: @@
 #* 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 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
+# 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
 #* 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.

← Older revision		Revision as of 11:37, 28 December 2018
Line 30:		Line 30:
	#* Replacement or refund of current commander skins should be considered and made as easy 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		#* 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 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
 * No model that would display more useful information than the current system exists.

@@ Line 1: / Line 1: @@
 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 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 7: / Line 11: @@
 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.
+* 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  =
@@ Line 15: / Line 17: @@
 # 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.
+#* 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
+#* 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.
+#* 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 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
+#* 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
+#* Replacement or refund of current commander skins should be considered and made as easy as possible
-## Additional types of "hats" could be considered
+#* Additional types of "hats" could be considered