• Register

Foxhole is a massively multiplayer game where you will work with hundreds of players to shape the outcome of a persistent online war.

Post news Report RSS Devblog 62: Resistance phase, Animation systems, and Office culture!

Read about features that are in development for Foxhole.

Posted by on

Disclaimer: All of the content below is heavily work in progress and is subject to change.

Resistance Phase

@Mark
After we announced Resistance Phase on our devstream this week, a saw a lot of discussion on Discord and Reddit. This thread and this thread on Reddit showed me that many of you guys are both excited and concerned at the same time about this new way to play Foxhole. I wanted to take the time to explain our reasoning and future plans for Resistance Phase.

Our primary goal with Resistance Phase was to unify all game modes in Foxhole and work towards a more cohesive and continuous experience throughout wars. It has always been our vision to have a singular persistent war instead of multiple game modes. Removing skirmish is just one more step in that direction. There were also some important supporting goals, such as streamlining our processes, code, and map creation efforts so that we can focus on building a bigger and more organic world that is free of the constraints that skirmish mode. For example, we no longer need to design regions to be balanced for skirmish mode so their layouts can be a lot more natural. We also don’t have to switch between disparate game modes, which has caused us all sorts of technical and operational headaches that ultimately hinder development.

We are going to be developing Resistance Phase over time and what you’ll see in Update 23 is a very bare-bones starting point and a huge work in progress. As it is today, this phase will feel like a short denouement after Conquest ends that allows players to continue fighting until the start of the next war. In principle, we expect this phase to still feel like a transition period in between Conquests, but we hope it will be more immersive and interesting since it takes place in the same persistent world as the rest of the game. There are a couple of special things that happen when the Resistance Phase begins. First, the Resistance faction will gain access to a new structure called the Resistance Camp, which is essentially a mini-FOB that can be built without a Construction Vehicle. Second, for a short duration after the Resistance Phase starts, Uprisings will occur at random towns in the world, which results in the Town Hall and Garrisoned Houses being flipped to the Resistance faction (defenses will be disabled as well). Finally, the Tech Tree will slowly decline, resulting in vehicles, structures, and weapons becoming Lost Technology.

We have a LOT of ideas on how Resistance Phase will be expanded on in the future. I wanted to discuss some of the ideas that have been brainstormed. First, we hope to give the Resistance faction more tools to fight a guerrilla war against the victor. As the losing faction, we hope these tools will give the Resistance a bit of a morale boost to help them regain their position during the transition period. At the same time, we also hope to give the victor their own set of tools to help them counter the Resistance. In addition, we want to add in mechanics to tie consecutive wars together. For example, we might want to allow players to build and hide a cache of weapons that they can access in the next war. The idea of player driven lore also excites us. Imagine writing a war story in a notebook and leaving it behind for someone to find in a future war. With all these ideas, the goal is to push towards a more persistent world and fluid narrative between wars.

Finally, we really want to hear suggestions and ideas about this feature. Tell us what excites you most about what Resistance Phase could become in the future.

Animation System

@HB
Let’s start with a question. How is it possible to animate an entire game, when you are the only person making everything that moves in the game?? Your character has to run, crawl, walk, jump, drive, and more,and all of those have to happen while the character might be carrying, shooting, reloading, equipping and unequipping, an assortment of armaments like pistols, rifles, carbines, mortars and whatever else comes your way. If I was to make a single animation for each and every one of those, things would get complicated real fast.


So what do I do? I chop and combine.For every single frame that you see a character moving in-game, several animations are playing at the same time, each one moving a specific part of the character, in sync with each other.

In Foxhole, the main divide for the character happens at the pelvis. Everything above it in the skeleton is considered “upper body”. (this includes torso, head, arms, and hands) Everything below it is considered “lower body”. (basically the legs and foot, but it also includes the pelvis itself)


This way, I can make a “running with a rifle equipped” animation and substitute the upper body for “running with a pistol equipped”. And since the rifle animation is taking care of the lower body movement, I don’t have to animate the legs of the pistol animation. Multiply this for every single weapon in the game, and it’s a lot of time saved not re-animation feet running!The time saved while animating is not the only benefit I get out of this system. I also get to jam any “reloading” or “firing” animation on the upper body of the character and I’m sure it will work with minimal issues regardless if the character is standing still, crouching, running, or even shadow-dancing and infuriating the enemy infantry. “Wow, HB! This sounds amazing!” I can hear the unfettered masses clamoring. “This system is perfect!”, they chant.


Well…. no. No system ever is.


As often is the case in game development, any decision you make has ramifications and limitations you have to deal with. One of such limitations is that when prone, several of these animations playing solely on the upper body can look strange and disjointed *.


The reasons why the prone stance is problematic is two-fold. First and foremost, when the character is standing, the pelvis and the chest are pointed on the same direction. But when the character is laying flat on the ground, his pelvis faces down as well. Which means that any animation that is made to work when standing will forcibly put his chest upright, completely breaking his spine **. In these cases, the only way is to create specific animation to play when the character is prone. No way around it.


Which brings me to problem number two: The pelvis cannot move. For those animation-heads out there, you probably know that the pelvis is the anchor of any animation. It’s commonly the place you start to build your rig from; and since it’s so close to the center of gravity of the character, tends to be the part of the body that leads a lot of the movement and weight shift of your animation. But the approach of separately animating the skeleton for upper and lower body leads to the pelvis being completely still then the player is not moving around the screen. If you are standing, it might not be perfect but the time saved in animation production and their upkeep is worth it. After all, you can move your chest and shoulder in all directions, even if you don’t move your legs. While running, the disconnect between the two halves is even harder to notice. When you are belly down on the floor, though… not so much. Most of the time, when performing any actions while prone, a person will shift around and position their whole body to be able to have the largest range of motion possible for that task. That meant that even for complex animations like reloading a Heavy Machine Gun, I had to find ways to do it only from the waist up. Needless to say that it leads to some very stiff looking movements.


How to fix it? Break all the rules, of course! Now, in the latest update, on very special occasions, I force the whole character to react to a single animation ***. Basically the exact opposite of the system that I’ve put in place, to begin with.

This might sound very counterproductive, but it is actually not. By only reintroducing full body animation on very specific cases, I can keep the versatility and coverage of a split system and just use the whole body when I’m sure it will not break anything. The outcome is so much better, with the added bonus that I didn’t touch any of the underlying system created by the programmers. Which means no extra impact to the network.


I can’t wait to use this technique to make the animations much nicer! Cheers! *Another ramification of this system I intend to tackle in another dev-blog is that additive aim-offsets tend to have adverse effects when combined with some animations playing in montages. Feet skating on the ground, gun bones floating around. These problems are more noticeable when the HMG is emplaced. The fix for them is not in the scope of this article since it will require some additions to the underlying code that runs the animation system as it is. Still, the emplaced HMG also looks considerably better, after update 23. Even if not perfect yet. ** Yes, I could force local mesh rotation on the upper body animations. But that would only make so the character clip the ground while playing an animation created with a different orientation. So I keep the top body world-oriented to smooth the blending between the firing montage and the additive aim-offset. *** If I were to be very precise, that already used to happen in the Animation Blueprint. Originally, the system starts with one set of animations for the whole body. I then separate the body and overlay much of the weapon animations on the upper half. This is where I play the montages in question as well. I apply additive animation on only the upper body; and then join the poses of both halves again, so I can apply any necessary full body animations, extra montages and additives before the final pose. What changed is that now some of those very specific montages that are supposed to influence only the upper body get to play on the whole skeleton if it passes certain criteria. (like being prone and having character_speed = 0)

Town Hall

@Adam

Working on a team is something that is developed over time with serious commitment and effort. Anyone can get lucky and find a group of people to work on a short term project, but not everyone can be apart of a team that can withstand the test of time, and grows with its members. I personally believe that building a healthy office culture starts from management clearly explaining what the expectations are for employees, but also the employee's participation in achieving those goals. It's a symbiotic relationship.

One of the best things about making video games is that the work itself remains challenging, constantly fresh and generally interesting, but do we remain interested in our colleagues? Are we invested in them the same way you are invested in the project? Our office is just a small, stinky room with desks in it, and yet it's still so easy to get caught in our tasks and life that we can go a whole week without saying hello to people in the other departments. One of the risks on a project is that work becomes more about solo production (getting stuff done on schedule) as most of the larger questions about the game have been answered, and less about the teamwork to achieve something. Underlying all of this, We constantly perceive a huge desire to rekindle our relationships with our colleagues again. Approaching this as a family, we have realized that we cannot possibly spend time together as we did when we were a studio of 5, so we have to be creative within our constraints and make time. We have been attempting to make space for this need to be with each other. We are a studio of eclectic tastes, personalities, and humor, so it's generally hard to please everyone, but when we are together and talking about something it’s amazing to see what we all actually care about each other. Last year we initiated something called a Town Hall Meeting in response to this. Essentially it is a monthly meeting where we all gather together to talk and then head to a bar to drink and eat together. The goal of these meetings are:

  • Be together as a team and have a structured office time to see each other

  • Eat a meal together so we can grow as friends

  • Create a space where we can objectively and honestly talk about the state of the office

We started up our new seasons of town hall meetings, and it was successful to me based on the criteria above. Whether people in the office were reluctantly participating is out my control, perhaps with time, we can see whether or not this is effective.

I personally am interested in working with these colleagues for as long as I possibly can, our company, like my life, would not be the same without any of them. I am interested in them as individuals, and I hope that in time we can grow closer as colleagues and friends.


That wraps up another Dev Blog. Be sure to check out our Foxhole Dev Stream for more information about upcoming features. If you have any burning questions you want answered be sure to tweet them to @Matt directly on Discord or Twitter, if your question gets selected it will be answered live on stream!

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: