Large game project, local variables [closed]

Question

I'm hoping that some experienced programmers can give me their point of view. I'm writing a large game in Windows with dx11. So far, I've got global objects of the class that interfaces with dx11, the class holding the position of the camera, the terrain data class, and a few other classes. In future, if I kept going with this way, I'd also have objects for all the game data, and so on.

I'm thinking it might be best to rejig the code to only have local variables, because generally this is regarded as a Good Thing, but mainly because I personally have come to prefer using them. Here's some rough c++-ish pseudo-code of how I imagine local variables would be implemented:

WinMain()
{
  cDirectX dx;
  cCamera cam;
  cTerrain terrain;
  ...
  while (msg.message != WM_QUIT)
  {
    ...
    gameLoop(dx, cam, terrain, ...)
  }
}

void gameLoop(cDirectX &dx, cCamera &cam, cTerrain &terrain, ...)
{
  ...
  renderTerrain(dx, terrain);
  ...
}

Is this (very roughly!) a good way to organise such a project? I suppose WinMain is the only function where the locals can be instantiated?

The only disadvantage I can see is that top level function calls (by which I mean, functions like gameLoop(), functions at the bottom of the call stack) will have very long lists of arguments. Perhaps this doesn't matter.

Thanks, Paul

Answer 1

The thing that breaks complicated programs is not complexity. It's dependencies.

The main advantage of not using singletons, globals, etc etc is that it significantly reduces what I've termed "spidering dependencies", where global variables are used throughout the code. Making any modification to how those systems work fraught with the possibility that some other downstream system may be relying on a particular behaviour.

So, what you want to do is work on minimising dependencies between subsystems.

For example, I've seen many games where randomly within the physics system the global HUD subsytem will be retrieved and have data poked to it, or worse, animations in the HUD started from the physics system itself, meaning any change to the way the HUD spawns animations may break something in the physics engine!

There's a few ways to "fix" this. All solutions stem from clearly defining the boundaries for your subsystems, and understanding what data needs to flow in, and out of them.

I'm a big fan of asynchronous messaging as part of this solution, as it removes the concept of "immediate" from the game engine. You have to request things from other subsystems, which will be fulfilled at some point in the future. So your systems must be able to deal with an intermediate state. (eg: resource requests result in an intermediate "ghost" resource which is handed across while the actual resource is loaded).

I'm also a fan of using intermediate layers between subsystems, such as our HUD and physics engine. The HUD should never be responsible for changing game state directly (it should post an asynchronous message when something has happened which is then handled by the game state) and it should certainly not know about anything in the physics engine. Our physics engine still needs a way to, for example, post the speed of the player to the HUD. So we can achieve this by posting to an intermediate layer under a "key". the HUD can then query this layer using the same "key" to retrieve the data. The HUD then does not know, or care about how the data reaches this layer, just that the data is there.

So, TLDR: try and minimise dependencies. Removing the use of globals is a good step. However, if you're just making a small game this may be more overhead than it saves, but always focus on keeping unnecessary dependencies to a minimum!.

Answer 2

Well... as for DX instance, there will be only one (I suppose), so it should be declared globally. For the rest. Terrain should be part of some "model pool". So basicly, sou have all models at one place (this pool can again be globaly - as singleton). And you can obtain models from that pool. Camera goes with your scene management. Usually, there will be only one camera. But for some purposses (water, shadows etc.) you may have different camera (projective and view matrix resp.). In that case it will be better to have some kind of rendering manager, that will hold informations, what you are rendering and which camera to use.

In my engine, I do it this way:

SceneManager.setRenerer(dx); //I have engine multiplatform, so there also could be gl, gles...all rendering is done via abstract classes and main functionality is hidden for "user" of engine
SceneManager.addRenerableObject(terrain, "Terrain");
SceneManager.addRenerableObject(house, "House#1");
SceneManager.addRenerableObject(player, "Player");

SceneManager.bindPlayerToObject("Player")

SceneManager.UpdateCameras(); //each camera is updated based on binded player position and rotation

....

SceneManager.RenderAll();