Status: Added a copy of the player to the ZIP.

---

QuoteThe editor has not been updated. The latest version remains V1.40n, which can be downloaded here:
http://www.neolemmix.com/old/neolemmixeditor.zip (For new users)
http://www.neolemmix.com/old/NeoLemmixEditor.exe (For existing users with older versions)

Contents of the new-user-package:
NeoLemmixEditor.exe  styles
NeoLemmixEditor.ini  ReadMe.txt

I recommend to add the NL player to this new-user bundle.

Reasoning: People get stuck on how to test levels. Improving the error message is good. Designing the error out of existence is better.

-- Simon

Status: Reclassified as a suggestion, as - while possibly considered a bad design decision - the current behaviour is intended, so changing it is a suggestion.

Implemented for next update, as an option. Default setting is off.

How to format your forum messages like a pro!

Links

• You can dump the address in the text, without any tag around it, and hope the forum software recognizes it.
  http://www.example.com → http://www.example.com
  
  
• Alternatively, put [url] around the address, to guarantee linkification:
  [url]http://www.example.com[/url] → http://www.example.com
  
  
• For very noble formatting, you can rename the link via [url=address]:
  [url=http://www.example.com]Example Website[/url] → Example Website
  

Named spoiler tags

[spoiler]Secret message[/spoiler] becomes:

Spoiler

Secret message

[spoiler=Custom clickable text]Secret message[/spoiler] becomes:

Custom clickable text

Secret message

Copying other people's formatting

You see other people's posts, and wonder how they got the formatting right.

Click "quote" on their post. Their message's source code will appear for you to edit. Study the source code to see how they formatted their text.

---

Icho has raged! With spoiler tags, the always-visible name goes into the tag, and the content goes between the tags. With URLs, the always-visible link name goes between the tags, and the URL content goes into the tag.

-- Simon

Hi,

Nepster has shown me a level that breaks in D Lix, because the terrain rendering is subtly different than in C++ Lix. We now have to decide -- which version has the bug. :-) And what our strategy should be.

The problem

Frame a) shows a terrain tile with odd dimensions, 57 x 57 pixels. There was an inconsistency in Allegro 4.x in how odd-dimensioned terrain was rotated. C++/A4 Lix built for Windows would rotate the terrain differently than C++/A4 Lix built for Linux.

To combat this inconsistency, I load the tile like frame b) in C++/A4 Lix: Odd dimensions are rounded up, padding at the right and bottom if necessary. The level format says where the top-left corner of each tile is, thus padding doesn't affect physics yet.

D/A5 Lix is written as if this bug/bugfix never existed, loads the tile like a), and rotates the tile like frame c).

C++/A4 Lix instead rotates the tile like d). Since the level format remembers the top-left corner of the rotated tile, the padding introduces a 1-pixel offset between the rotated tile c) and the rotated tile d).

Impact

This offset was enough to break 6 of Nepster's 107 replays.

Nepster has sent me a level where the above wooden tile, matt/earth/30, is aligned in a very precise way with the surroundings. The 1-pixel difference makes an intended walker's path impossible in D lix.

6 out of 107 is not that much. But it's enough for replay collectors to worry about this.

Solution strategies

Leave inconsistent: This doesn't require any work. We call it a bug in C++ Lix, don't fix it there, and continue to rotate like frame d). We hope that D/A5 Lix dosen't need a similar workaround, and continue to load the tiles as in frame c).

Port bug: I write code in D/A5 Lix to mimick the 1-pixel offset in C++/A4 Lix's handling of graphics and physics.

New level format: We could introduce a new level format that breaks C++/A4 Lix's forward compatibility with D/A5 levels.

geoo is considering tile-grouping instead of no-overwrite. I'm considering multiple skillsets per level, to enable handicapped games, asymmetric multiplayer maps, and different hatch numbers per player. All this would benefit highly from a better level format that allows grouping. I'd like to look into JSON or SDLang for this. <LetsAvoidMaking="Another">Bloated</XMLformat>

Unrelated improvement

No matter what we do, in D/A5, I want to infer the physics mask from the tile before rotating it, then rotate both graphics and mask. In C++/A4, I rotate the tile first with the graphics library, then check pixels of the rotated tile for solidness. This behavior as in C++/A4 has caused the inconsistency in the first place. I should have been carefully moving the graphics into place, keeping the physics simple and straightforward.

-- Simon

Hi,

the following features aren't critical to the game. I'm considering to postpone their porting from C++ Lix for now, and focus on other stuff. If there is lots of discussion emerging, I will eventually split it this into separate threads.

Player can change spawn interval during play: Dedicated thread about the VSI. At least 3 people still want to reply, but never seem to get around to.

Trampolines: They're featured in 7 out of roughly 500 singleplayer levels. By experience, they don't add value to multiplayer. They violate many assumptions of mental pathfinding with their special cases. They look like they should be fun, but they aren't fun.

Time limits: I mean singleplayer time limits, not overtime. This would need its own thread. I don't want to pour time limit oil into the VSI fire right now. But in 2016, several years after the first time limit thread, we should review the cullture that has emerged.

Time limits fuel more levels than the variable spawn interval (VSI) does. Time limits must be kept unless this is chewed through thoroughly. The VSI-problematic levels happen to have a large intersection with the time-limit-dependent levels.

L1 and L2 graphic sets: This is orthogonal to the current culture. It's a nice-to-have, and might attract conservative Lemmings fans. But it needs quite some extra handling code. Everything else has higher return-per-investment.

---

Manual screen start: Dedicated topic about dropping manual screen start. Will keep manual screen start.

-- Simon

Status: I have decided against implementing this change.

Let's learn object-oriented design with Simon, part 1.

I feel this would benefit the NL codebase, and even the Lix codebase has a few classes that are still a bit too long. No idea who else will benefit, but maybe it's entertaining.

Two disclaimers

• If this were 1995, OO would be hailed as the panacea of coding. In 2015, I will remind everyone that it's a design choice suitable for some parts of your program. It's your job to see whether it fits, or if it adds complexity that nobody needs.
• NL might not get additional skills. In that case, don't trade a debugged design for undebugged theoretical soundness. The point of a design to minimize the cost of changing and maintaining it. If you aren't going to change much, don't refactor yet.

Code will be written in a Python-D-C++-Hybrid that I make up on the spot, but I hope stuff will be most clear like this. Indentation will replace begin/end.

The main principle is to replace if-else-if-else-if-else by dynamic dispatch. Whenever you have this:

if (lem.action == walker)
    lem.updateLemmingWalker()
else if (lem.action == faller)
    lem.updateLemmingFaller()
else if (lem.action == builder)
    lem.updateLemmingBuilder()
else if ...

We can do the following instead (a naive approach, with problems still). But it will dispose of the error-prone if-else chains for now.

abstract class Lemming:
    void update():
        do nothing

class Walker extends Lemming:
    override void update():
        check ground
        move ahead or turn

class Builder extends Lemming:
    override void update():
        produce brick or not
        check if out of bricks

Then we make a container object that collects Lemmings, and put the walkers, fallers, builders, ..., inside.

foreach (lem in container):
    lem.update();

If the lemming is a walker, this code will not call Lemming.update(), which would do nothing, but instead call Walker.update(). If the lemming is a builder, the code will call Builder.update(). The code calls the correct method without us knowing what the correct method is. The code calls the correct method without us having made an if-else chain to select the correct method.

There is a problem here, because the lemmings will want to change between classes. When the builder runs out of bricks, it wants to become a walker. But a class object shall never self-destruct and replace itself with another class, because it doesn't know which references to it should be updated.

Idea for that in the next post.

-- Simon

Hi folks,

This topic is outdated. Download the newest Lix at lixgame.com!

This is a test release, with singleplayer mostly complete. This port is not finished yet -- it lacks a level editor, and it lacks multiplayer. Physics are unstable and may change between bugfixes.

Minim has designed several scaled-up versions of the internal graphics. They're visible whenever the game's resolution is at least 1.5 times as big as the old 640x480. Many thanks to Minim for this work!

Levels and terrain graphics are the same as in old C++ Lix.

I'm cross-compiling to Windows from Linux now. Let me know of any problems. Report bugs here, or open issues on github.

-- Simon

Hi folks,



Current status of D/A5 Lix

I'm 90 % feature-complete for singleplayer, and 80 % done with the singleplayer-relevant menus. In the upcoming days/weeks, I'd like to compile another test release for Windows.

Physics are similar to C++ 2015-09-02 plus geoo's physics fixes: miner cancelling prevention, refined lem order when updating physics.

Playing singleplayer levels is supported, replay saving/loading is supported. Automatic replay checking is not yet supported. Reasoning: Physics change somewhat anyway, and must be refined for a while. Manual testing of physics might be most interesting. Fewer features allow me to get the test release out sooner.

Or would someone like automated replay testing right away? Anything else that I forgot, that would be helpful for the smoke test? Bug tracker of D Lix.

Benchmarking in 2015-08

In August, I have asked people to send in their benchmarking results. As it turns out, I have the slowest machine of everybody. Therefore, I haven't analyzed the benchmark results more deeply, and instead wrote code that made myself happy. If I'm content with the performance here, probably most people will, too.

If anyone wants to make nice graphs or tables, you can download the bundled raw benchmark logs from 2015-08.

If anybody want to get entrenched and optimize drawing, they're encouraged to nag me in IRC.

geoo:

I have implemented drawing to terrain with correct semantics now. In particular, these two bugs are fixed: removers overwrote steel, adders overwrote terrain.

Drawing a miner swing takes 0.1 ms when it doesn't have to check for steel, and 7 ms (= half of a frame at 60 FPS) when the mask is copied pixel-by-pixel in a manual loop. Since in that case, it would cancel, this kind of drawing is comparatively rare. Exploders not overwriting steel are more expensive. The nuke explodes one lem a time, so it's again leveraged.

I am planning some experiments with holding the bitmap drawing. I expect this to speed up the pixel-by-pixel copying. I haven't looked into that again since you wrote the benchmark code. (Explanation of benchmark modes, and benchmark code on github before I eventually removed it from the master branch.)

Once this thread has settled, towards the weekend maybe, I'd like you to build for Windows.

-- Simon

Status: Changes have been made to prioritization algorithm, see this post. Topic remains open so how to improve it further (if nessecary) can be discussed.

Status: Changes to the framestepping / state saving and loading have been implemented that should greatly improve performance; change is included in V1.39n-B update.

Status: As of V1.37n, a red R is displayed on the info panel (between the lemming info and unspawned lemmings count) if the game is in replay mode.

Hi,

tl;dr:

Spawn interval (SI), a.k.a. release rate, should be fixed per-level. Can't change SI during play. Find counter-arguments: Suggest levels that can't be adapted with runners, jumpers, initial/required, or other features in Lix.

Why remove variable spawn interval (SI)?

Variable SI doesn't fit into the game design.

You control lems/lix by clicking on them, assigning skills. Right now, there are two extra ways to affect solutions: The nuke, and variable SI. In practice, the nuke assigns skills for you. Variable SI is an oddball, it affects lix-independent level variables.

The level author sets external variables, the player assigns skills.

Lix already allows the player to adjust spacing between lix, by walker/jumper/runner assignments. Each works differently than variable SI, but supports the game core much better. Supporting the core while solving a problem, that's the correct direction in game design.

Spawn-interval-changing solutions are prone to trial-and-error. Several players (Clam, NaOH, myself) consider SI-changing solutions less fun.

Replacements for variable SI

• Runners: I considered these superfluous before, but their use for clustering and separation has redeemed my opinion. Runners jump further, this enables level designers to enforce certain lix to become runner.
  
• Walkers or jumpers: These aren't permanent, they need different backrouting considerations than runners.
  
• Initial/required: Stream enough, but not too many after the route is built. With a fixed SI, number of initial lix becomes an important screw to adjust. Lemmings 2 had too many lems, 60 lems per level, so L2 was forced to use a fast SI. Levels became a bit bland. In Lix, you can lower the number of lems and have better fast-forward.
  
• Fast fixed SI, then let several die: Possible; but keep mass-murdering close to the beginning of a level. Players like to estimate how many lems may still die, to plan the solution.
  

What levels can't be adapted?

We have about 500 levels. My claim is that most of them can be adapted.

I believe the strongest counter-arguments (= arguments for keeping variable SI) will emerge from discussion of some existing levels, and how they use variable SI.

Proxima's earlier list of levels where the spawn interval is part of the intended solution:

• Thomas the Climber
  
• Changing of the Guards
  
• Buridan's Lix
  
• The Hotel in Hell
  
• The Continuum Hypothesis.
  

I would like to investigate these with Proxima, and with people who have solved them.

Everybody, suggest levels that can't be adapted well with other Lix mechanics, and would lose lots of their spirit.

When effective?

I don't want to change the C++ version. If I pursue fixed-only SI further, it would become a feature of the D port. So, nothing would change in the upcoming months.

Previous discussions

Discoverable UI (scrolling, dir select), where I presented the idea to the forum for the first time. Fixing SI was a proposed solution to something else, there.

Proxima suggested in here the 5 levels from the list above.

IRC: Clam, Simon, 2015-12-12

<Clam> I'd happily do without spawn interval being changeable in-game
<Clam> use FFF and don't have ridiculous amounts of rodents in the level
[...]
<SimonN> the variable SI is a fucking bug
<SimonN> heavy heavy bug, and there is a simple argument for it, about why it doesn't belong in this game
<SimonN> you control lemmings by skill assignments

IRC: NaOH, Proxima, Simon, 2015-12-20

<Proxima> Speaking as someone who's done a lot of challenges, it's a tool I use all the time
<Proxima> though of course, the point of challenges is always to do as well as you can with the tools available, removing a tool changes the game but doesn't make it impossible to challenge yourself
<NaOH> I have seen that it is very useful when attempting pixel-precise tricks
<NaOH> But I feel guilty when I use it somehow.
<SimonMath> this is dangerous :)
<SimonMath> basher staircases were removed on a similar hunch, with great effect eventually, but that wasn't all expected
<NaOH> I feel much much more guilty with basher staircases :3

IRC: geoo, Ramon, Simon, 2016-01-06

<SimonN> ARRRRRR, who wants to guess what feature I want to kill from Lix
<SimonN> With exciting new reasons, too
<SimonN> Cull, cull, cull. Summon ccx! Rise like a phoenix from deallocated memory and let us argue!
[...]
<SimonN> what affects physics, but is not assigning skills?
<Ramond__> something the player does?
<SimonN> yes
<Ramond__> wow no idea. there must be some hidden stuff I didn't know about
<SimonN> you can assign skills to make stuff happen differently, we agree on this?
<Ramond__> yes
<Ramond__> ...
<Ramond__> oh no...
<Ramond__> NO
<Ramond__> YOU DON'T MEAN
<Ramond__> NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOoooo

-- Simon

Hi,

this discussion was split off the NL issue about overwriting existing NL autoreplays.

Quote from: Simon
D Lix uses the player's name and the datetime, precise to seconds, a la
AnotherLixInTheWall2p-Simon-2015-12-02-035345.txt.

Quote from: Nepster
PPS: I'm not completely happy with Simon's D Lix replay names either: For single-player levels, the user name is useless, but the level pack and rank are important.

Quote from: Proxima on December 23, 2015, 09:09:05 PM

Quote from: Nepster on December 23, 2015, 06:23:16 PMPPS: I'm not completely happy with Simon's D Lix replay names either: For single-player levels, the user name is useless

Not when you are the level author and you are saving replays from several different users for future backroute-proofing!

Bad Lix replay naming: Agree with how pack/rank is important. I'm considering to autogenerate a directory tree inside replay/ that mirrors the tree in levels/. Solving the level
    levels/single/mypack/myrank/a.txt
creates
    replays/auto/solutions/single/mypack/myrank/a-Simon-datetime.txt,
creating missing directories in this exact full filename on the fly (mkdir -p).

I don't think auto-saving failures is needed at all. It could generate its own tree in replays/auto/failures, then it wouldn't ever clutter the solutions tree. But the failures tree would grow really quickly, almost no file would be interesting, and there's manual saving in case something is interesting.

I feel the player's name should go in the filename, with Proxima's reason. If it's really painful for some, they should write a script to mass-rename and move replays from the auto dir.

Workflow: Basically, this is the workflow I'd like to enable: User plays lots of exciting levels, then zip up a subtree of their auto/solutions/ and email that to the pack creator. The pack creator can merge that subtree with their own tree, which they might maintain outside of auto/, and run the replay verifier over a single tree.

-- Simon

Status: Since some people do like it the way it is, I'm expanding the available options for the next update. In addition to the current "Automatic name" and "Manual name" options, I've added:

> Automatic name with timestamp
> Automatic name, confirm overwrite, offer chance to specify custom name if user selects "No"

The "Timestamp" option will be the new default. This choice (rather than the confirm overwrite) is based on feedback from people who have tested it as well as theoretical discussions.

Hi folks,

the NL bug thread has grown a very exciting discussion about counting lemmings, cloners, zombies, ..., at the preview screen, and during the game. The sparking issue was the information shown in the ingame panel.

I value this discussion really much, and feel that it will be important in the upcoming months to refer to it. Especially (what to show during the game panel) can be directly useful for designing Lix. These discussions deserve their own thread, or maybe two, since it's two closely related issues.

Unfortunately, by nature of the dump-all-bugs-here thread, it both buries other bug reports, and will be buried itself by new reports. The discussion has interruptions, is hard to link, and to get it all, you have to sift through off-discussion-topic posts in the same thread.

I conceive three possible solutions here:

• namida says that putting all bugs in one topic, burying each other, is a good idea.
• Some moderator refactors the thread, picking exactly what is relevant to the ingame panel info,  and cloner/lemming/zombie counting, moving them to 1 or 2 new threads.
• I become mod and will then do it myself.

-- Simon

Hi,

Icho was visiting me at my office, and I wanted to show him the thread on clonesgame.com about lag. I didn't find the thread in the private beta testers forum. It turned out to be in a public board. :-]

So, it's linked above. It's for cultural reference mainly. Maybe ideas from there will be interesting for the D/A5 port of Lix.

-- Simon

Hi,

I need nicely upscaled versions of the Lix menu graphics!



^ Old file from A4/C++ Lix.



^ Work-in-progress 2x file from D Lix. This image has been rescaled manually. The scaling is not finished yet: the '!?' is still nearest-neighbor-scaled, not smoothed out.

What's to be done: Make nicely scaled images of all the GUI button stickers. See: List of all image files, but some of these needn't be scaled. Edit after Minim's reply #1: List of files that need scaling.

I would like upscaled versions at 1.5x, 2x, and 3x. Maybe 4x too, for good measure.

Why: D Lix is still far from finished, but one of its huge improvements is support for arbitrary resolutions (screenshot!). The graphical user interface is scaled accordingly, and more of the map is visible without zoom.

If a user with a massive screen loads the game, the GUI elements will occupy a similar ratio of the screen as in the C++ 640x480 version. They need much bigger graphics on them, scaled 3x or even 4x, to look well.



^ Otherwise, we'd get tiny symbols on huge buttons!

How to help: It can be done manually, but it's very tedious. There are tools to scale pixel art with various smart algorithms. A 1-minute google search hasn't brought up binaries of that Windows binaries for the project it's forked from, may be useful for you guys. I don't have Mono set up readily to build/run C#.

Making these images is not my top priority. But they need to be done. If you'd like to help, you can look into this! I'll be here all the time for any questions, or online in IRC.

Maybe making 1.5x versions is hardest. Pixel art scalers tend to be optimized for integer scaling.

I would fix the image's frame format myself from upscaling. (= I don't care if I get frame borders that are thicker than 1 pixel.)

-- Simon

Hi folks,

this wasn't clear-cut at all. The first post has some good ideas, but jumps to strange conclusions. Read all the responses and interpret yourself.

Original first post follows:

---

my visits at IchoTolot's always lead to fruitful discussions. We have found many unwritten guidelines for contemporary level design. It's time to present some of them in an orderly fashion. I think Icho will make another tread, he's the master of making interesting large levels.

We want to present guidelines, not rules. If you're a level designer, you can break them at your own discretion -- be sure though that you have a very good reason for breaking them.



Don't create disjoint unions: Don't make levels such that each half is an independent level. For example, don't roll two small levels into one large level, separating the halves by steel or lots of empty space. The same problem occurs when you solve one half, your lems enter the second half, and your actions from the first half have absolutely no effect on the second half.

Modern engines allow players to roll back mistakes, but they don't allow merging/rebasing two separate replays. Whenever you multitask, and fix mistakes in one half, you must rollback and repeat the simultaneous actions in the second half, even if they are completely unrelated.

The problems of disjoint unions tend to outweigh by far the puzzle of dividing the skillset.

Bad examples: Rendezvous at the Mountain, Synchronized Lemming, You take the high road. Also Ground City from Pimolems; it crams three moderately interesting levels into on gigangic disjoint union. Dividing the skillset is easy for all of them. Imagine these union levels with properly separated replacement levels (left half of Rendezvous, then right half of Rendezvous in a separate level). The artificial difficulty of the union level over the separated levels lies purely in the execution.

Somewhat bad example: Lost Your Ground from Icho's pack is a disjoint union of two equal halves. It's not that bad because each half is really small, and you don't have to multitask. But the basic problem remains. There is no extra concept to the solution brought by the mirror image. Icho has chosen to override a guideline for aesthetics here, the level still almost fits on one screen. On the other hand, don't mirror a huge level with no extra gain -- you wouldn't have a good reason to override the guideline!

Good examples Not disjoint unions: Sharing the World from Icho's pack, and Try to Compromise Before You Cue from Pimolems. Both of these look completely symmetrical, but require assymetric solutions. [Edit after Nepster's first comment: Not only assymetric, but a solution where the sides interact. So, these aren't disjoint unions after all, even though they look like one.]

Older threads with design guidelines

Time limits: Give unlimited time wherever possible.
Bridge stretching: Design gaps such that stretched and non-stretched bridges behave the same.

-- Simon

Hi,

this has been annoying Icho a lot. I don't remember if it's brought to discussion before.

On saving a replay, Lemmix saves 2 files. One is the binary replay format. One is a human-readable representation of the data in the binary format, but the human-readable one is unusable by Lemmix. I assume the human-readable file is leftover debugging. This is annoying because one of the two files is nothing but clutter.

The obvious solutions are 1) stop outputting the debugging file, or 2) stop outputting the binary file and have the game read the human-readable version.

You'd expect me to make a huge push for 2) now, but I don't feel as strongly about this as with human-readable graphics sets. The reason is that replays don't foster a culture around editing them with commonly-available tools. Occasionally, their contents are important to know for the game developer, because they're often sent in as bug reports.

I feel 1) is good enough for now, sounds like a one-line change.

-- Simon