views:

168

answers:

1

Here is my problem.

I am trying to write a small simple game engine (I'm doing it in order to improve my design skills) . I'm having a Scene Object which hold everything the rendering API need in order to render it.

Naturally , I would like my scene to be immune to future changes , meaning future changes to it will not have to break its interface. For example If i'll want in the future my scene to have a Fog feature which can be turned on and off , I want to be able to add it without breaking my scene interface.

One important thing is that the Rendering API communicates with the Scene through an Interface (which obviously named "IScene)

My thoughts are going towards the "Decorator" Pattern , can anyone suggest something that might be more appropriate?

+2  A: 

I suggest to have a look at existing APIs. You will soon understand that it's not a simple problem. Fog could be a filter (uniform over the screen) but that looks unrealistic. Fog should be more like a translucent cloud near the ground. So rendering it as one or more translucent gray objects may be more realistic but it might be impossible to implement with current hardware.

[EDIT] What I'm trying to say: A simple decorator pattern is probably not enough to achieve any complex effect. I haven't seen many engines but most go for a very simple scene object which only saves some globals (ambient light, camera position, display size) plus a list of objects to display. The objects then contain additional information.

These things are pretty dumb. A renderer will take the information stored in these objects and convert them into something the display hardware can use.

Again, my advice is to get some ideas from existing APIs because they already made all the mistakes.

Aaron Digulla
I understand what you'r saying about the fog but I only gave it as an example , My question wasn't about the fog but rather about waht pattern to apply in order to avoid future changes to the IScene interface
Read your edited comment, you've got a point , thanks for your response.