Author Topic: End-of-singleplayer screen  (Read 316 times)

0 Members and 1 Guest are viewing this topic.

Offline Simon

  • Administrator
  • Posts: 3129
    • View Profile
    • Lix
End-of-singleplayer screen
« on: May 02, 2021, 10:27:46 AM »
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. :lix-evil: 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
« Last Edit: May 02, 2021, 10:37:36 AM by Simon »

Offline Simon

  • Administrator
  • Posts: 3129
    • View Profile
    • Lix
Re: End-of-singleplayer screen
« Reply #1 on: May 16, 2021, 09:53:15 AM »
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

Offline Simon

  • Administrator
  • Posts: 3129
    • View Profile
    • Lix
Re: End-of-singleplayer screen
« Reply #2 on: June 14, 2021, 05:39:49 AM »
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