Foxhole Windows game

DISCLAIMER: All of the content below is heavily conceptual and may never be in the game. All images and text are stand-ins. Please read this before taking the images out of context!

The Return of Callahan's Gate

@NorthernPixels
Oh, praise ye mighty soldiers, but fear not, Callahan's Gate is on its way back to Foxhole. Yes, there's already a town called Callahan's Gate; however, it's naught more than a feeble imposter, a shadow of its former glory, a grotesque doppelganger clothed in the skin of our once-beloved town. Oh yeah, and we're making some other changes to Deadlands too. Deadlands is often a crucial map, especially in the early-mid war period. It's often quite contested and typically where the first major land-grabs stem from. Over here at Foxhole HQ, we've been monitoring how that plays out, and we've noticed some trends that we're not all too happy with. One of the more troubling trends is that control of the region seems to play out similarly every war until one faction brute forces the other and takes control of the region. This occurs due to much of the Eastern side of the map being open for business. Another nagging issue arises when establishing a war config. We always have to set towns with awkward neutral zone gaps to find an acceptable balance. In update 26, we updated Deadlands to have more synergy with the rest of the world, yet didn't take into account the fact that we might rearrange starting locations or orientation. As mentioned earlier, Deadlands being the most central map leads to it being quite contested early on. Lastly, we felt like some towns in the region flip too easily, and some not easy enough. The distances from Abandoned Ward to Relic Bases to important towns weren't as consistent as we'd like, either. We never set out to create a mirror region, and as you'll see in the map below, we still haven't done that. It goes without saying that these inconsistencies have been partially at fault with the lopsided early-war flow. So, here's how we're going to be updating Deadlands.

What goes into making changes to Deadlands? As the oldest map in Foxhole, Deadlands holds a special place—not just in our hearts—in the hearts of many players who've been with us for years. When we make changes to Deadlands, often it comes at a cost. In update 26, it was really a "Kill Your Darlings" moment for us. Towns like Sun's Hollow and Callahan's Gate were gutted, the River Mercy had been dramatically altered, and a substantial eastern extension was added. When coming back around to make further changes to Deadlands, I, personally, wanted to make sure that we maintained as much of its spirit as possible. When the opportunity arose to bring back the old Callahan's Gate, we jumped right on it. Furthermore, we're going to ensure that Brine Glen maintains its identity, despite being moved from the location it's held since it was introduced to the game some four years ago. At the end of the day, we want to bring back a little bit of the old Deadlands spirit, ensuring that it shines just as bright in modern-day Foxhole.

The Animation Continues

@AgeBee
Animation work is never finished in video games. There is always something you can make better, movements you can fix, bugs to squash. Particularly with a game that has a long development, a lot of assets that were created at the beginning of the production can look outdated by the end. One of the particularities of Foxhole is that some years ago, we had to update the skeleton of the player character. But in order to not completely toss all the work done up to that point and have it unplayable for months, the animations from the previous skeleton were imported to the new one. This was not a bad decision. It ensured the game continued to be playable and allowed for the progression of the development. But it led to a huge amount of animations that functionally worked, but didn't look good.
As we inch closer to the game's release with each day, I've been slowly fixing these ill-fitting old animations. As of now, the vast majority of them have been retouched, although there are still a few stragglers.

For instance, the wounded animation.

This set of animations is particularly interesting because the end result (the character laying on the ground begging for help) has to be matched regardless if the player was standing, crouched or prone at the time of injury.
That is pretty straight forward when the player is standing or crouching. Just keelback and flop on the floor.

But what happens if the player is prone when he gets wounded? After all, when prone, your head is forward. But when wounded, you face the other direction!

The trick is, you fake it. If the character is laying down, one of the ways they could lay the other direction is by standing up first, then falling back later. This could work but would take too much time, making the animation longer than what is required. So instead of standing up slowly, I made sure that the character's body "jerks up" due to the fatal impact. Suddenly assuming a position that is an in-between crouching, doubling in pain and explosion impact.

All alone it would look completely broken. In reality, though, when the player receives that fatal blow, there are blood spatters, camera shake and explosions all happening at the same time. This all helps to mask the transition and our brain goes "oh ok. I got blown back. Damn it." By then, the animation has already transitioned to the looping wheezing one. Now we are just left hoping we get healed by a good samaritan so we can stand up to fight again.

Data Refactor

@Mark
When working on a long term project like Foxhole, every so often its necessary to spend time refactoring to keep the game's code in a maintainable state. This refactoring process can be seen as doing the "gardening" work necessary to keep the codebase healthy. Without this vital work, it becomes harder and harder over time to add new features, change old ones, and keep the game bug free. Our latest endeavor has been a data refactor. In this context, data refers to the specifications of all the content in the game such as items, vehicles, structures, and more. For example, there are 112 item object types in the game (which include weapons, ammo, lore, relic pickups, and other things) and each of those has 28 properties as part of their specification. Properties include text like names and descriptions, stats like cost and crate size, and other variables that aren't directly exposed to the user such as flags indicating whether or not an item can be used while inside a vehicle. For just items alone, there are over 3000 data properties that have to be maintained by a fairly small team of developers. When you include vehicles and structures into the mix, that number jumps to well over 10,000.

Foxhole's upcoming summer update will include a fairly large drop of new content, so before doing that we're investing time into reducing the number of properties that have to be maintained, and also making some changes to make the process of game balancing on this expanding dataset more efficient moving forward. To reduce the number of properties for items, we first eliminated a bunch of legacy ones that weren't even being used by the current game anymore. The next step was to group together items that had a bunch of common values for certain properties and then factor them into "profiles". For example, we know that all small arms ammo items in the game behave a certain way (they are stackable, can be retrieved in multiples of 2, have the same retrieve time, etc) so instead of manually specifying the properties associated with these behaviours for each ammo item type, we instead have a profile that defines the common values. Then all we have to do is assign that one profile to each ammo type and to any new ammo in the future. With this approach, we were already able to reduce the number of properties down from 28 to 19, eliminating a ton of future maintenance work and effort for adding new content.

Another solution we implemented was for optimizing game balance. Right now in order to implement a game balance for a bunch of content, a developer has to open up a bunch of files for the content in question (e.g. one file for every small arms weapon if that's what's being balanced) and meticulously modify a bunch of values. It's an arduous process that's prone to human error and makes it difficult for us comfortably game balance more often. When strapped on time, the answer is usually "let's not touch that for now" when it comes to game balance. To help facilitate more efficient game balancing moving forward, we implemented a feature called "data tables", which allows us to visualize and modify lots of data properties across many pieces of content at once. We also rearchitected our code such that only properties relevant to frequent game balance (as opposed to all properties) are exposed in the tables. What's more these tables can also be exported into spreadsheet tools like Google Sheets for even easier manipulation.

While this refactoring task certainly hasn't been as exciting in the way that implementing new content or features is, but it's satisfying in its own way. It's the responsible gardening work that is necessary in order for us to further maintain and expand on Foxhole for years to come. You'll already see some of this bearing fruit in the upcoming Summer Update in a few months from now.
---------------
Our next devstream is still scheduled for next Tuesday at 2PM EST on our Twitch channel.