Lemmix goes Custom

[EricLang]

The Lemmini file format is quite good. some disadvantages:
- use of gif's which are more difficult to implement regarding transparent colors
- use of tilesets, which I want to abandon.

The advantage is that it's a clear format. We only need textfiles and images.
That clarity is my goal as well.

I'll give it a think.

[Dullstar]

I just like the option of low resolution!

[ccexplore]

- All 9 classic lemmings styles will be built into the executable (dirt, fire, marble, pillar, brick, rock, snow, bubble). No christmas lemmings

If I recall correct, the tileset for Chrismas Lemmings is not totally identical to the Snow set.  The exit is different for example.  I'm not pushing hard for it, but do consider including xmas as a 10th style, even if you are just using it with normal lemmings animations.

-Still figuring out how to define custom music (how to link a level to a particular song).
The music files (.mod, .wav, or .mp3) can be put next to the .lvl files

If you already have a sections.txt, it would seem logical to me to store the music information there as well.  You could for example have one line in sections.txt that defines the normal cycle of music (a list of music files that the game cycles thru as you go from level to level), plus additional lines that define "special music" for particular levels in particular sections (like the special music for the "special graphics" levels that fall outside of the normal cycle of music).

-How about customizable skillsounds?

Sure.  Should be easy to include the information in sections.txt as well.

[EricLang]

Certainly, me too!

[The Doctor]

I'm still interested in tile mixing, an idea I like from the PSP. I'm also interested in background objects a la Lemmings II or wallpaper a la PSP Lemming.

[EricLang]

If I recall correct, the tileset for Chrismas Lemmings is not totally identical to the Snow set.  The exit is different for example.  I'm not pushing hard for it, but do consider including xmas as a 10th style, even if you are just using it with normal lemmings animations.

I already thought of that and included it.
Music and sound will become customizable too.

[Dullstar]

I do like the Christmas lights in that style.

[EricLang]

There are some flavours for storing lemmings data:

- Fully transparent "Lemmini-like" storage:
All static data (tiles, interactive objects, animations etc.) is stored on disk in seperate directories/files.
All levelpacks are stored in seperate directories.
The level-files are uncompressed, but readable with a wordprocessor like notepad (An inifile, xml, or something that looks much like it).
In addition Tiles and objects could be included into the seperate levelfiles thereby preventing unplayable levels because files are missing on your hard disk.
Advantages: Readable, editing possible without a dedicated program.
Disadvantages: More diskspace, Lots of directories, lots of files, levels are dependant of data on disk.

- My own system:
All static data is on disk (as one compressed file) or included as a resource into the executable.
Levelpacks are stored in one file, compression is used.
Advantages: less disk space, no extra directories needed, just a datafile and levelpack-files
Disadvantages: only readable for the Lemmix program

I need to make a decision on this to proceed.
Please give comments and ideas.

[Mindless]

Actually, I'd prefer that levels have the entire style embedded in them.  If I ever get around to updating the level database, it's easiest not to have the user upload the style that the level requires.  Maybe I'm just lazy. <_<

[Dullstar]

I thought we already discussed the large file issue?  Which was the projected result of embedding the style, wasn't it?

EDIT:  I checked for it in this thread, this discussion occurred in a different thread.

A side note I think would be useful:  just because of already existing packs and levels, the old system must still be usable.

[lorcan]

or have a level filer converter? (maybe a feature of the Lemmix editor?) 

[Dullstar]

Possible.  But then there is still the possibility of large files, which most of us don't want to risk.  However, there is another way the converter could be relevant.

An idea on a thread with the name "Custom tilesets in Lemmix?" (if I remember correctly) was that the graphic set could be stored in folders inside the lemmings directory or something like that.

In the Lemmix directory, a folder could be made with the name "Tilesets" or "Styles" or whatever the game will go with.  Then in there you could put a folder with the name of the tileset, make sub directories with the names "Terrain" and "Objects" and then store the tiles/objects in image files under the name "xx" (replacing the variables with the terrain/object number).

These files could still be huge because of this system, but at least you only would have a large download every time you wanted a new tileset as opposed to having a huge download because the tileset was included in the level.  Levels could support taking tiles from multiple sets too; the tileset concept could be removed except to keep similar tiles organized.

Remember, while modern hard drives are huge, that is not synonymous with "infinitely huge" so the fact that the hard drives are big these days is no excuse for making the levels larger than they need to be.  There may also be people with slow connections, so let's only torture them in getting new sets, not new levels.

[Clam]

I like efficiency. I'd favour keeping the files as small as possible (by keeping the tileset and level data separate), but if we do this we have to make absolutely sure that we don't end up with a situation where you have levels without the data files needed to run them. Someone mentioned a way of automatically detecting missing tilesets that you need to run a level. I like that idea very much.

[ccexplore]

Remember, while modern hard drives are huge, that is not synonymous with "infinitely huge" so the fact that the hard drives are big these days is no excuse for making the levels larger than they need to be.

Let's not get carried away here.  We're not talking about "infinitely huge" level sizes.  In fact, if you ever download MP3s onto your computer, an average MP3's size is already like at least 4-5 times larger than the kind of level file sizes we're talking about here.

Moreover, as I mentioned earlier, once downloaded, Lemmix can potentially break the file down into its components, and things that are already on your computer (eg. tileset) can then be discarded away.

So I don't see hard disk space as a primary concern, compared with slow connections.  And as for slow connections, we should do some experiments with determining how much of a difference we're talking about, and what exactly constitutes "torture".  It's hardly "torture" if we're only talking about 1 minute or so.

=======================

Of course, it's also possible to support both options.  Then the level designer could potentially upload 2 copies of the level, one that only has the level, and another that has levels + graphics.  Then someone can first try the level-only download, and then if they discovered they are missing the graphics, they can then go for the level+graphics download instead of tracking down how to find the missing graphics themselves.

[lorcan]

I like efficiency. I'd favour keeping the files as small as possible (by keeping the tileset and level data separate), but if we do this we have to make absolutely sure that we don't end up with a situation where you have levels without the data files needed to run them. Someone mentioned a way of automatically detecting missing tilesets that you need to run a level. I like that idea very much.

IMHO keeping the tilesets and level data separate would be the best option. The game engine could scan for available (installed) tilesets and thus detects missing ones without having to exit brutally This tilesets scan could either be performed during the main game initialization (to retrieve a list of all the styles available) or on the fly when loading a level (checking if the current style(s) exists on disk and adding the style(s) to the list if they aren't already stored in that list). Doing this we could use several styles in a single level and we could also edit existing styles and create new ones  This is what I thought for my project...

Anyway if we'll use embedded styles in level files, we should consider a level converter at a certain point...