7. Mr Blue Sky
Sun is shinin’ in the sky
There ain’t a deadline in sight
There’s no specs yet, everything is in the play
And don’t you know
It’s a beautiful new game, hey hey
Disney Imagineers use the ‘Blue Sky stage’ to describe the phase of pre-production where no hard specifications are set for the project yet. For Cave Digger 2, this stage began already in January of 2020. Many of you might be too young to remember, but it was a time when nobody used a mask or washed their hands. This was a time of casual day drinking, free love and totally unrealistic expectations for the future.
At the time, Cave Digger 2 was broadly drawn out to be more of the same, just bigger, better and harder. We had everything on the table: MMO, crafting, trading, weapons, story campaign and spaceships. That cannot continue of course, nor should it, but it is a wonderful time for the artist, when you can just paint anything you like. You don’t have to care about technical limitations or that pesky budget yet.
Mr. Blue, you did it right
But soon comes Mr. Night creepin’ over
Now his hand is on your shoulder
Never mind I’ll remember you this
I’ll remember you this way
In September began the dark times, and I don’t mean just second wave of corona, but these:
I have a feeling, very few artists actually enjoy planning and writing specifications, but in the process of making any art, there are always stages that are boring, yet essential for the end result. For me those are spreadsheets and inking.
The current version of the Art Bible is running at some 50 pages. The word ‘Bible’ might be misleading though, as it’s not meant to be a never-changing tablet of rules, but a living journal. One mistake I wanted to avoid here, was setting any parameters for the visual style before seeing any assets in the actual engine. Tight limitations quickly take the fun away from individual artists.
Instead, the pre-production stage was less about writing specs and more about gathering inspiration. For this we had a couple of collaborative moodboards in use. We used, and still use a tool called Miro, which also has many other great features for remote collaboration by the way. This free playground of ideas gave all team members a sense of agency, and I believe letting everyone speak their mind gives to the project more than it takes.
It was only at the end of pre-production that I wrote the first revision of the Art Bible, when we were all on the same page what it’s supposed to look like. Many sections are still open, but it’s generally good to come up with headings at least, just so you don’t forget about anything.
Now we’re well into actual production, and the question I’m trying to answer is, how to keep Mr. Blue Sky along with us. How to keep up the same motivation and inspiration during the actual, hard work?
Return to the Blue Sky
When starting a new environment or individual asset, start by mass producing a lot of really crude sketches first. Don’t give any thought towards the viability or visual hierarchy yet, just draw. This gives you the joy of creating and lets you get some of the more obvious ideas out of your system.
I prefer to start with silhouette thumbnails. None of these actually made it to the game but many of their small details did in some way. Can anyone guess, what it is that thingamajig does? Leave a comment if you do!
These are some of the ores Jussi Pylkäs drew early on.
And these are his more developed sketches.
In this video Trent Kaniuga talks about the early days of concept art at Blizzard. He says, going through that phase where things didn’t need to make sense, was important to him (from 8:00), but continues, that having constraints of functionality is not a limitation to creativity, but a solution; the story gives you answers to what things need to look like. I know he talks about career development, but I still think going through that phase during the process every now and then is beneficial.
Don’t optimize too early
Related to the previous point, this mostly applies to concept art too. Don’t give in to the need of optimizing the asset in the initial sketches. We have only few hard rules due to the Oculus Quest hardware, like no real mirrors and no overlapping transparent surfaces. It’s generally better to give your imagination a free reign in the concept art and let the modelers and developers figure out the best solution to optimize the asset. Of course, that’s sometimes my job too, if I see some obvious issues.
Trust the people in your pipeline.
– Albert Einstein
This was a mistake of mine. In our early planning stage, I got stuck on allocating which modeler makes which groups of assets. We have two modelers, and I was trying to split them into departments based on their earlier work I’ve seen. That would’ve needlessly limited their professional growth and motivation to, not only learn, but produce assets they’re proud of. So, with a project of this scale, the better approach is to give a buffet of todo-tickets and let the people make their pick based on their own interest and skill set. We’re not Rocksteady, using two years coding cape physics, and that’s good news for people wanting to try new things.
Play the game
We maintain a habit of mandatory playtesting every week. Just so that people would remember the play the game. The benefit of having lightweight standalone headsets is that every dev team member is able to play our game at any moment (when the controller batteries are not empty).
This is of course a healthy habit for development purposes; you notice any issues with the artworks’ readability and fidelity in-engine. But the other reason, answering my earlier question, is the sense of accomplishment you get when you get to see your mark in the playable game. Also, it’s just fun messing around with the buggy piece of s… lovely piece of software.
-Juho Paaso-Rantala, Art Director
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.