Jump to content
  • Advertisement
Sign in to follow this  
TooLSHeD

Good OOP and UML

This topic is 4011 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

Hi I'm currently studying Engineering, we've got a project for our software course where we have to create a simple Gyruss clone. Most of the emphasis is on good design and the report, coding counts, but not as much. I'm busy doing the UML design. I'm stuck. I can't get my head around how to structure the classes. The player and enemy classes are relatively easy, they both inherit from a Sprite class and can be implemented quite easily. My problem is with the "management" classes, I've started of with a Window class that handles the window creation and related stuff, I added the main game loop, but then thought: should it be here? shouldn't it be in the Game_Object? should there be a Game_Object? If the main loop is a member how will it interact with all the other objects? They say to stay away from a monolithic design, should I design it to be more lateral? Any suggestions will be appreciated Thanks.

Share this post


Link to post
Share on other sites
Advertisement
Use the "knows a" relationship (association) to hook things up. The game loop definitely shouldn't be in the window class. Stick to something like model-view-controller.

Share this post


Link to post
Share on other sites
One thing to think about for having the player derive from sprite.

Is the player a sprite?

Or does the player HAVE A sprite?

Take a look into using composition as opposed to purely Heirarchical.

As for the management problem, you could have a kernel class which spawns off a window object to handle the creating of the window, then communicates with it for handling of the msg loop. That way the kernel is updating your game rather then your window.

Share this post


Link to post
Share on other sites
Ok I've looked at model-view-controller and observer patterns, can I model the Game Object as an observer and the sprites (player, enemy, projectile) as a subject. The sprite will notify the Game Object with its state (position, surface, etc.)? So the main loop will be contained in the game object and it will continuously render the other objects based on the updated states from the notifications?

Also regarding model-view-controller will all these aspects be contained in one class? I'm a bit confused.

Lastly, why would it be better to use composition as opposed to purely Hierarchical?

Share this post


Link to post
Share on other sites
Quote:
Original post by TooLSHeD
Ok I've looked at model-view-controller and observer patterns, can I model the Game Object as an observer and the sprites (player, enemy, projectile) as a subject. The sprite will notify the Game Object with its state (position, surface, etc.)?

The sprite's not changing itself, is it? Even if the AI routines are part of the object, something else is calling those routines.

Quote:
Lastly, why would it be better to use composition as opposed to purely Hierarchical?

Because sometimes things can be better described as "X has a Y" rather than "X is a Y". A movable object on your gameboard isn't a sprite. The sprite is just the graphical representation of it.

Here's a rough outline of how an OO game could work:

Input comes from the player, which is translated (via the controller) into a command of some kind. This, combined with AI decisions (part of the model), is implemented in the game's model. The state of the model is then transmitted back to the view, which produces the appropriate graphics and sound.

You can change up the structure in a variety of ways, but normally I'd have the controller observing the input and the model, directly passing events from the input to the model, and from the model to the view.

Share this post


Link to post
Share on other sites
Thanks I had the wrong idea about what a sprite is. If I wanted to implement observer patterns would it work the other way around then? The controller is the subject and the movable object is the observer. The controller will notify the subject that it's ready to render it or calculate collision detection and the observer will return its position and sprite.

Also I want to abstract the view to such an extent that if in the future I decide SDL isn't right and I want to implement the graphics using OpenGL(for arguments sake), is it a good idea to have the interface standardised and be able to change the implementation of the Window class so that it doesn't affect the other classes at all?

The only reason I'm considering this is to be able to include this in the report write up as a conscious decision I took while designing the game.

Share this post


Link to post
Share on other sites
Hello I am studing enginieering too.
The good desing of game is one point that I have put some good atention,So I thing I can give you some advices.

I do the following things:

Create an *Interface* "Actor" class.
This one will have some basic stuff like positions on x, y z, "do action" funciont , update functions, draw functions any general function.

Inheritate from this interface the class "Controllable Actor" and "SecondaryActor" (the names are your desition).

Also interface Actor must have a association with other Class "ActorGrafphic" that managed graphic logic (not graphic but graphic logic (it is differnt)).

Controllable Actor will have the posibility that this one will be controled by humanans, so it will be the one that the "Controller Modole" will interact.

SecondaryActar of course will be any actor that nor require human control.

If you can see this litle and (horrible explicated :-( ) desing, you get a desing with a litle more cohesion and more low coumpling betwen the classes that requires it. This one are Graphics by one side, logic, controller, IA, sound etc.

Sorry I can explain you more deeply but it take too time. If you sendme a mail I can gave you some UML class diagrams and Interaction diagrams more complete.

By the way the use of the Observer pattern is very good. I used for each one that requires it. For example in the controller sectionn (controllerManager is the Notifier and Actors the Observers), the ActorManager section etc.
Other patterns that are essential are factory (where it corresponds) and facade.
Other design patter that are really important are the "simples patterns" (are simple but mayor people do not apply them)this one are thre grasp pattenerns.
-High cohesion
-low acoumplemt
-don't talk with extrangers
etc.


I am actually tring to do a generic framework OO for games, doing generic is extremely complicate, becuse for example on the graphic part, differents engines have differnt way to use thing. But I keep tring.
Without doing generic is quite simple and create and amazing point for desing a game that the will have a very good designs qualitys and allows you to add, modified and erase thing in a very easy way.

It hopes it help you a little.
My email is vskjob at g/mail for any doubt.

Vsk.


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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!