So I've been trying to implement a health bar recently and I wanted it to follow my player objects (I have two because one of them is controlled with arrow keys and the other is controlled with w, a, s, and d).

The only problem is, I heard it was more efficient to have the visuals for the health bar in a separate class. I can't do that since I can't access my player x and y variables from another class since they aren't static (they can't be, or else I wouldn't be able to have more than 1 player object).

The reason I need to reference my player x and y variables is because I need my health bar to essentially follow my player. How would I go about doing that?

NOTE: I don't think showing code is completely necessary, since I only need the concept of how I would go about doing it. Thanks!

EDIT: I checked out your other thread, and now I understand what you're describing. You don't need a class to be static for it to provide information to other classes. In the same code that displays your other HUD/UI elements you can include instances of a HealthBar class (or whatever other approach you want to take). It will need to take information from your Player instances anyways, to show each player's current health, and at the same time you can pass information on the characters' onscreen locations to render the health bars in the right locations. Do you currently have a specific class for rendering things on the screen?

Why can't you have the health bar as a member variable in your Player class, rendered above/around your characters? You can still have a separate HealthBar class with its own sprites and render method. I doubt that any approach you take to implementing health bars could be inefficient enough to matter.

EDIT: I checked out your other thread, and now I understand what you're describing. In the same code that displays your other HUD/UI elements you can include instances of a HealthBar class (or whatever other approach you want to take). It will need to take information from your Player instances anyways, to show each player's current health, and at the same time you can pass information on the characters' onscreen locations to render the health bars in the right locations. You don't need a class to be static for it to provide information to other classes.

So I should render the health bar itself in the same class where I have the instances of my player objects?

Why can't you have the health bar as a member variable in your Player class, rendered above/around your characters? You can still have a separate HealthBar class with its own sprites and render method. I doubt that any approach you take to implementing health bars could be inefficient enough to matter.

EDIT: I checked out your other thread, and now I understand what you're describing. In the same code that displays your other HUD/UI elements you can include instances of a HealthBar class (or whatever other approach you want to take). It will need to take information from your Player instances anyways, to show each player's current health, and at the same time you can pass information on the characters' onscreen locations to render the health bars in the right locations. You don't need a class to be static for it to provide information to other classes.

So I should render the health bar itself in the same class where I have the instances of my player objects?

It depends on the structure of your code, but probably not. Your Player instances will be in some class (maybe Game, or something like that), and another class which is responsible for rendering UI/HUD elements on screen will exist elsewhere. Data does need to pass from other objects to the object that does the rendering but they don't have to both be members of the same containing class for that to happen.

Why can't you have the health bar as a member variable in your Player class, rendered above/around your characters? You can still have a separate HealthBar class with its own sprites and render method. I doubt that any approach you take to implementing health bars could be inefficient enough to matter.

EDIT: I checked out your other thread, and now I understand what you're describing. In the same code that displays your other HUD/UI elements you can include instances of a HealthBar class (or whatever other approach you want to take). It will need to take information from your Player instances anyways, to show each player's current health, and at the same time you can pass information on the characters' onscreen locations to render the health bars in the right locations. You don't need a class to be static for it to provide information to other classes.

So I should render the health bar itself in the same class where I have the instances of my player objects?

It depends on the structure of your code, but probably not. Your Player instances will be in some class (maybe Game, or something like that), and another class which is responsible for rendering UI/HUD elements on screen will exist elsewhere. Data does need to pass from other objects to the object that does the rendering but they don't have to both be members of the same containing class for that to happen.

Oh so the class that actually handles the rendering elements... Lol sorry should have payed a bit more attention the first time. So I don't necessarily have to make a separate class for my healthbar? I just kind of assumed it would be inefficient not to.

Thank you for your help, by the way!

Oh so the class that actually handles the rendering elements... Lol sorry should have payed a bit more attention the first time. So I don't necessarily have to make a separate class for my healthbar? I just kind of assumed it would be inefficient not to.

It may be a good idea to have a separate class define a HealthBar object, if only to define its on-screen dimensions and location and store the sprites that will be drawn. The instances of HealthBar can be instantiated anywhere that makes sense for your code, updated with player health values when your game logic updates, and then rendered along with everything else in the render loop.

Other design approaches exist which will work, but I think that HealthBar objects will be easier to work with both conceptually and for code maintenance. Again, efficiency (in terms of code performance) in this case will probably not matter much.

Thank you for your help, by the way!

Happy to help! I hope my suggestions are of some use to yo.

Oh so the class that actually handles the rendering elements... Lol sorry should have payed a bit more attention the first time. So I don't necessarily have to make a separate class for my healthbar? I just kind of assumed it would be inefficient not to.

It may be a good idea to have a separate class define a HealthBar object, if only to define its on-screen dimensions and location and store the sprites that will be drawn. The instances of HealthBar can be instantiated anywhere that makes sense for your code, updated with player health values when your game logic updates, and then rendered along with everything else in the render loop.

Other design approaches exist which will work, but I think that HealthBar objects will be easier to work with both conceptually and for code maintenance. Again, efficiency (in terms of code performance) in this case will probably not matter much.

Thank you for your help, by the way!

Happy to help! I hope my suggestions are of some use to yo.

Yeah they were DEFINITELY useful. I got it working in an extremely efficient way that uses the player object's name as a parameter :D

you should make two healthbar instances - one for player 1, one for player 2.
each only needs to worry about its own player. So, in the appropriate spot in code

healthbar1->setValue(player1->getHealthPercentage());
healthbar2->setValue(player2->getHealthPercentage());

where Player::getHealthPercentage() is essentially just { return (health * 100) / maxhealth; }

or the healthbar class can store a reference to its player and get this information itself.
or you can create a class to specifically calculate the ratio of two integers as a percentage, IE:

class PercentageOf
{
int #
int &denom;

public:
PercentageOf(int &_num, int &_denom){ num = _num; denom = _denom; }

operator int() const { return (num * 100) / denom; }
};

I'm a fan of classes like that, because it allows one complex class to perform logic using another complex class's members without any knowledge of that class at all. But making them and using them is a little awkward, so maybe not the best choice for a beginner.

or you can create a class to specifically calculate the ratio of two integers as a percentage, IE:

class PercentageOf
{
int #
int &denom;

public:
PercentageOf(int &_num, int &_denom){ num = _num; denom = _denom; }

operator int() const { return (num * 100) / denom; }
};

I'm a fan of classes like that, because it allows one complex class to perform logic using another complex class's members without any knowledge of that class at all. But making them and using them is a little awkward.

It's fine that you're a fan, but to a beginner this is just highly confusing. Please try to keep things as simple as possible in this forum.

You(null;) seem to have already solved your problem but I still have some doubts about this issue ( being a beginner myself ).

When I experienced this problem of object references, I created a GameObject class which was the parent of all game objects. The game object class had no default constructor but one constructor which takes a string argument. The GameObject class also consisted of a std::map from string to GameObject. So, in the constructor the object created was added to the map with the string argument as its id. The GameObject class also consisted of a static method 'get' which returned a object given its id.

I don't know whether my approach is correct, so I'm not recommending it to anyone but instead asking for expert review since after this discussion I'm doubtful about my approach. Please review!

The problem in this method seems to be about downcasting to the real type of object( Since I'm using C++ not Java ). Since I never felt the need of downcasting ( I put all the usual methods in GameObject class itself ) I didn't ponder more over this issue. But now I'm looking for correcting my approach.