The Neverending Lemmix Story

[EricLang]

A little update:
After trying a better remake of Lemmix with
-the programming language C# (no control over memory, too slow: discarded)
-then in the programming language Rust (I gave up after 6 months, the language is too complicated and too restrictive)

I discovered the (not even finished) language "Zig" which is very promising.
I started with the lemming-mechanics which work now and I have a bet with a friend:
He thinks A.I. can solve lemminglevels and I think not. The easy levels yes, difficult levels no.

So now I am building a simulator to be used with A.I. and we need insane speed for that. That is where this Zig-language comes in.

My original plan was anyway to slightly change the mechanics and I was wondering what people think about it.
Here is a short list:

-If a lemming exits the world (bottom, top, right, left) he will always die.
-(not sure yet) when reaching the top of the level they do *not* turn around.
-Steel is pixel-based instead of block-based.
-Steel is really really indestructable  (even if it is hidden behind other terrain).
-Bashers, miners and diggers will immediately stop when encountering a (masked) collision with steel, even if it is one pixel.
-Bashers, miners and diggers *always* accept their job even if they will fail because of steel. I think this reflects their brainpower better

There is one exception to the rule: the miner does not stop if there is steel at the first (high) stroke. I discovered that is irritating.

-The 'jumper elevator bug' is kept intact. That one is to cool to remove.

edit: Ah I forgot one thing. the sprites and mechanics will be 100% symmetrical (for example the difference for LeftToRight or RightToLeft builders will be gone).

To be continued...

[namida]

I suspect if you want optimal speed, C or C++ will likely be the way to go.

Make sure to segregate physics and visuals as much as possible. If the engine is rendering the gameplay even when it doesn't need to display it (such as when being solved by an AI; or a real-world case, mass replay checking in NeoLemmix, Lix and Loap all avoid rendering as much as possible), it's a significant hit to performance. Seperating these in NeoLemmix was quite difficult; it was much easier to achieve in Loap because it was designed as such from the start.

[EricLang]

Very true. there is no rendering involved. It will be completely separated, it always disturbed me.
I know visuals are deeply embedded inside the existing Lemmix. And NeoLemmix as well I think. Loap I do not know what that is.
It was quite some work to skip frames fast exluding all visuals.
Zig is faster than C.

[Mindless]

C# (no control over memory, too slow: discarded)

C# is definitely viable for game development.  The only heap allocation that Golems (programmed in C#) does in the main game loop is the creation of save states for rewinding; everything else is pre-allocated or is allocated on the stack.  And .NET is definitely not too slow -- it can outperform C in some cases.  There can be challenges, for sure, but don't write it off.

[WillLem]

Good to hear you're still working on Lemmix, Eric. Looking forward to your next revision!

Some thoughts on your suggestions:

-If a lemming exits the world (bottom, top, right, left) he will always die.

Very strongly against this.

SuperLemmix has force-field sides (lemmings react as if they've hit a Blocker) which make far more sense to me but are controversial. Solid sides make less sense but at least keep the lemmings alive and active in the level.

Deadly sides are the most popular, though, so you probably won't hear from anybody other than me on this particular mechanic. I just thought it was worth throwing in my two cents whilst I can!

-(not sure yet) when reaching the top of the level they do *not* turn around.

Do you mean Builders, or any lemming in any state?

-Steel is pixel-based instead of block-based.

Can you provide a picture example of what you mean here?

-Steel is really really indestructable  (even if it is hidden behind other terrain).

Strongly in favour of this.

Bonus points if you can remove the terrain layer and reveal the steel beneath in the event of pixel destruction within in the steel area (for example, by a nearby Bomber). I'm currently trying to find a way to do that in SuperLemmix, but the NeoLemmix steel code is very much not set up for this!

-Bashers, miners and diggers *always* accept their job even if they will fail because of steel. I think this reflects their brainpower better

Haha, I like your thinking, but... wouldn't this waste skills unnecessarily?

-The 'jumper elevator bug' is kept intact. That one is to cool to remove.

Please can you explain this one, I'm not sure what you're referring to.

the sprites and mechanics will be 100% symmetrical (for example the difference for LeftToRight or RightToLeft builders will be gone).

Very strongly in favour.

[namida]

I know visuals are deeply embedded inside the existing Lemmix. And NeoLemmix as well I think. Loap I do not know what that is.

NeoLemmix seperates them, but not completely. Some of this is unavoidable - there's no way to know the shape of a terrain piece other than by loading the graphic. But the majority of rendering is avoided when in mass replay check mode.

Loap is a clone of Lemmings 3D that I made a while back (and on a side note, is also written in C#).

[EricLang]

C# (no control over memory, too slow: discarded)

C# is definitely viable for game development.  The only heap allocation that Golems (programmed in C#) does in the main game loop is the creation of save states for rewinding; everything else is pre-allocated or is allocated on the stack.  And .NET is definitely not too slow -- it can outperform C in some cases.  There can be challenges, for sure, but don't write it off.

True. C# is quite cool and can be very fast. But I really dislike lowlevel stuff and the garbage collection. Of course it is very good if you do not have any heap allocation!

[EricLang]

@WilLem: I am not yet sure about everything. There are quite some insane details to handle...
A level-boundary-forcefield is a very viable idea as well.


Regarding turn-around stuff: In Lemmix there was this call everywhere to CheckIfWeAreAtTheCeilingAndIfSoThenTurnAround
Which lead to strange situations sometimes. And yes: I think the builders turn at leveltop.

Steel in the dos-levels are virtual blocks, in 99.8% of the cases put behind the typical steel blocks.
I plan to make the tiles themselves to be 'made of steel'. Thus we have a pixel precise collision check.
More or less the same I plan to do with one-way-walls: pixelprecise instead of a virtual square.

Reveiling steel would be nice... but that is quite some insane task which requires double layers of terrain. I think it is too dramatic

Haha, I like your thinking, but... wouldn't this waste skills unnecessarily?

Yes!

The elevator bug (as I call it) is when a jumper gets stuck inside a one pixel gap and goes up the terrain. On my Lemmix github I think somewhere a bit hidden is that ccexplores testlevel dedicated to this.

Furthermore: I discovered that - directly after lemmings change action, for example from walker to miner - always the first animation of the new action is missed.
I think I want to change that.

In general the idea is to stay very close to the orginal mechanics but more precise.