Planet Mud-Dev

August 26, 2014

thecodelizard

Under New Management

Things have been on hold for a bit because of work; however, I've learned quite a lot at my latest job, and I hope to be able to apply it to Smerg if I can just break through the brick wall that Crafting has put in my way. Fortunately I think I'm almost done, and hope to take on other important problems after this.

One of the biggest ones is that I'm probably going to change the save format from XML to JSON. While both are human-readable, JSON is much easier for the untrained eye to understand, and more importantly, there are plenty of libraries out there for automatically serializing/deserializing objects. My own hand-rolled XML save format came about mostly because I didn't know any better at the time. So instead of:

<smerg.data.Player name="Kh'tall">
  <smerg.enums.Race name="race">LIZARDFOLK</smerg.enums.Race>
</smerg.data.Player>


It would look like:

{
  "name": "Kh'tall",
  "race": "LIZARDFOLK"
}


JSON is able to infer types, and nest things in lists, as well as ignore fields that are missing or default them to sane values like the current save format, so it should match the current functionality.

I also intend to Base64 hashed passwords because they currently come out to unprintable Unicode characters which save without issue but will almost certainly cause issues if someone tries to edit the save file. Base64 is used for encoding data into ASCII; the output is some combination of a-z, A-Z, numbers, +, and =, so any editor can see it. You should never be editing the password in either case; this just means that your text editor won't garble the password and lock the user out of their account.

As I previously mentioned, I want to make this into a Maven project, so that anyone with a suitable IDE can build it without any particular issues. Maven is IDE-independant, whereas it's currently built with a NetBeans-specific Ant file, so this one is a necessity. (As much as I would love to get more people using NetBeans)

I'd also like to overhaul the reflective object editing a little - it works wonderfully now for primitive types, strings, and enums, but doesn't handle lists at all; it shouldn't take too much effort for it to be able to handle lists of primitives/enums/strings, or references to Smerg objects (which are pretty much always Area Name + Internal ID).

Once I get to a reasonable point in development I'd, as I mentioned, like to put Smerg on Github to open-source it. I'd also like to get myself a virtual machine from Amazon (they cost like a few cents an hour, if that) so I can host a couple instances of Smerg.

There's also rather a lot of redundant error-checking in most of the command code that all gets handled the same way - checking if an area with a given name exists, if IDs are less than 0, and so on. This could all be delegated into the methods that are being called (such as getArea()), throwing Exceptions instead that detail the error, following the "easier to ask for forgiveness than permission" model.

August 26, 2014 04:30 PM