About Toffee

Currently playing mostly Overwatch, I tend to stick heavily to the RPG, MMO, and FPS genres.

Incoming Changes to the Combat of B.C.E.

Hey folks, Toffee here. Over the last few weeks we’ve taken a deeper look into B.C.E.’s combat, thanks to the rapid testing capability of the Burnout game mode, and have come to the consensus that some changes need to be made. Today, I’ll be going over these changes, how we came to the choices we made, and how they will effect B.C.E. going forward.

As those who have been following our development are likely aware, the combat of B.C.E. is broken into three weapon types: Clubs, Spears, and Unarmed. Each weapon type has a primary and secondary attack option, and up until this point, all primaries had been melee, and all secondaries had been ranged. While this made sense on paper for the sake of uniformity and reducing learning curve complexity, in practice, it did not turn out the way we intended. In an effort to make each weapon type feel unique and effective, we have updated combat as follows.

The Club:

Primary: The club primary attack will not be receiving any changes. The weapon slows movement speed significantly, and we feel this counterbalances the 1-hit kill potential of the weapon in melee range.

Secondary: The club secondary attack, however, will be receiving a major overhaul. Instead of being an aim-and-throw attack like the spear, the club’s secondary is now what we call a Quick Block. When performed, a Quick Block will place the club in a blocking position in front of the wielder, blocking attacks from the front. When an attack is blocked, the attacker will be momentarily dazed and the quick block will be canceled, giving the blocker a brief window for rebuttal. However, as damage can still be taken from behind or from the side, committing to a block can leave you exposed.

Quick Block also introduces a new mechanic: projectile reflection. Rock Throw, the secondary attack of the Unarmed weapon type, will briefly daze an enemy it hits, slowing their movement and preventing them from picking up weapons or performing attacks. But should the rock strike an enemy who is Quick Blocking, that rock will be reflected back, becoming a hostile projectile, and has the potential to daze or even kill the original thrower or his teammates.

The Spear:

Primary: The spear primary will also be receiving a rework. In it’s current form, the attack is a simple forward Jab, but we felt as though it does not offer anything of unique value to combat. Since the secondary attack, the Spear Throw, is a much stronger option (being a 1 hit kill), this primary attack is lackluster, and was rarely used during playtesting. To bring the spear into a more balanced and unique state, we have replaced Jab with ShoveShove, when performed, will knock any enemies within melee range back a short distance. This is not a daze, but rather a spacing utility that puts some distance between the user and any would-be melee attacker. We feel that Shove works better in conjunction with the spears secondary attack, allowing players to better line up their throws and earn those impressive kills.

Secondary: The spear secondary attack will not be receiving any changes. We feel the skill required to land a long-range throw is counterbalanced by the weapon’s 1 hit-kill potential.

General Changes:

With these attack changes comes the concern of skill spamming and exploitation of these systems. Therefore, we will be applying the Stamina mechanic that already exists on Rock Throw to both Shove and Quick Block. The bar above each player’s head that denotes when a rock can be thrown again will now apply to the usage of these new skills as well. Exact cooldown times for each skill are still in flux, but suffice to say we’d like to keep them as short as possible.

While the changing of these attacks disrupts the level of standardization we had initially, we believe these modifications will improve the diversity of weaponry and add a bit more flavor to each type. Through upcoming playtests, we will iterate upon these changes and continue to polish and improve Burnout as a game mode, and B.C.E. as a whole.

Thanks for reading!

Improving B.C.E – Dev Update 4

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.

Improving Indoor lighting

Indoor (cave) lighting

Improving lighting

Outdoor 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. Then number of actor channels is a little high though.

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!

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.

NorthernStorm

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.

HeavyStorm

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.