Learn by making things

This project has come a long way from the first prototype of a capsule primitive sliding down an endless road and I’m finally ready to share a new playable demo.

This friday I attended the first of hopefully many mini game jams at Volta Labs. The theme of the game jam was explosions. The time limit: a mere three hours. Building a working game in such a short amount of time is a lot of fun. For a recovering overthinker like myself it’s also a great exercise in rapid prototyping and not getting hung up on small details. Working so fast inevitably means that you’ll write some silly non-optimized code, but it can also lead to some clever quick solutions to problems you might have otherwise spent too much time one.

The game finally has a driveable vehicle! The biggest challenge in this latest update was solving the tricky problem of getting the car to stick to the track and have correct rotations relative to the road surface while moving and steering. Another small but important addition is the guardrails which help to improve the sense of speed as they fly by. I’ll be releasing a playable OpenGL build soon, there are a couple more features I want to add, including some options on the main menu to let you adjust parameters of the track generator.

I’ve finally solved my intersecting track problem. My first solution involved generating the road in multiple passes. First the generator would do a “flat pass” and lay out road segments on the same plane, freely overlapping. Then it would identify points where the track overlapped and cache some information about those points for the “height pass” which would add hills and valleys to the road while paying special attention to the intersection points and keeping the overlapping sections separated by a minimum clearance value.

The track generator in the first prototype of my procedural racing game works like a treadmill. The road is generated ahead of you and disappears behind you as you drive. Constantly creating and destroying objects in a game is bad practice, so I use what is known as an object pool. Rather than constantly spawning new track segments, the ones that disappear behind you are “recycled” back to the front. The problem with this is that the object I was using as a track segment contained the mesh, the parameters that define the shape of the arc, and the methods for reasoning about the arc.

Last weekend it occured to me that despite the ever-growing popularity of procedurally generated content, I haven't seen a procedural racing game yet. Procedurally generated content would have some interesting implications in a racing game. It would reward general driving skills and the ability to improvise over rote memorization of the track.

This is a simple game I wrote in the summer of 2015 when I was first learning Javascript. I created it using the Phaser game library. You can play the game here and you can find the source code on GitHub.

I recently learned about an interesting technique for rendering 3D images, known as raymarching distance fields. This technique became popular in the demoscene for its power and simplicity. It is capable of generating complexly detailed 3D images in real time with remarkably few lines of code. An excellent explanation of how the algorithm works can be found here and many working examples can be found on Shadertoy. I wanted to explore this technique in more depth.

This year I participated in the Global Game Jam at Volta Labs. The theme of the game jam was ritual. In our group brainstorm we thought of rituals as referring to repetitive behaviors and routines, which got us thinking about robots designed to perform specific functions, which ultimately led to an elaborate and whimsical game idea about amnesiac robots trying to rediscover their purpose. Procedurally generated levels were part of the design of the game, and my role in the team was to write the level generator.