As well as implementing Classic Mode, which globally deactivates a number of features (some of which can be individually deactivated when not in Classic Mode), a number of changes to the Config menu have taken place:

Removed support for Online Features - Default sprites and styles are different in SuperLemmix, so it doesn't make sense to keep it connected to online features for NeoLemmix (not to mention that there's no reason that namida's NeoLemmix website should continue to support other forks such as SuperLemmix). Styles will therefore be manually updated periodically, and there will always be an up-to-date all-styles download available from the release topic.

"Don't Replay After Backwards Frameskips" has been re-named "Replay After Backwards Frameskips", and the checkbox function has been inverted to match.

Support for "Force Default Sprites", "Linear Resampling In-Game" and "Hide Advanced Options in Level Select" has been dropped. For the most part, this is to tidy up the menu a bit, but it's also because I'd personally rather not support these options in SuperLemmix.

Note that most of these have currently only been "soft-removed", and the code is still in place but has been commented out. I can always add these options back in if there's enough demand.

Graphics Options now has its own tab, to keep the interface tidy.

A "Reset Window" button has been added which auto-checks Reset Window Size and Reset Window Position at the same time.

Added option to choose between "Yippee!" and "Boing!" for the Exit sound.

Found the single line of code today which prevents Fallers, Splatters, Jumpers and Reachers from exiting upon contact with the exit trigger

Direct Drop re-implemented in Commit 2fb7a1fc5 along with Jumpers & Reachers being able to exit.

SuperLemmix will ship with the following packs:

DMA Compilation Pack - all OG levels fully restored and with relevant logos. This project is in progress and is nearly complete.

SuperLemmix Welcome Pack - this will include levels showcasing any engine-specific features that don't appear in NeoLemmix.

All menu graphics will be updated so that SuperLemmix is immediately visually different from NeoLemmix. These images will remain user-customisable, of course.

I'd also like to have each line of level preview text be different colours, like in the Amiga version (and also (Super)Lemmini(Too)).

Where I'm up to with this:

All menu graphics have now been updated. They may require further revision in the future, but are good enough for an initial release

I'm looking at how to change the colour of the font per-line on the level preview screen. I can't find the code that determines what is written here (although I have found the code which determines the clickable text at the bottom, and have modified the colour of these).

Re-inroduce Superlemming mode
- The mode will be available as a checkbox option in the Editor: "Activate Superlemming mode"
- Player-side, when active the framerate cap will increase to {?}, and all physics will move at {?}FPS | OR | the fast-forward button will be activated (least favourable option due to varying speeds)

Where I'm up to with this:

I'm unsure exactly where to begin with this one.

Thinking that it might be worth looking at how Superlemming mode worked in Lemmix, old formats NeoLemmix and SuperLemmini, and also have a look at how Lix handles the variable fast-forward speeds.

Here is a useful document about how the application handles when not processing code. This may come in useful when looking at implementing Superlemming mode.

I'm interested to get as many people's thoughts on this as possible.

Should levels only be solved by their intended solution? Should all other solutions be backroute-fixed, patched-out, or at most grudgingly accepted?

Or, can alternatives be happily accepted, but only if they're better than what's intended? Or even, should alternatives always be happily accepted because the player has found a different way to beat your level with the skills and situation that you've provided?

So then, should alternatives be outright encouraged, providing a skillset which enables multiple possible solutions, all of which are intended either by design or in spirit? This can be quite difficult to get right without making a level trivial.

On a wild note, should backroutes be encouraged? Or, is this just another way of saying "alternate solutions" in the event that the designer hasn't felt the need to prevent anything other than the intended solution?

I suppose what I'm really asking here is what's in the title: Why is the intended solution so important? It seems to me that there are so many other possible scenarios by which both designer and player can be satisfied, so what's the deal with packs which exclusively provide "do-this-only-as-intended" levels?

---

Maybe here's what's happening.

A scenario which comes up many times is that a designer will create a level, and a player will find a way to solve it with a solution which isn't intended. In that scenario, the player has "beat" the designer.

The designer must then take their level back to the drawing board and find a way to fix it so that only their intended solution is possible. We've all been there!

It gets beaten again, by another overlooked backroute. The level must be revised again. And again. And AGAIN! Until finally, in version 27.4, the level cannot be beaten by any solution other than the intended one.

But now, the player cannot solve the level. They don't know the obscure trick or they can't quite piece together the extensively complex series of actions which must be done in just the right order. Finally, the designer has "beat" the player.

But, neither of these situations is really what anybody wants. The player doesn't want a level they can't solve and the designer doesn't want their level to remain unsolved (not forever, anyway).

So, ideally, the player manages to figure out the intended solution, and at that point they have "matched" the designer. Nobody has "beaten" anybody: the player can own the fact that they figured out the solution, and at the same time the designer can be proud that their challenge worked as intended.

Maybe it's this then: if a level is solved by the solution intended, there are no winners and no losers. Everbody comes out on an even playing field, where wisdom and knowledge prevail.

Thoughts?

SuperLemmix is a new fork of NeoLemmix. The following is a list of proposals which I am going to at least try to implement, with help :

Re-introduce timed bombers as a new skill: the Timebomber!

Re-inroduce Superlemming mode!

Re-introduce the Grenader skill

Re-introduce Direct Drop (and other exiting mechanics!)

New skill panel

Modify the existing skills

Modify some of the water objects

New UI graphics (logo, menu, pre-screens etc)

Introduce a "Classic Mode" which disables all modern player-assist features

Include all of the fully restored original DMA level packs

Create and maintain a SuperLemmix Welcome Pack

Editor updates to account for the above

And, some absolute dreamland features:

Online multiplayer mode (yes, I'm laughing at myself as I type this).

"Typed" lemmings and matching exits which only allow lemmings of that type (I'd probably start by allowing mixing of Lemmings and Lemminas, and having exits specific to each. I'm a million miles away from being able to actually do this, though!) - this will likely need to happen in the event of a multiplayer mode anyway.

And, some other stuff I can't think of right now but that I've likely already created topics for somewhere on the Forums. I'll add them back to this list if I care enough about the ideas at this point.

Merged from 3 topics:

[DISC][FORK] SuperLemmix
[DISC][FORK] Adding Timed Bombers Back To NeoLemmix (Optionally)
[SuperLemmix] Timed Bombers

---

Note: Wherever the "oh no!" phase is mentioned in this post, it can be assumed that I'm also taking into account bombers exploding immediately in midair if the lem is a faller.

---

So, NeoLemmix is approaching its final version.

It's been a wish of mine since I first played NeoLemmix that the engine have a full-on "Classic" mode, which automatically disables all player assists (direction select, skill shadows, framestepping, splat ruler, CPM, etc) and leaves behind only the basic essentials, which I'd list as:

Pause (no assignments)
Fast-forward
Skill panel hotkeys (up, down and numbered)
Release rate hotkeys (only for up & down, no min/max jump)

And that's it! And, of course, timed bombers would be enabled in this mode as well. At present, it's theoretically possible to achieve all of the above except the timed bombers, since they don't exist in the current version of NeoLemmix.

I therefore propose a new fork of NeoLemmix (which I'd likely call SuperLemmix ) which allows both, optionally of course!

Unfortunately, adding timed bombers back to NeoLemmix is not as straightforward as copying and pasting the old code back in, as untimed bombers bring about a number of complications which would have to be addressed if both are to exist in the same engine. The current implementation of optional timed bombers in SuperLemminiToo has made some of these complications very apparent. Namely:

1) The actual assignment of the bomber would have to occur at the beginning of the "oh no!" phase, regardless of which option is applied. This is to prevent broken replays (i.e. the same replay should work regardless of bomber option). So, it would go like this:

With timed bombers enabled, clicking the lemming starts the 5 second timer, at the end of which the "oh no!" phase begins and the bomber assignment is written into the replay. In the case of untimed bombers, clicking the lemming starts the "oh no!" phase and writes the bomber assignment immediately, as per current behaviour.

2) For the first 5 seconds of each level, it must be possible for explosions to happen regardless of which option is applied, otherwise any level requiring an untimed bomber assignment within the first 5 seconds would be rendered impossible by having timed bombers enabled. I can think of only one way around this:

With timed bombers enabled, bombers assigned during the first 5 seconds of the level become "hot bombers," a new state which would have to be created for the purposes of the fork. The timer begins its countdown, but the lemming glows red. If clicked again, it skips the remaining timer countdown and goes straight to the "oh no!" phase. After the first 5 seconds of the level have passed, the lemming ceases to be a hot bomber and reverts back to a normal lemming, even if mid-timer.

This, as far as I can tell, allows the lemming to be both a timed and an untimed bomber simultaneously for just the first 5 seconds of a level. It only matters for the first 5 seconds, because after that timed bombers begin the "oh no!" phase anyway, as per untimed bombers.

There is only one problem with this.

If a level requires an immediate explosion on the first frame, even "hot bombers" can't account for this, since they require 2 clicks in order to explode, which costs 2 frames of game time. A level could be designed such that a single pixel would matter, and if the faller has advanced by even a single additional frame, we have a bug.

A possible fix for this would be to have the first frame of every level be a frozen "-1" frame iff timed bombers are enabled. This would allow the player to assign the bomber on frame -1, causing the lem to enter the "hot bomber" state, and then explode the bomber on frame 0. For frame -1, it must be impossible to assign any other skills, and the timer must not yet have started. In real time, of course, this would happen so fast that it would be almost imperceptible. But, for any level requiring that amount of precision during its opening frame, the code would be there to account for it.

As far as I can tell, the above proposal fixes the "first 5 seconds" problem. There may be something else that I've overlooked though, of course.

It also goes without saying that in the case of untimed bombers, current behaviour applies, but I thought I'd say it anyway

---

So, that's my idea. If I ever get around to learning programming properly, I'll definitely want to do this. If any existing Delphi programmers see this post and like the idea, please get in touch with me and allow me to be involved in the process of creating the proposed new fork! I'll want to give the UI a bit of a tweak as well, to differentiate it visually from NeoLemmix as it currently is.

Of course, at this point, this is all pie in the sky and might never happen. But, discussion is what Forums are for, so...