A Look Back at Darkness

By | May 8, 2020

Early Inspiration

While first exploring the BBSes in my local scene in the mid 90s the “door games” that almost every BBS seemed to have were a big source of curiosity. Who had what games varied widely by what the host BBS software could support and, as always, the individual tastes of each SysOp. I quickly learned that most of the more interesting looking door games were unintuitive if not extremely esoteric. I remember bouncing hard off of strategy games like Trade Wars 2002 and Barren Realms Elite while also having strangely fond memories of my repeated attempts to survive the irradiated wastelands of Operation Overkill II. It wasn’t until I stumbled into Legend of the Red Dragon (LORD) by Robinson Technologies (RTSoft) that I finally found a door game that actually hooked me.

Legend of the Red Dragon Intro Screen

Drawn in by the relatively pleasing aesthetic and approachable action RPG gameplay, your first steps in LORD would be spent figuring out the extreme basics of the game and establishing a bit of a daily routine. Quickly thereafter you’d shift fully into your routine of gaining levels and trying to survive the competition while working to discover how some of the game’s more obscure systems functioned and chuckling at Seth Robinson’s quirky sense of humor along the way. On many BBSes game content would be further supplemented by the addition of IGMs, 3rd party addon “modules” which could hook into LORD’s data files. It’s some time after that point that the repetitious nature of the gameplay lead the fun to dry up for many. The game had the potential to be a very different experience, however. These days when discussing LORD I often observe a disconnect between people who missed out on playing in an active game full of rambunctious players versus those of us who have and got to appreciate LORD’s systems in a different light.

It’s my opinion that, as with many other multiplayer games, the best content was ultimately what the game’s systems enabled the players to create themselves. Owing to its earliest origins as more of a social platform than a game, LORD includes many such systems, designed to encourage players to interact in more ways than just trading positions on the leaderboard. Players could, for instance, chat on various walls and post announcements in the daily news, send private messages back and forth, fight for the affections of various NPCs and even each other, make arch enemies to avoid and/or hunt down, and establish secret alliances and cabals, pooling resources to dominate the competition. I recall at one point that my brother and I both had multiple accounts on one particular local BBS that had more or less been running on auto-pilot for years, the antics of the door game patrons going totally unpoliced. My brother, a grizzled veteran of pen and paper RPGs by this point, got really into the aspect of “role playing” numerous characters to use the relationships he’d build to strategically manipulate other players. There were friendships, romances, betrayals – all of the hallmarks of a great drama!

I became a bit of a LORD super-fan myself. I called Seth’s BBS, The Darkside, to register my own copy of the game and started collecting every IGM, utility, and other related file I could get my hands on (there were already a fairly vast amount of them by then.) I recall going through what has become a bit of a rite of passage for SysOps and BBS modders everywhere, trying to get every single IGM you could possibly make run added to the game to create a single uber-customized version of LORD. Of course, given the bugs and balance issues that even the best IGMs could introduce to the game, this also tended to be an uber-broken version of LORD. Taking that idea a step beyond, I once even setup a board called “The Fortress” that was 100% centered around LORD, totally custom themed to look like it, with multiple games of LORD running to cater to different tastes. Looking back, it was ridiculous to think anyone would be as into the idea as I was, but it was still a lot of fun to do.

The End of an Era

RTSoft released numerous updates to LORD in 1994 and 1995, each featuring a slew of content additions along with the expected new features and bug fixes. In 1996 RTSoft released the overhauled version 2.00 of their Trade Wars 2002-ish game, Planets: The Exploration of Space (TEOS). TEOS was never exceptionally popular from what I’ve seen but I still consider it a bit of a hidden gem. In 1997, after plenty of teasing, RTSoft finally released LORD 2: New World to a bit of a lukewarm reception. Some specific callbacks to the first game and Seth Robinson’s ever-present sense of humor aside, LORD 2 was an incredibly different experience. Featuring a huge, semi-persistent graphical world to explore, viewed from a top-down rogue-like perspective, it felt closer to early text based and graphical RPGs and action-adventure games than the original Legend of the Red Dragon. Still, it was definitely RTSoft’s most technically impressive game to date. Its release was surely too late though, as dial-up BBSes were well into the process of becoming almost totally extinct by 1997. Released years earlier, LORD 2 could have been an absolute mega hit, but as such its popularity seemed to be quite isolated. Regardless, people that loved LORD 2 seemed to REALLY love LORD 2, with a number of them taking advantage of the game’s REF scripting language to create their own quests or even totally new game worlds, and I feel like it was ultimately very influential to those of us still paying attention by then.

Legend of the Red Dragon 2 Screenshot

Seth himself had apparently seen the writing on the wall and was already moving on, releasing a single-player graphical action-RPG called Dink Smallwood the same year and selling the rights to all of RTSoft’s BBS door games to a company called Metropolis Gameport shortly thereafter. I don’t know much about the history of Gameport but the ensuing years certainly cemented their reputation among already typically anti-corporate BBSers as cynical opportunists, buying up the rights to popular shareware games and utilities, collecting registration fees for them, and then doing fuck all to support them. RTSoft released a token (mostly bug fix) v4.00 of LORD just before selling the game, but having not had a real update since v3.55 in late 1995, cobwebs had already started to form on LORD’s legacy, and Gameport was certainly making no effort to clear them away.

Hacking Away

Meanwhile, I’d been very slowly learning to program since getting into the modding scene and by 1997 had put out a number of small, mostly terrible doors. I started out using Enigma’s “edoor” library for Turbo Pascal which was nice and lightweight and had a bit of an underground scene style to it, thus appealing to me a lot more than some of the larger, more mainstream door libraries. For those unaware, such libraries (often called “door kits”) made the entire process of writing doors much simpler as they, at the very least, took care of all of the tricky communications stuff behind the scenes. Many went a step further by including some of the common underpinnings of door programs, such as SysOp-side functionality like a local status bar and the ever-important ability to hang up on annoying users. Armed with one of these, a programmer could focus on the actual functionality of their door. As an aside, it’s safe to say that without the existence of such door kits we wouldn’t have ended up with anything close to the huge number of LORD IGMs I mentioned earlier.

Anyway, my only real frustration with edoor was that its source code wasn’t available which meant certain aspects of it couldn’t really be customized. More crucially, the routines provided by the library couldn’t be modified either which could really hamstring a larger, more complex project. I’d imagine resulting from being annoyed by the very same limitations himself, my friend Natedogg released his own take on edoor which he called the “Xtreme Doorkit” (or simply “xdoor”) with Demonic Productions in 1997. Xdoor did just about everything edoor did while yes, including the full Pascal source code. As an added bonus I had full support from the developer himself if I ever needed it. Naturally xdoor instantly became my door library of choice.

Xtreme Doorkit (XDoor) v1.02 file_id.diz

By 1998, with xdoor in my possession and a slowly growing confidence in my programming ability, I felt ready to tackle something more ambitious than the small utilities and doors I’d been working on up till then. At the very least, I hoped working alone on a larger project from the ground up would force me to expand beyond my rudimentary knowledge of Pascal. Branching out to a door game seemed like a logical choice, especially having observed the disappointing situation with LORD and the relative lack of other new door games coming out to help take its place. The idea of writing a door game quickly morphed into a scheme to rewrite LORD. I don’t mean a similar style of game like Darkness would eventually become, but a literal, fully compatible duplicate of Legend of the Red Dragon. Not only did I not have any specific ideas of my own, I felt some odd sense of duty to keep LORD alive, somehow. I dove into the project with a kind of fiery indignation – I was going to save my favorite door game!

Starting with LORD 4.00’s data structures, the only pieces of LORD’s source code that had ever been publicly released (for the purpose of allowing IGM and addon developers to access LORD’s data files), I began working on manually reverse engineering the game from there. My efforts hadn’t got very far at all before rumors started circulating that Gameport had granted a fellow named Michael Preslar the rights to continue development of the old RTSoft games for them. While this was surely positive news, regardless of his ability as a programmer, it seemed unlikely to me that anyone could adequately fill Seth Robinson’s shoes. Besides, I had already decided that my door game was happening. Rather than cancel my plans entirely, my new game would simply be a LORD style game, not unlike New York 2008, Lunatix, and Jedi Knights to name a few. Ultimately, this would surely be easier than the increasingly daunting task of trying to duplicate LORD’s seemingly limitless number of idiosyncrasies, so I rolled up my sleeves and got to work. Darkness was born!

Shaping the Game

So where the hell did the name “Darkness” come from? Well, I don’t actually know. I can tell you where it didn’t come from, though. I’d never heard of the comic book series The Darkness, which came out just before I started work on my game, until a team of awesome ex-demoscene dudes named Starbreeze turned it into a popular video game franchise in the late 2000s. The British rock band The Darkness? They came along after I’d already started work on my game. White Wolf’s “World of Darkness” pen and paper roleplaying game setting, which I was familiar with, likely wasn’t any sort of inspiration. If anything, perhaps Agent Orange’s debut album “Living in Darkness” might have at least been responsible for why the word was bouncing around in my head at the time. Regardless of where the word came from, it was clearly edgy and cool enough to appeal to my 17 year old sensibilities, and that’s all that really mattered.

What about cyberpunk? Well, I don’t have a very definitive explanation for that either. Living up to nerd stereotypes, I was a longtime fan of science fiction, computers, and anime, and I’d been vaguely fascinated by the crossroads where these things all met, the genre of cyberpunk, since first being introduced to it by pen and paper roleplaying games like FASA’s Shadowrun and R. Talsorian’s Cyberpunk 2020. I’d been playing Shadowrun with some high school friends here and there, and the mid to late 1990s saw several notable cyberpunk-ish movies and shows such as Johnny Mnemonic and the original Ghost in the Shell film. The genre definitely appealed to me. Still, I couldn’t really tell you why I decided on that theme for Darkness outside of the fact that I didn’t know of any other explicitly cyberpunk door games, and if my game was going to be a LORD clone, at least its setting could stand out from the array of medieval fantasy and hard sci-fi themed door games out there, right?

Exitilus 2.05 Advertisement

As for the game itself, this isn’t really evident from the betas that I eventually released, but from the early days I aspired for Darkness to be much more than a straight LORD clone. I’d start with LORD’s gameplay as a core, definitely, but I planned to build systems onto it from there. I wanted to incorporate flavor and gameplay features from some of the cooler LORD IGMs I’d played with as well as some other door games, with Tao Ge’s original versions of Exitilus being a game that had particularly intrigued me. Features such as an elaborate gang territory control and warfare system were planned from early on, for instance. I also wanted the world to be considerably more gritty and “adult” (that is, what passed as “adult” to an angsty teenager) in tone than LORD, and bringing some of the style and flare of the underground scene that I had become so entrenched in into the game’s aesthetics was a stated goal as well.

Development

Despite not having a clear idea of what I needed to do and practically no other existing door game source code to look at for examples, things actually went surprisingly quickly at first. Of course there were numerous challenges – I had a weak grasp on how to use binary data files, and I’d never coded any sort of ordered list in my life, for instance. Luckily with friends like xdoor’s author Natedogg and numerous others in my corner, it was never too hard to get to be pointed in the right direction when I found myself off in the weeds. Still, in the spirit of using the whole process for learning, I attempted to work in a vacuum as much as possible. I admit, it was also kind of a secondary goal of mine to surprise some of my friends with just how much my programming ability had grown. Indeed, looking back, it’s hard to imagine how I managed to come up with some of Darkness’s more complicated features like multinode functionality and IGM support completely on my own.

It’s worth pointing out that 1998 was probably the most tumultuous year of my life – I was finishing up my senior year of high school, girls finally started noticing me (somehow) and I had my first drama filled relationship as a result, and I started my first IT job, all of which combined into a chaotic strew of stress and exhaustion. The following years would add even more demands on me free time, as in addition to starting college and having heaps of homework, I’d become heavily involved in my local punk scene and started going out to shows as much as humanly possible. It’s kind of a miracle that Darkness ever even ended up in a state resembling being finished in the first place, honestly, and towards the end I definitely rushed through a lot of the remaining work just to get it out the door. For instance, the final encounter at the end of the game, which had been a huge focal point in LORD, was totally thrown together with relatively little care. At long last, I released my first private beta in January of 2000, followed up with a public beta, v1.00 wide beta 2, in late May.

Darkness v1.00 Beta Intro Screen

Coincidentally, the BBS landscape had started to change by then. In 2000, Mystic BBS shifted focus from its DOS and OS/2 versions to its Win32 and Linux ports, and Synchronet reentered the picture in a big way with the impressive version 3.00. Together, along with the RemoteAccess inspired EleBBS, these packages finally introduced a free and effective method for SysOps running more modern operating systems to run otherwise old school BBSes via telnet. To go along with that, all of these packages included support for a brand new drop file format specifically designed to allow Win32 and Linux native doors to communicate with them, DOOR32.SYS. Oddly, in order to help spread their new standard, both BBS authors had taken to hacking DOOR32.SYS support into some existing open source door kits, with Rob from Synchronet tackling the well-known C++ door library OpenDoors, and James from Mystic, in addition to his own Virtual Pascal library called D32, releasing a modified version of Natedogg’s xdoor which added Win32 support (via Virtual Pascal) while maintaining backwards compatibility with the older DOS versions.

Working with James, it took little effort to port the game from Borland Pascal to Virtual Pascal and upgrade to this new 3.00 release of xdoor, making Darkness one of the very first door games to support DOOR32.SYS when v1.00 wide beta 3 was released in mid 2001. This may seem like a footnote in Darkness’s story, but I believe this is probably the main reason Darkness hasn’t completely faded into obscurity in the years since. It went from mostly being only of interest to my friends in the underground scene to being on a huge percentage of SysOps’ radars practically overnight.

Final Release

Darkness v1.00 beta 3 file_id.diz

In the end, Darkness was pretty well received. People were excited for a new LORD style game, sure, but the gritty cyberpunk theme, including the over the top sex and violence, as well as the dark humor and underground aesthetic, seemed to really go over with the people it was most aimed at, which is to say angsty-ass teenagers and young adults like me and my friends. Surprisingly, a small handful of IGMs and utilities got released for it as well, and I was (and still am) grateful for the show of support.

Bug reports and suggestions also came rolling in and I did my best to address them. As with beta 2, I went on to release several interim builds that were distributed as archives of simple drop-in file replacements. This was a regrettably sloppy release strategy that has lead to a lot of SysOps who still run v1.00 beta 3 to unwittingly use older, buggier builds, though in my defense these releases were really only meant as stop-gap fixes for beta sites in between larger releases. Unfortunately, the next larger release never came and the build released at the end of November 2001 was to be the very last one. Not at all coincidentally, I entered the post-college workforce full-time in December. Quickly finding myself sapped of the energy and focus required, work on most of my scene related projects ceased, and I let Darkness fall by the wayside before ever getting it out of beta, and in hindsight, at a time when it was perfectly poised to ride the momentum of the growing telnet BBS scene.

To be continued…

Here’s is a quick list of Darkness v1.00 related files:

DRK100B2.ZIP – Darkness v1.00 Beta 2 (2000) D050300.ZIP – Darkness v1.00 Beta 2 Update #1 (2000) D061300.ZIP – Darkness v1.00 Beta 2 Update #2 (2000) D071900.ZIP – Darkness v1.00 Beta 2 Update #3 (2000) DRK100B3.ZIP – Darkness v1.00 Beta 3 (2001) D080501.ZIP – Darkness v1.00 Beta 3 Update #1 (2001) D101201.ZIP – Darkness v1.00 Beta 3 Update #2 (2001) D112001.ZIP – Darkness v1.00 Beta 3 Update #3 (2001)

DAMF105B.ZIP – Dark Alley Medical Facility IGM (2001) DENED1B5.ZIP – Darkness Enemy Data Editor (2001) DRKIGM8BALL10.ZIP – Magic 8 Ball IGM (2015) DRKIGMLEMO10.ZIP – Lemonade Stand IGM (2015) DRKIGMPSC10.ZIP – Darkness Plastic Surgery IGM (2015) FWH100B.ZIP – Females-Only Whorehouse IGM (2001) SM-WILLY.ZIP – Slick Willy IGM (2000)


1. Legend of the Red Dragon INTRO1 by David Nicholson from LORD400A.ZIP (1997)
2. Legend of the Red Dragon 2 Screenshot from LORD2 v1.01A (1997)
3. Xdoor v1.02 FILE_ID.DIZ by Jack Phlash from XDOOR102.ZIP (1997)
4. Exitilus v2.05 AD1.ANS by Tao Ge from EXS205-1.ZIP (1995)
5. Darkness INTRO1.ANS by Cyberphreak from DRK100B3.ZIP (2001)
6. Darkness v1.00 Beta 3 FILE_ID.DIZ by Jack Phlash from DRK100B3.ZIP (2001)

5 thoughts on “A Look Back at Darkness

  1. Thomas McCaffery

    I am trying to get Darkness V2 latest release, I think to work on Synchronet/Dosemu2. Only way I got it ti work was in command line of Synchronet DARK16.EXE %f and in darkness cfg D:/DOORS.SYS. I am not sure that is the correct way though.

    Reply
    1. jack phlash Post author

      Hmm. No, none of that sounds right at all. You should be supplying the node number as a command line parameter with /N. All of the other details are in the config/data files and don’t need to be supplied with the command line. %f in Sync supplies the path to the drop file, which would override what you put in the config and isn’t usually necessary. Perhaps what Synchronet is supplying with %f is correct while whatever you put in the config is not, though you’d normally need to supply “/P” before the dropfile path to specify it as a parameter anyway so I can’t imagine that’s even working, but darkness.log should tell you more. You could try “dark16.exe /n%n /d3 /p%f” to override everything in your config which I’d be way more confident in.

      Reply
  2. Scott Daniels

    Downloaded Darkness from your site yesterday(2/21/23) in hopes of getting it running on my BBS. As I do with all files I download, I ran it through my antivirus scanner. It came back with a positive for malware. I suspect a false positive but am not ready to deploy it yet. Have you run into this before?

    Reply
    1. jack phlash Post author

      Very odd! I can’t imagine much in Darkness’s code that could trigger anything like that. In fact, the only thing that comes to mind is the DOOR32.SYS support (which Darkness doesn’t do any differently than most other 32-bit doors.) This is the original Darkness, not Darkness 2.0, correct? Another possibility is how it launches IGMs, but again, that’s a pretty common function, particularly in DOS BBS applications. Which AV program was this triggered in? In the meantime, I’ll check into the archive to make sure it hasn’t been compromised somehow.

      Reply
  3. Josh Savell

    That’s awesome, I’m really interested in making a door game but there’s not a whole lot of places to look to learn. It’s almost like it was a lost art. I wouldn’t even know where to begin

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *