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
Show Posts
Akseli will be extremely happy about my choice of clothing, instead of being only very happy, as he is all the time.
