| 1 |
|
1 |
|
| 2 |
[quote] Making it dive in against some arbitrary set of targets would also hurt its predictability.[/quote]
|
2 |
[quote] Making it dive in against some arbitrary set of targets would also hurt its predictability.[/quote]
|
| 3 |
Make
it
dive
in
against
everything.
Especially
with
your
point
on
optimality,
I
would
support
just
having
scorcher
diving
in
against
everything
|
3 |
Make
it
dive
in
against
everything.
I
would
support
having
scorcher
just
move
in
on
everything,
and
then
having
the
player
decide
when
or
when
not
to
move
in
|
| 4 |
\n
|
4 |
\n
|
| 5 |
[q]The unit AI is more about being predictable than optimal. Attack Move causes Scorcher to jink around near max range because otherwise there wouldn't be a simple way to tell Scorcher to jink around near max range.[/q]
|
5 |
[q]The unit AI is more about being predictable than optimal. Attack Move causes Scorcher to jink around near max range because otherwise there wouldn't be a simple way to tell Scorcher to jink around near max range.[/q]
|
| 6 |
Move commands are not scalable, and are APM intensive to execute.
|
6 |
Move commands are not scalable, and are APM intensive to execute.
|
| 7 |
There is no simple way to tell scorchers to dive in on every unit. Even in micro situations where it is feasible, it certainly is not simple. It does not help that when you click on the unit, the scorcher switches to its ai, which ruins whatever you were trying to do with it. The existence of the ai itself means that you have to click past whatever unit you are trying to rush, which can make rushing in against fast units really difficult, as when they jink around you have to click PAST where they are, rather than just clicking where they are.
|
7 |
There is no simple way to tell scorchers to dive in on every unit. Even in micro situations where it is feasible, it certainly is not simple. It does not help that when you click on the unit, the scorcher switches to its ai, which ruins whatever you were trying to do with it. The existence of the ai itself means that you have to click past whatever unit you are trying to rush, which can make rushing in against fast units really difficult, as when they jink around you have to click PAST where they are, rather than just clicking where they are.
|
| 8 |
\n
|
8 |
\n
|
| 9 |
[q] If we just had Move then the "rush in" choice would be much cheaper than "keep at max range" in terms of player attention, which would warp tactics space towards it.[/q]
|
9 |
[q] If we just had Move then the "rush in" choice would be much cheaper than "keep at max range" in terms of player attention, which would warp tactics space towards it.[/q]
|
| 10 |
This is already true though. Attack move is not very useful even for its job at keeping max range. For scorcher, the only feasible command really is "move" (when it comes to units at least)
|
10 |
This is already true though. Attack move is not very useful even for its job at keeping max range. For scorcher, the only feasible command really is "move" (when it comes to units at least)
|
| 11 |
\n
|
11 |
\n
|
| 12 |
\n
|
12 |
\n
|
| 13 |
\n
|
13 |
\n
|
| 14 |
[q] If the current Attack Move behavior for Scorcher is rarely useful then it could be tweaked. Perhaps it should jink around a bit closer to its target, to strike a better balance between safety and damage. [/q]
|
14 |
[q] If the current Attack Move behavior for Scorcher is rarely useful then it could be tweaked. Perhaps it should jink around a bit closer to its target, to strike a better balance between safety and damage. [/q]
|
| 15 |
This would be better I suppose, but still not great.
|
15 |
This would be better I suppose, but still not great.
|
| 16 |
\n
|
16 |
\n
|
| 17 |
[quote]With scorchers I do mostly use move command much more than a-move. However, doubling up on their behavior will lose some function, and as GF said, predictability in how units will behave.[/quote]
|
17 |
[quote]With scorchers I do mostly use move command much more than a-move. However, doubling up on their behavior will lose some function, and as GF said, predictability in how units will behave.[/quote]
|
| 18 |
Are you really losing function if you don't even use a-move much? We are "losing function" in the sense that we are ridding of a near worthless a-move, in exchange for an amove that is actually useful, better than move command, and more scalable
|
18 |
Are you really losing function if you don't even use a-move much? We are "losing function" in the sense that we are ridding of a near worthless a-move, in exchange for an amove that is actually useful, better than move command, and more scalable
|
| 19 |
\n
|
19 |
\n
|
| 20 |
\n
|
20 |
\n
|
| 21 |
The general argument that I am seeing here is that the current amove provides some level of functionality that would be lost if a rush-in amove was added. And, that move command can do what a "rush-in amove" can do. It is true that the current amove DOES do something that would not be feasible to do, with its multiple units jinking around. However, the current behavior is just not useful for scorchers. It is evident by the fact that not many people even use amove on scorchers. There would be no effective functionality lost if this ai was changed or removed because it's simply not used. Move commands cannot do what a rush-in a-move can do because move commands are inconsistent, difficult, and only really work on low weights, or against single targets (or single clumps of targets).
|
21 |
The general argument that I am seeing here is that the current amove provides some level of functionality that would be lost if a rush-in amove was added. And, that move command can do what a "rush-in amove" can do. It is true that the current amove DOES do something that would not be feasible to do, with its multiple units jinking around. However, the current behavior is just not useful for scorchers. It is evident by the fact that not many people even use amove on scorchers. There would be no effective functionality lost if this ai was changed or removed because it's simply not used. Move commands cannot do what a rush-in a-move can do because move commands are inconsistent, difficult, and only really work on low weights, or against single targets (or single clumps of targets).
|
| 22 |
\n
|
22 |
\n
|
| 23 |
\n
|
23 |
\n
|
| 24 |
I would support keeping everything as is if the move command wasn't so damn irritating to work with. If there was a "move to this unit" command rather than clicking on a unit entailing amove. Or even if there was a way to just click on a unit and just have it move to that position, as if there was no unit there. I guess I'm also okay with nothing changing at all, and scorcher being gatekept by esoteric micro. I just thought that this is the thing that Zerok is trying to avoid.
|
24 |
I would support keeping everything as is if the move command wasn't so damn irritating to work with. If there was a "move to this unit" command rather than clicking on a unit entailing amove. Or even if there was a way to just click on a unit and just have it move to that position, as if there was no unit there. I guess I'm also okay with nothing changing at all, and scorcher being gatekept by esoteric micro. I just thought that this is the thing that Zerok is trying to avoid.
|
Scorcher amove behavior