-1

I'm trying to develop a little game and for this I'd like to separate the UI from the game logic.

So I'm thinking of using an "Animator" class that will be responsible for rendering the objects, but I have a bit of a dilemma here. I can think of 2 options to implement it:

Option 1: for each object the "Animator" will have a ObjectAnimator class which will expose a "Render(IAnimatedObject)" method. It will receive the entire object and render it according to its current state. The problem I see here is that each object will have to hold the animation state inside him which increases the coupling between the object and the animation. The benefit of this approach is that the object doesn't know its ObjectAnimator...

Option 2: Each object will expose a "GetAnimator" method which will give us its animating object. the problem I see here is that if I have hundreds of objects, I'll need to have hundreds of ObjectAnimator objects as well. It will also increase the coupling between the object and the animation object because the object will have to know it animator. On the other hand, the object itself won't have to hold it animation state.

which option is better? Is there an even better option than those I wrote?

1
  • I'm not aware of whether game clients follow that separation strictly. IMO the important thing is that you be able to parse all input (config files, network data, interactive input) without directly inserting it into the world. But then, I mostly do server-side, not GUI.
    – o11c
    Oct 20 '14 at 14:54
2

Steal an idea from gui libraries: every drawable object implements Drawable which has one method:

draw(graphics_context)

This approach has been in almost every gui hierarchy I can recall, including canvases.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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