Allegro.cc - Online Community

Allegro.cc Forums » Game Design & Concepts » [Bikeshedding]Does a HUD element hold its value?

Credits go to Bruce Perry for helping out!
This thread is locked; no one can reply to it. rss feed Print
[Bikeshedding]Does a HUD element hold its value?
weapon_S
Member #7,859
October 2006
avatar

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

  1. I actually do this now. I actually give each HUD object a pointer reference to the stat or object that holds the stat that they have to draw.
  2. 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...?
  3. Yes, I bet there are probably tons of things that get better magically, if I'd use some well-known design pattern.
Bruce Perry
Member #270
April 2000

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

  1. unless you over-engineer it.

--
Bruce "entheh" Perry [ Web site | DUMB | Set Up Us The Bomb !!! | Balls ]
Programming should be fun. That's why I hate C and C++.
The brxybrytl has you.

weapon_S
Member #7,859
October 2006
avatar

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.

Thomas Fjellstrom
Member #476
June 2000
avatar

weapon_S said:

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

james_lohr
Member #1,947
February 2002

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.

weapon_S said:

giving up speed

We're talking about a few bytes/referenced here, so you shouldn't even be thinking about speed.

l j
Member #10,584
January 2009
avatar

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.

weapon_S
Member #7,859
October 2006
avatar

I like that a lot.

I lawled.

Also, sigged.

;D Cool, cool, cool.

taronĀ  said:

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.

Go to: