Key of a level: How to map replays/trophies to levels

[Simon]

Lix 0.9.17 has:

• A level is identified by its full filename (path within levels/ plus the file's basename).
  
• Identical level files in different directories are considered different levels for replay-to-level matching and for trophies (checkmarks).
  
• Within larger sets of levels, it's popular to have ranks, i.e., one directory per 30-ish levels of that larger set.
  

Problems of 0.9.17:

• When a level moves between ranks (e.g., we reorder levels in lemforum), that level's replays will point to nonexistant file and that level's trophies are lost.
  
• The level is the unit of culture. The rank or the pack are arbitrary distribution methods and should not count towards level identity.
  

Ideas:

• Consider two levels the same when they have the same basename (= the tail of the full filename that is independent of directories) and the levels have identical level titles and authors.
  
• This treats the level directory as an associative array (a.k.a. dictionary) where a key is level title plus author plus basename (filename independent of directory). A value is then a level (the data in the file, not the file itself).
  
• Store trophies (checkmarks) by key (basename, level title, author) and let replays point to keys instead of to full filenames.
  
• Given a level file, it is trivial to determine its key. For each level, it remains fast to retrieve trophies.
  
• To match replays back to levels, accept a dent in performance: When you have a key (filename without directory, level title, author), e.g., because a replay points to that key, you must first list the entire tree and then open all listed files with matching basename (usually 1 match but might be a couple more) to compare title and author.
  
• To get the performance back, cache the key-to-full-filename resolution. While Lix is running, slowly index all files in the tree in the background. This would also make the search feature faster on Windows (slow harddisks, Windows itself, and Windows's virus scans nuke the search's performance).
  

Questions

• When do you consider two levels the same for trophies (checkmarks) and replay-to-level-mapping? When only decoration changes, the level should probably still count the same. How about renaming the level file? How about moving the file or changing the level title? How about changing the skillset or number of lix?
  
• Should the basename be part of the key? Or should the key consist only of level title and author? Should it consist of other things?
  
• Or continue to map replays/trophies to levels by full filename alone, accepting above problems of 0.9.17?
  
• For a selected level, I'd like to list all replays that point to this level. How should I implement that? Either I'll have to index the entire replay directory on demand (awfully slow), index the replay tree slowly in the background (feels weird for replays, but maybe okay), or require that replays for a level be put in a certain directory structure (but Nepster complained about Lix's replay directory structure, he wanted to sort replays by level position first, only then by solved/manual/proofs/...).
  
• Can we require that a replay's basename should start with the basename of the level? That makes it much nicer to find replays for a given level file.
  

Older topic: Musings on level culture, 2017-07.

-- Simon

[Simon]

I want to implement this. Trophies (checkmarks) should be tied to basename (not path), title, and author.

I will still keep the file format in ./data/user/yourname.txt even though I'm unhappy with it, for backwards compatibility. In the long run, all options should be stored e.g. in ./user/.

-- Simon

[Simon]

More musing on the level-replay-trophy association. (Trophies are checkmarks for solved levels.)

I'm slightly hesitant about (tying trophies to basename + title + author), and will improve the level-to-replay-matching first.

In theory, the following associations can each follow vastly different rules:

• For a given replay, find the level. (In 0.9.18, it's by level filename including path.)
• For a given level, find its trophy. (In 0.9.18, it's by level filename including path.)
• For a given level, find all replays. (In 0.9.18, it's not supported at all.)

Of course, Lix, as an ecosystem, is easier to understand if all these associations follow the same rule.

I'll implement: For a given level, find all replays that play meaningfully against it. I'll do this by looking at the basename (= filename without path) of level and replay: If the level is called mylevel.txt, I'll find mylevel-Simon-2000-01-01.txt. Rule: The basename should be identical to the head of the replay's basename, and the remainder of the replay's basename begins with a dash -. Maybe I'll ignore numbers or other versioning strings (people like to make copies of a level but still consider it the same level for replay-level-association).

That leaves the decision about the association for later. In particular, this doesn't change any existing format.

-- Simon

[namida]

Let's suppose we did rely on just basename + title + author.

What happens when we have a level like We All Fall Down? (Admittedly, most fanmade levels following a similar pattern seem to name them Part 1, Part 2, etc - though if you ignore numbers, this could still cause problems as all of them would just register as "We All Fall Down Part". If they were instead "Part I", "Part II", etc, that would avert this problem, though I don't really know which is more common.)

[Simon]

Yeah, a few levels have names mylevel.txt and mylevel2.txt, and they are distinct levels whose replays should not be merged.

I consider such levels dubious; for fresh ideas, I encourage fresh, independent visuals and names. But the game should function as expected even when designers do not follow such advice.

Nepster's suggestion is (never consider different level basenames the same for replay lookup by replay basename). Maybe consider two levels the same if their names are equal after cutting off anything past +, an arbitrarily chosen character? Or maybe don't bake anything at all into the dialog that retrieves replays.

-- Simon