One other side note: the two pictures in my last post show different games in which I moved down about 20 steps to get a good picture; you’ll notice how the game state (monsters’ positions and dropped items) is the exact same between them. This is because I ensured that I’m seeding the random number generator with the same value so that given the same inputs, the same outputs comes out the other side.
There are a number of reasons to do this, but one thing in particular I want to enable for Beta is logging all inputs and enabling testers to send me the list of inputs. In theory, if the beta user hits an error, this will allow me to completely replay the game all the way up to the point that they hit the error, pause the game, and get a much better understanding of what’s wrong.
One interesting catch is that I had to refactor my random generator class into several instances, and be sure I’m calling the right one for the right purpose. This is because there are a number of time-based random values (animations, particle positions, etc), and grabbing the ‘next’ random value from the generator for those causes things to change. So I now have a “gamestate” random generator (e.g. for generating dungeons, determining damage dealt, etc), and an “animation” random generator used by animations, particles and the like.
There’s one more scenario I might want to eventually enable – the idea of “global challenges.” These would encompass a single dungeon that is reset each week and which everyone can play and compete for high scores, world-firsts, etc. There are two ways I could do that – one is that everyone plays different dungeons, and the other is that everyone plays on the same dungeon. I like the latter for a variety of reasons (and actually consider the wiki-ability of it to be a good thing). However, it requires that I create a third RNG, specifically for level generation and population.