| 1 |
Save me some time and read https://zero-k.info/Forum/Thread/31189?postID=219329#219329 as it is mostly what I'd be writing here. In retrospect I came across a bit harsh there and we may even have had a player widget turn into a game widget in the year and a half since that post. Prefire was eventually solved by a combination of redesigning Kodachi and @esainane digging up (and fixing in-engine) an obscure weapon tag that let units fire towards where a unit is going to be provided that it will be in range when the projectile hits. These changes removed most of the utility of the widget, making it obsolete.
|
1 |
Save me some time and read https://zero-k.info/Forum/Thread/31189?postID=219329#219329 as it is mostly what I'd be writing here. In retrospect I came across a bit harsh there and we may even have had a player widget turn into a game widget in the year and a half since that post. Prefire was eventually solved by a combination of redesigning Kodachi and @esainane digging up (and fixing in-engine) an obscure weapon tag that let units fire towards where a unit is going to be provided that it will be in range when the projectile hits. These changes removed most of the utility of the widget, making it obsolete.
|
| 2 |
\n
|
2 |
\n
|
| 3 |
The main thing I want to highlight from the post I linked is that
|
3 |
The main thing I want to highlight from the post I linked is that
|
| 4 |
[q]My ideal world would have a list of other people's enabled widgets available at the end (and start?) of a match so that you can just grab whichever you like the look of. Allowing a rapid evolution of widgets as people share the good ones and improve/tweak them over time. [/q]
|
4 |
[q]My ideal world would have a list of other people's enabled widgets available at the end (and start?) of a match so that you can just grab whichever you like the look of. Allowing a rapid evolution of widgets as people share the good ones and improve/tweak them over time. [/q]
|
| 5 |
[q]Hot take: all allowed widgets should be publically available and the wiki should inform what they are and how to get them. [/q]
|
5 |
[q]Hot take: all allowed widgets should be publically available and the wiki should inform what they are and how to get them. [/q]
|
| 6 |
does not work. There is a massive gulf between "widget I can use personally as it fits my style and I know its quirks" and "widget that is user friendly enough for others".
|
6 |
does not work. There is a massive gulf between "widget I can use personally as it fits my style and I know its quirks" and "widget that is user friendly enough for others".
|
| 7 |
\n
|
7 |
\n
|
| 8 |
[q]Since nobody mentioned the elephant in the room, biggest problem is that the widget enthusiasts are also ones most likely to be (potential) contributors to game development. So pissing them off by removing their game advantages will hurt the game more in the long run than some unfair matches. A kind of realpolitik opinion on why it is tolerated. [/q]
|
8 |
[q]Since nobody mentioned the elephant in the room, biggest problem is that the widget enthusiasts are also ones most likely to be (potential) contributors to game development. So pissing them off by removing their game advantages will hurt the game more in the long run than some unfair matches. A kind of realpolitik opinion on why it is tolerated. [/q]
|
| 9 |
Yes. Maybe not the biggest problem, but it is there.
|
9 |
Yes. Maybe not the biggest problem, but it is there.
|
| 10 |
\n
|
10 |
\n
|
| 11 |
[q]One feature/design paradigm I particularly like about zero-k is that it arrives to have a "physics based combat model"; projectiles obey laws of physics, units don't have hidden bonus damages or armor types, and balance is achieved through tweaking these physical properties rather than artificially handicapping units. The prefire widget was a natural use of in-game physics to improve unit performance, and a physically accurate one at that. I would argue that the net result of the widget and rebalance is that the game is a more accurate combat simulation, which is something I value. The net result in terms of gameplay may be the same but there is value in staying true to the principles of the game's design. [/q]
|
11 |
[q]One feature/design paradigm I particularly like about zero-k is that it arrives to have a "physics based combat model"; projectiles obey laws of physics, units don't have hidden bonus damages or armor types, and balance is achieved through tweaking these physical properties rather than artificially handicapping units. The prefire widget was a natural use of in-game physics to improve unit performance, and a physically accurate one at that. I would argue that the net result of the widget and rebalance is that the game is a more accurate combat simulation, which is something I value. The net result in terms of gameplay may be the same but there is value in staying true to the principles of the game's design. [/q]
|
| 12 |
Yes, this is good. Who is going to do this work though?
|
12 |
Yes, this is good. Who is going to do this work though?
|
| 13 |
\n
|
13 |
\n
|
| 14 |
I made this ticket https://github.com/ZeroK-RTS/Zero-K/issues/4479 rather than weigh in on the Badger replay because it was "ruined" by the second and third (especially the third) posts. Trying to talk about anything reasonable on that thread seemed like a waste of time. It turns out I had already made a similar ticket a year and a half ago for Kodachi prefire. It seems like exactly the sort of non-specific additional command that @PRO_Dregs can appreciate.
|
14 |
I made this ticket https://github.com/ZeroK-RTS/Zero-K/issues/4479 rather than weigh in on the Badger replay because it was "ruined" by the second and third (especially the third) posts. Trying to talk about anything reasonable on that thread seemed like a waste of time. It turns out I had already made a similar ticket a year and a half ago for Kodachi prefire. It seems like exactly the sort of non-specific additional command that @PRO_Dregs can appreciate.
|
| 15 |
\n
|
15 |
\n
|
| 16 |
I'll
have
another
go
at
picking
apart
the
difference
between
player
widgets
and
game
UI.
Well,
apart
from
the
fairness
difference,
which
I
think
has
been
well
covered.
To
start
with,
the
UI
is
meant
to
be
used
by
players
to
implement
their
decisions,
not
make
decisions
for
them.
The
issue
is
that
the
act
of
creating
anything
involves
making
a
bunch
of
decisions
along
the
way.
In
making
this
comparison
I
may
have
conflated
"creative/design
decisions"
and
"ingame
player/strategic
decisions",
but
I
feel
like
the
natural
mode
of
widget
creation
is
to
conflate
these
two
types
of
decisions.
The
two
step
process
of
making
design
decisions
that
allow
for
a
range
of
decisions
ingame
is
[i]significantly[/i]
more
complicated
than
making
the
ingame
decisions
at
the
coding
stage
(
possibly
even
subconsciously,
as
per
your
playstyle)
and
then
writing
them
directly
into
the
widget.
The
widget
doesn't
negatively
impact
the
creator
because
they
can
tweak,
cutting
any
behaviours
they
personally
dislike
and
adapting
it
to
their
control
style.
Other
players
don't
have
this
assurance.
They'll
not
use
the
widget
or
be
stuck
having
their
units
implement
someone
else's
decision.
|
16 |
I'll
have
another
go
at
picking
apart
the
difference
between
player
widgets
and
game
UI.
Well,
apart
from
the
fairness
difference,
which
I
think
has
been
well
covered.
To
start
with,
the
UI
is
meant
to
be
used
by
players
to
implement
their
decisions,
not
make
decisions
for
them.
The
issue
is
that
the
act
of
creating
anything
involves
making
a
bunch
of
decisions
along
the
way.
In
making
this
comparison
I
may
have
conflated
"creative/design
decisions"
and
"ingame
player/strategic
decisions",
but
I
feel
like
the
natural
mode
of
widget
creation
is
to
conflate
these
two
types
of
decisions.
Consciously
keeping
the
design
decisions
within
the
widget
separate
from
the
strategic
decisions
of
those
using
the
widget
is
simply
a
lot
more
difficult
than
bundling
all
the
technical
and
strategic
considerations
together,
and
is
redundant
effort
when
making
a
widget
designed
for
personal
use.
The
default
is
to,
subconsciously,
hardcode
widgets
with
the
types
of
decisions
the
creator
tends
to
make,
and
to
mesh
well
with
their
playstyle.
Everything
the
widget
does
is
in
essence
a
real
strategic
decision
for
the
creator
because
they
can
tweak
or
rework
anything
they
want.
Other
players
don't
have
this
ability
and
it
can't
be
expected
of
them.
They'll
not
use
the
widget
or
be
stuck
having
their
units
implement
someone
else's
decisions.
Letting
a
powerful
widget
of
this
nature
dictate
balance
and
the
rest
of
the
design
puts
everyone
else
in
a
tricky
situation.
Many
people
will
either
be
left
behind,
or
use
the
widget
but
noticeably
degrade
their
UI
in
the
process.
|
|
|
17 |
\n
|
|
|
18 |
Imagine a master cobbler who shows up to a race with a box of magic shoes that double the running speed of the wearer. Unfortunately he only knows how to make them in one size - his own. Others can wear them with some greater or lesser degree of discomfort, and they don't fit some people at all. Having a whole box of such shoes doesn't make the race fair, and even many who can wear the shoes, but quite uncomfortably, would probably rather not have to.
|
| 17 |
\n
|
19 |
\n
|
| 18 |
In short, the naive unit AI widget decides that units should behave a particular way and implements it. The advanced version, the type that is polished enough for inclusion, gives players tools that let them decide how their units should act. For someone to really be deciding how their units should act they need to understand what the commands do, and the commands need to be obvious/easy enough to use. This is where all the polish and streamlining and UI design work comes in.
|
20 |
In short, the naive unit AI widget decides that units should behave a particular way and implements it. The advanced version, the type that is polished enough for inclusion, gives players tools that let them decide how their units should act. For someone to really be deciding how their units should act they need to understand what the commands do, and the commands need to be obvious/easy enough to use. This is where all the polish and streamlining and UI design work comes in.
|
| 19 |
\n
|
21 |
\n
|
| 20 |
Some sort of technical ban on local widgets would make development harder. Eg @PRO_Clopse was used local widgets, ones that issue commands, for a while. He would make some feature request, I'd see that it isn't in the options but could be with a small tweak, so I'd make the tweak and send him the widget. The feedback and revision cycle was tight. I'm also not so sure that the problem is restricted to the 1v1 MM. It might just be the canary in the coal mine - some widget that cause complaints in 1v1 might be noticed in team games a month later. Delaying this complaint isn't overall helpful to development. Regardless, I don't want to maintain two sets of balance for it.
|
22 |
Some sort of technical ban on local widgets would make development harder. Eg @PRO_Clopse was used local widgets, ones that issue commands, for a while. He would make some feature request, I'd see that it isn't in the options but could be with a small tweak, so I'd make the tweak and send him the widget. The feedback and revision cycle was tight. I'm also not so sure that the problem is restricted to the 1v1 MM. It might just be the canary in the coal mine - some widget that cause complaints in 1v1 might be noticed in team games a month later. Delaying this complaint isn't overall helpful to development. Regardless, I don't want to maintain two sets of balance for it.
|
| 21 |
\n
|
23 |
\n
|
| 22 |
Zero-K has been designed along the lines of what @Niarteloc said above, and while it takes increasingly more work for smaller gains, I'd hope we can continue to do so. However, the work largely involves things like resolving conceptual paradoxes, such as firing at the ground being mostly free, and implementing generic commands/behaviours, rather than making specialised widgets.
|
24 |
Zero-K has been designed along the lines of what @Niarteloc said above, and while it takes increasingly more work for smaller gains, I'd hope we can continue to do so. However, the work largely involves things like resolving conceptual paradoxes, such as firing at the ground being mostly free, and implementing generic commands/behaviours, rather than making specialised widgets.
|
| 23 |
\n
|
25 |
\n
|
| 24 |
One final example which someone might pick up. @Shaman had a widget that could do Snitch bombing. I recall asking for it as a generic attack command for transports that tells them to fling their cargo to land at a location. This hasn't happened yet.
|
26 |
One final example which someone might pick up. @Shaman had a widget that could do Snitch bombing. I recall asking for it as a generic attack command for transports that tells them to fling their cargo to land at a location. This hasn't happened yet.
|
Widgets in competitive games