Category Archives: Areas/Zones

Zone Reset Modes

In  the old days of Basternae 2, there were really only two area reset (repopulation) modes — either an area would repop at a fixed interval, or the area wouldn’t reset until all players had left.

In the process of rewriting the way areas reset themselves for the new game engine, I’ve added a few more reset types that might make for some fun zones:

  • Empty of Mobiles:  The zone won’t reset until every monster in the zone has been killed.
  • Empty of Objects:  The zone won’t reset until every takeable object has been removed from the zone.
  • All Quests Completed:  The zone won’t reset until all quests inside the zone have been completed.

The way things are done it’ll be pretty easy to add new conditions if the theme of the zone requires it.

Real Progress on the Editor

Now that I’ve started trying to use the zone editor I’m finding all sorts of things to fix and/or improve.  I’m not sure how long it’ll be before I can get a small zone put together using it, but it’s getting quite close to usable.  Far from pretty, but usable.

A Help Entry Editor

Editing help file entries has always been a pain, mainly because it’s always been a huge unorganized text file that has to be edited by hand.

I spent about an hour and a half building a simple help file editing application today. It will load/save help files, allow searching and browsing of entries, and of course, editing.

It’s nothing fancy, but it does make the task of editing help entries a little easier. It doesn’t have visualization for colorized help screens, but that would be easy enough to add.

Here’s a looksee:

Help Editor Screenshot

(Click the image for a full view).

Improving The Zone Editor

Over the past couple days I’ve done quite a bit of work on the mob and object editing screens in the editor.  I also found and fixed a few problems with the area converter.

The hard part of building the zone editor is going to be adding the map-based and walkthrough visualization modes.  They aren’t needed for building an area, but they will help quite a bit with visualization and layout.  I haven’t put much thought into how I’m going to go about implementing those features, but it’s something I can worry about a bit later, once I have the zone editor fully functional (which shouldn’t be too much longer).

Smashin’ More Bugs

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.

An ANSI Screen Editor

One of the things that was always a pain in the butt was creating and editing the ANSI color screens for the MUD intro, race and class selection screens, and the menu. With our new screen format it was actually pretty easy to build an editor specifically for Basternae screens. I spent a few hours today and here’s what I came up with:

MUD Screen Editor screenshot

(click for full image)

It’s nothing spectacular, but it does make the task of editing MUD screens a little easier. Since applications like TheDraw and ACIDDraw have been just about completely lost to the sands of time (and they were DOS apps anyway — yuk!), it’s hard to find an ANSI screen editor that will run in Windows these days (this runs on Vista and XP).

With the built-in “import” and “export” options it can actually be used to edit any ANSI screen. It only does foreground text colors, but it should do for now. I expect I’ll release it as freeware soonish since other MUD admins might find it useful even though the file format is specific to Basternae.

UPDATE: Yep, released it here: http://findmud.com/mud-screen-editor

A Few Fixes

I found and fixed a few minor bugs in the core MUD engine today.  I also found and destroyed some duplicate code and unused functions.

I’m not sure, but I think about May might be a good time to put a server up.  It’d just be for development until the game was in a playable state (read: had enough zones to make it worth playing).

A Bit More On The Editor

I spent a while working on the zone editor again today, and the quest editing section is complete.  Even though the version numbers I’m using are completely arbitrary, the editor is now at version 0.14.

Flag Editing in the Zone Editor

There’s a ton of things in the MUD engine that use flags. Rather than go through and create a separate dialog box to edit each batch of flags, I’ve come up with a way that just lets me tell the flag editor dialog what type of flags it’s using and it will fetch them and populate itself. That means it only takes a few lines of code to be able to edit the flags on a mob/object/room/shop/exit/etc.

Here’s an example:

private void btnEditExtraFlags_Click( object sender, EventArgs e )
{
int value = 0;
bool parsed = Int32.TryParse( txtExtraFlags.Text, out value );
FlagEditor editor = new FlagEditor( FlagType.item_flags, value, 0 );
DialogResult result = editor.ShowDialog();
if( result == DialogResult.OK )
{
txtExtraFlags.Text = editor.Value.ToString();
}
}

This means that something that would have been an entire class (probably >150 lines of code for each set of flags) is now reduced to <10 lines of code per item.

Here’s the resulting dialog:

Flag Editor Screenshot

There’s a fair amount of behind-the-scenes code, but it’s still pretty easy and efficient.  With this change I’m pretty far along on the zone editor.  Sometime in early March I hope to be able to create a working mini-zone with it.  After I declare it usable I’ll make it available for download.

An Inelegantly Elegant Solution

One problem I’ve had to solve in building the Basternae zone editor is the conversion of Basternae-style colorized strings into something that will display properly in a GUI.

Apparently text boxes aren’t smart enough to decipher Basternae-style text color codes (&+R, &n, &+y, etc.). In fact, there’s only really one control in the standard .NET forms library that supports multcolored text — the RichTextBox.

In order to use this RichTextBox, I’ve had to write a routine to convert all of the Basternae color strings into RTF format. Here’s the code:

public static void BuildRTFString(string text, RichTextBox target)
{
// Add header and build color table.
string rtfHeader = “{\\rtf\\ansi{\\colortbl\\red192\\green192\\blue192;\\red0\\green0\\blue0;
\\red0\\green0\\blue255;\\red0\\green255\\blue255;\\red0\\green255\\blue0;
\\red255\\green0\\blue255;\\red255\\green0\\blue0;\\red255\\green255\\blue0;
\\red255\\green255\\blue255;\\red0\\green0\\blue128;\\red0\\green128\\blue128;
\\red0\\green128\\blue0;\\red128\\green0\\blue128;\\red128\\green0\blue0;
\\red128\\green128\\blue0;\\red128\\green128\\blue128;\\red192\\green192\\blue192;
}\\cf0 “;
// Replace each color one by one.
string parsedText = text.Replace(“&+l”, “\\cf1 “);
parsedText = parsedText.Replace(“&+B”, “\\cf2 “);
parsedText = parsedText.Replace(“&+C”, “\\cf3 “);
parsedText = parsedText.Replace(“&+G”, “\\cf4 “);
parsedText = parsedText.Replace(“&+M”, “\\cf5 “);
parsedText = parsedText.Replace(“&+R”, “\\cf6 “);
parsedText = parsedText.Replace(“&+Y”, “\\cf7 “);
parsedText = parsedText.Replace(“&+W”, “\\cf8 “);
parsedText = parsedText.Replace(“&+b”, “\\cf9 “);
parsedText = parsedText.Replace(“&+c”, “\\cf10 “);
parsedText = parsedText.Replace(“&+g”, “\\cf11 “);
parsedText = parsedText.Replace(“&+m”, “\\cf12 “);
parsedText = parsedText.Replace(“&+r”, “\\cf13 “);
parsedText = parsedText.Replace(“&+y”, “\\cf14 “);
parsedText = parsedText.Replace(“&+L”, “\\cf15 “);
parsedText = parsedText.Replace(“&+w”, “\\cf16 “);
parsedText = parsedText.Replace(“&n”, “\\cf16 “);
parsedText = parsedText.Replace(“&N”, “\\cf16 “);
target.Rtf = rtfHeader + parsedText + “}”;
}

The inelegant part? It builds a big, ugly string in realtime. Yes, we’re essentially building an RTF document by hand.

The elegant part? All I’ve had to do is wire up the text changed event to any part of a mob, object, or room that supports color codes. All that mess above lets us use the following code:

private void txtDescription_TextChanged( object sender, EventArgs e )
{
Form1.BuildRTFString( txtDescription.Text, rtbDescription );
}

Yes, we can wire up any text box with a realtime colorized visualizer in a single line of code. Every character we type is shown as it would appear on the mud as we type it. Even with all the string replacement calls, it’s fast enough that there is no noticeable lag at all.

Here’s a screenshot of what it looks like (visualizer windows have a black background):

Screenshot of Basternae Mob Editor

I still hate the way WordPress formats my source code.

First Post From The New House

The computer’s plugged in, the internet access is turned on, my desk is half-assembled… almost fully moved in.

Over the past week or two the zone editor has been improved and is in a state I refer to as “version 0.06”.  It still has a long way to go, but it’s coming along.

Progress will still be slow until around mid-February as I get this place into a more liveable state.

Even More Progress On The Zone Editor

The latest update, which I call “version 0.03”, now has a ‘cancel’ button on each editing screen so you can revert to the original room/object/mob/whatever if you screw something up.  Saving changes to edited objects is a fairly large revision, and so far the only things you can make permanent changes to are resets.

More Progress On The Zone Editor

I’ve built out most of the editing screens in the zone editor to the point where you can at least load a zone and browse it.  Not every field is represented and nothing can be edited yet, but it’s one large step closer to being able to create zones (I call it version 0.02).  No screenshots, since I’m away from the computer with the code on it at the moment.

I’m also in the process of fixing up and moving into the house I bought a little while back, so I can’t really devote too much energy to the code at the moment.

Starting On A Zone Editor

I mentioned a while back that I would need to write a zone editor for Basternae 3. Although zones edited with DikuEdit 3.0x will load in the MUD engine after running them through the converter application, DE won’t be updated to work directly with the Basternae 3 area format — it’s an old DOS app and there’s far too much effort involved in adding XML support to it.

I’ve started building a .NET version of the area editor. The intention is to make it run on both Windows and Linux.

Here’s a super-early screenshot of the development, which I call “version 0.01”:

It doesn’t do much yet, just save and load areas, show the stats of a loaded area, and list the names of mobs/objects/rooms. One of the biggest roadblocks to creating an offline editor in the Basternae 2 days was the saving and loading of zones. Now we just link to the MUD codebase as a library and call Area.Load(“filename.xml”) and it’s loaded. Saving is just as easy — Area.Save();

Most of the work will be in actually building out the screens where you can set values on things, but the fact that it loads and saves zones goes a VERY LONG way toward getting things going.  It’ll get a lot prettier and more useful with time.

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.