It's that time again!
Week 8 has finished and I admit I'm a little behind according to my planned schedule, although some of the work I have done will hopefully save me time in other areas in the future.
The biggest time sink of all: performance issues!
So when I decided to add a load of physics-enabled rigid body furniture to my rooms, the game crawled to an absolute halt during the first few seconds of loading as all the objects settled down. Once they were sleeping, the framerate went back up again. In the end I knocked together a really quick system to disable collisions, rigid bodies, particles, lights and shadow calculations on all objects outside of the the player's view. Unity's camera does automatically cull rendering outside of the viewing area, but clearly this was not enough as there is a lot more stuff going on in the background too! To solve this, I've added a huge sphere collider around the player character, that collides with triggers around the dungeon and the different objects get enabled/disabled accordingly. Seems to work pretty well, and we're back up to a consistent 60fps most of the time.
Getting decent performance has always been a tricky thing with TinyKeep. Because we're procedurally generating our dungeon levels, a lot of the usual optimisation tricks were unavailable to us. And we're not talking about putting together jigsaw-like chunks of the level either, TinyKeep is procedural right down to the last floor tile and wall segment. Things like lightmapping, occlusion culling, static batching etc... can't be used because these must be baked in at development time. That means all our lights must be rendered in real time! So as you can imagine in a dungeon, with hundreds of torches, it's going to be an issue.
Our strategy to get around some of these issues is to compromise on the following:
1. Topdown camera. Even though we allow a bit of zooming in and out, it reduces the amount of the things to be rendered on screen. In fact this negates the need for occlusion culling entirely!
2. Deferred rendering path, this allows us to have many many lights on our scene as long as they are small. Thankfully, our torches don't light up a large area so this is perfect for us. Unfortunately, this technique breaks down for larger lights (such as a room lit by a chandelier, or fire pit), so we have to make sure that for rooms such as these we only use the one large light, and not include torches there. Once a light's range starts overlapping others, you'll get issues. The good thing about deferred rendering is the added benefit of real-time shadows from point lights, but again these are restricted to the larger lights only as calculating shadow maps is pretty expensive!
3. As mentioned above, disable physics, collisions, particles and lights outside of a certain distance away from the player. Of course this means interactions between monsters and objects can't happen outside of the player's view, but it's a compromise we have to make.
So far so good, but we'll probably have to revisit this once we add monsters and our AI code kicks in! Anyway enough talk about performance, here's some screenshots of some new features this week:
Week 8 screenshots
We now have dungeon entrances:
And exits!
Lighting schemes
I've also been working on different lighting schemes for the variety of environments I have planned for the game (prison, fiery hell, organic forest area, pitch black caverns). Of course these environments will all be using different models and textures, but just changing the lighting makes a huge difference to the feel of it all. None of the following are photoshopped, they are a simply slight tweaks to the ambient light color.
For the prison area, we're using neutral ambient lighting. Wood looks like wood. The stone walls and floors are cold and grey, the only respite coming from the warm glow of the fire pit.
Our cavern levels will be pretty dark, so the only way to navigate through these is with a torch, or by following luminous crystals and glow in the dark creatures. So for this environment, we use no ambient lighting at all (black).
Our fiery hell levels will be constantly lit by the red glow of flowing lava. The air is hot and dry, walls are scalding to the touch, and there is lava, fire and smoke everywhere. I wanted it to feel like we were inside a volcano, so the ambient light here is a highly saturated red.
Reference image (volcano): here
Finally our organic forest level will have vines, ivy, moss and other fauna, underground trees and waterfalls tearing apart the dungeon walls as nature reclaims its territory. I wanted to go for a Zelda-esque feel with floating spores, falling leaves and lots of sun shafts/god rays coming through the tree canopy. The ambient light has a green tinge to it, as the sun light filters through the green leaves.
Reference images (forest): here and here
Of course you need to use your imagination as to what the actual environment models and textures will look like, but for this exercise I was just focusing purely on the lighting.
Torture chamber
I had some extra time this week to add my first furnished room, a torture chamber complete with hanging gibbet cages, dead skeletons....
X-shaped stocks inspired by Theon Greyjoy's experience with the Boltons...
Of course all physics enabled, so if you push hard enough... (Whoops!)
What a week!
Dat lighting :)Looks good!