Runners Bypass Exit, Walkers Exit (Weird Lix Physics)

[Blitz]

Today I was scrolling through my replays and found very weird physics like the lix that is walking is allowed but the lixes that were running were not allowed and that was a close game my brother would have won if the lixes werent running

[Simon]

Excellent find, thanks!

I agree that, yes, these runners should exit.

Explanation: Runners run by performing twice per tick what a walker does once per tick. The bug is now: We look for exits only at the start and at the end of a physics update, not during the skill performances. Normally, that's not a big problem because fast-moving skills (faller, tumbler, ...) can't exit anyway. But runners move fast and can exit.

-- Simon

[Ramon]

This would have been a nice entry in my "unintuitive and obscure Lix tricks waiting to be culled by Simon" level series 

[Simon]

Indeed, it's the same conceptual roblem as in:
github #132: Walker bypasses trap, faller is killed

... which Ramond reported for C++ Lix around 2014.

Walker-to-faller covers more than one pixel per tick, too. Traps (one-lix-at-a-time-eating traps, not fire nor water) collide with lix only at the end of a tick. The lix knows about the trap collision, but doesn't know which trap or exit it was.

-- Simon

[namida]

Indeed, it's the same conceptual roblem as in:
github #132: Walker bypasses trap, faller is killed

... which Ramond reported for C++ Lix around 2014.

Walker-to-faller covers more than one pixel per tick, too. Traps (one-lix-at-a-time-eating traps, not fire nor water) collide with lix only at the end of a tick. The lix knows about the trap collision, but doesn't know which trap or exit it was.

-- Simon

NeoLemmix handles this by comparing the lemming's position at the start and at the end of each update, and checking for interactive objects along the entire path between those points (I'm not 100% sure of the exact rules it uses to determine when to move horizontal vs vertical, Nepster wrote that part, though some skills - most notably the Jumper - have overrides from the default behavior, and of course a special case exists for teleporting where it specifically does not check the inbetween points, not that Lix needs to worry about that one) when it does the object checks.

[Simon]

NeoLemmix
checking for interactive objects along the entire path

That's a good approach, and Lix has tracked fire and water along the path for 10 years.

But I've never tracked exits or triggered traps like this. I omitted this 10 years ago because it was harder to design for exits/traps. We need know into which exact one of the many exits/traps the lix went.

The correct solution seems to be: If a lix moves several pixels per physics update, (e.g., the runner moves forward, then forward), and we reach an exit/fire/water/a hungry trap/... after one of the individual movements, we must stop short the entire movement for that frame.

In other words: Movement within each physics update should be written as a program in a domain-specific language. The engine interprets/executes that program. Touching exits stops further execution of that inner language for this lix in this physics update. Ideally, the domain-specific language will then consist of high-level verbs such as "walk forward", "fly forward", "fall down", ..., which have different conditions on surrounding ground, and they all require the physics update of this lix to have not encountered hungry traps yet.

This yet another ingredient for my planned Lemmings physics manifesto.

Added this bug to the 2025 roadmap.

-- Simon