| 1 |
I'm not expecting to add any [b]strict[/b] 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:
|
1 |
I'm not expecting to add any [b]strict[/b] 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:
|
| 2 |
* 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.
|
2 |
* 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.
|
| 3 |
\n
|
3 |
\n
|
| 4 |
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.
|
4 |
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.
|
| 5 |
\n
|
5 |
\n
|
| 6 |
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.
|
6 |
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.
|
| 7 |
\n
|
7 |
\n
|
| 8 |
There are two ways to implement the control scheme for stop- or slow-to-fire.
|
8 |
There are two ways to implement the control scheme for stop- or slow-to-fire.
|
| 9 |
* 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.
|
9 |
* 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.
|
| 10 |
* 2) Auto-attack interferes with movement. Units automatically target unless set to hold fire. This is what Ronin did.
|
10 |
* 2) Auto-attack interferes with movement. Units automatically target unless set to hold fire. This is what Ronin did.
|
| 11 |
\n
|
11 |
\n
|
| 12 |
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.
|
12 |
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.
|
| 13 |
\n
|
13 |
\n
|
| 14 |
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).
|
14 |
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).
|
| 15 |
\n
|
15 |
\n
|
| 16 |
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.
|
16 |
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.
|
[discussion] Artillery fires while moving