Category Archives: Programming

Building software.

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.

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.

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.