‘@Play‘ is a frequently-appearing column which discusses the history, present, and future of the roguelike dungeon exploring genre.
I’ve been thinking about classic roguelikes, by which I mean old games from the 80s and 90s. What usually calls themselves roguelikes these days is a debased currency. Some of these games are very good (Spelunky! Balatro!), but they aren’t things that would have been recognized as roguelikes in the age of the coinage of that term, which was probably the naming of the Usenet group rec.games.roguelike. This has resulted in such things as Punished Backlogs’s “Objectively Correct” Ratings of the best roguelikes having, as a requirement, being “stage-based” and to have “great music.” Whether it’s nice to have or not, a true jedi craves not these things.
Every so often I start musing over what the “main” roguelikes, the ones that are most fitting to bear the banner of the genre, should be. When I was writing @Play for GameSetWatch, the games I settled on were Rogue (1980), Moria (1983), Hack (1982), Angband (1990) and NetHack (1987). Soon after I added Dungeon Crawl (1997), Larn (1986), Omega (1988), ADOM (1994) and Brogue (2009). Nowadays I’d add Alphaman (1995), the adventurer mode of Dwarf Fortress (2004) and Caves of Qud (2010). (If you want to see some more recent things I’ve written on roguelikes here, look into the @Play tag.)
There are some more games that deserve inclusion probably. There are some “lost roguelikes,” lost because they were written for ancient Unixes (Unices?) and were hard to preserve or their implementation relied on those old OSes. There have been attempts at preserving these games, like the Roguelike Restoration Project (GitHub), although its last update is from 2011. UltraRogue, infamously, saved games by doing a memory dump of the process space, and loading it back off of disk when time to resume the game. Some other games it lists are Advanced Rogue, XRogue and Super-Rogue.
While clunky, buggy and sometimes glitchy, there is still a strong appeal for these old games, from a time when roguelikes were a hyper-obscure niche mostly of interest to current and former computer science students. In the early days of the web, the worthy Boudewyn Waiyers maintained the first major Roguelike Home Page on the internet (Wayback Machine links: first archived version, last version there, final home).
and URW, or “UnReal World,” which has an interesting story behind it. Unlike the other games in this list, it’s still in active development, and while it’s much changed its focus it still seems to be a roguelike. I think this should be a forthcoming @Play subject
Not mentioned on the dusty archives of the Roguelike Home Page is Elona, a roguelike from Japan. I’ve bounced hard off of this in the past (its got some objectionable content), but hell, I’ve survived the likes of Omega Labyrinth Life. There’s also Castle of the Winds, an early Windows roguelike which is slated to be republished on Steam soon.
I must say, ArchiveRL on the Internet Archive is amazing, a 25-gigabyte collection of hundreds of roguelikes, many of them defunct and otherwise forgotten. If you’re looking for something ancient, esoteric and probably terminal-based, you’ll find lots of things in its murky depths.
I’ve played a fair bit of Caves of Qud recently and I have quite a few notes on it. I think my next subjects should be that, UnReal World and Elona. Are there any suggestions for directions to explore? I mean besides down, deeper into the earth, of course.
The title refers to an ongoing series with two videos so far. Part 1 (28 minutes) is about how the tokenizer works and how programs are stored in memory, and Part 2 (19 minutes) is on what the BASIC interpreter does to execute the program as it’s running. These are pretty detailed and a bit technical, but interesting of these kinds of shapes can fit into your brain. More below.
I’ll distill the basics of the videos for you. Commodore BASIC is a dialect of Microsoft BASIC. It puts the loaded program at the bottom of memory, starting at 2049, or $0801 in hex. (The custom on the C64 is to denote hex numbers with a dollar sign.) When lines are written, the C64’s screen editor start from the beginning looking for a line number, and if it’s found tries to tokenize the rest of the line. Unrecognized keywords are still stored as PETSCII characters (which will cause a syntax error when run).
Commands are matched against a list of keywords stored in ROM. All the keywords are stored as “tokens,” single bytes, to conserve program space and to help with execution speed. At runtime, the tokens are detected by their high bit being set, then run through a lookup table. It pushes the high and low bytes of the command’s address in memory then does an RTS, which then jumps to the routine by acting like it’s returning from a JSR. Notably, the short routine that gets the next byte of BASIC text to act upon, CHRGET, is actually copied into zero page RAM to run, to take advantage of faster zero page versions of some instructions, but also because it’s self-modifying.
I could link the things that everyone already knows about, that people in that wretched hive they call Reddit have already linked five times, that have blown up on social media, that there’s already a Youtuber or two making snide comments about. I mean, I’ve linked stuff like that before, pretty often really. They aren’t hard to find.
But I’d much rather link something interesting that’s basically unknown. Help spread the word about it! The only problem there is, how do you find that stuff in the first place? It’s a bit of a chicken-or-David-Egger. I think that’s what you’d call it, sure.
So when I saw someone I follow on Bluesky wrote out nearly every Nintendo video game property, including those that appeared on niche platforms like Virtual Boy and Satellaview, primarily so they could boldface the ones that have arrived on Nintendo Music, I had to run directly here to link to it.
The beginning of a long list
I don’t vouch for its total accuracy, but it still could be a useful resource. In fact I know there are some things that are missing, like their early arcade games Sheriff or Radar Scope, just for starters. But if the idea is to present things that realistically could present soundtracks included in Nintendo Music, it’s a pretty good list.
We linked to a Skawo video yesterday, the one about flash card rumble motors activating when playing Link’s Awakening DX. Well I happened to have this one open, so here’s another: the last gasps of a failing PPU chip, shown off in several games. (5½ minutes)
It starts out seeming to work okay, but it isn’t long before it becomes obvious that something very wrong is happening. If you ever wondered what a failing graphics chip looks like, well, this will show you one example of it happening. Chips can fail in any number of ways, and there’s no guarantee that another PPU in the process of expiring will expire in the same way, but this is the kind of thing that can happen.
The Game Boy doesn’t have a Rumble Pak. Of course it doesn’t; where would you slot it? But a few games were released for the Game Boy Color (and Game Boy Advance too) that have built-in rumble motors. Because of this, it’s impossible, with unmodified physical hardware, to separate the Rumble from the Pak. If the game supports rumble, it has the motor included; if it doesn’t support rumble, it won’t have the motor. Pretty simple.
Except. Some people discovered, if you put Link’s Awakening DX onto some flash carts with a rumble motor included, there is a point during the game where the rumble will activate. Skawo on Youtube looked at the game’s code and sought an answer as to why. (10 minutes)
The tl;dw: GBC rumble motors are controlled via a MBC5 chip, a chip not dissimilar to the now-famous MMC line of chips on the NES/Famicom. Writes to ROM space are caught by the chip and used to activate functions. The main purpose for these chips is to switch between memory banks, but one bit in the written byte activates or deactivates the motor. Link’s Awakening DX uses a MBC5 and a miscoded write that activates any included motor. The MBC5 usually ignores these writes because it checks the cartridge header to see if it includes rumble support, a check that fails for this game, but GBA flash carts run will use an emulator to run GBC games, and if the emulator is inaccurate it might trigger rumble motor regardless of any header.
So why is the value written anyway? I’ll leave that for the video to explain, but it has to do with the additional save information added for the Color Dungeon, and an issue in the game when it saves puzzle completion data for areas that aren’t in dungeons.
It’s been possible for quite a while to increase the framerate of SNES Star Fox. Even during the SNES’ hardware release period, an updated version of the SuperFX chip that made it’s then-amazing 3D visuals possible was used that doubled its performance, and was used in other games like Yoshi’s Island. And now overclocking and emulation can increase SuperFX performance by much more.
But there’s a problem with speeding up Star Fox this way. The game wasn’t designed that the frame rate can be separated from the gameplay or animations. If you speed up the chip, you’ll speed up everything else in the game too, rapidly making it unplayable.
Some progress has been made recently towards improving the framerate without making it a twitchy stuttery mess. Tyler Loch made a video of his efforts (3½ minutes), and to people used playing Star Fox’s at its original 15fps it’s a wonder to behold:
Because the code has to be adjusted in many different places, there are parts of the game that are obviously incorrect. Falling pillars, you’ll notice, tilt over much faster, bosses move and fire much more rapidly and are more dangerous as a result, and the engine of the player’s Arwing spaceship flashes at a rate that some people may not appreciate. And the video shows off only the first level, because the full game isn’t finishable yet. But much progress has been made! Let us hope Tyler’s momentum holds up through the rest of the project.
Sundry Sunday is our weekly feature of fun gaming culture finds and videos, from across the years and even decades.
Wario and Waluigi should need no introduction. (Wario shouldn’t anyway; Waluigi has not gotten most attention since the early 2000s.) After establishing them as the Nintendo-flavored version of “Bizarro,” we are informed by Michael McWhertor of Polygon that Camelot, the originator of Waluigi, had brainstormed up a wa-version of Peach too, which was rejected by Nintendo because they hate awesomeness.
Concept art of Wapeach, from Camelot originally, image from the Polygon article linked above.
It’s been two years since that article came out, and soon after fan material regarding this quasi-evil apparition began to appear. On DeviantArt (that place), user Niko–Neko has made to date 95 images of the princeless-waif, some just artwork, some comics, often involving her partners-in-wa, Wario and Waluigi. (Note: some images slightly NSFW, nothing explicit, but there’s at least one image where she’s wearing her cape and little else.)
I’ll leave you to explore Niko–Neko’s renditions of her hapless adventures on your own, as they’re not the actual point of this post, not directly at least. Instead, I invite you to partake in gawking at GabaLeth’s playlist of eight of those comics with voice-acting. (Total length about 4½ minutes)
I now leave you to dream about lovably incompetent dark princesses and the things they might do to you if they got you in their clutches. “Yow, it hurts so good! How may I serve you, oh Mistress of Darkness….”
Dwarf Fortress has always been a game about failure. It’s right there in its motto, “Losing is fun!” It’s a game where you just muddle through, doing what you can, learning as you go, and your games slowly, on the average, get longer and longer the more you play. It’s not that there aren’t guides and tutorials already out there, but the kind of game it is, it halfway feels like they rob something of the player. While I can understand not wanting to start from zero, the sooner the player learns that failure is the end mode of fortresses, the more they’ll understand that the intended way to play is to be audacious.
But which kinds of failure are the most fun? After spending several minutes setting up your expedition getting eaten by wild animals immediately off the wagon is a harsh start to play, especially if it happens repeatedly. Fortress destruction via dragon is scary, but it’s also hilarious; everyone dying on the surface before even digging your first warren is less auspicious.
Dwarf Fortess recently celebrated its 20th birthday, and in celebration Kitfox Games, its Steam publisher, has released a new official beginners video, made by BlindiRL. (34 minutes) It is a good way to move your fortress endings more towards the entertaining end of the scale.
And I’d like to point out, at the end of the video, we’re told that ending a fortress doesn’t quite mean it has to be a failure. If you decide to “finish” a fortress, but then start a new fortress in the same world and of the same faction, then it’s possible for your old dwarfs to decide to emigrate to it. This is something I’ve never tried myself, but it’s a good reason to keep playing in the same world, as you continue to write the saga of your game.
I’ve already introduced The Bard’s Tale in prior posts, so in brief: The original Bard’s Tale trilogy were all Wizardry-style dungeon exploration RPGs in the classic style, called by some “blobbers.” Indeed they did a lot to define that style. A few things that Wizardry did weren’t adopted by later blobbers, especially its particular form of permadeath, its simulation of “Out” parties and retrieving lost characters from the dungeon, and its willingness to obliterate your entire group instantly and permanently if you teleported into solid stone.
The Bard’s Tale, on the other hand, looks exactly what the standard picture of a classic blobber looks like today. So long as you have the cash to revive a character there is no real penalty for dying, there is no absolutely solid stone to teleport into, and there’s no concept of “Out” parties, for if your party wipes their corpses get mysteriously teleported back to the Adventurer’s Guild, where if there’s enough gold in their cold pockets you, I guess in the capacity of being a caring guardian spirit, can tell the priests to bring them back to life.
But while not as eager to annihilate members of your group, neither is The Bard’s Tale an easy game. Compensating for the lack of permadeath, dungeons tend to be much more diabolical in design, with magical darkness, teleporters, spinners and antimagic zones in evidence. Dungeon levels are bigger than Wizardry’s, there are more of them, and most significantly to a new player, “Town,” here named Skara Brae, isn’t a simple menu of options but an entire level of its own to explore! And at the start of the game, you don’t know where anything except the Adventurer’s Guild is! You have to do significant mapping before you can buy equipment, recharge your spell points, or even raise your experience level.
In this 7th installment of the video series, the player finds and begins to explore the third of the game’s dungeons, finds some interesting items, suffers from disk corruption and loses some progress, earns it back, and fights a jabberwock.
Pinball is tricky enough on its own, but then you “lock” multiple balls in some location, the game’s sound system starts to go nuts, and uh-oh, now all those balls are on the table at once!
Multiball is chaotic, and glorious for it, and it is not always possible to play one well. But you can learn to improve your chances at it, with practice and a decent strategy. For the latter, Tim Sexton explains how to go about it in an 18 minute video.
If multiball were easier, or less chaotic, it wouldn’t be as much fun! And even once you learn some decent tactics to lessen its complexity, like by learning to trap all but one ball on a single flipper and making shots with the remaining ball on the other one, it can still be fun sometimes to just try to make shots. Sometimes that works for me! But learning to play pinball consistently well means not taking on any unnecessary risk, and that’s certainly risky.
Tim’s video not only covers basic multiball tips, but it also examines some specific games, both new and old, and at the end presents examples of multiball play in progress. If you’re interested in improving at pinball, it’s worth a look!
Way back in 1984, having had success with their first product Softdisk, the nascent Softdisk Publishing released the first issue of Loadstar, a “magazine-on-disk” for Commodore 64 microcomputers.
Softdisk is mostly known these days as being the former workplace of several people who would go on to found Id Software, creators of Commander Keen, Wolfenstein 3D, Doom and Quake. Softdisk published, as the Id guys’ last work for the company, Catacomb 3D using the Wolf3D engine, and a Commander Keen episode.
Softdisk released other products too, but Loadstar eventually proved to be something special. Early on they assumed that their PC and Mac products would be their legacy, but then Microsoft and then the internet came along and it suddenly became much harder to make a go of it with a monthly paid software collection. Softdisk became an ISP; they got bought out by a bigger ISP; nowadays they don’t exist really, except as a bag of rights owned in pieces by Piko Interactive and/or Catacomb Games, who bought their Id-related assets.
The cover of Loadstar #72, the last issue sold on newsstands.
But some time before then Loadstar and its relevant assets had left the company. Defying expectations and buoyed by the large userbase of the Commodore 64 (quick googling suggests they sold 70 million units), Loadstar was still doing fairly well for itself. It was no longer sustaining the whole company like it once had, but it was too large an audience to ignore. So Softdisk spun Loadstar off to J&F Publishing, under the captaincy of its longest-serving Managing Editor Fender Tucker, and they kept the lights on a while longer.
When Fender retired from Loadstar at the dawning of the year 2000, he passed managing editorship over to Dave Moorman, who kept it going for 49 more issues. It was starting to become hard to find new things to keep Loadstar going at this point. While Dave had some regulars sending in new things, a large back catalog to mine for material, and skill enough to write some software for Loadstar himself, its release rate slowly dropped from monthly to, in 2007, two issues in that year. Then a tornado his his house and destroyed the tools he used to make Loadstar. One more issue made it out in the following year, that had been in production and finished by Ricky Derocher in 2008. And that is where Loadstar’s story ended.
Next, what I’ve been doing
A year or so ago, with the permission of Fender who still owns Loadstar and J&F Publishing, I threw together something called Loadstar Compleat. A prior product also called that had been sold by Fender for some time, a CD-ROM with the 199 issues from before and during his run, along with the 42 issues of another magazine, Loadstar 128, and various other products and odds and ends.
I took the issues from there, replaced some bad copies with better ones provided by Ricky Derocher, added in the 51 later issues from Dave Moorman’s editorship, and added a kind of shell program to make browsing and searching through them all easier. I packaged this all together and threw it up on itch.io as Loadstar Compleat for $15. Since then I’ve now also given three talks on Loadstar and its history, in person at VCFMW 2025, virtually for TPUG, and three days ago also in person at VCFSE 2026. (There should be video of that soon, I’ll link to it here when it enters my notice.)
Now, possibly, the future
Loading screen for early Loadstar issues
Dave has always said he wanted Loadstar to last to its 256th issue, to make it an even binary number (28, or 100000000). Even though Loadstar only had about 100 subscribers left by that point he was still committed to doing it, and only the fury of nature prevented him from making it.
I mentioned this at VCFSE, musing that perhaps I could finish the task he had started, making a final six issues of the venerable disk magazine, and a couple of people there thought that it might be a good idea. And I think I have enough knowledge now of Loadstar’s underpinnings that I might be able to accomplish this. With all the tools available for producing software for retro platforms now (I have an upcoming article on those in the works), it is arguably easier to make C64 software than it’s ever been, and now that there’s the Ultimate64 and Maxi65, the size of the C64 platform is growing once again.
So, let’s start making plans for how this could happen. In addition to doing whatever needs to be done to understand Loadstar’s file formats to get its Presenter system to fulfill our purposes, I figure we need:
Contributors, and contributions. Commodore 64 software, hi-res artwork (at least one image for each issue for the loading image), SID music (at least one piece per issue for the Presenter background music), articles and anything else we’d need to keep up Loadstar’s standards according to the systems they used in their late period, which used a polished Presenter menu program written in machine code, a text reader to display documentation and articles, and miscellaneous other niceties.
Means to compensate them. We aren’t sure if this can support itself financially yet. For right now, we need to keep our options open. If we get a lot of interest it’s not out of the question that this could mean a bit of actual money, but for now free issues are what we’re considering.
A means to produce physical disks. These issues would be sold digitally (as .d64 and .d81 disk images for emulators), but it feels like to be a real disk magazine, there must be actual Commodore-formatted 5 1/4″ and/or 3 1/2″ disks to sell too. You can still get 5 1/4″ disks. Amazon sells them ten for $25.
Middle-period loading screen. (Later issues used custom loading screens for each issue.)
We’re currently discussing ways to accomplish these things. I’ve started a thread at loadstarce.com to discuss this project. We are fortunate that many of the Loadstar editors are still around, including Fender Tucker, his associate editor Jeff Jones, and Dave Moorman, as well as people who care about Loadstar’s memory like Ricky Derocher.
There are two things we need right now. The first is indication of interest. Would you be interested in buying something like this? How about spreading the word about our little venture?
The other thing we need is “content”: software, writing, art and music, in formats appropriate for the Commodore 64. C64 art must be hi-res VIC-II format. Music can’t just be any old SID tune but in the format its Presenter used (more information on that as I determine it). Software doesn’t have to be machine code, for Loadstar published many BASIC programs, and multiple BASIC extensions too, including one, Dot.BASIC Plus, that still has a website and working downloads!
Are you any of you interested in, and capable of, providing these things? I don’t know how much we can pay you yet. For my part I will make the rounds online and approach people who might be interested in helping revive Loadstar, if just for a little while.
And who knows, if this proves popular enough, maybe we could go past issue 256? Shooting for 512 seems like a ludicrous dream, certainly not something I could do in my remaining lifetime, but who knows for sure? Let’s dare to dream.
If you want to be involved in the continuation of the frankly improbable legacy of Loadstar, you can reach me:
