I want to jot down my thoughts about level file management for Lemmings 3 and a potential solution for lem3edit to eventually take. Somebody might be interested, so I'll explain it here.
When editing Lemmings 2, I only had to deal with a single level file. I could name the file anything I wanted to, test them individually in the editor, then when it came to release the pack, copy over any files that changed and rename them appropriately into LEVEL###.DAT according to its tribe and position. Not the quickest process when it comes to releasing an update, but it was easy to organise.
In Lemmings 3 there is not one file, but three. LEVEL###.DAT, PERM###.OBS and TEMP###.OBS. The DAT file is tiny and contains basic level properties, like its size, which Tribe it is, time limit, that sort of thing, while the two OBS files contain the positions and types of all of the objects and terrain pieces that the level uses. Straight away we can see a huge problem, making a release or changing the order of the levels involves triple the work, as all 3 files need renaming. Doing this manually will be a huge pain, but its doable. And if you want to rename the levels while working on them to something easier to remember so you know which level is which, ideally you want all 3 files to have a similar naming convention. So a huge pain in the butt, still doable manually but very tedious.
But wait! Lemmings 3 has one more really annoying trick up its sleeve!
This isn't actually how it works at all! You see, when the game wants to load Classic 1, it loads up LEVEL001.DAT as you'd expect, but inside LEVEL001.DAT two numbers are saved, one for the number in the PERM filename, and one for the number in the OBJ filename. So renaming those latter two files is technically unnecessary, and PERM001.OBS doesn't even necessarily get read by LEVEL001.DAT.
This leaves two choices if someone is making a level pack and wants to reorder two levels manually:
1) Just rename the DAT file, leaving the OBS files with the same name and let the folder descend into a chaotically numbered mess, which is terrible for latter reorganisation and runs an easy risk of accidentally overwriting some other level's OBS file or deleting the wrong level's data.
2) Try to keep file numbers strictly correct, by first resaving level A to a different number, then open and save level B to A's old position, then go back to level A and save it yet again to B's old position. This is not really user friendly at all, but at least it keeps things in order.
Clearly, doing things manually will be awful no matter which way you cut it, so this leaves the program begging for another option, automating this mess with a proper level pack management system.
There's a couple of ways this can be done. My current thought is as follows:
- The editor can load and save individual levels in the default format, but you can also create a level pack. When using a level pack, a folder is created to store level files in, and the level pack itself is just a simple text file that stores all of the organisational data.
- Users are given an interface of 3 columns, one for each Tribe, with up to 30 slots, and players can load in individual levels or create new ones by clicking on an empty slot. You can assign each level done this way with an internal name to remember it by, and the level files themselves are stored using this name, they can all be tested from within the editor using an L2Suite-style temporary file moving and renaming so for now this is just for organisational purposes internally.
- Levels can be easily reordered by swapping them in the interface within a tribe, or saved down under the traditional file names for individual release/archiving and/or deleted.
- Finally, there's a publish button, which creates a folder with all of the level files in the proper named format so that they can be zipped up and distributed for others to play.
I feel like something like this is necessary for users to not go insane trying to make a level pack in the event anybody wants to. It sounds like a lot of work, but once the groundwork is done for handling an ini file for file paths for testing, and a way to test from the editor, you've already got the hard stuff out of the way.
