Recommended Posts

I'm a little confused on basic game class design...
How should I design my classes so that certain classes can be drawn and other can't, etc?
It seems like two options are using interfaces (eg. IDrawable, ISpellCasting, etc) or to use components (XNA seems to be designed this way I think). One other option is to have something like a DrawableEntity base class and descend from that but that seems to get tricky when you have an object that is both drawable and can cast spells versus one that cannot.
The component architecture seems nice but then you need a way to communicate between components (eg. the spell casting component may need to tell the drawable component that the character is now blue-tinted). How is this accomplished?
Also, how does collision detection fit into this?

0

Share this post

Link to post

Share on other sites

Original post by sofakngIt seems like two options are using interfaces (eg. IDrawable, ISpellCasting, etc) ... One other option is to have something like a DrawableEntity base class and descend from that but that seems to get tricky when you have an object that is both drawable and can cast spells versus one that cannot.

Separate correctly segregated interfaces are better than one bloated one; this concept is known as the Interface Segregation Principle (ISP).

Quote:

The component architecture seems nice but then you need a way to communicate between components (eg. the spell casting component may need to tell the drawable component that the character is now blue-tinted). How is this accomplished?

You could use an event or callback system. Suppose each component registers callbacks into a dictionary that maps event name to delegates, then suppose that each component is allowed to pull out from the dictionary (or otherwise store a reference to the dictionary itself) just those events it is interested in generating so that it can invoke them when it does so. In your example the drawing component would register a "colour change" callback, the spell casting component would search for such a callback and, if found, invoke it when the spell is cast thus informing the drawing component of this change.

Another simple solution is just to place all common data in a commonly accessible place, like the entity itself.

Quote:

Also, how does collision detection fit into this?

In much the same way that you may have a renderer for graphics you can also have a physics manager for collision detection/response.