Improving Lighting, Particle Effects, and Cavemen – Shempi
This week I’ve been continuing with my quest of visually improving B.C.E. Last time I mentioned the challenge of achieving good indoor and outdoor lighting. I’m happy to say that I’ve managed to get a good first version of the lighting in the cave. Since we’re using Global Illumination for the outdoor lighting, one of the challenges of building the cave lighting was ensuring that the cave wasn’t catching too much of the global illumination. Luckily for us, Post Process Volumes contain a very extensive set of lighting settings, one of which is GI Intensity. I lowered the GI intensity in the cave, turned up the temperature of the lighting, and decreased the eye adjustment settings. The result is a dark but navigable cave when the fire is unlit. When the fire is going, the cave is lit by the pulsing light of the flames. I have a quick tip regarding Post Process Volumes. When using Post Process Volumes to simulate indoor/outdoor lighting, it’s important that the point of transition is whenever the camera is transitioning from indoor to outdoor and vice versa. It’s trivial with a first person camera because the character and the camera will cross that point simultaneously. When using a 3rd person camera or, in our case, a panning “top-down” camera, the illusion is broken unless the lighting volumes are tightly fit for the camera’s full range of motion. Improving the “seamless-ness” of post process volumes helps suspension of disbelief.
Indoor (cave) lighting
I’ve also been improving the fire actors, most importantly the actual fire particle effects. The fire actors are still visually in their “proof of concept” stage, most noticeably in the logs on the fire. Another artifact of the proof of concept was a terribly optimized particle effect that would get increasingly large. In fact, it wasn’t one particle effect. The flames on the fire would appear to grow larger but in reality, each time the fire got bigger, more particle systems were being added. It worked as a proof of concept but in practice it was far too costly. Now there is a single particle effect for each state of the fire. The bigger flames are simply spawning more particles from one emitter rather than adding multiple emitters. As a result, I’m now able to have the particles emit light (before it would have been too costly given the terrible overhead of the many particle emitters) which completes the atmosphere of the cave, improving realism. As another optimization, I’ve decided to have the fraction of particles emitting light be inversely proportional to the intensity of the light. For example, on the biggest fire, there will still be roughly the same number of lights emitting as there were in the earlier states, but the intensity will be higher. Keeping the number of lights a low as possible is an important part of ensuring the lighting complexity doesn’t get out of hand.
I’ll close my section of the post with an update on the Caveman character model. The model is complete thanks to our talented friends Cameron McCarthy (character designer and concept artist) and Jordan Surkin (3D modeling/animating). The model has been passed on to me and I’ll be doing by best to rig it so that it’ll be ready to drop into Unreal.
HUD v1, Alert System, Bugfixes, and Spectator Mode – Kig
So this week I finally had all the assets to finish version one of the HUD. It’s not perfect yet but with the new font and 2D images it fits perfectly with the style of the game while improving readability. After that I went through all of our UI to update the font and make sure it was all functioning correctly. During this, I discovered we had a few issues with environmental deaths not showing up in the kill feed and it also bothered me that there was no respawn timer. While working on the respawn timer I ran into an issue where the client was unaware of its respawn time. This was because we had the event create a timer handler on server so the client was unaware of how much time was left on the handler. I changed it to run that timer on owning client and set it as reliable to get it to work. It is slightly disconcerting that I had to make it reliable for it to run at all because that might mean our network traffic is too high. I did some network profiling and, while our netcode isn’t perfect, there were no glaring problems with our traffic either. I’ll just have to keep monitoring it throughout development to make sure it doesn’t exceed our limits.
Network traffic seems ok. The number of actor channels is a little high though.
A few months ago I had a task to make a modular alert system that could be triggered by the game mode so that players could know when important events happened regardless of where they were on the map. This week Toffee implemented the triggers in the game mode and the map and they work pretty nicely. I ended up handling it much like our in-game chat system. The server broadcasts the alerts to all players based on what team triggered it and what team should receive it. Later I hope to add a lot of functionality to this feature like sound effects and animated pop ups on screen.
The last thing I worked on this week was re-implementing spectator mode. Before the ‘overhaul’ that we went through, spectator mode was a little buggy. It was just a generic actor that flew around the map and it could technically interfere with gameplay like blocking a spear throw. Now that our team system is more robust I went back and changed the pawn to a spectator pawn. You can now switch between view targets to watch the cavemen on the map. The HUD is also disabled for spectators and their chat is restricted so that they can only talk to other spectators. That way we don’t have people ghosting in spec. Improving the spectator mode is important to us, so we might have some fun updates to spectator mode on the way.
Action shot showing off most of the new HUD!
Starting today I’ve been looking into Unreal’s Sequencer tool so that I can get started with the gameplay trailer for Steam Greenlight. I’ve been watching lots of indie game trailers and I should start storyboarding the trailer with the rest of the team tomorrow. Lots more about that next week!
Inclement Weather – Toffee
Hi everyone, I’m going to be taking a break from the usual netcode posts to talk a bit about B.C.E.’s usage of weather during the Firefight game mode. Those that have been following may already know how the game mode works, but for those that don’t, I will go through it quickly.
Firefight mode consists of two teams of 6 cavemen fighting to obtain fire. The match starts with both team’s fires extinguishing just as a heavy snowstorm is coming. Lightning periodically strikes and sets trees ablaze, so each team must collect wood, obtain fire from a burning tree, then continuously light and fuel their fires as the storm approaches. When the storm hits, the winner is decided by who has a currently lit fire, and who has had a fire the longest.
In order to impose the effects of weather upon the players, light snow will be falling constantly all over the map, and blustering flakes and clouds will pour over the northern edge of the map, where the storm is brewing.
As the game progresses, the storm continues to brew along the northern edge, until about two minutes remain. When this time is reached, the blizzard slowly encroaches southwards, bringing heavier snowflakes and billowing clouds of snow. Eventually, the storm will encompass the entirety of the map, covering it in a massive blustering blizzard.
The goal here was to keep the player’s aware of the impending storm visually, but without impacting their visibility or performance very much. By keeping the storm particle system as minimal as possible, and having it only fully cover the map with about 30 seconds remaining, I believe we have achieved that. Visual indications of game state like these go a long way in improving player comprehension. This was just a quick look into a new feature added this week, but I will be returning the to networking posts soon. Thanks for reading, and I’ll see you next time.