21. Need for cheat
At every game development there comes a point where some kind of development or cheat menu is needed. Cheats and/or development tools makes testing a lot easier and makes the bug reporting process a lot easier, which usually takes a huge chunk of development time.
Since our game’s style is super dynamic, and a ton of objects are instantiated in runtime, spawning tools/loots/enemies/other is necessary. Thankfully we have already refactored our core spawning scripts, so implementing an object spawning was an easy task.
The Options panel is pretty basic for now. It includes basic options like godmode (no damage is taken), noclip (go through walls) and flying. These are essential, so that we can start to polish all of our rooms and really inspect all the levels thoroughly.
One of the biggest things we wanted to implement was JIRA integration. When developing a virtual reality game, making bug tickets is really cumbersome, and because of that, pretty much nobody had the energy to make bug tickets.
Thankfully Unity Asset store is again here to help with “EasyJira” asset. Unfortunately asset was a bit buggy with our version of Unity, but we managed to get it work with slight modifications. Players can assign a title, description and priority to the ticket that will be made in VR. We added a dropdown menu to specify if the problem is General, or in the Room. This adds some additional data automatically to the ticket, so it will be easy to assign to a developer. “Room” specification adds a room name in the front of the ticket and “General” adds build number and the platform.
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.