| 1 |
This sounds like nice quality of life, but unfortunately it seems to have an unresolvable conflict with a principle of ZK design. Specifically, the principle that the team of a unit is everything, with player ownership being irrelevant to the simulation (technically these are allyTeam and team respectively, but I'll stick to "team" and "player" here).
|
1 |
This sounds like nice quality of life, but unfortunately it seems to have an unresolvable conflict with a principle of ZK design. Specifically, the principle that the team of a unit is everything, with player ownership being irrelevant to the simulation (technically these are allyTeam and team respectively, but I'll stick to "team" and "player" here).
|
| 2 |
\n
|
2 |
\n
|
| 3 |
The simulation view of ZK abstracts away the source of player commands, just treating them as inputs to a system of rules that calculate game states. This includes things like physics and pathfinding, but also includes command queues and most unit AI (the unit AI not implemented by widgets). The simulation view is like the rules of chess, and a replay of ZK is just like a list of chess moves. Both replays record the simulation-relevant commands that went on to affect the game state. In principle we only need to know how the simulation of ZK works in order to devise a perfect strategy, but in practice people don't have infinite APM and the search space is too large. A list of moves in chess encodes an entire game, but ignores things like how the players used their hands to manipulate the pieces, how they perceived the pieces, and the time controls.
|
3 |
The simulation view of ZK abstracts away the source of player commands, just treating them as inputs to a system of rules that calculate game states. This includes things like physics and pathfinding, but also includes command queues and most unit AI (the unit AI not implemented by widgets). The simulation view is like the rules of chess, and a replay of ZK is just like a list of chess moves. Both replays record the simulation-relevant commands that went on to affect the game state. In principle we only need to know how the simulation of ZK works in order to devise a perfect strategy, but in practice people don't have infinite APM and the search space is too large. A list of moves in chess encodes an entire game, but ignores things like how the players used their hands to manipulate the pieces, how they perceived the pieces, and the time controls.
|
| 4 |
\n
|
4 |
\n
|
| 5 |
Another way to think of the principle is that a single player controlling a bunch of commanders should technically have the same options available to them as a team of players with one commander each. It isn't an unwavering rule though - few are. In practice the rule tends to be:
|
5 |
Another way to think of the principle is that a single player controlling a bunch of commanders should technically have the same options available to them as a team of players with one commander each. It isn't an unwavering rule though - few are. In practice the rule tends to be:
|
| 6 |
[q]Almost everything players might encounter or want to do in the game should be consistent with a full implementation of player ownership being irrelevant to the simulation[/q]A lot of rules end up like this. Some simple ideal set of unit abilities is defined, then the game is implemented so that each practical situation is consistent with the ideal.
|
6 |
[q]Almost everything players might encounter or want to do in the game should be consistent with a full implementation of player ownership being irrelevant to the simulation[/q]A lot of rules end up like this. Some simple ideal set of unit abilities is defined, then the game is implemented so that each practical situation is consistent with the ideal.
|
| 7 |
\n
|
7 |
\n
|
| 8 |
This
principle
is
a
big
factor
in
our
ability
to
scale
from
1v1
to
16v16
without
much
trouble.
It's
rare
for
an
RTS
to
even
go
beyond
4v4.
Personal
resourcing
and
tech
trees
are
a
problem
for
large
team
games.
Even
supreme
commander
has
(
or
had?)
your
own
units
being
able
to
shoot
through
each
other,
but
not
through
units
on
the
same
time.
|
8 |
This
principle
is
a
big
factor
in
our
ability
to
scale
from
1v1
to
16v16
without
much
trouble.
It's
rare
for
an
RTS
to
even
go
beyond
4v4.
Personal
resourcing
and
tech
trees
are
a
problem
for
large
team
games.
Even
supreme
commander
has
(
or
had?)
your
own
units
being
able
to
shoot
through
each
other,
but
not
through
units
on
the
same
time.
This
reportedly
made
team
games
with
mixed
player
armies
harder
to
use.
|
| 9 |
\n
|
9 |
\n
|
| 10 |
Consider the ZK economy. The simulation view of income and expenditure is that the team as a whole has income and storage, and that each constructor can use any fraction of its buildpower. The actual implementation of income and storage looks very different, but is consistent with each player having exclusive control of different portions of some theoretically global storage and income. Spending more than a whole players income is still possible by assisting allies or sharing resources. Note that sharing constructors is annoying, so it can't be a thing that people would want to do often. [b]The annoyance/fiddliness of using the user interface to implement an ability that is theoretically granted by the simulation view should be in proportion to how frequently players would want to actually use the ability[/b]. Actually that is a really important general principle, so I'll put it in bold.
|
10 |
Consider the ZK economy. The simulation view of income and expenditure is that the team as a whole has income and storage, and that each constructor can use any fraction of its buildpower. The actual implementation of income and storage looks very different, but is consistent with each player having exclusive control of different portions of some theoretically global storage and income. Spending more than a whole players income is still possible by assisting allies or sharing resources. Note that sharing constructors is annoying, so it can't be a thing that people would want to do often. [b]The annoyance/fiddliness of using the user interface to implement an ability that is theoretically granted by the simulation view should be in proportion to how frequently players would want to actually use the ability[/b]. Actually that is a really important general principle, so I'll put it in bold.
|
| 11 |
\n
|
11 |
\n
|
| 12 |
Construction priority follows the same idea. Theoretically anything can spend resources up to its build power, but in practice there are only a few useful ways to spend resources. Construction priority and reserve seem to cover what is required in practice.
|
12 |
Construction priority follows the same idea. Theoretically anything can spend resources up to its build power, but in practice there are only a few useful ways to spend resources. Construction priority and reserve seem to cover what is required in practice.
|
| 13 |
\n
|
13 |
\n
|
| 14 |
Overdrive has really benefited from the principle because it let us split social design from balance design. The theoretical implementation over overdrive is that the (Team Net Income)*(Team Energy Stored)/(Team Storage Capacity) is sent to the overdrive system, the energy is distributed for optimal metal return, and any excess (due to lack of grid) is returned. This is also how the system works in practice. Energy structures and metal extractors don't care who owns them within the team for the purpose of overdrive. It has to be this way, otherwise there would be a bunch of unintuitive unit sharing tricks that teams could use to send more of their energy to overdrive. This would probably be optimal play, which would "force" players to spend their time fiddling with unit sharing UI. The great thing about the principle of player ownership being irrelevant is that it takes the distribution of overdrive metal out of the realm of game balance. Strategy space doesn't care about the split, just the total metal income, so we have been free to come up with distribution rules that hit a good compromise of personal payback and teamwork.
|
14 |
Overdrive has really benefited from the principle because it let us split social design from balance design. The theoretical implementation over overdrive is that the (Team Net Income)*(Team Energy Stored)/(Team Storage Capacity) is sent to the overdrive system, the energy is distributed for optimal metal return, and any excess (due to lack of grid) is returned. This is also how the system works in practice. Energy structures and metal extractors don't care who owns them within the team for the purpose of overdrive. It has to be this way, otherwise there would be a bunch of unintuitive unit sharing tricks that teams could use to send more of their energy to overdrive. This would probably be optimal play, which would "force" players to spend their time fiddling with unit sharing UI. The great thing about the principle of player ownership being irrelevant is that it takes the distribution of overdrive metal out of the realm of game balance. Strategy space doesn't care about the split, just the total metal income, so we have been free to come up with distribution rules that hit a good compromise of personal payback and teamwork.
|
| 15 |
\n
|
15 |
\n
|
| 16 |
By now the problem with a toggle for Lobster only throwing units that the player owns might be clear. As written, this ability is illegal since things in the simulation can't refer to ownership within a team. Therefore, Lobster would have to have a more general ability - the ability to decide which units it throws when it activates. The UI would then implement the specific use of this ability as the proposed toggle. The problem with this is:
|
16 |
By now the problem with a toggle for Lobster only throwing units that the player owns might be clear. As written, this ability is illegal since things in the simulation can't refer to ownership within a team. Therefore, Lobster would have to have a more general ability - the ability to decide which units it throws when it activates. The UI would then implement the specific use of this ability as the proposed toggle. The problem with this is:
|
| 17 |
* There are a lot of situations where players would want to use the more powerful version of the ability. They wouldn't just want to only throw units they control, they would want to throw particular subsets of units.
|
17 |
* There are a lot of situations where players would want to use the more powerful version of the ability. They wouldn't just want to only throw units they control, they would want to throw particular subsets of units.
|
| 18 |
* The UI for selecting a subset of units to throw sounds absolutely horrific.
|
18 |
* The UI for selecting a subset of units to throw sounds absolutely horrific.
|
| 19 |
So, as far as I can tell, we're stuck between Lobster having a weak and somewhat useful ability that violates a design principle, or having a stronger ability with a UI that I would not want to inflict on players.
|
19 |
So, as far as I can tell, we're stuck between Lobster having a weak and somewhat useful ability that violates a design principle, or having a stronger ability with a UI that I would not want to inflict on players.
|
| 20 |
\n
|
20 |
\n
|
| 21 |
Finally on the principle, I am torn on the existence of player colours for radar dots. I've previously requested an option for unidentified radar dots to lack team or player information, but it hasn't been implemented, so I haven't been faced with the decision yet. On one hand, it is weird to be able to predict that a slow lone yellow radar dot is an approaching Lance simply because the yellow player has hovercraft. But this [i]technically[/i] has no impact on how the simulation works, only on the information provided. In terms of perfect play, it means that teams are needlessly leaking information for the convenience of not sharing all their units to one player (or not all being commshared). But thinking socially, I think it is generally good to see the enemy team as being made up of individual named players, rather than as a monolithic blob. So maybe the principle technically isn't violated, but we're still left open to the same sorts of problems. I can imagine players sharing units to play mindgames about who owns which factory, or is focusing on which front. I just have to hope that the payoff is so low that nobody feels obligated to share units for this reason. In the end player colours are probably just part of the considerations for practical play, similar to launch many attacks at once to overwhelm your opponents ability to think and respond. I still think I would make unidentified radar dots grey though. Perhaps it would even encourage more scouting.
|
21 |
Finally on the principle, I am torn on the existence of player colours for radar dots. I've previously requested an option for unidentified radar dots to lack team or player information, but it hasn't been implemented, so I haven't been faced with the decision yet. On one hand, it is weird to be able to predict that a slow lone yellow radar dot is an approaching Lance simply because the yellow player has hovercraft. But this [i]technically[/i] has no impact on how the simulation works, only on the information provided. In terms of perfect play, it means that teams are needlessly leaking information for the convenience of not sharing all their units to one player (or not all being commshared). But thinking socially, I think it is generally good to see the enemy team as being made up of individual named players, rather than as a monolithic blob. So maybe the principle technically isn't violated, but we're still left open to the same sorts of problems. I can imagine players sharing units to play mindgames about who owns which factory, or is focusing on which front. I just have to hope that the payoff is so low that nobody feels obligated to share units for this reason. In the end player colours are probably just part of the considerations for practical play, similar to launch many attacks at once to overwhelm your opponents ability to think and respond. I still think I would make unidentified radar dots grey though. Perhaps it would even encourage more scouting.
|
Lobster throwing only my own units