End-of-singleplayer screen

[Simon]

Progress report on the new feature, the end-of-singleplayer screen.

March 2021: Start implementing the end-of-level screen.
Discover small piece of duplicated logic in the overarching screen handling.
Get idea for huge refactor of the screen handling.
Weeks later, finish refactor.
Lix runs, main menu comes up.
Praise the type system, it catches all bugs at compile time instead of at runtime.
Lix crashes at runtime.
Hack to navigate; most screens don't crash, only the level browser crashes.
Become nearly insane analyzing the code and proving that it cannot crash.
Browse Bugzilla for related compiler bugs.
Find matching bug that I filed myself 6 months ago, during similar problem.
Download compiler source and study, getting ideas to sleep over.
Next morning, discover that somebody already has a pull request in the works.
May 2021: Be happy, continue with end-of-singleplayer screen.

What do we get from these first 6 weeks? The most boring screen in the world, see attachment. All you can do is go back to the browser.

The plan is:

• Add the stats for the solution from the finished/exited playthrough.
  
• Add replay-saving button, and info about about auto-saving.
  
• Add the personal record. I track lix saved and skills.
  
• Contemplate about more stats to track. The screen's top half gives room for more.
  
• In the bottom half, add preview of next level in the level tree.
  
• In the bottom half, add preview of next unsolved level, if that is different.
  

For consistency, the screen will appear every time you exit singleplayer, even if you didn't win. We might want to save a non-solving replay. And we want to support hotkey habits, e.g. hitting the quitting hotkey twice during a singlepalyer game will then always go to the browser, regardless of winning or not.

After this screen is finished, I'll look at the networking server, allowing different versions to play on the central server, and look into physics changes and level format changes. 0.9.x has been good for nearly 4 years, but we have more things to come.

-- Simon

[Simon]

More refactoring of the preview (level thumbnail with nameplate below) has lead to this.

The bottom two previews are on huge buttons. Later, they'll display the next levels, not the same level as in the top half. When the next level is already the next unsolved level, only one of the huge buttons will appear.

Lots of fine tuning ahead, for the UI and the exact positioning. Nice spacing is hard. Bad spa cing will make Proxima write a lovely rant, but it's still my goal to get it reasonably nice the first time.

And I haven't written any code yet that fishes the next level from the level tree, or the next unsolved level. I'd like to cache the entire tree, then fish the next levels from that cache. Ideally, the cache can later compute completion statistics, e.g., allow the browsers to show that you've solved 79.2 percent of pack lemforum.

Lix 0.9.37 will release later today, but this screen won't be in it yet. 0.9.37 will have small bugfixes, updated documentation, and many new multiplayer maps.

-- Simon

[Simon]

No new code this month for the end-of-level box. Slow thinking.

It's tricky to design the level cache that backs the whole idea.

• Cache shall track level order. Finding next level, and next unsolved level, shall be quick. This is the main concern.
• Cache shall compute directory completion ("you solved 197/240 of lemforum"), but I might postpone this requirement for a later version, to easen my tracking of level order.

Design problems, especially for the directory completion: When to re-index cached levels? What data structure should the cache be, a tree? Tree with nodes back to the parent? A set of filenames, and establish relations based on which filenames (of dirs) are prefixes of which others (dirs/levels)?

-- Simon

[Simon]

I have an internal database to track level ordering, including the completion.

Example: You've earned checkmarks as in the first screenshot. You complete Any Way You Want. Then, Lix's end-of-singleplayer screen offers you

• the next level regardless of completion, Pipe Dream, and
  
• the next unsolved level, Escape the Pit.

Bugs to fix before release:

• End-of-level stats. I'll have to show the stats for the finished level, and save its checkmark.
• Duplicate buttons. When the next level is unsolved, the screen offers two identical buttons. It should only offer one button, and caption it à la "Play the next level, it's unsolved:".
• Slow database creation. Once per program run, the database re-caches levels/single/ by opening and reading every single level file. Takes ~5 seconds with cold files on older Windows machines? Instead, I should dump the database to a single file and read that back.

Long-term improvements:

• Merge the checkmark tracking into this database.
• Have the level search use the same database. The level search shall also find multiplayer levels and other stuff outside levels/single/. Support this, but don't track checkmarks for multiplayer levels.

-- Simon

[Simon]

The screen will now save trophies of successful attempts, and also display the trophy.

Bug: It doesn't prompt the database to recache the saved trophy. This still requires complete exit-restart of Lix. I must immediately re-cache the database node of the saved trophy after saving a trophy.

The screen doesn't yet offer, but should offer:
* Replay same level with replay,
* Replay same level without replay,
* Manually save replay of finished attempt,
* Autosave replay of finished successful attempt.

All these must happen before I can release the feature. Otherwise, we'd have functional regression from the current 0.9.38 that does all of this in the level browser.

-- Simon

[Simon]

The end-of-level screen with next-level offering is a broccoli feature. It wouldn't have been easy to persuade me that Lix needs to offer the next unsolved level, but since it's functional (albeit yet crude), I don't want to miss it anymore. I've played through a third of lemforum pack in a continuous session. I haven't played this much Lix singleplayer for years.

As icing, this needs directory completion stats in the browser, and perhaps a button in the browser that also finds your next unsolved level.

The end-of-level screen isn't done yet; see bugs in previous post. But the development this year was a good investment.

(I call a feature a carrot if people clamor for it, with sound arguments even, but then don't use it after it's implemented. A broccoli feature is the opposite, super comfortable and important after getting used to it, but really hard to convince the developers to implement it. Nobody but me uses those terms, and they're far-fetched.)

-- Simon

[Simon]

This is how the end-of-singleplayer screen looks in 0.9.39, which I released 2021-10-12.

There are stats at the top-left, similar to what appeared in the browser in ≤ 0.9.38.

Below the stats, there is the usual feedback on replay autosaving and the button to save the replay manually. It should have the same functionality as in ≤ 0.9.38, but we can improve it in the future. E.g., Proxima (?) has always wanted to type an arbitrary filename on manual saving, and I'm contemplating to add quick backroute judging.

At the top right, we have the level that we just played. The caption changes depending on whether your attempt was solved; it says "Try again:" if unsolved. The area is really a huge button, you can click that level to play again, without replay. There isn't a way to resume the just-played replay, let me know if that becomes a problem.

This means that the top half of the screen is about the just-played level.

At the bottom, we have one or two next levels. These appear even if you didn't win. Until today, that survey got 3 yes, 0 no, 1 don't mind. We'll see how it feels!

Performance of the next-level finding code: I haven't looked into it further yet. Let me know how long the screen takes to come up when you get to it for the first time after running Lix. If it takes too long, I'll make the bottom area empty first, parallelize the file searches, and add the next levels when they're found.

I'm looking into a small library dependency issue to make stuff easy for Linux package maintainers. Otherwise, this is all good to go.

-- Simon