Object Orientated Question
Author
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?
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
ld
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).
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).
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
ld
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.
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.
Author
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?
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.
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.
Author
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
