The latest experimental version of the player containing the Shimmier features a minor annoyance which doesn't seem to have anything to do with the introduction of the new skill at all:

The "Let's go!" sound at the beginning of a level is only presented on the left ear exclusively, no matter how far to the right the hatch is placed. Since the location of the sound usually tries to emulate the position of the hatch relative to the camera, meaning the sound will wander from left to right if you move the camera around before releasing the pause button, I guess there's something off with that location-determining routine? Because the sound file itself did not change, so there's nothing wrong with the inherent panorama information of the WAV file.

It's especially striking because the hatch opening sound which comes immediately afterwards is presented on both ears again, dead centre .

Well, what this seemingly useless hobby of creating fictional problems for fictional little green-haired people can be useful for sometimes : I'm currently trying to backroute my own stuff.
Not so much my Lemmings levels, though (Arty is taking care of that! ), but my writing.

And indeed I think the concept of the backroute might be a good idea for any hobby writer or similar in order to clear up inconsistencies in their stories:

As someone who is guilty of somewhat enjoying criticising other people's works for plotholes and similar, of course I try to be equally strict with myself - even though it's just a hobby of mine . And one thing I've noticed is that a lot of logical missteps in stories arise from overpowered skills or items - kinda like in Lemmings .

One famous example would be the time reversal tool in Harry Potter (don't know what exactly it's called in the English original); as soon as an author adds something as powerful as time travel / teleportation / telepathy / telekinesis (funny how these all start with t ), that always begs the question: "Well, why didn't the characters use this in situation A / B / C?"

Likewise, in Lemmings, once a skill is on the panel, you must always consider the option of the player employing that skill in a totally different place than you expected them to - and that is just as valid, until you come up with a way to prevent it without simultaneously preventing it from being used in the intended location as well.


Human beings, both while playing Lemmings as well as in real life, like to take the path of least resistance. Which means, if there is an easier solution to something and it's apparent to them, they will usually use it. In essence, you could consider backroute searching an application of Ockham's razor, always asking the question: "Is there an easier way to do this?"

So it's nothing new, far from it; however, thinking of plotholes as backroutes to intended solutions gave me somewhat of a new incentive to actively try looking for such inconsistencies in my stories myself . It feels like a more "scientific" approach, where you actively try to falsify your own claims.



So, why did it take playing a lot of Lemmings in order for me to discover this for myself?

Maybe it is due to the more or less established mindset of a backroute in a level being usually regarded as the level designer's fault - combined with the awareness that it is in a level designer's power, and thereby their responsibility, to fix it. With plotholes in stories, in contrast, you often find both the authors as well as devoted fans rationalising the events after the fact, making additional assumptions in order to make excuses. This is because both the loyal fans and, obviously, the authors themselves, have already "locked in" on the intended solution, and now try their best to enforce it.

Hence, in both cases, it is usually easier for level testers / beta readers to discover "backroutes". And I think this is down to the same phenomenon that prevents a level designer or story author from finding it : I've already mentioned functional fixedness and mental set before on this forum - aspects of problem solving which mean that once we found a working solution to a given problem, we have a hard time coming up with possible alternatives.

This affects both level designers / authors and players / readers:
1) The author knows the intended solution, which obviously works, so they have trouble contemplating other solutions that might also work - because it would require them to actively stray from an already successful approach.
2) The reader is presumed to have a natural scepticism that needs to be overcome in order to achieve immersion in the story (suspension of disbelief); if common sense would suggest a less complex and more obvious approach to a problem, and a character still decides to do it in a more complicated way, it's going to ruin the immersion, because usually people don't act this way in real life.
The Lemmings player, likewise, is naturally "lazy" in the sense that he doesn't want to waste more time on a level than necessary. So once he finds a solution that works, there's no need to keep fiddling around to try something else: You find a backroute, you go for it. And then, later, once that backroute has been removed, re-solving these levels is often harder than solving new ones, because now you have to actively bypass the formerly successful approach which you still have somewhere in the back of your head.

Thus, the author can't stop not finding backroutes, and the player can't stop using them if they find them. The reader can't ignore a plothole once it's discovered, and trying to ignore them in order to  re-immerse onself in the story requires active endeavour on one's own part.



The irony is that this mechanism is probably usually beneficial: The Rubicon model makes a clear distinction between considering different options at first, and then, once you have decided on the one you're going to use, initiating action. Meaning: You don't go back to the planning phase anymore . No way "back to the drawing board". I also like to think of this as "putting blinders on a horse before having it move forward" .

But backroutes and plotholes fall into the category "what must not be cannot be", and in those cases, you have to force yourself to go back to the drawing board. So for such purposes, this mechanism seems to be disadvantageous.


Don't really know how useful or interesting this might be to anyone of you, but I like discovering such "patterns" by drawing analogies between seemingly totally unrelated fields. Sometimes, these analogies may end up a little too forced. (That's why my brother and I refer to these shitty analogies as analogies .)

But if I didn't enjoy looking for abstract patterns and ways to connect the dots between them, I probably wouldn't enjoy playing Lemmings either in the first place. So I guess we've come full circle here .


Any other "life lessons" you guys learned from playing Lemmings, no matter how arbitrary they may seem?

In the same vein as Crane proposing the reversal of a change that has been made a while ago , I'm going to bring up another thing from the past:

If you remember, around the time of the major format switch last year, the idea of neutral lemmings was being discussed. Skills were not supposed to be assigned to them, like with zombies, but in contrast to zombies, they could still be saved, or even had to be saved.

I don't know if that idea is still being ventilated, but I think a lot more puzzle potential actually lies in a thing we already had back in the day, which was the exact opposite: Ghost lemmings. They could not be saved, however they could be assigned skills, and they didn't interact with any kind of objects. This allowed them to walk through fire, traps, and water alike, doing things like mining or digging at the bottom of a water pit, which isn't possible otherwise.

Ghosts were removed together with gimmicks, and with regard to the latter, I understand how they would have slowed down every new implementation of a feature a lot. Having to balance e.g. a new skill with all these extra rules would have been pretty chaotic, obviously.

Ghosts, however, actually require less interaction in total than even regular lemmings! They simply treat all objects, including exits, as if they were background objects. So I can't imagine they would require a lot of code, plus the sprites are already there. Ghost sprites for new skills introduced in the meantime (=fencers and shimmiers) can easily be recoloured, just like we have created different lemmings sprites for the L2 tilesets.

There was one issue with the original ghosts, however: They always came as pre-assigned lemmings, i.e. either they were pre-placed lemmings or came out of pre-assigned hatches, like zombies.

That made me realise what a ghost actually is: Just another skill! So why not re-introduce ghosts as skills that can be assigned like any other?

This would make the ghost a unique hybrid of lethal skills (like bombers and stoners) and athletic skills (like climbers and floaters):

You can get past certain obstacles with him which no other lemming can get by - for example, fire traps - but in exchange for this enormous power, the lemming itself is sacrificed (since an exit is also an object, so he can't enter it anymore either). Athletes, often employed as pioneers, usually take paths the rest of the crowd can't take, and their task is to then create an alternative path for said crowd.

In some sense, ghosts are actually a more balanced version of the disarmer - because they can go through traps like disarmers can, but leave them active. The disarmer seems to be the least favourite skill at the moment, mainly because levels involving it boil down to
1) collect the disarmer as a pickup skill, the level is auto-solve from there;
2) pure timing-challenges, stalling the crowd until the disarmer gets his job done;
or 3) the crowd takes exactly the same path as the disarmer pioneer, because there's no difference between a disarmer and a regular lemming once a trap has been deactivated.

Some people even advised for disarmers to be culled during the format shift. While I of course will always be against such a move, I do have to say, if we still have even disarmers, there's no reason why we shouldn't have ghosts as well .

Also, it's in spirit (*badum-tss*!) of the Halloween season !

So, turns out that both Colorful Arty and Flopsy experienced considerable frustration on a couple of single levels (albeit fortunately on different ones for each person ) from my pack Lemmings World Tour, arising from pixel precision caused by minor but decisive conceptual mistakes. Meaning, this pixel precision was not at all part of the intended solution, but the level didn't outright prevent you from attempting the pixel-precise approach either.

Hence, I'm beginning to wonder whether I should purposefully reduce the complexity of levels on a conceptual level to prevent people from inflicting such unintended pixel precision on themselves.

We all agree that we usually don't want to put pixel precision into levels intentionally; however, we do want our levels do be challenging on a conceptual level, and as IchoTolot pointed out, one main factor that creates difficult level concepts is entropy, i.e. "it's not very obvious which skill has to go where, or which path you can take".

If I want to decrease player frustration by preventing them from getting on tracks that lead to self-inflicted pixel precision, I necessarily also have to reduce the entropy of the level, so that the player doesn't even consider going along a path that might lead to frustration.

Let me show you an older example, not from Lemmings World Tour, but from Lemmicks, where the consequences were less drastic (meaning Flopsy didn't get too angry about this, but it still took him about half an hour to solve the level):


Here comes the flood

In his LP, Flopsy tried for a brief period of time to climb up the right hand side of the level. I'm not refering to the solid level sides in version 1.43 here, but about building towards the steel wall next to the exit so that a climber can reach it and go up. Eventually, he found out this isn't possible, and I didn't even consider anyone attempting this, because the intended solution is the path on the left.

Now, I could close that gap on the right with even more steel, so that it would be clear right away that you can't climb up there. That means players won't even attempt to fiddle around at that spot. At the same time, this reduces the entropy of the level, because everything points you towards going along the left right away. So, would you seal the gap on the right, or wouldn't you?

This question can be extended to one-way arrows: While they are good to patch out backroutes, they also have the tendency of quite literally pointing the player towards a certain path they are supposed to take. So while they prevent certain unwanted alternative solutions, they also simultaneously give away a little more about the intended solution. Which is why I generally only want to use as many one-way arrows as necessary, even if it comes at the cost of a backroute in the first release of a pack.

I have come to recognise that I tend to be the "libertarian" voice on the forums, so just like I generally want as many design elements as possible to remain available to people and see culls as a form of "censorship" , I'd also prefer to leave more responsibility to the player, rather than patronising them by showing them too clearly what they can and cannot do. I'm not talking about actually hiding things from them, like hidden traps or exits, but about the forum-consensus ideal of "hiding things in plain sight".

So with that mindset, every player remains the architect of their own (mis-)fortune. I've brought it on myself with two of Nepster's and two of Nessy's levels, where I went for a more precise solution rather than the intended one. Since then, if something seems overly fiddly to pull off, I tend to seek the fault with myself for not having found the actual intended solution yet. But maybe that mindset just comes to me easily, given that I could barely complete any custom packs so far, but usually get stuck somewhere in the low middle . So in general, it's more likely that I as a player mess up than that the creator messed up.

But there are probably going to be different stances on this . The problem with self-inflicted pixel precision is that you don't see it coming, because those are unintended solutions, like backroutes.

We all agree that backroutes need to be patched out: Backroutes make the level easier than it's supposed to be.
Cases of self-caused pixel precision are the opposite of backroutes: They make the level harder than they're supposed to be.

So would you patch out "garden paths", too, even if it comes at the cost of giving away major aspects of the intended solution?

I created a custom sound for my leaf trap in the Autumn tileset. I inserted it into the Old Formats graphic set tool, because I'm more familiar with that one. The conversion of the tileset itself went fine, but the trap is silent in New Formats.

I know there is a sounds folder, and I put the sound in there, too. But I have no idea on how I have to name it in order for it to be recognised. This doesn't seem to be part of the translation table or anything along those lines.

If it's too difficult to make the Graphic Set Conversion tool take care of custom sounds as well, please at least make it part of the graphic set conversion instructions, so that any graphic set creator knows how to do this manually.

I don't know whether this is a bug or intentional (in the latter case, it would mean yet another culled feature), but moving background objects do not move in the editor. In fact, it isn't even possible to enter a direction of movement for them.

Inside the player, it works for a level from SEB Lems I tried out - Mother O'Donoghue - but not for my converted Autumn tileset level (the leaves remain static in the air).

I know that triggered decorations have been removed in New Formats, but moving background objects are a different category.

I also mentioned this in my graphic sets thread, but I think it gets lost there easily, so I bring it up here again.

I think I've found a way to solve two remaining issues with the new editor and level conversion at one fell swoop!

One of the few remaining distinctive features of the old formats editor - and one of the main reasons why people like Arty and me oftentimes still prefer the old editor - is the option to replace a piece that has already been placed in the level by hitting F9 and selecting a different piece from the list. This allows for several things:

1) Quickly selecting a new piece from the same tileset as the selected piece while the main graphic set may be a different one (for example, your main tileset is pillar, but you've taken a trap from dirt, and want to exchange it for another trap from dirt)
2) Replacing a piece with a tile from a different graphic set while keeping it in the exact same spot

It is the latter that would simultaneously also solve the issue we currently still have going on with the Ancient tileset (and also my custom edits to the old original Lemmings graphic sets, btw!) .

If a replace feature, as it has already been present in the old editor, also existed in new formats, one could do the following:

1) Create a temporary conversion of the complete old Ancient tileset.
2) Load up the level in the new editor.
3) Select the pieces from the ancient tileset and replace them with the identical pieces from "angel island" or "chaos angel", in this case. Everything now remains in the exact same spot as before!
4) Once all tiles have been replaced with their counterparts, delete the temporary conversion of the Ancient tileset. The level from now on consists of tiles from "angel island" and "chaos angel".

I could do the same with my custom edits of the fire, brick, and pillar tileset, of course: Temporarily convert mine, replace all tiles with the identical ones from the standard new formats versions, then delete my custom conversion.

I wouldn't be requesting this if it were only to fix my own mess with regards to the custom edits of the standard lemmings graphic sets . As I said, it also solves the issue with the Ancient tileset that has been split up into two sets in new formats, and that affects anyone who has ever used Ancient.

And, most of all, this tile replacement option is simply a generally useful and convenient feature that has been present in the old formats version anyway, and many users have come to enjoy it!

Even though it's probably still going to take some time until the Shimmier is test-ready, I already have some ideas in mind, and would therefore like to create the terrain shapes ahead of time in order not to forget them .

But for that purpose, I need to know from Nepster what the intended behaviour of the Shimmier is going to look like.

1) As far as I remember, the Shimmier starts with a straight vertical jump. What's the minimum and maximum height the Shimmier will be able to jump this way?
2) Are direct transitions from Climber to Shimmier going to be possible, like in Lemmings 2 (I doubt this, because it would require the Climber to do the "hanging" animation at the ceiling)?
3) Are there any ways to stop a Shimmier to make him fall off the ceiling earlier, rather than waiting for him to hit a wall (e.g. with a walker)?
4) When I bomb or stone a Climber, there is the oh-no animation while he is stuck to the wall. Can we expect the same for Shimmiers, or is a Shimmier turned Bomber / Stoner going to fall off the ceiling?
5) Will it be possible to (ab-)use the Shimmier merely for height gain, for example to get above an updraft and then assign a Glider?
6) If it is indeed possible to assign skills during the initial jump, will a Shimmier turned Bomber or Stoner during the vertical jump explode / stone in mid-air without the oh-no part?
7) Can Shimmiers only go along straight edges, like Climbers, or are they going to be able to compensate for a couple of pixels worth of slopes, like Bashers can? I remember that in Lemmings 2, they could shimmy along the bottom of the Outdoor grass pieces, which is not at all a straight edge.