Hi,



We have a fat buzzsaw buzzing. Zzzzzssss. And a lix.
Should the lix die if she touches the saw with her foot?
Should the lix die if she touches the saw with her head?
Should the lix die if she touches the saw with her body? She would pass through small terrain gaps.
What happens when she's a climber? The climber's head has a different x-coordinate than the foot.
What happens when she's a platformer? A platformer's head is lower than a walker's.

If we check at the head at all, should mechanics depend on the spritesheet? C++ Lix examines the spritesheet for the eye, then checks there. The examination happens at program start, not at compile time. You affect physics when you alter the spritesheet. In total, C++ Lix checks for traps at (foot), (4 hi-res pixels above the foot), and (eye).

I'm considering to check at (n hi-res pixels above the foot) for n = 0, 4, 8, 12, or even for n = 0, 2, 4, 6, 8, 10, 12. The check would be independent of the lix's job. Both ideas catch the thin laser beams, these beams have a thickness of 4 hi-res pixels.

12 hi-res pixels over the foot is slightly lower than a walker's eye. Walker's eyes are bopping up and down at 13 and 14 hi-res pixels above the foot. The lix in the image would still burn. 12 pixels is considerably higher than a platformer's eye at 7 to 10 pixels. In a minority of platformer frames, even the hair is below 12 pixels.

Earlier discussion with geoo, beginning right after the colorful github pushes.
<geoo> I'm not sure what's best here, really. Maybe make a thread.

-- Simon

Here are three arguments, you might want to consider:
1) Displaying the level (e.g. looking at Lix sprites) is a totally different part of the program than applying the game physics (e.g. checking trigger areas). So it makes sense to keep them separated as much as possible.

2) The sprite sheet is easily available to all users. So a lemmings fanatic might consider the Lix sprites heresy and change them into the lemmings sprites. Later this user notices that several of the traps no longer work and reports a very obscure bug, that cannot be replicated...
The user will never guess the cause of the bug themselves, because the dependency on certain gray pixels in the Lix sprites is honestly something noone would ever expect.

3) Lix players will never discover the current rule for trigger checks themselves. On the other hand it is quite easy to create levels abusing the change of trigger checks for platformer. Such levels will get almost impossible and totally frustrating for uninformed players. If you want to test this claim, let others playtest the attached level.  

I agree with all of these points. An excellent treatment of the problem.

Do prefer a strict, skill-independent rule over a per-skill rule, even if the per-skill rule were independent from the spritesheet?

Lovely example level. I lose a cuber and the miner, saving 8/9. Is there a way to save the miner?

-- Simon

Of course there is a way to solve the level . Saving 8/10 Lix is possible regardless of the implementation of the trigger area checks, btw.

And "per-skill rule is independent from the spritesheet" does only take care of the first two arguments, while only "skill-independent rule instead per-skill rule" removes problem 3).

Yep, got it now. This solution doesn't feel hackish, but I am used to these trigger checks. The D port migration will be an excellent opportunity to simplify mechanics.

There's a good easier puzzle in this level. Even with platformers grilled under the sawblade, 90 % of the level idea can be salvaged.

Agree on discoverability of the mechanics. The skill-independent checks can be at the foot only, or at several points above the foot, too. I like the checks at several points, because all traps so far are designed with this in mind. A trap works different from an exit, where the foot must be at the door. Different opinions welcome.

-- Simon