For the start of our game jam articles, click here.
Mechanical Monster Multiplayer
For game developers coming off the tail end of shipping a game, having a week to scratch build something new is wonderfully cathartic. It cleans the palate and soothes the soul, flash-igniting creativity in wholly new and unexpected directions.
Heaps of thanks to everyone who pitched in. No sandbaggers here. Great to work with different folks than usual, and to have the support of the audio team as we asked for way too much, to the production team for keeping us honest, and the executive team for sponsoring the game jam event in the first place.
What follows is a brief post-mortem about the project created by Game Jam Team 1, a cute, light-hearted little four person dash n’ smash game called Atomic Assault.
Monday morning. Coffee, juice, water, tea, or whiteboard marker in hand, the team’s cast congregated in the cozy chamber to concoct a collaboration that would culminate with a credible creation.
One of our designers took charge and asked everyone to come up with three words they felt would speak to the sort of game they’d want to make, or play, or make and play. He recorded the words on the board and then challenged the team to each dot vote the words that most resonated with each individual.
For those not familiar with dot voting, there’s dots, and you vote with them. More specifically, you have a finite number of dots, say four, and you put them next to each of the words you feel reflects your interests. If you want to get really clever, you can color code your dots, with colors reflecting the intensity of your passion about a given word, from burning red hot scarlet marker for most to fetid faded yellow marker for least, green and purple in there otherwise since you only had four markers to begin with cause someone keeps stealing all the blue ones to draw cool sports cars in the bigger meeting room. For folks into role playing games, the process is similar to moving points around when you’re crafting a new character. The words with the most dots win, and the rest get erased. Two similar words splitting the vote with an equal number of dots apiece will lead to someone dragging out a thesaurus to break the tie.
Our words were Demolition, Tim Burton, and Mech.
Next we discussed our team dynamics, took stock of each member’s skills, interests, and abilities. Have I mentioned how diversely skilled people at BBI tend to be? Artist one minute, robotics experimenter, rock star, boat captain, speed racer, rock climber, snowboarder, or amateur marathoner another, experimental VR guinea pig the next.
Our team had master modelers and a special effects wizard, however we lacked an animator. This example demonstrates an awareness of a limitation that we could filter subsequent product design decisions through, as we knew that any avatar movement would need to be programmatic – meaning handled by script or code, rather than via an animation system with bones and kinetics. This steered us (pardon the pun) towards vehicles and explosive combat, something that aligned nicely to the words we’d dot voted into office.
Agreeing on vehicles, and through the filter of our word “Demolition” around combat, destruction, and bombastic tone, we landed on the idea of a couch co-operative combat experience, something in an arena, team versus team, two players on each team.
A bit of earnest, excited brainstorming followed. Someone suggested being able to dash attack into one another, a comparison came up to that satisfying smack that happens in air hockey, and a feature formed.
Asking how scores happened, as no one felt the players should be winning by blowing one another up, lead to thinking of game examples like Rocket League, the score comes from bodily smacking a big metal ball into a huge goal to see it explode. The idea to smack one another into something for score emerged, and that lead to considering examples of scored destruction like Nintendo classic Bust-A-Move and genre descendant Bubble Witch.
Though dot voting might have culled words like mayhem and cyborg from dominance, their memory could not be wiped away as the player characters were to become something big, something cute, and something mechanized. Thinking of Kaiju, you can’t have giant lizards and robots smacking one another silly without the supporting cast of urban skyline buildings around to sell the sense of epic cyborg destruction.
An idea formed and gained universal approval. As a team based game, logistically it made sense for each pair of giants to represent and defend a “goal”, a city they call home for holidays and birthdays. The team must repel attackers, knocking them back into the buildings they’re trying to defend for big points, or taking the occasional pot shot with weapons dropped from the sky.
With a loose idea of what the game is firmly agreed to, the team quickly worked through a production plan to determine what assets we would need, and how the work would shake out across the team. Somewhat like creating a backlog for those familiar with scrum methodologies, a process that would support a subsequent functional design doc / checklist and the daily group stand ups we did to track progress, identify issues, scope, and affirm ownership and accountability.
By noon that first Monday our team had a sense of what we were making, and as we’d brainstormed together to arrive at our vision for the thing, we were excited about it and eager to each do our part to make things happen. Into the afternoon the first concerns were documentation and getting everyone set up with our new Unity project to best begin contributing content.
The whiteboard notes were translated into a design document that essentially served as a laundry list of content. The Google document became a “living” production document throughout the course of the week for functional designs, narrative overview, controls, and initial audio requests. Google made it easy for everyone to see and update the document at any time, adding and answering comments along the way. As tasks and items were completed they were struck through, while bugs were tracked at the bottom of the doc. Scoped / cut items were also stuck through and relocated to the bottom of the document. Audio quickly became complex enough that the assets were requested and tracked in a separate document outwardly facing to the Audio team.
Aesthetically, Tim Burton’s art had come up as a key reference point, and inspired the basic shape of our characters as well as the use of luminescent pink and neon green rather than conventional blue and red for differentiating the two teams.
After discussion and some quick exploratory doodles, our character artist found an internet fan of Tim Burton named Vaughn “Hat Boy” Pinpin who’d retooled many of the key Pokemon characters into gloomy styled cuties. Our artist then brought the notion of mech into play, while also incorporating suggestions of making the small character a schoolgirl, and the tankish character into something simian, preferably with an iron jaw as one might find on Trap-Jaw from the Mattel He-Man series.
Once he had models quick built, paint-overs were done to help inform how they’d be textured and the sorts of visual effects they might have. He tested the scheme on the Caterpillar first.
The end product saw the teams further differentiated through ensuring each team had a predominance of their key color, pink or green, to ensure clear legibility for the player versus the high camera perspective, as the characters would not be very large on the screen.
Meantime on the code side, a coders worked on locomotion and combat in a sandbox, setting up the functional parameters that others on the team would tune afterwards. Getting the units to take console controller input, to have the ability to dash, to be hit, to hit buildings, to acquire and use weapons, and to have stamina instead of health to spend, lose, and regenerate over time sat at the core of the gameplay experience. Getting the units moving and hitting one another came first, and fortunately quite quickly, affording us time to tune and the team time to play-test essentially from day one.
A designer worked through our game flow from launch through to summary screen, establishing the wrappers and user experience / interface aspects to ensure the team would be able to load and play the game as early in development as possible, albeit with lots of missing and placeholder components.
Another coder tackled the challenge of getting new rows of buildings to move into place as preceding rows were destroyed by players. Initially accomplished with cubes to represent city blocks, and more cubes to represent buildings, he had the rows moving towards the center from the sides by the end of the first day.
Through the week, cubes were replaced with buildings. Static strips were swapped with fragmented strips that could dynamically crumble into the center and the two sides appeared to crush into one another.
To make the most of our time, and more importantly, our visual effects artist’s time, the team secured a batch of generic city buildings from the Unity asset store. Some optimization had to happen, and two additional custom functional buildings had to be scratch built, the multi-building destroying Gas Tower, and the Eyesore”Trump Tower” Landmark worth beaucoup points when destroyed. Looking back, after the amount of retrofitting, optimization, and scratch building that had to be done to get the buildings to read and blow up correctly, trying to shortcut and save time buying an asset bundle from the Unity store, even with best intentions, probably didn’t save the artists all that much time.
The artists worked to add lighting to the buildings and environment to help with further legibility for the player, and to begin to bring all the assets in the scene together. The end product took a lot of leads from Tim Burton’s films, the heavy moonlight, mist, and silhouette skyline versus punched up contrasting street and building lights. Tweaking and tuning this ran right up to the final hours, and as is oft mumbled during game jams, “if we’d only had a bit more time.”
During all of this our visual effects wizard kept adding more and better weapon, destruction, and character ability effects into the mix. Every build seemed to reflect some new addition, and excited team chatter invariably ensued. Especially as more tunings for movement and weapons came into the builds, finding the sweet spot for each of the three character classes.
We got the intro flow working, from splash screen placeholder to character selection with timer that loaded into gameplay and announced the winner when the round completed. Player numbers, HUD icons, and stamina bars were added. A timer and score appeared. The game felt more real and realized by the passing hour.
On day four, the art for the mid-ground terrain destruction came in, the game looked nearly ready to have a bow put onto it, and the team began to consider the user experience and game flow from launch to match complete.
The team realized that the game would need to provide some context for players to understand why the combatants were fighting, destroying buildings, and why a chasm in the middle of the screens seemed to be consuming the resulting debris. Lacking time or resources to create an epic opening movie, a comic book story seemed the best answer, and though unfortunately added into the mix at the last moment with all the head slap of a tomato drink commercial, came together well enough to make aliens the deus ex machina and move on to gameplay.
Similarly, someone on the team suggested late in the week that the experience needed something crazy audacious to complete a match. How about a huge flying saucer wings in and destroys the loser? A quick group vote made that bill a law and the team commissioned a flying saucer from our character artist to fly in and vaporize the loser’s metropolis at match’s end.
Throughout all of this, we worked with the Audio department to qualify, quantify, cast, and orchestrate the sound effects and score for the game; from choosing the J-Pop anthem “Gimme Chocolate” by Babymetal for the opening front end to deciding what warbling wail best decried an alien invasion.
Our designer investigated options for playing audio in our project and elected not to use systems we’d used for Homeworld: Deserts of Kharak, instead leveraging the systems available in Unity’s base package, since our game had a fixed arena space and didn’t need the overhead of anything dynamic or positionally adjusting. Theoretically this choice also reduced the game’s processing overhead, allowing for better frame-rate and visual effect performance.
While we didn’t use DoK’s audio system, would be remiss to not point out that we earnestly grabbed chunks of utility code from DoK to facilitate rapid asset creation for defining player stats, their FX, and other aspects to help stand the project up more swiftly. If the game had had credits, there would’ve definitely been a special thanks to Homeworld: Deserts of Kharak in there.
The Front End loading screen proved to be one of the final pieces to go into the build because it required finished game assets. Off to the side of the working game project sits a stage where three characters appear to leap towards a special camera with a cluster of buildings and haze behind them.
Overall, the project proved challenging, educational, and deliciously successful. While some aspects were quickly scoped out, overall the end product reflects a valid proof of concept both for finding the fun for the gameplay, and defining a tone that could easily be expanded into numerous arenas, more hero characters, and a robust, irreverently silly narrative.
Some of the key takeaway lessons learned stem from where the team succeeded as much as where we tripped up or underestimated.
Communication. Use of stand ups, a dedicated Slack channel, email, desk-side chats, Google documents, and sitting together generally ensured everyone knew the skinny at any given moment, and allowed folks to ask and discuss on the fly as need arose, key to success with such an accelerated production pace.
Scoping. Rather than try to death march through trying to do to much, and further risk diluting efforts away from what works best and speaks most to the core values of the project, we regularly cut content features to stay on track, and were glad for it afterwards.
Legibility. This is a mixed bag and presented a lot of challenges. Though teams were readily readable, players could get confused as to which member of the team they were if they were dashing or dashed into a lot. Add to that our shift into nocturnal urban environmental tones and the amount of detail on our buildings, things can get muddy. With more time, I’m confident we could find a better balance of detail and accents for the characters and buildings to ensure players never lose track of their characters or the action around them so that they can make meaningful choices about how to move and react. The camera position and FOV are a factor in this too, as well as the size of the units versus the buildings.
Game flow. While the structure of choosing characters and getting into the game went in quite early, the Front End presentation and post game round summary screen went largely untouched until practically the last minute, in part simply because no one had stepped back to consider the full user experience from a narrative and aesthetically fetching yet legible point of view. We wrangled something together that works well enough, however for a full product a lot more effort would need to go into the Front End flow design and aesthetics.
Controllers. While the controllers worked, the team encountered a heap of unexpected issues around controllers on different PCs. Deciding to make a console couch co-op experience that might live on the PSN or Microsoft stores brought with it unexpected tech debt that the team didn’t initially anticipate, and that harried us throughout development.
In the Team’s Own Words. To wrap up, here’s a selection of answers surveyed from the team to four questions regarding their experiences creating a fun, playable game from scratch in a single week.
What was your favorite thing about the game jam and why?
“It was fun, fast-paced and motivating to work on a small project from start to finish in 1/4 the amount of time of a single milestone on a larger game. Watching quick decisions turn into fast results.”
“Working with new people and seeing how they work.”
“It felt like a vacation while still making games. It is a golden chance to make a game with so much freedom.”
What could or might be done better or differently next time and why?
“Having more controllers around! Or put in a keyboard play mode that way everyone can play regardless of having a controller. Planning out the environment earlier since that’s what the player sees the most. Felt like I spent way too much time on the characters and guns which were a fraction of the screen space.”
“I think overall things went very smooth and the end result was great, but perhaps more time and focus on the core presentation and mechanics, and less time on secondary systems (those could added to the design wish-list and be reserved for the full game, if it was ever made).”
“I learnt how easy it is for work you’ve done to be derailed or broken as soon as somebody else implements their own work. Not sure what the solution is but it was one of the only small frustrations I experienced. I guess having some rules and tricks on working on the same parts of the project would be good to have beforehand.”
What did you value most about the week?
“That we got to try new ideas, and new methods of authoring assets that would ultimately help us during production of larger games. Also, that at the end of the week, we had a fun game that I actually really enjoyed playing and was proud to have been a part of.”
“All the different things I learnt working in a development role instead of a support role, such as the knowledge gained of how a project is put together and the actual techniques gained from working beside someone in the same role.”
“Rapid-fire content creation. Because there were so many sounds to create in such a short time, and for a very diverse set of clients, it was a great opportunity to further hone my skills as a sound designer.”
Most unexpected outcome from the week, good or bad, or otherwise?
“Game diversity was amazing. Weapons for Atomic Assault were actually fun (they only worked last minute). I actually itched to play Atomic Assault all the time.”
“While not unexpected, I was consistently shocked by the quality of work on display (within the context of a game jam).”
“The overall polish of every game was very impressive. It’s amazing what a solid group of focused individuals can achieve in just a week. =)”
Four teams. Four projects. Four games that each and every one showed well during the company review that following Monday afternoon, replete with well deserved beers and cheers.
Thank you for taking the time to join us on our journey recapping how we jammed and what we took away from the process. Having a project that is actually fun to play at the end of the week, one of four delightfully different games produced that week, is something so sock hop too like Tom Cruise in Risky Business, just slipping and sliding some solid celebration. Cheers!
Article by Ian Christy
Atomic Assault Team Credits
Ramón Zárate Sáiz
Audio by David Renn and Crystal Lau
The next game is a turn-based tale of light and darkness. Read it here!