This is a class diagram for a quick test scenario i'm programming in several languages to help me decide which one is best. I'm not too experienced with designing. The aim of the test scenario is to test collision detection and general use of each language. The player model (player) will be placed on a map which will use a single plane (terrain), 4 box shapes as the sides of the terrain (buildings). Their will not be any CPU player though so you can ignore that instance of Player.
Since I don't usually design at all, i'd just like some feedback on this class diagram. Just to know if its appropriate and to iron out any problems.
Thanks in advance :)
|EDIT|
For some reason theirs a line missing.. theirs supposed to be an association link between player and terrain.
|EDIT|
Class diagram feedback
Author
This is a class diagram for a quick test scenario i'm programming in several languages to help me decide which one is best. I'm not too experienced with designing. The aim of the test scenario is to test collision detection and general use of each language. The player model (player) will be placed on a map which will use a single plane (terrain), 4 box shapes as the sides of the terrain (buildings). Their will not be any CPU player though so you can ignore that instance of Player.
Since I don't usually design at all, i'd just like some feedback on this class diagram. Just to know if its appropriate and to iron out any problems.
Thanks in advance :)
|EDIT|
For some reason theirs a line missing.. theirs supposed to be an association link between player and terrain.
|EDIT|
I'm confused about the arrows you're using, in the UML I know inheritance is represented by an arrow with a "non-filled" head, and composition by a filled diamond.
Depending on your idea of a Player, you probably want a HumanPlayer (not Player1, that would be an instance of HumanPlayer) and a CPU (or ComputerPlayer) to inherit from Player. In this case you would use the "open" arrows.
If your definition of a Terrain is something that contains all sorts of objects, then the association (that is missing in the picture) between Terrain and Player is probably OK, but perhaps composition would be more appropriate. And you'd also need to have a composition relation between Terrain and Building (or between Terrain and Collidable/Object, see next paragraph).
If you think of a Terrain as a floor objects can be on, association with a role like 'stands on' is probably OK but not entirely necessary.
Furthermore I'm not entirely sure what the Obstacles is for. Is it meant to be an abstract class that represents a collidable object? In that case a name like Collidable or just plain Object would be more appropriate. And Building and Player should inherit from it. The Collides association would then be a recursive relationship, although I'm not quite sure this is allowed.
Finally, the Boundaries should probably have a composition relationship with Building, and not inherit from it.
See http://www.holub.com/goodies/uml/ for a quick overview of symbols.
Depending on your idea of a Player, you probably want a HumanPlayer (not Player1, that would be an instance of HumanPlayer) and a CPU (or ComputerPlayer) to inherit from Player. In this case you would use the "open" arrows.
If your definition of a Terrain is something that contains all sorts of objects, then the association (that is missing in the picture) between Terrain and Player is probably OK, but perhaps composition would be more appropriate. And you'd also need to have a composition relation between Terrain and Building (or between Terrain and Collidable/Object, see next paragraph).
If you think of a Terrain as a floor objects can be on, association with a role like 'stands on' is probably OK but not entirely necessary.
Furthermore I'm not entirely sure what the Obstacles is for. Is it meant to be an abstract class that represents a collidable object? In that case a name like Collidable or just plain Object would be more appropriate. And Building and Player should inherit from it. The Collides association would then be a recursive relationship, although I'm not quite sure this is allowed.
Finally, the Boundaries should probably have a composition relationship with Building, and not inherit from it.
See http://www.holub.com/goodies/uml/ for a quick overview of symbols.
Author
Cheers, The lack of open arrows is simply due to microsoft office making simple things difficult. The obsticles are there as just collidable objects.
I was thinking about making Terrain a 'building' object since this is basically a single collidable object although it may cause problems with the collision types and maybe physics later in development. I will review the class diagram and post the changes considering the points mentioned.
I was also thinking about creating a 'Level' object that would contain all the objects such as buildings and terrain using composition. What are your thoughts on this?
I was thinking about making Terrain a 'building' object since this is basically a single collidable object although it may cause problems with the collision types and maybe physics later in development. I will review the class diagram and post the changes considering the points mentioned.
I was also thinking about creating a 'Level' object that would contain all the objects such as buildings and terrain using composition. What are your thoughts on this?
It's quite common to have a Level/Scene/SceneManager class that holds and manages objects such as meshes, terrain etc.
Given: "The aim of the test scenario is to test collision detection..."
These are the questions I would ask:
Why does the collision detection sub-system need to know if the object is a player or a building?
What is the difference between the Player object and the Player1 object?
(I think you meant PlayerHuman & PlayerAI)
Why are there two derived classes from Building that have width or length boundaries? Shouldn't those be properties of the building class?
Is this diagram specific to the collision object model or the game object model?
(Looks like game to me)
...
What type of collision object [do|does] {players, terrain, buildings} [have|use]?<br><br>Are you going to use only 1 type of collision privative (e.g. axis-aligned bounding-box or spheres?) or many?<br><br>How will you partition terrain into bounding volumes?<br><br>How will you organize large/complex hierarchical objects?<br>e.g. suppose you first test and see if the shot could have hit the person (with a quick sphere test), then you want to figure out which limb (using a tree of bounding-boxes), then which polygon to paint a decal (using a small section of the actual tri-mesh).<br>
These are the questions I would ask:
Why does the collision detection sub-system need to know if the object is a player or a building?
What is the difference between the Player object and the Player1 object?
(I think you meant PlayerHuman & PlayerAI)
Why are there two derived classes from Building that have width or length boundaries? Shouldn't those be properties of the building class?
Is this diagram specific to the collision object model or the game object model?
(Looks like game to me)
...
What type of collision object [do|does] {players, terrain, buildings} [have|use]?<br><br>Are you going to use only 1 type of collision privative (e.g. axis-aligned bounding-box or spheres?) or many?<br><br>How will you partition terrain into bounding volumes?<br><br>How will you organize large/complex hierarchical objects?<br>e.g. suppose you first test and see if the shot could have hit the person (with a quick sphere test), then you want to figure out which limb (using a tree of bounding-boxes), then which polygon to paint a decal (using a small section of the actual tri-mesh).<br>
Author
Thank you for the feedback, I really appreciate it. I have made changes to the digram to reflect some of the points that have been raised although some of it I did'nt quite understand.
I thought that each collidable object had to have a different collision ID to identify when each object 'touched' each other. I may be wrong though.
Here's my diagram with some of the changes made. I hope its an improvement, please let me know.
Thanks again for all your help.
I am still uncertain about the terrain object however since I don't know how this will be implemented or what collision detection will be applied.
Quote:Why does the collision detection sub-system need to know if the object is a player or a building?
I thought that each collidable object had to have a different collision ID to identify when each object 'touched' each other. I may be wrong though.
Here's my diagram with some of the changes made. I hope its an improvement, please let me know.
Thanks again for all your help.
I am still uncertain about the terrain object however since I don't know how this will be implemented or what collision detection will be applied.
That looks better than the original. Although, isn't terrain a type of obstacle?
I am a little concerned with the use of inheritance (I presume it's inheritance), particularly with the Player class. In a more complete class diagram would you be having the Player class inherit from Collidable, Moveable, Drawable, Audible, etc? That's a lot of multiple inheritance!
I would prefere composition over inheritance, the Player class can compose a Collidable component, a Drawable component, etc.
I am a little concerned with the use of inheritance (I presume it's inheritance), particularly with the Player class. In a more complete class diagram would you be having the Player class inherit from Collidable, Moveable, Drawable, Audible, etc? That's a lot of multiple inheritance!
I would prefere composition over inheritance, the Player class can compose a Collidable component, a Drawable component, etc.
Sorry to say so, but you design has some flaws.
You're modelling collisions as associations between classes.
You rely on inheritance.
And you mix several concepts that should be separated.
So, what to do with that?
First of all, from your model it reads that the Player class is associated with the Terain class, which in this case means that the Players interact with the Terrain directly.
Please work on that, this will run you into trouble.
First of all, usually the terrain is split up into several objects, with these objects attached to the scene graph.
Having a monolithic "Terrain" object in this case would only make sense as an adapto-like thing for accessing the terrain as a whole, but not for in-game interaction.
Secondly, as I read it, all these thing in your model are classes.
That's fine, ut some of the functionality should be defined by interfaces, such as the collision reaction.
The objects themselves should define their behaviour on collisions.
Collision detection is doen by the scene graph, using the spatial information each node contains.
Third, there is no need for "Player1" and "CPU" classes, the Player class is sufficient to do the job.
It should have a component that controls it, and that component should make he difference between human and CPU.
Otherwise, you'd be directly handling input inside a game class, which is a bad idea, obviously.
You're modelling collisions as associations between classes.
You rely on inheritance.
And you mix several concepts that should be separated.
So, what to do with that?
First of all, from your model it reads that the Player class is associated with the Terain class, which in this case means that the Players interact with the Terrain directly.
Please work on that, this will run you into trouble.
First of all, usually the terrain is split up into several objects, with these objects attached to the scene graph.
Having a monolithic "Terrain" object in this case would only make sense as an adapto-like thing for accessing the terrain as a whole, but not for in-game interaction.
Secondly, as I read it, all these thing in your model are classes.
That's fine, ut some of the functionality should be defined by interfaces, such as the collision reaction.
The objects themselves should define their behaviour on collisions.
Collision detection is doen by the scene graph, using the spatial information each node contains.
Third, there is no need for "Player1" and "CPU" classes, the Player class is sufficient to do the job.
It should have a component that controls it, and that component should make he difference between human and CPU.
Otherwise, you'd be directly handling input inside a game class, which is a bad idea, obviously.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
