Made a surprising amount of progress with this today. We now have a Playback Mode button in the Level Select Menu:



As well as looking pretty, this button opens up a dialog from which a folder of replays can be selected. Once chosen, SLX will then iterate over each replay in the folder, matching it up with a level from within the currently-active pack (note: at this point, it only looks in the currently-active pack for matches - this could be expanded to it searching the entire levels directory, but this may make loading slower). The "currently-active pack", in this case, is the parent pack of whichever level is currently selected in the Level Select treeview.

Each replay is then played back automatically, one after the other (the preview and postview screens are briefly seen in between each level). If a level has multiple replays associated with it, each one will be played back as and when the replay appears in the Playback list.

Playback Mode can be cancelled by simply cancelling the replay as normal (I might give this a dedicated hotkey if people think it's worth it - maybe we don't necessarily want to stop Playback Mode once it's started?).

Some issues:

1) The preview screen always shows the first level in the list's info, even though the correct level is loaded when playback itself starts
2) The music is always that of the first level in the list - this is likely part of the same problem, but I'm not sure exactly what's going wrong
3) If a replay doesn't have a definite "end" point (so, if the original player pressed [Esc] rather than nuking at the end of Tailor-made For Blockers, for example), the level will continue to play indefinitely - not sure exactly what to do about this at the moment, but ideas will come
4) Not an issue as such, but randomizing the playback currently isn't possible by any other means than manually mixing up the replay files so they're not in logical order. Let's get the other issues sorted first and get the feature nice and tight, then we can look at expanding functionality

If you're interested, check out commit 80da87c02 to see implementation so far. If you can see possible improvements or ways to fix the above bugs, input would be most welcome.

Otherwise, just watch this space!

L2 has 120 levels in total, with the 12 tribes having 10 levels each.

Again, happy to do the 10 beach levels. I'll probably get on them soon, it shouldn't actually be too difficult to just recreate them manually.

Once I've done that, it's very likely that others will jump on board for the remaining 110 levels

The 16x8 tiles in the image dump are in the correct order. So a 1 in the level file would mean the first 16x8 tile, a 2 is the second 16x8 tile, etc, so it should be straightforward. You just need to create the NL tilesets based on those 16x8 tiles (which I assume can also be automated). Then you're sorted for the terrain at least.

Regarding your other question, of course you could also create images of the levels from the level files and the 16x8 tiles, it's a very similar process to the above.

FF buttons be hold-down instead of toggle, how I thought they always should've worked

Interesting observation. In Lix, I hold the 10-second framestepping, too, and it becomes fast-forward for me. Hard to say if it's worthwhile to turn toggle-on fast-forward into hold-to-fast-forward. I imagine that toggle-on is better for recording solution videos, but that's niche. Even in livestreaming, I prefer hold-to-framestep instead of the toggled fast-forward.

I haven't played Golems enough yet to decide if I want a super-fast hold-to-fast-forward in Golems.

snapshot basically only needs to store the accumulated changes to the terrain and effect maps along with the (uncompressed) creature states, gadget states, and various other small bits of game state.

There is wisdom here: Separation of all level state into an immutable and a mutable section. It's enough to store the immutable section once, at the beginning. We store the mutable section in regular intervals, possibly compressed.

We can push this further in all of our engines.

E.g, hatches and water don't need to be part of the mutable state at all. Their animation is only dependent on the number of physics updates since the beginning. We can keep them in the immutable section, and only prepare them just-in-time during the drawing step. It's common to have 10 to 50 water tiles in a level; Lix can omit many allocating deep copies here.

Traps must remain in the mutable section because they eat lemmings at unpredictable times, and both physics and graphics depend on such recent eating. Theoretically, traps can split into an immutable location and the mutable number of the physics update of recent eating, at cost of even more complication.

Thanks!

-- Simon

@geoo

Thanks for the info, I’ll take a look at the assets later.

Conversion via script is a good idea. It would only have to be done once, assuming it works and all goes according to plan, so doesn’t need to be too pretty. Thereafter, the levels would exist in NL format and can be edited as necessary.

I wonder whether the levels could be saved as bitmaps somehow. These could then be used as backgrounds in the Editor, so at least if something went wrong in the script conversion it would be somewhat easier to make corrections as necessary.