beyond-all-reason / spring

A powerful free cross-platform RTS game engine
https://beyond-all-reason.github.io/spring/
Other
182 stars 95 forks source link

Decouple water unpathability from damage #1447

Open sprunk opened 3 months ago

sprunk commented 3 months ago

Units won't path into water if its damage per tick is above 1000 (kbot/veh) or 10000 (hover). https://github.com/beyond-all-reason/spring/blob/e55ce6231a0b125f41f56688277dca95ddc7b3bd/rts/Sim/MoveTypes/MoveDefHandler.cpp#L145-L147 https://github.com/beyond-all-reason/spring/blob/e55ce6231a0b125f41f56688277dca95ddc7b3bd/rts/Sim/MoveTypes/MoveDefHandler.cpp#L67-L69

Decouple this from magic constants and let maps control it independently via some boolean flag.

As a use case example, a bunch of ZK FFA maps have "tar" around them (water with no damage but filled with explicit 0 speed mod terrain to prevent boat shenanigans) but this fails because it is done via terrain typemap so is tied to the XZ location and not Y. So you can terraform a platform above the tar (and it will still have the 0 mod) or sink a regular part of the terrain down (which won't have the modifier and you can swim in tar).


Ground units also become more reluctant to path into damaging water as its DPS increases (via CMoveMath::waterDamageCost). This could become configurable too. I am unsure how a good interface to define the formula would look; ZK doesn't care much about this part because we use raw move.

marcushutchings commented 3 months ago

I think it should be configurable at the MoveDef level (pathing system needs to be made aware.)

marcushutchings commented 3 months ago

I also think we need to figure out how to stop raw move happily pathing units through damaging water. Would it make sense to fail a raw move check if the unit would walk through any damaging water or are there cases where it should be allowed?

marcushutchings commented 3 months ago

From my experience of playing C&C, players don't appreciate units voluntarily entering damaging zones unless they explicitly ask them to go through. So I'm not sure this strength based on damage makes sense. Generally, they either don't care or don't want it entered at all.

marcushutchings commented 3 months ago

@Beherith this topic will be of interest to you.

marcushutchings commented 3 months ago

At the moment, raw move will reject a path if it hits an area whose move cost exceeds a configurable threshold. Is that good enough or do we need something more clever?

sprunk commented 3 months ago

Some sort of way to mark areas as "only enter if the endpoint is inside" would be decent.

@GoogleFrog FYI (pathing through acid, raw move through acid)

GoogleFrog commented 2 months ago

What? I haven't noticed anything wrong with the current default. There are probably bad cases, but mappers are avoiding them.

sprunk commented 2 months ago

There's this 1v1 map with an acid/lava pool where units will happily path through it using ZK raw move. image

The question is whether you have any thoughts on how engine default non-raw move, and default engine raw move, should approach this (up to adding some new interface to configure it).

6AKU66 commented 2 months ago

Also some units can survive travelling via lava. So, sometimes players would want to via lava.

GoogleFrog commented 2 months ago

I think putting semi-damaging water in the path of units is a bad idea and should be avoided. Acid around the outside of maps is fine, lava that nothing wants to path into is fine. So I don't have a reference point for the design decision of how to deal with such cases, I'd just suggest never getting into that situation in the first place.

It sounds like what I would want is a callout which lua can use to ask how much damage a particular unitDefID (or maybe movedef) would take if it were standing at position x,y,z. But I don't want to pay the overhead of putting that in the raw move gadget for the one map where that would be relevant, so the question of how it should work overall is moot.

What you could do in the engine is look at the damage dealt by the move goal, and then avoid pathing into areas that deal (some configurable amount) more than that damage. So if you click on a damaging area, areas that deal that much damage or less are considered open. Otherwise units path around damage. And if this were exposed to lua in some super cheap way (maybe a damage threshold parameter in the existing "can I path here" check), then I'd put it into the gadget too.