Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Suppose I have a SquareObject class, which implements IDrawable, an interface which contains the method void Draw(). I want to separate drawing logic itself from the game core engine.

My main idea is to create a static class which is responsible to dispatch actions to the graphic engine.

public static class DrawDispatcher<T>
{
    private static Action<T> DrawAction = new Action<T>((ObjectToDraw)=>{});
    public static void SetDrawAction(Action<T> action)
    {
        DrawAction = action;
    }
    public static void Dispatch(this T Obj)
    {
        DrawAction(Obj);
    }
}

public static class Extensions
{
    public static void DispatchDraw<T>(this object Obj)
    {
        DrawDispatcher<T>.DispatchDraw((T)Obj);
    }
}

Then, on the core side:

public class SquareObject: GameObject, IDrawable
{
    #region Interface
    public void Draw()
    {
        this.DispatchDraw<SquareObject>();
    }
    #endregion
}

And on the graphics side:

public static class SquareRender{
    //stuff here
    public static void Initialize(){
        DrawDispatcher<SquareObject>.SetDrawAction((Square)=>{//my square rendering logic});
    }
}

Do this "pattern" follow best practices?

And a plus, I could easily change the render scheme of each object by changing the DispatchDraw parameter, as in:

public class SuperSquareObject: GameObject, IDrawable
{
    #region Interface
    public void Draw()
    {
        this.DispatchDraw<SquareObject>();
    }
    #endregion
}
public class RedSquareObject: GameObject, IDrawable
{
    #region Interface
    public void Draw()
    {
        this.DispatchDraw<RedSquareObject>();
    }
    #endregion
}

RedSquareObject would have its own render method, but SuperSquareObject would render as a normal SquareObject

I'm just asking because i do not want to reinvent the wheel, and there may be a design pattern similar (and better) to this that I may be not acknowledged of.

Thanks in advance!

share|improve this question
add comment

2 Answers 2

up vote 5 down vote accepted

I don't think dispatching events is the best way to do this. If you have a high amount of draw calls the event dispatching and listeners will have a lot of overhead.

Also you might want to look what classes you have, because you don't need a class for each color of square, or even if there are more properties. You could be able to just store the color or other information in a variables on each instance instead of having a lot of classes for really similar objects.

For the drawing, you can just set up either a static or non static function in the class that has the Update. So you will have an Update() and a Draw() method in one class. In the main game's Update method, call the Update() method on the instance(s) that need to be updated. Depending on your logic, if there is enough time left over, you then call the Draw() method.

Make sure that the game doesn't require the Draw() method to run exactly at your refresh rate. If the game cannot keep up, it is best to skip Drawing for that frame, so the game will have more time to run the next step in the simulation.

share|improve this answer
    
But then, when I want to change how something is drawn, I'll have to create another class for that, won't I? This way I could have specific classes to "skin" my own game, just setting the drawaction to something else (like drawing a border on every game object). I dunno. –  Conrad Clark Mar 20 '11 at 13:29
    
No just have a field in each object that holds information that references what graphics it has. Don't store the actual graphic in each object. Use an Asset Manager. –  AttackingHobo Mar 20 '11 at 18:12
add comment

The best practice for separating the game logic from game rendering is to have separate objects for the logic and the renderable, instead of having one large object that performs both tasks. The renderable object has a reference to the logic object so that it can update its own state (eg. animations) based on data in the game logic, or just query for relevant properties directly (eg. current position).

Once you make that separation, most of these issues above disappear, and you don't have to worry about complicated observer patterns or event dispatch.

share|improve this answer
    
Why would the renderer update the objects positions? Surely that should lie with the animation and physics layer. Which may abstract from a movable layer... and so on –  Daniel Apr 1 '11 at 5:16
    
My wording was unclear - I meant the renderable can update its own state, based on the game logic. I'll edit the answer to make this clearer! –  Kylotan Apr 1 '11 at 11:04
    
This is the same pattern used in modern GUIs like WPF, which have a logical tree (Button, List, ...) and a visual tree (Border, Ellipse, Bitmap, ...) –  Adal Apr 2 '11 at 20:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.