8. Virtually Real Game Design

Hey everyone! It’s me again, your friendly neighbourhood game designer. While Jaakko is focusing on some other important business, I figured I’d continue my musings from where I left off last time: designing games for virtual reality. I ended my previous ramble by stating that game design in a virtual reality space is more focused on designing experiences and content rather than designing game systems for the player to figure out and conquer. This time I’ll try to expand that thought.


To begin with, let’s look at the terms I’m using. When I speak of designing game systems, I mean building up rules for the game’s internal interactions. The more abstract a game is, the more focus has to be paid to designing game systems This does not mean that the systems themselves need to be particularly complex, just that they need to be there. Basically, designing game systems usually means rejecting mundane reality and substituting it with something of your own: chess simulates war, but in lieu of how war actually works, we have a game system formed by the rules. This leads to an interesting interaction when you build a game with virtual reality as a platform. 

The whole point of VR is to provide an agreeable simulation of reality, so you don’t really need a robust focus on game system design. Which means that as a game designer I can focus on designing interactions, content and experiences instead of building the game’s internal reality and logic from ground up. Virtual reality as a platform means that the player is immersed into the game right from the start, and most likely interacts with it much as they would interact with things in actual reality. So instead of deciding how to create an experience, the game designer’s core job shifts almost entirely to what you want the player to experience.

When going through VRKiwi’s expansive Steam library of reference games, what struck me the most was how simple most of the games and the challenges they contain are. The interactions are easily comprehensible: “grab gun, pull trigger” or “pick up sword, hit orc”. For someone who spends their free time with RPGs (either tabletop or digital) this is both delightfully and confusingly simple. The puzzles are also super simple, relying on the tactility of the medium to provide the experience rather than some complexity in the interaction itself. 


This is all wonderfully different from the platforms and genres I’ve worked with before, but not entirely unfamiliar. For if I had to compare designing for a VR space to something I’d actually compare it to designing tabletop RPG content and running a game as a gamemaster. In that space content and experience are king and queen as well, and the rules of the game are there to support your narrative (for the most part anyhow). The difference with VR is the scale of preparation and detail however: in a tabletop RPG you can handwave in anything you need at a moment’s notice, whereas in VR everything in the game needs to be put there beforehand. 


And THAT is what you need a game designer for.





*Thanks AMP! We’ll be mostly offline during the holidays but the blog will continue in January.

Meanwhile, go participate in our contest: https://www.reddit.com/r/CaveDigger/comments/kfivke/cave_digger_2_community_design_contest

Merry xmas everyone! -Jaakko




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.