Basternae.org

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.

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.

Class files have been converted to XML.  It was a lot less work than the race files.

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.

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.

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.

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.

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.

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.

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.