Author Archives: xangis

Pex, Glorious Pex

Back when I was programming C++, I worked with a great test tool: Parasoft C++ Test. It was great for auto-generating unit tests, which in my opinion is the best place to start. Even if they need to be modified by a Human to get proper coverage and real-world test results, the ability to generate tests that automatically check for things like NULLs and ridiculous value ranges is a good start to build from.

Even better is the savings in time. Manually typing out all of the tags, code, and various other “boilerplate” pieces is a pain. With automated test generation, all you have to do is go in afterward and add rows for the tests you want to run.

This is especially helpful for larger projects (more than 100K lines of code), such as Basternae.

After creating a test project, I told Visual Studio 2008 to auto-generate tests for me. It took about twenty minutes with the processor thinking at full speed. I can’t imagine how long it would have taken a human, but since the Human brain functions at about 300Hz it would have taken a mighty long while.

After auto-generating 1,966 tests, I decided to run them. It got just over a quarter of the way through with *LOTS* of failures (approximately none of this new code has ever been tested) and Visual Studio crashed.

One Visual Studio restart later and I was running tests again, with a massive amount of failures.

In the “CharData” class alone, 212 tests were generated and 199 of them threw exceptions on the first run. The rest were “Inconclusive”, which is the default result for auto-generated tests.

Already, Mr. Pex has made it obvious that the application has some architectural flaws, chief among which is the random number generator. The generator lives in an instance of the “SystemData” class when it should be in the “RandomNumber” class, which should be a singleton. When running without the controlled startup environment of the entire codebase, things break horribly. That’s one of the things a test framework is supposed to point out, right?

While automated test generation is not all-inclusive, Pex is extremely helpful for getting to the point where your tests are at least “Inconclusive” and ready to edit by a Human. If you get exceptions without even getting that far, you have some work to do (as I have).

I have seen no better tool for getting a quick and easy start on unit testing. Writing meaningful tests? Well, that’s something you have to figure out on your own, but at least the boilerplate is done for you.

Here’s where you can get more info on Pex, including a video demonstration:

http://research.microsoft.com/en-us/projects/Pex/

It is worth noting that this Pex is extremely beta. Every time I run it, I get the “VSTestHost.exe has stopped working” dialog box. Even with that, all of the tests do manage to run.

Continuing Spell Migration

When we last saw our hero, he was working on migrating spells from being hard-coded in 15 different places to being individual XML data files that are loaded at boot time.

While this makes it easy to modify, enable, disable, rename, or adjust spells without a recompile, the main reason I’m doing so is because there’s just so dang much clutter in the codebase with spell info strewn about everywhere. It’s like a pack of wizards exploded in there, I swear.

This will also make it far easier to make minor adjustments for balance. Instead of having to track down a developer to go through many slow tweak-recompile-reboot cycles just to adjust spell damage, the “balance engineer” will be able to work independently. In the future it may be possible to perform online editing of spell attributes without a reload. This is obviously not something that everyone should be allowed to do.

Part of the migration will be to move most of the actual function code into the spell files. Most spells are pretty generic in nature — add an affect (flight, strength, poison) or affect hitpoints in some way (fireball, heal). Even so, the same ~10 lines of code are duplicated for pretty much every spell with only the name changed.

Making the spells somewhat independent of the game engine also makes the engine less “tied” to Basternae. At some point I’d like to create a space-based MUD using the same code, and the spells would obviously be dead weight.

On Hold For Now

As you can probably tell, there hasn’t been any real activity here for a while.

I really enjoy working on Basternae code, but there’s no money in it, so for now it’ll be on hold while I work on more lucrative projects.

Don’t worry, I’ll return to B3 at some point…

Cheers,
Xangis

Magma MUD 3.04 Released!

I’ve made a minor update to the Magma codebase. Here’s what’s changed:

1. Added support for loading 4 of the 5 remaining Envy 2.2 zones that wouldn’t load.
2. Bundled the MakeZonesFast32 and DikuEdit 3.10 zone editors in the MUD package.
3. Added DOS conversion utilities for assembling DikuEdit zones (makezone.bat).

MagmaMUD 3.04 is available for download at FindMUD.

Resharper 4.0

Last year I tried the Resharper 3 plugin for Visual Studio, and posted my thoughts on it:

http://basternae.org/blog/2007/07/26/jetbrains-resharper/

It was OK, but not all that special. It had potential, but wasn’t quite “there” yet.

I just finished trying out Resharper 4.0 and you could paste the Resharper 3.0 review in its place. It’s neat, but not so neat that it’s a ‘must have’ utility. The features added in the latest version really aren’t anything I find useful — I don’t refactor Visual Basic, don’t use LINQ, etc.

It does, however, appear to run a little faster than version 3. That might just be the system I’m using it with, but the slowness is no longer an annoyance.

I’ll keep my eye on it. Maybe they’ll add something I can’t live without in a later version.

A Re-Preview Of The Editor

Yesterday I said the area format wasn’t likely to change. That was before I finished the code-data separation.

BasternaeEditorPreview2.zip

The same warnings from preview version 1 still applies.

First Zone Editor Preview Version

Here’s the first view of the Basternae Zone Editor available for download:

BasternaeEditorPreview1.zip (download removed, see the post about preview version 2)

Some warnings:

1. This is a pre-release version and it’s entirely likely that it will be unstable and lacking in features.
2. It has no help files.
3. It has no icons for the edit window buttons — just colors. You have to guess what they do.
4. The map edit and walkthrough edit modes are not done yet (and haven’t been started yet either).
5. Save your work often and keep backup copies.

This is just to download, play around with a bit, and get a feel for. I don’t expect that the area file format will change in a way that will break zones created with this editor, so you can actually start trying to use it to build something.

Check it out, see if it’s usable, and feel free to make requests, bug reports, or just say what would make you more likely to want to use the tool to create a zone for the new Basternae.

Rewiring The Core

In the process or getting an alpha version of the editor ready I’ve found that I had to separate the game code, a.k.a. “business logic” from the data, a.k.a. “object model”. Otherwise I’d have to include the entire MUD engine in the editor download. Since that’s not something I want to do I’ve had to pull them apart. It’s a lot like pulling apart a cold grilled cheese sandwich, and as expected, the bread did tear a little.

The “core rewire” still needs some work, but I should have an “alpha”, a.k.a. “try it and see how broken it is or isn’t” version of the zone editor out sometime this month.

A Review of Duris

The MUD Connector has an interesting review of Duris posted:

http://www.mudconnect.com/mud-bin/new_prev/review.cgi?rid=25705

I’ve always enjoyed Duris and still play it off and on (maybe half a dozen weeks a year), but it has always had so many flaws that I end up getting fed up and walking away after a while. Part of it is administrative, sure, but a lot of the problems are core game design — at the core it’s an excellent MUD, but so much of it is an unnecessarily frustrating mess that it doesn’t really have much longevity for me. I think it comes from the original philosophy of the design — the creators really didn’t differentiate between “difficult” and “irritating”.

For example (and I’m mainly referring to Duris from a few years ago because that’s what I know best):

Randomly killed by random-spawn unpredictable scan-track mobs in the underdark for no logical reason, or = annoying.

Instantly killed because you were attacked by a drunk orc when you try to leave the inn in your hometown and since you’re level 1, assisting guards one-shot you (and your class doesn’t have sneak) = annoying.

Getting killed in artifact-wielding players in low-level zones and having your corpse looted of spellbooks/totems that you are too poor to replace because you’rer a newbie = annoying.

Player-wiping because you want to refresh the player base, purge an overabundance of equipment, or replace the world maps, or cover up the fact that the game mechanics still need some work = annoying.

Needing to use your head to come up with a strategy to defeat mobs, complete a zone, or accomplish a task = difficult.

Being forced to rely on your wits and diligently reading room descriptions to solve quests or puzzles = difficult.

Optimizing your equipment and stat bonuses based on how you want to perform in combat and doing so by real combat experience rather than reading the source code = difficult.

Somehow they seem to think that and difficult are both beneficial. Difficult makes players keep playing because things aren’t too easy. Annoying makes them log in to WoW.

I still find it incredibly amusing that I was more-or-less programming for Duris during the 2000-2001 “arms race” with Basternae 2 — every time I added a feature or convenience command that was neat but didn’t affect game balance it would show up on Duris a week later.

Even so, I can’t really say I have anything against any of the admins of Duris. After all, I’ve never even met any of them (except Xyzom from old Duris, who I actually lived with for a while and worked on Illustrium Arcana with — nice enough fella but we haven’t kept in touch). All I can do is judge by their product, Duris: Land of Bloodlust, which needs some work.

Serious Shrinkage

The connection state management code in the socket layer of Basternae has always been what I call “spaghetti code”. It was a single method containing a huge switch statement with pretty sizable blocks of code for each case. Tracing program flow for characters that were not actively playing was always difficult due to the complexity and verbosity of this 1600-line function.

Today I refactored it into a bunch of more sensible pieces that go together a lot more smoothly. The 1600-line function is now 80 lines, I can actually tell what’s going on during program execution, and a handful of confusing and unused variables have been eliminated. Huzzah!

Zones From Lortar

Lortar has been kind enough to grant permission to use his zones from Basternae 2:

Fairlocke
The Elemental Plane of Air
Tower of Darkness

Unit Testing With MbUnit

In general either code works or it doesn’t and it’s easy to tell whether it does or doesn’t work. At least until you reach a certain level of complexity. At some point a project gets large enough that you can’t tell which project/dll your error is coming from, let alone which of the 100K or even 50M lines of code is doing naughty things.

Today I had a problem that was easier to solve by creating unit tests to point out where the flaw was. The tool uset? MbUnit.

Here’s an example of an MbUnit test I wrote in order to find a string processing bug:

using System; using System.Collections.Generic; using System.Text; using MbUnit.Framework; namespace UnitTests { [TestFixture] public class MUDStringTests { [RowTest] [Row(12, "12.box", "box")] [Row(1, "cheese", "cheese")] [Row(1, "1.pie", "pie")] [Row(1, ".chicken", "chicken")] public void NumberArgument(int expectedValue, string inputString, string expectedOutput) { string str = String.Empty; Assert.AreEqual(expectedValue, BasternaeMud.MUDString.NumberArgument(inputString, ref str)); Assert.AreEqual(expectedOutput, str); } } }

What this does is check whether we’re getting the expected output when we give a certain piece of input. It’s handy for detecting anomalies without having to boot up the server and/or mess with production code. Mind you, there’s no such thing as ‘production code’ since we don’t have a server up yet, but this sort of thing is likely to be handy in the future.

I’m not the type that has any chance of turning into a ‘write the unit tests first’ and ‘unit tests are more important than code’ evangelistic freak, but in most cases it is far easier than using trial-and-error to track down a bug.

I still hate the way WordPress formats my code.

Miscellaneous Fixes

I made a few changes to character creation today. There were a few places where it was case-sensitive — you could create a “Troll” but not a “troll” and there were a few weird state changes. For instance, when creating a character you would see the menu twice the first time it was displayed.

I also fixed a few immortal commands that will make it easier to create immortals and set command permissions for their abilities.

The say, emote, whisper, yell, shout, ask, and immtalk commands were broken (all messages came across blank), and are now fixed.

Issue Code Is Working

I finished testing the issue code today. We now have a functional ‘help desk database’ for the MUD. It’s primitive, but it should do the trick and can be expanded/changed as necessary. At least we’ve eliminated the bug, idea, typo, and ‘helps needed’ files that admins would rarely, if ever, look at. Here’s an example of usage:

< > issue update 2 This is a test issue.
Issue 2 updated with text This is a test issue.

< > issue close 2 Testing the issue entry system.
Issue 2 closed with resolution Testing the issue entry system.

< > issue show 2
Issue Number: 2   Priority: high   Type: helpentryrequest
Is Closed: True   Opened by Imm: True   In Room: 0
Created by: Xangis   Time: 7/6/2008 11:14 AM   Text:
disarm
Entered by: Xangis   Time: 7/6/2008 11:32 AM   Text:
this
Entered by: Xangis   Time: 7/6/2008 11:36 AM   Text:
This is a test issue.
Closed by: Xangis   Time: 7/6/2008 11:37 AM   Text:
Testing the issue entry system.

< > requesthelp disarm
Help entry request recorded. Thank you.

< > issue list
Issues:
[3] (lowest) Help Request: disarm
[4] (lowest) Help Request: issue
[5] (lowest) Help Request: ignore

< > Issue Number: 3   Priority: lowest   Type: helpentryrequest
Is Closed: False   Opened by Imm: True   In Room: 0
Created by: Xangis   Time: 7/6/2008 11:25 AM   Text:
Help Request: disarm

< > issue priority 3 lowest
Issue 3 priority set to lowest.

Basternae Zone Contract

I’ve put together a simple “zone permission contract” here:
http://www.basternae.org/BasternaeZoneContract.pdf

It’s probably not necessary, but while I was publishing my science fiction magazine I found it to be a good idea to get everything in “official” writing.

If you have written any zones you’d like to let us use or know someone who has, this can be sent either to my xangis at yahoo mail account or to the following mailing address:

Jason Champion
Zeta Centauri, Inc.
1388 Clydesdale Ave.
Columbus, OH 43229

TODO List Added

I’ve added a to-do list under the ‘Pages’ section. It’s not quite complete and the formatting isn’t all that great, but it might be a useful way to keep track of what needs to be done. At the very least it’ll give readers some idea what I’m working on.

So far I’ve been using simple “todo.txt” files in each of my Visual Studio projects, but that keeps them from being all in one place and is a bit disorganized.

An Upgrade (For Me)

It’s been a busy week at work — just got myself a promotion and haven’t had a chance to work on the MUD as much as I’d like (more tired in the evenings than out of time, really). Most of this week’s effort has been directed toward the editor.

I’m wondering whether it would be a better idea to release a prototype of the editor to get ideas and suggestions or wait until it’s pretty much useable before releasing it. It’s probably a difference of about 4 weeks in time/effort.

Removing Items From A Container In A Foreach Loop

It wouldn’t have been unrealistic for the designers of .NET to find a way to make this work:

foreach( Item i in ItemList )
{
  if( i.ShouldBeRemoved )
  {
    ItemList.Remove(i);
  }
}

What happens is you get a ‘collection modified’ exception and you’re hosed. You can’t move to the next item in the list because removing the item broke the list. It wouldn’t have been that hard for the design of IEnumerable (the thingy that makes foreach possible) to keep track of where the next item was even after a removal.

Instead of being able to use the above code, something like this clunky bit is required:

for( int i = (ItemList.Count – 1); i >= 0; i– )
{
  if( i.ShouldBeRemoved )
  {
    ItemList.Remove(i);
  }
}

It’s like telling someone they can avoid head-on car collisions by always driving in reverse.

Anyhow, there was a bit of a problem with the Select() command and socket management, and this was the solution. The socket code is now functional and stable enough that I can log in and run around trying to play the game. It’s not terribly playable yet — I have a *LOT* more work to do, but it’s still theoretically possible that a development server could go up i mid-but-more-likely-late May.

Sorting The Easy Way in C#

If you have a list of objects, say List<Widget> it’s mighty easy to to sort them using .NET.

First, derive the Widget class from IComparable:

public class Widget : IComparable

Then create the CompareTo method. In this case, we’re sorting the list of Widgets by name:

public int CompareTo(object obj)
{
if( !(obj is SynthProfile ))
{
return 0; // We could throw an exception here if we wanted to.
}
return this.Name.CompareTo(((SynthProfile)obj).Name);
}

Once that’s done all you have to do is call:

WidgetList.Sort();

Easy.

Xangis.com

Software and Music Mad Scientist