score / tape / level server futures...
Posted: Mon Nov 08, 2021 11:09 am
I understand the server validates, or attempts to validate, score / tape files. Some questions, suggestions, and ideas about that:
If a level is solved, a tape is uploaded. The server then tests whether it solves a level; but this is asynchronous.
If it turns out to be a levelset the server knows of; a level number it has a copy of; and the tape actually solves that level -- all good. But there are a number of things that can go wrong! Here are some ideas about handling some of them.
Scenario: server knows of this levelset:level, but the uploaded tape doesn't solve that level: alert the player by marking it somehow in the 'hall of fame' part of the game UI; and possibly by some sort of notification (because it's async -- by the time the local game learns of the discrepancy, he's playing the next level; or maybe he quit and a month has gone by.)
Why would the local game & server disagree about whether a tape solves a level?
- bugs in compiler or CPU on client or server
- different RnD versions
- non-identical level definitions
- some sort of cheating by the player
- ?????
Server could request a copy of the client's level definition. If it's identical (or if it's different but still doesn't solve with the provided tape), it knows something is weird, and should notify the player.
If it's different and does solve, maybe the server saves it as a 'variant' of that levelset:level (meaning the server's namespace for levels is now actually levelset:level:variant, though most won't have :variant).
This potentially also 'solves', in a sort of baroque way, cases where two unrelated or more-or-less disjoint levelsets have the same name: I noticed that I have two 'BD4' levelsets: levels/DX-Boulderdash/dx_bd4 'BD4' by 'ECI' with 100 levels, and levels/Emerald_Mine_Club/emc_bd4 'BD4' by 'Paul Williams' with 81 single-player levels and 21 2-player. (But RnD has no trouble distinguishing these locally -- obviously the levelset paths are different, but also the tapes are stored in ~/.rocksndiamonds/tapes/{dx_bd4,emc_bd4}; whereas the server seems to index by the 'name:' field from levelinfo.conf, not the directory name. I couldn't find the DX BD4 levelset in the server UI, which makes sense if they're indexed by name with no 'variant' system. It would be better if a 'variant' system only needed to be used for actual variants, not entirely different levelsets. Though, of course, my example levelsets aren't actually 'entirely different', just ports of the same levels to different historic gaming systems...) (I haven't tested whether tapes from one of the BD4 levelsets solve the other -- I suspect not. In fact, my saved dx_bd4 tapes don't even reliably solve their own levels, possibly because they were recorded under RnD 3.2.6.1 ...)
The same procedures could collect copies of levelsets completely unknown to the server.
Unlike tapes, it seems like levelsets should not be collected entirely automatically. There are copyright and ethical issues. I would want the game to dialog with the player at least once per new levelset, asking things like:
- did you create this levelset?
- [ if not: ] where / how did you get it?
- do you have permission to upload it to a public repository?
- do we have permission to upload it?
Things could get quite hairy if the levelset.conf refers to custom graphics, sound, music. Not too bad if they're specifically for this levelset, but if it refers out to another levelset's artwork, two new problems arise. It might be another levelset unknown to the server, so now the collection has become recursive. Or it might be known, but the player's copy actually has different artwork contents than the server (so now we have artwork variants...)
Dealing with that stuff seems like it might be too gnarly for automated handling. However, as far as I know, whether a tape solves a level definition is never affected by the artwork files -- so I suppose the server could be a repository of bare level definitions, decoupled from their artwork.
Of course if you can upload levelsets then players should be able to download levelsets. (I'm pretty sure you already had that in mind...) So, while browsing the score server, they should be able to point at a levelset and say 'put this on my machine'.
=====
In sum:
- feed back to the player if their tape doesn't solve on the server
- this involves async notifications which might come after the next level was played, or next time the game is run
- collect, retain, and handle as (effectively) different levels, variants of known levelset:levels
- collect unknown levelsets; possibly with artwork, but likely not
- try to be careful about copyright stuff in collecting levelsets
- also provide levelset downloading
=====
wheeee! :)
If a level is solved, a tape is uploaded. The server then tests whether it solves a level; but this is asynchronous.
If it turns out to be a levelset the server knows of; a level number it has a copy of; and the tape actually solves that level -- all good. But there are a number of things that can go wrong! Here are some ideas about handling some of them.
Scenario: server knows of this levelset:level, but the uploaded tape doesn't solve that level: alert the player by marking it somehow in the 'hall of fame' part of the game UI; and possibly by some sort of notification (because it's async -- by the time the local game learns of the discrepancy, he's playing the next level; or maybe he quit and a month has gone by.)
Why would the local game & server disagree about whether a tape solves a level?
- bugs in compiler or CPU on client or server
- different RnD versions
- non-identical level definitions
- some sort of cheating by the player
- ?????
Server could request a copy of the client's level definition. If it's identical (or if it's different but still doesn't solve with the provided tape), it knows something is weird, and should notify the player.
If it's different and does solve, maybe the server saves it as a 'variant' of that levelset:level (meaning the server's namespace for levels is now actually levelset:level:variant, though most won't have :variant).
This potentially also 'solves', in a sort of baroque way, cases where two unrelated or more-or-less disjoint levelsets have the same name: I noticed that I have two 'BD4' levelsets: levels/DX-Boulderdash/dx_bd4 'BD4' by 'ECI' with 100 levels, and levels/Emerald_Mine_Club/emc_bd4 'BD4' by 'Paul Williams' with 81 single-player levels and 21 2-player. (But RnD has no trouble distinguishing these locally -- obviously the levelset paths are different, but also the tapes are stored in ~/.rocksndiamonds/tapes/{dx_bd4,emc_bd4}; whereas the server seems to index by the 'name:' field from levelinfo.conf, not the directory name. I couldn't find the DX BD4 levelset in the server UI, which makes sense if they're indexed by name with no 'variant' system. It would be better if a 'variant' system only needed to be used for actual variants, not entirely different levelsets. Though, of course, my example levelsets aren't actually 'entirely different', just ports of the same levels to different historic gaming systems...) (I haven't tested whether tapes from one of the BD4 levelsets solve the other -- I suspect not. In fact, my saved dx_bd4 tapes don't even reliably solve their own levels, possibly because they were recorded under RnD 3.2.6.1 ...)
The same procedures could collect copies of levelsets completely unknown to the server.
Unlike tapes, it seems like levelsets should not be collected entirely automatically. There are copyright and ethical issues. I would want the game to dialog with the player at least once per new levelset, asking things like:
- did you create this levelset?
- [ if not: ] where / how did you get it?
- do you have permission to upload it to a public repository?
- do we have permission to upload it?
Things could get quite hairy if the levelset.conf refers to custom graphics, sound, music. Not too bad if they're specifically for this levelset, but if it refers out to another levelset's artwork, two new problems arise. It might be another levelset unknown to the server, so now the collection has become recursive. Or it might be known, but the player's copy actually has different artwork contents than the server (so now we have artwork variants...)
Dealing with that stuff seems like it might be too gnarly for automated handling. However, as far as I know, whether a tape solves a level definition is never affected by the artwork files -- so I suppose the server could be a repository of bare level definitions, decoupled from their artwork.
Of course if you can upload levelsets then players should be able to download levelsets. (I'm pretty sure you already had that in mind...) So, while browsing the score server, they should be able to point at a levelset and say 'put this on my machine'.
=====
In sum:
- feed back to the player if their tape doesn't solve on the server
- this involves async notifications which might come after the next level was played, or next time the game is run
- collect, retain, and handle as (effectively) different levels, variants of known levelset:levels
- collect unknown levelsets; possibly with artwork, but likely not
- try to be careful about copyright stuff in collecting levelsets
- also provide levelset downloading
=====
wheeee! :)