Yearly Archives: 2007

Converting Races by Hand

I spent quite a lot of time manually converting the race files to XML.  The file format didn’t lend itself well to automatic conversion, nor was much of it an easy search-and-replace setup.  Some of the values were strings of flags, some integers, some full sentences, without much consistency.

It wasn’t fast and it wasn’t easy, but the race files are now loading in the new Basternae.

Converting area files should be a lot easier since they have a more consistent format, but we have a lot to convert before we get to that point — class files, for instance, which will be very similar to race files.

Magma MUD Codebase 3.02 Released

During a trip this Thanksgiving I updated the Magma codebase a little. All I really did was fix a few compile errors that have come up in the past seven years due to changes with the C language and compilers — it’s otherwise the same code.

There’s a solution file that builds in Visual Studio 2005 (express or full version) and it also has a makefile that will compile in Ubuntu Linux 6.06.

This is the C code from the Basternae 2 rebuild era, released in 2000.  This is _NOT_ the code I’ve been working on over the past few months.

Why’d I convert it? Boredom mostly. It’s posted on FindMUD in case anyone is interested.

A Likely Host

After spending a while shopping around it looks like I’ve found the place to put a Basternae server when the time comes for on-line testing: Slicehost (http://www.slicehost.com)

Their virtual private server (VPS) hosting starts at $20 a month and is easy to upgrade. I don’t want to spend much since MUDs typically don’t generate any income whatsoever, and Slicehost ought to be a relatively painless way to go.

The head web application programmer here at work uses them and only has good things to say.

Compile Errors Defeated!

There are now no more compile errors.  It took just under 5 months to fix 75,000+ errors, giving me a fix rate of 15,000 per month (500 a day).  Not bad for something I only worked on in my spare time on a “as I feel like it” basis.

After the compile errors were squashed, there were 922 warnings.  It’s a bad idea to ignore warnings because there’s a pretty good chance they’ll just end up as runtime errors.  I went through and squished as many as I could as fast as I could, and the warning total is down to 28.  Those are (mostly) harmless.

Now begins stage 3:  Getting the game to run without errors.

This might be pretty involved, since I wasn’t able to test any of my rewritten code thanks to all those compile errors.  Right now I’m hammering out the glitches in the new network code (and I’ve already fixed a few).

Stage 4: Once I have the codebase in a runnable state I’ll have to convert over all of the area and data files.  You know how I converted everything to save and load XML files?  Well, the old areas aren’t XML yet.  I’ll have to write a converter application to do this.

Stage 5: Debug the whole thing.  Stage 3 debugging is easy since the game doesn’t *DO* anything without areas, mobs, and equipment loaded.  Stage 5 is where every command has to be tested, and it’ll be pretty involved.  This might be where it makes sense to set up a test server so other people can play around with it and help find problems.

Down to Only Six!

I’ve been working on the code the whole day.  The compile error count is now down to 6.

The trouble is that each of these six remaining errors will be extremely painful to fix.

< 300

The compile error count is now 297, with gains mainly due to date and time function rewrites.

Even though there were a lot of changes involved in the conversion, dealing with a System.TimeSpan and a System.DateTime is far more pleasant than the ugly and annoying integer math involved in C-style dates.  To get the number of hours that have passed with a C date, you have to do something like:

hours = time / (60 * 60 * 24); // assuming time is an integer time value in seconds.

With a System.DateTime you just do:

hours = time.TotalHours(); // assuming time is a TimeSpan.

I’d much rather deal with a class that has built-in date and time conversion logic — I hate manually converting, even if seconds-per-minute, minutes-per-hour, and hours-per day are well-known constants.

Under 500

The compile error count is now down to 486.

Most of the network communications code has been rewritten.  TCP/IP programming in C# is much like it is in C, but WAAAAY smoother — none of those ridiculous sizeof(sockaddr_in) parameters, etc.

Today’s Code

Most of today’s coding involved rewriting string functions.

The error count is now down to 834, with every gain a battle.

Should I learn C first? Or C++?

Every once in a while, a non-programmer interested in game programming will ask me where they should start learning. They’ll usually know that most modern programming languages are derived from or related to C and that most games are developed in C++, so the first question I hear will usually be:

Should I learn C first? Or C++?

My answer is: neither. I recommend learning C# first.

There are so many bad habits and terrible practices you can develop by starting with C or C++ first that it’s a bad road to go down. By starting with C# first you’ll be forced to learn how to develop object-oriented code instead of being able to mix an ugly blend of procedural and object code with no method to the madness.

The transition from C to C++ can be very easy — almost any code written in C will run unmodified in C++, with the biggest danger being that you might have used reserved keywords as variable names.

That’s very dangerous.

In C++ there are a lot of things that can be done that just shouldn’t be — especially global variables and constants, un-encapsulated data and procedural code, etc. The C++ compiler doesn’t care how badly-written your code is as long as you follow proper syntax. Some people spend years trying to “unlearn” C programming once they transition to C++. I know I had a hard time with it, and entire books have been written on the subject.

Instead, if you eventually end up making the transition from C# to C++, you’ll already be used to the idea of being able to use library functions and be less-inclined to “roll your own” version of things when you can find a library to take care of it for you. This will result in faster development — after all, it’s often far easier to plug something in or look up what’s available in the standard library than it is to write and debug new code, which C trains a programmer to do more often. Remember: an architect doesn’t reinvent the nail every time he designs a house.

Some other reasons to learn C# first:

  • C# is also good as a first language because it’s a very easy to make a transition to Java. Some people refer to C# as a “child of C++ and Java”.
  • With Microsoft’s Silverlight (designed as a Flash-killer), C# is also becoming more relevant for developing web-based games.
  • Every person I know that has tried to learn programming and given up has died at the same point: pointers. With C# you don’t have such a mind-boggling mess of things and are far less likely to have weird pointer-based crashes and glitches. You never have to learn the abstract insanity that is pointer arithmetic and memory manipulation. (void ** pointers still make me wake up screaming sometimes.

Under 1,000

I spent pretty much the whole day working on the codebase.  Every error clobbered is becoming a pretty hard-fought battle.  Even so, I seem to be winning.  Of course, after the errors are done, that doesn’t mean the work is over — far from it.

The error count is now down to 949.

.Net XML Serialization

Most of the saving and loading of MUD data in Basterne 2 was handled by low-level C functions that used a custom text file format for each data type. That is just a bad idea.

Save and load functions were typically dozens or hundreds of lines of code with lots of room for error and data loss. If a word was off by one space or a character was miscapitalized, a file load would fail and nothing could be done. Players of Basternae 2 probably remember pfile corruption issues with anything but fondness.

Every time we changed a file format by adding another value to an object, we had to build a translator that would convert the old file to the new version. Usually this wasn’t too hard, but it did result in a LOT of extra code lying around where it didn’t belong.

.Net makes this a lot better by giving us XML serialization.

With XML serialization, data is dumped out in a neat little XML file that can be read not only by our MUD server, but by just about anything that can read XML, which these days is just about every application in existence. Gone are the days of low-level custom file formats and painful data corruption issues (I hope).

So, how do we do it?

For example, I just rewrote the saving and loading of fraglists to use XML serialization. The code started as 174 lines of custom textfile saving and loading with lots of recursive looping to save and read the arrays containing numbers on the frag list by race and class.

Now the code looks like:

public void Load()
{
XmlSerializer serializer = new XmlSerializer( this.GetType() );
Stream stream = new FileStream( Database.SYSTEM_DIR + Database.FRAG_FILE, FileMode.Open,
FileAccess.Read, FileShare.None );
fraglist = (frag_data)serializer.Deserialize(stream);
stream.Close();
}

public void Save()
{
XmlSerializer serializer = new XmlSerializer( this.GetType() );
Stream stream = new FileStream( Database.SYSTEM_DIR + Database.FRAG_FILE, FileMode.Create,
FileAccess.Write, FileShare.None );
serializer.Serialize( stream, this );
stream.Close();
}

Cleaner and better, just the way we like it. I still hate the way WordPress formats source code.

The compile error count is now down to 1,649.

Under 2,000

The compile error count is now down to 1,900. It feels like there will be a running codebase relatively soon.

Shiny New Logs

Today I replaced the old-school C-style logging routines with new C# code based on the System.Diagnostics.TraceListener class.  That may not mean much to you, but trust me — logging is way better now.

The compile error count is now down to 2,205.

Random Numbers

I finally got around to replacing the old outmoded random number generator that the MUD has been using for ages. It’s the Mitchell-Moore algorithm and is present in just about every free codebase.

I ended up building a class that lets you select one of three random number generators to run the MUD engine on.

The first is the plain-old slow, ineffecient, and repetitive .NET random number generator.

The second is the R250/521 shift-register sequence generator. There’s a paper on it here:
http://www.informs-cs.org/wsc97papers/0127.PDF

The third is the Mersenne Twister, a fairly new algorithm by Matsumora and Nishimura. More information is available here:
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html

The neat thing about how I’ve set up the random number system is that new algorithms can be dropped in easily. I’m sure there won’t be much cause to change random number generators, but it’s a pretty easy option if we feel like it.

We’re now down to 2,591 compiler errors.

More Progress

The compile error count is now down to 2,654.

I’ve also added a codebase section to FindMUD since it seems that codebase downloads are getting harder and harder to track down these days.  There are only a handful posted, but I expect that the list will grow as the site evolves.

Under 3,000

The compile error count is now down to 2,779.

Some of the remaining code rewrites remaining are pretty significant:

  • Telnet/Network Code.
  • Data File Saving/Loading (I’m seriously considering rewriting data storage as database-based rather than XML-based).
  • Low-level string processing routines.

If you think about it, those three things are all you need to build a MUD (well, that and a command interpreter). Even though progress has been good lately, there are a couple whole-weekend projects coming up. With me house shopping and the holiday season creeping up I couldn’t possibly imagine having a running server before the new year.