Another TOJam completed, another
post mortem from a designer perspective.
This year's team is a mish-mash of ex-coworkers and friends, and same as last year, I was more than happy to bail out of programming if someone else was taking charge. Personally, unless it's a system I fully understand, I don't know how useful I can be in a 3 day sprint. Therefore, just like last year, I ended up "working" on a team of 5 as a "dedicated designer".
The jam's theme was "uncooperative", and a series of e-mails were exchanged back and forth about what kind of a game we could make. My approach to it was really laissez-faire, letting other people do the thinking and just filtering down what could work (and actually end up writing content for a few of them to see what they could go). I guess for me, coming from a more technical side of design, my focus was on the constraints and limitations than the "what ifs"... here's a quote from my first two e-mail replies:
b) What kind of limitations will you have/need (Lucky, Juan, Nozomi)? At least from my end, I'll be working with what you can come up with. No point in suggesting an FPS if you're hacking away at other things. Ditto with the art side, if there's a specific style or ideas you guys want to work with, might as well point that out.
c) Ideas working with the theme? I'm all ears right now. The quick thinking idea that I have at the top of my head is a quick dungeon crawler/brawler, with a "inn/shop" between every stage. However, the "uncooperative" part is that the inn shop owner is a dick and sells you the wrong things all the time.
If you take Castle Crasher as the example, then you're dealing with some form of layering even as a side-scroller. You may run into some sort of z-ordering issues, and more about how to define what looks right/is in context.
The final game "direction" was to go with a side-scrolling 2D beat-em-up with a "saboteur" mechanic: one player is a spy, in the game to sabotage the other three. The game's combat and mechanics are in place to let them to hide their tracks.
Implementation
On day one, many "up in the air" decisions were made, for better or worse. We ended up with a strict 2D perspective (not multi-layered like Streets of Rage); some combat was decided, along with enemy types; a quick level editor format was decided (image with pixel coordinate indicating object/enemy placement); specs on UI, spawning systems, and logic were hastily thrown together, some with far reaching consequences (like the image below, where at one point, enemies can collide into players, applying a force so great that it crashed through the floor)
The push to completion
Unlike last year's game, where it was number heavy, almost all the hard "design" work was done, and the soft design work such as balancing and adjustment would have to wait until a playable version exists. For quite a bit of the second/third day, I wasn't doing a whole lot, and actually began messing with Garageband for some sound effects. Of course throughout all of it there were quick snap decisions for things that was being created/implemented, but nothing too critical.
By the end of the second day, we started looking at the state of what we have and started quickly considering what can/needs to be dropped. On benefit of writing a design doc with optional checkpoints is that you know which milestones are hard requirements, and which ones can be dropped without breaking things. In the end, one of the key saboteur mechanics was dropped due to not having enough time.
Getting away from the core
Throughout the three days, there were numerous points where we kind of asked whether the game was getting away from the intended theme. In retrospect, probably. However, I also do think that in trying to fit such an unconventional theme, it's going to be difficult to get it properly working, playing fun, and be on point. For most people who came by to test the game out, it was a serviceable brawler, with a somewhat confusing "saboteur" reveal. It was hard to grasp what made the game un-cooperative outside of the friendly fire. We had speculated that the game would need at least two playthroughs for people to get it and for it to be interesting, and in our last game where all of us knew our proper roles, it actually clicked.
Lessons Learned
Jason (the other programmer/designer) had jokingly (I think) said to "throw out all the design docs". Sometimes I'm tempted to do so, especially at a gamejam because it's suppose to be organic, but at the same time it could lead to terrible breakdown in communicating the direction and specifics. How much space should the HUD take up? How many attacks do you need? How should things get triggered? I imagine that without a quick doc, we wouldn't have been able to start day 1 at full capacity.
On the other hand, I've noticed that some of the initial ideas I had are still rooted in large systems. One example of this was my initial idea of blocking out levels, and using it as a collision map and a template for the artists to fill it in. On paper, this is a very standard way to make levels, but it also makes level iterations painfully slow.
"Who needs a designer?"
During the jam I've heard that line at least twice, and it pains me to hear that. As a project scales up in headcount, the potential points for communication breakdown increases. An artist may not know how the programmer is going to implement their assets; the programmer won't know what format they're getting, and that's where I honestly think a designer would come in. A designer at a jam isn't about being "the idea guy" (and it's never the idea guy even in the real world), but rather the cleanup guy that fights fires as they pop up and keeps everything in check throughout the process.
At least that's what I tell myself.
