Simon blogs

[Simon]

Hi,

some loose rambling.

Basic tenet in open source: People are interested in how other people solve problems. You share source code obviously, but you also love to talk about what it does, and are honest about its shortcomings. You can show proudness of your project, provided you're not hiding the problems.

I'm sure the IRC regulars have grown used to "Lix does it like this, the reasons for it are A, B, C, and the source is ugly." The ugly parts ("// 9 indentation levels is way too much") come to mind much more frequently than the nice parts. Good parts don't come to mind all the time; they're simple and to-the-point.

You value public bug reports, and you value source patches even higher. Likewise, users are happy to make bug reports. (Treat users as co-developers.)

Level design shares some qualities with such development, but is different.

People don't play a pack several times. Given the abundance of great and intriguing levels today, people play your pack once if you're lucky, and zero times if you're not. Useful software is run again and again, individual levels are not.

As a pack developer, you want your users to play thoroughly tested levels. There are several approaches. You can make a closed beta. You can release on Lemmini first, where you have fewer users. Or, what I'd do -- release normally, be honest that it's not playtested, and have good faith that people won't play all at once.

I believe I'm unconventional: I cherry-pick single levels. I wait until other people praise certain levels, or, as with Icho's pack, entire level packs. Only then I invest a serious amount of time. As a result, my level diet consists of heavily playtested levels. Maybe others are like me; probably many are to a lesser extent.

Even if you choose "release publicly, and hope that some will wait anyway", you probably don't want unspoilered solutions in public posts. Most authors like feedback in a spoiler tag, or as a replay file. This way, the solutions are public, but you have to explicitly want to see them. This is exactly what spoiler tags are designed for: They don't put the solution out of reach, but only out of accidental reach.

I don't care if people post unspoilered solutions publicly for my little handful of levels. With time limits and hidden traps, I'm happy that most contemporary level designers share my views. But I won't shape discussion culture for level designers. If many like the spoiler-tagging and don't want solutions bantered in logged IRC, then following suit is the way to go.

Bonus rambling, apropos diet: The guinea pig diet consists of eating lots and lots of cucumber. A guinea pig would do the same, and they are extremely cute and obviously extremely smart, because they eat cucumber, which is tasty. Aim for at least half a cucumber per day, maybe even one per day. And cut way back on sugar drinks. Magic will happen!



<SimonN> I have bought 2 cucumbers earlier today, 1 is already eaten. Love love love
<geoo> me too :D :D :D

-- Simon

[Simon]

More loose rambling. Some of these ideas, I've presented them on IRC over the past months.

namida was sad on how bugs crept up in NL1. But finding many more bugs was expected: 2015 has been a super-active year for NL level development. 2015 was also a comparatively busy year for NL playing; I played at Ichotolot's without making my own levels. And more users find more bugs (obligatory link to Cathedral and the Bazaar).

namida likes NX as the abbreviation for NeoLemmix, presumably like Fx for Firefox, or because the X is cool. NX feels unnatural when you use PascalCase for the long name. The obvious abbreviation is exactly the capitalized letters.

If you get feedback, react to it in some way. Maybe you don't want to fix issues right away, then at least list them publicly. You won't get school grades for your hobby project, so don't try to hide flaws from other people. Icho is in his 5th or 6th iteration of backroute-fixing his large NL pack. This is splendid support. namida improved on tracking NL issues by encouraging separate topics for each, even though he'd like to fix only serious bugs right now. Also great.

Porting Lix's C++ code to D, I've noticed bugs in the physics from mere reading of code. Every program is full of bugs, this is also normal. You write software, you have bugs. (You make levels, you have backroutes.) I won't replicate C++ physics exactly, only wherever they feel important and easy-to-describe. geoo proposed to reorder some physics code anyway in the most recent C++ release 2015-09-02, and there are bugs to be fixed.

Example of why replicating physics would suck: The tumbler and flingploder are horrible to replicate exactly. The tumbler (= lix that is flung) had a bug in C++ where some terrain checks were off by 1 pixel, it got stuck inside 1-pixel-high horizontal lines. This is fixed, I hope, in D. Since the flingploder produces tumblers, it can't be ported accurately, unless I wanted to keep the other bug in. And the old exploder masks aren't symmetric. And the fling speed computation is crazily complicated. Yuck yuck yuck.

On the other hand, walker, faller, and ascender physics are ported with 100 % accuracy. They are much more a part of how the game feels. Also, sometimes we run into things we'd rather preserve as they are, come hell or high water:

    // Horrible function. Copied out of C++ Lix almost unaltered.
    // The problem is that this function's semantics have already been
    // debugged to no end, C++ Lix had lots of bugs with tumblers over
    // the years. We'd have to be really smart to make this simpler.

    final Collision collision()
    {
        ...

This got way too technical and low-level again. Rambling is best at high level.

The more features your game has, the harder and longer any porting attempt will be, and the more features can come out wrong/buggy/strange.

When you rewrite, which is crazy from the get-go, continue to support the old version until the new one is done. Seen from the outside, NL does this well. Lix, seen from inside, not so much I believe >_> But other people could tell better. I've had 2 large releases in the middle of 2015, while the D port has been underway since 2015-02. I haven't included Raymanni's sets.

Over the past 4 months, I lost 9 kilograms with the guinea pig diet! (= 20 pounds in archaic units) Happy happy happy.

-- Simon

[Simon]

I was fun-browsing Wikipedia about the Euler-Mascheroni constant, read one of the linked papers, and found a lovely qoute inside: How Euler, Johann Bernoulli and Jacob Bernoulli stayed motivated and productive. (source info)

• Always attack a special problem. If possible solve the special problem in a way that leads to a general method.
  
• Read and digest every earlier attempt at a theory of the phenomenon in question.
  
• Let a key problem solved be a father to a key problem posed. The new problem finds its place on the structure provided by the solution of the old; its solution in turn will provide further structure.
  
• If two special problems solved seem cognate, try to unite them in a general scheme. To do so, set aside the differences, and try to build a structure on the common features.
  
• Never rest content with an imperfect or incomplete argument. If you cannot complete and perfect it yourself, lay bare its flaws for others to see.
  
• Never abandon a problem you have solved. There are always better ways. Keep searching for them, for they lead to a fuller understanding. While broadening, deepen and simplify.
  

-- Simon

[mobius]

these sounds like the "Oblique strategies" I mentioned yesterday. Speaking of which; you can buy Oblique Strategies on places like ebay... except it costs 500$ because it's a very rare thing supposedly.

Can you recommend some similar books and things but at a reasonable price? Or maybe website that has these things?

[Simon]

No, don't know any books on aphorisms to boost motivation. My bedtime literature tends to be technical books, flower math, and books on games. >_>

-- Simon

[Simon]

Problem that has come up occasionally: New forum users send a private message, instead of asking publicly for help on tech or levels. Don't send a private message. Find/make a topic, and ask in public.

Tech: Ask publicly! Level editors, handling files, Python scripting, programming, ... if you try new technology, don't have fear of looking stupid. We're extremely happy that somebody is diving into something new and exciting for them. Other people might run into the same problem later. If you ask publicly, they benefit, too.

Level solutions: Ask publicly! You will get the answer publicly, in a spoiler tag. Both level authors and level players like to share their solutions with people who're ready to read the spoiler. Don't have fear of looking stupid! Authors are happy that somebody is showing interest in their work!

Split off the new postings to a fresh thread: Object-oriented design with Simon.

-- Simon

[Simon]

Users never read manuals. [...] We cannot allow engineers to build products for an idealized rational user when real humans are irrational: we must design for the way users actually behave.
-- paradox of the active user

From 1998, the article is pretty old. But it even shuns "learning packages" along with manuals or anything that doesn't smell like getting things done.

I have wondered about Lix's tutorial pack. Every other option seemed worse. :> Large level packs are encouraged to start with flower levels, but they should not all shove full-blown tutorials down players' throats. Anyway, it's common with nonprofessional games to think endlessely about what new users would do, and then never watch new users. >_>

<SimonN> I have one person who has looked for the singleplayer browser's play-button at the bottom, not at the top
<SimonN> no way this is a technical bug, but it suggests further studies with new users, and maybe it's a design bug

-- Simon

[ccexplore]

From 1998, the article is pretty old. But it even shuns "learning packages" along with manuals or anything that doesn't smell like getting things done.

(Disclaimer: haven't read the article yet)  Well, do remember we're designing a game in this case, not a tool.  I feel like there's a bit of a fundamental difference here since a tool is usually just a means to an end (so one can argue the less time user spent on learning about the tool, the more efficiently they actually reach their goal), but here the interaction with the game is the fundamental experience.  The tutorial levels could still count meaningfully as "getting things done" for a new player in this context, I think, as long as they still provide positive experience for new players to complete them.

[Simon]

Yeah, that's a good view. If you don't know Lemmings, maybe you expect light hand-holding. The tutorials start with the skills and end with advanced techniques and control features.

If you know Lemmings, the game should shout "I'm mostly like that" and keep all non-L1 features discoverable. That's why I introduced tooltips in the C++ version last year. They obscure the panel text but seem acceptable aside from that bug.

-- Simon

[Simon]

IchoTolot will take a course on C at our university in a few weeks.

Everybody loves ghost stories before going to bed, so let's spook Icho with Simon's quirks of the C language. Nothing is new, but everything is written down by me. :-]

<namida42> the function examples with passing arrays, i think i get it
<namida42> but the stuff about function pointers... tehfuqq
<SimonN> hehe
<SimonN> yeah, it's meant to be scary

-- Simon

[IchoTolot]

Seems like I've got some reading to do over the next days

[ccexplore]

Everybody loves ghost stories before going to bed, so let's spook Icho with Simon's quirks of the C language.

For "Examples of function pointer signatures", typedef can be used to slightly improve readability of those complex type declarations.  I suppose it's true that if C's syntax didn't have some elements (eg. pointer dereference, return type) on the left and others on the right (eg. parameter list), the syntax would probably be a little less convoluted and more naturally readable even for complex type declarations.

Regarding static:  it's still a quirk in that if you're not aware of the semantics, the syntax is definitely misleading, looking like the variable is initialized on each entry of the block rather than just once.  But it's not too strange if you keep in mind that when you use static in block scope, you are basically really trying to declare a global variable without actually making it visible anywhere else except within the block.

[Simon]

Bug reporting sucks, and how to fix it

Lovely rant!

Tolerating the flaws in the software because it's better than filing bugs about them (time frame: 2 weeks to a lifetime)
[..]
Sometimes, the subtle conditions that lead to the exposure of a bug are so difficult to describe that you end up with bloated sentences in which you're mostly trying to convey something visual or with a far too complex linguistic parse tree.
[...]
What you find yourself wanting to do is take a video of the problem occurring, but that would require subjecting yourself to the hell that is desktop video recording software for Linux.

-- Simon

[Simon]

Controlling your technology

What's a single, concise word for this phenomenon? It's a strong desire to control your technology, even if you never invoke any of your rights.

Example 1. I have a Kinesis computer keyboard. This keyboard beeps on every keydown. When I got the keyboard 3 years ago, the beep annoyed me. I looked through the manual until I found how to disable the beep. But I didn't disable it. From then on, I didn't care about the beep anymore. It was okay.

Example 2. When Proxima assigns during pause, he likes the game to unpause. He doesn't like how Lix advances only by 1 frame. Advancing by 1 frame may be enough feedback, but Proxima wants to play on. Last week, I put a user option into D Lix: You can choose whether the game unpauses on assignment, or advances by 1 frame only. Proxima knows this, and that's okay. He didn't rush to update the game at once.

I told my Kinesis story to a handful of programmers at the D conference in May, and their eyes lit up. This sounded so familiar to them. Proxima and I are in good company when we feel like this!

In open source, you have the right to fork software, but you never exercise your right. Forking is an emergency break for ships careening entirely in the wrong direction, when you can't save anything with diplomacy. Because you're allowed to fork, you risk less by getting used to that software.

The Kinesis beep and Proxima's unpausing are different from open-source forking. I found the beep annoying after buying the keyboard, and didn't know it beforehand. Proxima lost his unpausing because I implemented the one-step advancement. He was already involved with Lix.

It's strange. Dangle the carrot in front of me!

-- Simon

[Simon]

I would like to criticize level repeats in Lemmings games. A level repeat is a level that copies another level's terrain verbatim, but allots different level constants and skills. I don't like repeats, but others like repeats. This is good thread material, I should make a fresh thread.

Level repeats violate the principle of low coupling. I find this easiest to explain with programming code. Maybe you can already guess how the corresponding level design argument would look like.



For horizontal alignment, do you ignore neighboring lines, and align each line by itself?

    x = 20;
    width = 10;

Or do align horizontally according to neighboring lines?

    x     = 20;
    width = 10;

The horizontal alignment brings a maintenance problem. What happens when we insert a third line, or modify the name of an existing variable?

    x     = 20;
    width = 10;
    height = 30;

If you require horizontal alignment, you have to edit 3 lines now instead of 1 line. You have created an unnecessary dependency between all 3 lines. This is Christmas light code: One line goes out, they all go out.

Christmas lights are lovely metaphor for many things, and I should compare more things to christmas lights.

When you work on this code with several people, and several people change unrelated lines, the non-aligned code will still merge automatically. The Christmas light code, however, will give merge conflicts, and needs manual resolution.

These whitespace issues are the least problematic types of coupling in code, but the easiest to reason about.

More severe is semantic coupling in code: Module X depends on module Y, and module Y depends on module X. When one changes, the other may have to change. Can you cut the dependency in one direction at least? Can you make a new module Z with the common functionality, then have X depend on Z only, and Y depend on Z only? This way, because Z will often be small and require fewer changes, you can change X or Y each to your heart's delight.

Keep coupling to a minimum.

-- Simon