Flamelike weapons

[tuturto]

Have you thought of what it would require to have a flamer type of weapon? An area of effect item, that would spread from the user and fan out like a flame or cone? Walls would block the cone, maybe characters would too. It would probably be a bit problematic for the AI to use, because of the possible collateral damage.

[Mikolaj]

Interesting. We already have blasts (explosions), but they just work by emitting many projectiles in all directions, starting from the item that causes the effect. Yes, AI is currently stupid about damaging its own actors when throwing, e.g., potions that create a blast when they hit the ground. But since actors are moving all the time and potions travel slowly, it's hard even for humans to tell whom the explosion would hit.

I guess for cone attacks an actor would just projects many missiles in the given direction. The game content for the items in question would need to specify the number of projectiles (as it does for blasts) and the angle of the cone. The direction comes from the fling (project) UI and AI command.

The question remains where the projectile items should come from. Normally, when flinging, they come from the actor's inventory. When performing a blast, they are created ex nihilo. E.g., for potions, they have specifications of the form OnSmash (Explode "healing mist"), which means when they are smashed on the ground, they cause the explosion. Perhaps we'd need OnProject (\dir -> Cone "healing cone" angle dir) and when flinging an item we'd have a check that instead of projecting it, causes the effect (applied to the direction of the fling). The Cone effect would create and propel many projectiles (the number and kind taken from a cone 'item' definition) in a cone.

[Mikolaj]

That actually sounds like a very sane extension that fits very well the existing framework, so I even wanted to label it "medium" instead of "hard". But the devil is in the details, and there are many details here to work out. Even such annoying things as the Effect type no longer having many automatically derived standard instances, because the new OnProject constructor takes a function. Still, this sounds like fun.

[Mikolaj]

How does it sound? Are projectiles emitted in a cone enough? They can be very fast and there can be very many of them, so they discreetly mimic a continuous effect quite well, I guess. However, currently we don't have piercing projectiles (though they are planned), so (a segment of) the cone will be blocked completely by any actor in the way. So this is not strictly an area effect. Anything else I missed?

[tuturto]

This sounds like sensible way of implementing it. Cone being blocked by any actor could actually look pretty great, as it is possible to hide behind other actors and thus avoid the damage. Would all the projectiles be emitted at the same time, instanteniously, or is it possible to have them to be emitted over a time? The latter one would probably be quite complicated to implement properly and without bugs, so I'm thinking that instantenious would work too.

[Mikolaj]

Ah, right, we don't want a wave, but a cone. Perhaps it makes sense to hard-code it somehow. Actually it would also make sense for explosions, because even the dense ones currently look a bit too much like 1-projectile-thick expanding spheres. There is already an exception (which I don't remember very well) where an explosion is blocked heavily near the origin, in which case some of the projectiles originate in an adjacent tile and it looks more fuzzy and natural (and prevents too weak explosions e.g., in corridor dead ends). If we also hack something like this for cones (with different starting tiles, or otherwise), perhaps we can generalize this and perhaps even make it customizable in game content.

That sounds orthogonal to cones, so I guess we could just start with waves that don't behave well if emitted in a corridor (because most of the projectiles hits walls quickly) and iterate from there (in reality, most of the time, a portion of the wave would bounce off the walls, but bouncing projectiles sound too complex, so I'd rather implement this otherwise; e.g., there is no unambiguous deflection angle against a diagonal wall comprised of wall tiles with only horizontal and vertical sides).

Note that you could already emit projectiles with a couple of different speeds by having multiple OnProject Cone effects in the content description for the same item, each Cone with a different kind of projectiles, varying in speeds. That should look like a focused flame that quickly stops flowing from the flame-thrower, but as it travels in the cone, it's no longer focused, no longer leaves a given area quickly and covers more and more area both in width and in length as it goes. The problem is the content gets complex and verbose (both in the cone definition and also you need to to multiply the definitions of the cone projectile 'items', differing only in speeds). So far I've never defined explosions in this way --- it would be too hard to maintain and tweak.

An implementation where not the speeds, but the starting times of the projectiles differ has some extra problems. We'd risk that the player that very quickly walks in the direction of his just emitted cone might bump into the last wave of his projectiles, which would be a nasty surprise. Even without different starting times, this would be possible, e.g., if a fast projectile emits slow cones (or explosions) as it flies (with a Periodic effect). But that is specified in game content, so it can be tweaked easily until it works, while can't easily specify different starting times in content. (Perhaps we could add a 'Delayed timeDelta (...)' effect constructor, but it's not been useful for anything so far. I rather use Periodic that destroys an item after the first (or a given number of) effect activation for that.)

Edited to expand some ideas.