I'm not expecting to add any
strict stop to fire in the near future. I thought about it for Badger somewhat recently but decided that the model did not support it. This is the first issue:
-
A unit that stops to fire should look like it needs to, in the geometry of the model, and look distinct when it has stopped to fire.
Fencer stows its missile launcher when moving, Emissary has a pretty long gun, and Tremor unpacks and repacks its gun. These aren't the most informative animations, but these units stopping to fire is still much more plausible than the hovering and un-animatable Lance, or wheels and tiny gun of Badger. I think my standards may have also been raised, as I put a lot of work into selling the necessity of Bulkhead stopping to fire.
What about non-strict implementations, some sort of slowdown or penalty related to firing. Ronin used to slow down when reloading. I had it sort of 'hug' its rocket launcher to its chest to indicate that some state change had occurred. I removed the mechanic because it is a bit annoying to use and became unnecessary. Non-strict implementation can be annoying and also run into the visual language problem. Lance in particular seems like it would need a remodel to sell such a change, since it is permanently hovering and doesn't have that much scope for animation.
There are two ways to implement the control scheme for stop- or slow-to-fire.
-
1) Movement override auto attack. Units ignore targets when told to move somewhere. This is currently in use by the four stop-to-fire units.
-
2) Auto-attack interferes with movement. Units automatically target unless set to hold fire. This is what Ronin did.
Option (1) has the potential for stutter step micro, which is reduced by increasing unpack/pack time and decreasing reload times, so that all movement costs DPS. Otherwise, I quite like Option (1) because it lets players retain a lot of control. Option (2) has the issue of encouraging people to micromange unit states to make their units retreat at full speed. I don't see a good way to mitigate this issue. I really don't want people to have to touch state toggles in normal battles as I think it is an unsatisfying form of micromanagement.
The cost of firing has to be high to do Option (1) without introducing a lot of stutter step micro, hence its use for strict stop-to-fire. If we can't do strict stop-to-fire then we've got to go with Option (2), but I don't know a way around its drawbacks. In this situation I would rather tweak problematic artillery before doing Option (2).
Maybe we can come up with some new forms of movement penalty that solve these issues. Maybe small penalties would not noticeably cause these issues. The lack of visual justification and communication for the mechanic is still an issue though, so I'd want to have some plan for a model change after an experiment.
