Shadows of Doubt is a detective stealth game set in a fully-simulated sci-fi metropolis! There’s been a murder and it’s up to you to solve it by any means necessary, with the condition that you keep a low profile. A unique mix of procedural generation and hand-crafted design enables every room of every building to be explored. Be sure to wishlist on Steam, join our Discord or read previous dev blog entries here!

EGX Rezzed digital is happening right now (26th-28th!) If you’re a member of the press and want to get your hands on what was going to be shown at Rezzed, please get in touch!

From the confines of coronavirus lockdown, I bring you a brand new and over-due Shadows of Doubt development diary!

There have been points over the last 2.5 years in this project where I’ve felt like giving up; it’s such a large ambitious project that at times it has felt like I had bitten off more than I can chew. I’ll likely write about the challenges in more detail with another post, but for this one, I wanted to share with you perhaps the biggest saviour in terms of production viability: Voxels.

Back in the pre-art asset days of this project, when it was still a management game, I often wondered about what direction the art style would take. Realism was off the table due to workload, but I really wanted to explore a pixel art approach. As the game shifted to 3D, and then entirely to first-person, voxels started looking like the way to go.

This turned out to be perhaps the biggest decision in actually making this ambitious project actually somewhat do-able with a small team and small budget: The reason being that the turnaround of most art assets is minuscule in comparison to anything else.

It’s arguable that the voxels are a little bit of a mismatch in terms of what people expect. They’re associated with Minecraft and a general cartoonishness, which doesn’t fit the tone of this project at all. On the other hand, they do effectively evoke a low-fidelity style, something which has recently taken off in some really, really cool projects that I adore. I think in an ideal world I would choose a low-fi, low ploy art direction over the voxels as it’s more effective at conveying the atmosphere that I want. But crucially I also believe this would have resulted in increased turnaround time in regards to art assets. I’m happy with the trade-off.

When used in conjunction with the unity high definition pipeline it really pops. There’s something about the use of voxels and modern render technology that makes something look really cool. I’m not sure how else to describe it, because logically the two should be at odds with each other? Maybe it evokes the way we remember old games of our past; always looking better than they actually did. As if they were brought to life, but not replacing that low definition that allowed us to fill the gaps with our imagination.

Voxels, then. After a bit of research, it became clear that the main contender of voxel software is MagicaVoxel, an extremely awesome bit of free software that pretty much all voxel artists use. Great, that’s an easy decision then? Well no. Although it does a whole bunch of stuff really well unless they’ve changed it since I last looked at it, it doesn’t do two very important things that I figured I needed early on in this project:

• Be able to convert, or ‘voxelize’ traditional 3D meshes into voxels. This is important as I decided quite early on, to make this manageable I wanted to re-use some of the 3D building models I made for Concrete Jungle for this project.

• Be able to output voxel meshes with traditional UV maps instead of an atlas. This was important as I wanted to make normal maps for my models, and not just have them all as a flat texture. This was important in order to move away from the cartoon flat visuals and towards the low-fi look.

Then office co-worker Nick Gunn, who works on Industries of Titan (which uses voxels to crazy-awesome effect) recommended looking at Qubicle. It can do both of these things and also has the added bonus of being quite good at optimizing meshes for use in Unity: Something which magicaVoxel at the time also lacked.

There was a short learning phase; at first, Qubicle being limited to isometric view really bugged me, but I soon got used to it. I also began to establish my workflow. What was the best way to go from nothing to a final in-game model? My original vision involved using a pixel-art setup in Photoshop to manually edit the outputted Qubicle texture maps. I would use a really cool colour indexing technique to make everything look more like pixel art than anything else. It kind of worked in practice, but it soon became clear that to produce effective art assets quickly, I really needed to be able to paint directly onto the model. Photoshop does have this capability, but frustratingly there is no option for using point filtering, so my pixel art was lost to a horrible soup of texture when projected onto the model in Photoshop.

I explored some other options, but frustratingly I couldn’t find anything that allowed me to UV paint and that didn’t force the texture to be blurred. In the end, out of ease more than anything else, I decided to import my pixel art colour palettes into Qubicle and just use that to make the texture maps too.

Actually, after a brief adjustment period, I grew to really like it. It’s pretty simplistic — nothing fancy. But it has the essentials, plus it’s quick and easy to add noise, which is nice as it again makes it easy to avoid the flat surfaces that look cartoon-like. It was probably the tool I was looking for all along for both modelling and texturing. As I grew more used to using it, prop creation time reduced dramatically, and now most basic props can be created from scratch in under an hour, and for smaller things about half that.

Unfortunately, Qubicle doesn’t let you output the texture map alone, so my workaround for creating multiple maps involves exporting my original model with a colour map texture, then duplicating it in Qubicle and turning it to greyscale and creating a heightmap with it. Then, I export this as a separate model (and along with it it’s UV texture). I sometimes do this a third time to create a smoothness or metallic map too. Then it’s a case of putting all these textures together into a unity material (unity can automatically create a normal map from a height map) and we’re done!

The final bit of magic sauce I use is a special custom shader than can colour things without needing a whole new texture. I’ve talked about it in the past here, but what it does is allow another texture map to define unique colours to apply to the model. So for example, I can take a model of a bed and apply a special texture map to it that keys out the pillows in red and duvet in green, with the rest black. The shader will colour black areas with the base texture map, which will be the same for all bed model instances. The red and green keyed areas, however, will draw colours from my pre-defined colour pallettes which consist of 5 colours and are generated for each individual room. This is how the game can generate interiors with colours that are complementary to each other. With enough assets and this technique, I hope that we’re able to move away from the cookie-cutter effect you see in many procedurally generated games.

At the moment you’ve probably seen the same few props hanging around in my screenshots, but over the course of development during the next year or so you should see this greatly expand. Not least because we’re planning on adding a 3D artist to the team this year.

Anyway, that’s my 3D asset workflow, I hope some out there found it useful and/or interesting. I’m really excited to see the game environments grow into more unique and interesting. Don’t forget to wishlist on Steam, and join our Discord if you’re interested in the project— it really helps!