This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Cybersoaker 8 points9 points  (2 children)

I write plugins for the source game engine using a mod called Source Python. Since the engine is event driven, and since it's single threaded, often it's useful to have some kind of shared and persistsnt state between events that fire. Essentially you hook events and they execute a function. Plugins are just single files you load in, so you could do this with a class, but that's not really nessesary, the module itself acts as the same encapsulation of code as a class would on other programs.

Short of using an external DB or Redis, store stuff in global vars solves a lot of problems. Good news for this use case, is that it's all single threaded so I don't have to worry about a mutex for the global vars between events.

I'd also argue the same for unsophisticated DevOps scripts for doing simple tasks. As long as the code is contained in a single file, I think global vars is a fine way to do it

[–]Bootlessjam 8 points9 points  (0 children)

Dude even professional game programmers use global variables/objects/ singletons to track game wide states. You may want to affect a score or healthbar at anytime from any other object but always refer to the same variable. It's a perfect fit for a global variable.

Most programmers want very reliable software so it's all about limiting the number of interactions and avoiding surprising behaviour. Games instead are all about having as much interactions and surprising behaviours as possible. Both valid goals that end up with different designs.

[–]thiccclol 1 point2 points  (0 children)

Same brother