Deranged Wizard's Castle, or DWC, is an ASCII adventure game I made originally in Microsoft QBasic around 1993-1995. It started off as a modified version of Castle Adventure by Kevin Bales—using a hex editor, I altered the rooms in the castle beyond recognition. Eventually I developed a game engine from scratch in QBasic so I would be able to customize more than just the castle walls. Besides incremental changes—additional monsters, weapons, power-ups, and treasures—I gave the player a new set of actions to work with via the command parser. To make the game feel just a touch less anachronistic, I made the game full-colour (OK, sixteen colours, but that's vastly better than Castle Adventure's monochrome palette) and a "dashboard" showing the player's strength, the number of dollars to their name, and the number of bombs in their possession.

Before DWC, I made up a series of title screens and proof-of-concept "scenes" for a mixed text adventure/low-res graphical game I called "Dragon Warriors", no doubt influenced subconsciously by the NES game of the same name (I didn't have a Nintendo growing up but my friends did, plus I occasionally read Nintendo Power magazine). Eventually I realized the name was too generic, so I changed it to Dragon Warrior's Castle, and later Deranged Wizard's Castle. The eventual title was downright goofy and may have repelled more potential players than it attracted (along with the Regan-era graphics and gratuitously-tedious gameplay), but at least it achieved its objective of uniqueness.

Once the game had a reasonably complete quest—a loose story line, progressive difficulty, and a boss near the end—I began inviting my friends and acquaintances to playtest it. Early feedback suggested that the processor speed on my tester's computers, which was by and large higher than on mine—made combat particularly imbalanced. To this day, timing remains one of the most persistent challenges of making DWC work as intended across machines, emulators, and browsers.

Today I have to admit I'm a bit embarrassed by the sheer randomness of DWC. Much of the castle has micro-mazes made up of scattered bits of walls and assorted ASCII characters that are never identified as anything specific. To be fair, DWC emerged from a not-yet grown-up mind with lots of half-focused energy to burn and half-formed notions of how the universe should be. For better or worse I believed then that many more things were possible, though whether those things should happen was perhaps another story. Hopefully players will turn their attention toward whatever positive qualities I may have instilled in the game through the numbers game of persistence.

The current version of DWC has been ported to JavaScript and is mostly complete. I have chosen to preserve the lower-than-low-poly look, rendering the playing field and text with a font that mimics the text mode of early IBM PCs. I realize one could simply open the QBasic version in an emulator such as DosBox, but my main motivation for converting the game by hand was for coding practice.

An area of enhancement is the behaviour of enemies. Assuming the speed of the game is properly calibrated, I realized it was too easy for most players (especially in the 21st century) to defeat the monsters, given that they always retreated from and re-approached the player in a straight line and only changed angle when adjacent to the player. Also, an enemy could easily get stuck behind a wall, not having any logic with which to circumvent obstacles between itself and the player. Now I'm confident the player will be kept on their toes when encountering all forms of adversaries in the castle.

After finishing this port, I hope to make a proper game from scratch that uses similar text mode simulation while having a less "noisy" game path. When I created DWC, top-down design was not in my wheelhouse as it is now, and technological barricades existed that would be laughable today: 640 kilobytes of RAM, a 40 megabyte hard drive, and having to wait 30 or more seconds after hitting "Run" in the QBasic interpreter before the program would resume execution. Today it is possible to do several orders of magnitude more while wasting quite a lot less time. I would not be surprised if deciding the particulars of the new game winds up being the most time-consuming part of the whole process.