Work continues in the background and 'fraid there isn't really much exciting stuff to show at the moment (or for a while as game logic, etc. gets added in).However, I have a question for those in the know.
Q: How often do you use Global variables?
I noticed recently that every entity in the game has a member GameWorld *m_pGameWorld which is the resource an entity uses to obtain various bits of information about the overall game world.
This seems to be quite a redundant use of identical pointers, so I'm inclined to think that a global "g_pGameWorld" would be more useful, safer (as only one initialisation required) and be more efficient.
I was taught that, for the most part, global variables are to always be avoided as they lead to bad coding practices, badly connected hard-to-understand code, etc. and that objects should only take what they need via arguments and via object-specific methods/members. But it seems silly... really, for something like this.
OT: Got hold of RetroGAMER 47 on eBay. Cool articles on the development of Magic Carpet (was interested to note Glenn Corpes used the 'leave dead entities and re-use later rather than dynamic allocation' method discussed in the Scanners blog entry a few days ago) and also a big section on Elite. I wish I'd subscribed to this mag before many back-issues dissapeared... :[
I guess it all depends on whether there will ever be more than one game world in your game at any given time. If that's the case then why not ?
ReplyDeleteCoding practices are good and all, but mostly so you know that when you break them you find a good reason for doing so. :-)
Yep, that's just it. There will only ever be one instance in the game at any time, and all references will only ever be to that one instance, so I guess it's safe.
ReplyDeletei.e., if it was in danger of being de-allocated and re-allocated then the pointer location might change, but that won't happen as it is only allocated once at runtime.
Part of me thinks there's a more graceful way to handle these situations.
A friend suggested using a singleton class (which is how the message dispatcher and entity manager work), but for something like this a simple global is probably the best route.
"Coding practices are good and all, but mostly so you know that when you break them you find a good reason for doing so. :-) "
Yep, my thoughts exactly!
I personally, never use actual global variables. However, as you know, a Singleton class is more or less a global variable with a few exceptions. The big thing that I really do like about singletons are that there can normally only EVER be one of them. Typically the constructor is private, or all of the member variables and methods are static. This way you avoid any possibility of instantiating more than one. Also, you always know where the instance is. There is no chance in while codeing to say to yourself, hmmm, in what file or class did that global member variable go? Anyways, that just my two cents.
ReplyDeleteMonkeyTank: Thanks (sorry, didn't see this comment!). I recently moved all the remaining globals to singletons (where appropriate for a one-time-only class).
ReplyDeleteI'm habitually lazy, and statements like:
MyClass::Instance()->Function()
always feel longwinded to me. I've seen people use macros
i.e., #define MCls MyClass::Instance()
but this seems worse to me than using a global! :)
Thanks for the comments.