The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
Over the last eight weeks, I’ve been in Scotland competing in the 2014 Dare to be Digital competition, an international game jam where college teams from all over the world strive to construct a game in a two-month span. The three winning teams of this competition go on to be nominated for that year’s Ones to Watch award from the British Academy of Film and Television Arts.
My team, Overly Kinetic, was nominated for our game Chambara, a binary-colored split-screen stealth game inspired by a Samurai Jack episode. Creating Chambara at Dare was one of the most challenging and exciting times of my life, and definitely a highlight of my career. At our booth at the Protoplay Festival, I saw for the first time, people laugh and smile with each other as they played our game. To think that something I made gave such a positive, loving, experience to people, that’s amazing.
Here are my personal thoughts on the project and how it went.
WHAT WENT RIGHT
1. Preproduction paid off.
Chambara underwent an extensive preproduction period that extended for multiple months. Conceptualization and team-building began as early as January, and preparation for the pitch extended all through early May. The team met for three hours every Tuesday to plan for the pitch, prepare documentation, assemble project plans, consider funding solutions for our flights to Scotland, and conduct physical and digital prototyping. Our Tuesday meeting was often followed up by a weekend meeting where we would conduct research by watching chanbara movies or current anime, as well as playing games like Metal Gear Rising and Timesplitters. Over the course of those months, we discarded as many as three scripts for our pitch video and two project plans.
The result of our extensive preproduction period was an exceptional pitch video and high morale throughout the first week of Dare. Knowing every task we had to do to complete this game down to the hour, we worked game-jam-like hours through the first week and completed a playable prototype within three days.
2. Polished core mechanic.
The intentionality of my previous game, The Pilgrim, was to explore what game feel and character controls could communicate emotionally to the player. The “feel” of a jump can communicate anything from empowerment and joy, to disempowerment and frustration.
To this extent, much of the success of a character-action game comes down to the kinesthetics of movement through a space, which is why it was of utmost important that the “feel” of moving about in Chambara was empowering and playful.
Level design was blocked for a week because we could not reasonably create levels until we understood how players would feel moving through them. Once Alec designed an excellent, fully-featured character controller with some advanced movement features like gliding, walljumping, and blocking, we began to construct levels around those features. Subsequent iterations of that controller would add features such as variable walk speed, remapped controls, and a “squawk button”. Ultimately, the game owes a lot of its success to game feel and the tactical depth afforded by our movement system.
3. Rapid iteration and playtesting.
A mantra of game design is “fail fast, fail often”, which upholds that it is extremely important to have some testable proof-of-concept as early as possible and iron out the flaws from there. The reasoning behind this mantra is that the earlier that flaws with a design are discovered, the earlier those flaws can be corrected, making the process of creating a game an inward spiral of course-correction and continuous refinement. To this extent, we were successful. We implemented, tested, and discarded several of our ideas from preproduction on the very first day.
We ran extensive testing outside of the one public session that Dare to be Digital arranged for us. We treated every industry mentor that came in as another playtester, and studied their play-behavior very closely, down to tracking notes on how they moved their thumbs around the gamepad. Their reactions and feedback would form the basis of what we wanted to build and implement the very next week. Each of us would send builds back to our friends and family to get their feedback, and a comprehensive metrics backend provided us with ample data that we weren’t entirely sure how to interpret.
4. Simple assets.
Building a Chambara map is easy: simply drag and drop cubes, deform them, and throw one of two materials on each block. For a while, many of our environments were constructed entirely out of 3D primitives, which led to some delightful moments when I threw rigidbodies onto everything. For a short time, we had “leveloution”.
Around the sixth week, we determined that we needed to art up the levels to give them more grounding and readability, as well as solve the problem of players not being able to determine where the boundaries of a level were. So we began to construct art assets to replace the primitive cubes and planes that used to build up the levels.
Constructing these 3D assets was shockingly easy, especially given that our dichromatic aesthetic nullifies the need for UV maps and textures. Every asset I constructed was a simple cube with faces cut into it, each of the faces would receive its own material. This pipeline allowed us to create and implement 3D assets in only a fraction of the time it would have taken if we had used any other art style.
5. Multiplayer is exciting to design for.
While I was involved with The Maestros back at USC, I was only working on that project as a community manager. Chambara was my first multiplayer digital game, the rest of my projects being either single-player digital or multiplayer analogue. Working and designing a digital multiplayer game was a refreshing change of pace from the kind of work I’ve done in the past, and making this a project I was really invested in.
WHAT WENT WRONG.
1. Bad timing hurt some components.
Despite all the preproduction and planning we did, something would inevitably go wrong and throw the project off schedule, which is why we designed our game to allow for features to be cut or suffer without hurting the core game too much.
We worked on an asymmetrical schedule with our composer Austin, who was operating from four timezones away. Since we were working on this game full-time and he was working part-time, we inevitably moved the pace of the project disproportionately fast. We would build levels and features and put in requests for sound assets and music faster than he could reasonably create them. There were multiple times where we would request a sound effect for a feature that we would have to cut days later, thereby making him do unnecessary work.
We also planned for a comprehensive UI revamp later in production that we were ultimately unable to do. The main menu seen in the festival build is filled with a lot of issues, making it very inconvenient to set up games and match players to teams. Ultimately, we had to create temporary solutions by revamping the existing menu system and creating UI assets that were not as rigorously tested or refined as they could or should have been.
One of our team members got very sick later in production and was unable to come to the studio every day to work on the game. While we crunched much less than we would typically do during the school year, we still made sacrifices to our health in terms of diet and exercise. Affordable food options in Dundee are limited, and much of our diet came down to refrigerated tortellini and sandwich meat from Tesco, or processed meals from a frozen-food retailer called Iceland.
All Dare teams are allotted 200 GBP to use to spend on production of their game. We were confused as to how to use this money, because you don’t really need much money to make videogames. So early in production, we decided to save that money up for our Protoplay booth, which we wanted to be a welcoming, homey environment where people could come in and play our game and receive a prize for playing.
The American dollar isn’t very strong against the British pound, and expenses in our own currency were far greater for us. A 20 GBP expense was equivalent to a 35 USD one, making us reticent to spend.
Ultimately, we ended up going over budget and had to pay some of the expenses, like branded t-shirts and crafting gear with our own money.
4. Inconsistent theming.
While we spent much of our research phase in preproduction looking at samurai cinema and anime, very little of that influence made it into the final game. Visual tests of our levels over the first two weeks revealed that people associated our imagery with German Expressionist film, with its harsh angles, angsty edges, and dreary colors, which was a connotation that we didn’t find fun or appealing to us. Others said that the visuals reminded them of Frank Miller’s Sin City, which brings up a load of sociopolitical issues that we aren’t prepared to address.
We started art-ing up the levels around the sixth week and giving them life and thematic grounding. Nonetheless, the look and feel of the game remains inconsistent across the game’s five levels. “Glorious Mansion”, our two-player level, brings up European connotations with its red and white color scheme and its ornamental accents and assets. “Neo Tokyo” is a strange mashup of Akira’s late-80s cyberpunk style and utopian metabolist architecture. “Flour Mill” sticks out with its industrial gears, mechanical ticking, and wooden slats. “Mono-Ha Garden” is the only stage that uses cylindrical shapes as its base asset and is inspired by the Mono-Ha art movement of the 70s. “Reservoir” was actually a map that we didn’t have time to finish, and remains constructed entirely out of primitives. A number of silly easter eggs in the hills are its only theming.
We knew that the primary audience at the Protoplay Festival would be children, roughly 7 to 14 years old, moving into the competition, and felt that there were many ways that we could do something very harmful to them, as well as create a problematically racist appropriation. People change through experiences, and since videogames offer experiences, we knew that we could have a very negative effect on the values of our players. I discussed this problem in depth in my previous blog post about the subject.
While we made extensive measures to neuter the violence of the game and spin the mechanical interactions into something positive, I don’t think we did enough. When a mother at Protoplay dismissed our game as “another killing game”, I was deeply hurt. If anyone reacts that way, I don’t think we did enough. The formal systems of games necessitates conflict between players or systems, and to struggle against the structural foundation of the medium is a vast challenge that I doubt that we can pull off. While the magic circle indictates a separation between the world of a game and reality, games and the behaviors that they create through their systems are inherently political expressions. If the values expressed through our content are dissonant with what we believe, then I think that we would be doing something we would regret in the future.
Civilization is a great game because its systems encourage competition between players, creating brilliant emergent narratives. But when those systems in context are metaphor for violence, imperialism, and ultranationalism, I can’t really say that Civilization is a comfortable game once I leave its magic circle.
Which is why a single person calling Chambara “another killing game” is so perturbing to me. If our systems of conflict are construed to be about violence, anger, and confrontation by some people, then what does our game communicate to our players? Do our players leave the experience better or worse?
I think we mostly succeeded, I saw nothing but positive behavior from people who played our game. Kids and adults laughed, smiled, and bonded with each other as they played our game, often shaking hands after they were done. We witnessed no toxicity and had a greater diversity of players than we expected, entertaining young girls and older parents, people underserved by existing games. A father with an autistic child thanked us giving his son something to smile about, which really made our day, and overall, I think we created a lot of love in that festival tent. Yet, I can’t forget what that mother said, “oh, another killing game”.
Nonetheless, if Chambara ended up being the blood-drenched mess of violence and negativity that it could have been, presenting itself as yet another “killing game”, then I don’t think I could accept a BAFTA nomination in good conscience.
We intend to retrieve the rights to Chambara from Abertay University, who manages each team’s IP for the duration of the competition. What exactly we’re going to do with those rights remains to be decided. If we choose to develop the game further, we might self-publish on Steam Greenlight or Playstation Network, or pitch and sign on with a publisher. We will probably solicit our professors for advice on what to do from here.
We would like to submit to indie festivals like Fantastic Arcade, The Wild Rumpus, and Indiecade. It would be fun to travel to games events like EVO and essentially go on “tour” like what Nidhogg or Killer Queen has done.
If we can’t decide, we’ll probably open-source the game’s project files and make the game free to download, essentially donating the game’s source code to the public domain so people can poke through the code and assets and learn how the game was constructed. Open source is a great thing for education, and given Unity’s omnipresence in amateur games, I think we can do a lot of good for the world if we surrender our code.
Period: Production: 8 weeks
Staff: 5 full-time, 1 part-time
Software Used: Adobe Photoshop, Unity3D, Visual Studio 2010, Audacity, Autodesk Maya, Blender, Monodevelop, iMovie.
Budget: 200 GBP