FieryMUD is one of the oldest DikuMUD derivative MUDs that still runs today. I originally played around 1996-1997, and intermittently until the "Great Crash" in which most of the servers contents (including the code) were lost. In 2002, I found out that the game had been reborn, and began playing again.
After graduating from the University of Illinois in May, I began inquiring about a coding position. After proving myself, through some coding-unrelated tasks, I was finally given the chance to see their code, and begin submitting patches. Within several months, the "Head Coder" decided to move into the "Head Builder" role, since our previous Head Builder hadn't been able to devote time in a number of months, and named me his successor.
Some of my contributions to the current game (smallest first) :
- First contribution was a fix to a string displayed when you reached the maximum level of experience - a pet peeve of mine since I had seen it as a player.
- Using GDB, Insure++, and lots of patience, tracked down a multitude of bugs, including a well hidden (had been in the code for 4+ years, and no one had found it) buffer overflow which was causing the majority of the games crashes. Fixed various player-skills which had been removed because they never worked right.
- Added a handful of new spells and abilities.
After about a year, I was let in on the fact that they were working on a new top-secret codebase, and asked to join on that effort. The general gist of it was that people were impressed with the progress I had made on cleaning up the codebase, but we all realized I could potentially work for years just to get things stable. As such, we started Fiery V3.
Our main focus was on stability and balance; the two factors which we believed had slowly caused us to lose players over time. I spent some time working on the old code, just to keep up the appearance of things being normal, but spent most of my time on the new code, which had not at that time been announced to the players. Some of the highlights included:
- Game balance was predetermined; we had worked out general statistics for everything before hand.
- Game balance was somewhat enforced - builders could modify attributes on enemies from the expected values, but for the most part they were discouraged from doing so. Objects had a point-based system in the works to ensure nothing too powerful.
- Kept our codebase up to date with patches released to the main code base (Primarily the CircleMUD core, OLC [OnLine Creator - the system for designing the world] and DGScripts [a fairly widely used scripting language for CircleMud).
- Created a simple set of functions to interface with MySQL.
- Rewrote the storage portions of OLC to interface (.h, .c) with a MySQL database instead of flat-files.
- Modified and extended the scripting language to allow some of our more complicated quest scripts to run.
- Used my mathematics background to shift our damage system from a traditional system of random numbers of the form 3d5 ( sum of 3 random numbers between 1 and 5) to a more simpler to generalize system based on average and standard deviation. This allowed us to create a function dictating the average damage at each level without then having to try to find an appropriate 3d5 style combination which would fit the characteristics we wanted.
- Created a system and in-game command which interfaced with the firewall protecting the server which would allow administrators to request temporary access to log in (provided they had a valid login and password). The firewall explicitly denied connections not in a given IP list, which could be modified if you had permissions. This was necessary to allow coders with non-static IP addresses to access the machine.
- Created online editors for the online help.
- Introduced commands with reuse timers - IE - commands that can only be used once ever X time period.
What's a Head Coder?
The Head Coder acted effectively as a development lead, including such tasks as maintaining the "starter kit" for new coders, training new coders on how the system worked, and making overall architectural decisions about the code. In general, the role also entailed making game design decisions with the two other peers - a Head Builder (responsible for the actual content of the game) and the Overlord, who effectively had been passed down the responsibility of maintaining the game in general.