Simon blogs

[Proxima]

As I've mentioned before, walker is one of my favourite new skills, because of its multiple uses -- freeing a blocker, interrupting another skill use, turning a lix around -- and you don't know in advance which use will be part of the (intended) solution to a level. This can lead to very interesting resource management decisions.

Very few of my levels use runners, and on the ones that do, they could easily be replaced. Path of Wickedness uses a runner-jumper to clear a wide gap, but I could make the gap smaller instead.

However, at this point it's silly to talk of culling individual skills. The argument that seeing many unfamiliar buttons is intimidating is just as true with twelve as with fourteen. Lemmings had a nice friendly number, eight. But overall, the interesting puzzle potential of the extra skills in Lix vastly outweighs the initial intimidation factor.

DROD has a ton of different elements (roughly 90 in the latest game, which includes all elements from previous games). When the third game came out, I felt there were too many new elements at once and I couldn't get used to them, and soon architects were routinely incorporating the new elements into their puzzles and I felt left behind. I stopped playing DROD for years. What helped me get back into it was the main hold of the fourth game, Gunthro and the Epic Blunder, which is easier than the other main holds and deliberately restricts itself to a subset of elements, and Dan's Dungeon, a well-designed usermade hold that introduces the elements one at a time. Good introduction is much more important than number of elements. (This is the philosophy behind Entry Point, the ongoing project to make a similar introduction hold for all elements in the latest game.)

[Simon]

Hmm, thanks.

I'm okay with walkers turning, and I'm okay with walkers cancelling. My gripe comes from putting these two entirely orthogonal functions into the same skill.

But it's hard to take them out now: I scanned the community pack for walker usage, many levels have them. I haven't checked for how often they are mere panel decoration, or how often walkers occur in solutions. In any case, the walker is popular with lemforum levels.

The lemforum pack shall replace the skill tutorials, maybe we should improve the pack's walker introduction. The walker is special because it does two different things, and, as a second specialty, blockers can be assigned walker.

-- Simon

[NaOH]

Spoiler (click to show/hide)

Oh right, I forgot about the Bering strait, which is only 50 metres deep. I guess any mountain in Antarctica is ruled out similarly due to the shallow connection to Argentina.

I'm surprised there aren't any other shield volcanos in the pacific that protrude as far as the one in Hawaii. I guess the other Hawaiian mountains are ruled out because they probably touch, but still...

Very cool problem though, thanks!

[Simon]

Most graphical user interfaces are (1. select object), (2. invoke method on object). Level editors are the best example.

Playing Lemmings is a glaring exception: We click the skill first, then the lemmings. When you have a dense bunch in a pit, it's important that someone bash to the right, we don't care what lem in particular bashes to the right. But is this good enough of a reason? At least it feels right -- geoo and I wanted click-skill-first in Clones when that had click-clone-first-then-skill. I hope it wasn't only out of habit.

The forum has become quiet this week. A nice change of pace. I should focus on real-life work and the occasional Lix work. Then everything will turn out okay in time.

-- Simon

[ccexplore]

One important case to consider especially in multiplayer is to rapidly assign the same skill to multiple rodents.  I guess this actually can still work in the object-then-verb interaction model but requires the ability to select multiple objects first before selecting the verb, which IIRC is absent in Clones.  As a result, the Clones interaction model has a glaring shortcoming compared to the verb-then-object model.

I think you are correct to observe that the verb-then-object model typically can be "dangerous" in other contexts, since object selection immediately commits the specified verb, and thus relies on the object selection process being usually error-free on the part of the user--which it tends to be in the game as the rodents are often idempotent in many situations.

The level editor provides an interesting and very different use case to compare the two models.  For example, consider the classical case of selecting multiple level elements in the editor to move them as a single unit via drag-and-drop.  One can imagine how in a verb-first model, you could perhaps start by dragging one of the elements to the destination, and then while holding some hotkey, just click on the other elements one by one to apply the same movements to them.  You do actually get the same final outcome, and I have to say I'm not entirely sure how best to argue for the object-first model being better for this use case, beyond being widely used in other programs.  (One thing that does come to mind is, if the destination of the movement is too far away from the source, the verb-first method would require an extra scrolling of the screen, as you had to scroll back to the source location in order to apply the movement verb to the remaining elements.)

Perhaps the verb-first model is mostly habitual when it comes to the game, and that there might actually be a object-first model that do not have any shortcomings.  But habit is a mighty powerful thing, and many players have probably already been habituated from playing Lemmings.  It also helps that there are a large class of games where the interaction model is basically "verb only", because the "object selection" is implicitly fixed to the one single character that you have "full" control over.  So arguably the concept of specifying the verb first is not so foreign at all to many gamers.

[ccexplore]

One important case to consider especially in multiplayer is to rapidly assign the same skill to multiple rodents.

Just occurred to me that the inverse case of the hero lemming, where you want to assign a sequence of different skills to the same rodent, is one case where "object first" is a little more optimal, as you're not forced to re-click the same rodent multiple times for each skill of the assignment sequence.  Granted, this is probably somewhat less common in multiplayer, where you often still have to react to things happening elsewhere in the level.

This also brings up another point, that it's not strictly an either-or situation.  You can design exceptions to the interaction model to optimize for these various use cases where the predominant model may fall short.  For example, while I don't remember if this is specifically added per Simon's feedback, I believe Clones handled the spam-assignment case by implementing a special case of verb-first, where you hold down the hotkey for the skill, then click on multiple clones to assign that skill to each.  Conversely, some console versions of Lemmings 2 provided the ability to do a "sticky" selection on a lemming, during which clicking on a skill automatically assigns it to the selected lemming--essentially an object-first method special-cased for the hero lemming.

[Simon]

level editor
move them as a single unit via drag-and-drop
how best to argue for the object-first model

The movement target can be complex, e.g., place a cluster of pieces as a unit into a given gap, such that the cluster is centered within the gap. You don't know where any single block will end up before you have moved the entire cluster. Object-first allows for WYSIWYG here.

We can abstract over such clusters in the data model: Create group, add each piece of the cluster to this group, move group. This works in both the object-first or the verb-first world. Maybe this abstraction in the data model is better because it captures our intention: We wanted to move the group as a unit, with requirements for the unit rather than for loose pieces. The downside is that the data model becomes more complex. You're forced to define the map layout in a high-level language.

rapidly assign the same skill to multiple rodents

Good reason. You need more speed when you assign the same skill to n rodents, compared to the speed where 1 rodent accomplishes several skills, necessarily one after another.

Even for a single assignment, verb-first is fast. While I'm still aiming and clicking with the mouse on the rodent, I have already hit the skill hotkey with the other hand.

"sticky" selection on a lemming, during which clicking on a skill automatically assigns it to the selected lemming--essentially an object-first method special-cased for the hero lemming.

IMO, this points at a fixable shortcoming of the normal assignment. With directional select and priority inversion, I haven't seen the need for object-first. Long levels with lots of assignments to a hero maybe.

With object-first, but without directional select or priority inversion, you must select the object far ahead of time, before the rodent gets clustered. That should be unnecessary: Assignments happen at a single time, but its input must now span over a long time interval.

But habit is a mighty powerful thing

Yes!

-- Simon

[Nepster]

Here are a few more issues to consider when comparing verb-first and object-first:

1) During the first few seconds, clicking on some skill buttons currently does something, i.e. the game responds to player action. With object-first there are (apart from raising RR) nothing the player can act on until the first lemming spawns, even though skill buttons are displayed. This is bad.
So we would have to gray out the skill buttons whenever no lemming is selected. Certainly a possible work-around, but always clickable skill buttons look nicer to me.

2) Changing skills (especially via hotkeys) is much faster than homing in on a lemming and clicking on it (even for a single worker lemming). With verb-first I can simply the order of hitting the hotkey and clicking on the lemming coincides with the order in which my hands finish their work. On the other hand with object-first, my left hand would have to interrupt its action and hover over the hotkey until I manage to click on the desired lemming.
Note that in editors and other applications this is the other way around (at least most of the time). Objects are large and easily clickable, but then I want to apply multiple actions, or a complicated one, or one requiring precision, which usually takes more time.

3) Assume we have objects-first and assume the selected lemming wanders out of the screen. Should we automatically scroll to keep him inside the screen or should we stay at the current position? Automatically scrolling will be annoying, because it takes control away from the player (at least partially) regarding an action that used quite often (namely looking at other places or lemmings in the level). Not scrolling is bad as well, because then it becomes very easy to forget that a lemming is selected which may easily lead to mis-assignments of skills to that lemming.
Again there are work-arounds, e.g. not scrolling and disabling skill assignments to lemmings outside the screen or alternatively splitting the screen and keeping track of the selected lemming in one of the parts.

Of couse I might be heavily influenced by habit, but I feel that verb-first allows for a cleaner workflow.

[Simon]

1) During the first few seconds, clicking on some skill buttons currently does something
gray out the skill buttons whenever no lemming is selected. Certainly a possible work-around, but always clickable skill buttons look nicer to me.

Awesome domain-specific reason. Greyed-out buttons have a meaning already in the verb-first design: This skill won't be available throughout the entire level.


I spent the entire Sunday on a loose DVI cable.

My Linux machine decided to boot only into 640x480 text mode. Neither X nor the desktop environment wanted to start. I still had the command-line shell, so I checked all drivers, kernel messages, X log files, ..., and everything seemed perfect, only that the gfx card found no monitor. Edited several config files and rebooted 20 times. If I get 640x480 text mode, it can't be a loose cable, right?

When your monitor plugs into your graphics card via DVI, information flows in both directions:
The gfx card sends the image to the monitor. This is the obvious direction.
The gfx card reads from the monitor certain device info, e.g., max resolution.



DVI connectors come with two screws. I found these screws annoying for years, and only fixed one screw at best. But this allows your DVI cable to jiggle ever so slightly. When your DVI cable isn't 100 % perfectly plugged in, it can prevent the gfx card from reading the monitor values. Apparently, there is this emergency fallback that I landed in: The gfx card still sent 640x480 text mode to a monitor it doesn't even know.

Post on Debian User Forums with detailed symptoms. I love how the author wrote about his solution even though nobody else had experienced the error.


Everyday design

When the designer of USB dies, his coffin will be lowered into the grave... and be pulled back up, rotated half a turn, and lowered into the grave again. Then it'll be pulled up one more time, rotated back to its original position, and buried for good.

baddesigns.com, an old site with lovely everyday examples. When simple things have signs, especially homemade signs, it is usually a signal that they aren't well-designed.

-- Simon

[ccexplore]

I do believe all of the more recent monitor cable types (eg. HDMI, DisplayPort, etc.) no longer have this particular problem of partial looseness.

I also wonder if there may be conflicting designs at work.  Could it be possible that the DVI cable plug's pin layout is designed so that the ones least likely to affect display output (such as reporting back the monitor's data) are placed in the positions more proned to partial looseness?  Whereas Linux decides in the potential absence of monitor, the best fallback is to text mode (since command line is king) and avoid graphics mode altogether?  Granted, perhaps it would have been more desirable anyway for the DVI pin design to actually be more fail-fast, so that almost any looseness would immediately affect the display output in very noticeable ways.

With regards to USB, they did finally fix the reversibility issue with USB-C connectors.  Of course, it'll take a long time before everything switches over to the new connector type, so the issue will still linger around for now.

[mobius]

I like idea of having buttons greyed out for a lemming which cannot be assigned said skill or if the skill is at zero. Why not both? I'd prefer either having skills always greyed and only light up when selecting a lemming than be assigned such a skill or they are lit up always (except if zero) then dim if the moused over lemming is not able to be assigned.


UWXBill warns against over-tightening the screws on your monitor cables. They only need to be tightened enough that the pins can't be effected if the cord would get yanked on.
Tightening one side and not the other sounds like a bad idea too; one side could pull out further than the other making some pins loose contact or disrupting the connection of all of them.

https://www.youtube.com/user/uxwbill/videos

Last year I had a monitor cable go bad and the result was my whole screen took on a piss yellow color for a while, then the color went away but the screen was left with blurry lines. Eventually it stopped working altogether.

[Simon]

Hnn, I don't like to tighten screws either, very hard to unscrew. There will always be the next time when you must unscrew something again.

If your monitor shows a weird tint, that's a good pointer to a cable problem. 640x480 text mode was not a good pointer -- maybe I would have found the cable problem faster had the monitor not shown a picture at all.


This machine has an Intel i5-6600 quad-core at 3.3-3.9 GHz. The D compiler parallelizes well over the 4 cores, and I enjoy blazingly fast compilation for Lix's 22,000 lines of D. Lix itself runs only single-core, even when it verifies replays without displaying any graphics. Still, I get a nice performance boost here over the 10-year-old laptop:

	i5	10-year old laptop
Lix debug build	3 sec	18 sec
Lix release build	17 sec	1 min 40 sec
Verify 600 replays	23 sec	over 2 min
= replays/second	26	5

-- Simon

[Simon]

I'm back at my university town, the apartment is cold as fuck. I raised heating and shields to maximum power, but it'll take a while. How to stay warm? Good old UI rant!

Still a favorite example of bad interface design: Python shell.

$ python
Python 3.5.2 (default, Nov  7 2016, 11:31:36)
[GCC 6.2.1 20160830] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
>>> quit()
$

We know exactly that the user wishes to quit. It's unambiguous, there is no room for error. Every other shell in existence quits on quit. Thus, do we quit?

No, we tell the user to do it another way.

Lasse (reallife friend from university) compared speedrunning to playing the piano. The comparison is great, but it wasn't my first idea. I have compared speedrunning to a relationship. The moment you begin, all bugs turn into features.

-- Simon

[ccexplore]

Still a favorite example of bad interface design: Python shell.

I'm surprised the introductory text doesn't end with "Type "help()", "copyright()", "credits()" or "license()" for more information."   I suppose because all four are considered nouns and not verbs?

Lasse (reallife friend from university) compared speedrunning to playing the piano. The comparison is great, but it wasn't my first idea. I have compared speedrunning to a relationship. The moment you begin, all bugs turn into features.

Yeah, definitely like the relationship analogy more for this; the glitch-exploiting aspect doesn't really seem to have an analog in piano-playing. The piano aspect I guess referring to practicing certain difficult parts over and over until it fully and flawlessly commits to muscle memory, which I guess in a relationship might be loosely like knowing the person so well that you can finish each other's sentences.

So maybe it's like a pianist having a relationship while also rehearsing for an upcoming concert?

[NaOH]

Lasse (reallife friend from university) compared speedrunning to playing the piano.

I was just thinking this, too! When playing a very long and complicated piece, it's a game of "try to get to the end without messing up too badly," lasting several minutes without the ability to save state. Feels just like playing IWBTG.