How the project started
Hi everyone, my name is Brandon Swan and I’m the project lead on Battery Jam, a game developed over twenty weeks at the Savannah College of Art and Design in Savannah, Georgia. Our team consisted of four core people, along with some outside help in the form of animators and an audio team for sound effects and music, giving us eleven people on our credits currently. Our core team had worked together before, creating a board game that should hopefully be on kickstarter later this year, and enjoyed working together on it so much that we reworked our class schedules so that we could all do our studio class together to make a game.
Above all else, Battery Jam succeeded because we chose what we did carefully. We spent some time discussing options before the class had started, and made sure we pinned down a style of game and a scope that was going to work with our team and our aspirations. Since we can’t really give you much content about how to discuss your talents with your team, we’re going to tell you about some our design decisions, and a little bit of engine work. It was a pretty brisk twenty week sprint that got us a trip to E3 2015 for the college game competition and the Game of the Year award from the Autodesk CG Student awards, so we’ll do our best to gather our information, make it digestible, and hand it off to you to take what you can from it!
The Art
Why we chose our visual language
When looking at a lot of other student games, one of the common threads we felt were running through them was that despite so many of them having great ideas artistically, they were usually a little lacking in charm. So, we decided one of the main things we wanted to do was focus on trying to get personality out of the game. As a team largely made up of artists, we figured if the mechanics don’t pan out, at least we could get the curb appeal right! I was also the concept artist for the game, and lucky for me, the team was down with the robot+third wave ska idea I put forward, so I’ll take a minute to talk about some decisions we made in regards to our art direction.
How we Approached the Characters
The characters were an interesting challenge to figure out, but one that was defined by the limitations of the project. When we started the project, we had one animator on the team, and we knew she was capable of rigging. We also knew that we wanted four unique looking characters, so we had to figure out a way to keep rigging and animating simple, while finding a way to define their aesthetic.
Robots were an easy decision to make, not only because they’re robots and automatically the best decision, but because we didn’t have to worry about skinning an organic model. Simple parenting and ball joints seemed like the best and fastest approach. We knew it would be easiest to share the same rig as well, and knew we could switch out components of the characters to make quick changes to the designs between each one within our schedule.
So knowing that, it created some convenient boundaries to work within when designing the characters. On top of the rig limitations, we knew the game was going to be played from a top down perspective. The best way to define these characters then, was going to be by the shapes and colors of their heads in particular, at least within the context of the characters I was creating. I was looking at the Wipeout racing series for inspiration on some of the shapes and forms, and the liveries of the ships, while trying to mesh that with the ska theme we had chosen. As you can see, the attention is on making them sleek and sporty, while using comical proportions and the various instruments to add some quirkiness to them. Their personality is pushed more with animations like the intro sequence and title screen where the characters can be seen posing, then dancing to the music, and unique animations while playing.
We did run into an interesting dilemma once we started animating. When I created our characters, I drew them with very 2d silhouette dynamics in mind. Angled forearms and shins to make their stance look more dramatic being the main thing. When Everett modeled our first character, Turbo, he built him to the illustration exactly as he should have, and we thought it looked awesome, and it does! But once we started animating, we realized those bent joints led themselves to some very awkward looking poses and movements. For example, these models throwing a jab like punch, or any thrusting movement with their arms looks extremely odd because the forearm is bent so intensely. Luckily, these bends also work well for certain poses, so swooping motions like uppercuts or flexing in front of their chest read very well because the curve fits the line of action much better. Below, you can see a simple example of how we used the curves to make poses more dynamic.
Without the bends, these poses wouldn’t have the same flow that they do now. It lends a kind of illustrative quality to their shapes that worked out well for us, despite it stemming from a bit of a mistake on my part.
You can see on Rockets turnaround just how steep the bends in the shins and forearms actually are. This was essentially used as our T-pose, not for any particular reason outside that once I pinned down the general shape and proportions of the characters, I used their standing pose to create them. Instead of redrawing or rotating the arms in Photoshop, we figured the ball joints wouldn’t cause any problems if we just modeled them as posed so we could keep plowing ahead with our schedule.
Design
Hello all, Battery Jam designer and team pretty boy Abraham Plato here to discuss the motivations behind the design choices we made in Battery Jam and how those choices evolved over time.
Combat
During the early pre-production phase of Battery Jam when the shouting matches had died down and we had started to agree on things, the gameplay of bomberman was brought up, specifically the multiplayer. Unlike pretty much every competitive multiplayer game out there, the game didn’t focus on direct attacks. Instead you placed bombs in strategic lotions and essentially tried to influence your opponent’s movements until you could trap and kill them with a cleverly placed bomb. We thought this would be a very fun and unique way to style our combat. Rather than directly attacking opponents, we wanted to create a system through which players messed with each other’s movement and knocked them into tertiary deadly environmental traps, like lasers or lava (What?...You can’t be original 100% of the time!)
This design goal, coupled with the comical aesthetic of the game led to the creation of player power-ups like giant fans, magnets, rocket powered boxing gloves and a move that is legally distinct from Sonic’s spindash. Each of these posed their own set of design challenges early on to get them feeling fun and useful, but all of them suffered the same initial issue.
During their first iteration we thought of most of these powerups as placed objects. So the player would set the power-up on the stage and then it would do its thing. To keep a high energy feeling to the game we thought it would be fun to have the player jump into the air, throw the object onto the ground, and then flip away. While the idea itself was sound, it didn’t mesh well with most of the power-ups, which were meant to be directed at other players, and instead got dumped at the user’s feet. The second issue we faced was that the player remained locked to a “deploy” animation for a full two seconds, which is a veritable lifetime in game-time.
Our solution to the first problem was to nix the deploy animation for almost every power-up, making them into either a projectile giving their placement at the user’s location a purpose. Then we shortened the amount of time the player was in the air to a fraction of a second, which felt much more fluid for players trying to set up a trap and keep running. The major takeaway from this and from the early stages of Battery Jam in general was that players think and move much faster than we gave them credit for. If something takes longer than a quarter of a second it had better be very important and FEEL very important too or the player is going to get bored or feel stuck.
Necessity is the mother of invention
We loved the idea of creating a grid based battlefield that players could mold into whatever they needed in a given moment. Put up walls for protection, dig deadly trenches to knock an opponent into, or maybe just put a barrier between you and the player trying to kill you. The issue with this design was that players could quickly cut themselves off from the rest of the field and be stuck away from the action. We needed an ability that wasn’t inconsistent or random like the other player power-ups, because we wanted players to have a reliable way to get back into the fight, so we created player abilities. These would be consistent abilities the player had access to on a cooldown, and we ended up with two.
First, “Slam” was a player ability implemented in one of the very first iterations of our game. By slamming the ground players would level any adjacent tiles that had been either raised or lowered, back to center. This ensured that no matter what the state of the field is the player can immediately create a walkable terrain. To keep things interesting when you didn’t need it for leveling, we also added a knockback effect, which got first doubled and then tripled in size to make sure it felt useful as an attack. The cooldown timer was also cut from 15 seconds, to 10 and finally to 6. Early fears that the attack would become the only thing the player used proved to be unfounded, and were replaced with player’s constantly complaining about waiting forever to reuse the ability.
The second player ability came about as part of a happy accident. As I mentioned above several of the player power-ups went through several stages of iteration before they felt fun, useful and unique. No power-up went through as many changes as the goo mortar. In its current state it’s a big ball of goo that gets lobbed through the air, splattering on the ground and sticking anyone caught in the blast in place for a bit. Originally however, it was placed with the deploy animation right where the use was standing and only slowed player movement. This was pretty useless because it usually just hurt the user, and it wasn’t very fun even when people did get stuck in it, because moving at half speed is just annoying.
Yours truly had the brilliant idea to add a dash component, whereby the user could pop the goo where they were standing and leap away to avoid getting caught in it. This was also when the slow was changed to a stick, and this made the power-up feel WAY more useful. The problem was that in truth we had created two different power-ups in one, a dash and a stick. Player’s enjoyed using each of them individually but together they didn’t make much sense. Why would you want to run away from the opponent you just stuck in place?
We decided to make the goo a projectile which is when it became the goo mortar you know and love today, and make the dash a second player ability called “Blink.” We also added an invincibility buff so that Blink could be used to jump over lava or past a laser which gave it its own very useful slot in the player’s utility abilities.
Suspense as function
There are great moments in any entertainment medium when our sense of fun is enhanced because a moment is given a sense of urgency or suspense. It might seem like things are getting more difficult even when the only thing that’s changing is the volume of a pipe organ in the background and the level of camera shake. We designed several mechanics around enhancing the moment to moment suspense of Battery Jam.
Shaft the Laser Bot used to feel pretty useless. He never seemed to be able to kill anyone because he would spawn in on a random column and blast his way over maybe two or three columns and vanish. Players could easily easily dodge behind a raised tile, if they were even in his limited AoE at all. The solution came in two parts.
First we changed the laser so that it would always spawn in the middle of the stage and go left or right, thereby covering half the stage every time. Then we set it up so that Shaft would either go all the way to the edge, or one column shy of the edge, decided at random. This created high tension moments when a player had been cornered by the laserbot and it was bearing down on them and they didn’t know if it would spare them or cut them down.
Another environmental hazard, the bomber, underwent an even more extreme and important transition. At first the bomber would simply spawn a reticle onto a random tile, marking that tile as ‘armed and dangerous’. The issue was that there was no mechanical difference between these tiles and lava, both were simply deadly tiles to walk through. We came very close to scrapping the bomber all together. Luckily Everett had the thought to increase the oomph of the bomber by spawning it on many tiles at once, and rather than having it simply arm and wait for a player, bombs would then rain from the sky all over the field. In reality this is very easy for a player to avoid since the deadly effect lasts only seconds and they simply need to avoid tiles marked with a reticle. The important part of the new and improved trap is that it makes players feel like they are about to die, and usually results in people racing around the field screaming for their lives, fun!
Finally we embraced the age old practice of “sudden death.” It can be a great way to decide the victor in a tie or, in our case, force players into much faster paced combat if they’ve been avoiding each other a little too much. When a match goes on too long the outer rings of tiles begin to sink into lava one at a time, with a short interval between each one. The most immediate effect is that players have a smaller space to fight or run away, which forces consistent confrontation, speeding gameplay way up. It also creates a sense of tension, as the screen fills up with glowing red lava the players perceive the game in a different way. Everything becomes more high stakes and the ‘red is bad’ part of our brain kicks in and changes the way we approach the game.
Technical Art
Hello, this is Everett Gunther, lead 3D artist responsible for Battery Jam’s environments, character models, effects and lighting. I’ll be talking a bit about some methods we used to quickly add life and dynamics to our arenas.
The tone and energy of the game called for a backdrop which moved and pulsed with the beat of the music, so dynamics in the background art was a primary goal. The vast majority of those dynamics were achieved using simple animated material deformations. For example, waving flags, wind in plants and speakers that pulse with the beat. Let’s take a quick look at how this was done for the speakers.
For the speakers, I started out with the shape of the speaker cone modeled in as a flat surface, since I knew the deformation would be defined by vertex normals. I then made a simple black and white mask to clearly define the weight of the deformation.
In UE4, I selected the asset in the scene and went into Vertex Paint mode. I then imported the vertex color mask using the import from targa option. That way the texture was converted into much cheaper vertex color data.
The material setup used for the speakers ran using a linear Sine node, with the pulsing effect achieved by masking with the Sine’s direction output.
This result is then multiplied by the vertex normal, then the vertex color data, and then a value in world space units for the movement to happen across. The vast majority of our material deformers used this basic setup in different ways. Here’s how the final result looks in the scene.
And here’s another use of this method, for animating the height of our river water:
It was a priority goal for me in making the arena environments that they move and seem as alive as possible. We used these basic methods to animate things like grass waving in the wind, plants bopping up and down to the music, hovercars that float and bob in the air, flags waving in the wind, ect. They allowed us to insert dynamics at the material level in tons of places without the need for specially animated assets, saving us a lot of time and making the game look that much more polished.
Blueprinting
Hello, my name is Esther Nho and I did the majority of the blueprinting on the project. All of the events and interaction you see in the game was created solely with blueprints. Only a couple of us had some basic knowledge when it came to coding, so the blueprinting system was really helpful in the creation of our game. It was easy to get the hang of and provided all the tools we needed to add variety into the gameplay.
Having the logic in front of us made it easier to track down bugs that occurred. For the stubborn and persistent bugs, we were be able to figure alternate solutions to achieve what we wanted. If one way didn't work, there was always another option.
For example, Battery Jam is played using a gamepad controller. One of the issues we ran into was getting the controller to work with the widgets in our game. We were using Unreal 4.6 at the time, and later updated to 4.7, but widgets still did not offer gamepad events in their eventgraph.
The solution we used to get around this was to create a blueprint actor for every widget to feed controller input to those widgets. Whenever a menu was called we would enable input for all the player controllers for that blueprint. The actor had controller events that would trigger corresponding custom events in the widget.
Our "buttons" were image elements that were set from a texture. The animations were created in the UMG designer and played during the hover state.
We had two arrays of images for the normal and hover state of the buttons. When players navigated through the menu, the the proper image would be set on event tick depending on which button they were currently on. When players pressed the bottom face button on the gamepad, this triggered the event for the button that was currently selected in the menu. The controller blueprint was then placed in any level that could call the menu.
As Brandon mentioned earlier, Battery Jam was created over the span of 20 weeks. We were by no means experts on the engine before the project began. Because of our stringent deadlines, our main focus was to obtain functionality with as little bugs as possible. It didn’t matter how we did it, as long as we got it to work in the end. When I look at the scripts today, I know there were definitely more elegant ways to approach certain areas. As we move forward, we are shifting the technical mindset focusing on revamping a lot of our scripts to allow for more long term flexibility. Oh, and so we can add more explosions and stuff.