With procedural generation you can save a lot of space for content but did you know that Pitfall! on the Atari 2600 uses one byte (!) to describe a room? Here's the link to an article describing how that works:
https://evoniuk.github.io/posts/pitfall.html
#gamedev #procgen #retro
How Pitfall Builds its World

Thanks to your boosts, my follower count on Mastodon can *not* be represented by a singly byte anymore! 😊

@PixelProphecy Very true.

David Crane is one of my top #5 #gamedev heroes *ever*.

@mode13h His only game I don't like was "Bart Simpson's Escape from Camp Deadly". It was my very first time that I was disappointed by a GameBoy game when I was a kid πŸ˜…

@PixelProphecy Enjoyed this sidenote in the article:

> Reddit user knome and Hacker News user nwellnhof pointed out the size of this sentence in ASCII and UTF 8 were actually the same, so I changed an ASCII apostrophe for U+2019.

Technically correct, the best kind of correct!

@PixelProphecy I loved that game growing up…

@PixelProphecy

This is an amazing story, Thanks!

@PixelProphecy

I don’t know how true it is but supposedly the maze generation algorithm for Entombed (another 2600 game) is a mystery, or at least the lookup table for wall placement rules is.

@lorddimwit There are still so many secrets in these old games, I hope that they all are unearthed one day 😊
@PixelProphecy I can't even with the explanation of what a "room" is in the manual. Amazing (in a "fascinating", not a bad, way)

> This was the late 70s; there had never been a game with multiple screens before. This was in the days of Space Invaders and Pac Man, when everything in a game was in front of the player at all times, so the fact that Adventure was able to have 30 rooms when it was finally released in 1980 was quite impressive.
> The manual for adventure even had to explain the concept. It read
> "Each area shown on your television screen will have one or more barriers or walls, through which you CANNOT pass. There are one or more openings. To move from one area to an adjacent area, move "off" the television screen through one of the openings, the adjacent area will be shown on your television screen."
@jec Yeah, so many things we not take for granted were pioneered in these days, thanks for sharing!
@PixelProphecy the notion that the original code may have had useful comments is … charming.
@PixelProphecy
I think the same thing was done later in Diablo.
@fneddy We'd have to ask David Brevik how the procgen on the levels worked in detail, sadly he's not on Mastodon (yet?)

@PixelProphecy
He did a talk on it here: https://m.youtube.com/watch?v=VscdPA6sUkc&t=71m42s

And there was a very in deep analysis here: https://www.boristhebrave.com/2019/07/14/dungeon-generation-in-diablo-1/

But i think it's not really the same.

As i understand the Diablo algorithm "might"' have used a PRNG to generate the next room but it would still result in a complete new room every time because there is much more variables that enter the algorithm. Like position where the player entered the room and so on..

'Diablo': A Classic Game Postmortem

YouTube
@PixelProphecy Really cool but there has to be a pitfall!
@PixelProphecy
It's such an efficient way to create levels. I use a similar system in my Atari 7800 shooter to create the enemy formations. It takes one byte of data to create them.
@fultonbot When space is precious, you oughta get crafty with what you have, very cool!
@PixelProphecy
It's fun to try to create solutions with limited resources.
@fultonbot Players don't know that the dev was having just as much fun as them, solving all the interconnected logic puzzles of "how to make this game possible"
@PixelProphecy @misty Id be willing to bet you’ve seen this but in case you haven’t it seems like something you’d find Interesting
@PixelProphecy
I almost understood half of that ;-)
@raymierussell Enough to appreciate the engineering genius that went into the game, I hope πŸ˜…
@PixelProphecy
Absolutely. Makes me feel like a lazy programmer.
Each level of my #ZXSpectrum puzzle game is 12 x 10 blocks. Each block is represented by 1 byte so each level is 120 bytes (+1 timer byte). There are 50 levels so 121 x 50 = 6050. On a 48k machine that is not a problem.
@raymierussell So much space to work with ... compared to the 2600 πŸ˜‰ I'm certain you had lots of your very own intricate coding issues to solve on that one, developing for old platforms is anything but lazy. Cause here I am, copy/pasting regularly from StackOverflow πŸ˜…
@PixelProphecy
Lol, yes old systems can be eccentric. The Speccy has many eccentricities. The screen layout always gives grief to the noob. The thing that is a mind melter is the way the interrupts were implemented. The hardware was built on the cheap and the (user serviceable) interrupts were not implemented to proper Z80 specs so you have to bend over backwards & use 257 bytes of space to get them to work. A software 'hack' on the 48k machine can save the 257 bytes but crashes 128k machines

@PixelProphecy

That's awesome, thank you for sharing! It reminds me that somewhere on the stack is the desire to learn how procedural generation works.

@PixelProphecy This is incredible :) I love LFSRs, they sound completely impossible and yet manage to produce perfect cycles of random-seeming numbers - I tried to explain them myself in the context of Transport Tycoon here. Using two formulae that were the inverse of each other is just on a whole other level! https://youtu.be/bHRhPj0CRXI
OpenTTD - The Tile Update Cycle (Linear Feedback Shift Registers)

YouTube
@DavidXNewton Yeah, must feel like unearthing a shining diamond, like a one-of-its-kind thing. It's just so elegant!
@PixelProphecy ohh Pitfall! I used to play this all the time! I can still hear the sound that played when the little guy vaulted over the puddle. πŸ˜†
@PixelProphecy actually used this method for a text based adventure game on the VIC-20 - inventory management in under 3583 bytes was a big challenge.
@PixelProphecy @marcoarment Ages ago I saw a nice trick in the BASIC interpreter machine code: They implemented 2 BASIC commands with 3 bytes of code!
BASIC commands TRON (Trace on) and TROFF (Trace off).
Byte 1: Entry point TRON, set register a to following byte
Byte 2: Entry point TROFF, Reset Register A.
Byte 3: return
These days you could actually look at all, that was happening...
@PixelProphecy That is a fascinating read. It’s incredible how ingenious software developers were/can be when constraints like these are imposed!
@chrisd Absolutely! I bet there are so many more elegant gems to be found, especially in the early days of gaming
@PixelProphecy @marcoarment this is absolutely insane, great article!
@fabioromeu @marcoarment Glad I shared it, apparently hundreds of Mastodonians find it as fascinating as I do 😊
@PixelProphecy Didn't know the 2600 was so insanely low on RAM. Amazing.
@SonnyBonds Agreed! I find it stunning what creative tricks coders back then had to come up with on such limited hardware; I bet that's only the tip of the iceberg. A lost art, really.