BCEmachine: Constructing our mobile PAX booth


Hey y’all, Shempi here to talk about our month, and wow what a crazy month it’s been. The team had the chance to pitch our game at the MassDigi Game Challenge in February. We were awarded runner up in the College Alpha/Near Release category! Congrats to the category winners Obio and BareHand, and extra congrats to Small Squares for the Grand Prize win for May’s Journey, an adventure/puzzle game that teaches programming fundamentals. Overall it was a really fun experience where we got lots of valuable feedback and a ton of people loving our game! If you’re in or around the Boston area, definitely check it out next year. The real reason I’m writing this post is to talk about the BCEmachine, though, so let’s get into that.MassDigi Game Challenge


You’re probably wondering, what’s a BCEmachine? The BCEmachine was our mobile “booth” at PAX East 2017. I built a costume to wear at PAX that turned me into a walking, functional arcade cabinet minotaur thing. It was pretty awesome. In the following section, I’m going to explain why we did it, how I built it, and the experience of taking it to PAX.BCEmachine

The Motivation

You can say your game is fun as much as you want, but that doesn’t help you sell your game. We’re at a point with B.C.E. where we’ve found the fun. That’s supposed to be the hard part I guess, but really the hard part is getting it out there and convincing people it’s something worth paying attention to. After all, even if I tell you we’ve found the fun, that doesn’t mean a whole lot coming from me, the developer. In comes marketing, PR, and other exposure. It’s really not quite as simple as a couple of Facebook ads. I wish it were. I won’t claim to know much about marketing, but I know enough to say that it costs a great deal to get somebody to engage in your product in any way.

Bringing your game to a festival or convention is a great way to get people engaged. Blue Drop Games is based in Boston which just so happens to house the biggest (non-trade show) game convention in the US, PAX East, so we set out to bring B.C.E. there. First we tried applying for space at the IndieMegabooth which we didn’t get. Then we tried to win the Grand Prize space from MassDigi at the Game Challenge which, as I mentioned above, we didn’t do. We had no exhibiting space at PAX but with a tentative Summer release, we needed to get B.C.E. out there…

The Plan

The idea originally came from something Rich Gallup from Disruptor Beam said to us in passing about “just going for it” and setting up in the expo hall. We laughed that off and didn’t think much of it at the time, but later that night I got to thinking about it again. If there was a way to stay mobile while exhibiting the game, then Rich’s far fetched suggestion might not be so far fetched after all.

Thus the BCEmachine was born! The goal of this project was to smuggle B.C.E. into PAX East. Cue the Mission Impossible music. In order to do so, we had to have a mobile setup to prevent suspicion and fire code violations. Furthermore, we needed to have a reason for being at PAX. If we just walked in holding a bunch of demoing equipment, people would start to ask questions like, “Where’s your Exhibitor badge?” Luckily for us, PAX East is known for its monumental cosplay, which would provide the perfect cover story. That’s where the arcade cabinet came into play.

That was the plan. Cosplay as a mobile arcade cabinet, waltz into PAX East, and exhibit our game guerrilla style. If it sounds a little crazy, that’s because it probably was, especially with only a week and a half until the expo. Better get to it then!

The Build

The first step was planning the build. This was my first big DIY project of any kind, so I really had to do a lot of planning in order to get it right. Even then, there are some weaknesses I’ll go over at the end of this section. I used SketchUp to plan the build. It was my first time really using SketchUp but I’m familiar with Maya and Max and other 3D tools, so it didn’t take long to figure out. SketchUp is great because I was able to pull the measurements right out of it, which helped in ordering and cutting the materials. I’m sure there are a hundred other tools that do the same thing, but SketchUp is free and easy so that’s what I picked.Sketchup Arcade BCEmachine

The biggest challenge in planning the BCEmachine was how to actually run the game. I needed to balance weight with power needed to run the un-optimized B.C.E. I initially toyed around with using a mini PC build but that was quickly tossed out because powering it wasn’t feasible. The next idea used a laptop with a USB-powered monitor because I wasn’t happy with using a 15” display (I was having trouble figuring out placement of the laptop so that the screen would be centered). Finally, by phoning a friend, I figured out how to fit a laptop screen in the middle of the arcade “window,” so I settled on using a 17” gaming laptop. Power would still be an issue but this was the best combination of aesthetic, power, and weight.HP Omen BCEmachine

Here’s a breakdown of all of the supplies needed to build the machine with their approximate prices:

$1275 HP Omen 17-W253DX Gaming Laptop (bought and returned to Best Buy within 15 days…sorry Best Buy, they call it Indie for a reason)

$100 48”x96”x.394” Coroplast sheets x 2 (arcade cabinet shell)

$91 PVC and fittings (skeleton rig inside)

$69 Home Depot delivery fee (I don’t have access to a car that can transport the over-sized materials)

$20 McGroovy’s box rivets (securing coroplast to coroplast)

$165 Poster Printing (marquee and outer designs)

$26 Duct Tape (both black and white…a LOT)

$15 Spray Adhesive (adhering the poster prints to the coroplast

$4 Panty Hose (so that I could see while wearing the BCEmachine)

Total Price (approximate): $490 not including the laptop which was returned. Not bad for a PAX booth if you ask me.

Once all the parts arrived, it took exactly one week to build. Here’s how I did it.

Step 1: Cut the coroplast:

I used the measurements straight from SketchUp. I cut the stuff with box cutter, but it was extremely difficult. I should have used a hacksaw but I borrowed one from a friend and I didn’t have it until it after most of the cutting was done.

BCEmachine coroplast shellBCEmachine corplast shell


Step 2: Construct the arcade cabinet structure:

This part took some figuring out. I bought the McGroovy’s box rivets thinking that I would be able to cut a thin piece of coroplast and bend it, putting a rivet though it and each piece I wanted to fix together, sort of like a hinge. I grossly underestimated the strength of .349” gauge coroplast, though, and wasn’t able to bend it so I had to come up with a hack to make it work. I decided to split a piece of coroplast down the center of the gauge, then whittle off the corrugation, resulting in a pliable piece of plastic that I could use to fix the coroplast pieces together with. Note: whittling off the corrugation was a HUGE pain in the ass and I don’t recommend it, but given my time and budget constraints, I had to work with the materials I had. After all the drilling and riveting, the base structure was done. I had to rivet the 4 flaps of the “window” together in order to get that diagonal bevel effect.

BCEmachine rivetingBCEmachine riveting

BCEmachine rivetingBCEmachine rivetingBCEmachine riveting


Step 3: Add the see-through mesh and duct tape all seams

Pretty self explanatory. I cut two sections of the pantyhose, stretched them, and taped them to each side of my viewing window. I then used white duct tape to tape all the seams together and cover up the rivets. Looking back, I think the white tape might have looked better than the black tape I used to finish the trim in the end.

BCEmachine tapingBCEmachine laptop carriage


Step 4: Cut, build, and secure the PVC frame to the outer shell

I used the SketchUp dimensions to measure the PVC pieces I’d cut with a hacksaw. Once I put the thing together and tried wearing it I realized it was too heavy and some parts didn’t need to be there, so I just removed them. I didn’t use any PVC cement because I didn’t think I needed it. It might have been overkill, but it ended up biting me in the ass on the first day of PAX when the pipe would slip out of the fittings occasionally. The rest of the weekend we had the connections duct taped up and it wasn’t an issue. To secure the PVC to the coroplast shell, I used the same cutting, whittling, riveting technique from before to make bindings.

BCEmachine PVCBCEmachine PVC


Step 5: Cut the poster prints and adhere them to the surface of the BCEmachine

This time, instead of measuring everything out carefully using the SketchUp dimensions, I simply traced the outline of the structure. The cuts on the poster paper were pretty error-tolerant since I would have to tape up the seams anyway. I used the spray adhesive to adhere the prints to the surface of the BCEmachine. Something to note when using spray adhesive – when they say “when done, invert the can and spray until only aerosol comes out” they don’t mean when you’re done for the day. They mean after each spray unless you’re not going to wait longer than ~10 seconds. I wish I knew that going into this process, because the nozzle got really clogged up making it much more difficult than it had to be. Finally, once all the pieces were adhered, I taped up all the seams using mostly black duct tape and some white duct tape for the inside seams on the window.

BCEmachine outerBCEmachine outer

That’s it! Those steps took me a week. If I were to go back and do it again, I could probably shave about $50 off of the price of the build knowing I didn’t need so much PVC + fittings, and maybe finding a cheaper but equally effective solution for the outer design. I would also maybe use more white tape for the trim. I’m still not sold on either black or white, I guess it’s just a preference thing.

Now for the fun part…

The Exhibition

The BCEmachine was a smash hit!!! Well, with everybody except for one particular Enforcer. If you’re reading this, Enforcer, sorry for playing cat and mouse like that. I know you were just doing your job, but so was I 🙂 We spent Friday wandering around, confronting unsuspecting victims and having them play B.C.E. on what appeared to be some kind of odd half human/half arcade thing. Towards the end of the day we were told we couldn’t be demoing by that Enforcer I mentioned, so we left the expo and went to the Made in MA after party that we demoed at. The next day we started out strong just like the previous day, playing B.C.E. with awe-struck PAX-goers. It didn’t take long for that same Enforcer to track us down and threaten to kick us out for the rest of the day, though. Instead of playing, we just wandered around the show with the game on the screen, having our pictures taken, taking pictures with attendees, and just having a great time. The Enforcer didn’t like that either, so we finished the day simply showing the pre-game screen. Sunday was spent mostly wandering around without playing. Here are some of the best pictures.

BCEmachine @ PAXBCEmachine @ PAXBCEmachine @ PAXBCEmachine @ PAXBCEmachine @ PAX  BCEmachine @ PAX BCEmachine @ PAXBCEmachine @ PAX  BCEmachine @ PAX BCEmachine @ PAX BCEmachine @ PAX

Despite the limits put on us by the PAX Enforcer, the BCEmachine turned heads and drew crowds wherever it went. These are estimations but I would say about 100 people played B.C.E., 1000 photos were taken of the BCEmachine by attendees, 10000 people looked at/took notice of the BCEmachine, and the BCEmachine landed on 2 streams, one of which was dmbrandon’s Twitch Partners Lounge stream with over 800 viewers. On top of that, we had multiple offers for appearances on podcasts, YouTube Let’s Plays, and articles written about us. I’d like to preface this next bit by saying that I’m in no way an authority on marketing value. That being said, a 10×10 space alone (no furnishings, equipment, etc.) at PAX East costs $1500 for the weekend. Considering the total of about $600 we spent on the BCEmachine, Ubers, and food, you don’t have to do much math to see that we did pretty well with the BCEmachine. Hopefully soon I’ll do another (hopefully shorter) write-up trying to quantify the true marketing value of the pictures, impressions, etc. that we made over the PAX weekend. I have a feeling it’s up there in the thousands, but that’s a problem for another day.

Thanks for reading! If you made it this far, congratulations, you have an exceptional attention span. Here’s a picture of Mario playing on the BCEmachine as a reward.

BCEmachine & Mario


  • Shempi (Arjun)

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.

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!

Roadmap 2017: New Year, more B.C.E.

Happy New Year from the three of us at Blue Drop Games! Hope everybody had a happy holiday. In today’s development update we’re going to be broadly talking about B.C.E.’s development roadmap for 2017. Exciting stuff is on the way this year.

B.C.E. 2017 Roadmap

We are excited to take B.C.E. to the 2017 MassDigi Game Challenge. It’s a great opportunity for us to put B.C.E. out there and get feedback. The Game Challenge is a two-day event where the first day we’ll participate in mentor sessions with industry veterans and the second day we’ll pitch B.C.E. in a pitch contest. Definitely check out MassDigi because they’re doing great work in developing the game development scene in Massachusetts.

In the interest of getting B.C.E. into players’ hands as soon as possible, we’re planning to start a closed alpha test on Steam as soon as the Burnout game mode is ready for online play. We’re hoping to work out bugs and balance issues, and we want to gather feedback from players. Once the alpha is up on Steam, we’ll use that as a platform to push our major updates on the way to releasing B.C.E. We’re not sure of an exact date for the alpha yet but it will be coming soon. Speaking of release, we’re still planning to release B.C.E. in Summer of 2017. However, plans tend to change so it’s possible albeit unlikely that the launch might be postponed. The last thing I wanted to say on the topic of general release roadmap is that we are choosing to prioritize the Burnout game mode for several reasons that I won’t get into right now. That means that new features won’t be added and the Firefight game mode won’t be further developed until we reach the level of excellence that we’re shooting for in the Burnout game mode. Those things will remain goals for our team, but we want to nurture the development of what B.C.E. is in its current state.

Development Update

Now that I’ve covered the broad roadmap of 2017, let’s get into some gameplay specifics. As we have been iterating and testing B.C.E.’s Burnout game mode, we noticed a few stagnant pieces of the combat, specifically the Club Throw and Spear Jab attacks. Our goal with the weapons system in B.C.E. is to offer different styles of play for players with different preferences and to give players choices to make in the heat of combat. It became clear that a Club Swing attack is highly powerful compared to its secondary Club Throw attack. Similarly, we found that the Spear was only really useful for its throw. On the flip side, we’re really happy with the dynamic of the Punch/Rock Throw combination, so we know that we can do better. Therefore, striving towards deeply dynamic and skill-based attacks for all combat options, we’re changing the Club secondary attack to a Block and the Spear primary attack to a Shove. The Club Block will serve as a parry move. With correct timing, players will be able to deflect projectiles and block incoming attacks like the Club Swing. The Spear Shove is a defensive move that’s meant to push enemies away to maintain safe spacing for a Spear Throw.

Also on the topic of combat, we’re overhauling the player controls in B.C.E., optimizing them for gamepad play. Changes include improved joystick deadzones, aim assist, and sticky aim. These updates will make combat more approachable and the gamepad controls more crisp. Less fighting the controls, more fighting other players. You won’t notice the strings being pulled.

As usual, we’re constantly working to elevate B.C.E.’s visuals, so be on the lookout for new hand-made animations, environment art, and overall prettyness. That’s it for now, I need to get back to work. Here are some initial designs for the incoming Cavewoman player model.

-Shempi (BDG)

roadmap - cavewoman

Burnout game mode announcement.

Long time no see!

Hi everyone. We’ve been a little quiet lately but fear not…development on B.C.E. is still going strong. A lot has happened since the last post, so I will try to quickly cover the highlights. This post is going to go over our Steam Greenlight campaign as well as the new game mode, Burnout, that’s coming to B.C.E.

Steam Greenlight

We got greenlit on Steam! Pretty excellent if you ask me. Our Greenlight campaign was only live for 9 days before we got greenlit. We got mostly positive feedback from the Steam community, but there were a few questions and concerns. First off, (for those who don’t know) B.C.E. stands for Before Common Era. B.C.E. means the same things that B.C. (Before Christ) does, but with a little extra inclusivity. So Before Common Era refers to all time before the year 1. We love B.C.E. for the name of the game because it accurately captures the theme of the game while giving it some mystique. Also, B.C.E. is a very long span of time so we have a little wiggle room to play with 😉

Game Mode: Burnout

Another primary concern that we received from the Steam community was that the game was online-only. The community was correct of course, and we all agreed that the game should offer some form of offline play. The result of that revelation is the new game mode coming to B.C.E.: Burnout. Burnout is a fast-paced, 2 v 2 game mode that can be played locally, online, or as a local/online combo session. The goal of Burnout is simply to be the last team standing. The catch, however, is that each player “owns” a fire that controls his/her ability to respawn. That means that there are 4 fires total – 2 red, and 2 blue. As long as your fire is lit, your caveman will respawn and you can continue to fight. If a player’s fire is extinguished, however, they will not respawn until either the next round starts or their fire is re-ignited by a teammate. Attacking (melee or projectile) a friendly fire will light it, and attacking (melee or projectile) an enemy fire will put it out. We’ve completed building the core functionality of Burnout and, though we haven’t had much time to play around with it, our initial response has been very positive. We very much look forward to getting as many hands on B.C.E. and the Burnout game mode as possible, but at the moment we don’t have any news about and alpha test. Stay tuned for that.

Another goal that we have been working extremely hard to reach was submitting B.C.E. for consideration for the Indie Megabooth. If you’ve never heard of the Megabooth, definitely check it out here. They are the premier showcase for indie games, and just a few days ago we submitted B.C.E. for consideration. In fact, Burnout was designed with a convention setting in mind. The single-screen, couch multiplayer lends itself perfectly to a hype-filled setting like the Indie Megabooth. We hope to have some good news to share on that in the next month or so.

That’s all for now. As I mentioned above, I hope to have some news about an alpha test and Indie Megabooth soon. In the meantime, here’s a snapshot of our handsome new caveman.

new caveman 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


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.


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.

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.


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.