The scaffolding approach and background loading
Sunday, April 29, 2012 at 2:14AM
Kevin Conner in Production, Source Code


When I started building Degrees, the first thing I had to get right was the gyroscope flight control. In a flying game, motion is where the fun comes from. But you can't feel motion unless you have a point of reference, so I had to make some geometry for the level. The easy way was to scaffold it: Degrees would run some throwaway code and generate a level when it launched. That was good enough, and I could focus on flight.

After the flight mechanics felt good, I came up with Degrees's voxel art style, and I tried to implement and optimize it in order to find out just how much I could draw. This would inform the gameplay: Could the game take place outdoors? Indoors? How many enemies could I put on the screen? During that phase, I would periodically need to test some aspect of rendering that demanded a different shape of level. I would just change the scaffold code and get back to the real task. I like working this way because I can concentrate all my energy on one little detail and get it right, and that detail can be anywhere in the program.

At some point I'm going to have a level editor, and that means Degrees needed to load levels off the disk. I could have built the editor, so I could save levels, so I could load levels. But the level editor wasn't the thing to get right at the moment. I have a design goal that the game should not pause while it loads a level. As in SSX 3 and Metroid Prime, you should be able to move from level to level with no interruptions in the animation. So the level-loading code had to be done before the editor, because the performance of background loading affects the way a level ought to be built in the first place. I just adjusted the scaffold: Instead of running the level-generating code at launch, it runs before a build in another executable. It generates the same levels as before, but it saves them as files, and so I was able to write the code that loads levels too.

I love the scaffolding approach because you can see progress every day. You don't have to write for a week before your code works. It always works! And you can do quick experiments without getting over-invested.

Background loading

Following the scaffolding approach, at first I just wrote the loading code to run on the main thread. That helped me get saving and loading right, but the final step was to move it to a background thread so it wouldn't interrupt animation. I did that today, and I learned that I've got an upper limit on the order of 10,000 vertices per file if I really want it not to pause. I think I will end up with lots of tiny, interconnected zones in separate files. Metroid Prime loads one room at a time, and that worked well. Maybe I'll have the same kind of structure. So, I discovered a design goal for the editor today.

I was pretty happy with the design pattern I came up with for background loading, and I think I'll be using it elsewhere. Here, code for you:

Article originally appeared on Degrees, a game in progress for iPad and iPhone (
See website for complete article licensing information.