• entries
    359
  • comments
    237
  • views
    188453

I am going to hell methinks...

Sign in to follow this  
Telastyn

44 views

I'd like to share a little problem I've just run across and the rather horrible solution. I'm not sure if it's too horrible, as it makes stuff much easier to deal with, but...

The problem comes with an idea I had to better segment the moe game objects. In the previous iteration, public variables would trigger events when changed. A local event for things watching that particular instance, and a static event for any particular change to that variable in any instance. This turned out to be a useful way to hook networking messages, spell effects, rule triggers and the such. Unfortunately, trying to run the server as a thread spawned by the client led to them stepping on each other's static events. ThreadStatic might help, but that's not quite right; the server needs an instance of the global events, not individual threads in the server...

So, I decided to look back into a previous design that placed objects into a tree form. The game contains planes, which contain maps, which contain tiles, and so on. Instead of static events, a container would contain an event which would be triggered if any of its children trigger the event. Thus the client and server can have their own game objects which have their own events that effectively cover all objects. In theory, it would be even more useful since individual tiles or maps could set listeners/effects for limited area enchantments and the such.

The question then is how to technically implement such a setup without going insane typing in each event for each 'higher' class in the tree. Each object is already inherited from a common base to allow for ID lookup and to walk through the tree without much hassle, so that leaves interfaces. Something like:


public class Game: base, PlaneEvents, MapEvents, TileEvents...


would be fine. Events can work in interfaces, and a quick application of 'implement interface' will generate the members for me. A little tedious and messy, but only needs to be done once.

Oops, then there's no way to trigger the events.


The solution I ended up with was to progressively inherit the Event classes backwards up the tree.


Tree
Game -> Plane -> Map -> Tile -> Unit

Base Base Base Base Base
Unit Unit Unit Unit --- Event Objects inherited
Tile Tile Tile
Map Map
Plane


It works, and keeps me from having to manually enter all the events. Hell, it might even turn out to be a good idea or a common pattern I'm just ignorant of. Coming from C++ though, it is WEIRD to even think of such circular referencing. Hurray un-broken compiling.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now