A few weeks ago I wrote a VERY similar post about my Logger class and the debate over the use of Singletons.
I’ve done the same with my new randomization class, LRandom(). LRandom does several things under the hood, and is a singleton for a very specific reason. First, I wanted to use it to replace the random class that Dungeon Architect uses during initialization of a dungeon or map. In part because I wanted more control over randomization, and in part because I wanted all aspects to produce the same values with the same seed. Previously, at least in earlier versions, DA would produce the same dungeon layout, but things like decorations and extras would not always be the same.
Additionally, I wanted the same random class to be able to control other randomizations during play: loot, die rolls, et cetera. The current implementation uses a single System.Random instance, though I may extend this to have several – one for dungeon building, one for loot, one for mob AI, and so forth.
Also, the state of the System.Random is stored in a serialized file on exit. This should, in theory and after a lot more work, allow one to pick up where they left off with the state of the randomizer where it was before. The main goal here is to prevent “known randoms” with the given seed. The first chest you run across won’t always have the same stuff.
The class also contains the original DA methods for NextGaussianFloat() and GetNextUniformFloat() to integrate without changing a lot of the DA code. And lastly, it contains methods that allow the instance to be reseeded if need be, which is mostly good for debugging, but may have benefits during runtime as well.
So, currently, LRandom() and LLogger() are two singletons that I’m using that have proven very beneficial. If you missed my last post, or want to hear more about Singletons (the good, the bad, and the ugly, so to speak), check out this great podcast from The Debug Log- Episode 73: Design Patterns: Singleton.