1

I want to write a simple program.

There will be single scene, one camera and certain 3d objects. I know, how to implement this, that is not the problem. The problem is - how to design it in a principles of OOP. I'm planning to make a class of camera and class of 3d object.

And my question is who is implementing Draw method? I think that camera needs to implement the draw method, the camera will composite BasicEffect and RasterizerState instances and will implement Update and Draw methods. What have I also thought about, that 3D object will get camera state and settings and will draw itself or there will be some third party class that will get 3D object's vertices and camera settings and state and will draw all the stuff. So what is the right OOP design?

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Nikita
  • 1,811
  • 1
  • 20
  • 41

2 Answers2

3

I think you might be asking the wrong question.

Most of the time "proper OOP principles" don't come up during game development. Certainly when writing gameplay code it's both fairly obvious how to divide up things into classes, and not such a big deal to get "encapsulation and all that jazz" 100% perfect.

The "traditional" approach in game development, at it simplest, is to have a base class (eg: GameObject or Actor) with virtual Draw and Update methods. Then a class for each kind of object in your game that inherits from that base class and overrides those methods as appropriate.

Then you simply stick instances of those classes in a list in your game class, which you loop through in Game.Draw and Game.Update calling the respective method on each instance.

You might want to consider adding other methods besides Draw and Update. LoadContent is one good example.

The class DrawableGameComponent is a good example of this architecture (note that it uses the built-in Game.Components as its list). Personally I don't recommend using XNA's component architecture (I advocate a roll-your-own approach). But if you've never seen the Draw/Update thing before it is worth having a look at.

For dealing with your camera object, I recommend making the signature of your draw method look like this:

public virtual void Draw(Camera camera)

That way every game object will be able to access the camera and know how to draw itself. (Note that this is not possible with DrawableGameComponent.)

I strongly recommend having a look at this answer which describes possible game architectures - in increasing complexity. In particular it goes into more detail on the "Actor class" approach and how different actors could interact.

Community
  • 1
  • 1
Andrew Russell
  • 26,924
  • 7
  • 58
  • 104
1

Your question is quite broad. You could take a look at samples at Microsoft App Hub. There are many basic samples, and some more sophisticated ones, like Ship Game and several other full games. That could give you some ideas to think about.

Skull
  • 86
  • 5