If you discourage discussion, please don't bring claims like "this won't affect players who don't design", which I've attacked here; so far with no counter-argument to what I wrote.

Explanation of my vote for "collection, will design myself": I have 9-year-old tiles that can't be culled from Lix anymore, because levels depend on it. I have begun texturing and shading these, to bring them up to par. This isn't finished, but nonetheless on the to-do list. From what I've gathered about the planned NL2 design, the finished set is immediately usable as a 2x-scaled NL set, and can be reasonably downscaled to 1x pieces.

-- Simon

Quote from: namida on October 08, 2015, 03:00:26 AM
and a single file is more convenient to this structure.

No. Absolutely no.

You brought some arguments in the past, which I have criticized here, and you haven't replied to any criticism there yet.

A badly accessible format is bad for the player who never designs content. There will be fewer creative works made by other people, and that is bad for the player.

Please show why you deem a custom format superior.

QuoteI would say that given that a folder structure is supported, any further discussion on this falls into the territory of "it's not enough that my preference is supported, I insist that everyone else uses it too"

You're a systems designer.

Your responsibility is to nudge people into doing the proper thing. You want to foster culture around your system, not prevent it. I have shown why the tree is the proper thing for that.

Supporting it and pushing it are entirely different.

Quoteimplement either some numbering system, or some compatibility layer with a numbering system (or a very complicated conversion process for older content), if we want to be able to support other formats beyond the native one.

If your old format clashes with decentralization, or depends on numbering, then I acknowledge we should be careful here, yes. You have a ton of cruft to pull into the new system, there are many interesting level packs.

That doesn't invalidate any arguments about why the tree is superior, or why naming is good and numbering is bad.

-- Simon

The exact Lix algo is slightly different from what Icho describes; the fundamental idea is correct. The performance improvement is huge.

There are three pairs of savestates. Savestates are complete snapshots, not pointers into the replay as in NL. In each pair, for a fixed c, one savestate is taken every 2n * c physics updates, the other is taken every (2n + 1) * c physics updates. The first pair has c = 10, the second c = 50, the third c = 200. These values were chosen to combat networking lag. The pair for 200 updates catches even unplayable lags of over 10 seconds.

In singleplayer, this makes for a performance hit once in a while, after you have gone back so many times to exhaust all pairs. The resulting pause is comparable to longer than what you have in NL. While computing that long, the pairs are overwritten all the time again. This makes additional backstepping extremely fast, even after the single performance hit.

The values for c are chosen for networking, they are not optimal for singleplayer, and produce the above-mentioned work spike. It can be leveraged slightly with a fourth pair at c = 1000 or higher, which would correspond to saving less than once per minute.

-- Simon

Quote from: NaOH on October 08, 2015, 01:43:37 AM
An alternative that doesn't require hardcoding or unlockables -- have a lock.x.txt file

Hmm, this is better than hardcoding. I still have two hunches against this. The weak one: The editor allows to verify that there are no hidden exits or traps inside solid terrain. This is a weak counter-argument, because our culture already weeds out offending levels before they make their way into the distributed level tree. Maybe this idea points to a design flaw of the game class instead, where trigger areas could be visualized on command.

The stronger hunch is that it's bad to activate features by deleting a file, instead of by checking an option for advanced features.

People learn the level editor by opening and modifying existing levels, by deleting/moving tiles. They don't create levels from scratch early in their learning curve. I would like to foster such learning by exploration, and keep levels editable. On first sight, this seems only possible by separating singleplayer and editor further than they are now.

Quote

Quote
Bonus usability picture: Aleph-null-many exploders, another button with bad usability, but magnificent coolness factor.

This is amazing, how do I get this?

It's yet-unpushed D code, where I have been toying with unicode symbols. The bitmap font used in the C++ port doesn't provide this many unicode chars. To get it in C++ Lix, you'd have to draw it yourself over the star glyph in data/font_big.I.tga.

Quote from: Rubix
This is more of internal help system one day possibly:
If there was a new tab in the menu called something like   "Lix Informational"   the menu will have rows of buttons the size of an ability button with a picture in each.

Videos may be appropriate for multiplayer techniques, hard singleplayer levels, or level editing. The design challenge is to make videos for simpler things unnecessary. Therefore, such links might not go into the game, but, e.g., on the homepage.

-- Simon

I have made several attempts to push this. There is at least one thread exactly on this issue, but people haven't joined that discussion much back then.

But this is super important. More people than back then have been using the old setup, and know the problems. I want to drive this point home once and for all.

Tree of raw images and accessible control files = GOOD.
Custom formats for tiles or graphic sets = BAD.

I don't care if the control files have the same keywords as Lix files. I don't care whether one animation goes in a collective image, or in many images. I do care that every single file is a standard, worldwide-known format. I do care that data of different types (header values, images) be not merged in a container. They must be separate files that the host program will interpret together.

This has a ton of advantages:

People can use the tools they like on the files. Everybody is adept at different tools, but they all get the job done well. Even if you provide the best tools you can design for blob formats, you lose a million other tools. You forsake hard-earned experience. You lose scriptable tooling and shell interfaces. Well yeah, some Windows users don't care, and would happily work on tasks in a crazily unscalable way. :> Everybody else will immediately rage.

People don't want to learn a new tool; they want to get ideas from brain to usable file ASAP. And the most usable file is a simple image. It's the job of the host program to chew that into whatever bytes the game likes. It's not the designer's job to tear their perfectly well-represented image into whatever this year's NL version happens to like.

And no, it's not enough to have them make their images first, then later force creators to mass-convert content with a special tool. Omit the need for that conversion.

If the control files are getting complex, you can still offer your own tool to work on the data. People don't have to use it, but they can fall back to it.

Even the most stupid text file is admissible to search and replace, grep, sed, etc.; binary files aren't.

People can collaborate, and send each other good, descriptive patches. This is super important. If one tile needs work, that exact file can be fished from the tree, edited, and sent to the set maintainer.

The current NL culture requires you to be the very maintainer in the first place, before you can even think of making a patch! I would have sent Ichotolot some fixed one-way arrows for the castle tileset, had it been possible. Icho would have merged the patch. Icho doesn't care about the arrow's movement direction to make the patch himself!

(This phenomenon is prevailing in open source. Send in a patch, it gets merged, everybody is happy instantly. But put it on the bugtracker instead, and you have to hope that someone else cares enough to fix that particular thing, in a reasonable time, and in a reasonable way.)

The often-referenced "Neolemmix user" is not our lovely auntie who doesn't use a computer much, but is strangely eager to play trans-ONML-difficulty user packs. The typical user is reasonably computer-literate, knows many non-Lemmings games, and is often a level-designer themself. They have used other programs! They know better than to delete random files from a tree, and then complain that "it doesn't work".

Graphic-sets are archaic and damaging. I have to make a precise definition here. A graphic-set, of which usually only one is selected per level, is a subclass of all possible tiles, and only tiles from the chosen set may be used in a level.

Graphic-sets in NL are fundamentally different from what counts as a graphic set in Lix. A Lix tileset is a certain subdirectory in the tree. It is separated by its path from other sets. The game doesn't care if all tiles come from somewhere particular in the tree. It's perfect, because it matches the user's mental model of a tileset, and doesn't impose any restrictions during level building.

Graphic sets have corresponded to the users' ideas of L1, because all users were players. No user was a level designer in L1 when it came out in 1991!

In a time where people are both designers and players, a blob format per graphic set completely obscures what everything is. A graphic set, by this very name already, claims to be a set of graphics. Therefore, it should be a set of graphics, readily accessible on the disk. It should not be some untouchable blob that magically pops out tiles when the host program eats it.

Likewise, a gadget is a special tile: a graphic plus some meta-information. Put the graphic in a graphics file, readily accessible. Put the header info in a sepearate file, readily accessible as text, or as an image mask.

And obviously, graphic tiles should be referenced by their path name, or maybe by hash value. Never with a number that is dependent on a set. Don't even form the idea that for tileset mix-and-match, you could number sets, and number graphics in each set. Distributed content development is incompatible with numbering, plain and simple.

With this representation of single tiles, which is compellingly the most adequate representation of a single tile, it's apparent that a restriction per level to subclasses of tiles is arbirtrary and ill-motivated.

People have undergone needless chores for several days to work around the limitations in current NL. There's the stupidly named Epic tileset, it's simply a union of all 9 or 10 tilesets from L1/ONML tilesets. Giga has put the 500-something tiles of namida's various tileset into one union set. All by hand. No automation possible.

Ichotolot has meticulously put together L2 graphic-sets for NL from loose images. He has made good use of some programs (eidcut, eidrecol) that I wrote years ago to batch-process tilesets represented as images, and that made it tremendously easier for him. These programs were originally written to make Lix tilesets -- but because Lix only takes popular formats, the tools were immediately useful for his non-Lix purpose.

Despite existence of the Epic tileset, or similar union sets, they're rarely used. Being able to mix-and-match has not lead to only mixed-and-matched levels, not at all. Good taste doesn't go out of style.

Don't be working hard to do stupid things! Leverage the capabilities of a well-designed host program!

For releasing a level pack, it's not hard to program a checker that goes through all levels, and makes sure all necessary tiles from the tree are released with the pack. This is of the same difficulty as going through all levels, and checking what currently-existing graphic-sets are used.

People can use version control on their files. This ties in with the collaboration point; people can make the tool visualize what has been changed and how. Formatting patches becomes straightforward. But it is a sane practise for any project, programming, level design, graphics design, etc. (Chains are git is easy and all the cool kids are doing it.)

In particular, if you don't want to put your tiles under version control, you don't have to. All you have is a tree of images, which you can handle with whatever tools you please. That's the point.

Worldwide-known standard formats also compress better than whatever either of us could cook up. In case libpng is too hard to use directly, there are other libs for handling PNG.

To quote the Kernel coding style:

[Typedefs should only be used for] (a) totally opaque objects (where the typedef is actively used to _hide_ what the object is). Example: "pte_t" etc. opaque objects that you can only access using the proper accessor functions [= Neolemmix-specific tools, here]. NOTE! Opaqueness and "accessor functions" are not good in themselves. The reason we have them for things like pte_t etc. is that there really is absolutely _zero_ portably accessible information there.

Images and control files are super portable, there is no reason to make access hard. Don't hide what they are. Any format that is not a plain image, or a plain text file, makes access hard.

Maybe a classic cbloom quote, for good old ranting's sake?

Developers very regularly get some crazy ideas in their head about why they absolutely must do something in a crazy over-complicated way, and they cling to some silly reason why they can't just do it the simple obvious way. It takes a 3rd party coming in to rip up the code and take out the stupidity. (This used to be sort of my specialty).

-- Simon

I haven't felt like the buzzsaw is too lenient, altough I can imagine why it's bothering. I don't feel circles are neccesary are absolutely required, use a bigger buzzsaw to clearly block the path. Circles can be interesting.

For video games in general, if the character slightly enters the dangerous sprite and is not killed, nobody cares much. If the character doesn't enter the sprite, and is killed nonetheless, everybody will rage.

The argument for diagonal lasers is more compelling. When you're designing a specification, you can shoot for this.

Gadget designers should not get too fancy; they should make connected and idiomatic gadgets that clearly look like all/most of it is dangerous/desirable. The diagonal laser satisfies this, exits with multiple archways do not. The L1 Hell flamethrower looks like it has safe pauses, but it is always deadly. The L2 Sports exit is horrible.

You want to infer trigger areas from a text file, with a handful of simple commands for rectangles and circles; or from a second image, as a mask. Again, this dove-tails into the issue of graphic sets, and that you shouldn't gobble data into a format that no commonplace tool can understand.

-- Simon

I was with Icho yesterday, and we agreed how any overhang should cancel climbers. The rule should be as simple as possible, which makes the path tracable by eye much more easily.

The rule to become climber is separate from the rule to remain climber. I have been happy with the Lix rule for 9 years now:


walk walk walk
if (cannot walk forward)
    if (ridge is ascendable)
        become ascender
    else if (lem can climb && no low overhangs)
        become climber
    else
        turn walker


And there are no other (walker -> climber) transitions anywhere in the walker code. In particular, the climber is not greedy.

Icho believes the digger should not, under any circumstances, perform an overstroke (= remove terrain higher than his normal 1 row of 9 pixels). If no-digger-overstrokes creates a non-climbable overhang in a miner tunnel, that's perfectly fine.

Digger overstroke might appear to be reasonable to get overhang-free holes on bumpy terrain. But overhangs can be desired on bumpy terrain. To prevent overhangs as a designer, use flat terrain. To prevent overhangs as a player, dig on top of a bump, not in between the bumps.

-- Simon

Think very long and hard whether you want to keep graphics sets, or abolish them in favor of a dir with images.

I want to write an article/thread about this, but I'm too tired now. (Edit 2015-10-07: Thread on why plain graphics/text files are superior to any custom file format.) I want to make a full argument, it's important. The bottom line is, hours and hours have already been wasted because NL doesn't allow simple dirs with images, and I've been afflicted myself directly at least once.

-- Simon

You're welcome! It took a while over to New Zealand, but I'm glad it has arrived with no problems.

-- Simon

Yeah, hiding the play button is necessary. It's a little sad because the C++ browser classes need some fundamental change for this, while it's been implemented in the D port months ago.

Hiding the edit button for usability -- I'm considering to hide the button in the level root dir, and in the tutorial subdir that's one level away from root. I'm fine with hardcoding this. Or hide the edit button until at least one level has been started, even though I shun unlockables in games.

Other ideas by everybody to whom I haven't replied -- I've read everything so far. :-)

Bonus usability picture: Aleph-null-many exploders, another button with bad usability, but magnificent coolness factor.

-- Simon

Go for OGG and PNG. I wouldn't compress anything else.

Nyargh, make things accessible first, only then small. OGG and PNG are reasonably accessible formats, even though they hold compressed data.

Especially with stray levels in single files, you don't save much space by compressing each file per se. The space-saving approach would be taring them all up into one compressed blob. Optimize for the appropriate metric, which isn't necessarily filesize.

-- Simon

The image suggests Dolly Dimple, even if the description doesn't match exactly. Level 2 of rating Crazy in Oh no more Lemmings.

Screenshot with solution (!) on Lemmings Encyclopedia

-- Simon

Hi,

we haven't made a thread while I was in Vienna, 2015-09-14 through 2015-09-26.

I have spent the first week with Peter (ADmiral), seeing the town, and meeting some of his friends.

geoo and Ramond joined in during the second week. All 4 of us have slept at geoo's apartment for one day. We have played a ton of Tetris Attack, and reallife Zendo with my set of Icehouse pieces.



Left: Peter (ADmiral), right: myself. Ramon was sitting off the left, and geoo took the photo.

I have longer hair again than during summertime, when geoo was over in Göttingen. Akseli will be extremely happy about my choice of clothing, instead of being only very happy, as he is all the time.

The rule on the photo was by geoo:

Secret Rule

AKHTBN iff the number of sizes is equal to the number of colors.

Despite knowing the game for quite some time now, I didn't test thoroughly the single-color koans, and made rushed conclusions that every single-color koan was white. The game was eventually resigned, and I was angry about myself for not solving this. It's not a suitable rule for new players, but I should have been experienced enough to get it.

<SimonN> there's only one way to make up for this self-letdown -- play another game tomorrow

Of course we did. :-)

The black pyramids aren't used in Zendo. geoo liked to fidget with them to pass time.

-- Simon

Quote from: Nepster on September 30, 2015, 10:47:05 PM

Quote from: Simon on September 30, 2015, 11:12:08 AM
But the option brings serious harm -- hidden inconsistency that will eventually surface during play.

While this is a valid argument, I don't think it's quite as bad (in the case of direct drops) as you want to make us believe. There are currently other quirks of NeoLemmix that are worse in this respect

The other examples all have exactly one quirky way that can be learned by the player, and then future behavior can be anticipated.

I agree that the other examples can bring seemingly inconsistent behavior and are harder to understand.

QuoteAnd if we use your argument, then there should be no options to change the entrance order to ABBA or to change the max. fall distance. But both options are currently supported by the editor V1.35D, though we may of course decide to change that as well...

Correct, I'd suggest removing these options.

Max fall distance relies on careful judgement, you don't want to disturb that. Entrance order, you can make 4 instead of 2 hatches and get any entrance order you want.

-- Simon

Cellphone is probably the gadget with the widest range of use nowadays!

Interesting answers still. Thanks!

-- Simon