nesdev.com
https://forums.nesdev.com/

Procedural level generation on the NES?
https://forums.nesdev.com/viewtopic.php?f=2&t=16716
Page 1 of 2

Author:  FrankenGraphics [ Fri Nov 17, 2017 8:37 am ]
Post subject:  Re: Procedural level generation on the NES?

Ok, so here's an attempt compiling what FeRAM might be good for on a technical level:

-Speed: Close to conventional RAM speeds; overwrites in a single cycle*. Suitable for frequent and quick access.
-Durability/data retention: While there's an upper limit (typically 10^12 times per byte ), it goes many times beyond FlashROM and EEPROM.
-Interface: Comes as parallel, though serial seems to be cheaper in general. The parallel ones typically have a SRAM like interface built in.
-Price range: 1-5 dollars for reasonable sizes in the 64kB-512kB range
-Suitable as RAM? For most applications; it seems so yes.
-Suitable as ROM? yes No, if accessed frequently, as reads will cause wear just like rewrites.**
-Volatile? no.
-Battery requirement? no
-Unpowered data retention: typically estimated to last over 200 years below +35C, 95 years at +55C, or 10 years at a temperature of +85C.
-Power consumption: low; needs no "charge pump", and no constant current.
-technology: CMOS (warning: typically max 3.6v)
-availability: a few major companies like fujitsu and texas instruments manufacture FeRAM/FRAM; aswell as some relatively smaller companies.

Anything missing?

On a game/application design level:
-Good for any sort of world/data that is more or less manipulable, for example a level made of blocks the player can move, destroy and/or create
-Simulation-like parameters like "population happiness in this city block", "temperature", "minerals left" etc.
-Persistent enemy, npc, treasure statuses etc.
-Modifiable locations of ID:d items/objects
-Fog of war/field of exploration/field of view and other manipulable masks/maps
-any sort of complex save file
-generated, retrackable worlds/levels

*FeRAM doesn't need an erase cycle; nor separate read/write cycles. It operates by a rewrite cycle solely. This allows for very fast rates, especially with a Parallel interface. An SPI type FeRAM is a double bottle-neck, so avoid it.

**See tepples' subsequent post for details

Author:  tepples [ Fri Nov 17, 2017 8:55 am ]
Post subject:  Re: Procedural level generation on the NES?

FrankenGraphics wrote:
lidnariq wrote:
For FeRAM all reads are also writes, and each cell has a finite (but huge, usually) number of total writes.

Ok, so here's an attempt compiling what FeRAM might be good for on a technical level:

[...]
-Durability/data retention: While there's an upper limit (typically 10^12 times per byte ), it goes many times beyond FlashROM and EEPROM.
[...]
-Suitable as ROM? yes

Because reads count as writes, I don't see how something with a limit of a trillion reads is "Suitable as ROM".

Assume for a moment that a game spends an average of 973,000 cycles per second in a wait for vblank or wait for sprite 0 loop, and the loop is 7 cycles long. This means each byte of this loop is accessed 139,000 times every second. With a limit of a trillion access per byte, that's 7.2 million seconds or 2000 hours of power on time until the FeRAM cells holding this loop are no longer warranted. It's even worse for an all-in-NMI design like that of Super Mario Bros., whose loop is only 3 bytes long.

Emulators would have to warn for too many reads from the same ROM location in one second, and games would have to copy tight loops into the 2K RAM or unroll them.

Author:  FrankenGraphics [ Fri Nov 17, 2017 8:59 am ]
Post subject:  Re: Procedural level generation on the NES?

Thanks, i'll revise the post. The waiting spinlock could be copied to and ran from internal/separate RAM, though? EDIT: I somehow missed you wrote that more or less in your last sentence.

Author:  Alp [ Fri Nov 17, 2017 9:31 am ]
Post subject:  Re: Procedural level generation on the NES?

tepples wrote:
Procedural level generation tends to need more RAM than hardcoded levels, and RAM is one thing that the NES doesn't have much of. The exception is one-way scrolling like that of Super Mario Bros., where the procedural level generator could conceivably replace the level decompression code. But even in that case, balancing procedural levels to ensure even difficulty progression was not trivial.

One pre-NES example: River Raid for Atari 2600 is procedural with a fixed seed as a compression technique.

Not necessarily, clever data formatting is always king.

Last year, I had prototyped a randomly generated Zelda 1 clone on the NES, and the dungeons only used 64 bytes of RAM, generated from a seed. The Overworlds were a slightly different case, using about double that, to accommodate the extra level of detail.

The project was shelved, simply because I ran out of design ideas for monsters! :P

Coincidentally, my Super Mario Bros. clone "Cotton & Candy" actually features procedural level generation as an easter egg. If you walk through the top of a fake wall in level 1-2, you'll unlock a secret stage on the Overworld named "Minus World" :wink:

My levels have full left/right scrolling though, none of that one-way scrolling crap.

Author:  thefox [ Fri Nov 17, 2017 12:04 pm ]
Post subject:  Re: Procedural level generation on the NES?

This isn't exactly the kind of procedural generation that you're looking for (because it doesn't affect gameplay), but some time I happened to notice that Noah's Ark (E) uses randomization to generate some of its levels' visual content:
Attachment:
noahs-ark-ground.gif
noahs-ark-ground.gif [ 11.34 KiB | Viewed 1826 times ]
In the GIF is the nametable at the start of the level on two separate occasions. (I seem to recall this also affecting grass, but I couldn't reproduce that easily right now.)

SMB3 does something similar when generating the background layer, although that also doesn't affect gameplay in any way.

Author:  psycopathicteen [ Fri Nov 17, 2017 1:28 pm ]
Post subject:  Re: Procedural level generation on the NES?

SMB3 doesn't randomize scenery does it? The levels always looked the same to me every time I've played. It must keep the seed value the same every time it enters a level.

Author:  thefox [ Fri Nov 17, 2017 2:01 pm ]
Post subject:  Re: Procedural level generation on the NES?

psycopathicteen wrote:
SMB3 doesn't randomize scenery does it? The levels always looked the same to me every time I've played. It must keep the seed value the same every time it enters a level.

Attachment:
smb3-random-stamps.png
smb3-random-stamps.png [ 10.15 KiB | Viewed 1231 times ]
Those "stamps" at the top of the screen (flower, star, etc.) are randomized. The seed is not constant.

Author:  slobu [ Fri Nov 17, 2017 2:19 pm ]
Post subject:  Re: Procedural level generation on the NES?

There was a famicom game that ripped off the original Intellivision Dungeons & Dragons game VERY hard. Unfortunately, I forget the name.

Basically, it had a top-down view and dungeon sections were revealed as you traversed them.

RAM really isn't the issue with procedural content. You just need the right PRNG and the wherewithal to tailor your game around the results.

Author:  Sumez [ Fri Nov 17, 2017 3:48 pm ]
Post subject:  Re: Procedural level generation on the NES?

RAM can definitely help out a lot, but I'd agree it's not necessary.

Also, just to be clear. Procedurally generated content doesn't necessarily mean it's "random" - although it might as well be.

Author:  rainwarrior [ Fri Nov 17, 2017 6:38 pm ]
Post subject:  Re: Procedural level generation on the NES?

I always assumed that Balloon Fight's "Balloon Trip" mode was procedurally generated.

Author:  za909 [ Sat Nov 18, 2017 4:43 am ]
Post subject:  Re: Procedural level generation on the NES?

If I end up having enough space at the end of development, I do plan on adding a randomized "Endless mode" (รก la Megaman 9 and 10) to my game, and it pretty much requires no RAM at all. But that's because the entire thing runs on a timer that spawns sets of enemies from data in ROM, all I have to do is make the spawns be dependent on RNG output, or maybe define sets of spawns and let the RNG choose one of those sets.

Author:  FrankenGraphics [ Sat Nov 18, 2017 4:59 am ]
Post subject:  Re: Procedural level generation on the NES?

sumez wrote:
RAM can definitely help out a lot, but I'd agree it's not necessary.


It seems the sum is something like this: Work RAM makes the design and programming a lot more convenient/easier as a wider band of approaches become available, but there are applications and techniques within the rather broad term "procedural generation" where the 2kB:s of internal, volatile RAM is (more than) enough.

The question of volatile and non-volatile RAM is something i've pondered about just recently. In the commercial"making of" video for Solstice which rainwarrior linked to in another recent thread, they boast of a game experience "totally unique to the Nintendo Entertainment System", seemingly on the basis of it offering a world where "[...] the player can do whatever he likes, he can manipulate things within the game [...]". This is true in the sense that there's no correct path and you can go wherever you want, perhaps even more so than in for example metroid. But in terms of world manipulation, the game is actually strictly choreobraphed, with the potion system layered on top. This is pretty common for NES (and other console-) games, which i'd attribute to the expense of battery backed work RAM, or just work RAM in the case of a game design like Solstice.

Not that solstice has anything to do with procedural generation, but i think the parallel is valid when hypothesizing how a procedurally generated dungeon explorer/adventure game would work - how to keep track of chests, loot, opened doors, links between levels and anything else in that fashion.

Author:  Sumez [ Sat Nov 18, 2017 11:09 am ]
Post subject:  Re: Procedural level generation on the NES?

A true persistent "open world" game could probably demand a lot of ram depending on how you prioritize elements in the design, and leaving stuff explored, enemies killed, chest open etc, is bound to require a least some amount of it, even with clever bitmasks.
But that's a pretty limited application of procedural design compared to what it can be used for. :) Balloon Trip is a great example of a game with simple procedural design and absolutely no amount of persistency.

Author:  Vectrex2809 [ Tue Nov 21, 2017 5:26 pm ]
Post subject:  Re: Procedural level generation on the NES?

I actually did some simple procedural generation on the NES. In Brony Blaster, I randomly generate a path between the rooms, then I randomly choose from 16 sets of 16 rooms depending on how many doors the room has. It's rather simple but it works. - https://www.youtube.com/watch?v=Uyp31O3xSRY (This is an older version where the game would select from 256 rooms at random)

I also randomly generated the shelves on the bonus stages in REKT. The prices and the items on the shelves are randomised. It's just a cosmetic/comedic effect though. Level 4 in that game also randomly chooses rooms, although on a much simpler scale than Brony Blaster - https://www.youtube.com/watch?v=O9upGnDxbbM

Page 1 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/