About kig

I play mostly FPS and strategy games on PC, my favorite being Team Fortress 2. I've also worked in the industry at a mobile game studio using Unity. I'm currently playing Total War: Warhammer and Overwatch!

Gameplay Update Video

New Gameplay Footage!

Over the last few weeks you’ve seen some posts from the team explaining some changes to the game. We’ve been hard at work balancing the gameplay and revamping the visuals. We’re still a long way away from the finish line but the game has had a major face lift since the last time we recorded any gameplay. We’re not done with this week’s sprint but we had a playtest this afternoon and wanted to share some raw footage for those of you who want to see more from Burnout.

In this build you’re seeing new fires, new particle effects, animations, visual effects, and lots of new gameplay changes. We’re continuing to make small changes to the combat every time we playtest and we’re getting close to a stable beta release. When that happens everyone will be able to join in on the fun and help make B.C.E. the best it can be!

 

Burnout Coming Online

Finally Online

For the last two weeks I’ve been in the process of porting the existing Burnout framework to one that works online and locally at the same time. It’s a long process because when we first designed Burnout most of our code was for local play only. I’ve had to go back and make some serious changes to the way the GameState, GameMode, and HUD widgets work.

I wanted to redesign our architecture to make Burnout and Firefight game modes a child of a base game mode and then do the same thing for the HUD and GameState. This will allow us to change the individual game modes faster and also bring some features that Firefight has over to Burnout. In Unreal online clients cannot access information from the Game Mode classes. To get the player access to the current match state, score, and other HUD relevant info I had to move all of that critical information in to the Game State class so that players could access it. While the game mode is still responsible for keeping track of the score and changing the match state, it uses the Game State as a middleman for this information so that players can have access to those attributes.

burnout online

Plans for the future

By the end of this week it will be a lot easier to add features to the two main game modes. These changes will probably lead to me making some HUD updates like adding animations and improving the look and feel as we approach the Mass DiGi Game Challenge date. Later down the line we’ll be rapidly testing and iterating on Burnout and redesigning the core mechanics in Firefight.

Burnout now supports online play, voice and text chat, kill feeds, map voting, advanced alerts, and some other QoL changes related to spawning. By the end of next week the plan is to package these changes and then after some testing we’ll roll out our first Steam depot for beta testing. This is a huge milestone because finally players who are invited will be able to download the beta on Steam and join a play test for Burnout.

Greenlight Debut!

The B.C.E. Greenlight page is officially up for voting!

It has been a long 6 weeks since we redesigned the blog and started work towards this milestone. But this trailer and release is just the beginning of another year of hard work from the Blue Drop Games crew. We’ve put some time into setting up new media platforms on Facebook and Steam, so as always, check those out if you want to follow the process.

All that’s left to say is enjoy the new trailer!

Greenlight Grind – Dev Update 5

Greenlight Crunch Time – Kig

This week we don’t have tons to show because we’ve been working hard to get new art assets in the game, a new caveman model, UI and map polish, new textures, lots of bug fixes, and of course the gameplay trailer. We’re grinding to get the game ready for its media debut so we don’t have the time this week to make our usual in-depth posts from each member. Currently I’m working on building out our marketing plan for the next few months which includes a tutorial that I’ll publish to coincide with the Greenlight release.

I started this week with a deep pass on our QA checklist making sure all of our features were working. Toffee and I squashed some bugs related to the slippery ice, lightning strikes, and scoring. I’ve begun work on adding clutter and static meshes to the map so that it will look better. The changes are purely cosmetic and will help give the game a more complete look for the gameplay trailer.

Sequencer – Toffee

Hi everyone, this week’s update will be short, and will go over the use of Unreal 4’s Sequence tool. This tool recently released in a beta version in 4.12.3, and is more advanced than the previous matinee tool, used for recording gameplay clips in-editor and creating cinematic scenes. It has proved to be extraordinarily useful and simple to learn, and we have decided to use it, in conjunction with some playtest gameplay recordings, to construct our B.C.E. Greenlight trailer. Here is a test recording made in sequencer that showcases a fly-through of our current map in the firefight mode of B.C.E.

Caveman sneak peek – Shempi

greenlight

Polish Pass – Dev Update 3

Lighting Polish – Shempi

This week I’ve been working a lot with lighting in Unreal. Good lighting can add significant polish to any game. Lighting is a challenge because every use case requires a different lighting setup. One thing I’ve noticed is that many users find nice lighting through fakery of sorts, by using many lights of varying intensity. As a lighting beginner in Unreal, I’ve decided to start by putting the lights in that make sense, then tweaking from there. After much tweaking, the tentative lighting setup consists of 1 Skylight, 1 Directional Light, and 1 Exponential Height Fog. The skylight is a stationary light, which is the middle ground between static and movable lights. Stationary lights are not as costly as moveable lights while allowing baked lighting and dynamic shadows. Since a directional light would be necessary for believable lighting, I decided that the skylight will be used for the general “filler” lighting and therefore would not need to be movable. The Directional Light is what gives the scene shadows and depth. By making the directional light movable, and setting a variable in the engine config file (for some reason it’s disabled by default), we allow for Global Illumination through UE4’s Light Propagation Volumes. More on Global Illumination later. Finally, to soften up the scene we have Exponential Height Fog (EHF). EHF is most easily compared to plain old fog, but it’s useful for more than simply making a foggy scene. In UE4, EHF is customizable by density, starting distance (from the camera), opacity, falloff, color, and much more. Even the slightest use of EHF gives a scene depth, so it is normally recommended to use it. Don’t be deterred by the word “fog” though, because probably the most common use is producing an aerial perspective effect in scenes that have no fog at all. For both lights and the EHF, I use a very light blue color in order to lower the temperature of the scene for more believable lighting in a snowy environment.

Quick note on Global Illumination. Global Illumination is one of the most realistic lighting schemes in which each object being lit by a light source projects it’s own light onto the rest of the scene. Global Illumination allows for even a single light to produce a much more rich scene with realistic lighting and color bleeding. For example, if light were shining on a red box sitting near a white box, the white box would catch red light emitting from the red box. These details may seem small but they end up making a big difference in the lighting of a scene. Global Illumination helps realistically light BCE largely because of the snow that covers the battlefield. The snow, which is largely white, helps light the rest of the scene through the indirect lighting of global illumination. This gives our scene a richer, more vibrant look.

A big challenge for us is to have believable outdoor lighting, while also being able to have a nice transition to the darker indoor lighting of the cave. I’m currently experimenting with different methods to produce a dark, firelit cave that is largely unaffected by the outdoor lighting. While perusing the internet I found a method using reflection captures and the console command “r.DiffuseFromCaptures 1.” The basic workflow for this method is as follows:

1. Place reflection captures in the area that should be dark (house with windows, cave, etc)
2. Turn off the light source (this will only work for static or stationary lights)
3. Enter “r.DiffuseFromCaptures 1” into the console (this step might not be strictly necessary…still experimenting)
4. Update Captures on your reflection captures
5. Turn the light back on (don’t recapture!)

This method essentially preserves “out-of-date” lighting within the reflection capture volumes. This little trick is sort of a hack, so I’m hesitant to use it. One thing I have yet to determine is whether or not this method requires the ONLY reflection captures in your scene to be the ones that are used to fake darken a room. The reason this might be the case is because, as far as I know, you can’t individually update reflection captures. It’s all or none. I will continue to research that but if that’s true, then we wouldn’t be able to use this method because there are reflection captures all over our scene. Either way, my attempts at using this method have failed so far, so I must either be doing something wrong or this hack has been made obsolete by a new version of Unreal. The other method that I found involved decreasing global illumination through a post process volume. I suspect that a combination of both methods will produce the best result.

OldLighting

Old lighting

Reaching polish on lighting

Current WIP lighting

Lighting is still very much a work in progress, but it’s getting more and more polish with each iteration.

New HUD, Grass, and Fading Scenery – Kig

The last two weeks I’ve been hopping around a number of polish tasks but today it’s all coming together and things are starting to look good. After creating a behemoth of a landscape material I mentioned in my last post, I started looking into some grass materials on the Unreal Marketplace. The one I settled on looks pretty nice and it allowed me to edit the materials to add some snow effects, wind, and play around with the spawning of each individual type of grass and flower. Right now the grass doesn’t react to player movement and does not have any collisions so it looks static when they player moves through it. This is something I’d like to change when walking through a patch of grass but that will be a lot of work which I’ll have to focus on another time.

The grass is not optimized yet so it has an impact on the FPS. I'll be fixing that next week.

The grass is not optimized yet so it has a slight impact on the FPS. I’ll be fixing that next week too.

Another big change to the game is the new and improved HUD. Up until this point the HUD has been a mess of mismatching art styles and odd placements. This update moves all the relevant HUD information to the top of the screen and accomplishes two things. It makes the information more readable to the player and the bar at the top slightly mitigates the problem of having an extended line of sight as a result of our 60 degree camera angle. The style of the new HUD is meant to resemble cave paintings so the colors and geometry will be simple and it will match the style that all of the upcoming UI elements will incorporate.

Still on the way: Animated fires, new font, and cleaner spacing.

Still on the way: Animated fires, new font, and cleaner spacing.

The last thing I just got finished this week was fading scenery which was a really crucial feature. Once this is implemented, we’ll be able to bring in our cave asset which will add lots of polish. I started work on fading scenery about a month ago when I created a fade component. Unreal allows you to create new component actor classes so I wrote a simple fade actor in C++ that I could attach to any static mesh which would allow it to become translucent when the player was in front of it. This worked for a single player but caused issues on the network because the texture would fade for everyone on the server. After struggling with it for a few days I left it alone and finally picked the ticket back up this week. I scrapped the C++ component actor I had written and instead made a new blueprint for a parent fading object. This parent object does almost everything the fade component did but it does it at the replicated actor level instead of the static mesh actor level. This is an important distinction because when Unreal generates the map for the server and clients, static mesh actors only exist on the server. A replicated actor exists once on the server, and once for each client. This allows me to edit the translucency of a static mesh but only for the person who needs to see that change. This does mean however that the Game Mode must spawn the caves at runtime so that they are replicated to clients. The solution I came up with ended up being pretty elegant and easy so I think I’ll make a tutorial for it in the coming weeks. When I was working on this I spent a lot of time looking for tutorials and found nothing about networked fading scenery so it should save some people from the struggle I went through to get it working!

Now only one person will see faded scenery.

Now only one person will see faded scenery.

That’s all from me for this week. Next week I’ll be continuing to polish the HUD and map and doing a pretty deep QA pass on the game for the upcoming trailer.

BCE Netcode 2: Replicated Variables and Combat State – Toffee

Hi everyone, this is the second post in a series regarding BCE’s netcode, and how we handled network replication within the Unreal 4 Engine. Previously, I discussed on a basic level how the Unreal 4 Engine handles network replication. This time, I’m going to delve into a bit of our own netcode, beginning with the Caveman and the Weapons.

For those who haven’t seen or played the game yet, the core combat revolves around cavemen picking up and choosing their own weapons. Weapons have a melee and ranged attack, and their damage and effects depend on the weapon. For example, hitting someone with a club melee deals flat damage, but throwing the club stuns the recipient. In order for combat functionality to flow effectively, it was imperative that we categorize each potential state the caveman can be in. His holding stance, animations, and movement are dependent on the weapon held, and must be updated accordingly. We’ve deemed this state as the “Combat State.”

Combat State

Above is the logic flow of our Combat State switching. If you’ve seen the previous post, this might look familiar, as it’s an extended snippet of the same code. The caveman picks up a weapon, triggering this state switch: if they are not the server, they request the server to run the following functions on their behalf. Any changed information that other players need to be aware of is stored as a replicated variable.

When a variable is replicated, all currently connected players are aware of that variable’s value. This is useful for keeping track of things like player health, or in our case, Combat State. It’s crucial that all connected players are aware of each other’s states when in combat. The key to properly utilizing replicated variables is understanding that only the server can broadcast a change to that variable. Like the example above, this means that if the client were to update his Combat State variable locally from Unarmed to Club, his version of the variable would be updated, but no one else’s would. But should he request it be updated by the server, all connected players will see that his Combat State variable has been set to Club. Ensuring that the server handles the updating of these variables keeps everyone synchronized.

What occurs following the Switch has Authority node is as follows: set the calling caveman’s speed appropriately (cavemen move slower when holding a weapon or a bundle of weapons), destroy the rock in the caveman’s hand unless he is switching to unarmed, then perform a weapon-specific attachment. The implementations of these functions is irrelevant at the moment, but what’s important is that all of this is run on the server, allowing all connected players to see what happens to both the calling caveman and his weapon.

That about wraps it up for this post. Going forward I’ll be going into more detail on other areas of UE4 netcode and BCE’s usage in particular, as well as some insight into what worked and what didn’t during our development process. Thanks for reading, and I’ll see you next time. 

Fresh Start – Dev Update 1

Fresh Start

For those of you familiar with the old site you might have noticed things have changed. Our old site had some memory leaks and issues with hosting so we’ve migrated and we have a fresh start focusing on building the press platform for our game. This is still the place to find development updates but we’ve also added a press page for media outlets and potential customers to learn more about the game in a concise manner. The press page will also be how we distribute beta access to the game as we move forward.

The press page is still under construction and I’m in the process of importing posts from the legacy website to a separate page on this new site so that they aren’t lost forever. Expect frequent and detailed updates posted here every Thursday.

Development Update

The team is currently pushing towards the next milestone which is our Steam Greenlight debut. With that comes a lot of visual improvements to the game, a new map specifically designed for our game mode, much more visual and audio feedback, voice over work, new animations and models, and a host of networking and performance improvements.

Until now, the game had the working title of “Project Ice.” From this point forward the title is “BCE”.

Better Code

This week we’re working on fixing a lot of old netcode and re-doing the character class. The netcode has been unstable up until this point because when we started building the core systems of the game we didn’t have a very deep understanding of replication in Unreal 4. The same goes for the character and projectile movement classes. The last week has been spent diving back into old code, making it more functional and robust.

fresh start on caveman

Say goodbye to the red and blue UE4 models!

In the past we had a blueprint for two different character classes, one for each team. This was a bad practice because it added complexity, made our code difficult to follow, and made it difficult to move forward with planned features like cosmetics. We re-parented the caveman class with a newly design C++ parent class which contains an ENum that determines what team the caveman is on. The ENum initializes based on the player state when the server auto-assigns the client to a team. This improvement allows us to update the skeletal mesh of the player every time a change is made to the player state. These changes will come in handy down the line, when we implement cosmetic items.

New Map

We’ve also been working on a new map specifically designed with the data we gathered from early playtests. Our first map was completely procedurally generated but lacked any real level geometry. It was essentially a football field with trees in the middle. It was uninteresting to navigate and difficult to mentally map. We experimented with map hazards, procedurally generated landmarks and ice patches, but finally came to the conclusion that we would need to hand-craft a map so that it would have more character.

Another challenge that we identified came with the semi-top-down perspective in BCE. The camera is angled in such a way that players who are “south” of other players have the distinct advantage of being able to see and attack enemies without the threat of being seen. We have chosen to remedy this imbalance through level design. The new Gorge map features three organic lanes which laterally split the battlefield, removing much of the advantage that approaching from the bottom once afforded.

Gorge Level update

Here’s a sneak peek at the new map which is still going through its art-pass stage.

The new map is a little smaller, and has a second higher layer along a cliffside that offers an entry-only choke point into each cave. In the middle there are rivers of ice that will break over the course of the game, shrinking the mid choke point to make flanking opportunities more attractive. Along the bottom of the map there is a plane of slippery ice which, although difficult to traverse, leads straight to the enemy cave. We hope that with a map that helps encourage tactics and team work players will start getting the point of the game a lot quicker. It also looks way better thanks to our artists!

Going forward

We are scheduled to debut on Steam Greenlight by the end of June or early July. That update will include a newer more stable build of the game, a gameplay trailer, and a new song! As mentioned before we’re going to start posting an update every Thursday with possibly some more content in-between, so if you’re interested in the process check our Twitter!