All-In for Briar Heart

I’ve been working a lot on Briar Heart lately, and been having trouble posting regularly on this website. I’ve decided that I’m going to consolidate and since I’m focusing solely on this game project, that I will also be putting my public relations into a more focused effort. For the time being I’ll be making updates to the game’s IndieDB page and trying to increase activity there. I’ll be working towards making regular (weekly-ish) video dev logs and posting them up there. Twitter will continue to point to whatever’s new and interesting, and I will work to be more human and present on it. :P

For now, you can play the most up to date web build here! Any and all comments and feedback is very much appreciated! :D

Links again:
Web Build
IndieDB Page

Presenting Briar Heart

Briar Heart is back in action! …and in 3D no less– We’ve re-approached the task of creating a metroidvania (adventure-platformer) in a 3D space. In 3D anything is possible!tm We are currently working on character movement and the play environment.

BriarHeart Desura

The game will be updated and maintained on Desura (pending their approval) and there will be videos of gameplay and progress posted on Desura in the future. :)

IndieSpeedRun #1 – Guest Post-Mortem

Benjamin Johns– creator, provisioner of fine word-smithery, great guy… brings you his verbosity in the form of post mortem on our game–

Introducing this website’s first (but hopefully not last!) GUEST POST… mortem. :)

———————

Ah, retrospective. The last refuge of the lazy time-traveller.

All in all, I was disappointed by the high level of quality in the Indie Speed Run submissions. Like most people, I enter competitions so I can outperform the average and then feel smug and self-satisfied, and this particular batch of games is upsettingly competent and well conceived. The vast majority of these games fail to fall into the “laughable failure” camp from which I can suck the sweet juice of superiority. There are a few games that rank as legitimately inspired, which is just annoying. A handful cross the line into “games I would pay money for,” which is frankly infuriating. That’s no good for anyone.

So, after spending the last week basking in the warm glow of having made a thing I am no longer responsible for supporting, like my many illegitimate offspring in Indonesia, I took time out of my cognac swirling while staring into the fireplace, and logged on to Drizzly Bear to give Scubasaurs a fresh play through.

Fortunately, it’s excellent, and I once again have an opportunity to feel Better Than Other People. More specifically, it sets out to be a Pokemon-battle style Rock-Paper-Scissors, and it accomplishes what it sets out to do with such panache, affect, and polish that it’s difficult for me to imagine a game made in 48 hours that would be a BETTER Pokemon-battle style Rock-Paper Scissors. Other games may have more ambition, or more interesting ideas, or be more original; sure, fine. We picked a mountain and climbed to the top, and that there are other, taller mountains in the world does not change how my cognac tastes or how many sherpas died bringing it up the mountain for me.

Being a keen Analyzer of Experiences, I’ve broken down our successes and failures into categories with underlined titles and what have you. But it is Too Long, and you Will Not Read it. I understand. In essence, we did a great deal of things right, and what’s more, we were punctual in our correctness.

Cheers,

-Benjamin Johns

What Went Right:

Scope: The clear-cut, runaway success was our timing: we set out to make a game on Friday afternoon that took into account what we had at our disposal, developed to a modest plan that gave us something that was pretty shippable by late Saturday evening and had a comfortable backup-build by Sunday morning, and rolled a testable release out Sunday afternoon, featuring all of our core features, and most of the more approachable items on our wish list.

Some of this was cautious design: we set out to make something simple and achievable that wouldn’t require any Herculean all-nighters, and that was the product we delivered. But it also comes down to disciplined management. By midday Saturday, Sean was shoving every non-essential item to the backlog, and we were diligently walking away from “good enough” systems that still needed polish to tend to critical pieces that didn’t exist yet. The result was something that was recognizably a game very early on, with hours left to throw in the team’s most wanted.

“Rock Paper Scissors” Design: We tentatively landed on a Pokemon-esque fighter before we started, and had talked about a very simple, Rock-Paper-Scissors strategy for the battle system, where the gameplay decisions come from the player having to choose between the cost of changing out their character for a more effective one versus the cost of continuing to get pummelled in a poorly matched battle. This decision, to focus on a simple, comprehensible interrelationship in the battle system, got us to an effectively balanced three-character setup on the first try.

Knowing how the system works, it’s clear when one character is worth the switching cost and when you should stay the course. While I don’t think this is as clear to players as it should be, the fact that it works as intended justifies the wisdom of deciding on a simple, clear-cut battle model.

Style and Storytelling: As soon as we settled on “dinosaurs in a submarine,” Sean tasked me with writing a story, which he did because he knew I love doing that sort of thing, and which I did, despite my misgivings, because I really do love doing that sort of thing, enough so that I didn’t really care that having a story would almost certainly make the game worse.

The overwhelming majority of Indie Speed Run games with stories that extend beyond the most threadbare “go get the coins!” pretense are awful, usually shoved down the user’s throat in the form of a long tedious paragraph or four of exposition. I have a high tolerance for these things and even I have walked away from games with an unskippable scroll about the escaped souls of the ancient Bara’thoom needing to be reunited with their husk-hosts and blah, blah, blah.

So I would’ve been quite happy if our “story” consisted of the splash screen (“Well, shit”) and an animation of dinosaurs jumping in a submarine. There’s a meteor, they’re escaping in a sub; that’s some Angry Birds level motivation right there. I was happy to write dialogue, but was ready to yank it from the game as soon as it turned out to be predictably tedious.

But it didn’t feel tedious, and having just now replayed the game, it still doesn’t. In fact, if the game had just been three battle sequences without the interstitials, I think that would have suffered from the lack of rhythm. Sean’s decision to put the character’s heads on screen, and the quite excellent background art, actually makes the story feel like a story, and while it’s not as funny as it seemed in the moment, I still think it mostly works, and much better than a dreaded block of expository scene chewing. “Dinosaurs using submarine to escape meteor” isn’t a worse story than “ADD raptor, apathetic shark, and homicidal jellyfish battle their way to the Marianas Trench,” but I still consider the story a net gain, which is better than I had predicted at the onset.

Pixelart: Pixelart in this kind of competition is basically a cliche. But it’s hard to imagine any other style of art for concrete character types (e.g., “shark” instead of “amorphous gray blob generated by particle fountain”) having the same charm while getting pumped out on the same timeline. If anything, a competition like this emphasizes that there’s a big gulf between good pixelart and bad, in terms of legibility, personality, and sheer artistic worth. Sean’s art has depth and richness, and the animations tell stories. It worked.

Camshake: A little callout to an effect that carries way more than its implementation weight. The animations in general contribute a huge amount of personality (the swap-out animations make a cheap mechanic look much slicker, the raptor’s head-turned-away scratching motion absolutely makes the character, and the shark’s Pile Driver is one of the highlights of the game). But Ian’s late addition of the cam shake brings all sorts of gravity to the battles. The game felt flat without it, but I don’t think Sean or I really missed it until we saw what we were missing.

What Went Wrong:

Play Balance: I think it’s important, in this kind of experience, to keep things tilted in favor of the player finishing on the first try, since most players faced with a list of two hundred games aren’t going to give any game a second play-through. That said, the “battle lineup” (one shark, then two jellyfish, and finally two sharks and a raptor) is wrong in almost every conceivable way.

First off, it means you enter the first battle with no need to switch characters. There’s no REAL chance of you dying in the first battle (you’re three against one), so we should have set you up with the Raptor (poorly matched to fight the Shark), so continually attacking would cause you to die and replace your character with someone who would perform better. “Ah ha!” the player might say. “Some characters do better against sharks than others!”

The second battle, against two jellyfish, is better conceived (you get a lot of time fighting this one character, so you’ll probably notice that some things work better than others), but since you start with a jellyfish, who singlehandedly dispatched the shark last time, you STILL have no motivation to switch fighters. The easiest thing to do is to just hammer the Steal Life button for a long while, and after that, either replacement you pick for your jellyfish will pretty quickly finish the job. At any rate, there’s virtually no chance of a strategy putting you in even moderate jeopardy, and so it’s quite possible to get this far in the game without having any idea how anything works. Not a recipe for engagement.

And then there’s the final battle: With two sharks and a raptor, it’s not a total pushover; it might even be possible to lose without just “switching players” every turn to throw the match. But it still falls short of a genuine challenge. Ideally, I think this would have been a three versus four battle; in the imaginary universe where we’d taught the players the rules by this point, they’d have to actually demonstrate an understanding of them in order to finish the game.

The irony is that this sort of lineup-tweaking, thanks to Ian’s thoughtful battle system design, is shockingly easy. Like, rearranging three lines of code easy. But we were focused on polishing the effects and presentation, and we let this slide.

User Interface: In a sense, I think our controls for this game were brilliant, because unlike almost every other game in the competition, they require absolutely no explanation. Start clicking buttons, and just keep clicking buttons until the game ends.

But consequently, a huge amount of the on-screen real estate is given over to the three buttons and the text explaining what’s going on in the match, and it comes off as plain. The console scroll never changes color, and rarely changes size. We tried to gin it up with more flavor text, but this had the unfortunate effect of creating an even more overwhelming stream of information, much of which was now not even informative. The font matches the art style, but it’s small, and that doesn’t help its readability.

It would have been nice to put damage indicators above the characters in the play space, to make better use of color in the console box as a means of indicating things like Character Names and Damage Amounts, and to generally make that portion of the game more fun to look at. All of these items on their own are clearly “polish items;” but this is a UI driven game, and the UI isn’t quite fun enough.

Audio: Sean recommended BFXR for the sound effects, and while it took a little while for me to learn the ropes of the interface, after I got the gist of it they worked like a charm. On replay, I think the vast majority of the sound effects sound great, work with the animations and are well matched to the art style. Sean’s last-minute battle music composition adds a feel of immediacy to the battles and really suits the underwater setting.

But the big problem here is the mix. The effects are all over the place; some are reasonably loud and others are quite soft, and because they’re all played back at the same master volume to keep them from overwhelming the music, a number of them are barely noticeable unless you have the audio on your computer turned all the way up to max. As a result, most people playing will experience a lot of times they’ll expect a sound effect but won’t hear one.

Personally, so many of my experiences on the web with audio are unpleasant that I tend to make sound effects quieter out of a sheer sense of courtesy. But for a four minute game, players are willing to stomach whatever audio you throw at them. We should’ve burned the audio into the files louder and let the players vote with their volume knobs.

—————————–

Benjamin Johns has worked in the games industry for twelve years, as a test engineer, lead programmer, producer, renegade copywriter, and Gamestop Game Associate.  He is currently programming with Visual Supply Co and is a Senior Fellow at the Ottery Bar Institute for the Advancement of Bad Ideas.

IndieSpeedRun #1 – Post-Mortem

Bam! Another game in the bucket o’ games-mountain of game experience.
– man gotta stop hitting the metaphor so hard.

Tools Used:
- Unity 3D
- 2d toolkit
- Photoshop
- git
- bfxr.net
- awesome teammates

Team Members:
- Sean Gubelman – @gubester – Code / Art
- Ben Johns – @thoreticalb – Code / Copy
- Ian Cox – @dyselon – Code / Design
- Kristen Bornemann – @kristen_ – Production / Scope

High-Level Summary:
Had a great weekend!
Lots of firsts–
- First time working with a team on a 48hr jam
- First time shipping a unity game with a team
- Everyone else on the team’s first time using unity

I spent most of my time during the weekend drawing / animating, which was great exercise for me.
We were able to really work well together– Solid understanding of source control (git specifically) helped the team succeed in what I thought to be the biggest risk factor for the weekend: a team unity project. Also surprisingly, we managed to have a great team composition even though everyone was a ‘programmer’. Having a really strong designer and writer on the team was really awesome. I’m just glad that we were able to deliver on their best skills. :)
It seems like everyone had a really great time, and I’m excited for the next occasion that this team puts together a game!

- Sean

My Time Breakdown:
16.06hrs -> Art
04.41hrs -> Project Management
02.79hrs -> Programming
01.31hrs -> R&D
00.88hrs -> Audio
00.41hrs -> Public Relations

25.86hrs -> Total

Game is here