| 1 |
This discussion has conflated two similar topics:
|
1 |
This discussion has conflated two similar topics:
|
| 2 |
1. Players coding their own UI.
|
2 |
1. Players coding their own UI.
|
| 3 |
2. Automation.
|
3 |
2. Automation.
|
| 4 |
There is also the extra topic of RTS AI.
|
4 |
There is also the extra topic of RTS AI.
|
| 5 |
\n
|
5 |
\n
|
| 6 |
\n
|
6 |
\n
|
| 7 |
The first topic is a messy one. Coding your own UI has the potential to become an issue but it does not seem to be an issue at the moment. The "pure design philosophy" of ZK does not prevent local widgets but in practice issues could arise. If it became an issue we could block local widgets (or make a modoption). This would be circumventable but with some difficulty. Those people would know what they are doing so we could happily label them as cheaters. Local widgets are currently allowed for a few reasons:
|
7 |
The first topic is a messy one. Coding your own UI has the potential to become an issue but it does not seem to be an issue at the moment. The "pure design philosophy" of ZK does not prevent local widgets but in practice issues could arise. If it became an issue we could block local widgets (or make a modoption). This would be circumventable but with some difficulty. Those people would know what they are doing so we could happily label them as cheaters. Local widgets are currently allowed for a few reasons:
|
| 8 |
* ZK is designed to not be trivialized by automation.
|
8 |
* ZK is designed to not be trivialized by automation.
|
| 9 |
* Players effectively do developer work by writing useful widgets.
|
9 |
* Players effectively do developer work by writing useful widgets.
|
| 10 |
* Players tend to share useful widgets that they have written.
|
10 |
* Players tend to share useful widgets that they have written.
|
| 11 |
* Nobody seems to have exploited the current trust based system.
|
11 |
* Nobody seems to have exploited the current trust based system.
|
| 12 |
* Few people have complained and not loudly.
|
12 |
* Few people have complained and not loudly.
|
| 13 |
\n
|
13 |
\n
|
| 14 |
One fairly recent example is the Newton launcher widget. Someone made a widget which semi-automated Newton launchers, increased fire rate and made them reliable. They shared the widget and so, with slight usability improvements, I included it in ZK. Newtons now have a command which sets a fire-zone in which they will launch any unit which enters.
|
14 |
One fairly recent example is the Newton launcher widget. Someone made a widget which semi-automated Newton launchers, increased fire rate and made them reliable. They shared the widget and so, with slight usability improvements, I included it in ZK. Newtons now have a command which sets a fire-zone in which they will launch any unit which enters.
|
| 15 |
\n
|
15 |
\n
|
| 16 |
I understand the main argument against local widgets; that using different UIs introduces unfairness. For example the unit AI in ZK could be a lot better so there is potential for someone to develop a widget which gives them a significant advantage over other players. This is a good thing if they share their widget (because it would be included in ZK) but unfair if they keep it to themselves. It would still be annoying to lose against the widget while it is still under development (not yet released) so perhaps there could be blocked widget modes. More competitive matches could have blocked widgets while other matches allowed people to test and develop their widgets.
|
16 |
I understand the main argument against local widgets; that using different UIs introduces unfairness. For example the unit AI in ZK could be a lot better so there is potential for someone to develop a widget which gives them a significant advantage over other players. This is a good thing if they share their widget (because it would be included in ZK) but unfair if they keep it to themselves. It would still be annoying to lose against the widget while it is still under development (not yet released) so perhaps there could be blocked widget modes. More competitive matches could have blocked widgets while other matches allowed people to test and develop their widgets.
|
| 17 |
\n
|
17 |
\n
|
| 18 |
My current stance towards powerful user widgets is to include them. I am not worried that such a widget would break gameplay because I have not seen any sufficiently powerful user widget. Automation widgets tend to highlight areas of ZK which should be automated, they don't tend to remove choices and if they did I would consider it a flaw in ZK rather than a widget to be blocked.
|
18 |
My current stance towards powerful user widgets is to include them. I am not worried that such a widget would break gameplay because I have not seen any sufficiently powerful user widget. Automation widgets tend to highlight areas of ZK which should be automated, they don't tend to remove choices and if they did I would consider it a flaw in ZK rather than a widget to be blocked.
|
| 19 |
\n
|
19 |
\n
|
| 20 |
I am not so sure that ZK and SCII are so different on the interface customization front. There seems to be a lot in SCII hotkeys and tricks to improve your play. Furthermore I don't see drilling your UI interaction in SCII as significantly different to customizing and learning to use the default UI of ZK. Watch this video explaining how to Larvae Inject as if you had a widget to do it: https://www.youtube.com/watch?v=pIbo94IWeu8
|
20 |
I am not so sure that ZK and SCII are so different on the interface customization front. There seems to be a lot in SCII hotkeys and tricks to improve your play. Furthermore I don't see drilling your UI interaction in SCII as significantly different to customizing and learning to use the default UI of ZK. Watch this video explaining how to Larvae Inject as if you had a widget to do it: https://www.youtube.com/watch?v=pIbo94IWeu8
|
| 21 |
\n
|
21 |
\n
|
| 22 |
\n
|
22 |
\n
|
| 23 |
This brings me to the second topic; automation itself. Automation, for me, is there to decrease a tasks Decision:Clicks ratio in order to free players from spending most of their time implementing simple decisions. This gives them time to consider a wider range of (hopefully more interesting) decisions. ZK contains so many decisions that the difficulty of making good decisions rapidly should keep the game from becoming trivial. In theory the aim is for ZK to be able to be carried, as a worthwhile game, by the decisions instead of the clicking.
|
23 |
This brings me to the second topic; automation itself. Automation, for me, is there to decrease a tasks Decision:Clicks ratio in order to free players from spending most of their time implementing simple decisions. This gives them time to consider a wider range of (hopefully more interesting) decisions. ZK contains so many decisions that the difficulty of making good decisions rapidly should keep the game from becoming trivial. In theory the aim is for ZK to be able to be carried, as a worthwhile game, by the decisions instead of the clicking.
|
| 24 |
\n
|
24 |
\n
|
| 25 |
The expected rate of decision making can be very high which I why I do not think combat could be automated (locally). For example say you have a group of Rockos dancing around an enemy army. At any point you could decide to dive the Rockos in and go for a commander kill. Whether you do so depends on factors outside the army; how much their commander is worth at the time, whether your relative armies (across the whole map) mean you can afford to lose the Rockos, what units they may have just outside LOS etc... all weighed up against how likely the dive is to succeed.
|
25 |
The expected rate of decision making can be very high which I why I do not think combat could be automated (locally). For example say you have a group of Rockos dancing around an enemy army. At any point you could decide to dive the Rockos in and go for a commander kill. Whether you do so depends on factors outside the army; how much their commander is worth at the time, whether your relative armies (across the whole map) mean you can afford to lose the Rockos, what units they may have just outside LOS etc... all weighed up against how likely the dive is to succeed.
|
| 26 |
\n
|
26 |
\n
|
| 27 |
Decisions are required even faster during raiding. Should you lose a few raiders to secure a constructor kill? Where are they likely to have placed their raiders? Where are there defenses? Is it worth losing a raider for some extra scouting? Where are they likely to have a Tick? This leads into another aspect; the mind games of reading your opponent. I have no idea how you would communicate these decisions to an advanced raiding unit AI (short of mind reading). State toggles are too slow and lack nuance. The fastest way for a skilled player to implement these decisions is probably already in place; line move and Fight. So I do not think we could reach a point where 'fancy widgets' are playing the game for us.
|
27 |
Decisions are required even faster during raiding. Should you lose a few raiders to secure a constructor kill? Where are they likely to have placed their raiders? Where are there defenses? Is it worth losing a raider for some extra scouting? Where are they likely to have a Tick? This leads into another aspect; the mind games of reading your opponent. I have no idea how you would communicate these decisions to an advanced raiding unit AI (short of mind reading). State toggles are too slow and lack nuance. The fastest way for a skilled player to implement these decisions is probably already in place; line move and Fight. So I do not think we could reach a point where 'fancy widgets' are playing the game for us.
|
| 28 |
\n
|
28 |
\n
|
| 29 |
With automation anyone can set Rocko to fight and have it behave and interact basically like it is supposed to. I like this for a few reasons:
|
29 |
With automation anyone can set Rocko to fight and have it behave and interact basically like it is supposed to. I like this for a few reasons:
|
| 30 |
* New players get to experience an approximation of the balance which high level players experience. There is a dampening on unit power variability with respect to skill level. I am allowed to make stuff like Rocko a core part of the balance because everyone can use it.
|
30 |
* New players get to experience an approximation of the balance which high level players experience. There is a dampening on unit power variability with respect to skill level. I am allowed to make stuff like Rocko a core part of the balance because everyone can use it.
|
| 31 |
* Units can be balanced closer to what would be required if we had super-godly micro players.
|
31 |
* Units can be balanced closer to what would be required if we had super-godly micro players.
|
| 32 |
* The game feels more 'physicsy' when units act closer to their 'true' behaviour and limitations.
|
32 |
* The game feels more 'physicsy' when units act closer to their 'true' behaviour and limitations.
|
| 33 |
* Multiple battlefronts are easier to manage and there is less unevenness between the penalties received for not paying close attention to different unit types. The concept of attacking where your opponents units are temporarily idiots annoys me.
|
33 |
* Multiple battlefronts are easier to manage and there is less unevenness between the penalties received for not paying close attention to different unit types. The concept of attacking where your opponents units are temporarily idiots annoys me.
|
| 34 |
\n
|
34 |
\n
|
| 35 |
[quote]When someone thinks of an RTS game, there are certain traits that come to mind when wanting to improve. These include APM, scouting, expanding, micro, game sense, etc. Zero-K is the only game I can think of where coding is a valid route to improvement (not actually true, see: Robocode). This is not a bad thing in itself, but it is a very foreign concept to most gamers, and it will turn many players off.
|
35 |
[quote]When someone thinks of an RTS game, there are certain traits that come to mind when wanting to improve. These include APM, scouting, expanding, micro, game sense, etc. Zero-K is the only game I can think of where coding is a valid route to improvement (not actually true, see: Robocode). This is not a bad thing in itself, but it is a very foreign concept to most gamers, and it will turn many players off.
|
| 36 |
\n
|
36 |
\n
|
| 37 |
I would argue that automation, and thereby reducing the number of points of skill, results in less choices along with less clicking. Each click is a choice, and the player must handle the hidden resource of time. With less automation, there are more choices to the player regarding where to spend their time. With automation, the player has fewer things to worry about, fewer things that demand their attention, and therefore, fewer "choices" to make with regard to their time. The remaining choices are relatively high-level and hopefully more interesting, and the player can focus on these choices more thanks to automation. [/quote]As written in the first section I somewhat agree with the coding point. I disagree with most of the last paragraph.
|
37 |
I would argue that automation, and thereby reducing the number of points of skill, results in less choices along with less clicking. Each click is a choice, and the player must handle the hidden resource of time. With less automation, there are more choices to the player regarding where to spend their time. With automation, the player has fewer things to worry about, fewer things that demand their attention, and therefore, fewer "choices" to make with regard to their time. The remaining choices are relatively high-level and hopefully more interesting, and the player can focus on these choices more thanks to automation. [/quote]As written in the first section I somewhat agree with the coding point. I disagree with most of the last paragraph.
|
| 38 |
\n
|
38 |
\n
|
| 39 |
Automation does not necessarily reduce the number of different skills required for a game. If micromanagement was the main defining skill of a game (and it is for non-top SCII players) then reducing that micromanagement lets other aspects of the game rise in importance. By "defining skill" I mean the one which would yield the most improvement if practiced. Also by "micromanagement" I include many tasks referred to as 'macro' in SCII. I also do not think it reduces the total required skill because there always seems to be higher level things to manage once the burden of lower level micro is eased.
|
39 |
Automation does not necessarily reduce the number of different skills required for a game. If micromanagement was the main defining skill of a game (and it is for non-top SCII players) then reducing that micromanagement lets other aspects of the game rise in importance. By "defining skill" I mean the one which would yield the most improvement if practiced. Also by "micromanagement" I include many tasks referred to as 'macro' in SCII. I also do not think it reduces the total required skill because there always seems to be higher level things to manage once the burden of lower level micro is eased.
|
| 40 |
\n
|
40 |
\n
|
| 41 |
I also do not think automation reduces choices. It does not even reduce choices about where to spend your time. For example consider you have a long list of choices about where to spend the next 10 seconds. One of the items is:
|
41 |
I also do not think automation reduces choices. It does not even reduce choices about where to spend your time. For example consider you have a long list of choices about where to spend the next 10 seconds. One of the items is:
|
| 42 |
* Manage a battle. This would make the battle be a fairly even trade. Failing to manage the battle causes my army to be destroyed easily and an eventual loss of the game.
|
42 |
* Manage a battle. This would make the battle be a fairly even trade. Failing to manage the battle causes my army to be destroyed easily and an eventual loss of the game.
|
| 43 |
This
option
is
quite
conceivably
much
more
urgent
than
everything
else
on
the
list.
This
choice
makes
the
other
choices
on
your
list
unviable.
You
have
to
manage
the
battle
or
lose.
Now
consider
the
case
where
the
expected
payoff
of
managing
the
battle
is
more
in
line
with
the
other
choices.
Suddenly
there
is
no
obvious
place
to
spend
your
time
so
the
choice
becomes
a
lot
harder.
|
43 |
This
option
is
quite
conceivably
much
more
urgent
than
everything
else
on
the
list.
This
choice
makes
the
other
choices
on
your
list
unviable.
You
have
to
manage
the
battle
or
lose.
Now
consider
the
case
where
the
expected
payoff
of
managing
the
battle
is
more
in
line
with
the
other
choices.
Managing
the
battle
might
yield
a
bit
of
efficiency
and
focus
fire
on
the
unit
types
which
you
currently
want
your
opponent
to
not
have.
This
is
some
benefit
but
it
is
not
an
overwhelming
payoff
like
"Don't
lose
the
game".
Suddenly
there
is
no
obvious
place
to
spend
your
time
so
the
choice
becomes
a
lot
harder.
|
| 44 |
\n
|
44 |
\n
|
| 45 |
I understand that this system works in SCII because players are supposed to spend (say) 90% of their attention managing the battle and have a very hard choice regarding their remaining 10% of attention. This system locks players out of this decision making until they have the skill to make the battle take less than 100% of their attention. Also, perhaps SCII needs this system because all the other choices would sum to less than 100% attention for a highly skilled player. Then the battle choice provides pressure to make the time choice meaningful (I don't know, just a possibility). Regardless, I do not see that automation reduces time choices in general because there may still be many things demanding your time. If automation makes the Attention:Urgency ratio closer to uniform then it should actually increase the difficulty of the choice.
|
45 |
I understand that this system works in SCII because players are supposed to spend (say) 90% of their attention managing the battle and have a very hard choice regarding their remaining 10% of attention. This system locks players out of this decision making until they have the skill to make the battle take less than 100% of their attention. Also, perhaps SCII needs this system because all the other choices would sum to less than 100% attention for a highly skilled player. Then the battle choice provides pressure to make the time choice meaningful (I don't know, just a possibility). Regardless, I do not see that automation reduces time choices in general because there may still be many things demanding your time. If automation makes the Attention:Urgency ratio closer to uniform then it should actually increase the difficulty of the choice.
|
| 46 |
\n
|
46 |
\n
|
| 47 |
\n
|
47 |
\n
|
| 48 |
I would like an AI competition. It should at least give us some more AIs for people to play in singleplayer. It also sounds fun to play.
|
48 |
I would like an AI competition. It should at least give us some more AIs for people to play in singleplayer. It also sounds fun to play.
|
Automation tools