• Advertisement
Sign in to follow this  

OOP Design

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

Hello,

 

So, I'm currently making a rogue-like game (pretty sure I start every thread I make like that lol) and I find myself questioning the implementation of OOP in what I have so far. (2-D tile side-scroller btw).

 

Finding it hard to find the words for describing my design, sorry in advance if I am unclear

 

Here some classes that are relevant to my question:

 

Main game class

This contains my main game loop, and the 'master' draw function

 

Screen class

This is a base class for all of my, um, screens, menu's, game over and ingame

 

Ingame screen class

inherits from screen, overrides the draw function to draw tile map and  at the moment the entities and the player

has a Room array for map

 

Room class

contains tile array and entity list (vector)

 

 

 At the moment I have a Screen variable in the Main game class which I change between on calls, which works fine.  

 

To me, it seems natural for the Level map (of Rooms)  and the player should be in the Main game and update from there, rather than going through the calling them (or updating them in) IngameScreen class.

 

I would do this, but then that lies to a hurdle of setting/getting them in the Screen class.

 

Its easier to leave them in the IngameScreen class, but, then problems comes with input (I have a working system).

 

 

As I said, communication isn't as fluid as it could/should be (sorry[words why do you escape me :( ]). But if you have any thoughts let me know.

 

thanks

Share this post


Link to post
Share on other sites
Advertisement

first question would be, do you want to go with an oo type design, or something else like components, modular, etc?

 

you're using c++, so all options are open. 

 

as you seem to be discovering, traditional methods of c++/oo design of games can have issues.

Share this post


Link to post
Share on other sites

Take a look at shared_ptr (either std::shared_ptr if your compiler supports it, or boost::shared_ptr if not). You can then share your player object between the screen (for displaying) and the gameloop (for updates).

 

Something must construct the player, let's say it's the main game class and it can share it with the game screen by passing it through a constructor.

Edited by dmatter

Share this post


Link to post
Share on other sites

first question would be, do you want to go with an oo type design, or something else like components, modular, etc?

 

you're using c++, so all options are open. 

 

as you seem to be discovering, traditional methods of c++/oo design of games can have issues.

Component-based and object-oriented approaches are not mutually exclusive. A good component-based design is likely to implement object-oriented (or at least object-based) principles, and vice versa.

 

Looking at this game from the component-based perspective, there are two main components: the game world and the screen. The game world has the job of simulation, while the screen (or at least the IngameScreen) has the job of drawing a game world. Since the IngameScreen is responsible for drawing a specific world, make the world a member of the IngameScreen. That way, the IngameScreen has access to everything in the world, and the screen doesn't need its own list of game objects, which would just be duplicating data and wasting memory.

 

If the idea of making the game world a member of the IngameScreen doesn't feel quite right conceptually, you could also pass the world as an argument to IngameScreen's drawing method.

Share this post


Link to post
Share on other sites

Hi, Thanks for the replies

 

Take a look at shared_ptr (either std::shared_ptr if your compiler supports it, or boost::shared_ptr if not). You can then share your player object between the screen (for displaying) and the gameloop (for updates).

 

Something must construct the player, let's say it's the main game class and it can share it with the game screen by passing it through a constructor.

Are there any advantages of using a shared pointer rather than just passing it down through a function? 

 

 

Looking at this game from the component-based perspective, there are two main components: the game world and the screen. The game world has the job of simulation, while the screen (or at least the IngameScreen) has the job of drawing a game world. Since the IngameScreen is responsible for drawing a specific world, make the world a member of the IngameScreen. That way, the IngameScreen has access to everything in the world, and the screen doesn't need its own list of game objects, which would just be duplicating data and wasting memory.

 

If the idea of making the game world a member of the IngameScreen doesn't feel quite right conceptually, you could also pass the world as an argument to IngameScreen's drawing method.

 

 yeah, you are correct about role of screen and maingameclass, why couldn't I have put it like that?

I will most likely do as you suggested, but it seems a bit silly to make an overload of the draw function just to be used for one (ingame)screen. 

Share this post


Link to post
Share on other sites

Are there any advantages of using a shared pointer rather than just passing it down through a function?

Well that depends. If you can get away with just passing it through a function then just do that. If you need your Game object and your Screen object to both hold onto the Player object for long periods of their lifetime then you have shared-ownership so use a shared_ptr.

Put a different way, if they both reference the player using member-variables then use a shared_ptr. If a function just needs reference to the player for the execution of that function then use a (preferably const) reference.

Share this post


Link to post
Share on other sites

 

Well that depends. If you can get away with just passing it through a function then just do that. If you need your Game object and your Screen object to both hold onto the Player object for long periods of their lifetime then you have shared-ownership so use a shared_ptr.

Put a different way, if they both reference the player using member-variables then use a shared_ptr. If a function just needs reference to the player for the execution of that function then use a (preferably const) reference.

 

sounds like a a shared_prt is what I need smile.png if I understand correctly.

I assume I should make a player and map[][] shared_ptr in my maingame class? if so how do I access the shared_ptr in my ingamescreen class?

Edited by dsm1891

Share this post


Link to post
Share on other sites

sounds like a a shared_prt is what I need smile.png if I understand correctly.
I assume I should make a player and map[][] shared_ptr in my maingame class? if so how do I access the shared_ptr in my ingamescreen class?

You might well do that if they both need to be shared.
In fact you might like to take a look at the Model-View-Controller (MVC) architectural pattern. You could think of your Screen classes as views, your Game class as the controller and the player+map as the model. Consequently you could even group the Player and Map into a GameModel/GameState/WorldState/WorldData/Whatever object which is logically the Model in MVC. You can then share that (with a shared_ptr passed through a constructor or setModel function) between the Controller and the View, or your controller can own the model and pass it to the view via a draw function as a reference argument. Edited by dmatter

Share this post


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

  • Advertisement