Falling Rocks - technical issues, solutions, and learnings

Here are some things I found interesting about developing this app, including learnings, problems, and solutions:

For general architecture, I found it is better to let gameobjects take care of themselves, rather than having a "god" script that controls everything from "above." For example, I wanted any existing rocks to disappear on levelup. At first I had a method that looped through all the rocks and inactivated any active ones. It was not performant. Instead, in the Rock script, I have each rock observe the game state in the Game Manager script, and when the game is between levels, make itself disappear.

For scenery, I started out trying to use BlockadeLabs to AI generate the scenery, and it did a good job. However, the unpaid version creates a watermark at the sky zenith, which in this app is the most significant part of the scene, so that was unacceptable. I could edit it out, but I thought that was unethical. The only paid version was by subscription, which I wasn't willing to pay. So I found skybox assets instead. In the skybox settings, unchecking Generate Mipmaps fixed unsightly seams so that they barely show. I edited some of the images to create stuff on the horizon, such as buildings and hills.

I used Runway ML to AI generate the thumbnails for the achievements, and I really like the way they look.

I had a friend try the game, and he managed to turn the gun on himself, which hadn't entered my mind. I didn't want my game giving rise to such thoughts, so I disabled that action by turning Force Grab on and Anchor Control off. Now touching the gun snap turns it so it points away.

I originally started with the main menu on the left wrist, but then I thought about left-handed people, and possibly one-handed people, playing. I didn't want to make a "menu hand" setting nor deal with reparenting the menu, so I put the menu on the gun. It was hard to get the poke interactor working there due to close geometry.

Parenting the other menus to the Camera Offset worked well. Parenting them to the camera worked poorly because it would force users to look at them by moving their eyes only (and not their heads). Parenting them to the XR Origin also didn't work well, because grab move provider interaction made it look like the menu moves with the controller (when what is actually moving is the player.)

Persisting data using the PlayerPrefs class does not work as one would expect. When you tell it to save, it keeps the changes in memory and doesn't actually write them out until the user quits the game. A player could lose progress by running out of battery. There doesn't appear to be a way to force a write. An ugly workaround I haven't tried is to use a text file instead. Also I couldn't find a way to directly observe what was written. There's supposed to be some kind of persistent data path or registry, but it seems I don't have access.

I found that you can't press a UI button while not looking at it! This interfered with testing. For example, sometimes I wanted to hit Pause while something else was happening, such as a particle system playing, and it was hard to look at both at the same time.

On game pause, I freeze the rocks by imposing velocity and rotation constraints. This is much better than messing with the timescale, which caused other problems. I also freeze any rock particles on pause, which looks cool. I have only one particle system object for rock impact with platform, and I move it to wherever it is needed. Same for shots. I use a ring buffer to hold pregenerated rocks and shots, to avoid the performance hit of generating prefabs on the fly.

I would have liked to try having shadows appear beneath distant rocks, but I found that increasing the Shadow Distance made the close up shadows look bad, even with Shadow Resolution on Very High.

I added scoring and achievements to the game to make it more engaging. I had trouble deciding whether to show the scoring and achievements screen after each level. Maybe it would interrupt game flow. I tried showing scoring while playing, but it was unsightly. Showing it after each level seemed the lesser of the evils.

In the UI, some of my sliders need to be reversed, because for example increasing the gravity strength means decreasing the value of the gravity acceleration constant. Changing the slider direction was easy, but reversing the colors was not. I had to work around annoying automatic color changes: the control subtracts 10 from values of 255 on the fill side, and 41 from 255 on the background side. So I made the right sides black so nothing could be subtracted, the left sides of the reversed ones 255 cyan (becoming 214), and the left sides of the non-reversed ones 224 cyan (also becoming 214 so they match).

I hope this was helpful to you, or at least interesting.