[Suggestion][Player] Record "Fewest Skills Used" and "Largest Excess Saved"

[Crane]

I would like to suggest a couple of new statistics saved for completed levels, and that's "Fewest Skills Used", which is the total count of individual tasks assigned to lemmings, and "Largest Excess Saved", or something to that effect, which is the number of lemmings saved minus the number required (so 0 is exactly the number required).  This would cut the need to have lots of talismans for saving 100% except on the most difficult levels, but also allow a challenge for everyone in saving as many lemmings as they can on all levels.

I would suggest having these statistics on the level select pane from the main menu, and also adding "Best time" to that list too.

This will also help in tracking one's progress on some of the level completion contests.

[namida]

NeoLemmix already keeps track of the most lemmings saved, although it tracks this as an absolute number rather than relative to the save requirement. It's displayed on the postview screen.

[Crane]

Oh of course it does!  Somehow I forgot it was there even though I was staring right at it!

[namida]

I also don't believe it tracks fewest skills used; or at the very least, doesn't display it anywhere.

[Crane]

I figured that would be a nice one to add, especially for the 20-of-everything levels and the like.

[namida]

Agreed. I don't think it would be too tricky to implement - the game already keeps track of skills used, for talisman purposes. Even if that wasn't there, or isn't preserved through to the postview screen, replay data absolutely <i>is</i> still in memory when you're on the postview screen, and used skill counts could be reconstructed from that. Keeping track of it could be done exactly the same way as it is for the other records, so the only question would be where to display it.

[Crane]

I would personally display it on the level select screen, below the "talismans unlocked" label (if present).

[Nepster]

Yes, this should not be too hard to implement, although the number of lemmings saved is not yet written into the userdata.nxsv file.
The bigger question would be: When exactly should we update to records of max_saved_lemmings, min_skills and min_time_to_save_the_requirement?
1) Independantly: Whenever we solve a level, we check each of the three stats and update them if they are better than the previous record.
2) Saved > Skill > Time: If max_saved_lemmings is better, then overwrite all three, even if we are worse on the others. If max_saved_lemmings is equal, then compare min_skills, etc. This would correspond to the rating method of the first two level solving contests.
3) Skill > Saved > Time: Similar to point 2), but for the rating system of the third level solving contest. This is probably not what an arbitrary player would want, though.
4) Something else? The please post your suggestions!

[Simon]

4) Something else?

A trophy is a structure of

• number of lems saved at the end of the entire attempt,
  
• number of skills assigned until a given happy condition is true, and
  
• number of physics updates that passed after the initial state until the happy condition is true. If the condition becomes true halfway through a physics update, this physics update counts entirely towards this number.

For each level, the game shall keep 3 trophies:

• Max saved trophy, where the happy condition is the final exiting of the entire attempt, and trophies are ordered by (more saved first, then fewer skills, then shorter time).
  
• Min skill trophy, where the happy event is satisfying the save requirement, and trophies are ordered by (fewest skills first, then more saved, then shorter time).
  
• Speed trophy, where the happy event is satisfying the save requirement, and trophies are ordered by (shortest time first, then more saved, then fewest skills).
  

Achievements are not part of this design and I will not attempt to fit those in; this is an exercise for the reader. Maybe there will be exactly 1 extra trophy per achievement, maybe there will be exactly 3 extra trophies per achievement (logical-and the normal happy event with satisfying the achievement), ... There are similarities between achievements and level repeats.

If this 3x3 idea won't fly, then Nepster's 1) feels best, record all metrics independently from each other.

-- Simon

[namida]

Yes, this should not be too hard to implement, although the number of lemmings saved is not yet written into the userdata.nxsv file.

Are you sure about this? I'm almost certain that the lemmings saved record is kept, unless this feature has been removed in a recent update. I'm 100% sure V10.13.18 had this feature and 99% sure at least some new-formats versions have it too. (On the other hand, I can't rule out that userdata.nxsv isn't the file that tracks it.)

EDIT: 100% confirmed, both the lemmings saved record and time taken record are saved, and they do indeed go into userdata.nxsv, in V12.4.0.

[Simon]

I split off Other's replays should not overwrite own records, it's an excellent standalone issue, and it's orthogonal to saving more stats.

-- Simon

[Crane]

I would say each stat is updated independently.  You may have a solution that saves 100% but uses a lot of skills, and another solution that, say, saves 60% but uses a very small number of tools.  One should not overwrite the other.  Personally, I'd say that as long as the level is completed with at least the minimum number of required lemmings, each stat is checked independently.  So if you manage to save 100% for the first time ever, it doesn't overwrite the minimum number of skills if you've already managed to complete it with fewer skills than the current attempt.

Similarly with time.

[Nepster]

Yes, this should not be too hard to implement, although the number of lemmings saved is not yet written into the userdata.nxsv file.

Are you sure about this? I'm almost certain that the lemmings saved record is kept...

Sorry, my bad: I wanted to write "although the number of skills used is not yet written...". Not sure why it became "lemmings saved" there...

Personally I would prefer 2), but if most of you want 1) I will implement it. The 3x3-proposal seems like too much info, and we will run into a lot more trouble concerning displaying all this data, especially as it seems like information overload to the casual player. I will wait a bit before implementing 1), to allow more opinions stated here.

[namida]

While the contests may be a special case, to me it feels like generally speaking (eg. in the context of challenges, for example), each one would usually be an entirely separate record.

Simon's idea seems nice, but also tricky to implement and display, as Nepster mentions. If the tracking side isn't such a big deal, perhaps it could be tracked and saved but not displayed in the interface, with users who are interested able to obtain the information by opening userdata.nxsv in a text editor. Otherwise, I'm going to have to yeah, go with option #1.

[ccexplore]

If the tracking side isn't such a big deal, perhaps it could be tracked and saved but not displayed in the interface, with users who are interested able to obtain the information by opening userdata.nxsv in a text editor.

I'd second this.  If it's already possible (or trivial to implement) to store multiple record details for one level in userdata.nxsv and it's ok to have a little bit of bloat (which I think is negligible in practice anyway), it'd make sense to consider a system that may track more than what you currently display, so we have a separation between the data and the UI, and can iterate on the UI over time based on what people like to see.

Assume we've already decided on the set of statistics of interest (ie. from the thread, we have "lemmings saved", "skill used", "time to meeting save requirement").  Each solution then produces a potential record consisting of the combination of values of the statistics that the solution achieves.  The list of existing records for the level will then be managed as follows:

1) If the potential record improves on at least one statistic (could be worse/equal in other statistics) compared to at least one existing record, or if this is the very first solution so the list is empty, then we add it to the list of records.  If this condition isn't met then it means every existing record beats this potential record across all statistics, ie. no improvements whatsoever, so we're done.
2) also, if this new record is better or equal in all statistics to an existing record, then any such existing record has been completely superceded by this new record, and all such records will be removed from the list.
3) finally, for each statistic, we calculate the best value seen for that statistic across the updated list of records.  Any records in the list that does not achieve a best value in at least one statistic will be removed from the list. (Not sure if this rule might also make #2 redundant, I suspect so but don't feel like working it out.) [edit: not redundant]

The UI should be able to work out what to display by suitably sorting the list according to the statistics in some ranked ordering (eg. "most saved", then "fewest skills", then fastest), and pick out the resulting best record.  Similarly, the user can potentially copy-paste the list of records from userdata.nxsv into a spreadsheet program and performs the same kind of manipulation there manually to determine the result they need.

We may be keeping more data then is strictly necessary even to support all possible schemes of ranking of the statistics, but I think the above rules should help manage a good deal of possible bloat compared to a more naive scheme that keeps all records or only handles rules #1 and #2, and is still simple enough from an implementation standpoint.