Legend of the Red Dragon Linux Port Q&A

The classic BBS role-playing game Legend of the Red Dragon has a special place in the furthest reaches of my video game memory, which I suppose is unsurprising given the GameBanshee BBS that we launched and the interview we did with Seth Robinson. But getting the game to run in modern times is no easy exercise, particularly when you need to port it to an alternative operating system like Linux. A guy by the name of Chris England has done just that, and Slashdot took the time to quiz him about the project:

EP: You've had this game running for well over a decade now. Has it gotten easier to manage as time has gone by, or has it become more difficult?

With many years of fine tuning and automation, it has become very easy to manage. Between work and my addiction to the remote British Columbia wilderness, either my time was saturated or I was simply not around to keep up with issues like investigating players suspected of using multiple accounts or dealing with players taking advantage of known bugs. This led to a level of frustration among users in early years. For example, in our environment there is no carrier detection. If a player disconnected in an IGM [In-Game Module], they were essentially protected from being battled by other users. Fast forward to today where if a player attempted this, within a short period of time the system would detect it and leave them vulnerable, "sleeping in the fields.)

EP: You've created a custom BBS to manage these games -- How does it work?

The BBS part is a fairly basic sign-up, authentication and menu system made in perl. Much like a regular BBS, when a user selects the menu option to enter a game, a dropfile is generated and passed to the game. After that, things get a little different. It dynamically creates an autoexec.bat to invoke the games start.bat file with the appropriate node parameter and then fires up dosemu. The BBS itself listens locally on a non-standard port through xinetd/in.telnetd, as I needed to create a proxy script to reside in front listening for the incoming telnet connections. This was necessary in order to sanitize some undesirable input with a script that could make decisions and manipulate the packet contents in some cases. Aside from that, there are a number of automation scripts running in the background which range from compensating for lack of carrier detection and analyzing logs to converting LORD color ASCII to HTML and of course sending me a text message when it's time to announce a winner and reset a game.

EP: LORD was written in the dial-up era. What challenges have you faced in making it available for the modern age?

There are so many pieces that need to work together. I tried a number of combinations of operating systems, dosemu/dos versions, netfossil drivers, ANSI drivers, BBS software, LORD versions, IGM's, etc. It was difficult to find a combination where all components would play nice for the long haul. Having a stable environment was a top priority, so I decided to make my own BBS, forget about the fossil routines and just run the game as if it's running locally. This resulted in stability, but presented a number of other challenges from a security standpoint. IGM's with special sysop functions like "drop to DOS" were out of the question and I needed to prevent every possible method that could be used to break out of a batch file.