Lobster throwing only my own units

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).

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.

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:

quote: 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

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.

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.

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. 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. Actually that is a really important general principle, so I'll put it in bold.

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.

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.

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:

• 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.
• The UI for selecting a subset of units to throw sounds absolutely horrific.

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.

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 technically 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.

Be wary of applying the principle too widely. It is just about what can be implemented at the base simulation level of the game. There are many other levels of the game, such as the stuff players actually own and how they control the game. The things that players own, how they use them, and the feeling of impact on the game is important, more important than abstract ideas about the underlying simulation. The principle is a guiding rule that applies to a particular part of the design, and it is used because it helps the whole design, even the parts about making players feel like they have individual impact. I had to come up with the name earlier, and "the principle of player ownership being irrelevant" is a pretty cumbersome and, without context, potentially misleading one.

The aim of the principle isn't to dilute the players into a blob. I think of it more as a line in the sand. It is about accepting that a team game with the principal "fight your opponent, not the UI" is going to require some pretty powerful coordination tools, and that coordination tools are going to tend to push players into a blob. The principle helps fights the slide into blobness by providing a simple rule to follow in simulation-side design, then declaring everything else free game. We wouldn't stop trying to make coordination easy in teamgames without the principle, we'd just have to do it in a more ad hoc way. We'd end up implementing things that cause trouble later (such as players using the unit sharing UI to selectively launch units with Lobster), or overshoot and reduce individual control in situations where it was actually fine.

(I keep besmirching the unit sharing UI, but honestly, it is one of those UIs that exists more to keep the design honest than to be regularly used. Unit sharing exists and its fine for people to use it on occasion, but we've failed somewhere if people feel like they have to use it frequently.)

Overdrive is a great example of using the line drawn by the principle. We define a pretty simple mechanical implementation of overdrive that doesn't refer to ownership, and are then free to distribute resources to players in whichever way best balances teamwork and feelings of individual contributions. Trying to balance the economy mechanics while simultaneously making the individual aspects of the economy feel good would be more difficult. All the factors to take into consideration still exist, we've just found a way to insulate economic balance from tweaks to teamwork vs. individual feel.

The issues you highlight with old players skipping metal spots did exist, but as far as I can tell it is barely a problem now. Metal extractors and energy structures return some of their cost to the player that built them. In the past we've even overshot on the payback, causing people to spam energy to the detriment of their team so they can reap the increased income for their project. Now I might be mistaken, and the dial might be too far towards skipping metal extractors or fighting over them, but the great thing is that this can be adjusted without impacting the underlying function of the economy itself.

Being unintuitive to new players is a concern. I don't think it is too bad though as the basic advice of "grab free mexes, make some energy" serves pretty well. I don't think placing a mex is as simple as destroying one though. Placing a mex can be done with right click. To teamkill you have to find a unit with AoE and deliberately force fire it at a pretty small area of terrain. This stuff tends to get reported too. I have seen people complain about mex stealing, but this is often resolved by a simple explanation along the lines of "income is shared". I've also got to wonder whether someone who would deliberately fire at an allied structure is cut out to play team games in the first place.

Basically, a team game like ZK has to strike a balance between cooperation and individualistic enjoyment (all while maintaining "fight your opponent, not the UI"). I don't think the principle of player ownership being irrelevant to the simulation forces the design ZK anywhere that it wouldn't already need to go to strike this balance. Rather, the principle is a useful guideline that makes finding the right balance easier, and can probably even reap positive-sum benefits for both sides. Consider this: the principle doesn't actually prohibit players receiving all the metal generated by their own mexes, indefinitely. The principle doesn't care as long as the total income of the team is unchanged. Metal extractors share income to the team for other reasons.

Consider one of the more impactful use of lobsters is lobbing enemy units, not lobbing allied units doesn't fit the design at all.

The question under this condition is on how acceptable is it to throw allied units deliberately as some strategy, even under good faith try to win maneuvers. Now this range range from tactical saves of units too far forward and exposed/stunned, to literal armies stashed significantly behind the front line and out of position from fights. For the latter case, sometimes the armies are behind not because of lack of move commands but because of lack of mobility due to traffic jams common in dirtbagged terrain.

I don't see much allied lobster strategy probably because it is not easily and particularly effective without coordination and probably would just piss people off, but maybe someone would do it one day. (maybe a trollbot style account for isolation purposes) Perhaps some allied lobstering game winning play can be figured out after some study and experimentation.