9. Life in the mines part I

We’re back! The holidays and a new year happened. Being in the past couldn’t happen to a more lousy, inconsequential, offensively awful year! Good riddance, as I’m sure you all agree. I’ll give you a short status update on what’s happened on the Digger front.


Most of the little time we had in 2020 we used for design, concepting and building the pipelines. For laymen, pipelines is a fancy word for doing certain things in a sequence to produce another, somewhat finished thing. I promise to do a separate post about the iteration of our level design pipeline, as it certainly deserves it.

But now we have a level design pipeline in place. This means that the grayboxed levels of our designer Ari-Matti can be realised as prefabs in Unity – to be randomized into a coherent, themed mining run for the player.

In other news, this week we’ll have the first proper iteration of our enemies and AI – the nefarious plasma shrimp. Don’t ask where it came from – if I had to guess it was born in the dark mind of Jussi. He was probably hungry for sushi or something. Our modeler Tiina promised to do a separate blog post about the evolution of the plasma shrimp model. Justus is doing the AI for the shrimp and the other enemies, seems to be a fun programming gig.


Also this week Jammu implemented a pooling system, which instead of always instantiating a game object (say a gold piece) acquires it from a pre-made pool. This saves a lot of performance. We used a Unity3D asset called Pure Pool Object Pooling for this. Seems like it was easy to integrate and works with Photon Unity Networking.



We’ve been doing weekly builds in the Oculus dashboard. It’s a nice conclusion for the week, getting people together to play test the new stuff in multiplayer. The benefit is that it keeps us all on the same page. Also usually it’s pretty hilarious witnessing all the exotic bugs first hand. Sometimes you get stuck inside a mexican bandit (a placeholder enemy), sometimes your hands are twisted 180 degrees by VRIK etc. I’m sure we’ll do one blog post about all the hilarious bugs found during development!


To sum it up, the situation is that we have the freeform mining basics in place, an avatar, pickaxe and a cabin model in place and the level generation working. Everything else is still pretty much a placeholder – for example we don’t have an elevator or a shaft to put it in and our Valley terrain is just generic western assets instead of the frozen Alaskan landscape. Sometimes it takes more imagination than I can muster to see how this all will come together. And sometimes I do see a glimpse of Cave Digger 2.


I will keep this one as a serial topic to give you an update from time to time. See you next week!

-Kharan (Jaakko Asikainen)

Random dev quote: “Käyn ostaan turskan Pekurista ja lätkäisen jos kirjoitat sille yli kolmen sanan lauseita.

Join Cave Digger Discord!


Submit a Comment

Your email address will not be published. Required fields are marked *

MeKiwi Oy

Njetwork Inn
Isokatu 56
90100 OULU

VRkiwi is a trademark owned by MeKiwi Oy

MeKiwi Oy

Njetwork Inn
Isokatu 56
90100 OULU

VRkiwi is a trademark owned by MeKiwi Oy

This week our guest writer is Justus, our code guru and shader wizard. Take it away Justus!

Why bother making cool shaders? Why don’t you just go crazy with post-processing like everyone else?

Because we can’t. With Cave Digger 2 our first target platform is Oculus Quest. Quest is a standalone mobile device, and as such, it uses a rendering type called Tiled Rendering, which is really efficient for most rendering, but causes full screen effects like post-processing to be really slow. These effects will add significant fill-rate overhead and should almost always be avoided. Find out more about how Quest does Tiled Rendering here.

So in order to make fancy looking effects like custom fog, color grading or bloom, while maintaining stable 72 fps on Oculus Quest, we have to make the effects with shaders and particle effects.

But shaders are hard to make 🙁


It’s true that writing shaders can be annoying even if you’re an experience programmer. Cg/HLSL syntax is different from most programming languages. However there is a easier way. The trick is to use a node based editor like Amplify Shader or Shader Graph. You can find plenty of helpful guides and tutorials online. Also Amplify Shader has lots of good example shaders for you to learn from. This allows you to make shaders much faster, however the catch is that the shaders might not be as optimized as they would be if programmed by an experienced graphics programmer

Amplify Shader view of CD2 Gem shader. Cel Shaded lighting and Custom Fog are is done in a custom functions, which makes them more easy to reuse.

So what does it do?

*Slaps the roof of Cave Digger 2 Lit shader*

This bad boy has a custom fog that uses a cubemap for color. It uses a cell shaded lighting that’s similar to Breath of the Wild. It can do triplanar texturing and stochastic texturing.

Also we have a custom Gem Shader for making those loots look shiny and tasty.


How to make it work

To handle controlling the shader settings I created a scriptable object called Atmosphere and also created Atmosphere Manager to manage them

A scriptable object helps to quickly make different atmospheres for different areas. It currently controls the ambient lighting color and fog density.