Jump to content
  • Advertisement
Sign in to follow this  
Sean Doherty

Object Orientated Question

This topic is 5057 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

From and Object Orientated prespective if you have a unit firing a laser at a second unit: Who should be responsible for drawing the lasers muzzle flash? Who should be responsible for drawing the lasers impact point? Who should be responsible for drawing the laser?

Share this post


Link to post
Share on other sites
Advertisement
Alternatively, the unit's laser spawning weapon draws the flash (or spawns a flash), and the spawned laser becomes responsible for managing its own fx. This approach is used in the Unreal Engine.

ld

Share this post


Link to post
Share on other sites
1) The muzzle renderer object for the unit's "muzzle" object is responsible for drawing the muzzle flash.
2) Not sure what you mean. Are you talking about the results of the laser hitting the second unit? If so, then the unit renderer for the unit that got hit is responsible for drawing it.
3) The laser renderer object should be responsible for drawing the laser object.

If you don't know what I mean by the *renderer classes, then here's a little example of what I do:
Suppose that you want a tank in a game. These are the classes I would create:
* the Tank class:
Responsible for moving the tank and shooting the Tank's cannon object.
* the TankCannon class:
Responsible for shooting projectiles.
* the TankRenderer class:
Responsible for rendering a Tank object.
* the TankHumanController class:
Responsible for controlling a Tank object based on human input.
* the TankComputerController class:
Responsible for controlling a Tank object based on AI.

Each controller class, except for Tank, which "controls" a TankCannon object, has an update function, and is passed the object it should control on creation. Each renderer class has a render function and is passed the object it should render on creation. Both the Tank and the TankCannon class know nothing about how they are shown (in this case rendered) or how they are controlled.
This is the "proper" way of doing it; because if you group all of those classes together like most people do, you violate the Single Responsibility Principle (SRP).

Share this post


Link to post
Share on other sites
MKH's is the technically most accurate, although it doesn't deal with the real question of who manages the resources. The renderer should be responsible for the low-level task of doing the actual drawing, as it is the only bit of the system able to properly decide on global graphics operations such as sorting, culling, clipping and lighting.

ld

Share this post


Link to post
Share on other sites
The weapon should spawn a muzzle flash, impact thing and beam and just put them into the world, then they should be responsible for drawing and updating themselves.

And even rendering themselves is an open question I generally prefer having the renderer doing the drawing and that each object don't know how to render itself but can tell the render of an model-id (model in the broadest way possible, gotten from the renderer in the first place) that it would like rendered at a given position.

Share this post


Link to post
Share on other sites
Quote:
Original post by bytecoder
1) The muzzle renderer object for the unit's "muzzle" object is responsible for drawing the muzzle flash.
2) Not sure what you mean. Are you talking about the results of the laser hitting the second unit? If so, then the unit renderer for the unit that got hit is responsible for drawing it.
3) The laser renderer object should be responsible for drawing the laser object.

If you don't know what I mean by the *renderer classes, then here's a little example of what I do:
Suppose that you want a tank in a game. These are the classes I would create:
* the Tank class:
Responsible for moving the tank and shooting the Tank's cannon object.
* the TankCannon class:
Responsible for shooting projectiles.
* the TankRenderer class:
Responsible for rendering a Tank object.
* the TankHumanController class:
Responsible for controlling a Tank object based on human input.
* the TankComputerController class:
Responsible for controlling a Tank object based on AI.

Each controller class, except for Tank, which "controls" a TankCannon object, has an update function, and is passed the object it should control on creation. Each renderer class has a render function and is passed the object it should render on creation. Both the Tank and the TankCannon class know nothing about how they are shown (in this case rendered) or how they are controlled.
This is the "proper" way of doing it; because if you group all of those classes together like most people do, you violate the Single Responsibility Principle (SRP).


ByteCoder,

Is this what you mean?

Share this post


Link to post
Share on other sites
Byte:

Whether you know it or not, your little schpeil on implementing a tank has cleared up a lot of design issues I was having as well. Ever consider writing design tutorials?

Sean:

What did you use to create that UML design? I wasn't aware that there were programs and have been using Excel.

Share this post


Link to post
Share on other sites
Quote:
Original post by DesCr
Byte:

Whether you know it or not, your little schpeil on implementing a tank has cleared up a lot of design issues I was having as well. Ever consider writing design tutorials?

Sean:

What did you use to create that UML design? I wasn't aware that there were programs and have been using Excel.


Enterprise Arhitect is the best program you can get for a reasonable price.

http://www.sparxsystems.com.au/

There are still a number of issues with the design; I have only posted the first question. Once I get some feedback I will evolve the model.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!