This is the problem: there is a game-stat, and that game-stat is displayed to the player on the HUD. OO speaking, how should the graphic element and value element relate to each other?
I usually make a "normal" game entity have all its variables. Then it knows what to do for a update() and a draw(). For a HUD element, even though it shares the same methods, I'm reluctant to do that.
For instance score. Let's say the score is a multiple of 100, but the representation when the score changes rapidly goes over the decimals and units. (You probably know this effect.)
If there is a separate ScoreHUD object, it has to query the actual score for each draw, AND remember what the last value was.[1]
If there is a Score object that knows how to draw itself, all changes have to go through that object, AND it needs to be queried any time some other part of the game needs to know the score.[2](Temporary power-ups might be a better example for this.)
Both sound like they have set-backs. I guess, you could go for event-listeners or (some other kind of) message passing (?). But maybe that's giving up speed for superficial "cleanliness of code". Especially if this would be the only part that benefits from such changes[3]
Any thoughts, rants, reading, or other on this?
References
- I actually do this now. I actually give each HUD object a
pointerreference to the stat or object that holds the stat that they have to draw. - Now I'm leaning towards this solution. Probably gonna put all HUD objects into a big struct/class then. Maybe I only like this solution, because it's different...?
- Yes, I bet there are probably tons of things that get better magically, if I'd use some well-known design pattern.
You said it in the square brackets. Also remember it'll be easy to change later if you need to[1]. Get back to work 
References
- unless you over-engineer it.
unless you over-engineer it.
I think this is the essential part. Thanks for mentioning that. When I start thinking, I don't stop thinking. I then sort of over-engineer out of insecurity.
Another rule to add to my personal book: if you can't think of a better solution, don't try to make a better solution.
if you can't think of a better solution, don't try to make a better solution
I like that a lot.
I lawled.
Also, sigged.
To me, the natural design would be as follows:
The actual value of the stat is owned by the primary object that it relates to (e.g. the player object). Anything else that wishes to use this stat interfaces to the object that owns it.
Lets suppose you wanted to re-skin your game: if you have a clear interface to the underlying stats, it becomes easy to write a whole new HUD from scratch that uses the same interface. I'm also in favour of totally decoupling the core game logic from pure "eye candy". A good example being what you just mentioned: the score. The actual value of your score should sit in the core game logic, but eye candy (such as spinning up the score when it changes) should exist in the "front-end" logic.
I think that's pretty much what you're doing in 1), and think it's a far better OO design than the other options.
giving up speed
We're talking about a few bytes/referenced here, so you shouldn't even be thinking about speed.
I would just keep a reference to the actual value in the HUD element object.
Simple, easy and fast. Dereferencing is surely less expensive than passing messages around.
I like that a lot.
I lawled.
Also, sigged.
Cool, cool, cool.
Dereferencing is surely less expensive than passing messages around.
That's what I was talking about. And of-course: once you have an almighty design pattern you have to subjugate all your hard-working code to it. That might actually impact how fast things go.