• Skip to main content
  • Skip to header right navigation
  • Skip to site footer
Retro Game Coders

Retro Game Coders

Retro computer/console game + dev community

  • About
    • Retro Computer Collection
    • Contact
  • Blog
  • Retro Resources
    • Retro Gaming Timeline
    • Online Retro IDE
    • Retro Pixel Art Editor
    • Dungeon Loom Map Editor
    • 6502 Programmer’s Reference
    • Emulators
      • Acorn Electron
      • Amstrad CPC Emulator
      • Online BBC Micro Emulator
      • Commodore PET Emulator
      • Browser C64 Emulator
      • DOSBox/DOS PC emulator
      • Tandy CoCo/Dragon
    • Best Retro YouTube Channels
    • New Retro Books
    • Raspberry Pi Amiga Emulation
    • MiSTer FPGA Tutorial
    • BMC64 C64 Pi
  • Community

Home » Retro Game Coders Blog » Retro Gaming News and Reviews

Dungeon Game with Random Mazes Now Working on Commodore PET

Dungeon Game on Commodore PET

The first reboot Dungeon game test, working on Commodore PET (with others coming), all using random maps

​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 …

Category: Retro Gaming News and ReviewsTag: commodore pet, Retro C/C++ Programming
Previous Post:Retro Dungeon GameCross-Platform Game Programming in C: Mazes and Limitations of cc65
Next Post:Retro Dungeon in C: Putting my CC65 code on a dietRetro Dungeon in C

Retro Game Coders

Retro computer/console game + dev programming community by Chris Garrett

  • Bluesky
  • Threads
  • Facebook
  • Instagram
  • YouTube
  • Mastodon

Maker Hacks ・ D6Combat・chrisg.com

© Copyright 2026 Chris Garrett

Privacy ﹒ Terms of Service

Return to top