It's a nice piece of code, but as a mechanic it has big issues. The problem is with a concept I've been using for a while but haven't named. I think I'll call it the prominence-impact ratio. Essentially, the ratio of the 'brainspace' demanded by a mechanic and the actual impact of that mechanic on the game should be fairly constant across the game. 'Brainspace' encompasses things such as how much impact a mechanic has on your visual field, how novel it is, how much people are likely to think about it, and the costs imposed by making it harder to think about related mechanics. Game impact can be summed up in the question "If this mechanic didn't exist, how much would the game change?".
The prominence-impact rule would then be: "The prominence of a things should be in proportion to its impact on the game".
Limited violations of the prominence-impact rule can be used to intentionally control player focus - to draw players to focus on the hooks of the game, or the more fun parts, but this is risky. Games that randomly draw your attention to their mechanics are much harder to learn than games structured such that the important stuff is the most visible. It sucks to realise the game was 'lying' to you about something being important, or when you miss out on learning a vital part of the game for ages because it's so obscured.
I think this goes a long way to explain why I am wary of unique weapons and abilities. Or perhaps the prominent-impact law is just a generalisation (or explanation) for the concept of a complexity budget. Anyway, completely unique mechanics can demand a lot of brainspace in games where it appears, and this can be out of proportion with the importance of the mechanic to the game as a whole. This is why I think the addition of a previously unique mechanic to more units can actually be an improvement in complexity. A more common mechanic justifies the effort put into learning it, as the knowledge is transferable. It makes the game into a coherent whole, that can be learnt in terms of general rules, rather than a list of edge cases. For example, slow damage started on one unit and expanded over the course of a decade.
My preferred approach to heat is to find a way for Stardust to do without it. I don't think I like it enough to expand it to more units just for the sake of expanding it, however, a problem solved by heat may pop up in the future, so maybe it will be useful. But basically, I don't consider heat to be part of the general 'canon' of ZK mechanics yet. Also, Quill is not even a perfect extension of heat since Stardust has a weapon, while Quill has buildpower. Calling these two things implementations of the same mechanic stretches the analogy between weapons and buildpower. Slow damage shows there is some analogy, but it isn't immediately obvious how to translate between bullets generating heat and construction generating heat.
Putting aside heat in the context of ZK, the implementation on Quill itself is a large violation of the prominent-impact rule. The prominence of the mechanic is similar to that of Stardust heat. It adds a heat bar above the unit and changes the rate at which it works. Perhaps it is more prominent because Quill spends most of its time constructing while Stardust spends most of its time idle, so the heat bar will show near-permanently on Quill. Also, Quill heat will show up as variations in metal pull, but weapon fire is more obvious than construction, so exact prominence probably depends on the player.
The big issue is that Quill heat has very little impact on the game. It amounts to building something about 1s faster, provided it has been traveling (or idle) for a few seconds, and the player has excess metal. These situations are rare and the effect is tiny. So the mechanic has almost no impact on the game, yet it is about as prominent as Stardust heat. Even Stardust heat may be a bit too prominent for its impact, but at least it has much more impact due to its longer heat time and the fact that burst is much more important for weapons than constructors.
Unpack time is mechanic with prominence appropriate to this level of impact. Lotus takes a bit less than a second to unpack when built. This has no impact when enemies aren't around, so you have to look closely to notice it. It's a bit more useful when built in combat because players can see it pause for a bit, then shoot. But it doesn't have a large effect in combat either, which fits its low prominence.
An even more relevant example is constructor unpack time. I spawned ten Quills and Masons then had them start an Artemis at the same time, in the little nook to the south of their spawn. I gave them enough resources to construct at full speed, let them construct for a few seconds, and used the health of the Artemis to calculate how many resource had been spent. I ran this with the stable and with the heat PR, modified so that Mason and Quill don't have to unpack to start construction.
-
6.9 more resources were spent per Quill with heat and no unpack time, compared to Mason with no unpack time.
-
1.65 more resources were spent per stable Quill, compared to stable Mason.
Quill already has about 1/4 the effect of the heat change, compared to Mason, just by unpacking slightly faster. This seems appropriate for the prominence of the unpack animation. The unpack time even varies based on which way the constructor is pointing. I haven't done a survey of the prominence-impact ratio of the game, but communicating variations on the order of a second with animations feels appropriate. It also scores well on the uniqueness complexity metric, as the game is full of delays due to unpacking or aiming.
Finally, for completeness, Quill heat has some UI regressions and times when it is just plain confusing. Even if the prominence-impact rule were not violated, I'd want an alternate implementation. Perhaps give Quill a regenerating pool of boost BP, which it can use alongside its normal BP to spend extra resources until depleted. To match the heat implementation we would give Quill a pool with a limit of 6.9 and some rules about when it is used and regenerated. The tiny pool of 6.9 resources would highlight how little impact the heat has on the game though, so I'd probably want a pool of at least 50. This would be nuts though.
In short, mechanics should be about as impactful as their visuals suggest they are.
On the UI side, the Quill in the PR says it has 10 BP in all the tooltip, but in practise it has 5. Also the heat bar means approximately nothing when stalling metal (which is very common) yet can be manipulated, generating information noise.
For example, three Quills are building an Artemis at maximum heat. I add a fourth, and their heat starts to go down. As a player it looks like I've done something, because why would a bar over a unit change if nothing of note has occurred? But in fact very little has changed about the situation.
I hope you prefer my attempt to communicate what I've mostly been doing by feel. The alternative was me not being quite sure what to do, then saying "Hmm, I feel like this goes against the design in some way".
