Ultrablamtacular!

I know I keep talking about game development and software engineering. Sorry. But they’re two activities I engage in and when I find areas of similarity between them, it sort of catches my attention.  

 This week we were short a player for our regular game night. That meant we couldn’t play our regular games (I’m running The Changeling Campaign That Will Not Die, and R. is running pre-reboot V:tM). And since Ultrablam is in between playtestable states right now, we couldn’t run that, either. So, I turned to my trusty shelf, and got down a game that I’d gotten for the holidays (or my birthday…I forget) and we’d never played. It was a game that nobody, even my-normally-patient-with-rules-self, enjoyed, one so filled with antitainment that we actually quit before we’d resolved a single challenge. 

Let me point out that my group will stick through antitainment if there’s entertainment to had. We played the awful ready-made adventure for Fireborn and then, having realized how badly that sucked, we rewound several weeks worth of play, declared that none of it ever happened, and started again. That game lasted several happy months. We played Scion for god knows (pun intended) how long, clawing our way through the truly awful character generation to get to play in the really compelling universe, only to find that we hated the combat system, too. There was enough coolness there that we kept going. Later, we tried a different system with the same premise in a short-lived, but much-loved game we called “Suck it, Scion!” I just want to illustrate that my group A) is willing to try wildly different game systems and B) are not shrinking violet whiners who quit when they don’t immediately love everything about a game.

So how exactly does this relate to software engineering? Well, in software, good solutions for common problems have been gleaned from years of experience and zillions of lines of code. Those have been codified into solutions called patterns. (On a cool but unrelated side note: The Portland Pattern Repository’s WikiWikiWeb is the world’s first wiki. First whatevers are cool and wikis are cool, too. So that’s pretty much double cool.) Similarly, when there’s a disastrous example of how to not do something, that’s an antipattern – a negative example or cautionary tale. Well, the game we played (No, I won’t say which one. Maybe your group will just love it.) provided a valuable antipattern. And that’s how this story relates to software engineering. If you were waiting to hear how I wrote code to generate examples automatically or something, I’m sorry to disappoint. But I learned a lot about what not to do with Ultrablam, and by contrast, learned some things that I must do.

So what went wrong?

First of all, this was supposed to be a relatively light game, story-oriented (I know there’s a Story Games movement out there, but I don’t frankly know how to tell a Story Game from an indie RPG, so I won’t presume.) and suitable for play in a single evening. Well, part of what went wrong was the tone. My players got mad at the game just from the way the author addressed them. Ouch. The tone was, to our perception, micro-managerial, even specifying what tense we should play various scenes in. The group reacted very badly to being told so minutely how to play.  

Second, our supposed four-hour single-session game was two hours in before we got to a scene, just from the “light” character and scenario generation. By then, everyone was frustrated in large part because the rules seemed to take a very long time to tell us very simple things. I later found a section of rules summaries at the back of the book that could have saved us a lot of time, a lot of frustration, a lot of anger, and possibly even rescued the game. But there was nothing in the early part of the book that said, “Hey, if you know what you’re doing, you can just head on back to the summaries on page XX. Come back here if you don’t understand something.” And I had read the early parts of the rules beforehand, and did my best to smooth things out and explain without just quoting the book verbatim.

Third, this was supposed to be rules-light, story-oriented system. But it required a lot of record-keeping in play. You had to record when each attribute was used, how many times each bonus was applied, how hard each challenge was. OK, we might have been able to deal with that – after all, RPGs generally require that you maintain the game state during play. But what really pushed one player over the edge from, “This looks complicated,” to, “This is awful,” were rules that seemed to arbitrarily dictate how you could play your character. If you built a dexterous character, based on the idea that he’d defeat obstacles by going over or around them, rather than through, you’d find that the rules dictated that you couldn’t use your dexterity whenever you wanted, but had to cycle through every attribute, even what you’d chosen to be bad at, before you could be dexterous again. See onerous record-keeping above.

So what did I learn from all of this?

First, I learned that I need to restore the original tone I began with – Ultrablamtacular started out as almost a letter to my group to tell them how to play. It turned into a more formal document as it got longer and more complex and more complete. I don’t think I’ll have any trouble going from  sonorous to light in terms of tone – it’s much more of a struggle for me to put a serious face on things.

Second, I learned that I need to provide instant gratification. I’ve moved to the layout stage, and I sure am glad I discovered this now. I’ve got to provide a path through the book that skips explanations – as well as paths that provide them. This game experienced has entirely reshaped my vision for layout – and given me a way to use an idea I had a while ago but couldn’t really fit into the new, somehow seriousified Ultrablamtacular. We might have enjoyed the antipattern game if there had been a section that just said, “Do this…” instead of always saying, “Because of <reason we don’t care about right now>, do this…”

Third, I learned that I have to make sure that every thing that you have to keep track of in Ultrablam is A) as simple as possile (I’ve done a lot of work to make this the case so far) and B) absolutely, positively required to keep track of in order to play the game.

Aftermath

In general, I think the whole thing worked out pretty well. I had been approaching the antipattern game with some trepidation because it seemed to share significant conceptual foundation elements with Ultrablam. In fact, what I had intended to do was play the game and then ask the group, “So. Do I need to bother finishing Ultrablam? Or does this game accomplish everything I set out to do?” As it was, it was only a few minutes before the first comments like, “This sucks! Ultrablam does it a lot better!” started coming, and not from me, even. So that was a geniuinely gratifying experience even in the midst of what was otherwise a game-night disaster.