Sometimes I find that 'good' OO game design gets in the way of me getting stuff done.

One such problem that I'm currently wrestling with is the question of where the random number generator should reside.

I've got a class called "Game" which seems to be a natural place for it to go; but most of the game mechanics is actually done in the class called "World", and that's where most of the random numbers are needed. (Game has a World member variable.)

So I put the RNG inside World, and the Game class is allowed to use its world to get random numbers when it needs to.

However... now I've made a new class called MapGenerator, which is meant to be responsible for generating random maps – so it needs access to the random number generator as well, but there's no other reason for it to see anything else in World or Game or anything like that. And in the future, I'll probably think of new classes that are going to want to use the RNG...

The bottom line is that I'm starting to think the I should just make the RNG global, so that everything can use it. Or.. alternatively I could make it so that World, and MapGenerator, and anything else that needs the RNG, all require a reference to the RNG object in the constructor...

I'd just be curious to know how other people deal with this issue. Where should the RNG live so that everything that needs it can use it?

If your game will implement loading/saving, or demo saving/replaying, or if it will be a game server for multiple games taking place at the same time : It will help if you have one class that can store all the "state" of a game in progress. In that case, the RNG state is one of these pieces of data.
Otherwise, global is fine.

If you don't plan having several instances running at the same time, you can make it a singleton, which is kind of global, but provides mechanisms to ensure only one instance of the class is created.

That's a good question.. and I suppose the answer is that they don't really need to use the same instance. But I do feel like they should use the same instance from a resources point of view. (Allegedly, the rng I'm using uses approximately 625*sizeof(uint32_t) bytes of memory.^[1]) Also, I've written a few helper functions for generating random numbers in particular ways. Those helper functions need to refer to the rng - and I'd prefer to not have to pass the rng as an argument, or duplicate the functions.

As for the singleton suggestion. I've forgotten what the advantages of doing that are. Is it something to do with guaranteeing that the constructor / destructor will run?

I wouldn't suggesting having the RNG be implemented in multiple locations unless there is a very good reason to do so.

Take a casino game: the RNG is actually server-side so they can ensure that a programmer doesn't give too much favor to the player, and so they can keep track of their algorithm effectiveness.

In a multiplayer game, you need two RNGs: one that doesn't matter or affect anything (like for a particle system on a local client), and one that does (like where something will respawn). The "don't matter" ones are usually implemented in the Application:: scope, where everything has equal access to it, and it can be as pseudo-random as you want to spend time implementing.

The "does matter" ones are usually implemented in the Game:: or Network:: scopes, where the pseudo-randomness comes from the main server (external or on the same system, is the same).

I would probably avoid the global state myself. Of course you can get it done with global state, but is it the best approach? I would say no. I would probably add a property to every object that needed a RNG and pass it in through the constructor. I wouldn't likely use references though, because there's no way to know for sure that the referenced object still exists, and it's not clear from the caller's perspective that a reference is kept. Since you're already using Boost, you have a very simple solution: boost::shared_ptr<T>. You can share the RNG with as many objects as needed without worrying about wasted memory or violating best practices. Perhaps something like this:

Ok. A lot of people have expressed disapproval of making it global. Having it global is the easiest way of doing it, but I agree that it's probably wise to stick to good OO design. I still don't really want to pass RNG pointers / references around though (mostly for aesthetic reasons).

So how about the half-way house: a singleton^[1].

With that the RNG is effectively global, but any class that wants to use it must explicitly have a RngAccessor member.

What do you think? Better than global? Worse than passing references?

It didn't occur to me earlier about the benefits of separate RNG's for demos and cut scenes earlier, but now that I consider it, it seems an excellent idea. Using a reference for private data is a miniscule chore compared to this.

It's much worse. Worse even than using a global. If two separate classes need to share the same instance of your RNG, then it makes perfect sense to instantiate the instance of RNG in the containing class and pass a reference into the constructors of the classes requiring it.

A singleton is totally the wrong pattern in this case since there are times when you will want separate instances of RNG. Also, think of someone looking at your code for the first time: in the case of the singleton, it adds unnecessary complexity and confusion. A new programmer may think "should I use the singleton or create my own instance? Is it safe to use the singleton here? Is it even really a singleton?! Why has he used a singleton, is there something dirty here I don't know about? Is it thread safe?"

On the other hand, if you simply use a reference in the constructors, it's immediately obvious what is going on. In fact there's absolutely nothing special about your RNG class that it should require a singleton - it's not even that uncommon to see two or more objects reference a common object: if you used a singleton in every case your code would be a total mess.

Technically I think a simple global is an implementation of the singleton pattern.

But, I agree, singletons as they are usually referred to - a class with a single instance and a static method to obtain a reference to that instance - does seem to be mostly pointless. Once in a while it is useful in managing initialization order but frequently it serves no purpose at all. Likewise his accessor thingy, which might be considered a singleton implementation, serves little purpose.

edit:
Actually, I want to back away from that position a bit - initialization order problems are actually not uncommon at all, and singletons are a reasonable solution to them. I have seen singletons used a bit on things that had no initialization order problems, but maybe that's a matter of better-safe-than-sorry.

FYI, even when you only want one instance of something, a Singleton is a bad idea.

bamccaig: Be more specific. What is your recommended fix for the problems that normally arise due to initialization ordering on C++ globals, which is normally handled with a singleton?

Get over your obsession with hating globals bamccaig.

Imagine Allegro 4 without globals :

screen -> GetScreen()
mouse_pos >> 16 -> GetMousePos() >> 16
palette -> GetPalette()
mouse_b & 1 -> GetMouseB() & 1
key[KEY_ESC] -> GetKeyArray()[KEY_ESC]

Instead of nice, easy to work with globals, you now have a bunch of wasteful accessor functions returning copies of data for no good reason.

Also, singletons have two good things going for them :
1) You can't access a singleton before it has been constructed properly. This makes global constructors work in the correct order.
2) Some classes shouldn't be instantiated more than once, due to heavy initialization or use of system devices.

That said, unless you need to enforce a single instance of a class, or ensure your class is constructed before it is used, then there's not much reason to use a singleton.

Really, get over your hate for globals. Sometimes they're appropriate.