Cloakbot Imp

I think imp should still be capable of triggering its explosion while EMP, since manual self-d is allowed during EMP and that is what its attack is.

Other than that, players can always self-d it near the target after it has been stunned.

Lynx shall we delve deeper?

quote: You set aside the inconvenient examples and take snitches and faradays.

What are the inconvenient examples you are talking about? I have said I would like to remove or better visualise the present inconsistencies, and slow progress has been made over the years. For example Venom used to take 25% EMP damage. EMP immunity for Imp would be the addition of a large inconsistency.

quote: Setting aside the inconvenient examples, that snitch and faraday behaviour would render it obvious that collective imp attacks would fail is not at all apparent to me. Snitches work well together. They explode as in deliver damage together.

Snitches work terribly together if you just select a group of Snitches and give them an attack order. The Snitches walk in as a loose cloud, the first one explodes and deals a bit of damage, and then all the Snitches behind explode pointlessly. Even if you group your Snitches, the death of a single Snitch causes them all to die. This is directly analogous to what happens with Imps, except that by replacing death with stun you have an effect that does not propagate down a chain. This makes Imps theoretically a bit better on attack.

The only way you're going to get good use out of an attack command for Snitches is if you send them as a group and they take no damage along the way. If this level of control is baked into your assertion that Snitch work well together, then I propose the following unit AI for Imp:

• If you are about to be stunned and the target of your attack command is in range, detonate.

The exact implementation would depend on some trade offs and likely have some hax in the edge cases. Predicting imminent EMP damage from allies or visible enemies is theoretically possible, but technically tricky, so I'd probably just add a cheap gadget. The gadget would trigger when Imps take EMP damage and detonate the Imp if the damage would probably have been predictable by a really fancy widget.

If terve886 is reading, this is another example of simple gadget being a better implementation than a complex widget. Imagine what an ideal widget would be able to do, then write a simple gadget that basically does the same thing.

quote: So why shouldn't imps effectively explode together too.

Because EMP damage does not have the mechanical effect of causing units to die. EMP damage has the mechanical effect of blocking self-destruction so an EMPed Imp cannot explode.

quote: As you observe friendly fire is excepted in many units. As observed above, slow damage does not hurt local friendly units. It feels like a very arbitrary exercise to take a selection of examples that fit the bill and say: hey look the way it works is consistent.

Not "many units", a well-demarcated weapon type. To say "many units" implies that what presently exists is an arbitrary list.

I observed that slow waves (not slow damage, just slow waves) have the ability of not damaging friendlies. Slow waves are a consistently implemented and visually distinct weapon type with its own combination of behaviours. Once you have seen how an Outlaw works you can deduce how a Limpet will work. The visual distinctiveness aids your memory, even if only a single unit were to use the mechanic (such as the green glow bestowed by Lobster).

What would indicate that Imp is immune to EMP damage? There is no established visual language for such an immunity, and anyway, the unit model is tiny. Such a rule is much harder to discover, and to remember, than the behaviour of the slow wave weapon type.

quote: Only it's not. Generally your argument that imp behaviour in terms of implementation of collective attack is derivable from existing behaviour in other units is undermined by all the examples of new players or experienced players finding to their surprise that collective imp attacks don't work. Setting aside the actual examples of users finding to their peril this weird self stun queue behaviour, what explains my confusion at this? I have played this game for years and it was not obvious to me at all that this behaviour would arise. Had it been this thread would not exist.

Do you understand the mathematical underpinnings of compression algorithms? Or Occam's Razor? Or the idea of things being greater than the sum of their parts? I have been trying to communicate a notion of mechanical complexity by giving examples, but I don't think it is working, and communicating the concept directly is much harder than doing so by example. I am talking about mechanical simplicity in the sense of the rules of the game world being small and compressible. In the sense of not adding needless complication. The behaviour and interactions of the units should arise from a relatively small and consistent set of mechanics. Adding unique mechanics to fiddle with a specific bit of behaviour goes against this.

Something I realised is that you keep using the word 'behaviour' while I am using the word 'mechanics', and while I use these words to mean very different things, you may be using them interchangably. I touched on this here:

quote: I was more talking about the learnability of the rules of the game world, not the power of the interface used to interact with it.

but on rereading, what I said only makes sense to someone who already gets my point. I'll try again.

One model of Zero-K, the model I am using here, is that there is a game world with its own physics and set of rules. This set of physics and rules is called 'the mechanics'. Units have abilities within this world, bestowed upon them by the mechanics, such as 'move forwards', 'turn', 'aim over here', and 'fire my weapon'. The mechanics only bestow simple abilities upon the units, it does not tell them how to use their abilities.

Units using abilities to do complex things such as moving around the map, aiming and firing at enemy units, and avoiding fire, falls under unit behaviour (or interchangeably, unit AI). Taking this model and assuming perfect behaviour underpins the powerful interface and automation of ZK, as such an assumption forces the design to live or die by the theoretical consequences of its mechanics. Keeping this model in mind pushes the game to be interesting and challenging even in the face of powerful methods of unit control, even as-yet unimplemented ones.

So that is how I am using 'mechanics' and 'behaviour'.

quote: Only it's not. Generally your argument that imp behaviour in terms of implementation of collective attack is derivable from existing behaviour in other units is undermined by all the examples of new players or experienced players finding to their surprise that collective imp attacks don't work.

I am not making the claim that Imp attack behavour is derivable from the behaviour of other units. My claim is the mechanics that underpin the constraints on how Imp should behave to attack successfully are consistent with the mechanics of the rest of the game.

quote: Setting aside the actual examples of users finding to their peril this weird self stun queue behaviour, what explains my confusion at this? I have played this game for years and it was not obvious to me at all that this behaviour would arise. Had it been this thread would not exist.

The mechanics that underpin the constraints on optimal unit behaviour can be simple, without it being trivial to work out those constraints on the fly. Imp is a unique combination of simple and consistent mechanics (those of bombs, spiders, AoE, and EMP) and it could take some time to figure out what this combination of mechanics mean for how the unit should be used. There is also a difference between how a unit should behave and how it actually responds to commands. With Imp, it has the ability of coordination self-d but does not use it when given simple commands. To me this just looks like an incomplete part of the UI.

If the mechanics of ZK were simple enough to trivially figure out how best to use every unit in every situations, well, then I think we would have given up a lot of its depth. Of course, there are other types of depth a game could have, but eroding this depth would be quite a departure from the feel of ZK. Part of the design of ZK is to have complex behaviours and interactions arise from simple mechanics.

quote: I don't find it cool or rewarding. I just find it annoying. And the justification for its existence weird. Also I don't find it cool having to write a widget to fix this annoying behaviour. The mere fact that such a widget could give an advantage to fix this irritation irritates me.

Would you find it annoying to be on the receiving end of an unexpectedly EMP-immune Imp? You don't see the commands and unit AI of enemy units, all you see is them use their abilities in the game world, so a big benefit of consistent and well communicated mechanics is a reduced memory load for fighting against unfamiliar units.

Here are the steps I took when assessing Imp for this thread:

• Figure out what the problem is.
• See that the problem is bad unit behaviour.
• Check that Imp has the mechanical abilities required to implement better behaviour.
• Wait for someone to write a widgets or gadgets to better use these abilities.

The OP proposes behaviour changes, not any new abilities, so seems to the thinking along these lines too. It is only when EMP immunity was brought up that we got into the discussion of behaviour vs. mechanics.

quote: Also sorry if I come across like a dick in this post. I really value everything you do for this game and am very grateful.

No problem. At worst you are a rubber duck and at best people get to see some of the design of ZK. Also, I'm not sure if you're using "ideological" pejoratively, but hopefully you'll see that the things I push for or against have solid foundations. There is still a slippery slope argument here, but firstly, constrains breed creativity, and secondly, why dilute the feel of ZK? When written abstractly it can be hard to see how particular design principals feed into making ZK what it is, but I expect you would feel the difference with enough deviation from the current design.

quote: Without exception every single one of the built-in widgets started its life as a local widget that somebody wrote and tested on their own machine, then it was included in the game.

nop this is not quite true. Technically, all widgets were tested locally, but you imply that all the widgets were found in the wild and contributed by people who first wrote a thing they wanted and then put it in the game. In reality, a lot of the widgets, esepcially if you weight them by usefulness, were written specifically for release within ZK from inception. Often this happened because the widget was too boring for someone to write for their own use or because it requires integration. For example, I wrote the terraform GUI widget alongside the terraform gadget.

quote: It isn't.

I thought someone had said so earlier on this thread. Reading again, it seems I misunderstood.

That does make a imp ball a pain to coordinate, but then again multiple imp detonations against one target are not an efficient strategy.