Lots of interesting troubles - quite a few surrounding Unity itself. E.g. they have a physics API that gives different results when run automatically by the engine at 1x speed and when you run it manually as fast as it can go. This came up because I wanted to test every level automatically offline, using the exact same physics simulation as the player would experience.
The procedural generation of the levels was also an interesting problem. I used rejection sampling to basically place non-overlapping circles in a box, but when you want to create quite a dense level this becomes very inefficient (it can be very hard to slot the final few circles in). I tried a number of heuristics and other methods to speed this up, but none of them actually improved over brute force. One of the most interesting was using Gibbs sampling - i.e. generate an initial valid level configuration, then move one planet at a time and sample from the ensuing Markov chain (basically sampling from the marginal distribution of each planet given all the others). This ~kind of worked, but was annoying for a few reasons so in the end I just brute forced rejection sampling on a beefy AWS server :)
Not a stupid question - I did some small amount of experimentation with voronoi, but I also had some global constraints / parameters that I wanted the levels to have and these were more easily implemented in the sampling method.
