runevision blog

Fast and Gorgeous Erosion Filter

2026-03-30T15:29:00.012+02:00

This blog post and the companion video both explain an erosion technique I’ve worked on over the past eight months. The video has lots of elaborate animated visuals, and is more focused on my process of discovering, refining, and evolving the technique, while this post has a bit more implementation details on the final iteration. I suggest watching the video first, but it’s not required. You can also skip right to the links at the end.

In the real world, rainfall on mountains tends to converge into water streams and rivers, which carve gullies in the mountain sides. These gullies may form branching patterns, as smaller water streams merge into larger ones. And the gullies often butt up against each other, leaving sharp ridges dividing them.

But when generating virtual landscapes, the simulation of countless water drops is slow. It’s not very suitable for generation in chunks either, which means it’s not practical to use when generating landscapes that are too large to generate all at once.

This means techniques are sought after, which can produce the appearance of erosion without having to deal with simulating the process of it. This post is about such a technique.

Screenshot of Advanced Terrain Erosion Filter Shadertoy by me.

It’s essentially a special kind of noise which produces gorgeous branching gullies and ridges, while still allowing every point to be evaluated in isolation, which means it’s fast, GPU-friendly, and trivial to generate in chunks.

Furthermore, rather than defining the landscape entirely, it can be applied on top of any height function, essentially applying erosion on top as a filter.

Background

There’s a website called Shadertoy where people create and share standalone shaders. A shader is a program that runs on the GPU, which can be used to determine what a virtual surface should look like, or for various other effects, or even entire scenes.

In 2018 a user called Clay John (Bluesky) posted a Shadertoy called Eroded Terrain Noise. He wrote:

This shader is the result of a long time dreaming of a noise function that looked like eroded terrain, complete with branching structure, that could be run in a single pass pixel shader. I wanted to avoid anything simulated because then you cannot easily make infinite terrains.

That dream sounds familiar, but Clay John actually made it work. His Shadertoy is the original version of this technique. Hats off to him.

Later, in 2023, a user called Fewes, aka Felix Westin (website), posted a Shadertoy which built on top of the one by Clay John. Fewes’ version slightly tweaked how the erosion effect worked, and presented it in a vastly more polished way.

Screenshot of Terrain Erosion Noise Shadertoy by Felix Westin (Fewes).

In 2025 to 2026 I’ve implemented my own versions of the technique. First I made a version that addresses a few shortcomings of the original technique, and has more intuitive parameters. Eventually I developed a version that works in a completely different way, which produces crisper gullies and ridges and has more expressive parameters. But before going over the differences, let’s start with the basics of the original technique.

The basic idea

We start with a height function where we know not just the height at each point, but also the gradient, meaning the direction and steepness of the steepest ascent. Water flows in the opposite direction, so you can think of the negative gradient at each point as an arrow showing the direction that water would flow down the slope.

The gradient at each point of the terrain surface is like an arrow showing the direction that water would flow down the slope.

Let’s start simple, with a slanted surface, where the gradient is the same everywhere.

We use the gradient to add stripes that run along this direction. The stripes produce alternating gullies and ridges, that could plausibly have been created by water eroding the terrain.

A slanted surface with gullies created from stripes that follow the gradient.

The sides of these gullies and ridges come with their own gradients, which are added to the original to produce new combined gradients.

We can then repeat the whole thing again at a smaller scale: Add smaller stripes which run along the new slopes. These form new gullies and ridges which naturally branch out at an angle from the first ones.

By convention, each repetition is called an octave. Add a few more octaves, and we should be done, right?

A slanted surface with multiple octaves of gullies, each one taking the changed slope from the previous gullies into account.

Except – it’s not quite as simple as I just made it sound.

If we apply the erosion to our original height function, where the gradient is not the same everywhere, we get a chaotic mess. Even if we show it with just a single octave, it’s still full of chaotic gullies that are often not aligned with the slopes at all. What’s going on?

When rotating the stripe pattern to match a variable gradient, it results in chaotic stripes.

Generating stripes

To rotate the stripe pattern, we have to choose some pivot point to rotate it around.

Rotating the stripe pattern requires choosing a pivot point to rotate it around.

The problem is the rotation around this pivot point will create increasingly large distortions in the output the further away from the pivot point we are. This is because changes in the rotation angle not only changes the direction of the stripes at a given point, but also shifts which stripe is under that point.

The approach used in the erosion implementation is to divide the pattern into cells that each have their own pivot point for the stripes. If you imagine a square grid, there’s one cell per grid square, with its pivot placed randomly inside the square, similar to simple Worley noise.

We still get a bit of distortion, but it’s not too bad, since the pivot point is never too far away. At least as long as the gradient of the height function doesn’t change too drastically within a single cell.

The stripe pattern is divided into cells, and each cell has its own pivot point for rotation of its stripes.

The stripes of neighboring cells are blended together to avoid discontinuities between the cells.

To ensure smooth results without discontinuities, we blend the stripes of neighboring cells. The stripes are essentially extruded sine waves, specifically a cosine wave for the height offset and a sine wave for the derivative (slope).

The gully height offset follows a cosine wave, and the slope follows a sine wave.

The reason the stripes blend so nicely together even when not aligned, is that if you blend two unaligned sine waves, you just get a new sine wave with a smaller amplitude.

The blending can transform unaligned stripes from different cells into a long continuous stripe.

The cell size has a big effect. If we choose a cell size that’s large compared to the stripe width, we get significant distortion issues, just like when we used a single pivot point. If we choose a small cell size, there’s barely room for any stripes, and we get a kind of grainy noise instead.

If we make the cell size even smaller relative to the stripe thickness, the pattern begins to be all white. Or in terms of ridges and gullies, it’s all ridge and no gully. This is because each cell uses a stripe pattern with a white stripe in the center.

Preserving peaks

When I talk about peaks and valleys, I’m referring to the local maxima and minima of the original height function, whereas when I talk about ridges and gullies, I’m referring to the local maxima and minima of the gully stripes applied in each octave of the erosion filter.

Now that we can generate stripes aligned with any gradient, we can apply our erosion effect to the height function without getting chaotic distortions.

However, although we’ve now got nice gullies on the mountain sides, the mountain peaks look wrong. They barely look like peaks at all.

At peaks and valleys of the original height function, where the slope changes abruptly, the erosion effect creates messy folds.

That’s because the peaks may be located anywhere in our stripe pattern, and they get arbitrarily lifted or lowered based on that. Furthermore, there’s an issue whenever the surface steepness approaches zero, which happens at peaks and valleys. When the slope is zero, the gradient has no defined direction, so the direction of the gradient changes abruptly around those spots, which creates chaotic stripe patterns in the surrounding area.

There are two ways we can address this, and both are based on the steepness of the slopes. There’s the original approach used by Clay John and Fewes, which I call the frequency approach, and there’s an alternative approach I came up with, which I call the fade approach.

The frequency approach

The original approach used by Clay John and Fewes is to make the stripe frequency proportional to the slope, so the stripes are thicker, the flatter the terrain is.

At peaks and valleys, where the steepness is zero, the stripes become infinitely thick. And because each cell has a white stripe in the center, this means mountain peaks and valleys, where the slope is zero, always land on the part of the stripe pattern that corresponds to a ridge, and never a gully.

This works great for mountain peaks, but I discovered that it unfortunately causes valleys to have bulges at the bottom, since they land on "ridges" in the stripe pattern too. This is not visible in their Shadertoys, because they have faded out the erosion at lower altitudes. And this workaround is great if you want smooth valleys.

However, if you apply the erosion at equal strength everywhere, the bulges at valleys appear, and it means you can’t get crisp, V-shaped valleys.

The frequency approach produces bulges at the bottom of valleys if it’s applied at full strength everywhere.

You can find my Shadertoy here based on the frequency approach. It’s similar to the one by Fewes, but is refactored to have more intuitive parameters.

The fade approach

I came up with a different approach, which is to keep the stripe widths consistent and instead fade out the stripes where the steepness approaches zero. If we fade towards "white" – the maximum value of the gully octave – we get a similar effect as with the frequency approach, that the shape of peaks is preserved, but there are bulges at the bottom of valleys.

Now, if we fade towards "black" instead – the minimum value of the gully octave – we don’t get any bulge at the valleys, but instead we get a crease at the peaks. But if we fade towards a value that goes from black at mountain valleys to white at mountain peaks, we can get nice crisp peaks and valleys at the same time.

The fade approach can produce nice crisp peaks and valleys at the same time.

In my implementations, I let it be up to the user to supply this fade target value as an input parameter to the erosion function, for example based on altitude.

For a height value h at the current point, it could look like this, if the expected height range goes from valleyAlt to peakAlt:

float inverse_lerp(float a, float b, float v) {
    return (v - a) / (b - a);
}

// Convert the altitude to a value between -1 and 1.
float fadeTarget =
    inverse_lerp(valleyAlt, peakAlt, h) * 2.0 - 1.0;

The fade approach has a different issue that needs to be carefully handled. It initially seemed to create visible folds – also called discontinuities – caused by abrupt changes in the gradient directions around the peaks and valleys. But I later found out that this can be addressed by using an appropriate shaping function on the slope.

From early on, I had been raising the steepness of the slope to a power of 0.5, which is equivalent to taking the square root of the slope. This applies erosion more evenly than if we used the slope directly. Unfortunately it produces sharp discontinuities at peaks and valleys. This is because the square root curve starts off vertically, so as the slope increases from zero to even the tiniest slant, the erosion immediately increases drastically.

Erosion magnitude based on slope^0.5.

Erosion magnitude based on 1 - (1 - slope)².

But there are many other functions we can use to shape the erosion. The one I ended up using is to flip the curve vertically by subtracting it from one, then raising it to a power of two, and then flipping the result back.

float ease_out(float t) {
    // Flip by subtracting from one.
    // The saturate function clamps between 0 and 1.
    float v = 1.0 - saturate(t);
    // Raise to a power of two and flip back.
    return 1.0 - v * v;
}

This has a somewhat similar shape as the square root – in fact it’s mirrored around the diagonal – but the curve starts off much more moderately. This mostly removes the appearance of discontinuities, especially when we layer multiple octaves of gullies.

With this tweak, the fade approach works just as well as the frequency approach. And unlike the frequency approach, it works well when applying the erosion at full strength everywhere, which can be used to create sharp V-shaped valleys, if desired.

The quest for crisp, branching gullies

The erosion we’ve got so far looks nice, but the larger gullies and ridges get a little bit lost in the smaller ones. I’d prefer if the gullies at all scales could have crisper ridges and creases, and more clearly show a branching pattern.

To address this, I did a lot of experimentation, and developed three techniques that go hand in hand. I call them stacked fading, normalized gullies, and straight gullies, and I’ll go over each of them in the next sections.

In the techniques developed so far, the ridges of larger gullies get somewhat broken up and lost in the smaller ones.

By using techniques I call stacked fading, normalized gullies, and straight gullies, the ridges of larger gullies remain more crisp and unbroken, and the branching pattern of gullies of different sizes becomes more clear.

Stacked fading

We already fixed a problem with crispness earlier. The mountain peaks and valleys didn’t look crisp until we began fading towards black or white for the valleys and peaks respectively. And it turns out we can do something similar for the gullies and ridges.

Let’s establish a few terms first.

I’m calling the value we fade towards the fade target and it’s generally expressed in a variable that goes from -1 at valleys to 1 at peaks.

Then there’s the amount we’re fading towards the fade target. We’re doing a weighted average (also known as a lerp or a mix) of the gullies and the fade target, which can be 100% gullies at steep slopes, 100% fade target at flat terrain, or some mix of the two, depending on the slope. We can think of this as a mask applied to the fade target, before we layer it on top of the gullies.

When we’ve been talking about the fade approach, the fade target and mask have been based on the original height function and its slopes. But just like we don’t want gullies right on top of the mountain peaks or valleys, we also don’t want smaller gullies right on top of the ridges or creases of larger gullies. We can achieve this if we conclude each octave by updating the mask and fade target to also be black and white at that octave’s creases and ridges.

Flow chart of how the fade target and masks affects each octave of gullies.

The diagram above may seem daunting, but here’s the gist of it:

The octave 1 raw gullies are faded towards the input fade target based on the input mask to produce the octave 1 faded gullies. You can think of it as the masked fade target being "overlaid" on top of the octave 1 raw gullies. Nothing new so far.
The octave 1 faded gullies are then used as the new fade target for the next octave. The mask is also updated: From the octave 1 raw gullies, a mask contribution is created which is opaque at the creases and ridges, where the slope is zero. The existing mask is layered on top of the new mask contribution to produce the new combi-mask after octave 1.
The same steps are repeated for each new octave. The octave 2 raw gullies are faded towards the new fade target based on the new combi-mask to produce the octave 2 faded gullies. These are used as the new fade target, and the mask is updated with a new contribution based on the octave 2 raw gullies. And so on.

In broad terms, each new octave adds more ridges and creases to the terrain surface, which increasingly restricts the surface area where subsequent gullies can have any influence on the surface.

How are new mask contributions combined with the existing combi-mask? Let me start by saying that it was easiest in the diagram above to conceptualize the mask as being applied to the fade target, but in the code it’s actually a mask applied to the gullies, so 0 means all fade target and 1 means all gully. In this form, the new mask contribution can simply be multiplied onto the combi-mask to produce the new combi-mask.

We can furthermore implement a useful control here. By raising the inverse of the combi-mask (meaning its complement) to some power before multiplying it with the new contribution, we can control how detailed the erosion looks. Lower values restrict the effect of higher frequency gullies to steeper slopes.

float pow_inv(float t, float power) {
    // Flip, raise to the power, and flip back.
    // The saturate function clamps between 0 and 1.
    return 1.0 - pow(1.0 - saturate(t), power);
}

combiMask = pow_inv(combiMask, detail) * newMask;

From left to right, the detail parameter has been set to 0.7, 1.5, and 3.0, respectively.

Normalized gullies

One thing that’s holding back crisper ridges and creases is the inconsistent magnitude of the gullies, caused by the interpolation of stripes that may or may not be well aligned.

At one point I realized that since we interpolate both cosine and sine waves in parallel, we can think of each cosine/sine pair as a point on a unit circle, and the interpolated value as a point on a circle too. The interpolated circle point may have shrunk to a radius smaller than one, but it’s trivial to normalize it back to one. And this in turn means that both the interpolated cosine and sine waves have a consistent magnitude of one.

Now, in the actual interpolated stripe function we’ve used up until this point, the sines are multiplied with a vector orthogonal to the terrain gradient in order to calculate the gradient of the slope. But since this vector is the same for all contributing samples, the multiplication can be postponed and applied to the interpolated result rather than to each contributing sample, leaving us free to perform the normalization first.

When straightforward normalization is applied, some curious artifacts appear where ridges and creases join up and form loops. Supposedly, this happens at points where the interpolated waves cancel out completely; something that seems to unavoidably happen with some regularity. On the terrain, this manifests as spiky protrusions (and holes).

However, the loopy artifacts can be avoided if we only normalize lengths above a certain threshold. To avoid discontinuities between normalized and non-normalized gullies, we can use the following approach:

Scale lengths by a factor k that’s larger than one.
Clamp resulting lengths to one.

I’ve used a factor k of 2, such that lengths greater than 0.5 become normalized. This produces a good tradeoff with lots of gullies of consistent magnitude and without loopy artifacts.

Gullies with no normalization have inconsistent magnitudes.

Full normalization of all gullies produces spiky protrusions.

Normalizing only gullies of magnitudes 0.5 or greater results in a good tradeoff.

The style of partial normalization I’ve chosen produces second order discontinuities (abrupt changes in slope) in some places, but as it’s not noticeable once multiple octaves are used, I haven’t bothered with a more sophisticated approach.

I figured that the ability to produce directional noise is useful for many other purposes than erosion, so I’ve released the noise function as Phacelle Noise, which I’ve written about here.

Straight gullies

Once the ridges and creases got more crisp, another issue became apparent. Smaller ridges and creases would often run along larger ones for a little distance before branching out.

It’s here that the limitations of modeling gullies as extruded sine waves becomes apparent. See, on the side of gullies, the terrain slope is strongly affected by it, pointing sideways away from the ridges. But at the bottom and top of gullies, they have virtually no effect on the terrain slope. So at those points, smaller gullies will simply run parallel to the larger ones.

The terrain slope is not affected by gullies on top of their ridges or at the bottom of their creases.

Since the effect is gradual, smaller gullies tend to curl at the ends, rather than branching off cleanly from the larger gullies. A visualization of the ridges and creases with just two octaves of gullies shows the difference clearly.

Ridges and creases with curls at the ends.

Ridges and creases that branch out cleanly.

The effect of non-straight gullies is more subtle on the actual terrain surface. But when carefully comparing the images below, you may find that the first one, which does not have straight gullies, has more instances of ridges with small grooves on top, less instances of gullies branching out at clean angles rather than curving, and an overall texture which feels a bit more stringy and smushy.

An eroded terrain without the straight gullies technique.

An eroded terrain with the straight gullies technique.

I fixed the issue of non-straight gullies by essentially faking consistent slopes when calculating the slopes used for the gully stripe pattern directions.

We can pretend that the slope of a gully is constant from top to bottom, as if the gullies were extruded triangle waves instead of sine waves. The faked slope is implemented by using the sign of the sine wave that controls the gully slope, rather than using its value directly. That is, if the sine is negative, we use a value of -1, and otherwise a value of 1.

The derivatives of the gullies follow the sign of the sine wave, as if the gullies were straight from top to bottom rather than curved.

I also tried making the gullies actually be extruded triangle waves, but due to complex interactions in how the different octaves combine, that just ended up looking worse.

One aspect of the overall erosion technique I haven’t explicitly covered yet is that it outputs not only the heights of the eroded terrain, but also the analytical derivatives. However, those derivatives were never very accurate, whether in Clay John and Fewes’ implementations or my own. They are used internally to calculate the gully directions, but the output derivatives were never actually used for anything.

But even if not accurate, they can still come in handy, so I don’t want to remove support for them. (I actually did begin using them to calculate tree coverage.)

With the fade approach, the mask is also used on the derivatives of each octave. They are faded towards a slope of zero rather than the fade target value, which is only relevant for heights. But fading the derivatives towards zero at ridges and creases undermines the straight gullies technique.

So I began calculating derivatives in two different ways in parallel. The output derivatives are stored as part of a heightAndSlope variable whereas the internal version is stored in a gullySlope variable. And while the former is faded towards zero according to the mask, the latter is not.

The faked gully slope does mean that the new straight gullies created based on it have discontinuities at the creases and ridges of the faked slopes, as stripes going in different directions butt right up against each other. This can be seen in the octave 2 raw gullies part of the diagram from earlier.

But these discontinuities are fully faded away in the faded gullies used for the output height offset (and output derivatives), so they’re not a problem.

The discontinuities of the raw gullies are faded away when combined with the combi-mask.

One issue with the slopes remains. For the gullies, we could pretend they’re triangle waves, and calculate the slope of those pretend-triangle-waves according to the frequency and magnitude, but not so with the slopes of the input heights, of which we can assume very little.

If we use the input slope unchanged, the initial gully octave will have a disproportionally large effect near the peaks and valleys, where the input heights are typically rounded and thus have little to no slope contribution. But in the eroded output terrain, the peaks and valleys are typically pointy, with just as steep slopes as elsewhere.

I’ve experimented with a variety of solutions to this, but in the end what produced the best results was to just pretend that the input heights have a specific slope everywhere. This pretend slope can be tweaked to somewhat match the typical slope the eroded terrain ends up having.

It’s a bit ironic that my early work on the erosion technique was focused on making the analytical derivatives more accurate, only to end up giving up on that entirely. But that’s just how a labyrinthine process of discovery sometimes goes.

New coat of paint

The technique has now changed sufficiently that some tweaking of the parameters is in order, to make the most of the new functionality. While at it, I also found a new spot in the heightmap to focus on. Below is the reference terrain I’ll use going forward, which also includes features covered in the remainder of this article.

A new reference terrain that takes advantage of the new implemented features.

While not part of the erosion technique itself, it’s also fun to dress up the terrain with nice materials. I’ve been tweaking the logic inherited from the Shadertoy by Fewes, and added bumpy parts to it that evokes trees too. Furthermore, I managed to add little streaks that evoke water drainage using a technique I’ll discuss further down.

The new terrain with features evoking rock, dirt, grass, trees and water drainage streaks.

Pointy peaks

It turns out that normalizing the gullies make the mountains less pointy, keeping more of the rounded shape of the input height function.

At first, I tried to compensate by applying a special function to the input height that made peaks more pointy, prior to passing them to the erosion function. But I later found that there is a simpler solution that can be trivially implemented in the erosion function itself: Simply scale down the gullies part of the faded gullies by some gully weight factor (such as 0.5) and compensate by scaling up the erosion strength by the inverse factor (like 2.0).

Top left: Original height function with no erosion strength. Top right: Erosion applied, but the mountain peaks are not pointy. Bottom left: Gully weight reduced to zero shows only peaks and no gullies. Bottom right: With double erosion strength and half gully weight, we get erosion with nice pointy peaks.

Pointy peaks are still dependent on the fade target having a value close to 1.0, so in all the example images, the peaks at lower altitudes are less pronounced.

We can look at what happens when the gully weight is reduced to zero. This preserves the overall shape of the eroded mountains, including crisp peaks and valleys, but without all the gullies.

There is a subtle kind of ghosting effect of the gullies present, where ridges and creases alike are turned into all ridges where the original fade target is positive, and all creases where it’s negative. This unhelpfully counteracts half of the intended creases and ridges if very low gully weight values are used, but at larger values there are no noticeable issues.

There are undoubtedly other ways to go around this, but the approach here is simple and works well enough.

Rounding of ridges and creases

The implemented technique can produce very sharp ridges and creases, but something not quite as sharp is often desired. For example:

Real mountain peaks and ridges tend to not be razor sharp if you zoom in sufficiently.
Valleys and the bottom of gullies can get a rounded shape if sediment builds up in them.

For this reason I implemented "edge rounding" with separate control for creases and ridges. As I’ve previously touched upon, the mask is based on the slope passed through a shaping function. By chaining a variable-size ease-in function onto this shaping function, rounding of the ridges and creases can be achieved. And by mixing two different rounding values – one for ridges and another for creases – based on the fade target, the amount of rounding can be controlled separately for those.

Depiction of no rounding, rounded ridges, rounded creases, and both at the same time.

I wanted the rounding to have the same size for gullies of all octaves, so the rounding values are counter-adjusted in accordance with the erosion lacunarity value, which controls how much smaller the gullies are in each octave (typically half the size).

The rounding also affects peaks and valleys stemming from the original height function (and its slopes), but the erosion function doesn’t know about the sizes of the terrain features coming from those, so an input value is provided for tweaking the rounding of those.

Water drainage

While getting the erosion increasingly crisp, the idea of a holy grail occurred to me: Could the technique model the branching gullies so crisply that it could render little branching river networks? It turns out: Kind of, with some caveats.

Side note: I later learned that the branching streaks on mountain sides I had in mind constitute dendritic drainage, which, apart from rivers and creeks, also include channels of snow, sediment, and debris-flow. The colored streaks are often not the water itself, but the leftover rocks and sediment which is colored differently from the surrounding soil or vegetation. Either way, it tends to look like bright lines.

If we ignore the recently discussed gully weights and ridge and crease rounding, then the fade target is practically already a map of the ridges and creases in the eroded terrain, once the technique has gone through all the gully octaves. Only, the last octave appears with much thicker lines than the rest, since it hasn’t been filtered through the mask. This can be resolved by fading it towards a neutral value of zero / gray based on the mask, resulting in what I call a ridge map.

Left: The fade target after 2 octaves. Middle: The ridge map, based on 2 octaves. Right: The ridge map, based on 5 octaves.

Now, those recently discussed features do undermine the ridge map, so in order to avoid having to choose between one and the other, we can keep track of two copies of the fade target and mask in parallel, and process the ones for the ridge map without those features.

Here’s a visualization of the ridge map on the terrain:

Visualization of the ridge map on the terrain itself, with ridges in white and creases in black.

With the ridge map, it’s easy to draw little lines at the bottom of all the gullies that resemble dendritic drainage. Here’s the image of the textured terrain again:

The terrain with features evoking rock, dirt, grass, trees and water drainage streaks.

It’s not a perfect solution, since the interpolated stripes we use for the gullies cannot consistently produce unbroken lines. So sometimes a gully, and the drawn water drainage at its bottom, just stops halfway down a mountainside rather than following through all the way down to the lowest reachable point. Nevertheless, it looks nice and can be sufficient for use cases that don’t require accuracy in this regard.

Future work

You can see my final iteration of the technique in my Shadertoys Advanced Terrain Erosion Filter and Mouse-Paint Eroded Mountains.

As has hopefully been clear, the erosion technique I’ve described in this post is highly malleable. Compared to the original version by Clay John and Fewes, I’ve modified it to a point where its internal workings, capabilities, and characteristics are entirely different.

While I don’t have plans to further work on this technique myself, I find it likely that others will, given how open-ended the nature of the technique is, and how ripe it is with potential.

In my work with the technique, I’ve simply aimed to make the eroded terrain look good to my eyes, loosely using a bunch of reference images for inspiration.

An interesting jumping off point for future work could be to try to use the technique to emulate a variety of specific eroded terrain types, each based on different references. The input parameters should allow for a wide variety of looks on their own, especially when considering most of them can be varied based on other variables. If the technique then falls short of being able to emulate certain terrain characteristics, that could point the way towards potential future improvements.

I’ve released my code under the Mozilla Public License v2 in order to encourage further sharing of improvements. I’m looking forward to seeing how the technique evolves in the future!

Based on feedback after publication I've added some additional notes after the links section.

Links

YouTube videos

Some things are easier to explain in motion.

My video Fast & Gorgeous Erosion Filter Explained has more elaborate visualizations than this blog post, and more details on the initial process I went through.
Better Mountain Generators That Aren’t Perlin Noise or Erosion on Josh’s Channel is a highly polished and well explained video on two other non-simulated erosion techniques. I reference this video in my own video.

Shadertoys

You can run and see these visuals directly in your browser, and easily see and modify the source shader code too.

Eroded Terrain Noise by Clay John (Bluesky). The original version of the technique.
Terrain Erosion Noise by Felix Westin (Fewes) (website). Slightly tweaked erosion effect, and presented in a vastly more polished way.
Clean Terrain Erosion Filter by me. My earlier rewrite of Clay John and Fewes’ technique (based on the frequency approach), with more intuitive parameters.
Advanced Terrain Erosion Filter by me. My final iteration of the technique, with animated parameters.
Mouse-Paint Eroded Mountains by me. My final iteration of the technique, with interactive mouse painting of the terrain.
Phacelle Noise Animation by me. A demonstration of the Phacelle Noise I extracted into a self-contained function (blog post here).

Erosion filters in the wild

Let me know if you use the erosion filter technique in your project and have public images or videos to show for it!

I'm very happy so many people have found the technique useful enough to make their own implementations in a variety of shapes and forms. Some of the ones below are faithful implementations, while others are partial, derived, or based on an earlier version of the technique.

Implementations in tools and engines

Implementation in Unity Burst posted on Reddit and released on Github by Luke Mitchell.
Implementation in Unity Shadergraph posted on Bluesky and released on Github by Jens Maier.
Implementation in Unreal's landmass plugin posted on Twitter by Michael Kinsey.
Implementation in Godot posted (with source) on Godot forum by Henry.
Implementation in Blender geometry nodes Quick Erosion Filter free Gumroad download by Jérémy Derlande (Kollapse3D).
Implementation in Houdini blog post with source files by eetu.
Implementation in Leveller heightmap modeler tool included in version 4.4 (with source) by Ray Gardener.

Implementations in games and private experiments

Implementation in Hytale's Worldgen v2 posted on Bluesky and released on Github by Verday.
Erosion on a sphere posted on Mastodon by metarapi.
Terraform Blending Test YouTube video by HerrLynnsTube.
|peak| implementation in Desmos graphing calculator graph by lemon (and a simpler version here).

Shadertoy video exporters

This is not entirely related to erosion techniques, but here are the tools I used to render high quality Shadertoys footage for the video. Okay, I may also be using the links section here to tell a side story about my video production woes.

Shadertoy Exporter (original) by Jonathan Giroux (Koltes). This tool worked great, until it broke when the Shadertoy website introduced Cloudflare human verification in early October 2025.
Shadertoy Exporter (forked) by Lara Davidova (larathedev). This fork was made to work with the Cloudflare human verification, and was briefly functional, until the Shadertoy website entirely disallowed being displayed in an iframe later in October 2025.
Shadertoy Exporter (Godot version) by krazyjakee (NodotProject). This rewrite based on Godot is partially functional at the time of writing. It’s Windows-only, and (for me) has the following bugs: Does not convert the rendered frames into videos, has to be restarted after each render, and frequently does not register text input until the window focus is switched away and back. I begrudgingly used this for later footage in the video, manually running ffmpeg on the frames.
I’m aware there are also frame exporter browser plugins for Firefox and for Chrome, but these have even worse usability for me. I have my browser set to display a save dialog when downloading a file, so when I try to render a Shadertoy for 200 frames, it opens 200 save dialogs.

Additional notes

On using the second derivatives (curvature) for the fade target

Several people have suggested using the second derivatives (curvature) instead of the altitude for the fade target.

Using altitude is indeed not robust in the general case, since e.g. some valley could be higher up than some mountain peak. I'm not sure there's a perfect solution, and I kind of let it be up to the user to decide what to base the input fade target parameter on. I just base it on altitude in all my demonstrations.

I did think about using the second derivatives (curvature), but then every function involved in producing the input heights has to calculate and return those second order derivatives, or alternatively it has to be done numerically which is either slow (via multi-sampling) or rather inaccurate (via shader derivatives).

On top of that, curvature does not produce a value that's between -1 and 1 as the fade target needs, so you'd have to combine it with other things (like the first derivatives) to wrangle it into a useful range. That's absolutely possible, but hand-tweaking the particulars may still be needed.

So while it's something I considered, I don't really have a good solution. I'm curious if others will find a better way to handle this.

Phacelle - Cheap Directional Noise

2026-01-22T12:05:00.008+01:00

While working on a novel erosion algorithm last fall (which I'll release at a later time), I developed a directional noise function in the process, which combines various traits of other ones. Since I haven't come across one quite like this, I'll share my findings here. I call it Phacelle Noise, a portmanteau of phase and cell.

Update: After discussing with two of the authors of Phasor Noise, I've added a section at the end about the ways in which Phacelle Noise differs from Phasor Noise.

Simple Phacelle Noise animation recorded from this Shadertoy.

I ended up making two versions, but let's start with Simple Phacelle Noise. For each point, it takes a 2D vector as input, which indicates the direction that stripes should be aligned with at that point. As output it produces another 2D vector from which a phase (or angle) can be reconstructed. Based on this phase, a wide variety of stripe shape profiles can be achieved, for example applying a square wave, a triangle wave, a sawtooth wave, or similar.

It's also possible to use the X or Y component of the output vector directly. These both produce stripes with a sine wave shape profile, a quarter cycle apart (so essentially a cosine and sine).

Even for use cases satisfied by sine wave based stripes, interpolating both cosine and sine waves simultaneously has a significant benefit. See, interpolating multiple kernels of sine waves normally produces a result where the amplitude of the output varies greatly depending on how in phase or out of phase the kernels are. However, when both the interpolated cosine and sine are available, the resulting output vector can be normalized, which ensures both the output sine and cosine waves have constant amplitudes of one.

The other version, Sampled Phacelle Noise, is very similar to Simple Phacelle Noise, except that instead of taking the input direction as an input parameter, it samples the input pattern once per cell, which amounts to 16 times per pixel. Before I go more into that, let's look at some pictures.

Visual comparison with Phasor Noise

With respect to use cases and functionality, the closest other noise function I know of is Phasor Noise (website, paper), itself a reformulation of Gabor Noise. But Phacelle Noise works in quite a different way, which appears to be much simpler and computationally cheaper, and produces a bit different results.

Here's a comparison of Phasor Noise (top) with Simple Phacelle Noise (middle) and Sampled Phacelle Noise (bottom):

Phasor Noise applied to an example pattern by the Phasor Noise authors. From this Shadertoy.

Simple Phacelle Noise applied to an example pattern by the Phasor Noise authors. From this Shadertoy.

Sampled Phacelle Noise applied to an example pattern by the Phasor Noise authors. From this Shadertoy.

To me eyes, these images above look remarkably similar, but there are subtle differences if you look closely. Specifically around areas in the pattern where there are discontinuities in the input direction.

To make the respective handling of discontinuities super obvious, let's use a different input pattern that alternates between horizontal and vertical directions in a checker pattern:

Phasor Noise applied to a checker pattern of vertical and horizontal directions.

Simple Phacelle Noise applied to a checker pattern of vertical and horizontal directions.

Sampled Phacelle Noise applied to a checker pattern of vertical and horizontal directions.

Here you can see that Simple Phacelle Noise has abrupt discontinuities in its generated stripe pattern, while Phasor Noise and Sampled Phacelle Noise do not. Ultimately it's a matter of personal preference, or use case, which one is preferable. For raw stripey patterns, the discontinuities in Simple Phacelle Noise are probably not desirable. For the erosion use case I worked on, it works well, since the stripe (gully) pattern is masked out in those areas of discontinuities anyway.

The visual difference between Phasor Noise and Sampled Phacelle Noise is harder to put the finger on. It seems the latter has a bit higher tendency to produce broken lines rather than merged ones?

Performance

Performance-wise, both versions of Phacelle Noise are much simpler and cheaper than Phasor Noise. In Phasor Noise the innermost loop code (in their provided reference code) runs 5 * 5 * 16 = 400 times per pixel, and the input pattern is sampled in that inner loop, so 400 times per pixel as well. The primary author of the Phasor Noise paper Thibault Tricard pointed me to a corrected implementation by his colleague Xavier Chermain, which reduces the innermost loop count to 3 x 3 x 16 = 144 times per pixel.

On the other hand, the innermost loop code in Phacelle Noise runs 4 * 4 = 16 times per pixel. The input pattern is sampled only once per pixel for Simple Phacelle Noise (where it's simply passed as an iput parameter) and 16 times per pixel (that is, one sample per loop) for Sampled Phacelle Noise.

Noise	Loops per pixel	Samples per pixel
Phasor (Shadertoy by Thibault Tricard)	400 (5 x 5 x 16)	400 (one per loop)
Phasor (Shadertoy by Xavier Chermain)	144 (3 x 3 x 16)	144 (one per loop)
Simple Phacelle (Shadertoy)	16 (4 x 4)	1 (input parameter)
Sampled Phacelle (Shadertoy)	16 (4 x 4)	16 (one per loop)

In practise I can also see that both Phacelle Shadertoys run many times faster than the Phasor Shadertoy (when switching them all to use a sample pattern which is not itself computationally heavy). I haven't done a more in-depth performance analysis since I don't have much experience profiling shaders, especially Shadertoys.

In Simple Phacelle Noise, the fact that the input pattern is sampled only once per pixel means that it can be passed to the Phacelle Noise function as a simple input parameter. With Phasor Noise (and to a lesser extent Sampled Phacelle Noise), storing the calculated input pattern in a buffer to avoid excessive recalculations is more or less a necessity (if it's not trivial), while no such buffer is needed with Simple Phacelle Noise. This also makes it easier to make the Simple Phacelle Noise implementation fully self-contained and reusable, since it does not need access to evaluate another function or buffer.

Function lineage

I didn't actually know of Phasor Noise when I implemented Phacelle Noise (the simple variant), and I felt very clever for coming up with the idea that by interpolating kernels of both cosine and sine waves simultaneously, the interpolated result can be interpreted as a vector that can be normalized, and from which a phase can be reconstructed.

Phacelle Noise is derived from a function called erosion in this 2018 Eroded Terrain Noise Shadertoy by user clayjohn. This function interpolates kernels of both cosine and sine waves, but the sine part is multiplied with a vector largely orthogonal to the stripe direction (but slightly different per kernel). Calculating both cosine and sine here has nothing to do with normalization or phase, but is rather done to get both a stripe pattern and its analytical derivative. The stripe pattern is used to carve gullies in a terrain based on the slope of the terrain, and the derivatives (the slope of the gullies) are used to further produce more gullies, branching out in a fractal manner.

In 2023, user Fewes made a refined presentation of clayjohn's erosion technique in this Terrain Erosion Noise Shadertoy. While the core technique was kept mostly the same, Fewes did simplify the vector multiplied onto the sine component of each kernel, making it the same for all the kernels.

My own erosion work in 2025 was based on Fewes' version as a starting point. The sine component being premultiplied with a vector makes normalization and phase extraction less straightforward. It's nevertheless what I did initially, since my use case was erosion too, and I needed the derivatives. However, I eventually realized that there's no need for the direction vector to be premultiplied onto each kernel, as multiplying it onto the interpolated result is fully equivalent. This makes it easy to get the best of both worlds, both clean interpolated cosine and sine waves, and a simple way to get the derivatives too.

Digging further back, clayjohn's erosion function was derived from a function called gavoronoi4 is this Gavoronoise Shadertoy by user guil. This function produces stripes by interpolating kernels of cosine only, and the stripe direction is global rather than variable per pixel.

In turn, Gavoronoise Noise was inspired by Gabor and Voronoi Noise. Gabor Noise because it interpolates stripes produced by sine waves, and Voronoi Noise – specifically this Voronoi Shadertoy by user iq is quoted as a source – because it interpolates a "moving window" of cells, such that an infinite pattern of cells can be achieved while sampling only a finite number of cells at a time (typically 3 x 3, 4 x 4, or 5 x 5).

Readability

Regardless of whether Phacelle Noise is actually anything new (which will be discussed in the section following this one), I bet that my implementation is easier to read and understand.

See, most Shadertoys read to me as if the authors thought they were in an obfuscation contest. Variables are commonly one or two letters long, and it's your lucky day if there's even just a word or two of comments. This makes a lot of this code opaque to me. It's cumbersome having to reverse engineer what each variable means, and I'll have forgotten what the first one means once I'm done figuring out the third one.

It's here that I'll admit I don't actually understand how Phasor Noise works, despite having stared at the code for it for some time. I came away with certain conclusions (like the number of iterations and input pattern samples), but far from a full picture. I don't know what the innermost loop actually does.

Some of this culture of compact, non-verbose variable names might inherit from traditions in mathematical notation, where every variable is a single letter or symbol only, which similarly makes mathematical formulas (a frequent occurance in papers about graphics) often appear opaque to me. It's here that I'll admit I also read the paper on Phasor Noise, but that didn't help me understand it either. I mean, I understand the phase part perfectly, but not the part about how exactly kernels are computed and interpolated, and what those 400 inner loop iterations are needed for.

Mathematical notation is tricky to reform away from single-letter variables (even if there was willingness), since sequences of letters right after each other are interpreted as variables being multiplied. Except when they're not, as in sin, cos, and a host of other function names that are somehow allowed to be multi-letter by convention.

But the way I see it, with code there's no excuse not to make it as readable as possible without the reader having to resort to guesswork and reverse engineering.

So in my own Shadertoys I try to use as descriptive variable names I can, and I strive to add plenty of comments. And in that way, I hope my implementation of Phacelle Noise will be helpful to some people out there.

How Phacelle Noise differs from Phasor Noise

Is Phacelle Noise different from Phasor Noise?

Right after posting the first version of this blog post, I pinged Fabrice Neyret – prolific Shadertoy user and a co-author on the Phasor paper (and many others) – in the Shadertoy Discord server, and said I'd love to hear his input if he got a chance to take a look. Fabrice in turn pinged the first author of the Phasor paper, Thibault Tricard, to bring him into the conversation too.

I started the conversation this way:

There's two things I'm kind of wondering. One is how Phasor noise works, since I can't quite figure it out based on the Shadertoy code or the paper. There is an inner loop that does something with impulses, but I don't understand what it is?

The other is – I'm not in the academic world, nor super aware of all the various noise types that's been shared on Shadertoy over the years. And I'm wondering whether the Phacelle noise I just shared is functionally identical to some existing approach out there, that I just didn't happen to come across.

A rather long discussion ensued, where I gradually understood Phasor Noise better, and formed a clearer view about to which degree Phacelle Noise is new.

In the following, I'll refer to the "cells" in Phacelle Noise as "splats", since this seems to be one established terminology. ("Kernel" is another term for the same thing, but it can mean other things in graphics too.) "Cells" instead refers to the square grid cells that the "splats" are randomly placed inside.

As to my question about impulses, I understood from the conversation that "impulses" simply means the number of splats per square cell, since Phasor Noise places more than one of them per cell.

Difference in how kernel orientations are handled (for Simple Phacelle Noise)

Some parts of the discussion was specifically about Simple Phacelle Noise, since it's more different from Phasor Noise than Sampled Phacelle Noise is.

In the Phasor paper, the description includes "kernels of different frequencies, orientation, bandwidth and amplitudes may be summed". But in the 'one sample per pixel' approach used in Simple Phacelle Noise, the different kernels do not have different orientations. For a given point being evaluated, all kernels have identical orientation, which is the orientation of the input pattern at the currently evaluated point. Rather, the different stripe directions over space come from all the kernel orientations changing in unison as a function of the input direction at the currently evaluated point.

Thibault noted that it is indeed different from what the paper describes, although figure 20 in the Phasor paper uses this technique. He said it's a trick that was given to him by his PhD advisor at the time, and mused that it might be what is sometimes called "ghost knowledge": Knowledge that is present somewhere in the epistemic community, but is not really written down anywhere. Later he went on to try to find out which paper it was first described in, but it is in any case not described in the Phasor paper, or consistent with how that paper describes Phasor Noise.

I somewhat disagree with calling it a mere trick, as it makes the whole thing work in a different way, which is in opposition to what the paper describes. It has completely different properties in terms of qualities of the output, and which use cases it's suitable for.

Fabrice said that the difference in output is only notable "in the case where the vector field violates the requirement of changing slower than the sine wavelength" and that "In theory you should pre-filter it (which is not easy). After a while there would be little difference between the two approaches." But this "requirement" makes a lot of assumptions, and I reject it being universally relevant. I pointed out that in use for erosion, it's actually advantageous that the output changes abruptly around e.g. a mountain peak rather than always changing smoothly. Hence the qualities of the output are just different. Whether one is better than the other depends on the use case.

Besides the visual difference in output, it also makes a big difference in which setups are viable. Consider a use case where you need to chain many directional noise invocation after each other, each new one dependent on the output from the last. With an implementation that samples the input pattern per splat, this would require a separate buffer for each invocation, or else each "layer" would contribute to a combinatorial explosion of samples that would be completely infeasible to run.

Whereas with Simple Phacelle noise it's trivial. No buffers are needed, and no combinatorial explosion happens. The computational complexity scales simply linearly with the number of invocations.

In the end I suggested that it may simultaneously be a "trick" to an existing technique in one context, and in another context be the primary technque in its own right, and Thibault said that he was fine with that.

Speed optimizations

Phacelle Noise is (in its current implementations) hardcoded to sample 4 x 4 splats, randomly placed inside 4 x 4 square cells. It makes the most of those samples, producing results that often look similar to Phasor noise implementations that use an order of magnitude more samples. Furthermore, the fact that Phacelle uses only one splat per square cell differs from the Phasor Noise implementations I've seen, which have invariably used multiple splats per cell. Using only one splat per cell produces a distribution that's more evenly spread out (on average).

In practise, when I tried to reduce the number of samples in the Phasor implementations I saw, the results got worse than Phacelle Noise long before the number of samples got near to 16.

Apart from that, in the Phacelle Noise implementations I've put some effort into moving as many calculations as possible outside of the loops for performance reasons, while the Phasor implementations I saw repeat a lot of identical calculations for each sample.

Avoidance of artifacts caused by discontinuities in the splat weight functions

Phasor noise uses Gaussian functions for weighting its splats. And those functions never reach zero at any distance from the splat center. This works well for implementations that always sample all splats. But for implementations that only sample the nearest splats (for example because there are infinite splats), it creates artifacts because of discontinuities in the effective weight functions.

In the implementations where splats are divided up into square grid cells, the artefacts appear along the grid lines. It may not be visible in most presentations, but I've seen these artefacts clearly in terrain height use cases I've worked on.

This is why I subtract a value from the exp weight function (Desmos demonstration here), chosen such that it ensures the weight function gradually goes down to zero, and reaches it without discontinuities at the exact minimum distance from the evaluated point where splats may stop being evaluated. Fabrice said this is a common fix to apply to weight functions. Nevertheless it was not described in the Phasor paper or present in Phasor implementations I've been pointed towards, so it's a practial implementation difference between Phasor (as described) and Phacelle.

API surface and ease of use

I must say that although everyone involved did their best to be helpful and constructive, there was also a lot of friction in the conversation in general. Occasionally I would see comments dropped outside of the Discord conversation on my Shadertoys here and here, and they may give a bit of an impression of what I mean.

I felt that we were often talking past each other. In the Discord conversation, I tried to put that into the following words:

It seems you approach the concepts we're discussing mostly in terms of abstract classification. My own interest however is more rooted in concrete functionality and user experience, and as such is centered around things like ease of use, applicable use cases, API surface design, proper documentation, etc.

And in a lot of Shadertoy implementations I've seen of Phasor noise, the ease of use has been very poor for me. I didn't understand the code due to few or no comments, and there was often not even a clear seperation between code that's noise implementation and code that relates to presentation. This makes it very hard for someone who's not intimately familiar with the technique to just copy the noise function into another Shadertoy and use it there.

Case in point, I still haven't seen any Phasor noise function that takes the pattern direction as an input parameter; it always seems to be hardcoded into the function itself in one way or another.

To me, user experience, API design, etc. matters a lot, and is in itself justification to give things names. As a parallel example, I know of several libraries that does Voronoi tesselation, but they have completely different API design and functionality. Some are useful to me while others are useless. And it's pracical for me to be able to refer other people to the ones I find useful, and not just tell them to "use Voronoi tesselation", as there are a lot of details that matter beyond the basic technique.

As such, since the API design, possible use cases, characteristics and documentation of my Phacelle implementation is quite different from any Phasor noise implementations I've seen, I find it useful and practical that I and others can refer directly to this implementation by name.

Thibault replied that he agreed that Phasor implementations that are currently available are not well documented, and that most of them are code from the Siggraph deadline that have barely been cleaned up since. He added that he might create a cleaner example one day when he'll get some time.

Verdict from two of the Phasor authors

Thibault's verdict was that Phacelle Noise gives results visually similar to Phasor in 2D, but cheaper, although it does not provide any of the frequential guarantee given by Phasor, which he said was very important for texture synthesis and for anisotropic filtering. He said it also doesn't offer control over the isotropy of the generated noise (an aspect of the Phasor Noise paper which is not utilized in the Phasor implementations I compare Phacelle Noise with).

He concluded that if the question is whether anybody did exactly the same thing, the answer would be no, but that Phacelle did not do anything new that warranted publishing. Which is fine, as I have no intention of publishing.

Fabrice added that what I propose is a discussion about technical choices, and that while he believed no scientific reviewer would agree it's a new method, it could totally be accepted as such in practical (and lovely) venues like the JCGT journal (a follow-up to the Graphics Gem book series), which is interested in how to make things usable. (But again, I'm not interested in publishing.)

I made a hair shader

2025-10-23T13:33:00.001+02:00

I've actually been working on a cool erosion technique I'll post about later, but during some downtime, I had an impulse to see if I could make a basic hair shader that doesn't require any specially made meshes or textures. I ended up making three hair shaders.

The shapes below are just standard Unity spheres and capsules and only a simple normal map is used; no other textures. The hair strands follow the vertical V direction of the UV map of the mesh.

I also found some characters on the Asset Store and tried changing the hair material to use my shader. Luckily they all already had hair aligned vertically in the UV map (although not 100% for wavy/curly hair, which compromises my shader slightly).

You can see a video here with the shader in action on both basic shapes and characters:

I ended up making these three hair shader implementations:

Full multisample hair shader
Specular multisample hair shader
Approximation hair shader

All three shaders support a diffuse map, a normal map, and properties for color, smoothness, and normal map strength. The diffuse map alpha is used for cutout transparency.

See the hair shader repository on GitHub

The strategy was to start with Unity's Standard shading model (based on BRDF physically based shading), but modify it to simulate anisotropic shading, that is, to simulate that the surface is made from lots of little parallel cylinders rather than a flat surface.

This approach ensures that the hair shader looks consistent with other materials based on Unity's Standard shader (and other Surface shaders) under a wide variety of lighting conditions and environments.

1) Full Multisample Hair Shader

I started out doing brute force anisotropic shading, running the Unity's physically based BRDF shading function up to 50 times and taking a weighted average of the sample colors.

The normals in those samples are spread out in a 180 degree fan of directions centered around the original normal, using the hair strand direction as the axis of rotation. The final color is a weighted average of the samples.

Much of the "magic" of the simulated anisotropic shading comes from the way the samples are weighted in the two multisample shaders (and emulated in the third).

The weight of each sample is a product of two functions:

The cosine of the angle between the original and modified normal. This is because strands of hair occlude other strands of hair when the hair "surface" is seen from the side, and the parts of strands that face outward tend to be less occluded.
The cosine of the angle between the modified normal and the view direction. This is because the part of the strand that's facing the camera takes up more of the view than parts that are seen at an angle.

Both cosines are clamped to a zero-to-one range before the two are multiplied.

With this weight function to base the weighted average on, the results looked surprisingly good. Of course, running the entire shading up to 50 times is not exactly the fastest approach, performance-wise.

2) Specular Multisample Hair Shader

I made a second implementation that reduces computations somewhat by only multi-sampling certain calculations, namely dot products with the normal, and most of the specular term of the lighting. The diffuse term, fresnel, and other calculations are performed only once. The result is nearly indistinguishable from the full multisample hair shader.

There is still a significant amount of calculations being performed up to 50 times though.

3) Approximation Hair Shader

Of course, non-brute force approaches to hair shading are possible too, but way harder to make look good. Still, I eventually came up with something fairly decent.

The third implementation does not perform multisampling but instead emulates the same result. The math formulas required for this were devised by means of a combination of partial understanding, intuition, and trial and error, while carefully comparing the results with the full multisample hair shader. As such, it's difficult to explain the details of the logic behind it with any exactness, but you can see the details in the shader source code.

Closing thoughts

This was just a little experiment I did as a random side project. I haven't looked much at existing research on hair shaders, as I tend to not understand graphics papers very well. My impression is that this has less to do with the subject matter itself, and more to do with the manner in which it's explained.

The one research entry I did look at – Hair Rendering and Shading by Thorsten Scheuermann – only shows the results on a complex multi-layered haircut model; not simple spheres like I used for testing, which makes it impossible to compare results meaningfully.

I'm not planning any further work on the hair shaders, but I've released them as open source on GitHub. If anyone makes changes or improvements to them – or just use them in a project – I'd love to hear about it.

Notes on atmospheric perspective and distant mountains

2025-06-29T12:56:00.008+02:00

I don't know if it's because I come from a supremely flat country, or in spite of it, but I love terrain with elevation differences. Seeing cliffs or mountains in the distance fills me with a special kind of calm. The game I'm currently working on, The Big Forest, is full of mountain forests too.

I've just returned from three weeks of vacation in Japan, and I had ample opportunities to admire and study views with layers upon layers of mountains in the distance. And while studying these views, something about the shades of mountains at different distances clicked for me that’s now obvious in retrospect. I'll get back to that.

Note: No photos here have any post-processing applied, apart from what light processing an iPhone 13 mini does out of the box with default settings. I often looked at the photos right after taking them, and they looked pretty faithful to what I could see with my own eyes.

Increasingly deep blue mountains in the distance, seen from a panoramic spot on the Magome-Tsumago Trail.

Mountain ridges accentuated by both lighting and the haze of the atmosphere. Seen from a train near Nakatsugawa.

The blue tint of atmospheric perspective

A beautiful thing about mountains in the far distance is how they appear as colored shapes behind each other in various shades of blue. Sometimes it looks distinctly like a watercolor painting.

Light blue mountains in the background behind Matsumoto city on a cloudy day.

In an art context, the blue tint that increases with distance is called aerial perspective or atmospheric perspective (Wikipedia).

I've tried to capture this in The Big Forest too by making things more blue tinted in the distance. In terms of 3D graphics techniques, I implemented it by using the simple fog feature which is built into Unity and most other engines. By setting the fog color to blue, everything fades towards blue in the distance. It can produce a more or less convincing aerial perspective effect. Using fog for this purpose is as old as the fog feature itself. The original OpenGL documentation mentions that the fog feature using the exponential mode "can be used to represent a number of atmospheric effects", implying it's not only for simulating fog. For our purposes, let's call it the fog trick.

Work in progress screenshot from The Big Forest, showing blue tinted terrain in the distance.

Which color does things fade towards?

I long held a misconception that things in the distance (like mountains) get tinted towards whatever color the sky behind them has. In daytime when the sky is blue, the color of mountains approach the same blue color the further away they are. At sunset where the sky is red, the mountains approach that red color too. A hazy day where the sky is white? The mountains fade towards white too.

Of course, the sky is not a single color at a time. Even at its blueest, it's usually more pale at the horizon than straight above.

This raises a dilemma when using the fog trick. Set the fog color too close to the blue sky above, and the distant mountains appear unnatural near the pale horizon. But set the fog color to the pale color of the sky at the horizon, and the result is even worse: Some mountain peaks may then end up looking paler than the sky right behind them, and that looks very bad, since it never happens in reality.

Fading towards a color that matches the horizon can make mountain peaks tinted paler than the sky behind them. This looks bad, and doesn't occur in reality.

For a long time I wished Unity had a way to fade towards the skybox color (the color of the sky at a given pixel) rather than a single fixed color.

In practice, it's not too difficult to settle on a compromise color which looks mostly fine. It's just still not ideal, for reasons that will become clear later.

Are more distant mountains more pale?

Now, while I was tweaking the fog color in my game and in general contemplating atmospheric perspective, I could see from certain reference photos I'd found on the Internet that mountains look paler at great distances. Not just paler than their native color – green if covered in trees – but also paler than the deep blue tint they appear with at less extreme distances.

This was counter-intuitive. How could the atmosphere tint things increasingly saturated blue up to a certain distance, but less saturated again beyond that point? Now, the thing is, you never know how random reference photos have been processed, and which filters might have been applied. For a while, I thought it simply came down to tone mapping.

Tone mapping is a technique used in digital photography and computer graphics to map very high contrasts observed in the real world (referred to as high dynamic range) into lower contrasts representable in a regular photograph or image (low dynamic range). For context, the sky can easily be a hundred times brighter than something on the ground that's in shadow. Our eyes are good at perceiving both despite the extreme difference in brightness, but a photograph or conventional digital image cannot represent one thing that's a hundred times brighter than another without losing most detail in one or the other.

If you try to take a picture with both sky and ground, the sky may appear white in the photo even though it looked blue to your eyes. Or if the sky appears as blue in the photo as it did to your eyes, then the ground may appear black. Tone mapping makes it possible to achieve a compromise: The ground can be legible while the sky also appears blue, but it's a paler blue in the photo than it appeared to your eyes. Tone mapping typically turns non-representable brightness into paleness instead.

So I thought: Distant mountains approach the color – and brightness – of the sky, so they may appear increasingly pale in photos simply because they're increasingly bright in reality, and the brightness gets turned into paleness by tone mapping.

However, while observing distant mountains with my own eyes on the Japan trip, it became clear that this theory just doesn't hold up.

Revised theory

Some of my thinking was partially true. Distant mountains do take on the color of the sky, just in a bit different way than I thought. And tone mapping does sometimes affect the paleness of the sky and distant mountains.

But on this trip I had ample opportunity to study mountains layered at many distances behind each other. I could observe with my own eyes (no tone mapping involved) that they do get paler with distance. (It's not that I've never seen mountains in the distance with my own eyes before, but on previous occasions I guess I didn't think very analytically about the exact shades.) Furthermore I've taken a lot of pictures of it, where (unlike random pictures I find on the Internet) I've verified that the colors and shades look about the same in the pictures as they looked to my eyes in real life.

Photo from the Magome-Tsumago Trail where mid-distant mountains in the left side are a more saturated blue while more distant mountains near the right side (also shown in zoomed-in cutout) are paler. The most distant can only barely be distinguished from the sky.

So here's what finally clicked for me:

Mountains transition from a deep blue tint in the mid-distance to a paler tint in the far distance for the same reason that the sky is paler near the horizon.

To the best of my current understanding, the complex scientific reason relates to how Rayleigh scattering (Wikipedia) and possibly Mie scattering (Wikipedia) interact with sunlight and the human visual system, but the end result is this:

As you look through an increasing distance of air (in daytime), the appearance of the air changes from transparent, to blue, to nearly white. (Presumably this goes through a curved trajectory in color space).

When you look at the sky, there's more air to look through near the horizon than when looking straight up, so the horizon is paler.
Similarly, there's also more air to look through when looking at a more distant mountain compared to a less distant one, so the more distant one is paler.

A small corollary to this is that the atmospheric tint of a mountain can only ever be less pale than the sky immediately behind it, since you're always looking through a greater distance of air when looking just past the mountain than when looking directly at it.

This can be generalized, so it doesn't only work at daytime, but for sunsets too: Closer mountains are tinted similar to the sky further up, while more distant mountains are tinted similar to the sky nearer the horizon. In practice though, it's hard to find photos showing red-tinted mountains; much more common are blue-tinted mountains flush against the red horizon. Possibly the shadows from the mountains at sunset play a role, or perhaps the distance required for a red tint is so large that mountains are almost never far enough away.

I sort of knew the part about the horizon being paler due to looking through more air, but for some reason hadn't connected it to mountains at different distances. In retrospect it's obvious to me, and I'm sure lots of the readership of this blog were well aware of it, and find it amusing that I only found out about it now. On the other hand, I can also see why it eluded me for a long time:

It's just not intuitive that a single effect fades things towards one color or another depending on the magnitude.
It's hard to find good and reliable reference photos, and unclear how to interpret them given the existence of filters and tone mapping.
The Wikipedia page on aerial perspective doesn't mention that the color goes from deeper blue to paler blue with distance. You could read the entire page and just come away with the same idea I had, that aerial perspective simply fades towards one color.
If you go deeper and read the Wikipedia pages on Rayleigh scattering and Mie scattering, they don't mention it either. The one on Rayleigh scattering has a section about "Cause of the blue color of the sky", but it doesn't mention anything about the horizon being paler.

In fact, I've not yet found any resource that is explicit about the fact that the color of increasingly distant mountains go from deeper blue to paler blue. It's even hard to find any references that explain why the sky is paler near the horizon, and the random obscure Reddit and Stack Exchange posts I did find did not agree on whether the paleness of the horizon is due to Rayleigh scattering or to Mie scattering.

I found and tinkered with this Shadertoy, and if that's anything to go by, the pale horizon comes from Rayleigh scattering, while Mie scattering primarily produces a halo around the sun. I don't know how to add mountains to it though.

All right, that was a lot of text. Here's another nice photo to look at:

A nice mountain vista seen from the site outside Abukuma Cave.

I'm still not really certain of much, and you should take my conclusions with a grain of salt. I haven't yet found any definitive validation of my theory that mountains are paler with distance for the same reason the horizon is paler; it's just my best explanation based on my observations so far. I find it somewhat strange that it's so difficult to find good and straightforward information on this topic (at least for people who are not expert graphics programmers or academics), but perhaps some knowledgeable readers of this post can shed additional light on things.

One thing is pretty clear: An accurate rendition of atmospheric perspective (at great distances) cannot be achieved in games and other computer graphics by using the fog trick, or other approaches that fade towards a single color. I haven't yet researched alternatives much, but I'm sure there must be a variety of off-the-shelf solutions for Unity and other engines. I've learned that Unreal has a powerful and versatile Sky Atmosphere Component built-in, while Unity's HD render pipeline has a Physically Based Sky feature, which however seems problematic according to various forum threads. If you have experience with any atmospheric scattering solutions, feel free to tell about your experience in the comments below.

It's also worth noting though that the distances at which mountains fade from the deepest blue to paler blue colors can be quite extreme, and may not be relevant at all for a lot of games. Plenty of games have shipped and looked great using the fog trick, despite its limitations.

Light and shadow

Let's finally move on from the subject of paleness, and look at how light and shadow interacts with atmospheric perspective.

Here are two pictures of the same mountains (the big one is the volcano Mount Iwate) from almost the same angle, at two different times. In the first, where the mountain sides facing the camera are in shadow, the mountains appear as flat colors. In the second you can see spots of snow and other details on the volcano, lit by the sun. The color of the atmosphere is also a deeper blue in the second picture, probably due to being closer to midday.

A view towards Mount Iwate from Kaiunbashi Bridge in Morioka, taken at 6 p.m. The mountain appears as a shape with a single flat color.

A view towards Mount Iwate from Kaiunbashi Bridge in Morioka, taken at noon. Spots of snow are visible on the top, and creases in the mountain are faintly visible.

And here's a picture from Yama-dera (Risshaku-ji temple), where the partial cloud cover lets us see mountains in both sunlight and shadow simultaneously. This makes it very clear that mountain sides at the same distance appear blue when in shadow and green when in light. The blue color of the atmosphere is of course still there in the sunlit parts of the surface, but it's owerpowered by the stronger green light from the sunlit trees.

A view from a wooden pavilion in the Risshaku-ji temple, overlooking the nearby valley. Partial cloud cover leaves the mountains partially lit and partially in shadow, which in the distance makes them look blue with green spots.

That's all the observations on atmospheric perspective I made for now. I would love to hear your thoughts and insights! If you'd like to see more inspiring photos from my Japan trip (for example from a mystical forest stairway), I wrote another post about that.

Resources for further study

Here are links to some resources I and others have come across while looking into this topic.

From my perspective, these resources are mostly to get a better understanding of the subject, and the theoretical possibilities. In practice, it's not straightforward to implement one's own atmospheric scattering solution in an existing engine. Even in cases where the math itself is simple enough, the graphics pipeline plumbing required to make the effect apply to all materials (opaque and transparent) is often non-trivial or outright prohibitive for people like me, who aren't expert graphics programmers.

A simple improvement upon single-color fog is to use different exponents for the red, green, and blue channel. This can be used to have the tint of the atmosphere shift from blue to white with distance. There's example shader code for it in this post by Inigo Quilez, though unfortunately it lacks images illustrating the effect. The post also covers how to fade towards a different color near the sun, and other effects.
Here's a 2020 academic paper, video and code repository for the atmospheric rendering in Unreal, and here's the documentation.
Here's the documentation for Unity's Physically Based Sky.
A 2008 paper that gets referenced a lot is Precomputed Atmospheric Scattering by Bruneton and Neyret, with code repository here. Unity's solution is based on it, and it's cited and compared in Unreal's paper.

Photos from an inspiring trip in Japan

2025-06-27T16:07:00.014+02:00

I've just returned from three weeks of vacation in Japan. Besides being great as a vacation – which was the only thing my partner and I planned for, really – it happened to also be inspiring for me as a game developer. I like to make games that take place at least partially in beautiful nature, give a sense of mystery and wonder that invites exploration, and that have environments that incorporate strong verticality. And in all of these respects, Japan delivers in spades.

Of the many hundred photos we took, I've selected a few dozen to share here, along three themes.

I had originally intended to include a section on distant mountains and atmospheric perspective too, but it turned into a larger topic of its own that I've written about in this post.

Mystical forest stairway

One highlight of the vacation was our day trip to the Risshaku-ji temple in Yamadera. It's a complex of multiple temple buildings stretching up a mountainside with spectacular views, but it's almost the path up there that I found most inspiring as a game developer – a 1000-step ascent through a mystical cedar forest with shrines and stone lanterns along the way.

Stairway going up to the Risshaku-ji temple through a cedar forest.

The combination of the winding stairs and the extremely tall cedar trees gave not just a strong sense of verticality, but a weirdly strong sense of three-dimensional depth in general. Weird, because I have two eyes and always see the world in 3D, but this place made me feel the spatiality of my surroundings more strongly than usual.

The sides of the stairway are dotted with stone lamp posts and small shrines.

On top of that, the sunlight filtered through the trees in that really beautiful way that makes forests look magical. The Japanese even have a word for it, komorebi (木漏れ日).

A little side path goes to a collection of inscribed stones.

Update: I got a question on Mastodon about the weirdly strong sense of three-dimensional depth I felt, which made me reflect more on the reasons.

First of all, I think feeling small among huge shapes evoke a strong feeling of depth in general, but it may be diminished in familiar situations, such as being on a street with tall conventionally shaped buildings.
Second, distances feel greater when they're not horizontal. 100 meters down the (flat) street is nothing, but 100 meters up or down a steep incline feels huge.
Third, in most environments, you see mostly things close by (ground or wall) or mostly far away (horizon or sky) when looking in a given direction. But in forests, and inside huge buildings with many columns, you see near and far simultaneously, emphasizing depth.
Fourth, the cedar trees had huge tall trunks, which made it possible to see both high up in the air and far up the mountain side, without the view being obscured much by the tree canopies.
Fifth (and most speculatively), the sunlight being filtered through the trees produced little attention-grabbing highlights everywhere at various depths, which further enhanced the perception of depth.

So I think it's this powerful combination of multiple factors that reinforced each other: Huge uncommon shapes, verticality, seeing things both near and far simultaneously, partially unobstructed far views, and the lighting. End of update.

The forest path ends at the entrance to the temple area, which is marked with a Niōmon gate. A few red trees adorn the landscape here amid all the green.

A view from the forest path up towards the Niōmon gate which marks the entrance to the temple area.

The view at the top, past the forest, did have the advantage of gorgeous mountain views.

One of the Risshaku-ji temple buildings is perched on the cliff side.

One path in the temple area ends at a wooden pavilion overlooking the valley.

Nature and gardens

Sometimes, what's inspiring is the whole arrangement of elements in a place; other times it can be a single magnificent tree. Here's some more things I thought looked neat.

Walking the Magome-Tsumago Trail, we saw this beautiful contrast between the shade in the forest and the sunlit mountain view visible outside it.

A tall waterfall near the Magome-Tsumago Trail.

Beautiful tall trees in a garden at Gofukuji temple.

Beautifully shaped trees in a garden at Gofukuji temple.

Quaint bridge in Morioka Castle Ruins Park.

A magnificent tree in the Morioka Castle Ruins Park. The tree is hollow but still living. You can tell it's important, as there's a circle decoration on the ground around it, as well as two layers of fence.

Beautiful ponds in the Morioka Castle Ruins Park.

Small bridges in the back garden of a tea house in Morioka.

Strolling home from a restaurant in Morioka one night, we saw this lamp post half-embedded in a hedge in a small crater-shaped indentation. The hedge was blooming, and all the flowers were facing the lamp. The other similar lamp posts along the road were not embedded in the hedge this way, so this beautiful little scene probably started as a happy accident rather than being planned for.

Lamp post embedded in blooming hedge at night.

A wild cliff side by Risshaku-ji temple, with downward facing holes in the overhangs.

A faint waterfall streaming into the river at the bottom of Rairaikyo Gorge.

Lived-in urban vibes

This is the one category which isn't directly relevant to my own games, as they don't take place in contemporary urban environments. But what can I say. I follow the artist Alariko (ArtStation, Bluesky) on social media, and I think his art has stimulated my appreciation for the beauty in the kind of lived-in, worn, quirky, cluttered urban scenes he expertly captures.

In Japan, these kinds of scenes can be found everywhere. Well, maybe not in posh streets or pristine gardens, but you never have to walk far to encounter it.

A street in Nakatsugawa. In front of a slightly grimy tan two-storey building, a utility pole carries a web of wires extending out to the nearby buildings, and is adorned with multiple traffic signs and a mirror.

A heron is scouting by an embankment around Morioka river. Nearby is a bridge overhead, and traffic lights visible above.

Private staff buildings amid the greenery near the Risshaku-ji temple, with a variety of potted plants, garden utilities, and an outdoor air conditioner unit in front.

A building in the Asakusa district of Tokyo is surrounded by potted plants, a bike, a blue covering over unknown items, and a red lit paper lantern.

A view down upon walls and rooftops of nearby buildings to our hotel in Asakusa. The view is dotted with pipes, ladders and potted plants.

Procedural creature progress 2021 - 2024

2025-01-10T14:26:00.052+01:00

For my game The Big Forest I want to have creatures that are both procedurally generated and animated, which, as expected, is quite a research challenge.

As mentioned in my 2024 retrospective, I spent the last six months of 2024 working on this – three months on procedural model generation and three months on procedural animation. My work on the creatures actually started earlier though. According to my commit history, I started in 2021 after shipping Eye of the Temple for PCVR, though my work on it prior to 2024 was sporadic.

Though the creatures are still very far from where they need to be, I'll write a bit here about my progress so far.

The goal

I need lots of forest creatures for the gameplay of The Big Forest, some of which will revolve around identifying specific creatures to use for various unique purposes. I prototyped the gameplay using simple sprites for creatures, but the final game requires creatures that are fully 3D and fit well within the game's forest terrain.

I've seen a fair amount of projects with procedural creatures. It's not too hard to create a simple torso with legs, randomizing the configuration, and animating movement by transitioning the feet between footsteps in straight lines or simple arcs.

This works fine for bugs, spiders, lizards and other crawly critters, as well as for aliens and alien-like fantasy creatures. The project Critter Crosser is doing very cool things with this. While it features mammals too, I'm not sure they'd translate well outside the game's intentionally low-res, quirky aesthetic.

If we also consider games where only the animation is procedural, Rain World is another example where this works great for its low-definition but highly dynamic alien-like creatures. Spore is a classic example too, though its creatures often end up looking both alien and goofy.

For The Big Forest though, I want creatures that feel like they truly belong in a forest, with movement and design reminiscent of quadruped mammals like foxes, bears, lynx, squirrels, and deer. The way mammals look and move is far too distinct to simply "wing it" – at least in my game's aesthetic. Achieving realistic mammalian creatures requires thorough study, so although I also plan to include non-mammal creatures, I’m focusing primarily on mammals for now.

Procedural generation of creatures

The basic problem is to generate forest creatures with plausible anatomy with a small set of parameters and ensure that:

The parameters are meaningful so I can use them to get the results I want.
Any random values for the parameters will always create valid creatures.

My main challenge is identifying what constitutes meaningful parameters. This is something I have to discover gradually, starting with a large number of low-level parameters based on minimal assumptions and eventually narrowing down to a smaller set of high-level parameters as I refine the logic.

From the beginning, I decided to focus on basic proportions for the foreseeable future, without worrying about more subtle shape details. For this reason I limited the generated meshes to extruded rectangles. I had to start somewhere, and here's the glorious first mesh:

Later I specified the torso, each leg, each foot, the neck, head, jaw, tail, and each ear as multi-segmented extruded rectangles. I found this approach easily sufficient for capturing the likeness of different animals. By the end of 2023, I had produced these three creatures and the ability to interpolate between them:

This was based on very granular parameters, essentially a list of bones with alignment and thickness data. Each bone length, rotation values, and skin distance from the bone in various directions was an input parameter, totaling 503 parameters.

Creating creatures from scratch using these parameters was impractical, so I developed a tool to extract data from skinned meshes. The tool identified which vertices belonged to which bones and derived the thickness values from that. However, it was error-prone, partly due to inconsistent skinning of the reference models. For example, in the cat model, one of the tail bones wasn’t used in the skinning, which confused my script. This is why part of the cat’s tail is missing in the image above.

I tried to implement workarounds for such edge cases, and various ways to manually guide the script towards better results for each creature, but each new reference 3D model seemed to come with new types of quirks to handle. After resuming work in 2024, I had these seven creatures, with their reference 3D models shown below them:

(I lost two of my original reference 3D models – the coyote and bull elk – because they were in Maya format. Since I don’t have Maya installed, when a project reimport was triggered, Unity couldn’t import the models, and they vanished. Since it's not standard practice to commit Unity’s imported data (the Library folder) to source control, I couldn’t recover them.)

Anyway, so far all my efforts had been focused on representing diverse creatures through a uniform structure that can be interpolated, but I hadn't yet made progress on defining higher-level parameters.

Failed attempts at automatic parametrization

Once I shifted my focus to defining higher-level parameters, the first thing I tried out was using Principal Component Analysis (PCA) (Wikipedia) to automatically identify these parameters based on my seven example animals. In technical terms, it worked. The PCA algorithm created a parametrization of seven parameters, and here's a video where I manipulate them one at a time:

As I suspected though, the results weren't useful because each parameter influenced many traits at once, with lots of overlap, making the parameters not meaningful.

Why did it create seven parameters? Well, when you have X examples, it's easy to create a parametrization with X parameters that can represent all of them. You essentially assign parameter 1 to represent 'contribution from example 1', parameter 2 to represent 'contribution from example 2', and so on. This is essentially a weighted average or interpolation. While this isn't exactly what Principal Component Analysis does, for my purposes it was just as unhelpful. Manipulating the parameters still felt more like interpolating between examples than controlling specific traits.

When I talk about "meaningful parameters", I mean parameters I can understand – something I could use in a "character creator" to easily adjust the traits of a creature to achieve the results I want. Say, parameters such as:

Bulkiness
Tallness (relative to back spine length)
Head length (relative to back spine length)
How pointy the ears are
Thickness of the tail at the base (relative to torso thickness)

However, PCA doesn’t work that way. Each parameter it produces influences many traits at once, making it impossible to control one trait at a time. I encountered the same issue in the academic research project The SMAL Model. While this project is far more sophisticated than what I could do, and is based on a much larger set of example animals, their PCA-based parametric model (which you can try interactively here) suffers from the same problem. Even though it can represent a wide range of animals, I wouldn't know how to adjust the parameters to create a specific animal without excessive trial and error.

I'm also convinced that throwing modern AI at the problem wouldn't work either. Not only would it require far more example models (which I don't have) and AI training expertise (which I have no interest in acquiring); it still wouldn't address the fundamental issue: An automated process can't understand what correlations and parameters are meaningful to a human.

Another problem with automated parameters is that they don't seem to guarantee valid results. When experimenting with my own PCA setup, or with the SMAL Model I linked to, it's easy to come across parameter combinations that produce deformed glitchy models. Part of finding meaningful parameters is figuring out what constitutes meaningful ranges for them. For example, the parameter "Thickness of the tail at the base" might range from 0 (a minimal tail thickness, like a cow's) to 1 (a tail as thick as the torso, like a crocodile's or sauropod's).

This ensures that the tail thickness can't accidentally exceed the torso’s. It also means that changing the torso thickness may affect the tail thickness too. While this technically involves "affecting multiple things at once", it’s done in a way that’s sensible and meaningful to a human (specifically, me). An automated process can't know which of these "multiple things at once" relationships feel meaningful or arbitrary.

Manual parametrization work

Having concluded there was no way around doing a parametrization manually, I began writing a script with high-level parameters, which would produce the values for the low-level parameters (bone alignments and thicknesses) as output.

I made a copy of all my example creatures, so now I had three rows: The original reference models, the extracted creatures (automatically created based on analyzing the skinned meshes of the references) and the new sculpted creatures that I would try to recreate using high-level parameters.

Initially, the high-level parameters controlled only the torso thickness (both horizontal and vertical) and tapering, while the other features remained as defined by the extracted creatures. Gradually, I expanded the functionality of the high-level parameters, ensuring that the results didn't deviate too much from the extracted models – unless they were closer matches to the reference models.

Why keep the extracted models around at all instead of directly comparing with the original reference models? Well, I was still working with only extruded rectangles, and there's only so much detail that approach can capture compared to the high-definition reference models. The extracted models provided a realistic target to aim for, at least for the time being.

From there, my methodology for moving towards more high-level parameters was, and still is:

Gradually identify correlations between parameters across the example creatures, and encode those into the generation code. The goal is to reduce the number of parameters by combining multiple lower-level parameters into fewer higher-level ones, all while ensuring that all the example creatures can still be generated using these higher-level parameters.
As the parameters get fewer and more high-level, it becomes easier to add more example creatures, which provides more data for further study of correlations.

I repeat these steps as long as rolling random parameter values still doesn't produce sensible results.

Here's a messy work in progress:

To help me spot correlations between parameters, I wrote a tool that visualizes the correlation coefficients between all pairs of parameters, and shows the raw data in the corner when hovering the cursor over a specific pair. (In this video, the tool did not yet display all parameter types, so a lot of parameters are missing.)

Focus on joint placement within the body

In 2024, most of my focus on parametrization revolved around the sensible placement of joints within creatures. For instance, in all creatures with knees, the knee joint is positioned closer to the front of the leg than the back. While the knee placement was fairly straightforward, determining the placement of hip, shoulder, and neck joints across creatures with vastly different proportions proved significantly more challenging.

Many of my reference 3D models looked sensible externally, but had questionable and inconsistent rigging (placement of joints) from an anatomical perspective.

Anatomical reference images of bones and joints in various animals were also frequently inconsistent. I could find detailed references from multiple angles for dogs, cats and horses, but not much else. For instance, depictions of crocodile anatomy varied greatly: Some showed the spine in the neck centered, while others placed it near the back of the neck.

All of this uncertainty meant I was constantly second-guessing joint placement – both when contemplating how the procedural generation should work and when adding new example creatures. I wanted to solve this one and for all, so I could stop worrying about it.

Solving the joint placement would also simplify the process of adding additional example creatures, since I could just focus on making them look right "from the outside" without worrying about joints placement. Eventually, I did largely solve it. By this point, I had established 106 high-level parameters that controled all the 503 low-level parameters.

Speeding up creation of additional example creatures

Once joint placement was mostly automated, I come up with the idea of accelerating the creation of example creatures using Gradient Descent (Wikipedia). My goal was to implement a Gradient Descent-based tool that could automatically adjust creature parameters to make the creature match the shape of a reference 3D model.

To my surprise, the approach actually worked. In the video below, the tool I created adjusts the 106 parameters of a creature to align its shape with the silhouettes of a giraffe:

The tool works by capturing silhouettes from multiple angles of the reference model (once) and of the procedural model (at each step of the iterative Gradient Descent process). It calculates how different the procedural silhouettes are from the reference silhouettes, using this difference as the penalty function for the Gradient Descent.

To measure the difference between two silhouettes, the method creates a Signed Distance Field (SDF) from both silhouettes being compared. To speed up the process, I made my SDF-generator of choice Burst-compatible (available here). For each pixel near the silhouette border (pixels with distance values close to zero) the process retrieves the corresponding pixel's distance value from the other SDF to determine how far away the other silhouette border is at that point. The penalty function sums these distances across all tested pixels in all silhouette pairs, yielding the overall penalty.

This explains why, in the video, the legs growing are the first feature to change. Increasing the leg lengths reduces the most distance penalties at once. After that, extending the neck length has the greatest impact.

Notably, the process doesn't get the ears of the giraffe right. The reference model has both ears and horns, while my generator can't create horns yet. So the Gradient Descent process, which aims to match the silhouettes as closely as possible, made the ears large and round so they effectively serve double duty as both ears and horns. I later worked around this by hiding the horns of the reference model.

I also experimented with a standard optimization method called the "Adam" optimizer, but the results were not good. Ultimately, the automated process wasn't perfect, but it complemented my manual tweaks to speed up the creation of example creatures to some extent.

By this point, I had spent three months in 2024 working on procedural creature generation and had developed eleven example creatures covering a variety of shapes. I eventually scrapped the "extracted creatures" because the combination of high-level parametrization and Gradient Descent tooling made them unnecessary as an intermediate step.

However, I was not even close to a sufficient high-level parametrization yet. Feeling the need for a change of pace, I decided to shift my focus to the procedural animation of the creatures.

Intermission

As I was writing this, I realized that while I’m convinced I haven’t yet achieved the goal of ensuring that "any random values for the parameters will always create valid creatures", I hadn’t actually put it to the test. So, I quickly wrote a script to assign random values to all the high-level parameters. These are the results:

While a few of the results look cool, most are not close to meeting my standards, as I expected. Still, this randomizer could prove useful going forward. It might help me identify which aspects of the generation are still insufficient and why, guiding my further refinement of the procedural generation.

Anyway, back to what happened in 2024.

Procedural animation of creatures

When it comes to procedural animation, I have the advantage that I wrote my Master's Thesis in 2009 about Automated Semi-Procedural Animation for Character Locomotion, accompanied by an implementation called the Locomotion System. That was based on modifying hand-crafted animations to adapt to arbitrary paths and uneven terrain.

Even before that, I implemented fully procedural (pre-rendered) animations as far back as in 2002 when I was 18.

In the summer of 2022, I tried to essentially recreate that, but this time in real-time and interactive. As a starting point, I used my 2009 Locomotion System, stripping out the parts related to traditional animation clips. Instead, I programmed the feet to simply move along basic arcs from one footstep position to the next. To test it, I manually created some programmer-art "creatures" with various leg configurations.

In 2024, I resumed this work, now applying it to my procedurally generated creature models.

The result looked somewhat nice but were rather stiff, and the approach only works for taking small steps. As I've touched on before, animating procedural, mammal-like creatures to look natural is a tough challenge:

Quadruped mammals like cats, dogs, and horses move their limbs in more complex ways. Or at least, we're so familiar with their movements that any inaccuracies makes the movements look weird to us.
Fast gaits, such as galloping, are more complicated than walking.
The animation must control not only the legs, but also the spine, tail, neck, etc.
Since the creatures are generated at runtime, the animation must work out of the box without any manual tweaks for individual creatures.

That's a tall order even with my experience, but hey, I like a good challenge.

My approach to procedural animation is purely kinematic, relying on forward kinematics (FK) and inverse kinematics (IK). This means I write code to directly control the motion of bodies and limbs without considering the forces that drive their movement. In other words, there’s no physics simulation involved and no training or evolutionary algorithms (like this one).

A training-based approach isn't viable for creatures generated at runtime, and frankly, I have no interest in pursuing it. The only way the animation interacts with the game engine’s physics system is by using ray casts to determine where footsteps should be placed on the ground.

Hilarity ensues

As an aside, one of the fun parts of working on procedural animation is that works in progress often look goofy. When I first applied the procedural animation to my procedurally generated creatures, I was impatient and ran it before implementing an interface to specify the timing of the different legs relative to each other. As I wrote on social media, "It might be hard to believe, but this animation is actually 100% procedural."

The system itself already supported leg timing, as it was inherited from the Locomotion System, where timing was automatically set based on analyzing animation clips. However, in the modified fully procedural version, I hadn't yet implemented a way to manually input the timing data. Once I did, things looked a lot more sensible, as shown in the previous video.

Other people's comments about the absurd animations sometimes inspire me to create more silly animations, just for fun. "Somebody commented that the procedural spider and the procedural dog are destined to fight, but actually they are friends, they are best pals and like to go on adventures together."

Around this time, I wanted to better evaluate my procedural animation by directly comparing it to hand-crafted animation. To do this, I applied the procedural animation to 3D models I had purchased from the Asset Store, comparing it to the included animation clips that came with those models.

Continuing the theme of goofiness, my first attempt at this comparison had a bug so hilariously absurd that it became my most viral post ever on Twitter, Bluesky and Mastodon. (The added music adds a lot to this one, so consider playing with sound on!)

People would inevitably suggest, and sometimes even plead, that I bring this absurd silliness into the game I’m making, for fun and profit. While I understand the sentiment, the reality is that my vision for The Big Forest is not that kind of game. There's definitely room for some light-hearted moments, but that’s not the primary focus. For reference, think of a Ghibli movie – there’s a certain kind of silliness that would fit well there, but it would need to align with the overall tone.

Incremental progress and study

I started studying my procedural animation alongside the handcrafted animations to better understand the subtle but important differences. Here's the comparison tool I made again, this time without the hilarious bug.

Even without the bug, it still looks very rough. At higher speeds, it becomes clear that the approach of simply moving the feet from one footstep position to the next doesn't work.

In real life (and in the reference animations), at high speeds like galloping, the feet don't stay in contact with the ground for most of their backward trajectories. They only touch the ground for short durations. My procedural animation didn't account for this yet. Instead, the hips got pulled down to be within distance of the feet, and that's what caused the torsos of the procedurally animated creatures to drag along the ground.

Once I tried to account for this, things improved slightly – at least in that the torsos no longer dragged along the ground.

To better make informed decisions about how far up the feet should lift, how much time they should spend touching the ground, and similar animation aspects, I developed a tool to plot various properties of the reference animations. For example, the plot below shows that as the stride distance (relative to the length of the leg) increases, the proportion of time the foot is in the air also increases. The white dotted curve represents my own equation that I attempted to fit to the data.

Below is another plot that shows the signed horizontal distance between the hip and the foot (actually, the footstep position) along the horizontal axis, and the foot's lift on the vertical axis. In the center, where the foot is directly below the hip, the lift is generally zero. Notably, the plot includes data from gaits at different speeds (walking, trotting, galloping), but the distance at which the foot lifts off the ground is fairly consistent across those speeds. So while higher speeds are associated with longer step lengths, the "distance" (relative to the creature) that a foot is in contact with the ground is not proportional to the step length. Instead, it it's closer to a constant value, relative to the leg length.

I made many plots with this tool, visualizing data from the reference animations in all kinds of ways. Some of the plots revealed clear trends, like the two above. Others resulted in a jumble of unrelated curves or dots that I couldn't use for anything. In this way, my process was (and is) very much a classic research approach: Formulating hypotheses, testing them, discarding those that don't pan out, and building upon the ones that do.

Inverse kinematics overhaul

I had noticed that many animals kind of bend or curl their feet – and sometimes the entire lower part of their front legs – when lifting them. However, my procedural animation didn't capture this behavior at all. I could hack around this by dynamically adjusting the foot rotations over the walk cycle, but it often resulted in unnatural poses.

Eventually, I concluded that I needed to revamp the inverse kinematics (IK) algorithm I was using, with focus on better handling foot roll and bending scenarios. My old Locomotion System employed a two-pass IK approach, where the foot rotation was given as input to the first IK pass. Based on the orientation of the lower leg found by the IK, the foot rotation would be adjusted – rotated around either the heel or toe – to ensure a more natural ankle angle, followed by a second IK pass to make the leg match the new ankle position. This two-pass approach worked all right for the Locomotion System, which was applied on top of hand-crafted animation. However, I found it insufficient for the fully procedural animation I was working on now.

In principle, this two-pass approach could be changed to run iteratively, rather than just twice. However, this would be computationally expensive, since the IK algorithm itself is already iterative. Instead, I implemented a new IK algorithm where the foot rotation is not a static input, but is controlled by the IK itself.

Having the IK handle the foot rotation is a bit tricky, as it must behave quite differently depending on how much weight is on the foot, ranging from none to full weight.

I made significant progress with this approach, although there’s a tricky issue: There are edge cases where multiple solutions can satisfy the given constraints. This makes the leg poses, which are state-less, sometimes snap from one configuration to another based on even tiny changes in the input positions. I have some ideas on how to address this, but I haven't tested them yet.

After incorporating the new IK system and adding logic to make the feet bend when lifted, my results looked like this at the end of 2024:

While it's still a bit glitchy and far from perfect, the bending of the feet and legs is at least a step in the right direction.

And that's how far I got so far

Both the procedural model generation and the procedural animation still have a long way to go, after spending around three months on each, and that can feel a bit demotivating. On the other hand, I've been making steady progress, even if it's slow. Writing this post has actually helped me realize just how much I've accomplished so far after all.

That said, I feel it's time for a break from the creatures. When I return to them later, I'll hopefully do so with renewed energy.

I wish I could have wrapped up this post with a satisfying milestone or a neat conclusion, but there was already so much to cover, and I didn't want to delay this write-up any further. I also think there's value in showing the messiness of creative processes and research. Let's see where I'm at when I write about the procedural creatures next time!

2024 retrospective

2025-01-05T17:00:00.013+01:00

Another year went by as an indie game developer and what do I have to show for it?

In last year's retrospective I wrote that apart from working on my game The Big Forest in general, I had four concrete goals for 2024:

Present my Fractal Dithering technique
Release my Layer-Based ProcGen for Infinite Worlds framework as open source
Wrap up and release The Cluster as a free experimental game
Make better use of my YouTube channel

I ended up doing only two of those, but it was the two most important ones to me, so I'm feeling all right with that.

Release of LayerProcGen as open source

I released my LayerProcGen framework as open source in May 2024. LayerProcGen is a framework that can be used to implement layer-based procedural generation that's infinite, deterministic and contextual.

I wrote extensive documentation describing not only the specifics of how to use it, but also the overarching ideas and principles it's based on. I also did a talk at Everything Procedural Conference about it, which was well received.

I'm unsure how many people are using the framework directly for their games, but I know of several who've been inspired by its underlying ideas and made their own implementations.

Sythelux Rikd ported LayerProcGen to Godot. The core framework worked in Godot out of the box, but Sythelux ported various of its Unity-dependent optional utilities and made example scenes for Godot. Oli Scherer created a Rust implementation of LayerProcgen with some slightly different architectural choices. For his game "Around The World" Thomas ten Cate aka Frozen Fractal wrote his own implementation that works on a sphere.

Overall I feel like LayerProcGen has made at least a little dent in the procedural generation community, and I'm happy to have been able to make such a contribution.

Release of The Cluster as a free experimental game

I finally wrapped up and released The Cluster, a game I'd been working on on-and-off since 2003! I already wrote about it here, so no need to repeat myself further, but despite not having much of an impact on anything, I'm personally happy to at long last have this "unfinished business" out of the way.

Stuff I didn't get to do

I didn't get around to presenting and releasing my Fractal Dithering technique. Hopefully this year!

Update January 2025: I got it done less than a month after writing this blog post, yay!

I also never made more "proper" YouTube videos after the one in January 2024 about the terrain generation. I considered doing one about LayerProcGen, but there's already the video of my conference talk about it. I could probably explain the framework and ideas slightly better by creating a video with nice animated graphics and diagrams, but it would be a lot of work for marginal added utility. I also considered doing one about all the interesting tech in The Cluster, but I didn't feel like diverting more of my time to that game over working on my current game. Why no new videos about my current game The Big Forest then? Well, read on...

Progress on The Big Forest

The Big Forest is the game I'm currently working on, and it's still in its early stages, just like I said last year. The game will be fully procedurally generated, and so far I've been working on a series of disconnected experiments and proofs of concept that will eventually all be rolled into the game. These include procedural generation of terrain, gameplay progression, creatures and music.

I had worked on the terrain generation in 2023, and I continued this work in the first few months of 2024.

Previously the paths in the terrain had simply gone from one chunk corner to the diagonally opposite one. I now generated points of interest (with towers for now) and made the paths connect those, although it's not yet completely robust.
I managed to radically speed up the generation by making use of Unity's Burst compiler (without Unity Jobs, which are not a good fit). I'm very happy with that. For fun, I made a video where I had drastically increased the player's speed, like they're some kind of fast hedgehog.
I changed the terrain chunk implementation to use chunks of different sizes, with larger chunks of lower resolution further away from the player. This made it possible to expand the draw distance greatly without slowing the generation down.
Using chunks of different resolutions introduced cracks in the terrain, so I implemented a skirt solution.

On the subject of YouTube videos though, I'm not sure I could make an interesting video of the 2024 terrain progress mentioned above, and there's plenty of other videos out there that cover very similar ground.

After this I kind of needed progress with other aspects of the game before it made sense to focus more on the terrain. After taking a break to wrap up and release LayerProcGen and The Cluster, I returned to The Big Forest to work on its procedural creatures.

I spend the latter half of 2024 working on that - three months on creature model generation and three months on procedural animation. I was writing a whole section about that here, but it got so long that I've written a whole separate post about the procedural creatures instead. Long story short though, I had some progress but it's still very far from where it needs to be.

The fact that it's still well short of being any good means I don't consider it good material for a YouTube video either, as I think such videos work best when they can conclude in a satisfying wrap-up of something. I did write the blog post though, and now I need a bit of a break before I resume working on the creatures again.

Oh right, a video of a bug in the procedural animation I was working on became my most viral post ever on Twitter, Bluesky and Mastodon. (The creatures in this video are not procedurally generated; I was testing the procedural animation on purchased animal models for research purposes.)

Other tidbits

I can take no credit for it, but my business partner for the Quest port of Eye of the Temple, Salmi Games, released an update for Quest 3 that adds real-time shadows from the torch, higher frame rates (90fps almost everywhere), improved texture resolutions and aniso, and higher clarity due to foveated rendering being mostly disabled. This brings the Quest version (on Quest 3) even closer to the PCVR version. UploadVR covered it here.

I very occasionally make music, and in 2024 I released two very different tracks. And as a first, these ones even have vocals (by me): Just to Say Goodbye, a sad song about an alien with bad timing, and Sorte Gryde, a metal re-imagining of an old Danish singing game, with a dash of Saturday-morning cartoon villainy.

I was briefly mentioned in this video about making games feel mysterious by Mark Brown of Game Maker's Toolkit due to my 2021 article about designing for a sense of mystery and wonder. Neat!

When I was around 11 I would draw "video games" on paper during breaks at school. Not sketches or design docs, but games that were fully playable using your finger to indicate where your avatar is, and following simple rules. Earlier this year I had these games scanned (42 pages!). I made a zoomable annotated display of one of the games. I'd like to do more with the other games too, maybe even make a (digitally) playable game out of the one with 3D perspective dungeons.

Goals for 2025

I'll keep this short.

Develop the creature generation and animation sufficiently to put them into the game. If I'm still not there by 2026, I need to seriously reevaluate some things.
Make at least one new YouTube video about The Big Forest.
Present my Fractal Dithering technique.

Wish me luck!

Procedural game progression dependency graphs

2024-10-02T17:49:00.012+02:00

In 2022 I came up with some new ideas for what kind of game The Big Forest (working title) could be. During the year, I developed a way to procedurally create dependency graphs and also procedurally create fully playable game levels based on the graphs.

In the video below you can see the prototype I had near the end.

A dependency graph is a concept in mathematics and computer science which has been independently "discovered" by lots of game developers because it turns out to be pretty central to designing any non-linear game.

At its simplest you can think of locks and keys. A locked door has the corresponding key as a dependency to be able to progress through the door. But dependencies can also be abilities in a Metroidvania game, quest objectives in an RPG, or required inventory items for a puzzle in a point-and-click adventure.

Here's a few different articles by others that discuss what they are. Note the lack of standardized terminology. I personally use "game progression dependency graph" since the concept is applicable to all non-linear games, not just puzzles or dungeons.

I posted about my game progression dependency graph tech on social media (Mastodon and Twitter) throughout developing it. But when people ask me about it now, it's hard to point to posts scattered across a year of social media posts.

I've copied all those posts (nearly verbatim) into this blog post so it's documented conveniently in one place. For this reason it contains not only the conclusions at a single point in time, but also the questions I asked, my confusion, and my developing understanding of the problem space over time. Each header corresponds to a new thread. Images and videos generally relate to the text above them.

Let's start the journey.

March 30 2022

I'm slowly starting to experiment with novel generated graph structures again, here with an early and rough game progression dependency tree. I'll need to merge certain locations, turning it into a directed acyclic graph, and later generate a spatial graph based on it.

I must say I find it tricky to work out data structures for this. Which concepts should be nodes and which should be edges? And with both different types of nodes and different types of edges, should those types be represented as class types (inheritance) or just with data?

I keep having to revise my thinking about which concepts are represented as nodes in the graph and which as connections...

The graph generation now creates a directed acyclic graph rather than a tree structure. It took a long time to get the layout to be nice, avoiding crossed edges when possible and minimizing wasted space.

In the replies someone mentioned Metazelda. It looked familiar so I might have seen it a long time ago. I also did basic lock+keys for my game Cavex myself back in 2007. (Cavex eventually turned into The Cluster.)

The concept I'm working on now takes place in a bit more of an open world where areas are accessible by default and only certain places locked off. The "tunnel/dungeon carving" mindset feels like it might not be as helpful in this context, but I'm still figuring things out.

April 6 2022

If I have to spend a lot of time looking at these generated game progression dependency graphs, I might as well make them nice to look at.

I revised my thinking on the nodes again and added a "location" requirement to almost all the node types. On the first try, the resulting graph had multiple new neat ways of bending the connections, without me having changed the layout function at all. Robust algorithm I guess. :)

Unfortunately it doesn't seem as robust in avoiding crossed edges anymore.

Hmmmmmmmm

First glimpse of an idea to generate a dependency graph and a spatial graph simultaneously from the same underlying data structure.

Really, no need for distant parts of the spatial graph to repel each other quite so much. This can make the graph more curvy, more interesting looking, and more compact at the same time.

April 10 2022

Left: Game progression dependency graphs.
Right: Spatial graphs that could be the basis of where things are located in the world.

A key for a locked gate is a direct dependency, but can be located far away spatially.

Some people may be reminded of articles on squidi.net about procedural generation, which discuss how you could generate an entire game using these principles. It’s a classic resource, and those articles cover a lot of ground, some of which one will inevitably hit when trying to do procedural progression (as this article on puzzle trees also states). Light on implementation details but great food for thought.

I'm going towards an approach of generating the structures by incrementally injecting new dependencies anywhere rather than a simple recursive top-down approach. And I decided to generate both graphs simultaneously rather than as consecutive passes.

These two things combined should hopefully make it possible to inform new dependency injections both on what would be a good spot dependency-wise and a good spot spatially. That's the next thing I'll focus on.

The game progression dependency graph and spatial graph visualizations now support changing the data structure on the fly. This makes it possible to see the node injections as they happen, and exactly how they modify the graph. Alas the jiggles had to go.

I found out I can create more balanced game progression dependency graphs by switching to an approach I call ... (checks notes)

Exploding The Graph, Then Picking Up The Pieces.

The approach so far is powerful in the theoretical possibility space of graphs it can create, but it tends to only open up one new location at a time, stifling player choice. I'm struggling to find a way for the generation to embody the "just right" shapes described by Gareth Rees.

The problem definitely relates to the branching factor, though whether to focus on in-going or out-going edges or both is unclear. The question is then how to construct a DAG with one start node, one end node and n in-between nodes with a given desired branching factor.

April 18 2022

I guess I'm getting closer to something I might be able to use: Dividing n nodes into m columns and then connecting them. But I'm not entirely happy with how specific/hardcoded/restrictive this approach is. For example, this will never create connections that skip rows.

By the way, the graphs here are at a different abstraction level than the previous graphs I've shown. Here, only location nodes are considered. All the other node types can be injected and connected later in a way that respects the same dependencies.

After sleeping on it I came up with a much better approach that creates more random and organic graphs, and always ensures ingoing and outgoing edges are either 1 or 2. Just looking at these results makes me much happier than the results in the previous video.

The new approach is based on a simple graph rewrite rule I keep applying on random edges until the desired number of nodes is reached.

I may have been inspired by a chapter in Dormans Joris' thesis Engineering Emergence which I read recently after some people mentioned it.

Graph layout rewrite

At this point I took some time improving the graph layout algorithm for the dependency graph, but didn't post on social media about it. The graph layout takes cues from the algorithm explained on the Wikipedia page about Layered Graph Drawing (Sugiyama-style) and I improved my implementation by taking ideas from these papers:

After the layout improvements I took a six month break from the game progression dependency graph research and focused on other things for a while, before taking it up again in November.

November 13 2022

Top: Game progression dependency graphs.
Bottom: Spatial graphs that show where things are in the world.

A key for a locked gate is a direct dependency, but can be located far away spatially. Next step is making gameplay objects from the spatial graph nodes.

The graph rendering used to be based on IMGUI with ugly matrix hacks but I spent today changing it to be based on Shapes by Freya Holmer so it supports perspective and is just much nicer. It's an awesome library and the switch was very easy.

November 19 2022

"I'll just add some icons to my game progression dependency graph," I thought. Haha, except, what do the icons really represent? The obstacle or the reward? Both? One week later, I've ended up with this schematic representation.

Here's two quite similar graphs before and after the iconographic makeover. Icons inside a node represent the obstacle/medium of that node, while icons shown at the top edge of a node represent the reward/outcome.

November 24 2022

With the dual game progression dependency graph and spatial graph, I can now begin to construct a world to explore. Right now it's still looking rather abstract. 😅

November 28 2022

Whee, I now have actual "gameplay" created from my game progression dependency graph and spatial graph (starting from 16s in the video). Only a few node types for now, but it's a cool milestone! 🗝🍎🐱🚩

The game will be focused on exploration, paying attention to the environment and finding clues in it about how to progress.

A note on the spatial graph. The spatial positions of elements are laid out based on a node relaxing / repulsion algorithm, and then Voronoi cells are created at each position and walls created between cells that don’t belong to the same location.

November 30 2022

Every gate, key, creature etc. now has a unique generated pattern to identify it by, so I could get rid of all the letters. One step closer to a world full of visually depicted clues.

Adding some trees. Trees make everything 1000% better.

December 3 2022

Generating a strange walled garden full of secret clues, based on a game progression dependency graph.

Someone noted in the replies that the "kitty keys" are an unusual concept, and that they couldn't think of an example where you need item A to lure creature B to point C to unlock gate D. I don’t know of that exact constellation elsewhere either. In some animes (and also The Fifth Element) a human is a key. And in the game Rime there’s some robots that serve as keys. I thought animals could be a fun variation on this already strange theme.

December 19 2022

Why did I implement this mechanic!? It'll just reveal I'm terrible at remembering things! Anyway, just a few new mechanics implemented for my strange walled garden that's procedurally generated based on a game progression dependency graph.

December 23 2022

Playing an instrument and finding songs with curious powers in this strange garden. (The game progression dependency graph it's procedurally generated from is shown at the end.)

End of prototype

At this point I stopped working on this prototype. As a proof of concept it had succeeded with the successful generation of fully playable little levels with a variety of gameplay mechanics and clue types.

The limiting factor was no longer the dependency graphs themselves.

One limiting factor now is the iconographic gameplay. Different creatures are all little cat head icons only differentiated by different colored patterns. For things to be more evocative, immersive, and easy to remember, I need to actually generate 3D animals of a wide variety. So that's the next thing I started working on, though out of scope for this blog post.

Another limiting factor is that I envision exploration to play an important rule in making the game satisfying to play, but the aesthetic of the prototype does not make exploration interesting at all. Luckily, another aspect of the game I've been working on is beautiful terrain generation. So eventually I need to integrate the procedural progression gameplay into those generated landscapes. But again, I need to first put work into creating procedural 3D models of the various gameplay elements before it can all be meaningfully integrated.

I hope you enjoyed this chronology! If you have any questions, let me know in the comments. And if you want to follow the ongoing development of The Big Forest, check out the social media links in the menu, or copy-paste my blog URL into your RSS reader.

The Cluster is now released

2024-08-18T12:35:00.006+02:00

The Cluster is finally released and available for free on Itch. It's a 2.5D exploration platformer set in an open world that's carefully procedurally planned and generated, and does a few interesting things I haven't yet seen in other games (check out the links for more info).

Here's a trailer:

My last blog post about The Cluster was in 2016 and titled "Development of The Cluster put on hold", and by that I meant put on hold indefinitely.

At that time I had reached the conclusion that I had to give up my ambition of releasing The Cluster in the form I had envisioned. That would have required way more variety and features to be implemented, and due to a variety of burdens detailed in the post, that was not really viable after all, due to various details of the game's design and implementation.

The context for this decision was that I had envisioned The Cluster to be a commercial title, and it was my primary game development project at the time. (Back then I was a game developer only in my spare time.) I wanted to switch my focus to different projects that were more viable to be able to be released as commercial games, specifically Eye of the Temple, which has since been completed and released to decent success, and The Big Forest (working title), which I'm working on these days.

Still, I had put an incredible amount of work into The Cluster over many many years (going back to an initial prototype in Game Maker in 2003!), so I never managed to get reconciled with the idea of it never being available for others to see and play. Especially since, like I mentined, it does some things I haven't seen elsewhere. So at some point I decided I wanted to release it for free sooner or later, as I also mentioned in this 2022 blog post. Not in the ambitious form originally envisioned, but in the limited but fully playable state it had already reached, plus a bit of polish to smooth out rough edges - for example adding robust gamepad support.

And so, between 2016 and now I returned now and then to work on The Cluster for a little while, polishing it, fixing bugs, adding gamepad support, adding a settings menu, adding interaction prompts for how the controls work, and lastly, getting a round of playtesting by volunteers and addressing feedback from them. At the beginning of 2024 I said I wanted to get it out this year, and well, now it's finally out.

The graphics are nothing special and the gameplay can get a bit repetitive over time, but still, for people who are content exploring a big world in search of artefacts, where there is a clear structure and purpose to the world layout, the game can be fun for a few hours, and provide an experience different from other games out there.

It's also a showcase game for my open-source framework for layer-based infinite procedural generation, LayerProcGen. Oh yeah, I released that a few months ago, which I guess I never blogged about!

Anyway, the game is free, so give it a try. And if you do, let me know what you think! :)

2023 retrospective and goals for the new year

2024-01-08T16:03:00.011+01:00

2023 was a pretty good year for me!

I'll touch here briefly on my personal life, then go on to talk about the Quest 2 release and sales of Eye of the Temple, and finally talk about my new game project and goals for 2024.

Personal life

It's the first year since the pandemic that didn't feel affected by it. I moved from Denmark to Finland in 2020, just as the pandemic began, so on the social side it was some slow years initially.

Things picked up in 2022, but especially in 2023 we had lots of family and friends from Denmark visit us here and have a great time, and we also made more strides on the local social network front.

Particularly memorable was a wonderful weekend celebrating the 40th birthdays of me and a friend, with some of my closest family and friends from Denmark and Finland at a site called Herrankukkaro in the beautiful Finnish archipelago.

Eye of the Temple released on Quest and turned a profit

In April 2023, a year and a half after the original PC release on Steam, my VR game Eye of the Temple was finally released for Quest 2, with the help of Salmi Games. While it was super tough getting there, in the end we managed to ship the game at a level of quality I'm very proud of. Others agreed; it got a great critical reception, as well as a high user rating of 4.7 out of 5 stars.

It's super gratifying regularly seeing new reviews of the game from people who say it's the best VR experience they've had. Oh, and recently, UploadVR ranked it the 5th best game for Quest 3 and Screen Rant ranked it the 6th best game for Quest 2. Wow, what an achievement for my little game! (But remember, critical acclaim does not equal sales…)

I’m no longer working on the game at this point. After being occupied with it over a span of seven years, I really want to move on, and I'm also done with VR in general for now. But the sales of the game are still developing, so let's talk a bit about that.

My thinking about the game’s sales performance has changed a lot over time. I didn't pay myself a regular salary during the game’s three years of full time work. But when evaluating the game financially, I use the old salary from my previous job as reference, and calculate whether my time investment at that salary (I’ll refer to it as just “my investment”) would be covered retroactively by the game’s revenue. Of course, I also keep in mind that the covered percentage would be higher if I based it on a more moderate salary.

I was initially slightly disappointed in the Steam sales. As I wrote about back in November 2021, the projected year one sales would only cover 25% of my investment. Back then I expected the Steam year one revenue to make up the majority of the game's lifetime revenue. One year later, the sales had outperformed that projection, and my investment was actually covered 40%.

A lot has happened since then, in particular due to the Quest launch.

Comments from many VR developers in 2021 and 2022 had indicated that Quest sales could commonly be 5x-10x as large as Steam VR sales. For Eye of the Temple, the Quest week one revenue was merely twice of what the Steam week one revenue had been, so it was not quite as high as Salmi Games and I had hoped for. Speaking with other VR developers in 2023, it seems that the time when Eye of the Temple launched on Quest was generally a bad period for Quest game sales.

Still, Quest is easily the most important VR platform, and later the sales picked up significantly, with the recent Black Friday and Xmas sales combined having as big an impact on revenue as the launch sales. Already, 70% of total revenue has come from Quest and 30% from Steam, with the Quest version having been out for a shorter time.

My investment is now covered 140%. In other words, even based on a proper salary for myself that's fitting for my experience, Eye of the Temple has recently flipped well into profitability. That still doesn't make it a runaway hit, but it's really nice to know that it's a success not only creatively and as a passion project, but also in terms of financial sustainability. Back in 2020 when I was still developing the game, I had not expected that at all for my first commercial title.

My new project: The Big Forest

So what comes after Eye of the Temple? Like I wrote above, I'm done with VR for now.

The working title of the new game I'm developing is "The Big Forest". It's set in a big mystical forest and has a strong focus on exploration. The gameplay will involve light puzzles based on connecting clues found through exploration and gradually gaining access to new areas.

The project is in its early stages. The game will be fully procedurally generated, and so far I've been working on a series of disconnected experiments and proofs of concept that will eventually all be rolled into the game. These include procedural generation of terrain, gameplay progression, creatures and music.

I started working on the game in 2022, but I put it on hold shortly after, when I started working on the Quest 2 version of Eye of the Temple. In the last third of 2023, I started working on the procedural landscape for the game again. You can see an overview of that progress in the video below.

As for what the game is about in general, I made this page about The Big Forest where you can read more about it.

Goals for 2024

I expect The Big Forest to be my focus for several years (and that might end up being an understatement).

But I also have a list of more concrete things I hope to get done in 2024, not all directly related to my game:

Present my Fractal Dithering technique

Update January 2025: Didn't quite make it for 2024, but it's done now

I want to release a video, blog post, and source code for a rendering technique I call Fractal Dithering. It's unrelated to my game — just something I developed because I had an idea for it and had to try it out. The code is all done, and I worked on an explainer video (not the one here below) back in June-July 2023. But making the video took so long that I ended up having to take a break from it because I was losing motivation. Let's get that wrapped up.

Release my Layer-Based ProcGen for Infinite Worlds framework as open source

Update May 2024: It's done

I've put more than a decade into developing a framework for contextual procedural generation of infinite worlds. I wrote about it here in 2013. I originally developed it for the game The Cluster I was working on at the time. I since abandoned that game, but now I'm using the framework for The Big Forest. I think the framework could be useful for others as well, which is why I'd like to open-source it.

The generality of the framework is proven by using it for two entirely different games - The Cluster being a 2.5D platformer where the world is made out of generated meshes and The Big Forest being a first/third-person game based on generated terrains. In 2023 I put some work into removing cruft from the framework that was only relevant to The Cluster, and generally streamlining it. There's still some more of that work left to do.

Wrap up and release The Cluster as a free experimental game

Update August 2024: It's done

I already wrote about it here in 2022, but I'd like to wrap up my old game The Cluster and release it for free as an unfinished game, partly because the game is fully playable and one can easily have a few hours of fun playing it, and partly because the game demonstrates a lot of interesting things that can be done with my Layer-Based Procedural Generation for Infinite Worlds framework in areas including level design and pathfinding. It's the longest-running project of my life, and it'd be nice to get it out there, even if it's in an incomplete state.

Make better use of my YouTube channel

Until recently, my YouTube channel just had various videos that show off things with little or no comment, and without any channel branding or identity. I'd like to start making videos in a more "classic YouTube format" where I discuss a subject with a proper intro and outro, channel branding, background music, etc.

I've just recently kickstarted that effort with the video about developing a procedural landscape for The Big Forest that I embedded further up this page. I aim to produce a few more such videos in 2024, for example one video for each of the subjects mentioned above.

What would you like to see?

The goals above all relate to things I'd like to share, so I'm very interested in gauging which of those things might be of interest to you all. If there's anything you'd be interested in in particular, let me know!

Charts to visualize how much you owe Unity for their per-install Runtime Fee

2023-09-15T16:39:00.010+02:00

Unity Technologies has announced a new Unity Runtime Fee that charges developers a fee of up to $0.20 per installed game above certain thresholds. According to my calculations, it can be a bankruptcy death-trap, at least in certain cases.

Shockingly, the owed percentage is unbounded to the point that the owed amount can exceed gross revenue, since it depends on installs, not sales.

Update 1: Unity since backtracked and apologized for the announced changes. With the new updates to the terms, Unity will clamp the install fees to be at maximum 2.5% of revenue. And the changes will not be retroactive after all. Furthermore, John Riccotello is stepping down as CEO. There are more details in the linked blog post.

Update 2: About a year later, Unity canceled the runtime fee altogether. Good.

Nevertheless, Unity has suffered a tremendous decrease in trust and goodwill, which already was not great before. With the cancellation, there is less urgency for developers to switch to a different engine, but the whole situation has highlghted the importance of being prepared for such a scenario and have eyes and ears open towards other engines as well.

The original post continues below.

You can check out the specifications in their blog post. Based on those, I've made two charts where you can look up how big a percentage of your gross revenue you would owe Unity, based on the number of installs and on how much revenue you make for each of those installs. The fee specifications are different for Unity Personal and Unity Pro, so there is a chart for each.

If you want to check the math used for the charts, you can check out the source for the chart for Unity Personal and the chart for Unity Pro.

Effect on free-to-play games

The first takeaway is that free-to-play games are kind of screwed, since the average revenue per user is often very low in that monetization model. This is probably deliberate. See, Unity is reducing or waiving the new fees for games that make use of certain services of theirs, such as Unity Gaming Services or Unity LevelPlay mediation for mobile ad-supported games. And there are reports that getting more games to adopt these services and kill off the competition was the whole point of introducing the new fees. This sounds like a rather shitty anti-competitive practice.

Enough about free-to-play though; I don't personally care that much about it and my knowledge about this area is very limited. What about premium games? Even if those are just collateral damage in Unity's strategy, they are still profoundly impacted.

Effect on premium games

Premium games (games that are bought with an up-front purchase) can typically have price tags such as $10, $20 or $60, and at those prices, Unity's Runtime Fee of $0.20 (or lower) per install is just a tiny fraction, right? No, unfortunately that's not how it works at all.

Sure, if you assume that a premium game has one install per unit sold, and think of the revenue per install as the original price the game is sold at, then the new fees don't look too bad for premium games. But it's a trap to think that way.

The average lifetime price for a premium game is lower than you think

The average price a game sells at over its lifetime can be a fraction of the price it sells for initially. Deep discounts (e.g. 90% off on Steam) and bundles (Humble Bundles and similar) can rapidly drag down the lifetime average price of a game, since it often happens that way more people buy it at these lower price points than at the original price.

So when using the charts above, don't consider a game's initial price. Instead, think of the lowest price the game could be sold at when it's at the maximum discount it will ever be, or when it's sold in a bundle together with other games, each game earning only very little per sale.

And that low price, that's just the starting point.

The number of installs is not the same as the number of copies sold

Don't think of the X axis in the charts above as the number of copies sold. The number of installs can be much higher, due to a variety of factors:

A customer can install their purchase copy on multiple devices. Unity has said this will count as multiple installs.
A customer can uninstall the game and later install it again. Unity initially said this will count as separate installs and later said it won't. They have not disclosed how they would be able to know.
On some devices and stores, updating a game to a newer version might count as a new install. Unity has not disclosed their methodology.
Pirated versions of a game are unrelated to copies sold. Unity has said those won't be counted, but in practice they have no way of knowing if a given install is a pirated copy or not. They have said that developers are welcome to contact them if they suspect they have been victims of piracy. If this does not fill you with confidence, you're not alone.
Sometimes, full premium games are made free to play for a weekend or similar. It's a kind of demo, but using the same build as the full game. It's just limited in time. Meta also has a try before you buy functionality where players can try certain games for e.g. 15 or 30 minutes before deciding if they want to buy it. These types of demos, that are not separate builds, count towards the install counts of the full game, and obviously the number of people who try the game can be much higher than the number who end up buying it. It essentially behaves similar to the free-to-play model.

How to actually use the charts

The problem is that you probably have little idea what the sold-copies-to-installs ratio will be for your game, given all the unpredictable factors mentioned above (multiple devices, reinstalls, updates, piracy, time-limited full-game demos if applicable). But you can start by pretending one sale equals one install and plot a point in the chart based on that.

Plot an initial starting point in the chart based on sold copies and revenue per sold copy:
- For the X axis, predict how many copies your game will sell.
- For the y axis, predict the average price the game will sell at, keeping in mind that it'll probably be closer to the lowest price the game will ever sell at than to the initial price.

Now spot the diagonal black line that goes through the chart, which represents the 0% threshold.

Draw a line from your chosen initial starting point in the graph and down and to the right, parallel to that black 0% line.

The higher the sold-copies-to-installs ratio is, the further you will move down and to the right along that line. This is because a higher sold-copies-to-installs ratio will both increase the number of installs and decrease the revenue per install. And in these particular charts, it forms a straight line because both the X axis and Y axis are exponential.

Example

Let's say you expect your game will sell on average for $10, taking discounts etc. into account, and that you expect to sell 300k copies. You want to know what you might owe Unity if you stay on the Unity Personal license (which is actually allowed regardless of revenue according to their announced changes).

So in the chart for Unity Personal you plot in an initial point, which is at 300k on the X axis and at $10 on the Y axis. This would represent what you owe if there is exactly one install per sold copy.

But to be aware of potential effects of the sold-copies-to-installs ratio being higher, you draw in a diagonal line starting from your initial point and going parallel to the bottom black 0% line.

Following this line shows you the effect of higher sold-copies-to-installs ratios, such as 2x and 10x, and you can see how this drastically affects how big a percentage of your gross revenue you owe to Unity.

Consequences

Unfortunately I can't help you figure out what is a realistic sold-copies-to-installs ratio to expect, because I have no idea even for my own games, let alone others'. And that's kind of the problem here. Charging based on installs is utterly bonkers due to how unpredictable it is.

It's impossible to budget for. And it makes all kinds of things which are a normal part of game development (like discounting your game, accepting that piracy is inevitable, etc.) into suddenly nerve-wrecking issues since they could have drastic effects on what you owe Unity.

On top of the number of installs being unpredictable even if they were counted correctly, you also can't trust Unity to do that, since the way they track it is proprietary and unaccountable. It relies on Unity saying "trust us, you owe us this much money" and you not being able to inspect their methodology, data, or calculations at all. And many of the things they claim they will correctly count or correctly refrain from counting, are simply not practically possible.

In fact, an alleged Unity employee (and it looks legit to me) posted anonymously that Unity is aware developers may in some cases lose more per install than they earn, even to the point of bankruptcy, but that they would "fix this with the customer to not bankrupt them".

The issue with that is that no serious business would leave a matter of potentially going bankrupt to be addressed with some future ad-hoc fix at another company's whim. That stuff needs to be up-front and contractual, even with companies you trust, let alone with Unity.

In short, this is an absolute train wreck.

On a related note, I also wrote here about how contrary to what Unity says themselves, Unity 2022.x or earlier and Unity 2021.x LTS or earlier are not affected by the Unity Runtime Fee as far as I can tell, based on Unity's own Terms of Service. It covers how a previous version of the Terms of Service allowed to stick with that version of the Terms of Service if you don't upgrade Unity, and how it doesn't matter that Unity removed that clause in a later version of the Terms of Service, since the older terms did not give them the right to change the terms like that.

Behind the design of Eye of the Temple

2023-05-06T16:29:00.011+02:00

My VR adventure Eye of the Temple, that I've been working on since 2016, has landed on the Meta Quest 2! It was released last week on April 27th.

Get Eye of the Temple for Quest 2 on the Oculus Store

Originally released for SteamVR in October 2021, so many people have asked for it to be brought to the Quest 2 as a native app, so I'm happy it's finally a reality. The Quest 2 version was co-developed with Salmi Games and it took all our combined and complimentary skills to bring the game to life at target framerate on the Quest 2 mobile hardware.

We also made this new trailer:

The game got a fantastic reception! UploadVR called it "A Triumphant Room-Scale Adventure" and has labeled it an essential VR experience, and it got great video coverage by Beardo Benjo, BMFVR and many others. It also got great user reviews and a high review score on the Oculus Store.

Behind the design

To mark the Quest 2 launch of Eye of the Temple, I've written no less than three articles - published elsewhere - about different aspects of its design.

The Origins and Inspirations of ‘Eye of the Temple’

To celebrate the launch, I spoke with Meta about the origins of Eye of the Temple and the wide variety of inspirations (from classic platformers to Ico and Indiana Jones) behind the game.

Read the article on the Meta Quest blog

Approachable and Immersive Design in ‘Eye of the Temple’

Immersion can mean many things, and VR has lifted the ceiling for immersion in games higher than ever before. In this article, I’ll detail how a design dogma of “embodied immersion” in Eye of the Temple goes hand-in-hand with making the game highly approachable—even for people who don’t normally play video games.

Read the article on the Oculus Developer blog

The Hidden Design Behind the Ingenious Room-Scale Gameplay in ‘Eye of the Temple’

Eye of the Temple is one of the rare VR games that focuses on not just on pure room-scale movement, but dynamic room-scale movement. The result is a uniquely immersive experience that required some clever design behind the scenes to make it all work. This guest article explains the approach.

Read the guest article on Road to VR

Other bits and pieces

Here's a reddit post talking about how we had to completely change the water effect implementation on Quest 2 in order to keep the same aesthetic on the mobile hardware.
Here's a short YouTube video where I explain how the room-scale platforming gameplay works behind the scenes. It essentially covers some of the same subject as the Road to VR guest article I mentioned above, but in less details.
Here's an FAQ with answers to common questions we've received since the Quest 2 release.

One year later...

2022-10-14T17:08:00.014+02:00

Today is the one year anniversary of the release of my VR adventure Eye of the Temple on Steam! It's currently 40% off to celebrate.

I thought I'd take a moment to talk about what I've been up to since the release, both related to Eye of the Temple and other projects.

Eye of the Temple updates

In the months after the release I worked on various fixes and updates to the game.

In December I added save slots selection and Steam Cloud support.
In February I implemented some minor improvements to the VR comfort options.
In April I released a new feature called Speedrun Challenges with bite-sized fast-paced physical challenges and Steam leaderboards integration.

Of those, the Speedrun Challenges was the biggest feature. Leading up to its release, a handful of people from the game's Discord community had been testing the feature and competing for top spots on the leaderboards of the challenges. This was really great to see! I also set up a page on speedrun.com and even implemented autosplitter integration for the popular speedrun timer LiveSplit, meaning that the game can control starting and stopping the timer exactly.

Here's a video of Mettanine's current world record for the first speedrun challenge:

I had contemplated whether to run some sort of contest when the Speedrun Challenges feature released. However, after some contemplations back and forth, I decided not to wait and see if there was any interest in the Speedrun Challenges feature at all. I figured a contest should be used to boost existing interest, not conjure up interest out of thin air based solely on extrinsic rewards.

As it turned out, there wasn't any interest to speak of. Once the feature released (which I posted about in various speedrun and VR subreddits and Discord servers, on Steam and Twitter, and wrote to journalists about), there were only a couple of people trying it out - much fewer than the handful who had been fairly active testing it during beta. Oh well. While certainly some people found the idea fascinating, I guess speedrunning and physically intense VR are two niches with too tiny an overlap, at least for PC VR.

How has the game performed in its first year?

I wrote last year that sales of Eye of the Temple around its release had been mediocre, and that assuming year one sales would be about 3x of week one sales, the game would be on track to cover maybe half of its production costs after one year of sales if I based it on giving myself only an entry level game programmer salary.

Year one sales outperformed that projection, instead being 4.45x of week one sales in units sold, and 4.1x in revenue. So that's nice! The costs are about two thirds covered instead of only half. If I instead base the costs on my old salary I got at Unity, they would be covered only 40% so far. However, I think expecting a lower salary when going indie is reasonable, especially in the beginning.

What about a Quest 2 port of Eye of the Temple?

Edit: Eye of the Temple for Quest 2 released on April 27 2023! See this post for more details.

There's still no announcement regarding a Quest 2 port of Eye of the Temple at this time, but I do hope and believe it can happen, and there are still continuous efforts trying to make it a reality. Let's just say, I've been in a whole lot of meetings.

My next game

I have ideas for a new game, but it's in very early stages. It won't be a VR game. It'll be procedurally generated world focused on exploration. It doesn't have a name yet, but let's call it The Big Forest for now.

As the code name suggests, the game will take place in a big forest. I developed a procedural environment experiment in 2016 that serves as a proof of concept.

The game will have a generated structure of progression. In April I worked on experiments generating such structures and visualizing them as dependency graphs and spatial graphs.

The game will have procedurally generated and animated creatures, and I've experimented a bit in August with procedural animation. Luckily I can draw on my experience developing my Locomotion System back in 2009.

Furthermore I have ideas about how to populate the world in a way that's informed by my article from 2021 about designing for a sense of mystery and wonder. Combining all these elements into an actual game is going to be a tall order though.

My old game The Cluster

Before I started working on Eye of the Temple in 2016, I had worked for over ten years on a fully procedurally generated 2.5D platformer game called The Cluster. (Fun fact: The term "procedural generation" was not in common use back when I started in 2003, so I called it random level generation.)

Eventually in 2016 I gave up releasing that game in a traditional sense, for a variety of reasons. But in the past year I've gone back and implemented a few improvements and bug fixes, and I'm considering whether I should spend a bit of time wrapping it up enough to be released for free as an experimental game, or an extended tech demo if you will. (Update: I released The Cluster as a free game in August 2024.)

For one, the game is fully playable and certain people can easily have a few hours of fun playing it. I recently recorded half an hour of gameplay here:

For another, the game demonstrates several techniques that I think are still to this day somewhat novel within the field of procedural generation.

Overall, the game's procedural generation applies a planning approach to an infite world generated on the fly. In this article from 2015 I contrast the simulation and the functional approaches with the planning approach, which is more akin to traditional level design. In procedurally generated games, there are many examples of a planning approach used on finite levels generated all at once, for example in rogue-likes, and there are examples of the functional approach used for infinite worlds that are generated on the fly, for example in Minecraft. But I'm not sure how many games have used a planning approach for infinite worlds. The Cluster's multi-tiered map shows the game's planned space on a vast scale.
It demonstrates that the "Layer-Based Procedural Generation for Infinite Worlds" approach that I discuss in this moderately popular YouTube video from 2013 actually works and scales up to a playable game.
The game has directional signs at various spots where the road forks, pointing the way to landmarks like shrines, gates and the hub village. While this is common in manually designed games, I'm not sure if I've seen it in procedurally generated worlds. The things pointed to exist far outside the currently generated chunks, and reinforces the feeling of the world as a carefully planned place.
Because the game's planned world has knowledge of goals far outside the currently generated chunks of the world, the gameplay can revolve around exploration with a hints system that provides a balance in between aimlessness and knowing where to go.
It incorporates full enemy path finding in a 2D platform game, and moreover a procedurally generated one at that, so enemies can follow the player almost everywhere. It may have been done before, but it's certainly not common in platformers.
The game has sophisticated camera framing. Based on the locations of walls, ground and ceiling segments, the camera positions the player differently in the frame and smoothly interpolates between these different framings.
The game has a lot of built in debug options that makes it possible to inspect various aspects of the generation at the various layers of abstraction.

It feels like a shame to let all this go unreleased. On the other hand, any work on this free release can be seen as a distraction from working on my next proper game which has commercial potential. If you're interested in the release of this game, please let me know, since that all helps motivating me to wrap it up.

Overall

It's been a bit of a weird year. My attention has been split between all of the things above: Updates to Eye of the Temple, meetings related to porting it, working on various experiments for my new game, and tinkering on wrapping up my old procedural platformer. There've been periods of productive focus and motivation, but also periods in between of procrastination and lack of motivation. I hope I can find my way into a more persistent groove soon.

I can't talk much about Eye of the Temple, but if there's anything related to The Big Forest or The Cluster that you find interesting and would like to hear more about, let me know! This can help inform future blog posts and videos, and maybe even what I'll focus my attention on.

My experience launching Eye of the Temple

2021-11-22T13:53:00.020+01:00

My VR adventure Eye of the Temple, that I've been working on for the past five years, has finally shipped! It was released last month on October 14th.

Naturally this was a huge milestone for me after having worked on it for so long. And while I've released some smaller games for free in the past, Eye of the Temple is my commercial debut game. I actually did it! Wow, I say, patting myself on the back.

Shipping the game has been great, but also a bit confusing emotionally. There has been some big ups and also some downs. I might as well write about it here - mostly for my own sake, but who knows if it could be useful or just entertaining to someone else.

The time leading up to launch

I’m a developer first and foremost, and I frankly don’t enjoy doing work related to promotion very much. I know many others are in the same boat.

The last major development work I did before launching was implementing localization around the end of August. Then came some weeks of working intensely on creating two trailers - the launch trailer for launch day, and a shorter launch day announcement trailer to be released a month before launch. Both trailers used mixed reality footage recorded by Anaburn.

When the trailers were more or less done, I had an entire month of doing just promotional work like creating gifs, sending out a press release and mails to journalists and creators (influencers) about the upcoming launch, tweeting, preparing the game for launch in Steamworks, tweeting specifically to influencers, plan pre-launch exclusive streaming with Ragesaq and spazkoga, writing to the (small) mailing list, etc. etc.

Once launch day came, I had been deeply entrenched in “PR mode” for a long while, which is probably not ideal for my psyche.

Launch day

Release day finally came and I spent much of it sending out emails to journalists and YouTubers, writing posts on Reddit, Twitter and Facebook, and keeping the awesomely supportive people on the game's Discord server informed, and asking for their support once again. At 4 pm (local time in Finland) I finally pressed the release button and then I was busy replying to the flurry of comments and replies everywhere for a few hours.

A few days earlier I had asked for advice on Twitter about what to do on release day in order for it to be a good emotional experience. The general advise was to avoid sitting in front of a screen all day obsessively hitting refresh on pages, and instead make sure to take time to celebrate the achievement of shipping in good company with good food and drinks. And so I did!

At 6 pm my partner and I went over to a launch party that my friends at Forbidden Studios had graciously offered to host at their studio. Champagne was had, pizza was eaten, and some people tried out the game for the first time while onlookers were entertained by it. Lots of chatting and high spirits. This was really nice and I hardly checked the Internet at all.

In the following days my notifications were on fire like I've never experienced before, and I spent all my time replying, retweeting and posting a few things of my own. It was kind of stressful but also very cool.

I checked the sale stats too.

Mediocre sales

Sales of Eye of the Temple were not absent. The game was selling. It just wasn't selling a lot.

Let me clarify one thing. Most indie games aren't selling a lot. In fact, most indie games sell less than Eye of the Temple. It's well known that only a fraction of games on Steam make enough money to make game development sustainable for their developers. Even a base level of success (only barely covering the costs of making the game) requires being way above the median. So let me start by saying that I’m lucky the game has been selling at all.

Will sales of Eye of the Temple on Steam cover the costs of making it? Not really. I’ve developed Eye of the Temple over five years, but some of it was part time. It corresponds to about three years of full time work. Since it’s predominantly developed solo with only little use of contractors, the biggest expense is salary for myself. If I calculate with a salary for myself that’s less than half of what I’ve earned in the past, and lower than the average entry level game programmer salary (ignoring I’m a senior programmer with 13 years of experience), the game is on track to cover maybe half of that after one year of sales, assuming year one sales will be about 3x of week one sales.

But I’m fortunate to have other sources of income besides the game sales, so I won’t be struggling paying my bills. Don’t worry about me.

Really, the main reason the sales feel mediocre to me is that I think there’s a lot more people who would enjoy the game (and have the means to play it). But before I can meditate on the question of whether it feels like Eye of the Temple should have been able to sell better, we first need to catch up with some other things that happened.

An awesome review score

Four days after release I wrote this on Twitter:

Eye of the Temple currently has 32 reviews from paying customers. I'm curious if it'll reach the magical threshold of 50 reviews in the first week. No matter how highly a game is rated, it can only go from "Positive" to "Very Positive" with 50 reviews.

And lo and behold! Already the day after I could write this:

Eye of the Temple reached 50 reviews, and Steam changed the label to 'Very Positive'! This honestly happened quicker than I thought it would, and I really appreciate the help from you all! Thanks a lot!

A “very positive” rating on steam requires at least 50 reviews and that at least 80% of them are positive. But Eye of the Temple has a much higher rate of positive reviews. At one point it was 98%, a fact I used as part of drawing focus on the end of the launch discount.

Promotional image used when the launch discount was about to end.

It’s since dropped to 96%. (With only a bit over 100 reviews, all it takes is one more negative review to make it drop one percentage point, while it takes over 20 positive reviews for it to climb back up again.) Still, that’s a super high percentage I hadn’t expected at all, and I’m positively thrilled the game has been received that well!

During development I had the impression, based on play-testing with lots of people (also VR first-timers), that only quite few people had issues with motion sickness when playing the game. However, I always had a worry that my perception was skewed for some reason, and that lots of people would report getting motion sickness once the game shipped, and that this would have a big negative impact on the review score. But that never happened at all, and that has been a huge relief!

The awesome Steam reviews

The reviews on Steam are just awesome. They proclaim Eye of the Temple to be not only mechanically groundbreaking with an unprecedented level of immersion, but also simply one of the best VR games created.

Capturing the essence of over 100 reviews is no easy task but I’ve put together the following summary, with links back to 27 of the original reviews.

A slew of reviews highlight the uniqueness of the game, saying it’s “a refreshing change to see a new game form in VR”, that there’s “nothing like this in VR”, and that it’s an “instant classic”. Others write that it’s “some of the most creative VR gameplay of any VR game”, that it’s “nothing short of genius”, and that “this dev is some sort of mad genius”. Some write that it’s “a revolution in Virtual Reality” because “the motion system is completely revolutionary” and that it has the “potential to create a whole new genre in VR-Games”.

According to the reviewers, what makes it so innovative is that “being able to actually walk through the entire game in your play space is just mind boggling and super immersive”, making it “one of those rare mind-blowing VR experiences”. Some say that the game “does otherworldly things with your mental perception” that “makes you forget you are in VR” and that as a result, “the immersion level is off the chart” and it “takes vr immersion to a new level”.

For some reviewers, that level of immersion made this VR adventure the “most ingenious and thrilling VR game”, speculating that “if Steven Spielberg or George Lucas made VR games instead of movies ... this is the VR game they would come up with” because it “captures perfectly the whole Indiana Jones vibe”, so that “if you want to feel like Indiana Jones, this is the closest you could ever get”.

Overall, lots of reviewers say it’s “one of the best VR experiences” and “one of the greatest VR experiences of all time”. Several focus on room-scale, calling it “the best Roomscale VR Game” they’ve played and “the best room scale experience out there”. Some say it’s the “2nd best roomscale game” next to Half-Life: Alyx and that they “haven't had this much fun since playing Half Life Alyx”. Others think Eye of the Temple surpasses it and is simply the “best VR game”. One reviewer didn’t limit it to VR and said: “I’ve been playing video games for 30+ years, and finding ALL the secrets in Eye of the Temple was easily the most satisfying moment I’ve ever had in a game!”.

It’s almost hard for me to believe how positively these reviews describe the game. I’m blown away and humbled by the response here.

Of course, if you would rather sample some of the reviews yourself, you can see all the reviews on Steam here.

The buzz

A whole lot of people made videos of Eye of the Temple on YouTube, most of which can be found here. It’s too many to list, but I appreciate all of them! I gave out a lot of keys to even YouTubers with very low subscriber counts who had shown an interest in the game while it was in development. There has also been many people streaming the game.

A few larger channels made videos as well. Here’s all the videos I know of with 2,000 views or more:

Beardo Benjo (14K views)
Naysy (11K views)
Daily VR (5K views)
OtterWorldly (4K views)
Ben Plays VR (3K views)
My own official launch trailer (3K views)
RitualNeo (2K views)
Disco-VR (2K views)

A lot of the videos are really brilliant. The most concise is the excellent 2 minute review by Ben Plays VR while two of the most entertaining to me are the mixed reality videos by Naysy and OtterWorldly. Naysy even had a TikTok video too that went viral with over 4 million views. That’s really cool!

I couldn’t see any spikes in sales from any of these things, but I’m convinced they all helped a lot combined. All in all, it feels like there’s a bit of a “word of mouth” effect for Eye of the Temple.

The silence

Disappointment is just a miscalibration between expectation and reality. In this section I’ll talk about the biggest emotional let-down, but it’s important for me to emphasize that I’m not complaining, blaming anyone, or saying that the world is unfair. I’m just saying that I had certain expectations that were not met, which means they were incorrect to begin with.

You see, I had kind of assumed that the press outlets and popular YouTube channels that had covered the game before its release, and spoken highly of it, would most likely also cover the release of the game. That turned out to be an incorrect assumption.

Let’s start with the press. The highest-traffic outlets that have reviewed Eye of the Temple are Android Central, VRFocus and the German MIXED, which all reviewed it on launch day. Eye of the Temple hasn’t gotten reviews in more mainstream outlets like IGN, The Verge or Screen Rant, and I never much expected it would, since they never covered the game prior to release either.

In contrast, the two most popular outlets for VR news, UploadVR and Road to VR, have covered the game multiple times prior to the release. UploadVR covered it here, here, here, and here and mentioned it in an article 38 Titles We Can’t Wait To Play and Road to VR covered it here, here and here. With that much coverage prior to release, it took me by surprise that they didn’t review the game when it finally launched, and here over a month later still haven’t. UploadVR did post a quick note about the end of the launch discount and I appreciate that of course.

Taking a bit more zoomed out perspective, we can look at Metacritic. Metacritic doesn’t include all reviews, but it can still give a general overview. When looking at the Metacritic page for Eye of the Temple you can almost hear the tumbleweeds rolling, with its single review from VR Focus. Compare with the pages for other recently released VR games that sold much better: I Expect You to Die 2 (PC version) with 11 reviews and Sniper Elite VR (PC version) with 20 reviews. Of course, those weren’t made by solo indie developers, but it’s just to put things in perspective.

On YouTube a similar effect was going on, to a degree. Since we already talked about coverage of the released game on YouTube, with the most seen video having 14K views, we can do a little comparison with some videos from last year that covered the free demo of the game:

Ctop (105K views)
Virtual Reality Oasis (50K views)
A Wolf in VR (27K views)

This makes the view counts of the videos of the released game seem almost quaint in comparison. The demo got covered by channels that have more subscribers and can command higher view counts. (That’s ignoring Naysy’s TikTok video that got 4M views of course. I don’t currently know how to meaningfully compare YouTube views with TikTok views.)

Here, I had particularly thought it likely that Virtual Reality Oasis would cover the full game since he’d talked positively about it not only in his video but also in the podcast he hosts. On Twitter, after release, someone suggested he was likely to cover the game, to which he replied “I already covered it and had a great time with it” - referring to his coverage of the demo a year prior. And I really appreciated that earlier coverage of course, and said as much. And yet: That there’s no reason to cover the released game when already having covered the demo is a logic that probably makes a lot of sense from the perspective of a YouTuber’s situation, but to the game developer it feels like getting cold water thrown in your face. My expectations were miscalibrated, and having them corrected was no fun.

Another YouTuber I had hoped might cover the game, even if it was a slim chance, was Nathie. He hadn’t covered the game or its demo, but he had covered the game jam game Chrysalis Pyramid from five years earlier that was the precursor to the game. And back then he had said he hoped the developers would make a full game out of it, and he had made a bunch of suggestions for things to include in such a game. And now five years later, there is a full game, and it does include a lot of the things he suggested. If he then tried out that game on his channel, it would be like going full circle. It just seemed like such a good story, and people love good stories.

Two weeks after release I told that story through this video, honestly hoping it might nudge him to cover the game on his channel. The video was very well received by people, and I was happy to see that Nathie also quote tweeted it on his Twitter account, but alas still no video coverage. Ah well, it was worth a try.

Anyway, lesson learned. With both press and influencers it seems logical to think “if the game got this amount of coverage before it was released, surely it will get at least as much if not more when it actually launches”. But that’s not a given at all. Reality can end up being the opposite.

Speculation time

Okay, there you have it, all caught up. The reviews on Steam were way better than I expected and there was a healthy buzz on YouTube. The coverage in the press (and to a degree among more mainstream YouTubers) was way worse than expected, and worse than coverage of the game prior to release had been. And the mediocre sales were somewhere in between, being lower than expected but not completely bad.

Now I can meditate on whether it feels like Eye of the Temple should have been able to sell better, or rather on what the reasons might be that it didn’t.

Maybe PC VR is just dead

That’s what some people tell me. All the attention is on Oculus Quest these days. There might be something to this, though this doesn’t explain why some other recent PC VR games like Sniper Elite VR, Cooking Simulator VR, or I Expect You To Die 2 sold way better on Steam than Eye of the Temple (extrapolated from number of reviews). And Eye of the Temple has as good Steam review or better as any of those.

Maybe it’s because the play area requirement limits who can play the game

That’s true. According to an old survey, only about 50% of people with VR headsets have a play area of 2m x 2m or more. Headsets have decreased in price since then, becoming available to people with lower income, and this might mean an even lower percentage have enough room now. But that’s only because the number of people with headsets grew so much.

It’s estimated that 2 million people own Half-Life Alyx and that per July this year there are nearly 3 million monthly connected headsets on Steam. Even if only 10% of those have a 2m x 2m play area, that’s still a huge market. So the play area requirement is by no means the bottleneck here.

Maybe people just don’t care as much about indie developers with no track record

Harsh but true to a degree. I mean, like I described above, there has been decent coverage of Eye of the Temple in the press prior to launch, and a respectable YouTube buzz when it launched, so it’s not like nobody cares. But when looking for reasons why there was so little coverage upon the actual launch, and also why the sales weren’t better, being an unknown indie is probably a notable factor in that.

Maybe it’s my lack of PR experience

Another factor that goes hand in hand with being an unknown indie developer that self-publishes is having a lack of PR experience and know-how. While I’ve read a lot on the subject and followed a lot of best-practices (sending review keys to journalists and influencers well in advance of launch etc.), there’s undoubtedly also things I didn’t think about, things I didn’t execute well on, and things I did know about but didn’t have time to even try. I’m pretty sure this factors into the lack of press coverage.

Maybe the demo stole some of the thunder

Journalists and influencers prioritize "fresh news" and there's a risk that a demo (or free prologue) released in advance of a full game can detract from the "news value" of the release of the full game. The original intention was that the demo was released a few months in advance of the full game, which is supposedly the ideal gap, but then the full game took much longer to wrap up than I had thought. It ended up being released a full year after the demo, and this can further have magnified the "old news" effect.

Maybe the game just doesn’t have mainstream appeal

Oof, this is not a nice thought. This is also very speculative because it’s very hard for me to directly assess. While developing a game, it’s easy to get trapped in an echo chamber where you hear most feedback from fans of the game. I feel like I’ve always been aware of this, and while I’ve never dismissed positive feedback, I’ve kept in mind that it might not be representative of a larger player-base.

However, the reviews on Steam has been just as positive. Is it possible for Steam reviews to be an echo chamber too? I suppose if a game’s presentation (trailer, store page etc.) very effectively selects for the people who will end up enjoying it, then maybe… If this is what has happened, it’s probably a good thing. It’s valuable for a game to only attract the people who will enjoy it, exactly so that it can get better reviews, word of mouth etc. from those who have played it.

However, it would also have the effect that the positive reviews are not at all indicative of potential for more mainstream interest in the game, which could be counter-intuitive and confusing. This would explain the large discrepancy between the really positive Steam reviews and the mediocre sales and silence from the press. But I don't know if a "Steam review echo-chamber" is a plausible hypothesis or not.

Maybe it's the game's presentation that doesn't have sufficient appeal

One thing that goes against the "limited mainstream appeal" hypothesis is that many people have talked about how showing the game off to family and friends is a blast, and have recommended the game as a great choice to show to VR first-timers. I would think that this indicates very healthy mainstream appeal. Another possibility could be that while the game itself has good mainstream appeal, the game's presentation, such a trailers and store page, doesn't manage to convey that, and doesn't manage to attract all the people who would have enjoyed the game if they tried it. But the plausibility of this hypothesis is also hard for me to assess.

Maybe it’s a combination

It’s probably a bit of all of the above?

Still, I have a feeling there’s a lot more people out there who would enjoy the game, and I hope more of those people might discover the game over time and get to see for themselves what those glowing reviews are raving about.

The future

Here’s what I have planned for Eye of the Temple:

I want to add support for multiple save slots so multiple family members can play with separate saves, and people can let their friends try the game without losing their own progress.

I might look into adding some features to the speedrun mode that might make it more motivating to try out, like having speedrun challenges for completing just a section of the game.

And of course, I’d love to bring Eye of the Temple to Oculus Quest 2, but I don’t have the skill-set to do it myself. I’d need help from a skilled Unity developer (studio or individual contractor) with lots of experience profiling and optimizing for Quest or other mobile platforms. I'm now in contact with a number of companies - we'll see how it goes!

Thanks for reading! If you have any thoughts on all of this, be sure to let me know. :)

Designing for a Sense of Mystery and Wonder

2021-02-08T11:05:00.009+01:00

I play games to get to explore intriguing places, while challenge and story is secondary to me. But there still has to be a point to the exploration. I don’t want to just wander around some place - I want to uncover something intriguing and ideally mysterious. But the mystery lies not in the uncovering; it lies in the anticipation, or rather the lack of knowing exactly what I might find. In this article I examine that sense of mystery and wonder that’s tied not to story or themes, but to exploration. I’ll be using the word mystery as a shorthand for the kind of mystery and wonder I’m talking about here.

Zelda: Breath of the Wild from 2017 is an amazing game to go explore in, and one of my all time favorites. That said, while there are many things in the game that exude a sense of mystery - and certainly more so than in the average open world game - there are also a lot of missed opportunities.

Breath of the Wild reinvented the Zelda formula as an open world game.

I’ll compare Zelda: Breath of the Wild (BOTW) with Zelda: A Link to the Past (ALTTP) to try to figure out why ALTTP has a stronger sense of mystery than BOTW. A Link to the Past is a much older Zelda game from 1991 but I first played it in 2019.

Along the way I’ll be extracting four key design strategies for evoking a greater sense of mystery, and apply those strategies in the form of proposed design changes to BOTW. Finally, I’ll touch on some more general considerations to keep in mind when designing for a sense of mystery and wonder in general.

Mystery-mileage

While I’m critical of certain aspects of Breath of the Wild in this article, I want to highlight a few things that did give me a sense of mystery and wonder: The eerie Lost Woods, the disorienting Thyphlo Ruins, and the three deceptive enormous labyrinths found in the world. These all evoked a great sense of intrigue and not knowing what I was dealing with or what I would find. But the sense of mystery in those locations largely came from them being unique one-of-a-kind things (or three-of-a-kind in the case of the labyrinths, although they were quite different from each other).

One of the three towering labyrinths in Breath of the Wild.

While having one-of-a-kind mysteries like this is absolutely great, not everything in a large scale game can be uniquely different from everything else. It would require too many resources and not be manageable. That’s why this article focuses on strategies that make the existing variety of content in a game less predictable and more mysterious without requiring large amounts of additional variety of content. That’s the kind of strategies Breath of the Wild could have used to get better “mystery-mileage” out of its already amazing content.

Curiosities with unknown outcomes

Let’s start with the most obvious element that caused many people to feel that the world in BOTW is not as mysterious as it could have been. When you explore the vast world of Breath of the Wild, you’ll frequently come across something curious, like a circle of plants in a pond or an abstract stone sculpture with a piece missing. And initially you’ll go “huh, that’s curious” and be intrigued. Let’s investigate! You try to dive into that circle of plants in the pond or locate and add the missing piece to the stone sculpture - and a little fellow pops out of nowhere and rewards you with a Korok Seed! Oh cool!

A little puzzle in Breath of the Wild that rewards the player with a Korok Seed.

However, by the 20th time you notice something curious, you’ll probably be thinking, “ah, it’s probably just another Korok Seed”. It’s still a fun little thing to do, and the Korok Seed is useful, sure, but there’s no longer any sense of mystery about it.

To be clear, there are various small mysteries in BOTW that lead to other things than getting a Korok Seed, but those are usually related to quests that lead to an Ancient Shrine of the Blessing type. In contrast, Korok Seeds never involve a quest and always follow a set of predictable templates. It’s a many-to-one relationship: One set of curiosity types leads to Korok Seeds and a separate set of curiosity types leads to shrines.

Not knowing what you get

How does this compare to A Link to the Past? The closest analog in ALTTP might be the optional heart pieces, since they are also often hidden behind a little curiosity or mystery.

Compared to the Korok seeds, though, the heart pieces in ALTTP are more strongly related to exploring nooks and crannies in the world. Sometimes you can see one in advance out of reach and the puzzle is figuring out how to reach it. Other times they just reward exploration but couldn’t have been known in advance.

Pieces of Heart are hidden away in many novel ways in A Link to the Past.

Sometimes they’re inside a chest, but chests can contain other things than heart pieces too. Similarly, reaching the heart pieces sometimes involves blowing a hole in a cracked wall with a bomb. But cracked walls can also lead to other things than heart pieces, so you won’t know what you’ll find. It’s a many-to-many relationship: Each of the curiosities that might lead to a heart piece (a chest, a cracked wall, etc) might also lead to another outcome.

The fact that the curiosities or puzzles that lead to heart pieces don’t follow specific templates that are only used for heart pieces means that finding heart pieces in ALTTP doesn’t feel formulaic and predictable in the same way that finding Korok Seeds does in BOTW. And this uncertainty and unpredictability about what to expect contributes to a sense of mystery.

The many-to-many relationship

What have we learned in this comparison between the curiosities in BOTW and in ALTTP?

A question we can ask to determine if we are not getting the best mystery-mileage out of curiosities in the world is:

When the player sees something curious in the world, can they predict in advance what they’ll get out of it?

And a strategy we can make use of to decrease predictability of the outcome is:

Have a many-to-many relationship between the types of curiosities in the world and the types of outcomes.

Perhaps it can sound like unknown outcomes is about randomness, and that it’s the same principle that makes slot machines and loot boxes addicting but not intrinsically engaging. But unknown is not the same as random. When you explore a world and learn of an outcome of a given curiosity located at a specific location, this knowledge might be relevant later in the game, or if replaying the game. It’s a fact you’ve learned that’s tied to the experience of exploring the world. Loot boxes, in contrast, are not tied to a location in the world and the outcome can’t be learned. As such they’re not tied to exploration but are detached random events.

Now let’s try to apply the strategy above to curiosities in Breath of the Wild. Perhaps some of the “Korok” style puzzles shouldn’t always lead to Korok Seeds. Sometimes they could lead to, say, an entrance to some area opening, a treasure chest being revealed, or it could mark the beginning of a new side-quest. Then you wouldn’t know in advance what you’d get or even it’s degree of significance. The relationship between curiosity and outcome would have been changed from a many-to-one relationship to a many-to-many relationship.

Ambiguous classification of spaces

In the last section we looked at how to make it harder to predict what you’re going to get. In this section we’ll be looking into how to make it harder to form an idea of what something even is. We’ll explore ambiguous classification starting with a comparison of the Ancient Shrines in BOTW with the dungeons in ALTTP.

Ancient Shrines and Dungeons

The entrance to a shrine in BOTW always uses (nearly) the same model. So you know exactly what a shrine looks like.

An Ancient Shrine in Breath of the Wild. They all look like this.

When you enter, you descend a long tube elevator down into an often enormous space. The kind of challenge found there varies greatly (sometimes there’s no challenge at all, if the challenge was reaching the shrine entrance in the first place), but invariably you will reach a platform at the end with a treasure chest and a monk who grants you a Spirit Orb that can be used to increase health or stamina. Then there’s a cut, and you’re back at the Shrine entrance in the world above.

Dungeons in ALTTP are not an exact analog to Shrines in BOTW. The dungeons play a more central role since they give you new abilities, they end with boss fights, and beating them is required. Still, they’re close enough for our comparison.

Entrances to dungeons in ALTTP don’t have a specific look; they are each unique.

Various entrances in A Link to the Past. Can you tell which of them lead to dungeons?

Some of the images above depict entrances to dungeons while some of them depict other entrances that are not to dungeons. Can you tell which is which? I actually can’t remember this myself despite having played the game just a few years ago.

I can’t overstate what this does for the sense of mystery when exploring this world. Instead of seeing “there’s a dungeon”, “there’s an X”, “there’s a Y” etc. I just see mysterious entrances. Who knows what’s inside? Compare this to BOTW where you always know when an entrance is an Ancient Shrine because all shrines look the same.

Now, I know that some dungeons in ALTTP get explicitly marked on the world map, but that doesn’t counteract the sense of mystery entirely.

What even is a dungeon?

Now, if this was only about the entrances, we could say this is another example of a many-to-many relationship where you don’t know what the outcome is in advance when you see an entrance.

But in ALTTP the mystery doesn't stop when you've entered an entrance because even once inside, it's still not entirely clear what kind of space you've entered. Is it a dungeon or not? And if it is, what does that mean exactly?

For what is a dungeon? There's forum discussions online where people discuss how many dungeons ALTTP has, and people reach different numbers depending on which criteria they use. Is it the spaces where you get a new ability? The ones that end with a boss? The ones that are mapped out with a dungeon map? And does the castle that you clear one part of, and then later in the game return to clear another part of, count as one or two dungeons?

This illustrates that it's not entirely clear cut what what constitutes a dungeon in this game, and I find that to be a good thing. It’s harder to know what to expect, and consequently, it feels more like anything might be possible, when structures in the game don’t consistently follow clear templates and the player can’t conclusively classify the spaces they encounter.

But just having occasional exceptions to the template isn’t enough. Imagine what it would do to the sense of mystery in ALTTP if dungeons clearly communicated “this dungeon follows the classic template” or “this dungeon is an exception” as soon as you see the entrance? This would greatly reduce the intrigue for the dungeons that follow the template, since it’s clear what to expect from them. This is exactly the situation we have in Breath of the Wild.

BOTW does have a few dungeon-like places that don’t fit the shrine template. And they were highlights in the game. But the sense of mystery those “exceptions” from the template produce doesn’t rub off on the shrines, simply because it’s so easy to tell if something is a shrine or something else. It’s important for the sense of mystery then, that the instances that are exceptions to the template can’t always clearly be told apart from the instances that follow the template.

Undermine simple classification

What have we learned in this comparison between the Ancient Shrines in BOTW and the dungeons in ALTTP?

A question we can ask to determine if we are not getting the best mystery-mileage out of different types of spaces in the game is:

Can the player easily tell different types of spaces from each other and unambiguously classify them?

And a strategy we can make use of to increase ambiguity is:

Reduce or eliminate signifiers that would otherwise clearly distinguish different classes of spaces from each other, or introduce exceptions that challenge or confuse simple classification.

Now let’s try to apply this strategy to the Ancient Shrines in Breath of the Wild. Instead of using the same recognizable model for all shrines, it would have been viable to create a dozen different “entrance” 3d models, each of them still highly visible from afar so they can still serve as a goal to move towards, and have each shrine use one of those. Crucially, these entrance models should also be used for entrances to other things than shrines - like notable caves, hideouts, passages and similar. (Footnote: And yes, shrine entrances also have a Sheikah Plate activation mechanism and a teleport location marker. Where would they be if using an entrance model that’s not specific to Ancient Shrines? I don’t have an answer to that but it’s a solvable design problem.)

This would make use of the many-to-many relationship discussed previously to ensure that when you’d see some entrance, you wouldn’t know what it would lead to - an Ancient Shrine, or something else. You’d have to investigate to find out.

However, this only makes the nature of the space unclear prior to entering it. To truly make the classification ambiguous, it would have to stay unclear also while inside the space, and maybe even still after having completed the encounter. This means we have to break down some of the other clear signifiers of Ancient Shrines too.

Does every shrine have to begin with a tube elevator? Does it need to be a separate space from the outside world at all? Consider the shrines of the Blessing type, where the challenge lies in finding and reaching the shrine entrance in the first place, typically in some hard to reach spot, while there’s no challenge inside the shrine space. The treasure chest and monk simply sit there.

In Ancient Shrines of the Blessing type, the treasure chest and monk are reached without any challenge.

Why do shrines with no challenge inside need a separate shrine space at all? Couldn’t the monk sometimes hang out right in the hard to reach spot? In that case, it would be more ambiguous whether the defining trait of a shrine is just the presence of the monk, or if there has to be a separate shrine space as well.

Another possibility could be that after completing one shrine in the game, the monk at the end would be missing. Maybe there’s a message that you have to find him elsewhere in the world (yes, “our monk is in another castle”). Would this still count as a shrine? And if so, would the shrine count as completed before or after finding the monk?

If the answers to such questions could go either way, we’re on the right track towards the classification ambiguity that enhances the intrigue. If on the other hand you still think it would be obvious whether something is a shrine or not, think about what distinction makes it obvious and how that distinction could be broken down as well.

One last point regarding this type of ambiguity is that UI and other meta-elements can easily counteract it, if not carefully avoided. For example, the ambiguity of what is or isn’t a shrine is decreased if a title displayed on the screen tells you that this is a shrine, like in the image above. Maybe those titles are deemed important to keep for other reasons, but it’s worth being aware of the tradeoff involved.

Overlapping gameplay modes

Fairies are a staple in the Zelda franchise and they usually come in two varieties: Regular fairies that can be used to restore heath, and Great Fairies that can upgrade some armor or weapons.

In Breath of the Wild, regular fairies are found primarily at Great Fairy Fountains where the Great Fairies also reside, but also at other locations like atop the Deku Tree, at a pond on Ebon Mountain, and in Hyrule Field. They are always out in the open.

Fairies in Breath of the Wild can be collected at various spots out in the open world.

In A Link to the Past, regular fairies are found at Fairy Fountains located in a great variety of places. It’s normally in a cave or other inside area, but the entrances to these areas may be regular cave entrances, a staircase hidden below a rock, a hole in a hollow tree trunk, a hole under a bush, or behind a wall you have to blow up.

Fairy Fountains in A Link to the Past are hidden in a variety of ways.

Interestingly, these entrances are not only out in the open world. Notably, some fairy fountains are hidden away inside dungeons. In BOTW, finding fairies and clearing shrines are two entirely separate activities or gameplay modes with no overlap - from a design perspective it’s very clean - while in ALTTP there’s an overlap. Clearing a dungeon leading up to a boss is not a separate gameplay mode from searching for hidden secrets.

It might seem like a moot point to highlight such an overlap of gameplay modes - of course you can explore and find all kinds of secrets in dungeons just like in the outside world - why wouldn’t you? But the shrines in BOTW shows us that it’s not a given.

Spaces that serve multiple gameplay modes

In our comparison of BOTW and ALTTP we’ve found that a breakdown of clear separations between different gameplay modes enhances the sense of mystery because the player can’t form clear expectations of what to find where. Interesting things can be found anywhere.

A method we can use to determine if we are lacking overlap between different gameplay modes is:

Making a list of the different game activities or modes that exist in a game. Does certain locations or spaces in the game offer only few or a single gameplay mode to engage with?

And a strategy we can make use of to increase overlap of gameplay modes is:

Ensure spaces and locations in the game serve multiple different gameplay modes, though not all of them have to be equally obvious.

Let’s consider how we might apply this in Breath of the Wild. All over the outside world you can find various ingredients for recipes, some more rare than others. Why not be able to find those inside Ancient Shrines too? Not necessarily as a regular thing, but it could add a lot of sense of mystery to all shrines if some rare ingredients could be found inside even just a few of them. This would create an overlap of the gameplay modes of finding ingredients and clearing shrines.

And why stop at ingredients? Certain shrines could have fairies in them - just like certain dungeons do in ALTTP. Why, maybe you might even find a Korok Seed inside a shrine! Or certain side quests in the outside world might be initiated somewhere inside specific shrines. These design changes would break down the otherwise clean separation between Ancient Shrines and other gameplay systems and activities, and in the process contribute a bit to also making shrines feel like a more integrated part of the world.

Integrating the inside with the outside

We need to talk about caves. A Link to the Past is full of caves. Some cave entrances simply lead to a small cave room where you may find a reward like a treasure chest - possibly with a puzzle you need to solve first.

Some caves have multiple entrances. Sometimes when you enter a cave you’re teased with a reward you can’t get, but you can get it if you enter via a different entrance. Other caves serve as a shortcut - or maybe as the only route between two places. This makes the caves feel less like a space entirely separate from the world and more like a place that’s an integrated part of the world itself.

Cave entrances in A Link to the Past.

This all adds intrigue, because you have no idea what the nature of a given cave is before you explore it. It might be something trivial but could also be something critical to progress in the game.

Now comes the extension to this I particularly like. It’s not only random caves that can have multiple entrances. For a few of the dungeons, this is the case as well. For example, there’s a dungeon that you can exit through a different entrance and reach an area in the outside world that’s only accessible this way.

The Desert Palace in A Link to the Past is a dungeon with multiple entrances.

This greatly enhances the sense of mystery for several reasons. One is, as noted for caves, that it makes it harder to predict what to expect when the boundaries between different systems and spaces are less strict. But another reason is that mystery thrives when it’s grounded. The more logical, tangible and real the places in the world feel, the better they support suspension of disbelief, and the more effective the sense of mystery becomes.

Compare the dungeons and caves in A Link to the Past to the Ancient Shrines in Breath of the Wild. To get into an Ancient Shrine, you enter a small entrance above ground and soon find yourself in an enormous ornately decorated underground space. The first few times this feels super mysterious. How could this otherworldly space have been created deep underground? Astounding and unreal! But after seeing this repeatedly it begins to no longer feel unreal in a mystical way but rather in a gamey way. Is this space even located under the entrance at all? It might as well exist in a different dimension. And what difference does it even make? In the end, the game just transports you to a space entirely separate from the outside world - it’s a game thing; it’s what games do. And so the suspension of disbelief is eroded, and the sense of mystery along with it.

The inside space as a continuation of the outside

Comparing caves and dungeons in ALTTP with the Ancient Shrines in BOTW shows us the importance of integrating inside spaces into the larger world.

A question we can ask to determine if confined spaces in the game are disintegrated from the overall larger world is:

Does a given type of confined space in the game always have only a single connection to the larger world? Does navigation inside this type of space never affect navigation outside the space, and vice versa?

And a strategy we can make use of to increase integration is:

For a given type of confined space, design at least certain instances of it as a continuation of the outside space such that navigation inside and outside of the space affect each other.

This could be applied in Breath of the Wild to infuse a greater sense of mystery to Ancient Shrines by occasionally giving them a separate exit from the entrance. In these cases you’d emerge in the outside world somewhere else than where you entered the shrine. Maybe some spot off the beaten track, sometimes half hidden, but where it’s interesting for the player to end up?

While we’re at it, we could also, rarely, have a secret entrance/exit in a shrine as well (a bit like the secret exits in Super Mario World). It could for example lead to a location in the outside world that’s only accessible this way.

A suggestion I’m not making is to make the layout of the shrines physically match and integrate into the outside world. While it would undoubtedly be cool, it would be so much extra work to design them under that constraint that it wouldn’t be viable, when taking into account that there are hundreds of shrines in the game.

Breath of the Wild already demonstrates that this kind of tight integration can be done, because the dungeon-like Hyrule Castle is designed exactly in such a tightly integrated way - and it’s awesome!

Hyrule Castle is one of the few dungeons in Breath of the Wild that has a tight integration between the inside and outside areas.

But there’s a difference between pulling it off once and pulling it off hundreds of times. That’s why the proposed design changes are ones I believe could have been pulled off without incurring too much extra work. In the end, a successful integration of the inside and outside of a space hinges more on the purpose and navigation of the space than on its aesthetics.

Clean design versus mystery

I’ve suggested four different strategies for increasing the sense of mystery and wonder. You’ve probably noticed they all relate in some way to reducing how formulaic and predictable a game is to the player.

Classic system design wisdom that can help a large project stay manageable and maintainable is to make different systems have clear responsibilities with minimal overlap and interdependencies.

In that light it’s easy to imagine that gameplay elements like Ancient Shines and Korok Seed puzzles have a sort of template that takes care of all the common elements so only unique content has to be filled in. And that makes a lot of sense from a production perspective. However, it may also inadvertently lead to a diminished sense of mystery.

Ironically, I think it might be easier for designers not as experienced in making clean maintainable designs to stumble upon creating a sense of mystery, because a lack of clear consistencies in a world lends itself well to that. I even suspect that part of the reason A Link to the Past has a greater sense of mystery might be that the developers had not been forced to establish quite as efficient production processes and pipelines. After all, A Link to the Past, while large for its time, is a game of much smaller scope than Breath of the Wild.

The world in A Link to the Past was large for its time, but small compared to Breath of the Wild.

The point is not to make less clean or less maintainable systems. But I think it’s worth considering whether clean and unambiguous systems (from a design and production perspective) should also be clean and unambiguous to the player. And if they shouldn’t, then applying the strategies for creating a sense of mystery can make the systems less transparent to the player.

Ambiguity versus usability

Now, more ambiguity is not always better, and the usability of a game should not be sacrificed to obtain it. For an interaction to be easy and efficient to engage with, the user needs to be able to predict the outcome of their actions. This is generally the opposite of what we need to create a sense of mystery and wonder.

This means it’s important to be conscious about which elements of the game should aim for usability and which should aim for ambiguity. There is no one right way to determine that; rather, it depends on which kind of experience you want to evoke.

One rule of thumb is to avoid unpredictability where it causes significant frustration for the player in a non-engaging way. In this article I’ve focused on a sense of mystery tied mostly to exploration, and I think that it’s rarely frustrating not to be able to predict what you’ll find when exploring a new area. An exception to this is if the exploration has a significant cost. For example, if a game has bottomless pits that kill you, but some secretly contain a bonus item instead, that might enhance a sense of mystery but would also be frustrating to search for.

Another rule of thumb is to focus on unpredictability in gameplay elements that exist squarely within the game’s fiction, whereas focusing on usability makes sense for elements that form the interface between the player and the game. If the player can’t predict how to do something in the game (like how to jump, or how to dig a hole with a shovel) which the game’s protagonist would undoubtedly know how to do, then that leads the player’s attention to meta-elements of the game, which can diminish suspension of disbelief. On the other hand, things that are as unpredictable to the game’s protagonist within the fiction as it is to the player don’t compromise the immersion in the fiction.

How to interact with a menu is rarely where you’ll want to prioritize mysterious ambiguity over usability.

Some cases are not as clear cut, for example games where the player has lots of weapons, and certain enemies are only vulnerable to certain weapons. If there are no tells and the player simply has to find out by trial and error (as happens to be the case in ALTTP), then that’s an element of unpredictability. Some people like this and feel it adds to the sense of mystery while other people consider it a case of frustratingly bad usability.

Careful simultaneous attention to usability and unpredictability is also needed when it comes to puzzles. In a good puzzle it should typically be easy to predict how to interact with the elements of the puzzle, while it should be hard to predict how the individual elements in the puzzle combine into the correct solution.

In general though, these rules of thumb can be bent and broken to good effect when done intentionally and for good reasons. The point is not to always optimize for one thing or the other, but to be aware of the tradeoffs and make design decisions with intentionality.

Pattern breaks

So far I’ve mostly discussed how to achieve a sense of mystery and wonder by designing systems that never get too formulaic and predictable, which keeps the player on their toes. We can call this pattern obfuscation. However, there’s an argument to be made for an alternative approach where we let things get predictable, only to then subvert the player’s expectations by breaking the established pattern. Some of the design proposals above arguably already fit that bill, but let’s take a closer look at this distinction now.

While discussing a draft of this article, Nick Konstantoglou from KickBack said, “When the player stops seeing the world and starts seeing systems and to 100% know what to expect, the mystery dies. But it's really so easy to reintroduce the mystery element: Just break the pattern a few times. Making the player complacent and then pulling the rug under them completely resets expectations and I would argue it’s even more effective than if they never got complacent at all.” This is sometimes referred to as a pattern break.

One pattern break that left a big impression on me was in Super Mario 64 when encountering the Boo ghosts in the castle. Up until this point, the castle had been strictly an “overworld” serving as a gradually expanding map giving access to the individual stages of the game. When dying in a stage, you’d be thrown out of it and back into the castle, whereas there were no enemies or dangers in the castle itself. That pattern was broken with the Boos, which pulled the rug under me and made me question my assumptions about the castle. As a side note, this pattern break also broke down one of the (assumed) distinctions that separated the stages and castle as two different classes of space. The castle made use of several other pattern breaks as well and successfully remained mysterious throughout the game.

Encountering Boo in the castle in Super Mario 64 subverts the otherwise safe nature of the castle.

To obfuscate or to break

The difference between pattern obfuscation and pattern breaks is mainly a matter of when and how frequently a pattern is mixed up and which feelings you want to evoke. Pattern obfuscation is more subtle, since the player may not become aware of a pattern in the first place but just experience an undefinable sense of mystery. On the other hand, the subversive nature of a pattern break may evoke a stronger emotion, especially if the subverted pattern was an obvious one that had gotten very predictable. This stronger feeling comes at the expense of a greater sense of boring predictability up until the pattern break happens though.

The surprise of a pattern break itself is not the primary reason for its inclusion - it’s the increased sense of mystery from that point onward, due to the player no longer being sure of what to expect. As such, for a pattern break to be effective, it has to come late enough that the player has formed clear expectations based on a set pattern, but not so late that there isn’t much time for the post-break increased sense of mystery to pay off. Realistically you’ll need multiple different pattern breaks at different times to get the most out of it.

From a production perspective, pattern breaks lend themselves well to be hand-crafted one-of-a-kind exceptions to a pattern, since in their nature they are infrequent. They still provide good mystery-mileage because the mystery rubs off on the remaining instances that follow the pattern. Pattern obfuscation on the other hand needs to be more systemic and often involves mixing up multiple systems, such as with the many-to-many relationship strategy.

That said, there’s no hard line to be drawn between pattern obfuscation and pattern breaks. You can see it as two ends of a spectrum, and my design proposals in this article have been a bit all over that spectrum, really.

In our toolset of mystery-creation, it’s good to be aware that the sense of predictability versus lack of predictability is something that can be manipulated over the course of the game and played with in various interesting ways, to different effect.

In conclusion

I’ve discussed four concrete strategies for getting more mystery-mileage out of different elements and spaces in a world:

Have a many-to-many relationship between the types of curiosities in the world and the types of outcomes.
Reduce or eliminate signifiers that would otherwise clearly distinguish different classes of spaces from each other, or introduce exceptions that challenge or confuse simple classification.
Ensure spaces and locations in the game serve multiple different gameplay modes, though not all of them have to be equally obvious.
For a given type of confined space, design at least certain instances of it as a continuation of the outside space such that navigation inside and outside of the space affect each other.

These strategies are in no way exhaustive. They are merely examples, and don’t apply to every game. However, even if they don’t apply directly to a game, they might give you some ideas for similar strategies that do.

At a more general level I’ve discussed the tradeoff between mystery and usability, and the rules of thumb to prioritize unpredictability mainly where it doesn’t cause too much frustration and where the unpredictability is situated within the world’s fiction rather than in the interface between player and game. And I’ve discussed the ways a sense of predictability versus mystery can be manipulated differently with pattern obfuscation and pattern breaks.

By using these strategies and tools in our toolset, we can - without incurring significant extra costs in development - help prevent our worlds from getting predictable and formulaic, and in turn leave all the more room for players to experience a sense of mystery and wonder while exploring.

Thanks for reading! Writing an article on game design is new for me, and obviously many of the points I’ve made here are a lot more subjective than in my more technical articles. Whether you agree or disagree with them, I’d love to hear your thoughts! Let me know in the comments which games gave a particularly great sense of mystery for you when exploring them, and why you think that is.

Update October 2024

I'm honored that this article was quoted from and linked to by Mark Brown in Game Maker's Toolkit. Go watch the video, it's a good introduction to the topic of designing games to feel mysterious: What Makes a Game Feel Mysterious?.

Browsing the other resources referenced in that GMTK video, not many of them went to much analytical depth on the subject (or were even addressed to game designers), but this recent talk by Andrew Shouldice at GDC 2023 was excellent, with clear takeaway: 'TUNIC': This Was Here the Whole Time.

Via that talk I also stumbled upon an old talk by Jim Crawford of Frog Fractions fame, which likewise has clear takeaway on the subject of mystery: Preserving a Sense of Discovery in the Age of Spoilers.

Getting TortoiseHg on Windows to work with SourceHut's SSH authentication

2020-12-09T12:40:00.006+01:00

You can skip to the header below for the actual guide. Or stay here for a rambling preamble.

I'm a skilled programmer, but I'm not a technical person. I'm not good with computers. Or at least I highly prefer if things just work, and I don't have to fiddle with settings and configurations.

This is one reason I strongly prefer Mercurial for source control over Git. It has a higher degree of just working. (I don't want to get into an argument over this. You can question my assertion, but my preference is my preference in any case.)

Unfortunately Mercurial has become a niche choice as Git has achieved overwhelming popularity, largely due to GitHub. I wouldn't really have cared about that, except it made BitBucket close down their support for Mercurial some time ago. And BitBucket was a hosting solution for Mercurial that was affordable and also just worked.

I and many other Mercurial lovers have then had to find alternative hosting. And I ended up with choosing SourceHut. SourceHut is the opposite of "it just works". It's made for people who identify with hacking and tinkering and knowing all the technical stuff. Why did I choose it then? The "just works" alternatives had pricing that just did not work for a game development use case.

Now, SourceHut has been a pain to use in many ways for a non-technical person like me, but I've had the most pain at all trying to get SSH authentication to work. Unlike BitBucket, SourceHut does not allow HTTPS authentication, so you have to use SSH, and nobody ever sat down and made SSH easy to use on Windows.

Getting SSH to work involved juggling things like multiple types of SSH keys and formats all placed in a hidden folder, many different helper tools, and reading dozens of half-baked how-to guides that all contradict each other, often assume prior knowledge, and that are all for slightly different use cases which means they didn't quite work for me.

I got it all to work around a year ago, but I recently wiped my hard drive and needed to do it all over. I couldn't remember anything, so had to figure it all out all over again. So now I'm writing my own half-baked guide, mostly for my future self in case I need it again, but others might stumble over it and maybe find it useful too I guess.

When you read this guide, you might think it doesn't sound that complicated after all. But remember the guide omits all the things I read I should do and which I thus attempted, but it didn't work, and eventually turned out not to be needed anyway. Like running the main PuTTy application, or running tortoiseplink, or editing your mercurial.ini file. Anyway, on to the guide.

Getting TortoiseHg on Windows to work with SourceHut's SSH authentication

Use the instructions here to generate an SSH key and add it to sourcehut:
https://man.sr.ht/tutorials/set-up-account-and-hg.md

Ignore the rest, from "Creating a Mercurial repository" and forward. I assume you already have one, and in this guide we don't want to push with command line since we'll be using TortoiseHg.

Now you should have a id_rsa private key and id_rsa.pub public key inside a folder called .ssh (inside your user folder), which is hidden by default. You can change Windows settings to show hidden files and folders if you want to be able to have a bit better overview.

Download PuTTY. Inside the PuTTY installation folder you'll also find PuTTyGen. Use PuTTyGen to create a id_rsa.ppk key from the id_rsa key using the instructions here:
https://devops.ionos.com/tutorials/use-ssh-keys-with-putty-on-windows/#use-existing-public-and-private-keys
Note: In the open dialog, you need to change the dialog to display "all files" in order to see the id_rsa key. The guide above doesn't mention that. PuTTY can still import it even though it doesn't even display it by default. Save the file as id_rsa.ppk inside the same .ssh folder the other keys are in. Ignore the rest of this guide. You don't need to run the main Putty application itself.

Download TortoiseHg if you haven't already. In the TortoiseHg installation folder, you'll find a helper tool called Pageant. As explained in the tips and tricks section of this guide, we'll want Pageant to automatically load your key when it starts. I'll summarize here:

Make a shortcut to Pageant if you don't have one already. Right click the shortcut and click "Properties". In the Target field in the properties window, you need to keep what's already there but also add a space and then a path (in quotation marks) to your id_rsa.pkk file at the end so it's automatically loaded when Pageant starts.

Now, before you start up TortoiseHg you always need to run Pageant first, using the shortcut you made. Then you should be able to use TortoiseHg to pull and push with SSH authentication.

However, optionally, you can automate this. You can make Windows run your Pageant shortcut on startup by moving the shortcut to the Windows startup folder: Open the “Run” dialog box by pressing the Windows key + R. Type “shell:startup” (without the quotes) in the “Open” edit box and click “OK.”. Copy the shortcut into this folder.

Then you can always use Tortoise without having manually run Pageant first.

That's it! If you have any issues or questions, don't hesitate to - um, to google your issues and try to figure it out. I really can't help you; I don't know what I'm doing. I only barely got this to work myself, and don't really know why, or how it all works. Sorry!

Goodbye Unity

2020-12-04T10:45:00.004+01:00

Today is my last day at Unity.

It's been nearly 12 years since I joined the then-tiny startup with ~20 employees. Now there's over 3000 and it's been quite the ride to be part of this company while it has evolved, especially with the big role it has had in evolving the whole game industry too.

Lately I've been longing to do something smaller again, and so it's time for a new adventure in my work life to begin. Starting next week, I'm a full time indie developer!

For a start I'll be wrapping up my VR action-adventure game Eye of the Temple that I've been working on part time for the past 4 years. There's a demo on Steam already that has very positive reviews and I expect the full game can ship in early spring 2021.

What I'll do after is not fully settled yet, but I have an idea for a (non-VR) game set in a big forest full of ruins, strange artifacts, pathways and mysteries that I might begin working on next year.

My mental state at the moment is kind of a mixed bag. On the one hand I'm very excited about future possibilities and being able to work on exactly what I want. On the other, my motivation and productivity is a bit flaky these days. I don't know the exact reasons, but possibilities could include:

Uncertainty about what my everyday life will be like (though economically I'll be fine!).
Having felt unfulfilled work-wise for a good while before I quit.
Having moved to a new country this summer (from Denmark to Finland), in the middle of a pandemic where it's hard to meet new people.
Being in the end stretch of developing a game where it's mostly boring stuff left.
Dark winter setting in - that normally doesn't affect me much but could be a compounding factor still.

However, I'll go easy on myself and just accept my productivity and motivation not being at its greatest right now. Perhaps I won't hit the ground running in my new indie life, but that's okay. I didn't have that much vacation this year either, so I'll see this as a chance to take it a bit easy for a little while while I adjust to my new life.

All in all, not a bad place to be, and I'm excited about the future!

Eye of the Temple in 2019

2019-12-31T13:47:00.008+01:00

I've completely failed to keep up the posting in 2019, but it's not too late to write at least one post this year! Here's (almost) everything that happened with the development of Eye of the Temple in 2019!

But first, let's look at what happened in the last part of 2018 after the previous post.

Fall 2018

In September 2018 the game got a proper looking in-game menu replacing the old debug UI.

It also got area names appearing when reaching a new area (or revisiting an old one).

Lastly the speedrun mode got completely revamped. In the speedrun mode you can step onto platforms before timers run out to build up incredible speed - if your reactions are fast enough! This is not for the faint of heart, but if you're up for a bigger challenge than the base game provides, it's worth checking out. What's new in revamped speedrun mode is that it gives visual feedback that makes it clear how fast you need to step to rake up speed.

A big update hit in October 2018 with two new areas - Fiery Pass and Black Sanctum - as well as a whole new and rather cool-looking ability in the game which I won't reveal here.

Okay, now let's look at 2019!

New area, new music, and Steam achievements

2019 started with an update in January that added a new area called The Wall as well as changes to the existing areas The Atrium, Monument Square, and The Cauldron. The temple got more "tied together".

January is also when the game got Steam Achievements implemented.

And last but not least, a new dynamic music track was added, composed by Claudio Martinez who's also behind the other music in the game. I implemented the track into the game such that it changes dynamically to match different moods in different areas of the game.

Satisfying combat and water splashes

In February the combat in the game was revamped to feel more satisfying. This was done based on lots of helpful feedback from the playtesters and various people on Twitter.

And water splashes were added to the areas with water for fun and immersion, though they have no effect on the gameplay as such.

Big minecart update

A big update hit in May, where minecart rides were added to the game! To get access to it, you'll have to first get through a new added area called Creepstone Mine. A small new area was also added that's only accessible by minecart.

This update also added a secret room in the game. To this day, none of the playtesters have found it yet.

New areas, and the game now has a story

An area Watergrave Arena was added in August, featuring more combat, and in October an area called Dark Ruins was added which culminates in a new kind of challenge with some tense moments. Afterwards you'll get to pick up an all new gadget.

This update also added a new element to the game which is story. Bits of story can now be uncovered at a number of shrines throughout the temple. The overall story was developed in collaboration with Lex Wilson. In the final game the story bits will be voice acted, but for now it's text only.

Reveal trailer

I released a reveal trailer for the game in November, which you can see here:

This was covered by UploadVR as well as by a few other outlets.

Looking to 2020

2020 is the year Eye of the Temple is released, unless things go terribly differently than I anticipate. (That said, I once thought it would come out in 2017.) There's one final area in the game left to do, apart from various fixes and improvements. That sounds manageable, but then, it's probably the most challenging area to design and get right, being the culmination of the game and all.

If you're interested in Eye of the Temple, don't forget to add it to your wishlist on Steam!

Happy new year!

Creaking Gorge and The Cauldron

2018-09-17T21:38:00.009+02:00

Since my last post in July where I finally got a vision down for the level design in Eye of the Temple, I've been feeling super productive adding new areas and features to the game.

In August I added two new areas and in September I've been revamping the in-game UI and the speedrun mode. Only problem is I haven't kept up with these blog posts. To avoid this post getting too long, I'll cover the new areas here and save the UI work for a later post.

Creaking Gorge

Creaking Gorge is an area where you move along and into cliff sides and atop wooden scaffolding. It's by far the most vertical area in the game, spanning more than 50 meters vertically.

It's a fairly non-linear area too with multiple paths that can be followed in an order you choose. The verticality combined with the fact that not all of the paths can be seen, since they carve into the cliffs, means that it can be a challenge to keep track of your orientation and where to go next.

It's an area of contracts since the bright and wide open space of the gorge itself is interspersed with ventures into cliff caves with narrow corridors and dark suppressing chambers.

Creating Creaking Gorge was mostly a level design job, as the elements and mechanics of it were already present in the game, apart from the wooden scaffolding which is purely visual.

The Cauldron

Following Creaking Gorge comes The Cauldron, a smaller area taking place over flowing lava and involving fire traps and puzzles.

The first thing I did for The Cauldron was start working on the lava surface.

I looked at existing solutions like this Lava Flowing Shader, but its unidirectional flow is more suited to a lava river than the kind of lava pools I have.

I ended up offsetting texture look-ups in two directions according to some sinus and co-sinus functions. Additionally there's a texture that maps distance to walls, so the flow can be slowed there and the lava also be darker. Here's that texture, and its effect on the lava.

The bubbles are made with a particle system emitting sphere meshes, but they looked bad when I just gave them fixed or random colors. I ended up making the regular lava texture based fully on world space look-ups, not UVs, so the bubbles could be mapped identically.

After adding steam particles, a better lava pattern, and baked lightmaps, the result looked like this:

After getting the lava into shape (which frankly is purely visual too but adds a lot to the feeling of the area), I got cracking working out the puzzles. For the fire-based puzzles here, I had to generalize a bit how fire propagation worked so that anything that can catch fire can be lit up by any fire source. The result is some simple puzzles where the player has to use fire in new ways than previously.

Two distinct new areas done in one month! I'll have a hard time beating that in the future I think, but here's to hoping.

Level design workflows

2018-07-14T23:20:00.006+02:00

Let me talk a bit about my workflows for doing level design in Eye of the Temple since I recently had some progress in that area.

I've been in something akin to a level design writer's block for a long time, being able to rework individual small areas, but unable to start the major world redesign that I've been intending for over a year.

Maybe calling it writer's block is pretentious - the fact is that I've never done this sort of work before, so I may just not have developed the necessary workflows to deal with it. Anyway, I think I might have finally cracked the nut.

I've had plenty of ideas, but fragmented and not crystallized enough to get down on paper. How do you start planning a non-linear world meant to be highly interconnected and interdependent? I can talk about what eventually worked for me.

I've long pondered what type of document could help me get ideas down on paper in a quick way. In addition to text documents (glorified to-do lists) I've been using tilemaps for sketching level designs.

I've been experimenting with using Unity Tilemaps as a digital replacement for pencil level design sketches. Some success so far, although I'm really missing rotation/flipping of selection and proper multi-selection.
— Rune Skovbo Johansen (@runevision) November 27, 2017

These tilemaps naturally lead to obsess over details though. What recently helped me move on was allowing myself to draw free-hand inaccurate lines and gloss over the contents of rooms.

It's difficult because I have ideas for the rooms that are important and which informs their shapes. The fear of forgetting those details if I don't put them down right away is there, but have to be ignored to get on with the broader strokes.

In order to inform what to draw in those broader strokes, I consult my documents with intended progression of a given section of the game. What puzzles are encountered, what abilities are learned and used. This is an iterative process where both documents are altered.

Finally, after watching Boss Keys episodes by Mark Brown, I tried using his dungeon graph notation to document, then refine, how dependencies in the world works. I already had loosely these ideas in my head, but getting things into the right document form can help immensely.

These 3 document types, progressions described in text, a world map sketch, and a dependency diagram, each make certain aspects of the creative process easier, and iteratively refining them all in a complimentary manner now helps me plan out the complex world.

The tilemaps are convenient in that the rough sketches can be refined into more detailed plans over individual rooms where each tile is planned, but my lesson was to only do this later, as necessary.

This is not to say that these will be the only document types I use for planning out the world. None of them capture the three-dimensionality of the world well, and white-boxing may well be the next thing I look into.

That's it. A lesson learned in using various forms of documents that fit various aspects of the job in order to be able to get on with "getting things down on paper".

P.S. Be sure to check out Mark Brown's awesome dungeon graph template on his Patreon.

New pots feature, mixed reality, Discord server, Yonderplay event

2018-04-22T11:37:00.012+02:00

It's time for a new update on the development of Eye of the Temple.

Events

GDC in March is well behind us and I had a great time there. Among other things, I got to show off Eye of the Temple at the European Game Showcase (and saw a lot of other cool games too). This was a private event for specially invited people from the network of the organizers.

Now, Eye of the Temple has been selected for Yonderplay, an event that's part of the Nordic Game Conference in Malmö in Sweden and open to everyone at the conference. This will go down on May 25, the last day of the conference. This is the most public showing of the game yet, and I'm very excited about it! If you'll be at Nordic Game Conference yourself, come by and say hi and give the game a try.

Mixed reality

At GDC I also met some of the fine people from LIV, a platform for mixed reality recording (and more) for VR content. I've been integrating support for LIV in Eye of the Temple (it's very easy) and a handful of people from their community has been helping me test the game both with focus on mixed reality and in general.

Apart from testing and feedback, I've also been allowed to create and use some gifs from their recordings. Being able to show Eye of the Temple in mixed reality is very exciting to me, since it shows the physical nature of stepping around in the game in a way that's been impossible with regular purely virtual footage. Here's a few examples:

These gifs are featuring ThreeDee from ComedyPipe. I tweeted them here and here.

I would love to have mixed reality gifs with others playing the game as well. If you have Vive or Oculus Rift with a mixed reality setup and is up for it, please get in touch!

Discord server

For a long time I've been using itch's forum feature to talk with early testers of the game, but I'm now beginning to move more towards Discord. I've only just learned about Discord recently, but have been happy with it so far. Feel free to join!

Here's an invite link to the Eye of the Temple Discord server

Pots

Last but not least, I just implemented a new feature in the game: Pots!

Pots contain gems. You can tap the pots gently to get the gems out a few at a time or just smash the pots with your whip or torch to get all the gems all at once. But that would be a shame for such antique and rare pottery, now wouldn't it?

The pots give players more opportunities to use the whip, which I think was much needed. They also add more physicality to the game, since the pots (and the shards if they're smashed) are physics-driven objects. Hopefully it also adds just a bit of player expressiveness potential and unpredictability to the game.

A player can intentionally smash a pot, or intend to just brush it softly with the whip to tease out gems in a non-destructive way. This can however still accidentally make it topple over and fall down and get smashed way below. Players could set goals for themselves to smash all pots or avoid smashing any. Whether this will happen in practice is yet to be seen but it at least feels nice to me to allow for different approaches like this.

I made this silly and crudely acted video showcasing the new pots. Do you enjoy pottery too? Let me know in the comments!

New trailer, public Steam page and Eye of the Temple in the press!

2018-03-20T02:20:00.002+01:00

Last week I took a dive into the world of PR with Eye of the Temple.

There is a new trailer you can see on the website eyeofthetemple.com or right here below.

And Eye of the Temple now has a Steam page: Eye of the Temple on Steam

If you have a Vive or Oculus Rift, and think Eye of the Temple looks interesting, you can totally add it to your wishlist on Steam now! ;)

After that I took my first stab at contacting the press with a press release. The story got picked up by UploadVR and a handful of smaller outlets (see list on the Sanctum Dreams website). Considering I'm an unknown small indie developer with no experience with the press, I'm pretty happy with the results.

This week I'm at Game Developers Conference in San Francisco. I'm mostly here with Unity, but I'll also be showing Eye of the Temple at the European Game Showcase.

Exciting times!

January 2018 update

2018-01-30T21:59:00.002+01:00

It seems like I didn't blog since July. How scandalous! Well, here's an update on what I worked on for Eye of the Temple since then.

Presented as a series of tweets, because that's what I have time for.

Note: Add blockers seem to sometimes randomly block some of the embedded tweets for some reason.

Prettier background environment

The cold snowy mountains didn't give the feeling I was aiming for. Failing to find anything ready-made that fit the bill, I created my own lush, mountainous environment.

What do you think of this new environment art for the backdrop of the temple that we've been working on? #gamedev #indiedev #VR #HTCvive pic.twitter.com/ASGxGCeG3p
— Eye of the Temple (@eyeofthetemple) September 20, 2017

Another shot of the mountains surrounding the temple. #screenshotsaturday #gamedev #indiedev #VR #HTCvive #madewithunity pic.twitter.com/GmfAwyzPvp
— Rune Skovbo Johansen (@runevision) September 23, 2017

Failed attempts at mixed reality capture with StereoLabs ZED stereo camera

I think a mixed reality video would be the ideal way to show off Eye of the Temple, so I invested a bit in this. Unfortunately it didn't go well due to a combination of a bad choice of immature tech, and an insufficient green-screen setup. I might revisit this in the future though.

@stereolabs3D Could you show how this 3D printed mount is meant to be used with a Vive controller and tracker respectively? pic.twitter.com/UqoEm0E77v
— Rune Skovbo Johansen (@runevision) September 16, 2017

It's designed to hold a Vive controller, a tracker and even an oculus touch. pic.twitter.com/yc4fC2J5ZJ
— Stereolabs (@Stereolabs3D) September 16, 2017

I posted a video here with my troubles. See tracking issue at 8:04. I mailed your support with more details. https://t.co/DCk6KeRO0O
— Rune Skovbo Johansen (@runevision) September 23, 2017

Argh! Mixed reality recording is hard! #VR #mixedreality #HTCVive #indiedev pic.twitter.com/YWVH6oFgc9
— Rune Skovbo Johansen (@runevision) September 26, 2017

Glowy light for certain platforms

Any Unity shader experts who might know why I get heavy banding on alpha of frag function output on Windows (but not Mac)? pic.twitter.com/Xrq8CliYNo
— Rune Skovbo Johansen (@runevision) October 16, 2017

I made a spiky glow for this platform. Helps a bit with awareness of edges without having to look down all the time. #VR #gamedev #indiedev pic.twitter.com/I9ScvbmzZL
— Rune Skovbo Johansen (@runevision) October 17, 2017

New build for testers with whip and other improvements

I finally finished developing the whip and got a build out to the testers.

Trying to recruit people to test the speedrun mode (never had any luck!)

The speedrun mode is super fun and challenging to me, but nobody else seem interested in it. Besides asking on twitter I also contacted some of the notable VR speedrunners and people who has posted about VR speedrunning on Reddit, but got nothing out of it. If anyone reading this have a Vive and would like to try it, do let me know!

#speedrunning in #VR with #HTCVive? Anyone want to give the speedrun mode of @eyeofthetemple a go? https://t.co/6g2WSQ2jnT pic.twitter.com/MtVtMKdLC0
— Rune Skovbo Johansen (@runevision) October 26, 2017

Implemented a new type of dangerous rooms for the temple

The reviews for this feature are through the roof.

Watch out! Working on a new type of danger in @eyeofthetemple... #screenshotsaturday #gamedev #indiedev #VR #HTCVive pic.twitter.com/95uYeL3b86
— Rune Skovbo Johansen (@runevision) October 28, 2017

It's getting tight in here. @eyeofthetemple #screenshotsaturday #gamedev #indiedev #VR #HTCVive pic.twitter.com/Tvrd3OcWk2
— Rune Skovbo Johansen (@runevision) October 28, 2017

"What do you mean I have to get in there!?" New room in @eyeofthetemple #screenshotsaturday #gamedev #indiedev #VR #HTCVive pic.twitter.com/7lE2iqorVD
— Rune Skovbo Johansen (@runevision) October 28, 2017

Got serious working on the big level design overhaul

Still far from finished with this one.

I've been experimenting with using Unity Tilemaps as a digital replacement for pencil level design sketches. Some success so far, although I'm really missing rotation/flipping of selection and proper multi-selection. pic.twitter.com/jT2PZloAYE
— Rune Skovbo Johansen (@runevision) November 27, 2017

I'm using #unity3d tilemaps for level design planning of multi-story structures. Moving things around becomes a pain though; having to do it separately for each layer. Any better alternatives? pic.twitter.com/STSb8AarvB
— Rune Skovbo Johansen (@runevision) December 29, 2017

Worked on a texture tool "Bricker" to easily create bricks and carved shapes

I've been continuing refining my tool for generating textures+normals from simple color masks. Output quality is getting there... #gamedev pic.twitter.com/jWzCUdc6Oz
— Rune Skovbo Johansen (@runevision) December 11, 2017

Contracted a few pieces of concept art to get inspiration for improving the visual look of the game

I've had decent progress towards realizing the concept art vision for @eyeofthetemple. I'll put further work on that on hold for now and focus again on a level design overhaul. #gamedev #indiedev #screenshotsaturday #VR #HTCvive pic.twitter.com/csUc4C5o7p
— Rune Skovbo Johansen (@runevision) December 23, 2017

And finally, introduced this little birdy

Bird spotted by the temple. #gamedev #indiedev #VR #HTCVive #birds pic.twitter.com/x8W7IRm54g
— Rune Skovbo Johansen (@runevision) January 15, 2018

That's it for now. Hope you enjoyed this glimpse into the development, and see you soon. Back to working on the game for me!

Remember you can also follow the development as it happens following @EyeOfTheTemple or @runevision on twitter.

July update: Trials and triumphs of whips and levers

2017-08-03T00:26:00.005+02:00

Here's the latest updates on the development of my Vive VR game Eye of the Temple.

For the past several months I've been working on improving the whip I prototyped last year. In the last post, I showed how it could grab levers, but there were a lot of issues and the whip and lever didn't exactly look pretty. Now see what it looks like now:

This feels really good to use now. It didn't get to this point without a lot of issues on the way though.

The whip

A bit of background on how the whip is implemented in broad strokes. Using physics joints etc. quickly turned out infeasible when I did the prototype last fall. Instead, I’m keeping track of positions and velocities of “links” in arrays in my own scripts and doing very custom simulation with lots of tweaks and workarounds. One of the needed things to make it behave whip-like is that in the spring code that maintains distance between adjacent links, one link should affect the other slightly more than the other affects the first. This is to simulate the fact that the whip gets thinner towards the end, which is critical for whip-like behavior.

Collisions with level geometry works by doing sphere-casts, one per whip link per frame, which is around 30. The spherecasts are from the previous position of a segment to its new position, and if anything was hit, I move the new position to the intersection point, which should be in between the old and the original new position. That's the basics.

There's special logic that makes the stick of the levers "sticky" and "unsticky" at specific times, which aids the behavior, but the way the whip curls around the stick (or fails to curl, sometimes) is still driven by the regular simulation apart from that. For all other surfaces, there's no special logic. It uses the sphere-cast based collision avoidance I mentioned above.

I should say there's a glaring issue in my collision approach which isn't shown in the video, which is that collision fails against moving surfaces, such as the moving platforms. I'm not quite sure if I want to solve that, because it's going to add tons of complexity to the code, while probably also degrade performance significantly. I've chosen to ignore this for now, since there's no lack of other things that need to be done that are more critical.

The lever

The lever has caused me all kinds of problems. Doing a lever that works properly, particularly for VR, is apparently a complicated problem. I made a video about my woes here:

I found out that levers could be made to avoid sliding out of their joints given three criteria are met:

First, the collider of the lever handle must not overlap with any other colliders in the world. The tricky thing here is that it's not easy to see that overlapping colliders might affect the handle, since the handle is firmly locked in place. But they do affect it in very non-obvious ways. So I ensured the handle collider doesn't overlap with any other colliders.

Secondly, the rigidbody must have its position set to locked.

Thirdly, the center of mass of the rigidbody must be overwritten in script to be set to the pivot that the handle should rotate around.

Unfortunately, this leads to another problem. Sometimes the lever handle would get completely stuck, in which case no amount of forces would make it move one bit. After some experimentation, this seemed to happen if the handle is exerted to forces while the connected rigidbody (which is kinematic) simultaneously move. (Some levers in my game sometimes get moved around.) I worked around this by disabling the rigidbody position locking at strategic times and then reenabling it again. This seemed to fix the issue.

Polishing it up

After I had gotten most of the technical issues resolved, I set out to create proper 3d models for the whip and lever to replace the simple cylinder placeholders I had before.

And as the last step, I added the ability for the whip to be rolled up (which it now is by default). The whip is still fully simulated while rolled up, which is what gives the rolled up whip its nice juicy appearance. There's no animation or pre-canned movements involved in the whip at all.

The transition where the whip gets rolled up is done by pulling at specific segments of the whip towards a specific point on the handle. This happens to also be how the whip remains rolled up in general.

In the video I do a little upwards flick and then the whip rolls up. This is purely "role playing" though. The rolling up is actually triggered just by pressing a button on the controller. ;)

If you've been following the development of Eye of the Temple, does the whip related gameplay change how you view the game? What do you think it adds to it?

June update: Verticality, puzzles, whip

2017-06-13T19:36:00.001+02:00

Here's the latest updates on the development of my Vive VR game Eye of the Temple.

For the past month I've been mainly working on improving the whip I prototyped last year. It can now be used to grab levers at a distance, and then you can yank the whip backwards to activate the lever.

Testing whip and lever in Eye of the Temple. Still some way to go, but getting there. #gamedev #indiedev #vr #HTCvive pic.twitter.com/8TZHflQnM2
— Rune Skovbo Johansen (@runevision) May 20, 2017

There's still some way to go, especially with getting the audio cues right. The physics will never be quite like a real whip, but making it satisfying to use is the top priority.

Apart from this I've been looking into designing more puzzles for the game. I'm no expert puzzle designer, but bit by bit I come up with some that I think work well. The latest involve tall rotating towers, activated by levers (no whip use necessary for this one) where you need to step around on and in them at two different levels.

This also marks my increased effort in making better use of verticality in the level design. Experiencing the great heights is a draw of the game, and I'm figuring out how to use that optimally.

"Add more verticality" they said, and I agree! New puzzle elements in @eyeofthetemple #VR #HTCVive #madewithunity https://t.co/hvxgYxW0uR pic.twitter.com/tjDuCk2ufo
— Rune Skovbo Johansen (@runevision) June 13, 2017

I don't have a new build with these new things yet. The work right now is on smaller isolated pieces and puzzles, and once I have a set of those that fit nicely together, I'll begin integrating it all back into the overall world design.