Basternae.org

I just checked Alexa stats for FindMUD.com.  Although Alexa isn’t exactly the full measure of the web since only a small percentage of people have the plugin installed, here are the MUD sites that FindMUD outranks:

mudmagic.com
mudbytes.net
mudlists.com
mudmaker.com
ftpgame.org
dikumud.com
mudlist.betterbox.net
dune.net
envy.com
silverden.com

It’s a respectable list, but we are far from surpassing the 800-pound-gorilla of MUD sites, the MUD Connector.  I don’t expect that to happen, but I do hope to get into the top three at some point (the other two being topmudsites.com and mud.de.)

Of course, FindMUD needs a lot more work that won’t happen in a single day, but I am gradually improving the site.  Just today we posted our own version of the MUD timeline.

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.

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.