Monthly Archives: November 2007

Fixing Communication Routines

So I ran into a few glitches and buffer problems in the communication routines. I rewrote a few functions, simplifying them in the process, and things are a lot smoother now. At the very least they should be more stable than communications on Basternae 2.

The character creation process has a handful of glitches to work out. I’ll probably do that before I take on area loading, which will be the largest of the data format conversion projects.

It Runs On Linux!

The original intent from the beginning was to make the C# version of Basternae run on both Windows and Linux, giving me more flexibility in choosing hosting. I figured it’d be a week or two of coding workarounds when it finally came time to do the porting.

I loaded the code on an Ubuntu 7.10 laptop and told it to build.

Of the 100,000 lines of code here’s how many errors were found:

Five.

Every one of these errors was an implicit type conversion that Visual Studio didn’t complain about but the Mono compiler did. Five type casts later and it builds on Linux.

Under an hour to port a 100,000 line application to another operating system. C# rules.

The Joy of the Flags Enumeration

In the old days of MUDs it became a rather common occurrence to use each bit of a 32-bit integer as a binary flag to set or unset a value. This was far more efficient than using an array of 32 boolean values because the integer consumed 4 bytes, while an array of 32 booleans consumed anywhere from 32 to 128 bytes, depending on the system architecture.

This helped to save a great deal of storage space and memory, which was incredibly important given the machines of 1991 or so: a 33MHz 80486 processor with 16 megabytes of RAM was pretty typical.

Even with systems a lot cheaper and a lot faster now, the amount of RAM and processor time you use is still a pretty big determinant of the type of hosting plan you will need to purchase. Saving RAM is still a good idea.

Take, for instance, the “system flags”. It’s a group of flags that control certain things about the game, such as whether equipment wears out in combat and whether mobs are limited in the number of spells they can cast in battle. Stored in the new XML format as an integer, a typical value is:

<_actFlags>8256</_actFlags>

That’s not very descriptive.

We can make it a little more descriptive by using an enum tagged with the FlagsAttribute. Here’s how we implement it:

[Flags]
public enum MudFlags
{
none = 0,
turbolevel = 1,
equipmentdamage = 2,
mobcastslots = 4,
mobslootplayers = 8,
autoprice = 16,
walkableocean = 32,
nameapproval = 64
}

In our system data class we have a variable that is a MudFlags type.

As with an enumerated value, this type uses the flag names for serialization and deserialization. Now we can see what things are turned on with a quick glance at the system data file:

<_actFlags>equipmentdamage autoprice</_actFlags>

So, equipment damage and automatic pricing is turned on.

This is also handy for displaying what flags are set — we can just use the ToString() method of the MudFlags type to get more info.

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.