🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

I am going to hell methinks...

Published July 19, 2006
Advertisement
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.

TreeGame -> Plane -> Map -> Tile -> UnitBase    Base     Base   Base    Base       Unit    Unit     Unit   Unit               --- Event Objects inheritedTile    Tile     TileMap     MapPlane


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.
Previous Entry Eww...
Next Entry Progress Report
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement