In the Windows 64-bit build instructions, we recommend to install LDC and then to double-click win-build.bat. This works well and I recommend this to everybody for release builds. LDC builds the fastest-running executables.

The win-build.bat specifies the compiler to ldc. The question is if this is necessary or should at least mentioned in the file name since somebody could just have dmd set up and get an error.

Now, if somebody installs only DMD and not LDC, he has diverged from the release notes early. I'll assume that he knows what he's doing. The build instructions even cover DMD and tell him to type the command manually. If he still double-clicks win-build.bat, he'll get the following error: Error Failed to spawn process "ldc2" (The system cannot find the given file.) Given that he see this only after he has willfully diverged from the build instructions and installed DMD instead of LDC, I'd say it's fine as it is. He can edit the script or type the build command manually.

I could also write win-build.bat to be compiler-agnostic, but then it'll pick DMD over LDC when both are installed. I encourage everybody to build release builds with LDC. DMD is better for active development, when you need the fastest-possible feedback and care less about producing fast-running binaries.

It should be possible to test in the script for installed compilers ahead of the dub call, e.g., with a Windows equivalent of Linux's which. Then you build with LDC explicitly only if LDC is found, otherwise you build in the compiler-agnostic way. If you want to investigate this, I'll be happy to merge it.

---

Readers may wonder: Why different compilers for different builds, aren't there build types? Yes, there are build types; you can instruct either compiler to build debug binaries or optimize for release. Still, you'll see the fastest build times with DMD without optimization, and you'll get the fastest-running binaries from LDC in release mode.

-- Simon

It's released! Download it here:
DOS Games Club's Lemmings 1 podcast episode

Runs for 2 hours and 9 minutes, as MP3, 148 MB.

-- Simon

One approach is not to worry:

• Make several levels of medium difficulty.
  
• Have others playtest your levels.
  
• What levels did they find much harder than you anticipated? Those are hard levels.
  

My take on Proxima's idea:

• Place some terrain and give plenty of skills.
  
• Solve your level several times. Optimize the solution for skills.
  
• Trim the skillset to match your optimal solution.
  

Or:

• Play lots of levels by others.
  
• Build a level that combines two ideas from existing levels.
  

geoo's favorite:

• Play lots of levels by others.
  
• Submit your replays to the author.
  
• The author will judge some of your solutions backroutes. Sometimes, he'll also fix his levels to prevent your backroutes.
  
• Which backroute did you like the most? Were you surprised that he judged a particularly cool solution a backroute?
  
• Build a new level that has your cool backroute as the intended solution.
  
• I recommend to make the new level look sufficiently different from the original level. After all, the idea is now different, and it's nice to give different ideas different looks.
  

Draw levels on paper, mainly to brainstorm, but you can also plan details.

It's not necessary to start with an idea. You can make your level look like art first, then draw inspiration from that.

Not only the level can look like art, even the solution can look like art. E.g., when you solve a level by Pieuw, ask yourself: Where can we place the basher/miner so that it continues the longest? Now, if your level has only one miner, has no other destructive skills, and has lots of obstactles to mine away, it'll be easy to spot the miner placement. Can you disguise* the beauty? Will the player have an a-ha effect when he finally finds the idea?

*) By disguise, I don't mean invisible things, e.g., don't hide exits/traps fully inside terrain. Everything should be clearly visible and its behavior should be obvious. Still, you can make the player wonder which parts are important and which are merely decoration. As Icho describes: Hiding things in plain sight.

You can make levels harder by adding extra problems to a medium-difficulty level, but you'll have to test for backroutes from the extra skills.

-- Simon

Position of the message: No preference, happy to test the UI again after you put it into the stats.

Habitually, I never look at the minimap and instead scroll/zoom much more on large levels. But others like the minimap.

Yeah, I have the preference for the solid color of the splat ruler. I grant that the rainbow cycling isn't as intrusive as I thought, but it's still more intrusive than I like.

---

Bugfixes: Had a busy day at work, but you've already caught everything. I'll summarize nonetheless:

Overshooting is fixed entirely in Experimental 5. Good!

The following bug is now fixed, too: In earlier stream, on kaywhyn's Fun Teleportation Race in Space, we saw the Experimental 4 freeze after the last lemming left by exiting. The lemming scored a point and made the score equal to the save requirement. Nonetheless, Experimental 4 didn't exit, and instead showed the message. The Experimental 5 exits here always, which is correct.

All 3 user options do what it says on the tin, with the designed exception that the nuke overrides the user option and exits. No bugs here.

The only bug is what you've already seen: When I nuke during the freeze (to exit immediately without seeing explosions), NL writes the nuke into the replay. When we watch this replay, the red R will stay after the final assignment (because there is the nuke coming up) and, when we reach the freeze, the nuke button will have the white square, but we won't see any nuking.

If you have fixed this by not adding the nuke to the replay: Excellent, I believe that is the cleanest fix. I'll test it. I'll have time to stream playtesting on Friday, Saturday, or Sunday evening.

Do you want a Mumble session with code rewiew? Again, Friday, Saturday, or Sunday evening is good.

-- Simon

All right, I inserted grey letters with size 1 pt in your first post, and in your reply #22.

Let's see if that's enough to confuse search engines. Maybe search engines are smart enough to ignore the small letters. Feel free to add more such obfuscation on your own.

I took the liberty to trim your warning ("I need to say this, This is NOT for ...") to minimal wording. Reason: People don't like to read; the fewer words you put, the better. (I saved your original text offline. If you want the original wording back, let me know, I'll PM you the original text.)

-- Simon

Good catch, thanks. Link is fixed. I had put 3 'a' in a row by mistake.

WillLem: Written summary of the feature testing will follow here tonight. Then you need not watch it all.

-- Simon

Recording done. Editing usually takes a few weeks for them. I'll link it here when it's published.

Mostly Lemmings 1 with its history and oddities. Some tenets of custom level design. Short glimpse into L2, L3, other licensed games.

-- Simon

Splitters are particularly problematic code-side

What issues do you see code-wise?

At best, I see how splitters can be boring when you send too few lems through: 50 % of the time, a splitter does nothing but prepare itself for the next time. namida grabbed it from L3D, where it rotates by ±τ/4 all of the time instead of 50 % of the time, in hope that it works well enough in 2D. Reminds me of how I hopefully took the walker from L3, where it either turns or cancels, but oddly never both.

-- Simon