How to organize game objects

I have been dealing with some issues regarding picking and the notification of events. This prompted me to evaluate how my game objects are set up. I know the standard method is to extend a Quad or TriMesh or whatever you need and then add in your game logic right there. My current system is somewhat different in that I have my game logic in it’s own object which is associated to the spatial and vice versa. This association is done by an external mapping so that I don’t have to modify the stock Quad/TriMesh/etc. Now when a mouse pick/mouse over event occurs I’m sending the notification of that event to the object that owns the spatial that was interacted with. That object derives from my “GameObject” class which maintains a link to it’s parent and if it doens’t want to handle the event, it passes it up the chain. This is similar to the method used here:



http://developer.apple.com/documentation/Cocoa/Conceptual/BasicEventHandling/index.html



although I developed my system before learning of this (doh!)



My question is really about how my seperation of game object and spatial works. Is it extra work for no good reason? Is there any gotcha’s to just extending the spatial classes (Quad, etc.) ?



Also, if it’s a good idea to have the game logic in a class derived from the spatial family, how do you easily integrate an event handler framework without extending each individual type of spatial that you need and adding it there? If there was an intermediary class somewhere that had the implementation of the events you want to support (I have an interface defining those and my GameObject class acts as an adapter for the methods similar to Swing’s event adapters), then I could see having a nice integrated message handling system for any object in the graph. The one problem this introduces is additional overhead to maintain who your parent is which, unlike a GUI system, happens quite a bit in my game :’(

My question is really about how my seperation of game object and spatial works. Is it extra work for no good reason?


It sounds a bit like the model-view pattern, which I saw a discussion about over at javagaming...

umm...

Yes, here it is: http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=GameDesign;action=display;num=1078223795

Yes I thought about trying to organize everything into the MVC paradigm but the problem is that currently a lot of the “model” related work is done in the view (ie collision detection). I suppose if you weren’t doing triangle level collision detection you could process most everything from the data but it seems for games the view is just too integral to the whole process unless you design for MVC from the beginning (which bring up a host of trade-offs I’m sure). I’m actually happy to have my process sit on top of the view and share the model data with it, a partial MVC I suppose.



If this is a problem that many people have encountered I’d really like to see some sort of unified architecture supporting event handling that can be applied to the whole scene graph. I’ll be happy to donate all my code as soon as it’s tested and working satisfactorily.

I have done something like this before, event handling, message relaying. Basically, an Entity class…



If you want to have a look at my code, and perhaps get a few ideas from it, its here



Its quite a long listing…



Actually, we could combine powers to make this? what do you think?



DP

I wouldn’t mind teaming up for something like this, however, my focus is much narrower than the code you proposed in the other thread. My goals would be to get a system where a game message can be easily sent to the appropriate handler, wherever that may be. I would err on the side of flexibility because invaraibly each developer will want to implement things their own way. To this end I would propose we work on a system where:

    -Every object in the scene graph can have a handler attached.
    -Every handler has the default action of passing the message up the chain (to its parent).
    -The message passed is done in a way that developers can extend it to contain their own messages (hopefully without requiring lots of casting everywhere or a big block of instanceof() conditions).
    [/list:u]

    That's about all the requirements I've come across in my own game. Of course this doesn't answer the question of should the "handler" of the message be extended from Spatial or be a completely seperate object that just contains game data and logic?

This proposal would solve this problem: http://www.jmonkeyengine.com/jmeforum/viewtopic.php?t=1330

That proposal is somewhat related to what I was thinking, although I was going to have an external map that allowed lookups both via the game object and the Spatial. Just having a map in the Spatial doesn’t solve the issue of having a coherent way to handle message passing and the delegation of those messages to another object up the chain.

… but it would let the spatial know what the other object was.

No your absolutely right it would accomplish that. I’m just looking for a bigger overall solution. The hash I suppose is a generic way to handle the issue as any developer can basically add a value to Spatial without mucking with the internals of jME. There’s still the problem of going the other way and identifying all the spatials a game object controls.

If you’re using a map from Spatial to an event handling object (which seems like the best way to keep Spatial from growing any bigger), I’d recommend using java.util.IdentityHashMap, which uses the system-generated hashcode and the == method to check for equality, which would be much more useful than a general HashMap.