Chambara Mid-Mortem #1

WEEK 3, DAY 4

Things have been going at a good pace for Chambara right now, I bought us a website recently, which you can find at http://www.chambaragame.com. Our second set of deliverables, marketing materials for programs for the ProtoPlay festival, is due early next week. We have a good prototype done and recently finished up our very first public play test, and are planning on doing a public, internet play test within the next few days. Very soon, you’ll be able to download and play the current version of Chambara on any Windows, Mac, or Linux computer, provided you have a supported USB controller and a friend to play with.

I want to do something like a standard games postmortem for this project, but write it during active development, rather than doing so after the project is done. I believe acknowledging our mistakes and successes will let us learn from our issues faster, allowing us to course-correct better during the process of development.

An amazing dodge and comeback.

WHAT’S GOING RIGHT

1. Thunderingly Rapid Prototyping

The first week of development was the most intensive. Having been accustomed to crunch time while juggling classes and development on The Pilgrim, we hit the ground running at a thundering, breakneck speed, arriving earlier and leaving later than most other teams at Dare to be Digital. We had a prototype up and running by the second day, which allowed us to see our ideas in action very quickly and better understand what does and does not work for this kind of game. We revamped movement and created our own custom character controller and a large number of test levels to learn how to design interesting, exciting action.

2. Experimentation

Much of the existing knowledge about level and game design is not applicable to the kind of game we’re making. We can’t guide our players with lighting, paths, and textures, and weapon balance is not a matter of balancing numbers on a spreadsheet. The Counter-Strike “Figure-8″ loop is totally inapplicable for what we’re trying to create, rendering a lot of existing design writing and talks in a state of limited usefulness. This leaves us to discover what works and what doesn’t through our own experimentation. Exciting.

3. Fast Development & Testing

The best part about our workflow is that texturing and UV-mapping objects is totally unnecessary, making our asset pipeline extremely fast. By constructing our levels out of primitives, we are able to construct testable levels in hours rather than days. The benefits of this agile workflow are innumerable, and has allowed us to reach a polishing phase in a matter of weeks. The development plan that we established during the Spring has been totally burned through, leaving us tens of hours ahead of schedule. I expect that the game will be in a state where we will be comfortable showing it to the public by late next week, and I’ll move forward on creating a web presence for this game on indie games communities and submitting to festivals like Fantastic Arcade.

Our block mechanic

WHAT’S GOING WRONG

1. Unified Artistic/Ethical/Thematic Vision 

During preproduction, we didn’t see the value in establishing guidelines for the kind of game we were trying to make. We didn’t write any design documentation, we didn’t establish an Art Bible, nor a vision statement. As a result, we’ve spent the last several days in conflict about the thematic direction of the game. There are some who want Chambara to be an edgy-cool game inspired by the best elements of Batman Beyond and Samurai Jack (our original inspiration), while others want to create something cute, goofy, and playful, while others want to create something subversive of the oppressive heteronormativity inherent to the form.

These disagreements have slowed down production, and nailing down a character design was a process that took more than twice as long that I hoped it would. Retrospectively, establishing that vision prior to development and agreeing that the project is a shared effort between all of us would have saved us much time and frustration.

2. The Doldrums

I see the job of producer as an ultimately personal one, assuring that the participation of each team member fulfills their own personal needs and that they’re always working on something interesting to them. A disproportionate distribution of participation in a project is harmful, and being tasked with nothing to do while other team members are heavily involved isn’t fair.

Granted, this issue comes from the fact that some of our time was spent puttering around waiting for certain tasks like character design and controls to be finalized by another team member to be completed, removing blockades on progress. So I expect things with move much more smoothly later on, though I want this to be something that we are very cognizant of.

3. Unclear Milestones

Because we burned through our development plan, we find ourselves far ahead of schedule. Our core feature list is more or less complete and the prototype has been proven to be fun and accessible. So the path onwards is unclear. Features are envisioned and implemented on the spot as we wander around, trying to figure out what we can do to take this game further. We’ve been considering new maps and game modes, but we can only go so far before that extends the list of needed sound assets far beyond what can be created and implemented in time. I’ve worked with metrics and outreach to communities like reddit indiegaming, but I feel that such measures are unwelcome by my teammates. I am interested in working with cheat codes, game modifiers, or easter eggs, but will need finalized decisions about UI and design before I take that on.

tl;dr, Scotland is beautiful.