Class heirarchy and stuff

I was looking through the duskz code as it is right now and there are still plenty of messy bits that I want to do something about. In some places there just seems to be more code than there should be to do fairly simple things, often a simple routine is just coded inline and repeated multiple times. And each object implements it's own parser as well as a different format/convention for storing it's state.

Although there is an object class hierarchy for the in-game objects, there is little to no use of the facilities in Java for object oriented programming such as virtual methods, or even inheriting during object initialisation. Apart from the classes there is also class information stored in type fields as well. e.g. a basic LivingThing can be a player, or a pet, an Item can be any type of item from armour to a backpack. Each container includes fields which are only applicable depending on some other field. They then have testing methods to determine what type they are, but it leads to ugly code with lots of manual checking in places. Actually the code looks more like a C design, where the objects are just data containers.

The existing class structure is something like:

DuskObject
  LivingThing
    Mob
  Item
  Merchant
  PlayerMerchant
  Prop
  Sign

Each class either does its own i/o completely, or has it's i/o done for it in a completely separate class. I started an inconsistent stab at addressing this but I think to do it properly will require a common format/parser too. I'm going to stick with a Properties-like format for simplicity (name=value), but relax the requirement for unique keys (to allow multi-valued items).

First requirement is to clean up the class structure. I started at the base class and came up with a new hierarchy, which grew somewhat large by the end. I've also filled out most of the fields - in some cases it was hard to work out just which type of object a given field is restricted to. I gave them mostly unique names with the aim of avoiding clashes as I develop it, although they'll probably mostly stick.

Thing
  Active
    Player
    Pet
    Mobile
  Holdable
    Useable
      Food
      Drink
      Item
    Wearable
      Weapon
      Armour
    Container
  Shop
    Merchant
    PlayerMerchant
  Sign
  Prop

This will let me do things like move the 'get list of sellable items' to a function on Shop, rather than having it appear in multiple places throughout the code, each having to test which type of merchant too.

The code for game logic is also spread across mostly LivingThing and DuskEngine in random ways (some of it my fault by this time). Even things like the game pulse - there are two separate tick threads, for no particularly obvious reason? It might have been created to run enemy a/i on a separate thread, but extra stuff got added later - in any event it should run on a common clock.

I started just investigating the current structure to see how it's used, but I think i'll just rewrite the whole lot, the objects, the i/o & file formats, and well, most of the behaviour code too. The game logic itself is fairly simple so i'm hoping I can hide some of the dumb-but-necessary code like i/o away to expose the simplicity. There wont be much left of the original code apart from the battle logic, and the overall behaviour.

Could keep me busy for a while though ...

Update: I found there was a single weapon - a "runed shortsword", which was also "useable", so I decided to put the useable fields into Holdable instead so anything can be "used", if the game so desires. Non-usability is set by simply not setting hose fields. This could be extended to other types of item, but doesn't seem useful.