Hi all,
I am in the process of creating a small game. The engine will have a number of events that the GUI can subscribe to. The events are:
- ballselected
- balldeselected
- ballmoved
- ballremoved
This would all be fine if I only had one type of ball, but there are X number ball types. They all derive from an abstract Ball class.
Each ball type has its own actions that happen when this event happens for them. They will all need to pass different information back to the GUI. For example I have these two ball types (there are more just reducing the amount of info here).
- BallBouncing
- BallExploding
BallBouncing will need to tell the GUI where it may have moved to, so would just pass back information about it self.
BallExploding on the other hand would destroy the surrounding balls from it. So it would need to say which ball it is and all the balls it has destroyed.
these two balls types could both be fired from the same event, but have different event args. I could include a dictionary of values but that is not as explicit a having a custom event args for each type.
I also thought that if I created a custom event args that had the ball that was involved and then inherited from that for each ball type I could cast the event args back.
public abstract class BallBaseEventArgs : EventArgs
{
public Ball ball;
}
public class BallExplodingEventArgs : BallBaseEventArgs
{
public IList<Ball> explodedBalls;
}
So in the GUI event handler it would cast the event args by knowing what ball type was used. I don't like this solution much either as it feels dirty and too tightly tied up.
So I guess I am asking does anyone have suggestions, ideas how to tackle this sort of situation please.
Thanks
Jon
EDIT
OK, so I thought I would try and explain my structure a little more to clarify and see where it takes us:
I have an Objects DLL that has the interfaces for the Board and ball's, it has two Enum's one for the board types and one for the Ball types (this is used mainly for the factories to know which type of object to create). The DLL also has the various implementations of the Ball class and the Board class.
the abstract Ball class holds information such as the colour, its X and Y coordinates, is selected and BallType Enum. It has a couple of methods, Clone() (from ICloneable) and CompareTo (with the Equals and hash value bits).
I have an Instance Manager DLL that has a singleton object that controls the access to the Ball's Board and Game Configuration Data. This DLL also holds the BallFactory and boardFactory (not sure if these should have gone in the Objects DLL, reason they are not is because they are not objects so to speak, not sure if this is a great practice).
Then I have the Engine DLL. This deals with all the Logic of the game. How board and balls are created, why they are created and how they are used. There is a LogicFactory for the Ball and Board classes (all these factories use the BallTypes and BoardTypes Enum's to decide which implementation to use).
The Logic Classes decide how the Board moves balls around and calls the ball's action methods:
- ballselected
- balldeselected
- ballmoved
- ballremoved
Which is in the Ball Logic class.
The reason I didn't put all the logic in the objects them selves is that I thought the logic and functionality should be separate from the objects that just store the data about it, (this could be completely wrong). Most of the functionality about how a Ball could move / act is contained in the BallLogic bass class and each derived class decides on what it calls, (all methods are virtual so can be changed as well if needed).
Thanks for all your input, its really appriacated. I am doing this for fun but mainly to learn the right (and wrong) ways to develop different kinds of applications.