So here is a diagram that I will now proceed to ramble about.



Basically its showing the relationship between some interfaces and classes. These are some of the most often used, interacted witch classes, dealing with Tokens and Events.

Ok, I am going to explain the diagram a bit, feel free to pop that guy open in a new tab or window.

Token Interface
This is the pure model of the token, whithout influence of the view (I currently classify it as part of the model). Note that any game must keep track of where its tokens are. This the Xergs system uses Axis Aligned Bounding Boxes to determine the boundries of all tokens.

While this may seem imprecise, the use of subtokens allows for finer granularity if desired. for example, a dragon with have a certain total height and width, represented as the parent token's height and width, the dragon may actually be broken down into several bounding boxes ( for the head, neck, body, etc.).

TokenView Interface
The view specific stuff such as getImages are in this interface.

PlayerToken
Implements the TokenView interface and represents the Human (or SI-Controlled teammates).

Event Interface
Provides three methods: apply, actionDone, actionReset. Objects implementing this class are intended to represent and action by either the player or computer NPCs, such as attacking, running, fighting, etc.

EventView Interface
Contains view specific methods such as getImages, so that it can be represented graphically.

Action
This is the concrete class of the EventView interface. As stated this represents an action such as running and through use of other interfaces, allows it to be generic to fit any mobile Token, since it uses the TokenView interface to get the image for the performed action from the Token that its working on.


Summary
So, basically TokenView objects are being juggled around by the game engine, which treats them as simple Token objects since we don't want to have the GameEngine being aware of how something is drawn (that would make upgrading to 3d a ginormous pain in the ass).

The game engine is mostly interested in getting an Action from the Token and having using 'apply' on the given Action. Apply will be the actual action of running, etc. How it looks will be determined by EventView.

So these TokenView objects are then responsible for being drawn, or rather returning something to the DrawEngine that can be drawn.

The Future
Well, this is all fine and dandy, but if you saw the methods on my Token class you would see it getting pretty big. But I want to add more options, such as can the Token be interacted with? That definatly a non-view action, so it shouldn't really go onto TokenView. The view of the interaction (such as a dialogue box) would be view specific.

Should I add a hasDialogue method to Token? Seems kinda klunky to force every token, even ones that it makes no sense for to have to have yet another function that just returns false. So here is my big paradigm shift:

Stop extending interfaces and start implementing (or not implementing) more of them. So, to explain, I mean I should make a interface 'Speaker' that denotes if the Token has a dialogue object (dialogue objects will be interactive/non-interactive descriptions such as 'this is a rock.' or 'what you like to buy?').

Whenever something wants an dialoge from a Token, it can just test to see if that Token implements the Speaker class (I know, I am working on that name). In Java, this is a trivial "if( instanceof Speaker)" test.

This will cut down on method clutter where the methods are justing going to indicate that some functionality isn't needed. Also, looking at an objects Interfaces will tell you more about what the object can do. It CAN be inspected, it CAN be drawn. Yes, that means I have to refactor TokenView to Drawable2D interface. But then when I want to draw 3d objects, the tokens will implement Drawable3D interface, rather than modifying TokenView to have a getVertices method, instead of a getImages method.

Don't even begin to suggest that I plan ahead and have all objects implement both getVertices and getImages methods, to "plan ahead". That isn't planning ahead, its locking yourself into an implementation scheme (a scheme that may not provide you with enough flexibility when you need it). What if you final 3d pipeline engine doesn't want vertices, but some other object? Even more code modifications then. Also, it will clutter up objects with fake methods (since the object is sprite based, getVertices won't mean anything).

I am all rambled out now.