Globals underrated continued

Sorry, in the last post, instead of saying "you don't want any global accessed from anywhere" what I meant was "you don't want every global accessed from everywhere."  You do want some globals accessed from somewhere.  It's going to be really hard to convince me that Mat Noguchi's proliferation of pointers is a good thing, unless they're smart or shared.

How would I enforce layering without a proliferation of pointers?  One could use code review, etc, to get all the coders on the same page about the ideal you're trying to live up to, but if you want to do something in code, and the layering has the same level of coarseness I talked about in the last post, I'd use libraries.  Game.lib (or exe) would depend on both Renderer.lib and GameMechanics.lib, but Renderer and GameMechanics would not depend on each other.

You might wonder why I'm keen on separating game mechanics from the renderer.  Reason A is because I'd like to make games like Civilization Revolution that run the same game mechanics on wildly disparate platforms (DS & Xbox).  Reason B is it appeals to the game designer in me - I like to think of the game mechanics as being a sort of pure form separate from interface.  (Though in reality no game can be separated from its interface, it is a fun and useful thought exercise.)

Comments

[Soren Johnson]

For Civ4, we completely separated the game code from everything else, so much so that you can compile the game/AI logic separately into its own DLL. This allowed us to release the game code so that modders could create their own game DLL to overwrite the default, leading to total conversions like Fall from Heaven. (You can find the code here: http://www.2kgames.com/civ4/downloads.htm)

And, yes, we used globals too...

[Mat Noguchi]

Heh, I'll throw even more fuel onto the fire and state that you don't need smart or shared pointers if you have a strict enforcement of lifetime plus some constraints on what you use pointers for. I prefer the same model as http://misko.hevery.com/2009/04/15/managing-object-lifetimes/ : you store references to other objects if they have a longer lifetime, otherwise, pass it via the stack. So I don't use smart or shared pointers for that, just raw pointers. Whee!

It works out pretty well for our caching system, although you get some weirdness when dealing with legacy code. (And yes, that kind of blows the ideal out of the water.)

[Bryan McNett]

read/write globals are dubious in single-core, and prohibited in multicore - unless it's a simple game and it's OK to let cores sit idle.

this is because multiple frames are processed in parallel across multiple cores. if there were read/write globals, maintaining data coherency across frames becomes costly or impossible.

except wii, all console and PC platforms are multi-core already, and the number of cores is scheduled to grow faster than moore's law.

don't say nobody warned you.

[Grumpy]

Are any of the people who are raging about global variables good game programmers, by which I mean, specifically, developer/artists/designers who happen to make novel or interesting content that has a code component, particularly for games of new or ambiguous genres? I'm sure many of you are brilliant systems and engine programmers, which is great in the right contexts.

My own personal experience has been that global variables (and, in general, ditching all notions about aggressively constraining what can access what and dealing with "architecture") are really useful for fiding novel game play in an iterative context. I'll readily concede that these practices are bad for big teams, high performance requirements (especially multicore), client/server issues, persistence, and blackbox reuse... but when it comes down to "how hard is it make and evolve novel, innovative, surprising interactivity, particularly at a large scale, between elements of the game that players weren't expecting", my personal experience has been that there is a direct and specific correlation between "good engineering practices" and "high performance, beautiful, astonishingly predictable and tedious game designs".

New and novel game styles thrive on unexpected (to the player) interactions. Code is how we describe interactions and correlations. Unexpected interactions are specifically the sorts of things good engineering practices are designed to eradicate or make extremely irritating to explore.

If, on the other hand, your job is to make the next Madden or another Iraq colored FPS, where performance and asset quality is most of what you're shooting for... well... yeah! Down with globals!

[Mat Noguchi]

> Code is how we describe interactions and correlations. Unexpected interactions are specifically the sorts of things good engineering practices are designed to eradicate or make extremely irritating to explore.

Umm... I will argue to the death that code that has unexpected consequences is the very thing that prevents you from composing it with any degree of sanity. One way code can have unexpected consequences is by accessing mutable global data explicitly. If it happens to be global but the code never knows that, then it doesn't matter.

Emergent behavior does not require crappy code. In fact, good emergent behavior requires quite robust code, as it is less likely to cause real problems by stressing it in unexpected ways.

[Jake]

If you are a good programmer you dont need global variables. Here http://www.rapidsloth.com shows how you can program without the use of global vairables.