No. Procedural generation wasn't out of the ordinary in the 8-bit era and neither was dungeons of mass skeletons to slaughter with 4 players in realtime.

Diablo's definitely feasible in whatever hypothetical 8-bit you're thinking of. I'm assuming you're going for AT 286s in mind.

*Smacking my head*

Completely forgot about Gauntlet.

Yes, I was thinking of a 10 or 12mhz 286 with 512k to 1mb RAM as the target platform, maybe with 256 color VGA but it might be better to stick with 16 color 320x200.

And the isometric perspective shouldn't work against it either. Not sure about the memory required to have monster sprites and UI panels that pop in along with smooth scrolling however. You'd also have to do some clever shift trick to do shadows, or excise those completely

You reckon Blizzard would sue your ass off for making something like this?
Or would it be enough for the name to be different and change some
elements of the story?

snorg wrote:

You reckon Blizzard would sue your ass off for making something like this?
Or would it be enough for the name to be different and change some
elements of the story?

Consider Torchlight. You can make a Diablo-type game without stealing Diablo's assets, story, items, etc. :B

But yeah, as Lei said, making a Diablo-type game in the 8-bit era was definitely not impossible by any stretch. The only major consideration was memory limitations. With a pre-made world, you can load the pieces of the world you need from disk as you need them, but with a procedural world, you have to keep a lot more of it in RAM, meaning you couldn't make your procedural data too complicated. Once DOS hit the scene this wasn't as big a deal, but for most 8-bit computers and consoles, this was a big deal as they had far less RAM to work with.

One of the closest early 8-bit games I can think of to being like Diablo would be Dragon Crystal, which came out on the Master System and Game Gear, as it has procedural dungeons, procedural equipment, and decent graphics. It's not real-time though. Another good example in terms of real-time dungeon crawling with procedural dungeons would be Gateway to Apshai.

Blizzard were originally planning on doing a Gameboy port of Diablo, but they didn't get too far with it. https://www.youtube.com/watch?v=QSPwIFLv_ak

snorg wrote:

I'm just not sure how you'd have the monsters wandering around in real-time

You may do anything, it just will be slower. And RAM is not a problem as you may get dada from disk/cartridge/cassette. To make it playable you'd need to simplify things - less active objects, smaller levels, less backgrounds, etc. Hardware sprites make it easier. There were action isometric 3D games on 8 bit.

Tertz wrote:

And RAM is not a problem as you may get dada from disk/cartridge/cassette.

You can't store procedurally generated stuff on-the-fly to disks or cassettes with any meaningful speed though, and it's impossible with ROM carts, so again, procedural generation is greatly limited by the complexity of what you're doing and how much stuff you need to generate, which made it a prohibitively memory expensive process for most 8-bit systems for all but the most simple of procedural content.

Make it 100% assembly. You could probably make a game like that run in an 8088 too.

Gemini000 wrote:

You can't store procedurally generated stuff on-the-fly to disks or cassettes

Yes, we can. And to keep such data on disk can be even comfortable, if the size is not big and r/w happens not often.
It's not obligate for Diablo case, as downloadable may to be only monsters, backgrounds etc for new levels or their parts. The algorithm and placement matrix itself need not much RAM, levels may be done smaller and simpler anyway. It was not typical for 8-bit games to have save function, but it's also possibly to save complete generated levels structure or initial data for maze generation and then return on same levels.

it's impossible with ROM carts

Cartridge is interface wich may contain many things, including rewritable EEPROM, RAM, sound card, HDD adaptor, etc. The limitations of cartridge interface of concrete PC is a separate question. Also cartridge may be used with a disk simultaneously: static data as graphical stuff on it and variable data on a disk.

Yes, this sounds like any number of 1980s isometric games. The big problem with those was that everything slowed down painfully if you had more than 2 or 3 moving objects on the screen.

If I remember correctly, Elite saved memory by using a procedurally generated world with a prebaked seed value, instead of storing its world data conventionally. I wonder if anyone's ever used a memory editor to input their own seed

Tertz wrote:

Gemini000 wrote:

You can't store procedurally generated stuff on-the-fly to disks or cassettes

Yes, we can. And to keep such data on disk can be even comfortable, if the size is not big and r/w happens not often.

By "on-the-fly" I specifically meant in a state of active reading and writing, like you get with RAM. :P

Tertz wrote:

Gemini000 wrote:

it's impossible with ROM carts

Cartridge is interface wich may contain many things, including rewritable EEPROM, RAM, sound card, HDD adaptor, etc. The limitations of cartridge interface of concrete PC is a separate question. Also cartridge may be used with a disk simultaneously: static data as graphical stuff on it and variable data on a disk.

OK, I could've explained this one better because I meant you can't store it straight into the ROM data, since ROM is read-only.

Diablo is basically a realtime Rogue-like, right? If so, how much more complicated would it be to take Rogue's gameplay and put it in realtime on an 8-bit system?

Rogue was already available for 8-bit systems back in the day.
https://en.wikipedia.org/wiki/Rogue_%28video_game%29

Jorpho wrote:

Rogue was already available for 8-bit systems back in the day.
https://en.wikipedia.org/wiki/Rogue_%28video_game%29

I meant in real time. 😉 I already knew it was available on 8 bit systems.