If you've been wondering how to get all those bonuses, or if you've been itching to try the game but would like a little demo first, check it out in all its poorly encoded glory. I just positively love the music in this game; I should make a CD or something...

Categories: DOS, Games, Retro
No Comments »

Imagine. You're sitting by the fire place, playing the latest game on your big screen television. Beer on one side, your beautiful wife on the other, and both of you are wrapped in a warm, soft blanket with your favourite shooter of all time stitched lovingly to the front.

Too much for a blanket? I think not.

Categories: Retro
No Comments »

I first experienced this desktop software while using a Tandy 1000 RL machine which my father decided to go out and buy at the last minute on Christmas Eve, so I wouldn't be disappointed. It was a nifty little machine with a 20 MB hard drive, built-in audio, 3 1/2-inch drive, and virtually no expansion capabilities what-so-ever. It had one ISA bus; everything else was pretty much hardwired into the system. It did have serial and parallel ports which allowed you to plug-in a MODEM or printer which certainly helped later on. After booting it up, I discovered the manufacturer had installed DeskMate onto a read-only partition on the harddrive. Much to my dismay, they had pre-configured it at the factory. When I needed to reinstall the system sometime later, DeskMate never functioned like it did out of the box. For some reason, and I have yet to figure out, it was about two or three times slower.

When compared against other Windowing environments at the time, such as Windows 2.X or even Windows 3.X, it could hold its own. The major feature missing was network support, but even Microsoft products didn't support that until Windows 3.11.Until DeskMate walked into my life, I had never experienced a visual desktop before. It was an exciting experience and I wanted to explore every nook and cranny. First and foremost, I wanted to write software for it, so I phoned the number provided by Tandy Corporation in our manual. They said I needed to purchase the software development kit (SDK) and a suitable compiler. At the time, I didn't know what a compiler was so I thanked the person and went about calling local stores and asking them questions. After a bit of research I discovered that the SDK was expensive and so was the compiler, which according to the sales person was a "program to make other programs." They were probably brushing me off since I was basically a kid (or a young punk) at the time. I know they were at least a few hundred dollars a piece which put them out of my price range. In the end, I'm happy I didn't invest the money in the SDK since I have since learned it wasn't very good. Apparently, many companies had to write much of their own code in order to do anything useful. I would still like to check out the API, so until then, I reserve final judgement.

DeskMate had all sorts of small applications available. It had all of the standard applications like a word processor, simple database, spreadsheet, drawing application, telecommunications software, etc. These applications are extremely simplistic compared to what is available today; although the word processor did have spell checking and even a thesaurus and dictionary (purchased separately), and the database was functional enough to be useful. It even installed a personal diary program, which was very well done. It also came with a variety of useful on-screen tutorials to help you learn the software as you use it. Microsoft Windows didn't have anything that helpful until Windows 95.

Categories: Reflections, Retro, Software
1 Comment »

This is a perfect game to play after a hard days work at the office. It's perfect because the objective couldn't be easier to remember: collect all of the white pellets in every level. Naturally, collecting these pellets isn't as easy as collecting rocks. There are plenty of obstacles in your way like daring jumps, touchy explosives, attractive magnets, and small angry balls of fire. To further enhance your experience, each level is timed so you can't allow yourself to be distracted by screaming kids, nagging spouses, or government taxes. On second thought, it may not be wise to ignore the second one.

If you're one of the few skilled players who manage to complete the game - I finished it a couple of years ago (after years of "training") - you can supplement your addiction with the Robot Factory. Only through the factory can your dreams of monolithic, white pellet construction be realized. Remember to save your construction and post it on the Internet; don't forget to add a comment here telling us where we can find it.

I would recommend playing it on the Atari 800 XL. It has much more vibrant graphics than the Commodore 64 version and the sound is pretty much the same.

Categories: Atari 8-bit, Games, Retro
No Comments »

The first Atari 8-bit computers to arrive on the scene in 1979 were codenamed Candy and Colleen, referring to the Atari 400 and 800 respectively. The latter was rumored to be named after an attractive female staff member (she undoubtedly had curly brown hair and lovely chocolate eyes, just like my wife). The Atari 400 was marketed as a gaming system, while its more expensive cousin was seen as a personal computer. Both machines featured a membrance keyboard, which after careening around town for a while, seemed to have walked down the wrong alley and was subsequently never heard from again. Much of the "guts" for the 8-bit computer line came from Cyan, the engineering team responsible for the Atari 2600. In a couple of years, they produced three processors for the new computer models: CTIA, POKEY, and ANTIC.

CTIA is an acronyn for Color Television Interface Adapter and was the successor to the TIA chip used in the Atari 2600. It was reponsible for translating the information produced by the ANTIC chip into signals the television could understand. In later machines, Atari replaced the CTIA chip with the GTIA chip which had much more functionality. In addition to the DAC (digital-to-analog converter), the GTIA controls sprites, collision detection, priority control and color-luminance (brightness) to all objects including display lists from the ANTIC processor. Along with all that extra functionality, some GTIA versions made for the European market were buggy due to a PAL processing error.

The ANTIC processor was reponsible for interpreting display lists, which were instructions on how each scan line was to be displayed, line locations, interrupts, scrolling, and indicating where to find resources such as graphics or character sets.

POKEY was responsible for reading the keyboard, generating sound and serial communications. It also provided timers, a random number generator (for sound noise as well as random numbers), and maskable interrupts. POKEY has four semi-independent audio channels, each with its own noise, frequency and volume control. Each 8-bit channel had its own audio control register which selected the noise content and volume. For higher sound resolution, two of the audio channels can be combined for more accurate sound.

The XL versions contained simplified circuitry to help cut down costs and space requirements. The XL versions were also engineered to comply with the new FCC regulations at the time. One particularly interesting feature, called the PBI (Parallel Bus Interface), allowed for unprecedented access to the computer hardware by an outside peripheral. The PBI is a 50-pin port which provides an unbuffered, direct connection to the system bus lines (address, data, control) running at the same speed as the 6502 CPU. Only the 600XL and 800XL computers had such an interface. The XE systems of the day (65 XE, 130 XE, 800 XE, XEGS) came with the Enhanced Cartridge Interface (ECI), instead.

If you don't have the space or simply do not want the original hardware in your home, there are a few good Atari emulators out there. Atari800Win is an excellent hardware emulator for Microsoft Windows, and is my preferred choice for this platform. Another great emualtor is the open-source project called atari800. Due to the nature of this opensource initiative, it will probably become the leader in Atari 8-bit emulation unless something goes wrong, which is not uncommon for such projects. Obviously the more people who fiddle with the timings and compatibility, the more a project will progress toward the overall goal of 100% compatibility. Whichever version you choose, both have the source code available in case neither supports your favourite platform. One such platform could be the Gamepark handheld device. atari800 was ported to the device some time ago in 2003-2004, but the author has since dropped the project.

If software development is more to your liking, then you may appreciate programs such as CC65. CC65 is a cross-compiler/assembler suite for a variety of destination platforms such as Atari 8-bit and Commodore 64. This cross-compiler will create binary files that are compatible with the desired microprocessor. Compilers are usually complex tools at the best of times, but don't let that stop you! If you don't want to program in assembly language, then CC65 will let you write your software using the "C" programming language. "C" is considered a higher level language by many people, but these people obviously haven't dealt with nested pre-processor macros before. For the more hardcore amoung you, there is always the option of using a native Atari assembler to write your software. You may even be able to use BASIC - don't underestimate its power! I've written several programs using BASIC and the results never fail to impress... myself.

Categories: Atari 8-bit, Hardware, Retro
No Comments »

My experience using BASIC is something I cannot easily put into words. I had never been exposed to programming before, so at first I had a hard time understanding the concept. I started out slowly, playing around with some simple commands which were described in various issues of ANTIC magazine.

Actually, my first experiments were much simpler, consisting of just a single command being given to the interpreter. I loved being able to control the color of my background or make a bunch of erratic and tuneless beeping sounds through our television speaker. For the first time, I was in control of the machine, even if all the machine did was squeak and change colors. I didn't learn about how the interpreter used line numbers until my father picked up a copy of Atari BASIC by Albrecht, Finkel, and Brown. It was during my sessions with this book that I also learned about control flow statements, looping, data types, and loads of new commands. It still took me a while before I learned how to save my creations to disk, but it was too late to go back by then. The bait had already been taken, and it wasn't long before my parent's saw what was happening: I was hooked and I was going to need funding for my new hobby.

For the most part, I learned most of my Atari BASIC programming skills through my father's subscription to ANTIC. This magazine was devoted to the Atari 400/800 series of computers which were popular in the early to mid-1980s. Another popular magazine at the time was A.N.A.L.O.G., but I didn't have access to as many of them as I would have liked. I enjoyed the latter because it had much more diverse and complex programming examples and articles. When I got my hands on our first copy, I wasn't even pausing to read most of the articles, I just brought it straight to the computer and began entering the source code in by hand. Sometimes the process took hours and my code was often marred by spelling mistakes and missing commands. I eventually learned these mistakes were called bugs by people in the software world. Tracing through these programs taught me a lot about programming and debugging. Mostly, it taught me to be careful while typing, and began to practice my typing skills using another software program designed for this purpose. To this day, however, I am mostly a 3:4 finger typist; three being the typical number of fingers I use for my left hand, and four being the perfect number for my right.

My father eventually purchased a dot-matrix printer for the system. It was a Star NX-1000 II, and I absolutely adored this printer. I quickly learned how to use it in BASIC and began printing reams upon reams of code. I enjoyed debugging and enhancing my programs using the printed form. It was an excellent way to get a handle on the whole problem, since the environment in the interpreter prevented you from seeing the whole picture easily. The font was just too large and the software did not have the ability to manually scroll the view. In fact, the concept of a window wouldn't be realized on desktop computers until a few years later. In order to examine a block of code, you needed to continually LIST the sections in chunks or just dump the whole thing at once and wait for the area you were interested in to come into view. The continuously scrolling source code was slow enough you could track it with your eyes, and once you saw the region of code you wanted, pressing the break key would stop the process.

Another great feature of the Atari's BASIC language was the ability to examine and modify specific bytes in memory. At the time, I don't think I fully understood the concept of a memory address, at least not the way I understand it now. It was more abstract for me than other concepts. I knew that writing certain integer values into locations identified by other integer values allowed me to play music and control the colors of fonts and backgrounds, but I didn't associate these number values to a physical address in the machine. In fact, I'm not sure I even truly understood what memory did, other than the typical high-level rationalization: if you buy more RAM it will allow your computer to play this game or use that piece of hardware. I generally understood memory to be a good thing. The more you had, the better off you were.

It wasn't until I started programming the Commodore 64 (C64) with a friend of mine that I began to understand its function and organization. A big part of that understanding came from a device called the Super Snapshot cartridge which could plug into a port on the Commodore computer. This miraculous device had a number of cool features, and one of those features allowed the user to interrupt a game (or whatever) and examine/modify the contents of RAM and then return as if nothing had happened. Initially, we used this device to cheat on games by changing the number of lives, strength, loot, whatever. All we needed to do was isolate the byte responsible for tracking these attributes in memory, modify the contents of the variable at that address, and voila! We were invincible, we could crush any opponent, or we could buy any item. Life was good. I believe the manual for the Super Snapshot explained a number of details about memory and how it was organized. This served as a great stepping stone for my next foray into the world of Atari memory.

The next big advance for me came after reading the book: Mapping the Atari by Ian Chadwick. It explained what all of those numbers meant and how they were used by the Atari. I was enthralled and began to experiment with earnest. Incidently, the commands I was using to read and write values to and from memory were called PEEK and POKE respectively. Loads of fun can be had with these commands and that great little book. As it turns out, this book became even more useful while dabbling with assembly language years later on the Atari.

Categories: Atari 8-bit, Programming, Reflections, Retro
1 Comment »

Atari DOS - This operating system was the first operating system I was exposed to during my youth, and the 2.x series was the most popular in my household. The operating system was loaded off of 5 1/4" double-sided double-density diskettes which usually offered about 320 KBs of storage space after formatting, although other disk formats offered less or more storage depending on density. The operating system did little more than manage disk functions such as formatting diskettes or erasing and copying files, hence the full name "Disk Operating System." It could, however, be used to boot strap the cartridge or run a binary program at an arbitrary address after it was loaded. The DOS was mostly used to access files and programs stored on floppy diskette. It provided a File Management System (FMS) which needed to remain in memory in order to provide disk access functionality to other programs.

Believe it or not, there are still hardware/software hobbyists and professionals creating products to use with your Atari. I have a software solution called A.P.E. which allows me to use my computer as a virtual disk drive, printer, modem, etc. It's absolutely fantastic and accelerates software loading to a fraction of the time it took before. There are also products which allow you to connect a hard drive through the cartridge port, or even USB devices!

A.P.E. stands for Atari Peripheral Emulator and is an essential piece of software for any Atari user. Until a few years ago, I was forced to play my Atari games via an emulator or on the Real McCoy using the terribly slow, but wonderfully nostalgic floppy disk drive. I don't think it's necessary to mention how painful it was waiting for the disk operating system to load, and then waiting for the actual game to load, and then waiting for the game to save, and then waiting for the game to load the second disk... you get the idea. There was a lot of waiting, and somehow I mangaged to do it without batting an eye lash in 1984.

First and foremost, A.P.E.'s biggest strength comes in the form of its disk drive emulation software. In order to get it to work, you must own a working Atari computer. The author probably explains exactly which Atari computers are compatible somewhere on his website, but I can tell you for sure that the Atari 800 XL and Atari 400 computers work like a charm. Simply connect your Atari computer to your personal computer using a custom SIO interface cable. The cable can be purchased through the web site, or you can even make your own if you're so inclined. Install the APE software on a computer, configure it, select a disk image, and boot up your Atari machine. Voila! The software you selected will boot in record time. Plus, your personal computer now acts as a virtual hard drive for your Atari! You can put away those floppy diskettes, all of your games and applications can be saved and archived as an "ATR" file, which A.P.E. can understand.

Categories: Atari 8-bit, Reflections, Retro, Software
No Comments »

The story behind the source code release goes something like this: In December of 1997, id Software released the source code for Doom to much fan fare and adulation. After only a few short weeks, web sites starting popping up and modified (or modded) versions started appear on bulletin board systems. Before the source code was even released, their were already tools available for modifying the existing graphics and levels, or for creating your own levels, on the Internet. These tools operated on the storage format for the game's resources, which included maps, graphics, sound effects, etc. These resource files were called .WAD or .IWAD files. WAD does not stand for anything in particular, but you could choose to think of it like a wad of gum after eating a burrito. It contains all sort of unrelated bits in it, like green pepper and cheese, but together they form a chewy and cohesive whole. Yummy.

Modification to the actual game engine allows for much greater control over how the game operates. Despite this new found ability, many programmers or modders chose to leave the original code base intact, in order to give their users the freedom to play the older levels designed by the master's at id Software. I believe this should be an important creed for any aspiring Doom hacker to follow, as it will allow your audience to experience the many thousands of levels available for immediate download. Just in case your levels fail to impress your core audience, such as Mother.

This project is intended to document what you need in order to build the DOSDoom (another port of Doom) source code on your machine. We chose to use DOSDoom, instead of the original code base, because the original requires a fair amount of modification to get it building with the available development tools and environments on an MS-DOS compatible machine. This brings me to my next point, you're going to need a compatible DOS operating system installed somewhere in your house, if you want to compile this project; Windows 95 actually works quite well too as they are basically one and the same in many respects. As a trusty member of the classic gaming community, I trust this shouldn't be a problem for those of you who are still reading.

DOSDoom brings a nice set of options to your exisiting Doom game. Features like mouse support, the "look" feature, CD audio, alpha blending, custom resolutions, and a whole lot more! Trust me, when you're finished setting it up, you'll think it's almost like a new game.

Ok, first things first, you're going to need the source code. It also helps to have a pre-built copy of DOSDoom on hand for comparison, and a chance to try it out just for fun. Personally, I love this version of Doom and will typically opt to play it over the original; unless we're talking about the Playstation port, then we could be persuaded switch platforms for a while, or the Mac OS X port I wrote about a while ago. Of course, before either version will work, you need an original version of Doom. Please respect copyright laws and get yourself a legal copy; it's not that expensive when you consider what you're getting in return. Now would be a good time to unzip the pre-built copy of DOSDoom into your Doom game directory.

For those of you who weren't born with a debugger in your bonnet, there's a few pieces you need to have in place before you start unpacking the source code for DOSDoom. First, you need to understand the process by which program code gets transformed into something you can actually use. However, we're not going to write yet another treatise on "How To Program In Such And Such A Language," although for your reference, the core programming technologies used in this project are called C and Assembly Language. Learning to become a programmer is an iteresting but terribly long ordeal. I don't recommend it unless you're planning on making it a serious hobby or even a profession. Choose to play the game instead, you'll probably be happier.

Since you're still reading this article, I think it's fair to assume that you're mildly interested in the topics presented thus far, so let's get a few terms under our belt before we begin. There is one general phase which must take place before you can use the source code provided and that phase is called compilation. A compiler is a tool used for translating source code which has been written in a high-level language, such as the C programming language, into a lower-level language more suitable for native execution within the hardware environment you are using. From a software development perspective, writing a good compiler is one of the most difficult and rewarding experiences a programmer could choose to undertake. However, simply using a compiler is usually no more difficult than learning any other moderately complex tool. Yes, there are usually a plethora of options and fancy doodads available for any aspiring geek, but many of them are rarely used and can be ignored most of the time. The compiler used for this project is part of a free development environment called DJGPP. DJGPP was primarily constructed by a man named DJ Delorie with plenty of help from the open source community. It contains numerous utilities, including a DOS port of the GNU GCC Compiler Collection.

Assembly Language, on the other hand, is much less abstract and tends to be a lot closer to a machine's level of understanding. This source code does not need to be rigorously compiled and students of computer science will often write simple assemblers for course projects. Instead, Assembly is translated into machine language almost directly. Depending on the software used, "almost" can vary from assembler to assembler. DOSDoom's source code contains only a couple of assembly language modules and can safely be ignored unless you're planning on making low-level modifications to the game's rendering engine. For this project, we'll be using GCC's assembler called GAS for all of our assembly needs. There is one item we wanted to mention when using GAS assembly code: it does not follow Intel's coding conventions for instruction mnemonics, it uses the AT&T style instead. For a great book on coding for the Linux platform (which typically uses GCC as the default compiler/assembler toolkit), pick up a copy of Professional Assembly Language by Richard Blum (ISBN: 0-7645-7901-0).

Now that we're all a little familiar with the basic process, here is the complete list of packages needed in order to compile DOSDoom:

• Allegro Game Library v3.1
• GNU Compiler Collection v2.8.1
• GNU Assembler & Toolkit v2.8.1
• Make v3.79.1
• DJGPP Development Kit v2.02
• DJ File Packer v1.07
• RHIDE v1.5
• CSDPMI v5.0

Now what are these extra packages all about anyway, eh? They're all required too, except for RHIDE which is a nifty Integrated Development Environment (IDE) very much like Borland's early C/C++ IDE, and the DJ File Packer which is used to shrink the size of the resulting executable into something more manageable. The DPMI server is required by every 32-bit protected-mode application (in this case it's DOSDoom) for DOS and gets launched automatically by the client application - just make sure it's available via the PATH environment variable or in the applications home directory. The item listed only as Make is a set of tools used to easily build applications by managing their dependencies; although the syntax used to create Make files is anything but intuitive. Last, but certainly not least is the Allegro Game Library originally written by Shawn Hargreaves. Allegro is used to fill some of the gaps left by id Software when they released the source code for Doom. It's a great library and can save you loads of time when you're trying to write an application. All of these tools or libraries are relatively complex and deserve your attention if you want to make any useful contributions to this code base.

All but the last package, CSDPMI, must be unzipped into the same directory; CSDPMI goes into the Doom game directory instead. To help illustrate where everything goes, here's a look at our build directory:

contrib
allegro
bin
doc
gnu
include
info
lib
man
manifest
projects
share
tmp

Once the packages have been decompressed, modify the DJGPP.BAT file to suit your own directory organization. For example, my batch file looks like this:

@echo off
set PATH=c:\source\dosdoom\djgpp\bin;%PATH%
set DJGPP=c:\source\dosdoom\djgpp\djgpp.env


Execute the batch file whenever you open a new console window (when using Windows 95), or after you've booted into DOS. Now, open the file under the Allegro directory and find a file named makefile. Remove the bit of text "-Werror" from the file using your favourite text editor. This is a compiler option which will halt the compilation process when a compiler warning is encountered; normally, it's not a bad idea, but for the sake of simplicity we'll remove it for now. The next step is to build the Allegro library by typing the command make.

Depending on the speed of your machine, the compilation process may take a while and you'll see several messages displayed on screen. If you downloaded everything from this web site, you should experience no errors (provided you removed the compiler option mentioned above); although a few compiler warnings will make their appearance now and then. Once the Allegro library has been built, you should now enter your DOSDoom source code directory and type make again. This will build your DOSDoom executable file. You'll need to copy this file (/obj/dosdoom.exe) into your Doom game folder (where the main executable file doom.exe is found) . Run the file dosdoom.exe and enjoy!

Remember: When making modifications to DOSDoom, please acknowledge all of the contributors who have made DOSDoom into what it is today. Without the tireless efforts from these people, you would have a lot of work on your plate before you even got started implementing your own vision of what you want Doom to be.

Categories: DOS, Programming, Retro
No Comments »

Since I couldn't find any on their site, I've churned through the Exult engine using Doxygen to produce a usable set of API documentation. It's a good reference to get a handle on their overall architecture in case you felt like diving a little more deeply.

Categories: Programming, Retro, Software
No Comments »

During the early 1990s, the Internet was fairly new to most people. At the University I attended for a time, we were using a PC-DOS based environment which had Novell's Netware stitched on top of it. At the time, I had a small number of Usenet news groups I liked to read every morning, and I stumbled across a post by an individual in alt.rec.gaming or the like. This was before the days of spam and prolific pornography, so when a person posted a message with a subject line like "Check out this cool site!" You had no reservations whatsoever about following the link.

The link he provided wasn't a URL which could be viewed in a web browser, but looked something like this:

telnet://chaosrealm.darkmatter.org:4000/

Until I started paying to go to school, the only experience I had with a public network in the late 1980s was through local Bulletin Board Systems. I could e-mail people on other BBS systems through something called FidoNet. Those systems would use a BBS mailer for the users to create their message (or it could be uploaded using a pre-formatted text file), and then copy it over to the FidoNet servers for transmission using specialized protocols. The mailing address was rather complicated and needed to have a series of names, symbols, and numbers affixed to it if you ever expected it to reach its destination. Due to my own inquisitive nature and two very understanding parents, I was able to set up and experiment with computer communication. As a result, I was somewhat more experienced with networking before entering University than your typical freshman, but I had never used a telnet client before. It was certainly a mystery that needed solving. Little did I know what worlds waited for me on the other side. Nowadays, there is a bare-bones telnet client on virtually every desktop. Under the Xandros operating system, the program is called "telnet." Likewise for Microsoft Windows and MacOS X.

After a bit of research, I discovered what I needed to access the site, so I started poking at the client program. A friend of mine saw what I was doing and thought it looked interesting, so he pulled up a chair and logged into his own terminal. What we saw was disappointing at first. It was essentially a blank screen with a small title surrounded by credits centered in the middle and a login prompt near the bottom left-hand corner. I knew neither of us had an account, so I thought our little adventure would probably end right then and there with a message like "Invalid login" or "Permission denied." Instead, we received a prompt asking "Are you sure you want to use this name?" Tentatively, I declined and sat staring at the screen for a few seconds. I was familiar with the concept of a "handle" or nickname from the BBS systems I frequented. I remember not wanting to use the name I had entered, which was probably something unoriginal like my first name. I don't remember the name I chose and it's probably for the best. Little did I know, the interesting questions would soon follow.

The server accepted my new name and prompted me for a password. It then asked if I wanted to be "[M]ale, or [F]emale?" During my role-playing sessions, I had never considered being a woman, even though friends of mine tended to flip-flop between the sexes just for fun from time to time. I guess it just wasn't something I even thought about. My teenage philosophy was black and white: how could I be a fearless knight of the realm with breasts? However, faced with the same opportunity on my computer, I did pause for the briefest of moments. Anonymity is not somethings easily overlooked by most people. Not wanting to appear unmanly in front of a friend, I quickly pressed the 'M' key. To this day, I have never played as someone from the opposite side of the gender coin. I eventually realized it didn't really have an appeal for me. If I was going to invest the time creating a character in this new world, I needed to take it seriously and not go galavanting around the realm trying to fool everyone into thinking this body is real and I know how to use it. Besides, I really don't think I would be able to do a very good job of it. I would probably end up over-acting and annoy everyone in the game while fooling no one at the same time. And then there's the whole psychological impact of sustaining an Internet female persona...

Depending on the site you visit, the questions don't necessarily end after you choose your sex. There can be questions about your race, occupation (warrior, cleric, mage, or dentist), attributes, and a description for your character just to name a few. Before you start hammering away at the the keyboard, it's important to realize these details will be visible to other people. The site I visited that day was classified as a MUD which stands for Multi-User Dungeon/Dimension. There are many other classifications of multi-user software environments such as MOOs, MUCKs and so on, but I have only been interested in dungeons. A MUD is a world tapered in such a way the user will feel like their transported into an interactive book. All of the details in a MUD are described by words; there are no sounds, graphics, or vibrating joysticks. The illusion is helped along by talented authors and other player characters. Just like actors and actresses, most people who enter a MUD want to remain in character while they're on-line, so information about their personal lives are usually not revealed. If they want to elaborate on their real life, then they usually initiate a private chat or use special abbreviations to illustrate they are speaking out of character.

The software hosting the MUD is stateful. It knows when you're logged in and when you're not. When you're naughty and when you're nice. By your command or when you log off, it can record vital details about your character like the equipment you're carrying, the money you've accumulated, and other pertinent details. Anyone familiar with games like Dungeons & Dragons will feel right at home in this universe. In fact, it's often a fun alternative to playing face-to-face, especially when you're role-playing amigos live far away. Muds essentially run by themselves, but they can also be directed in real-time by controlling characters often called wizards, gods, or heroes. These characters have permissions to modify the world and initiate quests. Ordinary players can sometimes attain these positions by achieving a very high-level character ranking and then be offered a promotion, or simply participating in its day-to-day operations by becoming more involved. Sometimes it's just easier to befriend one of the wizards and beg for an opportunity to prove yourself worthy. Just try not to cry if they refuse.

Wizards are usually programmers who typically interact with the MUD on a technical level. They usually have a character which is used to logon to the server in order to test the deployment of a new feature. It's inadvisable to anger these people because they can eject you from the MUDvery easily. Their characters on the MUD are not ordinary players; they usually cannot be killed and they often make themselves invisible to ordinary mortals. This is a kind of power one can abuse. Do what you like on your own server, but I can guarantee no one will want to visit your realm if you abuse your abilities as a Wizard.

Back in the heyday's of MUDding, there were literally thousands of these servers up and running on the Internet. And as a player, you had your pick of the litter. Low and behold, though, the majority of those servers were rehashes of existing worlds. There were a few bright stars amoung them, but it was a challenge to find a truly original MUD with a decent up-time. If you're going to spend the time to create and manage a MUD, then I suggest you think of an original theme first and then come up with an interesting environment. It could be used as an interesting spot where you and your friends and family can hang out instead of the typical chat room.

Interaction on the MUD is accomplished via text commands you feed to the server hosting the game. These commands and transferred over the Internet via the telnet protocol and then the response is sent back to your client in a timely manner. So, what commands are available for you to use? It depends on the server software, but they are very similar to the commands used by many classic adventure games. At some point in their history, games like Leisure Suit Larry and King's Quest all sported a command interface where you typed what you wanted the character to do. For example, commands like "take bottle" or "look at painting" were commonplace. MUD commands were pretty much the same, except they could usually handle more complex sentences and contained a larger set of available commands. There is also the multi-player aspect to consider. A MUD needs a much more extensive set of commands used for communication like "shout," "talk," "whisper," or "emote." These all have different effects based on your permissions and proximity to other players. For example, some MUDs do not allow just anyone to shout a message, since it will usually be heard by everyone currently logged into the MUD. Players in the past have used this feature to be very naughty.

Due to its popularity, you would expect there to be a lot of MUD software available on the Internet and you would be right in thinking so. From this point onward, we'll be studying an implementation called CircleMUD. CircleMUD was created by a man named Jeremy Elson in 1993 and is a worthy extension to the DikuMUD codebase which was written by Katja Nyboe, Tom Madsen, Hans Henrik Staerfeldt, Michael Seifert and Sebastian Hammer in 1990. It is stable, well programmed and documented and certainly one of the more popular servers available today.

Before we delve too deeply and greedily, I think it's worth talking about the software license. You can use the software free of charge, but you must comply with the license agreement, which basically has three requirements. First, you can't make any money off of CircleMUD. That also includes soliciting funds or accepting donations. Second, you must give the authors credit for their hard work. And lastly, you must comply with DikuMUD license. All of these details can be found in the documents accompanying the distribution.

Categories: Retro, Software
No Comments »