Seperation of game- and rendering logic

Posted by Qua on Stack Overflow See other posts from Stack Overflow or by Qua
Published on 2010-05-03T07:24:42Z Indexed on 2010/05/03 7:28 UTC
Read the original article Hit count: 383

What is the best way to seperate rendering code from the actually game engine/logic code? And is it even a good idea to seperate those?

Let's assume we have a game object called Knight. The Knight has to be rendered on the screen for the user to see. We're now left with two choices. Either we give the Knight a Render/Draw method that we can call, or we create a renderer class that takes care of rendering all knights.

In the scenario where the two is seperated the Knight should the knight still contain all the information needed to render him, or should this be seperated as well?

In the last project we created we decided to let all the information required to render an object be stored inside the object itself, but we had a seperate component to actually read those informations and render the objects. The object would contain information such as size, rotation, scale, and which animation was currently playing and based on this the renderer object would compose the screen.

Frameworks such as XNA seem to think joining the object and rendering is a good idea, but we're afraid to get tied up to a specific rendering framework, whereas building a seperate rendering component gives us more freedom to change framework at any given time.

© Stack Overflow or respective owner

Related posts about design

Related posts about design-patterns