Crafting levels for games has its own workload, over and above that of creating the game itself, plus your ability in this area can be the difference between the game sucking and being fun to play.
While there are a lot of games where you win by memorizing maps and enemy movement, I have never really been fond of those kinds of games. It feels more like studying than play to me.
I think that is where the trend of Rogue-like games using random room generation and procedural generation to create levels came from.
Another benefit, mainly for the developer, is we get to play our own games.
With that in mind, I looked at maze algorithms. You might have seen my Python example.
First step was to recreate it in C (you can view a browser example compiled with emscripten right here on my Itch page).
Next, I rebuilt the Dungeon game to use this algorithm. First using modern C, and then recoding until it worked on older systems.
There are a few differences between modern C and old-school C that might not be immediately obvious due to using modern cross-compilers.
First, just because something compiles, doesn't mean it will work. Things that spring to mind are lack of actual clocks in some computers (although that can be a GOOD thing - old batteries leak!), lack of addressable screen memory (lots of computers used character-based serial terminals), and lack of memory in general.
We also have to keep in mind that we are a bit spoiled by even modern terminal tools. Back in the day it wasn't even a given that you would have 40 columns of text to work with.
So my code is not what you might call elegant, but it not only compiles, it is playable.
The result is the first reboot Dungeon game test, working on Commodore PET (with others coming), all using random maps.
I chose the PET because it is a purely text based machine (well, PETSCII), has a known architecture (versus CP/M that could be pretty much anything) and has 32KB of memory to play with.
Still, my fear was the 1 or 2mhz 6502 would grind to a halt with this algorithm - it is not the fastest algo out there, it is just the best suited to my needs - but it is not bad at all even on the humble PET.
Download the .prg to play on your actual or emulated Commodore PET (I recommend Vice emulator) or click over to my browser based emulator to try it out!
Let me know what you think ...
I remember the PET. I saw some at the computer club I went to in the early 80s along with various other machines. They were mostly incompatible with each other.
We take lots of memory and a fast CPU for granted these days, but you had to code efficiently in those days. I saw someone give a talk on programming the Atari VCS that was really under-powered. You had to be really clever to get a playable game running.
I did mostly BASIC on my Beeb, but tried some assembler.
Yeah the 2600 is a real pain, you have to "race the beam" (as in the CRT drawing the screen) which means to get anything done your code has to be super, super efficient. And yet they produced a BASIC cart for it!
Thanks for your contribution to the STEMsocial community. Feel free to join us on discord to get to know the rest of us!
Please consider delegating to the @stemsocial account (85% of the curation rewards are returned).
You may also include @stemsocial as a beneficiary of the rewards of this post to get a stronger support.