Basternae.org

Command processing in the old Basternae was pretty klunky. The command interpreter would just pass on any text that was entered and each command function would have to do a lot of parsing to split up the command strings and figure out what the user actually intended. About half of each command would be devoted just to breaking up strings in some cases.

Luckily with .Net we have all these nice string functions — Split, Join, Substring, IndexOf, Remove, and many more.

With the new command processing engine I’ve just written the command functions are a lot easier to read, maintain, and create more of.

Of course, I’ve had to redo every command in the process and that’s only 80% done so far, but it’s a far better system overall.

And, of course, I still have to finish the replacement spell system.

I came across this article on Scripting with C#.

Quick summary: It tells how to load and compile C# code from within a running application so that you can dynamically load scripts.

This is something I’ve been meaning to find out how to do for a while. I’ve always wanted to create a file-based spell system that loads and compiles all spells at boot time so that they aren’t so tightly integrated into the engine. As it was historically, if you removed a single hardcoded spell, such as “armor”, the entire mud would crash or at least be very unhappy.

Well, what good are 400+ hardcoded spells going to do you when you use the mud engine for a sci-fi, historical fiction, or contemporary post-apocalyptic setting? None at all. That’s why getting them once-removed from the core is something I wanted to do. Super-long-term there’s not just one MUD coming out of all this effort.

Seriously.

I don’t mean just writing a basic telnet chat server with a few objects and commands you can interact with.  Any amateur programmer can do that.

No, I mean writing a full-featured MUD engine that supports all of the features MUDders have come to expect from a game like Basternae 3.  It’s really dang hard.

I’ve spent hundreds of hours working on this rewrite and it’s still pretty far from done.  The area format is still changing quickly enough that I don’t have a working zone editor I can pass out, and I still have a whole spawn engine to write (for those of you who know MUD internals, it’s more-or-less the Basternae equivalent of “resets”.)  I also have to write some sort of mob-action-scripting engine.

It’ll be worth it when I’m done because I’ll have an engine that has been completely written by me and nobody will be able to say what I can and can’t do with it, but it sure is arduous — it takes a damn long time to write 100,000+ lines of code (as you can see by noting that the B3 blog posts beginning about a year ago).  And I’m no newbie coder — I’ve been writing code for more than 20 years, MUDs for 6-8 years depending on how you count the gaps, and commercial code for 3 years now.

That’s why Basternae 3 isn’t open yet.  I could easily have taken the old zones and code up and just went with that, but that’s not something that supports my long-term plan.  Maybe I’ll mention more about that plan at some point.

A little less than a week ago I mentioned that I had broken the heck out of the codebase.

Well, it’s all back together again.  The MUD engine and the zone converter are as healthy or healthier than they were before, the weather’s nice, and all is well with the world.

In the interest of making sure the MUD can be modified easily well into the future I’ve broken the heck out of the codebase.

Yep.

I’ve been refactoring, rearranging, renaming, and restructuring things so they make a lot more sense. That has inevitably broken a few things, but it will be far easier to add new types, flags, and enumerations in the future — things like adding a new terrain type without breaking existing terrain types or having to recompile the editor and re-convert all of the zones.

Believe me, we had quite a headache with zone file format changes on Basternae 2 and I don’t want to repeat it.

This means that it’ll take a few days before the codebase will build again and I’ll have some work to do on the converter and the editor, but it’ll be worth it.

I’m still looking at putting up a test server in May and so far Slicehost is the most likely candidate. Feel free to offer suggestions. Since it’s out-of-pocket and non-income-producing, my budget isn’t any more than $20 per month (should I be accepting donations for this?)

Now that the communication routines are a lot smoother I’ve been able to test and debug more of the rewritten code.  I fixed a bug in the new command interpreter and one in the string builder today.  I also came up with a better way of handling per-area repop points so it’ll be a lot easier to set up new hometowns with race/class spawn points, especially since I’ve added repop point editing to the zone editor.

One thing that has always been a little annoying is updating/changing the about box every time the program version or date changes. Here’s a neat little way to make it pull the values from the assembly info:

private void aboutToolStripMenuItem_Click(object sender, EventArgs e)
{
Assembly assembly = Assembly.GetExecutingAssembly();
AssemblyCopyrightAttribute copyright =
(AssemblyCopyrightAttribute)AssemblyCopyrightAttribute.GetCustomAttribute(
assembly, typeof( AssemblyCopyrightAttribute ) );
AssemblyTitleAttribute title =
(AssemblyTitleAttribute)AssemblyTitleAttribute.GetCustomAttribute(
assembly, typeof( AssemblyTitleAttribute ) );
System.IO.FileInfo info = new System.IO.FileInfo( assembly.Location );
DateTime date = info.LastWriteTime;

MessageBox.Show(
title.Title +
” version ” +
assembly.GetName().Version.ToString() +
” released ” +
date.ToShortDateString() +
“.\nThis application is ” +
copyright.Copyright +
“\nWritten by Jason Champion (Xangis).\nFor the latest version, visit http://www.basternae.org.”,
“About ” + title.Title );
}

With the following AssemblyInfo:

[assembly: AssemblyTitle("Basternae Editor")]
[assembly: AssemblyCopyright("Copyright © 2006-2008 Zeta Centauri, Inc.")]
[assembly: AssemblyVersion("0.9.0.0")]

We get the following about box:

It’s pretty easy to customize it to grab other assembly attributes once you know how to retrieve them.

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.

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.