NeoLemmixSharp

[∫tan x dx]

Hi all!

For some time now I've been working on a new lemmings engine. I'd like to introduce NeoLemmixSharp!

NeoLemmixSharp is designed to be a "superset" of the features of regular NeoLemmix. The engine is intended to be backward compatible with NeoLemmix, aiming for 99.9% compatibility. That is, the intention is that the vast majority of existing NeoLemmix levels should play identically in the new engine, and the few that do not are hopefully easy to tweak.
In addition to the features expected of NeoLemmix, a greatly expanded feature set is planned. These features draw inspiration from various sources, including lots of concepts from Lemmings Revolution.

This is a completely new engine written in C#. The project is very much still in development; even the name "NeoLemmixSharp" is temporary!
I've attached a design doc outlining some of my plans for the engine.

I intend for development of this new engine and its various features to be driven by the community. Feedback, suggestions and contributions are welcome!

Github repo

Let me know what you think!

[Mindless]

It certainly sounds like a good idea to be compatible with NeoLemmix given that it's where most of the level-design activity is happening, but -- reading though that design doc -- that's a lot of game mechanics.  Personally, I prefer games with fewer mechanics -- especially in the case of puzzle games.  But given the popularity of NeoLemmix compared to Lemmix, I seem to be in the minority.

[Simon]

C# 13, DotNet 9) and uses the MonoGame framework.

I'll have to see how to install a build toolchain for this on Linux. It should be possible; your choice of technologies is popular and MonoGame says it's available for Linux.

I'll report my results after a serious attempt to build. Happy to help you write build instructions afterward.

sole exception to this [all interaction happens via skill assignments] is when the player may modify the release rate of a hatch.

Will you remove exiting during the nuke? Or did you merely not list the nuke as a second exception?

"anchor pixel", is used for both terrain and gadget collisions
additional "foot pixel" that counts towards gadget checks only

It feels more natural to use only the foot (and never the ground under the foot) for both terrain and gadgets. Did you consider this? What problems will arise from this?

When you import NL levels, you'll then raise the trigger rectangle to work with the foot alone (instead of shrinking the trigger rectangle vertically to work with two separate pixels).

aiming for 99.9% compatibility

What kind of level will behave differently? Or is the 99.9% a blanket figure to allow potential future incompatibilites?

I guess: NL gadgets with 1-pixel-high trigger rectangles will not convert functionally-identically to your two-pixel collision in NeoLemmixSharp.

-- Simon

[∫tan x dx]

Will you remove exiting during the nuke? Or did you merely not list the nuke as a second exception?

No, the nuking functionality will remain unchanged. I just forgot to mention that possibility.

It feels more natural to use only the foot (and never the ground under the foot) for both terrain and gadgets. Did you consider this? What problems will arise from this?

What should occur in this case? Under the current behaviours (anchor pixel), a lemming will drown when it touches the water. Given the commitment to replicating NeoLemmix mechanics as much as possible, we need to preserve this behaviour.
If we switch to using the foot pixel to determine movement and collisions, then there will have to be extra checks to see if the pixel beneath the foot is within a hitbox. Fundamentally, there is no real difference between this and just using the anchor pixel. Changing it would also potentially lead to messier code.

What kind of level will behave differently? Or is the 99.9% a blanket figure to allow potential future incompatibilites?

The 99.9% statement is indeed a blanket figure. In regards to incompatibilities, levels which feature gadgets (water/fire/exit, etc) that have been rotated will most likely not function in the same way as expected. This is due to the differences in how hitboxes are rotated between engines. WillLem has had similar experiences in SuperLemmix, changing the way hitboxes rotate with the gadget. NeoLemmixSharp will behave similarly to SuperLemmix in this manner.

That said, what is also planned is the ability to define separate collisions for different orientations. That is, if a lemming has gravity oriented down, then it will check one hitbox, whereas a lemming whose gravity is oriented to the left would use a different hitbox.
This will have the most noticable effect on long, thin gadgets, such as flamethrowers.
As for one-pixel-tall hitboxes, this will indeed need to be special cased. As a result, these gadgets will have a hitbox that is functionally two pixels tall.
I can think of at least one gadget that would be affected by this: the horizontal electricity hazard in the dex_industry style (along with its counterpart in dex_circuit).

[namida]

If we switch to using the foot pixel to determine movement and collisions, then there will have to be extra checks to see if the pixel beneath the foot is within a hitbox. Fundamentally, there is no real difference between this and just using the anchor pixel. Changing it would also potentially lead to messier code.

Alternatively, you could simply move trigger areas upwards by one pixel compared to where NL would place them. The only place this would end up functioning differently to NL is the top and bottom rows of pixels, and neither is particularly likely to have a trigger area there that doesn't extend higher/lower than just that one row and is significantly affected by this change (and I'd question what kind of fair level even could have such an object, though I wouldn't outright rule out that there's a way).

On the other hand, if a similar change is applied to climbers, I can see that being a bit harder to handle in a way that's always consistent with NL.

[Simon]

You raise the trigger rectangle by 1 pixel at tile-import time.

I'll argue: The cyan outline is fairer UX-wise than the pink rectangle. It's now obvious that walking across the grey surface is deadly. And it's obvious for tile creators (who must define the pink/cyan rectangles) to avoid the typical mistake of making the bottom row harmless. Tile creators can now match the visible rectangle to the visible water, and get correct physics.

You already give no guarantees that trigger areas rotate as in NL. And different gravities have no precedence in NL. You can also do anything you like with different gravities without breaking back-compat.

namida, what exactly do you fear for climbers? I imagine that tan x will keep the climber foot inside the wall (what I consider strange, but necessary for NL compatibility)? All collisions will happen a pixel higher, against trigger rectangles that also moved higher. I don't see a problem. What is it?

-- Simon

[∫tan x dx]

I fail to see the point of making these changes.
Fundamentally, a lemming needs to make collision checks with the pixel beneath its feet.

The current system makes use of the anchor pixel for these primary collision checks. This implementation gives the desired behaviour, without overcomplicating things.

If the system were to be changed to use the foot pixel instead, there would have to be separate checks for collisions one pixel beneath the lemming's foot (relative to gravity). Making this change would mean a vast amount of code would have to be re-written, which could also introduce a lot of bugs.

What possible reasons are there for changing this? I really don't understand the problem at all.

[Simon]

use only the foot (and never the ground under the foot) for both terrain and gadgets

Ah, yes, my wording was unnecessarily wide. I don't want to focus on the terrain collision here.

Let me retract the quote and ask instead: When you collide gadgets with lemmings, instead of colliding two pixels (the foot, and one-below-foot), have you considered colliding only the foot?

The conversion work stays similar: On importing NL tilesets, you'll have to change trigger areas either way. Either you shorten their height, or you raise them. And you collide at one new position (where NL didn't collide), at the foot.

But it improves UX. All three of tile designers, level designers, and players will profit, as in my paragraph "The cyan outline is fairer UX-wise [...]". Isolated from any programming/redesigning work/bugs, do you see value in the cyan box, compared to the pink area?

-- Simon

[WillLem]

The engine is intended to be backward compatible with NeoLemmix, aiming for 99.9% compatibility.

It certainly sounds like a good idea to be compatible with NeoLemmix given that it's where most of the level-design activity is happening

By all means keep the same level file format so that NL levels can potentially be played; this is definitely a good idea, for the reason given by Mindless.

However, I'd encourage you to branch out from NL physics/design/etc as much as you want with your engine; the great thing about creating a new engine is that you can try new things without worrying about existing content.

Good to see that you're keeping some of the traditional gameplay elements (e.g. timed bombers) and making them optional so that players can tweak the gameplay as they wish. A particularly great idea is the scoring system which rewards traditional-style play by docking points for using pause, framestepping, etc. One suggestion I'd offer here is to make the scoring a bit more visible either by a medal system or a "S, A, B, C, D" scoring (used in Sonic The Hedgehog games but also pretty widespread); a certain points threshold awards a certain letter.

That way, instead of fnishing the level and seeing "36,208", you'd see "A / Gold" or "B / Silver". It means more to the player and signals that the score could have been improved upon; it would be necessary, then, to have some way of calculating the maximum possible score for any given level.

Anyway, some great ideas in the PDF! Looking forward to seeing the engine when it's ready, happy to help with anything if you need it.

[∫tan x dx]

When you collide gadgets with lemmings, instead of colliding two pixels (the foot, and one-below-foot), have you considered colliding only the foot?

Unfortunately, that is not going to be an option. One key difference in the new engine is that gadgets can now act as solid terrain.

Lemmings will be able to walk on gadgets such as metal grates, water lemmings will treat water as solid, and so on. As such, the hitbox of such a gadget will have to be treated identically to terrain. Hence, anchor pixel checks for terrain/gadget collision (solid gadgets), foot pixel checks for other gadget collisions (non-solid gadgets).

[namida]

namida, what exactly do you fear for climbers? I imagine that tan x will keep the climber foot inside the wall (what I consider strange, but necessary for NL compatibility)? All collisions will happen a pixel higher, against trigger rectangles that also moved higher. I don't see a problem. What is it?

-- Simon

Imagine a flamethrower object placed such that the trigger area extends to cover the last pixel outside the wall, but does not go into the wall. With the "pin inside the wall" setup, the climber passes by this flamethrower safely. With the pin outside the wall, he gets burninated.

All other cases (except Sliders, which are basically just Climbers that move downwards instead of upwards) can be addressed simply with a corresponding 1px rise in the trigger area heights, but the climber case - where moving the pin outside the wall also involves horizontal movement - is not as straightforward, and would appear to require either level adjustments or a special case. (In general - I've found that "pin inside terrain", although perhaps counterintuitive from a visual point of view, just seems to work better from a programming point of view in general - even in non-Lemmings games. I took a similar approach in the Commander Keen fangame I made a while back.)

[Simon]

have you considered colliding only the foot?

gadgets can now act as solid terrain.
hitbox of such a gadget will have to be treated identically to terrain.
Hence, anchor pixel checks for terrain/gadget collision (solid gadgets), foot pixel checks for other gadget collisions (non-solid gadgets).

Right, I had seen gadgets-as-solid in your document, and I don't see how it is a counter-argument to colliding only the foot (never the anchor) for drowning, and only the anchor for walking on water. Neither from a conceptual standpoint, nor from a technical standpoint, nor from performance.

I'll write a proper argument to this on the weekend.

"pin inside the wall" setup, the climber passes by this flamethrower safely. With the pin outside the wall, he gets burninated.

Horizontal change vs. NL, hmm. It's more intuitive to collide with gadgets on the outside, but that will break compatibility more than tan x wants to break.

You're right with the flamethrower for out-of-wall pins. And your oh-noers would fall when you bomb mid-climb.

"pin inside terrain", although perhaps counterintuitive from a visual point of view

This visual counterintuitivity is the heart of the matter.

The visualization of the trigger area shouldn't rely on implementation choices. Tileset designers and level designers don't write physics code. Compared to what NL 12.14 shows, you should show the area one higher, regardless of implementation. It should look like it collides with the lemming when it does collide.

Tileset designers and level designers have fallen for the misdesign in the past. Now tan x is finally fixing the bottom (tileset designers won't accidentally allow walking across the bottom of water anymore), good. But then it's painful to see more complicated physics rather than a fixed top, too.

-- Simon

[∫tan x dx]

This visual counterintuitivity is the heart of the matter.

I really don't think this is an issue that needs solving at all.



That ship has sailed a long time ago. The original lemmings engine shipped with this exact kind of visual counterintuivity baked into it.
Players are confused at first, but adapt quickly. The notion that a lemming's hitbox is beneath its feet is something that players can quickly adapt to.

At any rate, I will NOT be changing this functionality in my engine.

[Simon]

Sorry, with "counterintuitivity", I wasn't talking about reactions to solidity. I'm aware of your desired level of back-compat. I mean, I was already not prodding for, e.g., climber outside terrain.

I'll try at the weekend to make my concern clear enough. Not much time today.

-- Simon

[mobius]

I skimmed through the design doc and can only say I completely agree with the initial goals/themes. These are things I always felt were really important (for honestly most games not just Lemmings).

When adding new features there's always a period where the game feels overwhelming until players get used to everything then it seems normal. The reason I always pushed for new features is why I'm presently not very active at all; eventually the game gets stale and uninteresting.

Some of the most interesting (and at times complex) challenges I've seen is trying challenge solutions to Lemmings Revolution; such as (assign 1 skill to each lemming or only one lemming.)

to give some feedback answer questions:

Moveable/expandable gadgets:
this sounds quite fascinating. Moving platforms make sense though sound very complicated to implement in practice. Stretchable terrain (apart from rising water) sounds totally foreign to me.

-on what should happen if a builder encounters and open door; what you call a metal grate:
 I always understood yet found Revolution's mechanic to feel wonky. What would make more sense to me is if the builder could build straight through open doors. If the doors were to close later, the builder bricks that are inside the door should be destroyed. That seems logical to me and fits with the grinder gadget's behavior as well.
 
-the game Chips Challenge 2 has logic gates with its many buttons and you can literally build a mini-computer inside of a level This also makes for some mind-boggling possibilities like essentially re-creating other games like simon says or Tetris within the game. Here, more simply, I could see it useful for example, for demanding that one or a group of lemmings get to specific spots of a level that would be difficult to enforce otherwise.

aw I'm sad you won't have lemming mining into water. <joking>

NGL my thoughts on Revolutions "walk on water" mechanic while interesting was always kinda janky. What always made more sense to me was a "water lemmings" either being kind of permanently a swimmer or just walking through/under water (on the bottom of the tank say) ignoring it completely. Although I admit at first glance that doesn't really add much to the game?