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

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.

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.

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.

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.

sounds like a a shared_prt is what I need 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?

sounds like a a shared_prt is what I need 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?