C# 2D Game Design/Architecture Question

Question

I am developing a 2D game for windows phone using C# and XNA. I have a list of screens managed by an engine. each screen has a list of components like 'camera', 'skyBackground', 'landBackground', 'units' and so on. All those components inherit from an interface 'IComponent' which has the following:

public interface IComponent
{
    void Initialize();

    void Update();

    void Draw(Camera camera, Color tint);

    BoundingBox BoundingBox { get; }
} 

This has it advantages and disadvantages. It unifies all game objects so i can treat them the same, but creates some harmless but still annoying issues like having plenty of empty initialize functions, or a camera with an empty draw method, or a UI class that doesn't need the camera as a passed in parameter to draw in the 'Draw' function but takes it anyways and so on.

I then thought of creating a number of interfaces like 'IUpdate', 'IInitialize', 'IDraw', 'IBoundingBox' and having my screens store a list of 'object' rather than a list of 'IComponents', and then in the update method i would do as follows:

foreach object obj in objects
    if(obj is IUpdate)
        ((IUpdate)obj).Update();

But I don't know how the 'is' command works behind the scenes, maybe its a costly feature which shouldn't be called each frame for all objects in each loop.

So am not sure what to do here, should I accept a unified interface with the few currently harmless kinks it introduces or use my 2nd idea? or maybe you could suggest another alternative?

Thanks a lot

Answer 1

You never know how costly a feature is until it's in your code and tested running, realizing that you don't know is a great thing.

I think that your main problem is that you've packed your idea of what a "component" is with way too much functionality. I think that you want to reduce the responsibilities of component to the bare minimum, maybe just engine maintenance and debug helpers.

From there you could add more interfaces for updating and rendering and so on to appropriate classes, and when those objects are created add them to separate lists of components that are known to use those interfaces. One way you could do that would be for the class to have an initializer that requests that it be placed on the rendering list, for example, or that it needs an update.

Your engine, then, maintains those lists and knows that anyone on that list needs to be called and you don't have to check each object each frame.

It may help to make a large scale block diagram of how your system will fit together logically, if interactions appear to be really complicated then that's an indication that your blocks need redesigning. With diagrams and logic you will avoid getting stuck in the implementation details before you even know what it is you are implementing.