Yearly Archives: 2007

Rebuilding An Engine

Most of the work done over the past few days has been boring, grueling engine rewrite stuff.  There’s not much exciting that can be said about reorganizing variables, changing the way that lists are processed, and cleaning up object reference handling.  It’s a lot of code rewriting that will have little or no visible effect on the way the game is played.  It will, however, make it far easier to add to and update the code with our planned changes.

Got The Dotcom

It seems that the domain Basternae.com recently became available.  I bought it, so both basternae.org and basternae.com point here.  Yippee!

Magma MUD Codebase 3.03 Released

Over the past month I’ve been playing around with the Magma 3.02 code a bit more. I found a few crash-bugs and fixed them, mostly caused by references to rooms and objects from Basternae 2 that no longer exist.

The big change is that 58 of the 63 original Envy 2.2 zones will load in the engine. This means you can actually run a MUD with the codebase. Nobody wants to play a stock MUD, but at least you can have a functioning game world while all of your new areas are being built.

I’m sure there are still some bugs and/or stability issues, but this release is a big step forward.

Let me reiterate what I said when releasing 3.02: This is _NOT_ the code I’ve been working on for Basternae 3. This is the codebase from early Basternae 2.

It’s posted on FindMUD if you would like to download it. Runs on Linux (tested on Ubuntu) and Windows (tested on XP).

Mud Sound Protocol

Today I added the framework to support the Mud Sound Protocol (MSP). I don’t have any sounds and haven’t added support to the client yet, but when it comes time to add sound it’ll be very easy. I figure I’ll do the sound design myself and/or enlist help from some of my friends over at Darksonus and it’ll turn out quite nicely.

IT App Monitor Robot

This post on The Daily WTF reminds me of the startup script we had for Basternae 2 in the early days:

http://thedailywtf.com/Articles/ITAPPMONROBOT.aspx

Since the codebase would tend to hang or crash, we would have to watch for the process and restart it if it was missing. If the CPU usage was above a certain amount for more than about a minute it also told us that the code was in and endless loop, so the process would have to be killed and restarted. It wasn’t not quite as intricate as the WTF setup, but it was still pretty kludged.

Fixes and More Fixes

I have the client and server running well enough that I’m able to create a character and log in to test all of the available commands. In the first pass, just logging in and typing the command name to see what happens, I’ve found a fixed quite a few glitches. I haven’t fixed all that I’ve found yet, but at least it’s progress.

It finally feels like this is turning into a game again.

Client Progress

Most of the development for the past few days has been on the client application.

Here’s a screenshot giving an idea of what it looks like so far. It’s quite a bit different from what it looked like a few months ago:

Click on the image for a larger version. It obviously needs more work, but I’m liking it so far.

Two More Areas Converted

I had to spend a while improving the Basternae 2 to 3 zone converter, but it’s a LOT better now.  The Thri-Kreen hometown and Kobold hometown are now converted and loading.  There’s still more framework stuff to do, but I should be ready to start acquiring and attaching zones before too much longer.

First Area Converted

Don’t get too excited, it’s not even a real area — it’s what was formerly known as “limbo.are” — the area that contains all of the objects and mobs used by spells, such as the items created with the “minor creation” spell and elementals created with the “summon elemental” spell.

Even so, this means that we have a conversion program that works well enough to convert mobs, objects, rooms and area data. It still needs some work, but is more-or-less usable. In theory we could start adding zones. If we had any.

The next thing I’ll be working on is the character creation process. Some of the changes I made during the rewrite broke it a bit, so I’ll need to spend a solid day reworking it.

A Help Desk?

I’ve written what is essentially an online help desk system for the MUD to keep track of bugs, ideas, and typos. I’m sure it’ll need to be adjusted with use, but at least now the immortals should be better able to keep track of where the problems are and what needs to be done with them.

Fraglist, Crime, and Corpse Files Converted

The fraglist, crime, and corpse data files have been converted.  The crime file conversion required no effort whatsoever since justice doesn’t do anything with it.

Right now I’m working on a scheme to replace the old typo, idea, and bug file concepts, which were pretty useless.  The idea was that anytime a player typed “bug <whatever>”, it would go into a file on disk that could only be accessed from a shell account.  In most cases, the bug, idea, and typo files were completely ignored.  With this new system, immortals should be able to read, fix, and modify any of these issues online.  I’m still working out the details, but it’s looking pretty good so far.

Help File Converted

The help entries have been converted to XML.  Instead of being embedded in the area files and potentially spread across any number of area files, they are all in a file that contains only help entries.  In practice, Basternae 2 only had two area files that contained help entries, but it’s pretty silly not to have them all in one place.  The idea was, I suppose, to be able to have area-specific help sections.  Nobody used it.

I’d like to work out a nice way to be able to switch intro screens.  For instance, if it’s October maybe we’ll want to show a Halloween-y screen and show the regular screen during the rest of the year.  As it is now, the screen file has to be hand-edited and the game restarted in order to change anything.  It would be nice to have a handful of screens that load automatically at boot time and be able to switch between them without restarting the game.  In fact, part of the goal with this incarnation of Basternae is to never actually need to reboot for any reason (providing the game is stable enough to never crash, and that’s one goal I’m aiming for).

Socials Converted

The socials file, a text file containing 127 KB of text for the social actions in the MUD, has been converted to the new XML format. The help entry file is next.

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.