Sign in to follow this  
squidlarkin

a global threat

Recommended Posts

squidlarkin    122
I'm working on what is basically my first C++ project of any appreciable size, and it's coming along great, I'm learning a ton. But my code is a horrible mess. I know that it's considered a good idea to have as few global variables as possible, and to chunk your code into manageable functions, but so much of my code needs to be aware of so much of my data. Things like my player object and the number of ticks in the current frame are referenced almost everywhere, so I make them globals. Now almost all my game data is global. Can anyone point me to some useful reading for understanding the whys and hows of proper variable scope?

Share this post


Link to post
Share on other sites
ToohrVyk    1596
Quote:
Original post by squidlarkin
I know that it's considered a good idea to have as few global variables as possible, and to chunk your code into manageable functions, but so much of my code needs to be aware of so much of my data. Things like my player object and the number of ticks in the current frame are referenced almost everywhere, so I make them globals. Now almost all my game data is global. Can anyone point me to some useful reading for understanding the whys and hows of proper variable scope?


Your problem is not about variable scope, but rather one of design. The player object, for instance, should certainly not be used everywhere — aside from the game itself, I don't know who else should know about the player. The physical world? Nah, the player is an object like any other, the world doesn't need to know it is the player. The enemies? Nope, the player is a hostile object in sight like any other, the enemies don't need to know it's the player.

In short, all physical objects (and nobody else) should know about the world they live in (which provides queries to locate the nearest object(s) that correspond to a given filter) and about the objects they collide with. The player doesn't come in anywhere here — the game needs to create one at initialization and insert it into the world, but nobody else needs to know that it's a player!

The same goes for the ticks in the current frame. It's used to update the movement of physical objects, which are all handled by the world, and the various timers which are owned by objects (which are also handled by the world). However, your average object doesn't need to know about the time (or, worse, the time delta) at all!

You seem to have a view that is too global. Your modules should be modular: they shouldn't depend on many other modules to work.

Share this post


Link to post
Share on other sites
squidlarkin    122
This is helping a bit, but I'm still having trouble wrapping my head around just how to handle scope in OOP. I'm sure it's completely intuitive once you've worked with OOP for a few years, but well... I haven't.

Here's another example I just ran into. I've got a handle to my sound system that's needed whenever I want to play a sound. If I have a FireShot() function, then of course I need to pass the handle to it so I can play the sound of the shot being fired. But if FireShot() is being called from GetInputs(), then I need to pass GetInputs() the sound handle, along with anything else that could possibly be needed by any function that GetInputs() calls. This seems wrong to me.

Share this post


Link to post
Share on other sites
Zahlman    1682
FireShot() isn't properly a global thing; there will likely be several firearms in the world, and each should be able to .fire(). Because guns can make noise, they should have-a sound_handle, and then you make a call through the m_sound_handle within .fire().

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this