NeoLemmix - Quo vadis?

[Nepster]

If a player wants less complexity, meaning less objects and less skills to choose from, they should probably play original Lemmings or ONML first. Custom packs aren't for beginners, as has been pointed out again in the recent thread about introductory levels. And if a player has tackled the DMA-based packs in NeoLemmix, there are still plenty of more restrictive packs to choose from, as you and Nessy and many other people have created them, packs which e.g. stick to classic skills only.

I do however highly doubt that a reduced number of features equals reduced complexity. Unless you consider Nepster Lems non-complex. It doesn't use a lot of skills, tilesets, or objects, which is probably also due to the time it was first created, but it's complex simply by the size of its levels and the design of its terrain.

Paralems, on the other hand, employs nearly every feature NeoLemmix has to offer - but I doubt anyone here found it particularly complex to play through . It simply has a lot of variety, but it is not a very challenging pack.

You confuse complexity and difficulty: NepsterLems may be very difficult, but there are only very few game mechanics to learn, so there is little complexity in there.
On the other hand ParaLems has lots of different objects, that the player has to learn what they are and how they work. This is complexity. On the other hand, finding the solutions once one knows what all parts of the level do, is (at least compared to NepsterLems) relatively easy. This means relatively low complexity.

I know it's easy to bring pixel precision on oneself . And on some levels I did indeed feel I might still have found a backroute. I just considered it very unlikely, since this pack has existed for quite some time now, and both IchoTolot and namida have done LPs of it, that any backroutes could still be remaining in there.

I admire the genius stuff you have come up with on many of these levels, but the fact that they are so challenging is simultaneously their downfall: I just can't play a lot of these in succession to each other. Each level is a mystery to solve on its own; however, the only thing which happens once you do succeed is unveiling another mindf*ck riddle.

Well, no pack is ever backroute-free. And I value even partial feedback, e.g. regarding the first two or three ranks.

IchoTolot once talked about himself wanting to "beat the player", and doing so fair and square, and cited your levels as prime examples. And it's true, they certainly aim for beating the player, as if each single one of them asked "Am I the level where you're finally going to quit?" This is great for providing challenges, but comes at the cost of easily killing the player's motivation.

Beating the player was not my intention (except with the very last level, but the preview text should warn you there). It was more a challenge for myself to come up with something new using only the very old game mechanics.

The old formats has one huge problem: I don't know anything about how the data is stored in the .lvl, .dat and .nxp files. So it's basically impossible for me to add any new features to the old formats, or to improve the existing editor.

Is namida the only one with any knowledge about the old format code? If it's written in an entirely different language, I know this kind of knowledge can't just easily be transferred from one person to another (I just experienced that because some fellow students basically hoped for me to quickly explain half a year worth of Python stuff to them last week ). But if this is mainly a case of "namida understands format A, I understand format B", then a "NepsterNeoLemmix" would make even more sense. Because it's two entirely different people with entirely different philosophies designing two entirely different engines.

The basic problem is, that everything is saved in a binary file, which makes it extremely hard to read back the info. So even if I knew (and this info is available) that the save requirement is saved in bytes 1234 and 1235, reading it back is a huge chore. This is still relatively easy when done with the same programming language that was used to store the binary file, but reading a binary file with C# that was created in Delphi is extremely nasty.
The second problem is, that binary files are not flexible at all. Here one example: Water objects can be resized horizontally in the new-formats. For this we have to store another integer for water objects. However the old formats only allows a fixed byte size for every water object, so we don't have enough space in the current binary format to store everything. This in turn means, that I would have to introduce another binary format to store the new levels and read them back in.
Incidentally that is the reason why there are already four or five different .lvl file types, each storing the level information in slightly different ways. Supporting that is a huge mess, which I will never ever tough for fear to destroy the backwards-compatibility. On the other hand, text-based file formats are extremely flexible and if I implement new features, then I can still use the previous algorithm to load and save the level. It just has to be modified slightly.

[Strato Incendus]

You confuse complexity and difficulty

We can argue definitions of what counts as "complex" or "difficult" all day. The bottom line we keep coming back to, because you keep emphasizing it as your goal, is "friendliness towards new players".

Confronting a new player with NepsterLems would be just as pointless as overwhelming him with the feature diversity of Paralems: Frustration would kick in way too soon, because it takes a while to figure out all the things you can do even with just the classic skills. So a new player should be pointed towards either original Lemmings, or something like SubLems or CasuaLemmings.

A more seasoned player (let's define this as someone who has played through original Lemmings and ONML) will seek for new challenges in one way or another. For some players, this will consist of taking only things they already know, but taking them to great extremes, like Nepster Lems or Lemmings Migration. For others, it will mean getting into contact with new skills, like swimmers, fencers, and disarmers, or objects, like splitters, teleporters, and possibly also radiation and slowfreeze. Indeed, for someone who has played through original Lemmings and original ONML, the concept of radiation shouldn't be that foreign, apart from the fact that the countdown takes longer. And then it just makes sense for the other lethal skill (the stoner) to have a similar thing (slowfreeze).

Hence, there is no point in trying to "protect" players from over-complexity, or from the challenge of memorising lots of things. Because players will seek these challenges for themselves, and they will also pick and choose which type of challenge they prefer. Just look at all the people messing around with kieranmillar's levels, and how many features (mostly different types of skills) they have to memorise! Yet, they seem to enjoy it, including some execution-based pain that comes with the fan in Lemmings 2.

With keeping existing features, you do not restrict people in any way to still enjoy the "purist", restricted and more "conservative" type of challenge Nepster Lems, Lemmings Migration etc. have to offer, while at the same time leaving all options open for people who prefer different designs. If we all agreed that we wanted your types of levels only, as great as they are, we could simply go back to playing (Super) Lemmini, because mechanically NepsterLems could easily also have been created for that platform, whereas many other packs couldn't.

Hence, why the need to reduce the number of features NeoLemmix has when these reduced engines are already out there, in peaceful co-existence?

With removing features, in contrast, you slowly transform NeoLemmix back to its roots until your type of challenge is pretty much the only one which can still be created. Which will at some point leave players bored, or at least "annoyed". Playing through your pack is certainly not boring, but at least for me it gets annoying pretty quickly , no offense here. And I don't mean "annoying" by "frustrating". It's more that when I have just solved a complicated level, click continue and instantly see the next huge open-ended chaos maze pop up, I don't really have the energy left to wrap my head around that right away. I will most likely exit the programm and return to it sometime later... much later... and then it's nice to have something more light and refreshing for the meantime, something totally different.

Currently however, you're taking a lot of this fun stuff away, which will streamline the content which can be created a lot, rather than allowing for an open and free market of ideas, where less popular levels just don't receive much attention, but aren't entirely prevented from being built.

It was sort of surprising to me that among the levels nin10doadict skipped in his LP of Pit Lems, like "Check mate" and "You had it coming", were the ones I had deliberately created in a way most akin to your level building style . I wanted to create something challenging, taking your levels as a good example, and challenging is what the levels became - with the result of people skipping them ^^. Even when nin10adict did solve the level in the end, he was sure I had created it just for trolling.

Water objects can be resized horizontally in the new-formats.

I don't quite understand what you mean by that. Do you want to change the size of the trigger areas of water? Or be able to do that in the level editor?

[Nepster]

You confuse complexity and difficulty

We can argue definitions of what counts as "complex" or "difficult" all day. The bottom line we keep coming back to, because you keep emphasizing it as your goal, is "friendliness towards new players".

Well, and while high complexity of the game mechanics is unfriendly towards newer players, high difficulty is not. Yes, new players will solve neither, but the difference is in their reaction when they see the solutions somewhere else: Is it "Oh, I didn't know you couldn't do that/this object worked like that!" or is it "Oh, I never tried this approach!".

Hence, why the need to reduce the number of features NeoLemmix has when these reduced engines are already out there, in peaceful co-existence?

To improve NeoLemmix. And the other engines don't have similarly nice user interfaces.

Water objects can be resized horizontally in the new-formats.

I don't quite understand what you mean by that. Do you want to change the size of the trigger areas of water? Or be able to do that in the level editor?

In the level editor you can specify how wide the water should be. Both the sprite and the trigger area are resized automatically.

[Strato Incendus]

In the level editor you can specify how wide the water should be. Both the sprite and the trigger area are resized automatically.

Ok, that's certainly neat and all, but is it really necessary to create this option? Most water areas are 8 pixels wide, right? So when I want a, let's say, 12 pixel water pit, I just push two water objects so far into each other that they together form the exact size I want.

To improve NeoLemmix.

I still don't see the improvement which is supposed to result from fewer options. Trends come and go in NeoLemmix. Before SQron entered the community, time limits used to be a big no-no unless absolutely necessary for a level. Now there are forum members who consider them (quote Arty) "a nice breath of fresh air".

I could easily make an argument for culling time limits, because most puzzles don't have them anyway, so not much content would be hurt, and the community as a whole seems to like solving puzzles without this artificial pressure put on them . So, removing the option of putting time limits on levels would encourage level creators to create better levels which are difficult in a fair way.

[Nepster]

In the level editor you can specify how wide the water should be. Both the sprite and the trigger area are resized automatically.

Ok, that's certainly neat and all, but is it really necessary to create this option? Most water areas are 8 pixels wide, right? So when I want a, let's say, 12 pixel water pit, I just push two water objects so far into each other that they together form the exact size I want.

Usual water pieces are 64 pixels wide. And the same option applies to one-way-walls and quite a few other object types.

I could easily make an argument for culling time limits, because most puzzles don't have them anyway, so not much content would be hurt, and the community as a whole seems to like solving puzzles without this artificial pressure put on them . So, removing the option of putting time limits on levels would encourage level creators to create better levels which are difficult in a fair way.

Yes, I know. Simon made these good arguments, too, before removing time limits in Lix. But I expect that a great majority of NeoLemmix users will prefer keeping the option of having time limits. So I won't suggest this, given the problems I have with my suggestions to remove far less liked features. Sometimes one has to be realistic

[Strato Incendus]

Usual water pieces are 64 pixels wide.

Ah, yes, I counted the number of STRG steps (which are 8), each of which jumps 8 pixels wide, rather than the pixels themselves . Still, the same logic applies: I can move two water pieces pixel by pixel to decide how wide the area is supposed to be as a whole.

For one way-walls, admittedly, the arrows might look a little silly if one were to try that. But since they only have an effect when on terrain anyway, over-extending one way-walls have never been a problem for me to date. I'd really have to think of a specific corner case where this might somehow become relevant. And if that corner case occured, I'd probably take the drawback of the one way-arrows slightly overlapping from putting two areas into each other to decrease their overall size.

[Nepster]

But what if you wanted a water pit that is only 16 pixels wide?

[namida]

Another advantage: Suppose you had water all along the bottom of your (for example) 1280 pixel wide level. You later decide to make the level taller. If you've used a bunch of individual water pieces, that's 20 water pieces you need to move - sure, you can select multiple, but you need to either select them one-by-one, or use a selection box then manually unselect any objects / terrain that you don't want to move that got caught.

With the new system, you can instead place one water piece and resize it to 1280px wide. Then there's only one object to move (or delete, if applicable) when needed.

In the case of objects where the trigger area doesn't extend all the way to the edge (or beyond the edge, in some cases), resized objects also handle this a bit better than multiple overlapping ones would.

A single resized object also has slightly better performance than multiple standard-size ones, although to be fair you'd need to either be playing on a pretty weak PC and/or dealing with a very large and complex level before this becomes noticable.

The new formats definitely offer a lot of advantages to both content creators and end users; but these culls are definitely putting its overall adoption in jepoardy. (Of course, given that it's open source, there's always the option of someone simply releasing a forked version that re-adds these features, too...)

[Strato Incendus]

But what if you wanted a water pit that is only 16 pixels wide?

I'd hide it between the terrain pieces where it's supposed to be. Water pits rarely float in thin air .

Of course, your modifications to this offer a lot more flexibility, it's not that I don't notice that . But, as namida has correctly pointed out, when the decision is between minor inconveniences and forfeiting actually level-defining elements, I'd always take even the clunky old NeoLemmix 1.43 over the smoother, yet option- and feature-wise reduced new engine:

The new formats definitely offer a lot of advantages to both content creators and end users; but these culls are definitely putting its overall adoption in jepoardy.

It's mainly the fencer and the possibility of combining a multitude of graphic sets which make me create levels for 10.13. When it's clear right from the start that a level isn't supposed to have gimmicks, 10.13 is the version with more options, so I go with that one. It's always about "What inspires you to create a level?" For me, skills and their combinations do. And that's why skills are the main thing for me to change an engine, like I also tried Lix as soon as I had some jumper + walker ideas (since L2 has the jumper, but not the walker).

Just like the fencer leads me to 10.13, the shimmier and later on jumper might also make me friends with the new formats version. Easier use of creating water areas or graphic sets are a nice addendum, of course, but if it's for their sake alone, I'll take options over convenience any day.

(Of course, given that it's open source, there's always the option of someone simply releasing a forked version that re-adds these features, too...)

Yay, more alternative versions! I guess I'm going to have to learn Delphi then and implement the Fencer into NeoLemmix 1.43... I really miss it in "Lemmicks"! Would have been interesting to see it interact with the hardworkers gimmick... or having a ghost fence... or an instant fencer pickup skill...

[Ryemanni]

Resizing the water and one way arrows automatically is very useful. It was one of my top-wanted features for the new editor.

[IchoTolot]

Some users were complaining about NL to stagnate and I think it has to do mainly with there only being 1 person on the code side of things now.

After I've finished up United and rewrote the NL manual, I could try and read myself into the code and help Nepster to speed up processes and reduce pressure.

It will take a long time to get myself into the massive block of code though and I will probably have to sacrifice a ton of free time before I start to be useful there + also I need to learn C# and Delphi in which I don't have programming experience in (I have mostly programmed in Java during my computer science bachelor), but I think we need reinforcements on this front more than anything else!

[Strato Incendus]

Props to you if you want to help out on that front, IchoTolot!

My programming language skills are currently still restricted to Python (I think Arty was working on something in Python to make a specific ArtLems level work?) You said that C# and Delphi are also new languages to you, however I guess with a computer science degree, you have more preexisting knowledge to build on.

So instead, I could rather help out on the sprites side of things; with all the different NeoLemmix sprites that exist for New Formats now, we are going to need recoloured versions of the shimmier sprite to go along with the Shadow, Highland, Egyptian etc. tribe.

These PNG files are independent of the programming, I think, so if Raymanni or Nepster can send me the strip-png of the shimmier sprite, I could get to work on converting it to the different tribes currently available .

That said, I'm not sure whether "NL stagnating" refers to the development of the program itself, or to the development of content for the program .

[Nepster]

Thanks a lot, IchoTolot! Any help is very welcome, and C# is conceptually rather similar to Java, so it shouldn't be a big step to get used to C#. Delphi on the other hand is a bit more low-level and has sometimes rather weird syntax, but if you know some statically typed language, it shouldn't be such a big step. At least I could understand it without much problems and modify it by copy-pasting stuff.
I guess the larger problem will indeed be getting used to the overall structure and where the code is for what part of the application. But at least the NeoLemmix code got a lot better in the past few years in that regard. Anyway, I can always tell you the part of the code you need to look at and then you can start placing breakpoints and debugging through it to learn how that part works. Usually one doesn't need to know all that much code to start becoming productive.