• Yukkafuzz

Iteration Frustration

Last week I wrote about how liquids caused me to decide to swap to a spherical coordinate system. In that post, I sort of snuck that in there like it was a small little change - at the time, I knew it was more significant than I made it sound, but as it turns out, it was even bigger than I expected in terms of work to put in. This week has been filled with cleaning up all the details involved with the swap.

Rather than go into the gory details, which involves a lot of math going between spherical coordinates and Cartesian and discussing meshes, vertex density, and stitching, I take a step back to look at the decision as a whole. Way back when I began developing terrain generation, I remember carefully considering my options:

1. A surface that stretches infinitely in two dimensions with height and depth modulation

  • quick to implement

  • can take advantage of Unity-run gravity, skyboxes, and more

  • can never walk all the way around a planet

2. A surface that stretches in two dimensions, but loops back to simulate a planet surface

  • a little more realistic than the previous option

  • can take advantage of Unity-run gravity, skyboxes, and more

  • more or less impossible to make the looping act as a sphere - a cylinder is the best you can do

3. A sphere constructed with a Cartesian grid (the system I had chosen)

  • quick to implement

  • terrain divisions are the same size everywhere

  • areas of the planet that should be flat will appear to have bumps

4. A sphere constructed with a spherical coordinate grid (the system I have now)

  • more complex with coordinate system conversions

  • terrain divisions will get smaller as you go toward the core and the poles

  • flat surfaces will appear flat

I eventually discarded the first two options because they could not be made to properly simulate a sphere, which I decided was critical to the space exploration experience - planets are going to be far smaller than a realistic size to allow actually walking fully around them. Between the other two options, I chose 3. because I couldn't think up a clean way to avoid the terrain splits ("blocks" of sorts) from getting extremely small at the poles and core, and I thought it would be cool if players could truly go everywhere on the planet.

So what changed? Well, I underestimated how awkward it would be having non-flat surfaces where they should be flat. I mentioned last week that it looks okay (but not amazing) for solid terrain, but really just looks wrong for liquids, and I really want liquids to be part of the terrain generation, not added on afterward. I also did not consider the number of potential solutions to the problem with the spherical system, where I am now using a sort of hybrid grid at the poles to mitigate the extremely small terrain that would occur otherwise.

Making a switch like this - a pretty large system fairly late into its development - can be pretty frustrating, especially with how much thought I put into the initial decision. It's important not to fall into the sunk cost fallacy, though; "never sacrifice design" has been a principal principle (I couldn't help myself) I've gone by. As that design changes, or as the design priorities reveal themselves, it's important to be willing to axe large bodies of previous work to accommodate the change. In the terrain case, most of the work I had done could actually be reused thanks to careful code implementation the first time, but what felt really bad was needing to totally redo a liquids system I had pretty much just completed. Again, never sacrifice design even when it makes it feel like you wasted a few days. The work put in to creating these new features is what clarifies the design, and so it is not truly a waste.


One Knight Studio © 2019