I'm making a game using LOVE, so everything is programmed in Lua. I've been experimenting with using classes and object orientation recently. I've found out that a nice system to use is having most of the game's code in different classes, and having a table of instances with all of the instances of any class in it. This way, I can go through every instance of every class and update and draw it by calling the same function.

There is a problem, though. Let's say I have an instance of a player with variables for health and recharge time of a weapon. I also have a master instance which is responsible for drawing the HUD. How can I tell the master instance what the player's health is? Bad solutions:

  • Assuming that the player instance will always have the same position in the table - that can be easily changed.
  • Using global variables. Global variables are evil.
  • Have the master instance outside of the instances table, and have the player set variables inside the master instance, which it then uses for HUD drawing. This is really bad because now I have to make a duplicate of every variable the master instance needs.

What is the proper, standard way of sharing variables between instances? Do I need to change the way I keep track of instances?

Edit: the hump library for LOVE has a signal/slot system. Would that be a reasonable way to share variables between instances?


1 Answer 1


From the easy to the scalable and complex to implement, kind of:

A fast to write option is simply to let the HUD know where the player is and let it grab what variables it needs directly. It's not very flexible, but for games where the player is well defined and the scope of the game is tightly contained it can work well enough. This is a tightly coupled solution.

Add some structure to the attachment and get...

Another option is to take a look at MVC (model-view-controller) architectures. There are a few varieties but the basic idea is that the model only deals with data (ie. your health) and has one or more views (ie. your HUD) that attach to it and retrieve the data either immediately when it needs it or more commonly the data tells any views when its value changes. The controller you won't have to worry about for your needs. This is a moderately coupled solution, someone somewhere has to directly connect all these models and views.

Then add a go-between so you don't have to connect directly to the object and get...

Another option is a messaging system where there is a global post office. The health sends letters to the post office, who then delivers copies to anyone who's registered to receive things like that. Or vice versa, your HUD can send a letter asking for players to send back their health. This method is very flexible, nice to have in dynamic environments where players come and go constantly. Much less coupled, and gains flexibility.

And add a layer of smarts to the data itself so both sides are talking to the data instead of holding it, to get...

A third option which is more database-like would be to keep one global table of character data (like health) that the character writes to and the HUD queries from, using some kind of ID (identifier) to let the database-like table know what you're asking for. This is kind of like how large, complex games like MMOs work. Barely coupled at all, like the post office your data can come from anywhere but it also includes a layer that neatly packages it for you and streamlines the send-receive-respond cycle.

  • \$\begingroup\$ As the asker said: "Globals are evil!" And so is decoupling for the sake of decoupling. +1 for the first paragraph, but sad to say -1 for the rest: using vague metaphors instead of standard terminology like "observer" or "pub/sub", suggesting globals for decoupling, and the remark "kind of like how large, complex games like MMOs work" seems irrelevant. \$\endgroup\$
    – Eric
    Sep 26, 2012 at 9:25
  • 1
    \$\begingroup\$ As a response to a new programmer I don't think that he'd get the most out of jargon and a pile of links, instead I decided to roll out some ideas to explore in the hopes of generating further answers. Global interfaces are a far cry from global variables which is the main concern, without them all frameworks and engines would disappear. Please follow up with an answer for the asker, you have valuable observations he can learn from! \$\endgroup\$ Sep 26, 2012 at 15:29
  • \$\begingroup\$ Don't worry, I'm not that new of a programmer. I'm just not used to using object orientation outside of Game Maker. Can someone confirm if a signal system is a good way to pass variables around? \$\endgroup\$
    – tesselode
    Sep 26, 2012 at 16:53
  • \$\begingroup\$ @PatrickHughes As I said, I agree with your first paragraph: just give the HUD-instance a reference to the Player-instance. From what I understand the asker has an object model that works for him, and while alternatives are good, it seemed to me there was no need to suggest a rewrite to MVC or an MMO-like object database querying system. That's all. :-) \$\endgroup\$
    – Eric
    Sep 29, 2012 at 18:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .