I’m a little surprised that these things aren’t automatically validated based on a given savefile and the seed that was used.
For example, Brogue saves store the initial RNG seed, as well as all the actions taken afterwards. Combined, this means that any given save can be “validated” by generating a map using the same seed, running each of the player’s actions, and then confirming that the game is in the same state that the save-file describes. It works, because even a tiny bit of unfair manipulation would result in a butterfly effect cascading through the rest of the playthrough, affecting later floor generation, monster behaviour, loot cache generation, etc.
Brogue is of course a traditional roguelike, and its turn-based nature allows this kind of validation that can’t be performed to the same degree with other games. Still, couldn’t there be a tool to at least confirm that it’s possible for a specific item seen in a save-file to spawn at the level it did? Or something along those lines?
The article describes people now doing the kind of reverse engineering needed to implement something like that… So it’s not that surprising it wasn’t done back in 2009?
The proprietary nature is a roadblock but all in all near universal, so pretty habitual.
Integration with reproducibility or speedrunning is a big thing however, for instance the team had to exhaustively search for the seed, but it’s not uncommon for modern roguelikes / dungeon crawlers to straight up give you the game seed, so repro is easy, and a spliced run would be impossible to miss.
Absolutely, I’m not saying that Diablo (or Diablo communities) should pursue the same method that Brogue uses. Saves could, though, record what floor or room an item was found in, and that could be checked for being possible on the server side if the save-file is uploaded anywhere.
Around 1GB per save game then :-) Double it if you’re a completionist.
Keep in mind that in 1997 the cost of 1GB was around $100 in the US (equivalent to ~$200 today).
I think 13 bytes/tick would be very, very, very high. Even simple RLE compression would probably save a looooooot of entries for ticks on which the player doesn’t click anything.
I figure a fairly naive encoding for Diablo 1 input per tick would be something like 4 bytes for mouse position, 1 bit for mouse button y/n, 7 bits for keyboard scan code if set.
It’s funny nobody noticed the other inconsistencies, like the mysteriously changing inventory and such. You’d think with such an “impossibly lucky” speedrun, people would pay attention to things like that.
I’m a little surprised that these things aren’t automatically validated based on a given savefile and the seed that was used.
For example, Brogue saves store the initial RNG seed, as well as all the actions taken afterwards. Combined, this means that any given save can be “validated” by generating a map using the same seed, running each of the player’s actions, and then confirming that the game is in the same state that the save-file describes. It works, because even a tiny bit of unfair manipulation would result in a butterfly effect cascading through the rest of the playthrough, affecting later floor generation, monster behaviour, loot cache generation, etc.
Brogue is of course a traditional roguelike, and its turn-based nature allows this kind of validation that can’t be performed to the same degree with other games. Still, couldn’t there be a tool to at least confirm that it’s possible for a specific item seen in a save-file to spawn at the level it did? Or something along those lines?
The article describes people now doing the kind of reverse engineering needed to implement something like that… So it’s not that surprising it wasn’t done back in 2009?
True, I guess the game being proprietary just makes these things exponentially harder…
The proprietary nature is a roadblock but all in all near universal, so pretty habitual.
Integration with reproducibility or speedrunning is a big thing however, for instance the team had to exhaustively search for the seed, but it’s not uncommon for modern roguelikes / dungeon crawlers to straight up give you the game seed, so repro is easy, and a spliced run would be impossible to miss.
How big would a Diablo save file be if it recorded ALL actions?
Absolutely, I’m not saying that Diablo (or Diablo communities) should pursue the same method that Brogue uses. Saves could, though, record what floor or room an item was found in, and that could be checked for being possible on the server side if the save-file is uploaded anywhere.
it wouldn’t be that bad. you basically need to record mouse and keyboard events at ~60Hz
you’re looking at megabytes per hour. which they probably wouldn’t want to do back when they released it in 1996, but it’s a trivial amount these days
The game ticks at 20Hz apparently, so that’s 72k ticks per hour. 1MB/hr if you can keep the per frame input data no higher than 13.889 bytes per tick.
Around 1GB per save game then :-) Double it if you’re a completionist. Keep in mind that in 1997 the cost of 1GB was around $100 in the US (equivalent to ~$200 today).
Hah, sure.
I think 13 bytes/tick would be very, very, very high. Even simple RLE compression would probably save a looooooot of entries for ticks on which the player doesn’t click anything.
I figure a fairly naive encoding for Diablo 1 input per tick would be something like 4 bytes for mouse position, 1 bit for mouse button y/n, 7 bits for keyboard scan code if set.
[Comment removed by author]
It’s funny nobody noticed the other inconsistencies, like the mysteriously changing inventory and such. You’d think with such an “impossibly lucky” speedrun, people would pay attention to things like that.