Or did you have to do a bucketload of math to work out where to place things?
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 :)
I just launched this little game of mine - Astro Golf. You can think of it as Desert Golfing but in space, where the gravitation pull of the planets create some interesting levels. I think it was on an HN comment that I first heard about Desert Golfing many moons ago, so it felt fitting to post this back here.
All the levels are procedurally generated, and are guaranteed to be hole-in-one-able. I did this by computationally testing a huge amount of levels offline.
This is my first game, and I learnt a lot doing it. Happy to answer your questions! I hope you enjoy it.
Peace