![36770-Diablo_[U]-1.jpg](https://i.imgur.com/wMBtPge.jpg "36770-Diablo_[U]-1.jpg")
What do you guys think a 16-bit port of Diablo would be like?
More repeating tiles because of limited space, but otherwise, probably not all that different if it was on say a SNES.
>>3043302
>More repeating tiles because of limited space
I believe Diablo uses far less tiles than games like Chrono Trigger or Final Fantasy VI. The game isn't very expansive, and the environments don't have that many details.
If I'm not mistaken though, buildings in Diablo are object models and not tiles. I'm not sure how the logic for that works, but all of the objects could probably be converted into a tileset regardless.
Save space is a big problem in my eyes. The PS1 port already had ridiculous needs and floppies didn't cut it either so only systems with hard drives can really be considered.
>>3044067
Passwords.
>>3044071
A password encoding several MB worth of information?
>>3044076
It probably would need some simplification but games like Megami Tensei or Dragon Quest work with a password system.
>>3044081
It worked poorly for them. And they used it because there was no battery powered RAM available, not because 8 kB of that stuff didn't cut it.
>>3044071
Diablo tracks a ludicrous amount of data in its save files. There is absolutely no possibility of a workable password system.
Even to use SRAM you would need to pre-generate most item/attribute combinations, store them in ROM and then reference in the save data by index.
>>3044076
>A password encoding several MB worth of information?
I have no idea why Diablo's character files are so large. There shouldn't be that many flags for the game to keep track of. The saves might in fact be save states rather than flag-driven data, which is retarded.
>>3044241
Nearly all of Diablo's levels and items are generated. All of that information has to get stored. You could have two of the same item yet their attributes can be quite different.
>>3044241
That's probably because of the maps, which are randomly generated each time you play. It would be inconvenient to do a memory dump.
>>3044279
I guess a 16-bit port would either have predetermined maps to minimize save space or be shorter so you can beat it in one sitting
>>3044295
Or It could have randomly generated floors (which was a big feature of Diablo), but you would be able to access only one floor at a time.
Do people actually play diablo? Because you guys know that it's just a roguelikes and pretty much every actual roguelike is more complex and interesting than diablo
>>3044203
This. Saving on the PS1 port of Diablo can take 10–15 blocks (default memory cards were 15). Awful.
>>3044269
just store the seed, re-generate on load
>>3043290
>What do you guys think a 16-bit port of Diablo would be like?
Like a shitty real-time version of Fushigi no Dungeon.
>>3043329
>If I'm not mistaken though, buildings in Diablo are object models and not tiles.
No, they are pre rendered. There are no polygons in Diablo.
>>3043290
Better than the original due to superior controls.
What are we all going to do in the year 2065 when Diablo 1's random seed goes static?!
>>3045359
I don't plan to live past 70 so I'll have checked out a few years before that happens. Not my concern.
>>3045359
elaborate
>>3045165
That might help with initial map layout, but it doesn't help at all with status of interactables, map discovered, monsters or the player's inventory.
>>3045461
I can accept that. This information would be lost during save. If the game makes that aware and is consistent about it though, that's a feasible option. Pondering Diablo on a 16-bit system is all about compromises and alternatives
>>3045463
>losing all your progress basically your entire character
>acceptable
>>3045464
>basically your entire character
what?
The story has very simple checkpoints, that can easily be flagged. All inventory items have seeds, and inventory size is limited. The only thing you'd lose between plays is items in a map and fog, but that can be explained away in-game
>>3045467
You cannot generate the player's inventory with a seeded procedure. In fact you can't generate anything that is the result of player action at all. You can't even guarantee the same items in a run with the same seed because the order in which the player does things changes the order in which the pseudorandom values are plucked from the RNG.
Basically the entire concept of rebuilding the game state procedurally is fucked the instant the player makes their first decision at the start of the game.
>The only thing you'd lose between plays is items in a map and fog
You lose:
Map discovery
Monster location and status
Interactable object status
Destructible object status
Items on the ground
Player's inventory
Basically all you can do with the seed is start the same dungeon over from the start.
>>3045540
>You can't even guarantee the same items in a run with the same seed because the order in which the player does things changes the order in which the pseudorandom values are plucked from the RNG
Which is why you save for each item the seed of the rng immediately before the item was generated, or said differently, the value of the rng that was drawn to generate the item.
That is, you do not save one seed to rule them all, but the state of the rng for each item and level. Your inventory is limited in size, and there is a limited number of maps, so that is feasible.
>Map discovery
>Monster location and status
in game explanation: time passed since you saved, stuff the monsters are back, and you are not sure on the specifics of the map any longer, so discovery is at zero. The map itself is unchanged.
>Interactable object status
>Destructible object status
Not sure on those
>Items on the ground
someone else took them after you saved
>Player's inventory
each item has its own rng seed, the state of the rng as the item was generated, that's all that needs to be saved, for items that actually are rng based (not potions and stuff)
>Basically all you can do with the seed is start the same dungeon over from the start.
You keep your inventory, you keep story progression. "mobile" things, like monsters and items on the ground are gone, because you were gone.
>>3043290
>What do you guys think a 16-bit port of Diablo would be like?
pixelated.
>>3043329
>buildings in Diablo are object models and not tiles
I bet you think Sonic 3D Blast and Donkey Kong Country use 3D models too
>>3045359
por que?
>>3045579
He meant it's a huge sprite, not part of the background.
>>3045820
That's amazing, how i didn't know about that?
>>3045549
You're talking about cutting out sections of the game to put in a password system. Diablo's save system is bulky but perfectly acceptable given the systems it was running on, and benefits the game immensely.
And the playstation version can keep a character saved in reasonable space. It's just impossible to actually set up a password system unless you rework the entire progression system of the game. You have to stop the seeding at it's core, not just make the game lose specific functions of the seeding process. It has to be a preset game of diablo. Nothing random. Enemies always in the same spot. Same map. Same items in the same locations. That's the only way a password system would work.
And that's ignoring losing out on one of the best video game soundtracks of all time, a travesty in it's own right.
>>3046026
>You're talking about cutting out sections of the game to put in a password system
NVRAM. Password can't hold enough data. That said, yes, I'm altering aspects of the game to make it work on a different platform. Welcome to the world of mid 90s ports.
>You have to stop the seeding at it's core, not just make the game lose specific functions of the seeding process
What? An RNG is just some code and a current value. A seed is simply a defined current value. Whenever you need a new value, you just feed it the last value, and wait a moment. That's it. That's all there is to it. It has no bigger state. On a code level, at any point during execution you can simply dump the last retrieved RNG value, to get repeatable execution. So when the game's about to generate a new item, you just poll the RNG for the current value, put it aside, then let the item generation code go to work. Next time you need to re-generate the value (loading a game), you hand the stored value over to the RNG, then let it generate an item. It'll be the exact same item, with all consequences. Same with levels, etc. You just override the RNG at specific moments, feeding it a seed instead of whatever it's currently using. Everything new is still getting generated on its own (don't override the global RNG state), and is still perfectly random. So first time you encounter a location, the RNG will randomly generate it, but you remember the state of the RNG immediately before it. Next time you load that location, everything's the same. Visit the location from a different save state, and obviously the RNG is in a different state, leading to a different map.
>losing out on one of the best video game soundtracks of all time
tracker music is fairly compact
It would look exactly like this
>>3046030
>Welcome to the world of mid 90s ports.
Well yeah, of course. I know that if you wanted to make a out-of-generation port to a 16 bit console you would have to make cuts.
>What? An RNG is just some code and a current value.
I understand that, but do you know how much power diablo required to do what it did, as far as actually generating it's levels and items were concerned? Loading a level on a computer that met the minimum reqs was not a quick affair. I'm uncertain you can retool the game to even attempt to run on a SNES given how much memory and processing power it needed, unless you were to specifically make the game static. We're talking about a game that asks you to have 8mb of ram ready to dedicate entirely to to task of the game, 128kb of which the SNES has covered.
I'm actually convinced the poor console would spontaneously combust. But it would be fun to see if you COULD retool it to run on SNES. Doom asked for much less than Diablo and managed a shoddy port. It would be even worse than that.
>>3046080
>do you know how much power diablo required to do what it did, as far as actually generating it's levels and items were concerned?
Irrelevant, that code is not realtime
>given how much memory (...) it needed
That might be more relevant. The map generator would probably have to be more simple.
>unless you were to specifically make the game static
No idea where that obsession is coming from. Procedurally generated material takes up considerably less space on the cart. Trying to make the game static is gonna bloat your cart like crazy. Unless you mean a fixed seed, which is unnecessary, as the generator code does not change.
>We're talking about a game that asks you to have 8mb of ram ready to dedicate entirely to to task of the game
Within a consumer OS, without dedicated hardware for tiling, with that figure including video memory, with that figure assuming at least 640x480, probably double buffering.
>I'm actually convinced the poor console would spontaneously combust
So you are
>Doom asked for much less than Diablo
Please tell me you'Re kidding. Doom practically requires flat mapped memory and gains nothing from hardware tiling support. Getting Doom to work on the SNES was working against anything and everything the SNES can do. It's the equivalent of going grocery shopping with a Ferrari, and then surprisingly having issues with the trunk space.
>>3046095
>That might be more relevant. The map generator would probably have to be more simple.
Of course. But you have to simplify everything else at the same time. It wasn't just the levels that were random. And it generated it all at once.
>No idea where that obsession is coming from. Procedurally generated material takes up considerably less space on the cart. Trying to make the game static is gonna bloat your cart like crazy. Unless you mean a fixed seed, which is unnecessary, as the generator code does not change.
I'm saying that's the only way the game is actually going to generate a level, items, and other things in a reasonable time frame. I understand how impossible it would be to fit the game onto a cartridge if you were to simply make it static, unless you were to make the entire game based around the first four levels.
>Within a consumer OS, without dedicated hardware for tiling, with that figure including video memory, with that figure assuming at least 640x480, probably double buffering.
Well, of course. And you know how much RAM the SNES had ready to dedicate to video, let alone processes outside of that, in comparison to that rather large number? We're talking an order of magnitude of difference here. Even at half that number.
>Please tell me you're kidding
Of course, I'm just poking fun at the Doom port.
>>3046123
>And it generated it all at once
That's not necessary.
>actually going to generate a level, items, and other things in a reasonable time frame
There's nothing about procedural generation that says it must be slow.
>We're talking an order of magnitude of difference here. Even at half that number.
And we're talking vastly different environments here. It's not uncommon that a non-trivial part of that "required" memory was householding for video and sound, TSRs, drivers, stuff the SNES does natively, or has nothing to do with.
I was thinking about how you could port or even demake Half-Life for the PS1, then I've come to the sad conclusion that the biggest roadblock is how you could save your game with only 8kb. I checked my PC save files and they're as little as 220kb and as big as 728kb. I suppose they're save states, but this isn't like Quake 2 where you can just save password capable things like your furthest mission. Half-Life doesn't have fading corpses and your inventory isn't determined by what "mission" you made it to. Oh well. To get back on topic, it's impressive how a game like Diablo where anything can happen and needs to be recorded, can fit to PS1 memory blocks.
>>3046048
So it would magically turn into Diablo 2?
>>3046403
yeah I'm sure that was THE ONLY roadblock
>>3045359
...turn back the clock. How fucken hard is that, m8? By that time you'd have to be running it on a virtual machine anyway and you won't even need to touch your system clock.
>>3045359
what are you talking about?
>>3047542
Nonsense.
>>3043290
exactly like this, of course some huge compression technique would be required, and an extra chip with 2 batteries maybe some sort of crazy shit
>>3043290
https://youtu.be/A5uQFviNoIc
>>3043290
We almost had an 8-bit version
https://www.unseen64.net/2008/04/05/diablo-gameboy-cancelled/
>>3049561
>install Oblivion
>see this thing being shilled on the installer
>>3049568
is... is that a cell phone game? they made an elder scrolls game for cell phones?
>>3043290
Probably something like this.
>>3049668
Yes, same wit Sonic, Doom, etc.
>>3045374
>>3045653
>>3046827
>>3047517
>>3047521
>>3047542
not him, nor do I know how true what hes saying is, but I think hes referring to when the internal clock that the Diablo 1 RNG calculation is based on gets capped out as time progresses. All RNG in every game is based an scripts that use a random time reference as a way to base what the randomly generated number will be. there is no true RNG, but only simulated RNG. If you click to randomize 5 times it will seem random, but if you were to turn back time and do it again at the same points in time you would get the same results based on the time the program used for calculation. that being said, when Diablo 1s RNG clock hit 9999 or maximum value (I don't know if it ever will or when if it would happen) then every time you start up a new diablo 1 game the map will permanently be the same every time and no longer have (simulated) RNG created maps (It will actually, but because the value can no longer change the RNG will result in the same seeds) and no long have fresh play throughs.
There were plenty of isometric adventure games on old consoles/computers. Were any of them (pre-Diablo) procedurally generated?
![scree08[1].jpg](https://i.imgur.com/Sdqvudi.jpg "scree08[1].jpg")
>>3051276
lol
could be...
>>3051265
>I think hes referring to when the internal clock that the Diablo 1 RNG calculation is based on gets capped out as time progresses
unix timestamp ends in 2038. Its long form is not gonna end any soon. So at best that means they're not using a standard mechanism to obtain time, if they use one at all.
>All RNG in every game is based an scripts that use a random time reference as a way to base what the randomly generated number will be
wrong, very wrong. There are many ways to obtain a seed. Reading out uninitialized memory, timing (ticks, nanos) the time between bootup and the player pressing start, noise from an analog device (soundcard, etc) and so on. There's no need to use a realtime clock, and it's not available on many platforms anyway.
>when Diablo 1s RNG clock hit 9999 or maximum value
The seed is re-obtained every time the game starts. These things are usually not capped, but instead overflow
So, yeah, the whole claim sounds highly questionable to me, and I need some actual proof.
>>3051593
Again, there's a PS1 version of this game and PS1 doesn't have a system clock. That proves it's not relying on real time.
>>3044241
this is true this supposed 16 bit port wouldnt couldnt be that large..
>>3049817
What he posted is basically the Amiga and Atari ST versions. Gauntlet wasn't a very fancy looking game, even at the arcades.
http://hol.abime.net/2704/conversionshot
Of course, 16 bit machines could do much better (pic).
More random Gauntlet type stuff was posted in this thread:
>>3040710
>>3049372
Wasn't that on a PSP? Not 16-bit.
>>3052514
It's GBA so 32 bit.
>>3049817
>>3049561
I found this gem: Daikatana for GBC!
>https://www.youtube.com/watch?v=jNoBFFgza00
>>3051967
The existence of the PS version says nothing about the implementation of the PC version
Plenty of y'all have pointed out that PC Diablo's memory requirements would make a mincemeat out of, say, the SNES 128kB memory. There are two ways around this:
1) Memory map a fat SRAM to the cart ala NES mappers.
2) Simplify the game to run on stock hardware.
Let's pretend the first one is out, even though it is easily doable with today's hardware. So in what ways can the game be simplified to reduce the memory footprint?
It is obvious that level data and fog data comprise the largest data set in the game. Actually all levels in the game can be reduced to a single number, the seed number, if you are willing to rebuild the map everytime you go to that floor. Since the map is static there is no need to save it besides circumventing wait times, which would be nontrivial on the SNES. Fog is harder because you interact with it. Either fog would have to be have a courser granularity, or the player could just have a set light radius. If the former, automapping wouldn't have to be axed. If the latter, you'd have to kiss the map goodbye.
So far so good: we've managed to reduce the level data down to 16 numbers.
That leaves enemies and items (equipment, chests, and interactive scenery). To reduce the memory footprint, if you saved the bare minimum of data, each enemy would only need an X and Y coordinate, and maybe a few flags (does it know where I am?). Dead enemies could be removed rather than saved to free up memory. You could skip saving things like HP and just set the creatures HP to max every time the level is loaded up. Items would require a few more bytes to describe them, but if the random item creation variety was scaled back just a bit (ie modifiers have set values rather than ranges), only a few bytes (maybe 4ish) would be needed per item.
Graphically the game would fit. The backgrounds are simple enough, and there are only at most 3 enemy types per floor.
I think a port is within the realm of possibility.
That being said, nethack would never fit.
>>3052546
Actually a great gb rpg if not the best. Try it anon! If he had only released this i bet it would have been different
![221522-the-elder-scrolls-travels-shadowkey-n-gage-screenshot-weapon[1].jpg](https://i.imgur.com/dzGdPud.jpg "221522-the-elder-scrolls-travels-shadowkey-n-gage-screenshot-weapon[1].jpg")
>>3049668
They made one on the fucking N-Gage.
>>3053450
Imagine that, a full Oblivion demake to look like Daggerfall
![7[1].jpg](https://i.imgur.com/iA4uMxw.jpg "7[1].jpg")
