New server stuff

I just managed to get enough of the new server to run in order to login, walk around (anywhere - no walls) and run some simple commands (e.g. 'look').

The greeting is implemented in javascript:

    player.chat("Welcome to the DuskZ test game.");
    player.chat("Copyright(c) 2013.. etc etc fixme.");

    count = player.getInt('logincount');
    if (count == 0) {
       player.chat('Welcome newbie!');
       player.setInt('logincount', count+1);
    }

    true;

I've added arbitrary variables to objects which can be used to track quests and so on, rather than using hidden 'conditions' - I will instead reserve conditions for real conditions (poision, etc).

The code base is just under 3 000 lines of code at this point, but there are still many things left to implement. I do have much of the guts there (albeit untested, or unfinished) including battle engine and mob ai. But most of the commands aren't ported over yet, and the skill/spell system is not sorted out.

All the code is either new or radically altered old code, as I've tried to leverage the object hierarchy to properly abstract away and hide information. e.g. the details of the mathematics of the battle system is now mostly on the Active class, with the Battle class just used to oversee the battles. This factoring of code into sub-classes is proving to be quite lengthy and involved (and probably error-prone).

I also only run one master clock thread now which handles movement, ai, battles, and updates. Rather than having mob ai on another thread. I will have to think of another way to leverage multiple threads, if it is required.

Another big change is the server-client sync mechanism. Rather than cascade changes as they happen - e.g. mob moves, then update every player who can see it straight away, everything is updated at the end of each turn (clock tick). Each Player tracks the visible objects the client should have, and sends deltas if required. This may or may not be more efficient in cpu cycles and ram, but it's a lot easier to understand and debug. It would also let me put all updates into a single message in an 'atomic' way to properly fix the jumping-sprites-when-moving problem. And it opens a few other possibilities too.

So it's turning out to be a pretty big job, but one step at a time ... at least it's nice to have something to run (and crash) after hacking solid for a few days on it.

Update: So I woke up too early this morning (with a bit of a hangover to boot) so I had a quick look at trying to get the tile/movement scripts hooked in.

I decided to try giving map locations symbolic names and use those for both finding which script to run, and referencing inside of scripts. Each map has an alias file.

main.alias:

  alias.49.33=goto-drop-inn
  alias.49.34=drop-inn-porch

do-drop-inn.alias:

  alias.4.15=leave-drop-inn
  alias.4.14=entrance

These could be set inside tiled using properties.

And then the doorway scripts are simply ...

onLocationAction/goto-drop-inn:

  trigger.jumpTo("do-drop-inn", "entrance");

onLocationAction/leave-drop-inn:

  trigger.jumpTo("main", "drop-inn-porch");

As the doorway is currently a tile that cannot be occupied, it also needs a "can move" script.

onLocationAble/goto-drop-in:

    true;

Hmm, whilst the automatic symbol indirection works ok for the action script, it doesn't allow one to re-use scripts or optimise the simple true/false case. Maybe I should just use the alias mechanism for symbolic references, and define script linkage separately.

Update [Thursday]: Still plugging away at it but not enough to warrant a further post. Work is frying my brain a bit (crypto stuff atm, something useful to know about but a bit painful nonetheless) but I'm doing a bit of hacking on duskz most nights, filling out the implementation and clearing out TODOs and FIXMEs.

I got battles working a couple of days ago, together with items and equipment yesterday. Tonight I got most of the rest of the client updates doing - inventory, equipment, stats and status - actually re-arranged the code a bit so client-server sync is in another class, which only sends updates if things have changed and groups them a bit more sensibly (or will do when i'm done). Less clutter in Player which is big enough as it is. So for all that work ... the update mechanism is a lot less chattier than it was previously, particularly at login, which was a desired result. Code is simpler too, and can be made to work with pull clients.

This is the guts of the 'player' level game, so what I will look at doing next is filling this level of functionality out before worrying about the rest of the commands. I need to organise the code a bit too before checking it in.

And debug.