regular terrain piece is positioned over the top of the steel piece, regular autosteel will mean the affected pixels are now non-steel.

Understanding the difference, I'd formulate the guideline as "use regular autosteel", a stronger guideline than "rely on autosteel". What looks like steel is steel, and what looks like dirt is dirt. That's good and conforms to the guideline to be explicit.

-- Simon

Object-oriented design with Simon, part 7
"Object" must be empty

It is an egregious offense to call a self-defined class Object or Instance.

If you name your own defined classes Object or Instance, you will unnecessarily overload human language. There is always a better name than Object, and almost always a better name for Instance.

The only merit to have a class Object is to have a universal root class. D defines Object as such, which would be no problem if it were an empty class, usable like C++'s void*. But this was before D got powerful templates. Therefore, Object defines opEquals as a hook to override == instead of leaving comparison to templates and duck-typing. I ran into subclassing problems intrinsic to D's Object.

D is still a low-Simon-rant-% language. :>

-- Simon

Agree with "../" not descriptive enough. In the root dir's blah-blah text, I've told people to play the tutorial, then click ".." when they're done. Instead of telling people what a button does, we should try to improve the button first.

I have never allotted vertical space to anything but the file list. With the file list's paging button, there are 20 files per dir shown at once. The lemforum pack has 40 levels per dir, a multiple of 20, probably because of this restriction. With a scroll bar, there is no advantage anymore in sticking to a multiple of max. visible entries. We can shorten the file list vertically.

I like ccx's breadcrumb navigation with buttons per nesting level, [levels] -> [single] -> [lemforum] -> Simple. Either in addition to an improved "../" in the top left, or instead of it. I haven't yet pondered how much screen space we should invest on the tree navigation.

-- Simon

UI fail in D and C++ Lix: Iff we're not in the file-browser-specific root dir, "../" is at the top of the directory list. Now we mash "../" repeatedly with the mouse. We end up toggling between the root dir, and the first dir inside the root dir.

Mass-clicking "../" should not be dependent on how many dirs we have to traverse.

Inspired by 2012 blog post about UI abuse on Ipods. The blog site itself violates a design principle, WTF the UI clicks for you.

-- Simon

Expected behavior: NL shows a dialog, so we can pick an NXP to play. Only after we have picked an NXP, a graphical window comes up.

Apparently, not even the NXP-picker comes up. That's a standard Windows widget, so this is surprising.

Try ccx's and namida's ideas first. Maybe later, namida can throw together a test application that spawns only this widget, and doesn't initialize anything else. We lack any kind of error message, I have no idea except for debugging by such brute bisection.

-- Simon

The round has been open for 3 months. I don't believe this will ever resolve.

Let's make the Quizmaster account available again. I'm not keen on running a standard round of Family Feud right now, but I've got a game design itch. Shall we see what surprises I got up my sleeve?

-- Simon

Thanks for the exhaustive checks!

I haven't meditated yet about open edges, closed ceiling. It sounds viable, especially in light of many levels relying on the closed ceiling. Let's meet on Saturday and take a detailed look.

-- Simon

I see the level edges as a "solid steel boundary" and not as a deadly "electric fence".

I don't see the edges as an electric fence either. Lemmings die when outside of player's range, not because they're grilled by the edge. The current NL burner edge doesn't feel right. The egde should do as little as possible.

My Feeling: open edges > steel > electric fence.

It is still weird as hell in general seeing Lemmings get burned when they got near the edge.

100 % agree!

Quote from: cxx

One word: gravity.

other games "I" played the level edges are not deadly so encountering deadly edges is unnatural. The bottom is a logical exeption, because of the gravity point (----> "Mario"

In Jump'n'runs, gravity pulls you towards the bottom, where you're killed. To go towards the edge, you must want to go there, by steering towards the side. At the edge, the character ignores input towards that side.

Gravity in Lemmings, too, pulls you towards the bottom. But lemmings walk uncontrollably towards sides. You have to be active to prevent them from walking somewhere! The sides attract lemmings like the bottom does.

In Lemmings, it is natural to walk outside of the level. There is no magical barrier that prevents what lemmigns would do on their own. And while we might return in the real world upon hitting an obstacle, the lemmings get stuck.

But I would make it an option in the Flexi Toolkit allowing to fix one behavior for a whole level pack

Pack-dependent options open a new can of worms. What is with playtest? What is with standalone levels? Is the complexity warranted, even though authors have been consistent within a pack?

The per-level option is not as bad as it is now, should the boundaries get visual hints.

Always the same > option per-level > option per-pack.

Edges are weird, no matter what they do. I care about consistency. Let's not be coy. If we evade a decision, the players will suffer.

We're not in a hurry to decide, and can sleep over this for a week.

Quote from: Simon on February 23, 2016, 04:14:52 AM

Likewise, even if we have deadly edges, instead of relying on them, we should enlarge the level or put a trap.

If you really thinks so, quite a few levels in the Lix lemforum level pack need to be modified. Quickly skimming through Hopeless I see like 6-7 levels where solid edges can be used to backroute levels or at least simplify the solution.

I'm okay with a few explicit hazards. I was speculating that edge reliance is bad design, but I'm not sure.

I agree that explicit hazards can be ugly. Like ccx, I don't want to require traps. When you have levels with large open areas, I agree that the void looks nicer than a load of traps.

Regarding your second point: Steel borders need not look bad (depending on the level), usual terrain suffices most of the time and quite often you don't need to cover the whole border with terrain (just the relevant parts).

Yes! Normal terrain suffices often and looks good.

Then level designers who want deadly sides may frame their levels with this trap

EDIT: Maybe the deadly edges option adds 8 pixels of map to each side and puts a laser beam in there automatically -----> lesser hassel for designers

I like this push for explicit edge behavior. I don't like mass traps.

When you want a void, the traps look horrible, and don't produce the right feeling either.

When you want steel, terrain or steel looks okay, and match what you perceive.

Once again. The edges aren't an electric fence. When edges are deadly, the lemmings get lost in the void outside of the level. The edges do as little as possible!

-- Simon