Battery Jam is a 2 to 4 local multiplayer combat game where you’ll use items and player abilities to push, pull, stun and knock players into lethal traps around the arena. It began life as a 20 week project at the Savannah College of Art and Design, designed in Unreal Engine 4 using it's Blueprint visual scripting language. From there we went on to win numerous awards, and have continued building content with the intent of a digital release. I’m the lead on the project and have been responsible for numerous roles like concept, art direction, character design, UI design, and have worked very closely with everyone involved to make sure the game stays cohesive, interesting and of course, entertaining. Though I’m certainly not the reason the game turned out as well as it has, that’s the extremely talented team at work, I have played an important role in just about every part of the game. Ultimately, this was a team effort, and I tried to make sure that I let the team invest as much of their opinion and ideas into the game as they could while keeping things on point, but I’m going to break down some of the design decisions, gameplay mechanics, and artistic choices we made along the way.
Before Battery Jam, I took the lead on almost every project I was a part of, not necessarily because I wanted to be in charge, but because it seemed like the people around me wanted to work on a game, not organize one, and it was a job I felt confident I could do. Turns out I really enjoyed this though as it allowed me to work with everyone, share my ideas, listen to their idea’s, and try to marry the two when it seemed appropriate. With Battery Jam however, it was the big project I had been waiting to really drill my vision into and felt confident I knew what it would take to make a solid experience.
In school, I had heard numerous speakers and developers talk about their experience making games in college and they all told a similar story. “We scoped too big”,” we aimed too high”,” you should be building Space Invaders, not Grand Theft Auto”. On top of that, it seemed like all too often at SCAD I was seeing student games that were little more than an environment to interact with, and I have never been a big fan of just being in a place for the sake of being there when it came to games, I want something to do. I also felt that I was consistently seeing pretty solid art directions but lacking in places like animation or music. Almost all the games I was seeing left me feeling like they lacked any real charm, not because what they were trying to do was bad, but because it didn’t quite come together. With these things in mind, I had two main pillars to build the project around.
We had Twenty weeks, and a team made of mostly artists, and these were artists that complimented each other well. If we were going to be able to do anything right it was going to be making a game with curb appeal.
Right off the bat we looked to old games for some inspiration. We had to pitch 3 games, but had already decided we liked the idea of something character and action driven to avoid the pitfalls of the environmental showcases I mentioned above. Since none of us had worked with AI, we figured it wasn’t a hurdle we wanted to tackle for this project, so we decided multiplayer would be a good direction, and we chose local so that we didn’t have to fight with networking. When we were discussing the games we were researching, as you might have guessed, we came across Bomberman. Well, specifically, Esther Nho, our lead scripter came across it while we were all digging through games and I got really excited. It was a real eureka moment.
There were some key elements we liked about Bomberman that we felt really set it apart.
Simple level Design - Since Bomberman was essentially just an arena with a grid, we wouldn’t have to invest a whole lot into making an interesting play space. Tiles would make up most of the screen, allowing us to flesh out the small areas around it and make sure those areas were interesting and fun.
Indirect Combat - Bomberman was all about using what few tools were available and tricking players into getting trapped and killed. It’s a simple system with very clearly defined tools that the player can use to interact with each other. This sounded a little more interesting than just walking up and punching someone, or just shooting another player.
When we started fleshing out this concept, I raised the idea of having only non lethal weapons to push players into lethal traps built into the arena, instead of laying down lethal traps like Bomberman, allowing us to push the indirect relationship between players. One of the other members of the team, Abraham Plato, had also wanted to invest some time into making the arena dynamic. The two ideas came together to create the tile system with their raising, lowering, and hidden trap functionalities along with the core concepts for the items that players used to knock each other around. I’ll explain these more in the sections below.
Instead of the standard first to X style deathmatch, we opted for a last man standing game mode. We tried to expand on that mode by adding a small objective into the game in the form of gaining more lives during the match. Initially we decided to do this by spawning blue glowing bolts around the arena for players to collect, but this failed for a few reasons.
There was so much stuff going on the screen that it was hard for new players to understand what the bolts were even doing. We had the lives shown on the scoreboard at the top of the screen, and we had what we thought were adequate telegraphs to show the player what was happening, but as much as we adjusted it, it just wasn’t reading, and worse yet, even when we told people what they did no one seemed to care.
One of the main reasons we chose to do the bolts was to create small objectives for players to fight over. Since nobody cared, they weren’t doing the job we’d intended them to do. People were just attacking each other, or in some cases, staying out of the fray all together while other people fought, allowing the hiding player to hold on to their lives.
Soon after we started discussing what we might be able to do to address this issue. I raised the idea of a charge pad, so now, instead of busying up the screen with mindless objectives/items, we had one large objective that players could fight over. You still gain lives with it, but we thought it would work well because you have a game built around knocking each other about, but an objective that tasks you with staying on point for a time. It not only worked as intended, but was much more entertaining to use as its feedback was so immediate. It wasn’t just a blip and a segment like the bolts, there were effects popping off, sound queues for the whole charge, and enemies trying to take it from you. This really brought the game mode home and gave it the distinct flavor we had hoped for, and after adjusting the UI to match, we finally had players understanding what was happening when they were getting more lives. (More information about the Scoreboard and UI Below)
The system we developed is fairly simple. Players can pick up items around the arena, and can carry two at any time, they can't dispose of them, only use them. Players also have access to two player abilities, a dash and a slam. The items, and the player abilities are largely non-lethal and are used to push, pull, stun and knock players around into deadly traps that spawn in the arenas. Each arena has it's own unique traps, but each arena is made up of arena tiles which can contain unique traps on each stage.
Arena Tiles - One of the most integral elements of our game, these are found in every stage and haven’t really changed a whole lot since their original inception. We knew we wanted some sort of barriers within the arena from the get go since knocking players around a wide open empty plane isn’t exactly an exciting concept, and we wanted lethal traps to destroy players in. We realized we could use the tiles that take up the arena in order to make both, as well as hide various traps within them that could change level to level while maintaining the raised and lowered states, maximizing their use mechanically, while minimizing the necessary asset creation. What was great, was this felt appropriate thematically as well. I break down the traps unique to each level below, but wanted to make sure you know these up front as the items the players use can sometimes interact with or be effected by these. I talk more about the environments and their unique traps in a section below.
When I threw the idea for non lethal movement oriented items out there, I was imagining them moving players in much more complex manners. Instead of simply pushing or pulling players to you, I was seeing things moving like chess pieces. Some items might knock you diagonally, or back two spaces then one to the left. While I’m still intrigued by this idea on paper, once we started discussing it, we all pretty much decided it was a little too complex, and had a number of dynamics that made us feel it just wasn’t going to work very well. So we took that idea, simplified the concept and came up with our items and abilities.
The Item Box- This isn’t anything too intense, just a simple way for players to pick up the items during the match! It selects an item at random, and deposits it in the player's inventory while a large icon pops up above the box as an indication of what item the player received.
The Fan and Magnet - The easiest decisions we ever made, a straightforward push or pull item that can be fired in four directions. The only changes we made to these during development was expanding on how far their effects went, making them both longer. Our initial lengths were about 3 tiles spaces, and we kept coming up short of landing people in traps or pulling them into them. At three spaces, there simply wasn’t much in the way of opportunity due to having to use at least one of thosethree spaces for a player, and one for a trap. We extended the magnet to four spaces, and the fan to seven. Reasons being, if the fan pushed you out of it’s range, you could simply run off so we didn’t mind pushing the range pretty far to increase the opportunity to get knocked into a trap. The magnet on the other hand will hold you in place if it doesn’t pull you into a lethal trap, and leaves a player set up for a combo with another item, so it has a little more utility. The magnet also works through raised tiles, whereas the fan does not.
Goo Mortar - This item actually began it’s life as a completely different sort of item. Initially called the “Goo dash”, it would launch the player out of an explosion of goo, sticking any players near you, and allowing the player who dashed to turn around and attack them, or simply escape from a situation. This version just never worked that well, there was a disconnect as to why you were dashing, players weren’t using it right, and it just wasn’t going well. It got changed to a projectile, one of the few you can fire in any direction, with an undulating target area. Now, you can lock a player down from across the map if need be, opening them up to be taken out by you, or someone else. It also has the functionality of flattening out a 3x3 tile area where it lands, which means you can also use it to fill the board out.
Tile Pop/Drop - These were an interesting showcase to how a simple idea might not be as simple as you think. The concept from the get go was that the player could hold the item button to ignite up to three tiles which would then pop or drop after a brief telegraph once the player released the button. There was a big problem here when players kept lighting a single tile underneath them without knowing that they did, and popping or dropping themselves out of the stage costing them a life. We knew that meant we needed to make some adjustments, and we discussed it a lot, debating about whether or not we needed to adjust the functionality of it, or simply the presentation.
We decided to focus on the presentation, and adjusted the way the tile telegraphed the information. Initially, we only lit up the center circle, then we lit up the four corners as well, it stayed this way for a while, but we kept coming back to the same issue without an elegant solution. We made two more changes. The first, we just lit up the entire tile instead of just the pieces of it. I had raised this idea later on in the project when we were focusing on cleaning up how we presented information to the player. By using the corners and center, we were creating a lot of texture on the board. We thought that would be good at first, but it was just too much noise. Now, you just have a large block that makes a much more distinct warning sign. The second, our lead 3d artist Everett Gunther had the idea of sending out little waves when the tile was initially triggered, which gave a brief telegraph that extended beyond the tile that the player was standing on, which ended up helping the read tremendously.
Spindash - The Spindash is the second of two items that players can actually aim instead of just firing in one of four directions. The player ping pongs around the environment, knocking any player they hit in the direction of contact and stunning them briefly. Everett was clever enough to catch on when testing immediately that the ball would deposit players over lava and traps, so he coded it that it wouldn’t automatically finish over lava. The player can still manually stop the attack over anything, which means they might drop themselves into lava. The main adjustment to this was changing how far the line indicating your aim came out, and making it bounce off of surfaces you aimed at instead of just coming to a stop, allowing players to really aim up their shots quickly and keep pace with the game. It’s not always the most useful item, but it’s fun and works well to create a lot of immediate feedback to entertain the people playing.
Rocket Glove - Another fairly straightforward tool. This launches a projectile that can travel the length of the board unless stopped by a player or a raised tile. If a player is struck they got knocked back a few spaces and stunned briefly. This is a useful tool that allows players to close the gap between them to use other items or a slam to knock them that last inch into an environmental trap.
Wormhole - The Wormhole was another aspect of the game that hasn’t really changed much since it’s inception. It was a simple idea, our version of a blue shell. It’s only going to spawn on the player with the fewest lives, and is the only item that directly destroys other players by pulling them in from a radius around the player that deploys it. It’s one of the most dramatic looking events in the game, and usually leaves new players squealing about what just happened, but is super simple mechanically.
When we started talking about what we wanted to produce for the project, we came up with a plan for one arena during the first ten week course, a second arena during the second ten week course. Someone had brought up the idea of creating unique items to pick up for each arena, but I shot this down pretty much immediately, as I felt it would be detrimental for a few reasons.
Changing the tools the players have available means there’s just that much more to take in and understand. If we were wanting an “easy to pick up, hard to master” appeal, it wouldn’t do us any favors to give the player 5 dozen tools to learn.
If we had done this, we ran a serious risk of people saying “I like this level more because item “X” on level “Y” is awful and I hate it. While yes, that could theoretically be squashed with a lot of play-testing and changes, we had 20 weeks. Even if that was going to benefit the game, which I’ll reiterate my opinion that it wouldn’t, we simply didn’t have the time or resources to take on that kind of task.
Instead of unique items to pick up, we decided it would be much more interesting to create unique trap for each level. This way we could make different difficulties for each level, context oriented traps, and unique mechanics to tweak the game's systems and general game flow all while maintaining a consistent player tool set.
Skascraper - This was the first level we created when we started Battery Jam. Since we were building it around a musical theme initially, those elements faded as development continued, I had thought it an interesting idea to make it look like the event was happening at something like a concert. Everett Gunther had wanted to try something with a lot of depth behind the stage so it ultimately became this giant tower with a concert event on top that had been changed to an arena. We thought it would be fun to make it appear that people had just pulled over to see the event and watch, so we had floating cars pull up and park near the stage.
Shaft the Laserbot - Shaft is pretty straightforward and hasn’t had much adjusting. It basically flies up to the bottom of the screen and shoots a giant laser beam across the stage from the middle, moving either left or right. He does have some variables however, sometimes he will pass over the entirety of the field in the direction he chooses, but sometimes he will stop before the final column. This adds some randomness to his behavior and allows for some tense situations when you’re trying to escape and are uncertain if he’ll stop or not. Since the laser shoots from the bottom of the screen, players can take cover behind a raised tile, or even knock down other tiles to expose other players.
Artillery Strike - Originally this started with a simple functionality of every once in awhile it would just drop a bomb somewhere on the map after a brief telegraph that covered 2x2 tiles.This was later changed to create a hot zone where a section of the map would light up with numerous telegraphs that would all slam bombs down within seconds of each other. This not only made the design a bit more lethal because of coverage, but more entertaining too because suddenly you’re surrounded by bombs and someone’s pointing a fan at you. It really helped push the tempo of the stage up.
Tesla Coils - These initially spawned in a group of 3 tiles vertically or horizontally, but much like the Artillery Strike, simply wasn’t packing enough punch. They were changed to take up an entire row or column when they spawned, unless the tile in that column was raised or lowered. They’re a pulsating hot zone where the tile will telegraph for a moment, then be lethal for a few seconds, then perform that cycle a few more times. After we made the changes to this and the artillery it was becoming increasingly clear how much fun it could be to actually be fighting against the stage, and not just players trying to use it to kill you.
Bebop’s Ruins - By the time we got to make the second level we had started to understand what was working and what wasn’t with the traps. As such, production of Bebop’s Ruins was fairly smooth. By this point, we had created our own little backstory for everything, mainly that this was a sporting event in a crazy world and the event itself would take place in random locals where someone would deploy the arena. The idea for this stage was that someone essentially slammed it into some old ruins and made use of traps within the temple.
The River - When we were brainstorming ideas for level mechanics we kept bouncing around making large sections of the level do something, move, collapse, explode, anything. I don’t remember how the river idea came to pass exactly, but there was one main change we made. Originally the river was run horizontally through the arena. Once we tested this though I suggested we rotate it since it would take fewer tiles out of actual play from the board. The arena itself is 9x14 tiles, so if we had a river running horizontally at two tiles wide we were removing 28 tiles, whereas vertically we were only removing 18. We didn’t want the river to be a complete deadly void though, so we added logs moving down it to add some randomized opportunities to get across the arena or get saved after being hit into the river. We also added two bridges so that players always had an option to get around the arena if they didn’t want to rely on logs or the dash ability.
The Flamethrower - We took a page out of Mario 64 with this one. When a player was ignited they’d begin sprinting. Players can control the direction while they run, but we added a bit of a randomization to the movement and increased player speed to keep people on their toes and make sure that people weren’t too easily avoiding traps. We not only used a particle effect to show the player was on fire, but also added a new running animation to help drive home the altered state.
Poison Gas - The good old fashioned control mix up. Up is down, down is up, unless it’s up is left, or right. When we brought up the idea, a couple of us were of the opinion that simply reversing controller input wasn’t disorienting enough. So when you’re struck by this, the controls rotate in 90 degree increments, meaning it could be one of three altered states outside of the default. This ended up working pretty well in tandem with the Flamethrower! Normally, the flamethrower is pretty simple to deal with, but once you throw in the mixed up controls, it’s panic inducing and play testers always seemed to be amused by trying to save their flailing robots but launching into lava or the river.
Hydro - The third and most recent level as of this writing, Hydro was an attempt to push the dynamic environment a bit further. We batted around a lot of ideas on what to do and how to handle it, but seemed pretty caught up on the idea of playing with water. We considered putting the players inside a living space within an aquarium where the arena was surrounded by glass where it would break allowing water to pour in, or a capsizing vessel of some kind possibly being knocked around a stormy sea. Ultimately ended up taking inspiration from oil rigs and treating it as if a massive tidal wave consumed it temporarily. Currently, we’re actually redesigning the oil platform itself, as we weren't happy about how this turned out, and refining the mechanics on a few things.
Tidal Wave - Right now, the tidal wave is an interesting visual effect that doesn’t really do anything mechanically. We’re trying to come up with an idea on what to make it do, like pushing players the direction it comes in, or bringing debris across the stage to hit or stun players. It does leave the environment submerged temporarily, allowing jellyfish to float by and affect the stage, which was basically the intent behind it initially. It was just supposed to transition to a different state, but we realized it’s a wasted opportunity not to make it have more of an effect.
Jellyfish - When the field is submerged the jellyfish float past the arena wreaking havoc on the stage causing each tile within a certain radius to flutter and ignite, either popping it or dropping it or resetting it back to neutral. This has an intimidation effect much like the Artillery strike does giving players the sensation that things have really hit the fan. Players who happen to get caught underneath a jelly fish get zapped and knocked away essentially mimicking the effect of the rocket glove.
Warp Trains - The concept we pushed for the oil platform aesthetic was essentially a sea based shipping facility. Trains loaded with cargo would zip across the arena when portals would open up on both sides of the screen space and launch rails quickly followed by a train. The portals and the rails act as a telegraph, the train itself is the projectile that will knock players away if they’re hit by the front, or bounce players off if they get pushed or pulled into the sides as it zips by.
One of the things I really wanted to try with Battery Jam was ditching traditional HUDs. I’ll be up front, I like a good HUD, they’re pretty useful and often times a beautiful showcases of clever thinking and art. Good HUDs don’t feel invasive, they accentuate the game, can really help pull in some extra personality, and above all relay important information. That said, I’ve been wondering about new ways to address these kinds of things. Instead of plastering the screen with a bunch of icons and symbols, I wanted to try to get the HUD into the game itself. Let me break down some of the things I wanted out of the HUD vs where it ended up after testing and discussions.
The Scoreboard. - The scoreboard was such a beautiful idea that consistently shot us in the foot, over and over again. When we landed on the robot battle arena theme I started thinking about the massive score displays you see at sporting events, and thought this would be a fun approach. Everett raised the idea of having a video feed of the arena that would switch from player to player as if people viewing the event could see what was happening on screen. We thought this would be fun for players who would get a glimpse of them as a star on the screen, but it was just noise, no was looking at it, so it was one of the first things we changed with the board so that we could use that space for player information.
After the removal of the live feed on the scoreboard, we had me space to try some other ideas. We thought that maybe instead of just showing X of Y collected on the screen showcasing the progress of bolts, you collected 5 for a life, maybe we could show that information by building a robot on screen part by part. The idea was that your character silhouette would be showcased, and as you collected bolts you’d see your legs, waist, arms, torso and head warp in with each bolt until the Silhouette would empty again and a life would be deposited on your stack of lives. No one knew what the heck was happening though, and as stated above, no one cared about the bolts. We even tried adding a number within the silhouette to showcase how many bolts were collected and it still just was not working.
We spent a lot of time tweaking this, adding new effects like a zap of energy dashing from the bolt you collected back to your section of screen, making the silhouette flash and animate when bolts were collected, nothing worked. Worst of all, we were realizing people were not only not capturing bolts, but they didn’t even realize there was a scoreboard at the top of the screen. The discussions around this were huge, varied and complicated because we had so thoroughly been building our game, our presentation of the arena in relation to screen space, and even the levels themselves around the presence of a scoreboard, and it simply was not working for us.
Part of a bigger discussion involving how to handle the bolts that no one cared about, the scoreboard got completely redone after we ditched the bolts system and moved over to the charge pad. Despite my efforts to design a scoreboard that was a bit more interesting than just giant numbers, regardless of the heated debates surrounding it, by the time we got to where we’ are at, giant numbers seemed like the best solution we had. Slightly frustrated to admit it, but of course this makes sense. Everyone knows what numbers are, no one knows what a half filled out robot silhouette means until you explain it. Sometimes, the tried and true is the tried and true for a reason. So we changed the number of lives you had in stock to a giant number, we ditched a 5 life max limit that we had initially used with the bolt system, and we added a big empty battery at the bottom of the individual player space on the screen underneath your character portrait to showcase how charged the next life and charge pad were. The charge pad itself also showcased this information by filling up as you stood on it and changing colors to match the character standing on it when active. It was this iteration that finally seemed to be getting through to people and getting noticed during the match.
Player Inventory and Abilities - Since I wanted to integrate the UI into the game more, I took the opportunity to display player information in a similar manner by placing the item inventory and ability cooldown timer directly underneath the character. This was to accomplish the goal of clarifying the player items and abilities within the arena space as well by giving them a larger visual presence by extending the ring past the player’s avatar. I had also hoped that by placing that information underneath the player, you could avoid looking to the corners of the screen to see it, allowing you to keep better track of the events on the field. I feel like this was largely successful, as it allows you to track your items, and look directly below any nearby enemies to see what they have in their inventory.
It took a few tries to get it in a state visually that players took note of, but sometimes players would still suggest they’d prefer a traditional UI. We want to implement this as an option, but have not yet as of this writing. It did seem that once players played a round or two they were not having any problems with the under the player UI though. When looking at the feedback for why the under the player UI might have received the comments that it did, it seemed partially the UI and it’s feedback’s fault, but also just a matter of players learning how to read the game and see this information. One of the reasons I was against the traditional Ui was because of what it took to look at it. With traditional UI set up, a player would have to -
Look at their own corner to see their items, taking the eyes off the area around their avatar.
Register an incoming player, understand what corner the incoming players information was in, and find the appropriate corner to see what items and abilities they had, again, taking their the eyes off field
Once information was gathered from themselves or other players, they’d have to once again find themselves or the incoming player on the field, which were they to have been attacked right as the looked away would mean they could mean that they’re in a drastically different spot.
I also tried to make sure I designed distinct and easily readable icons for the items for quick reads during gameplay. The Ring around the character works as the cooldown timer, the striped area denotes the empty portion of the time remaining. Those times were 6 seconds for slam, 3 seconds for dash, both using the same cooldown meter so that players had to be decisive about when and how to use those abilities, instead of spamming them non stop. The items are displayed as two icons which stay oriented towards the screen so that no matter where you are on the arena, your icons are always right below you.
The Main Menu - Main menus are like a welcoming mat to your game and I really wanted to use this as an opportunity to drive home how excited and energetic we were trying to make our game feel. So I came up with the intro sequence where the characters dramatically posed, jumped in and danced while you explored what options were available. This, and the in game animations were made possible by our animators Rachel Geiger and Emily Katske. The initial inspiration for the entire aesthetic for Battery Jam was basically ska music which I’ll talk about below, and the first pass on the menu’s looked a little rough as I was trying to emulate lo-fi punk concert poster kind of aesthetic. I later cleaned up the fonts, but otherwise the layout remained largely the same.
Character and Level Select - The character and level select are part of the same menu system, and flow seamlessly from one to the other. We made the menu items in black and white so that we could apply colors to them based off of the colors we applied to the different skins for each character, so no matter what character or color you choose, the menu would adjust to fit. We carried this into the level select as well, giving each level unique assets that popped out, and a unique color pallet. The sky assets behind the menu's were originally created for the Skascraper level, but we repurposed them as a dynamic background for the menus.
One of my professors gave students an option to design a new website for Battery Jam and Niyna Spellman created a really interesting website that I don't have images of, but we used it to create some of the base design languages for our website and press kit. Her design was actually much more intricate, but was a great inspiration for the languages we started messing with.
The inspiration behind the aesthetic was close to my heart. Punk Rock and Ska music, Robots, and cute things. I wanted it to be a loud, bright, colorful, exciting world filled with ridiculous nonsense. I wasn’t worried about a plot, though a small one developed to drive the aesthetic, and I wasn’t interested in any sort of narrative. I just wanted a fun game full of fun things to look at and do. Ska music specifically is something I enjoy a lot, and I felt it would give Battery Jam a very distinct tone, and I had originally wanted it to permeate everything from the visuals to the animations and the sound effects. It’s a big part of what drove the idea of the robots all dancing.
I knew right away I wanted the characters to be cute. Not cute like a tiny puppy, but the kind of cute with an edge that even people who aren’t interested in cute things would enjoy. I described the idea as a chibi sports car. I wanted them to be sleek, cool looking characters, but shaped and behaving in a way that was fun and nonsensical. I did a write up about my approach to the characters for Epic games, which I’ll use to explain the process here. (*Pasted from my section of our development article for Epic)
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.