Basternae.org

Well, maybe not a *whole* engine quite yet, but certainly two thirds of one.

I’ve generated about 500 little XML files to hold all of the skill and spell data for dynamic runtime loading.  It’s all pretty neat — skills and spells can be tweaked by hand without having to compile any code (though the MUD requires a reboot) and they’re loaded at runtime, stored in a Dictionary type, and accessed based on their names.

There isn’t a single hard-coded spell or skill value in the engine.  Hardcoded values were something that always bothered me.

Another thing I did in this process is embed “logical preference” data in the skill and spell files so that the AI engine can be improved while at the same time removing the need for thousands of lines of “spaghetti code” like in Basternae 2.  You see, each spell and skill check in B2 was hardcoded in a specific order and with a specific percentage chance.  Adding a skill or rearranging mob AI meant editing these in more than one place.

Instead (when the AI code is done), we’ll be able to set a few flags on each spell or skill and it will handle it automatically (unless a specific mob has a personality override file).

Oversimplified example:

Fireball.xml:  Type = offensive, Preference = 65, Likelihood = 40
LightningBolt.xml:  Type = offensive, Preference = 50, Likelihood = 50

This means, essentially, that a mob would have a 40% chance of casting fireball during combat, and if that didn’t go off, it would have a 50% chance of casting lightning bolt.  Changing the way the mob performs in combat is just a simple number tweak.

I have some pretty huge plans for mob AI, but this new spell/skill system goes a long way toward making those plans easy to implement.

I also have yet to embed all necessary custom code in the spell/skill files, but one thing that’ll be done is that most information needed to trigger a spell will be embedded in the file.  Instead of manually writing a dozen lines of the same code for each spell to validate the target, check saving throws, set damage type and amount, send messages, and deliver the affect(s), most spells will use one general-purpose function that checks the spell types and flags and executes the spell’s action.

This means that most standard spells that are just damage or single-affect, like “soulshield” or “fireball” won’t have any embedded code at all.  Instead, only super-involved custom spells like the enchantment spell “earthen smith” will have their own embedded instructions.

Well, that was long-winded.  It had to be — I’ve done a lot and I’m pretty proud of what I’ve accomplished with this.

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.

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).

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.

Class files have been converted to XML.  It was a lot less work than the race files.

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.

It’s done - objects save and load as XML data rather than some ad-hoc text format.  I’m sure there will be a few extra details to work out, but the saving and loading of basic objects works now.  The change cleared up a bug or two that would come up once in a while due to formatting inconsistencies.

I still have to fix the violence update problem that I mentioned on the 1st.  I’ve tried a few minor changes in the hope that the problem would be resolved, but it really does look like a full combat-process rewrite is in order.  The original method is fundamentally flawed, so we need to work out a better way.

I’ve started tackling the conversion of all object saving to XML. Player saving was easy, since players tend to be pretty much the same and have all the same data fields. However, with all the different types of objects, nesting, affects, extra descriptions, etc. objects are a bit more of a project to convert. Objects are also saved in more than one type of file — corpse data file, player files, storage chests, etc.

So far I have them saving to XML the way I want them to. The next step is loading, which will take a good solid afternoon or evening of codework.

I’ve been mulling over the idea of moving data files over to an SQL database rather than XML, since XML is DREADFULLY SLOW. It’s not dreadfully slow on this fast machine, nor will it be on any server that I use, but it could become an issue at some point.

SQL would be a good thing and a bad thing. I’d get the automatic field matching and data integrity at the expense of greater complexity. Although there are tools to edit SQL databases directly, it’s not as easy as editing a text file if I needed to change a value in a file. Backups would also be a bit more complicated.

One thing at a time — I need to finish this first.

Traditionally MUDs I’ve seen have used raw text files for player files. Some might use binary, and some might compress them into a gzipped format.

There’s a problem with using this sort of file: in general, they are written or read a single line at at time. In Basternae 2 we had a significant problem with player file corruption. If the save or load engine had a problem with one of the values found in the file, you were pretty much screwed. If this happened during a file save, you pretty much had to restore the player file from a backup and hope that the backup was recent.

In order to banish this problem to the realms of oblivion, I’m incorporating the XML-based file save/load code that I used on my AlgoRhythmia 3 application. The difference with this code is that instead of opening the file and writing it line by line, dealing with values as they come, instead it creates an XML data store in memory and populates that with the values, and then serializes it to disk after all the values are checked.

So, intstead of having a half-written player file if the values are bad, it’ll be an all-or-nothing. If the data store fails to build, the file won’t be written, so instead of losing up to a week worth of play data, at most about 15 minutes would be lost, and that assumes the player hadn’t picked up or dropped any items in that time.

Once I have this code done I may give serious thought to setting up all of the game files to use XML. In addition to the build-then-save, XML also some built in checks and guards, so a typo in a hand-edited file would be much less likely to destroy the universe.

The downside: XML files are larger and slower.

The other upside: Data files written in XML can be easily processed by other applications, such as a web script that posts dynamic game stats on a page.