next »

[dmcondolora]

Hi, I'm David, Designer & Programmer of the husband-and-wife team Brain&Brain. Our first game is Doggins, a quiet adventure that follows a dreaming terrier's battle of wits with a villainous monocled squirrel. It's a point-and-click adventure made for touch, with a focus on visual storytelling and non-traditional puzzle design. (More on the design philosophy here.)

We released Doggins on iPad in March, and the response was pretty amazing: Apple featured Doggins in "Best New Games" and "What We're Playing", it was nominated for the SXSW Gamer's Voice Award, we showed the game at PAX East as part of the Indie MEGABOOTH, and have had great write-ups from sites like Kill Screen and Artistry in Games.

So why the DevLog? After three months as an iPad-exclusive, we're bringing Doggins to Android. And it hasn't been as simple as I'd hoped. A DevLog will help sort my thoughts and keep on track, provide insight for people doing the same thing, and hopefully keep others from making my mistakes!

As this is going to be focused more on technical challenges than game design, here's some technical info:

Engine: Corona SDK
Language: Lua
Software: Sublime Text 2, Pixelmator, Sketch, Final Cut Pro X, Compressor
Size: 334 MB

First conversion challenge: cutscenes.

[dmcondolora]

A few years ago my wife fell in love with traditional hand-drawn animation, and started studying how it was done. When we started Doggins, it was important to both of us that a good portion of the animation was hand-drawn. So she sat down to do her first ever piece of animation, which ended up being Doggins' walk cycle:

Her drawing studio.


Onion-skin of the animation on paper.


Cleaned-up and vectorized!

You can read more about her process here. While we loved the hand-drawn approach, it was extremely time-consuming and hard to iterate on. We couldn't use it for everything; she was the only artist on the team, after all. So while nearly all of the Doggins character animations were done this way, most of the additional animation was done completely digitally, though still frame-by-frame.

When it came to cutscenes, spritesheets weren't always a great option, so we turned to Apple's Motion and created six video cutscenes. But it wasn't completely smooth: Corona's video support in the simulator is extremely limited, so we could only test on device. And since these are full-screen video files, we had to create two versions, one at 1024x768 (for iPad 1, 2, 3, 4 and Mini) and another at 2048x1536 (for iPad Air and iPad Mini Retina). We also discovered after uploading to Apple (but before being reviewed, fortunately) that despite having Retina displays, iPad 3's and 4's couldn't play back retina-resolution cutscenes. This was a limitation of the hardware, not Corona. So we had to code some fancy if statements, and deal with some slightly blurry cutscenes on high-res devices.

Which brings us to Android. The original videos are h.264-compressed QuickTime files, and while Android supports h.264, it doesn't support the QuickTime wrapper. All of the cutscenes had to be recompressed to MP4 files, still using the h.264 codec. This format is also compatible with iOS, so I don't need to maintain a separate set of assets. One important thing to note is that Android only supports the Baseline Profile of h.264. My compression settings in Apple's Compressor:

I experimented with several bitrates, and 6000kbps seemed right for most cutscenes, with one needing a higher rate and one getting by with a lower one. For the '2x' videos, I just doubled the bitrate; all other settings were the same.

These settings work pretty well on Android; I've been testing on a first-gen Nexus 7, which can even play back the 2048x1536 videos, despite having a medium-res screen. Not bad. There is some stuttering in playback as videos comes to an end, and a one-pixel line at the right edge of whatever is behind the video object, so I still have some work to do. I'm not sure that there's anything I can do about the stuttering, though.

One more thing about 'retina' videos: since the non-retina Nexus 7 can play back retina videos, my code assumes that devices with a DPI of 240 or higher (hdpi devices and up) can play retina videos. This is a bit risky, but as I can't test on many devices and I don't want to completely drop retina video support for Android, it seems like the best approach.

Finally, you can see some Doggins cutscenes in action in our

.

Next: custom fonts!

[dmcondolora]

Doggins doesn't feature a whole lot of text, probably because we intentionally steered clear of dialogue trees and relied on visual storytelling. That being said, the user interface still has some text, as does one of the puzzles; we used custom fonts for these sections of the game.

Corona has a peculiar way of using these fonts. For iOS devices, you create a text display object, and specify a custom font using the font's Mac OS X system name. The simplest way to find that is by double-clicking the font file in the Finder:

Calluna Sans, from exljbris Font Foundry.


Aldous Vertical, from Monotype.

The font name is in the title bar of these images. As you might expect, it differs from the filenames: CallunaSansRegular.otf and ALDOUSVT.TTF. So creating a text object in Corona using one of these fonts looks like this:

Code:

musicLabel = display.newText("MUSIC", 0, 446, "Calluna Sans", 18)

That's great for iOS, and is how we originally coded our use of custom fonts. But custom fonts on Android require you to replace the "Calluna Sans" above with the actual filename (minus the file extension), in this case, CallunaSansRegular. I didn't know that, so the first time I loaded up Doggins on a Nexus 7, the Main Menu looked like this:

It's subtle, but that's the native system font on the right, not Calluna Sans. I could solve this by checking what OS the game is running on and using the appropriate custom font syntax, but I didn't want to do that, nor did I want maintain two codebases. The solution is a simple one: rename the font file to match the font name. CallunaSansRegular.otf and ALDOUSVT.TTF become Calluna Sans.otf and Aldous Vertical.ttf. After I did that, the Main Menu looked great on Android:

Next: audio!

[laxwolf]

Welcome to the tigforums! I beat the game at Pax East if you remember me. Can't wait to see inside the development.

[dmcondolora]

@laxwolf: Awesome, thanks for playing it at PAX! I'll do my best to keep updating this thing and giving insight into our development process. Thanks for your interest.

[dmcondolora]

Here I sit, the real Doggins on my lap, taking my second stab at this post after the first was lost to the aether…

Like so many others, we 'saved' our audio work for the end of the Doggins development cycle. This neither encouraged good sound design nor a sane schedule, and quite honestly, I should have known better: my day job is in films, and I've done a good bit of temp sound design for animated features. I know how important audio is. When we finally did start dropping sounds and music into the game, the change in tone was palpable. The world became alive, a real place.

The Takeaway: Start sound design when you start your game. Audio is just as important as your game's visuals.

People sometimes seemed puzzled by the headphones at our SXSW booth. "You call it a quiet adventure—does that mean there's no sound?" No. No, it does not. Photograph by Richard Boeser of Sparpweed.

Doggins follows a simple multi-track audio layout:

1. Hard effects (footsteps, drawers moving, gum stretching, etc.)
2. Ambience (room tone, wind, electric buzz, etc.)
3. Music

To help provide separation, hard effects are typically mono, while ambience and music are stereo. We often have more than three channels playing at any given time, but this gives you an idea of our simple sound design philosophy.

A lot of our sounds came from a library, but many of the hard effects were recorded by Brooke around the house:

Here she's testing what it sounds like to spin a toilet paper roll (a sound that was dropped from the game). In the background is the recording setup: an Audio Technica shotgun microphone on a boom pole, running through an Apogee JAM into GarageBand on a MacBook Pro.

The sound of Doggins sniffing is the game's inspiration, our real-life Doggins, Oliver:

While the game has no dialog, everyone's favorite henchman, The Giant Crat, does make a few vocalizations. We decided early on that Brooke would voice the characters in the game, and while she wouldn't let me post the unprocessed recording of her as The Giant Crat, here's a clip of the processed in-game audio; just use your imagination.

I initially did my sound editing in Soundtrack Pro, but it crashed frequently due to its age and incompatibility with the latest OS X release, so I eventually migrated to Final Cut Pro X. This greatly enhanced my workflow, and I hope to do a post on how I used Final Cut Pro X in tandem with Compressor in the future. The audio was exported in CAF and AAC formats (we used uncompressed CAF files for looping audio, as compressed files exhibited a 'click' when looping, a known issue in Corona), integrated into the game, and the rest is history.

If we had planned ahead, that would be the end of this post. But, like most things audio, we didn't. It turns out that CAF and AAC audio files are not compatible with Android; a conversion is in order. I haven't done it yet, but I'll be converting all of the uncompressed CAF files to WAV, and the compressed AAC files to MP3. Both WAV and MP3 are playable on both iOS and Android devices, so once again I won't have to maintain a separate set of assets. After a careful set of find-and-replace operations in my code, the new audio should "just work."

I'll let you know how it goes.

[dmcondolora]

Taking a break from development, I'm super excited to announce that Doggins was selected for the Indie Prize Showcase at Casual Connect in San Francisco next month!

We'll be showing the game there from July 22nd - July 24th, so if you're in the neighborhood, come say hi!

Also, Doggins was recently reviewed by GrabIt Magazine (a great digital magazine covering iPad games), and they're doing a giveaway right now. If you have an iPad, go nab a free copy of Doggins while they last.

Still in the process of converting audio files, more on that in the next few days!

- David

[Slader16]

I'm really loving this art style, following! 

[dmcondolora]

@Slader16: Thanks a lot! Brooke did an interview with Artistry in Games that includes lots of concept sketches and process info, if you'd like to know more: http://artistryingames.com/doggins-an-interview-with-brain-and-brain/

[Slader16]

Thanks for posting the link, I love reading stuff like that! 

[lobstersteve]

Adorable walk-cycle 

[dmcondolora]

@lobstersteve: Thanks a lot! Here's a video of the pencil test, so you can see its starting form: http://blog.brain-and-brain.com/post/77183149462/brookecondolora-pencil-test-for-doggins-walk

[Slader16]

I'm really liking it so far, just can't figure out how to get past The Giant Crat

[dmcondolora]

@slader16: Thanks! If you get really stuck, feel free to send an e-mail to support [at] brain-and-brain.com.

We've been out of town for the past week, so the DevLog has ground to a halt. But fortunately progress hasn't; I should have a new update early next week.

[dmcondolora]

It's been quite a while since my last post, and we've been busy. Just…busy doing things besides posting. For example, this:

Today, we're releasing Doggins for iPhone/iPod touch! I know, that's not Android, which was the topic of this devlog. While working on the Android version, I did a lot of optimizing for smaller screen sizes and varying aspect ratios (more on that in the future). Once I did that, I realized that an iPhone version could actually work pretty well, and we shifted gears to polishing it up for iPhone. It made more sense to keep Doggins an iOS-exclusive game just a little bit longer.

The good news (aside from Doggins coming out on iPhone, hurrah!) is that the Android version is basically done, save some testing and setting up of storefronts, and we're planning to release it at the end of September. I'll post some more updates on that process once I have a few days to recuperate from the iPhone release.

Oh, and we have a new trailer!

[dmcondolora]

One of the challenges of Android as a platform is the wide variety of screen sizes and aspect ratios. While most devices seem to fall into the 16x9 or 16x10 spectrum, there's really no way to know what kind of screen someone will be playing your game on. We originally designed Doggins for the iPad, which has a 1.33x1 aspect ratio at 1024x768, and when we finally decided to do the Android and iPhone ports, we knew that we couldn't spend a lot of time remaking the art to fit a wider screen. That left us with two options: pillarbox or crop.

Pillarbox

Pillarboxing is a technique that scales the image to fit the screen, and places black bars to the left and right of the image. It's what you see when you watch an episode of Star Trek: The Original Series on your huge widescreen TV. Thinking that cropping would obscure important game information, I decided to try pillarboxing first. it didn't take long to make the necessary changes. Here's what Doggins looks like with pillarboxing, on a simulated Kindle Fire:

As you can see, it feels…cheap. If I bought a game for $3.99 and it looked like that, I'd instantly know that the developers didn't really care about the presentation of their game, or their players on that platform. Not a good first impression.

Crop

Still unsure if it would work for the game, I decided to try cropping. In this case, the image is scaled to fit the width of the screen (in landscape orientation), cropping the top and bottom evenly. However, in this case I anchored the bottom of the image to the bottom of the screen, cropping only the top. The result:

Much better use of space, and a much more professional look. As an added bonus, on a small screen (like that of an iPhone 4S), filling the screen's width results in more readable text and a larger image; you just lose some of the top. Fortunately for us, we designed Doggins to have a lot of headroom. This was to give the environments a sense of scale, making him feel smaller and more 'dog-sized' in any given location. While we lost some of that sense of scale by cropping, what w didn't lose was any game art that was vital to the player.

Overall, cropping worked well. There were still some challenges, namely how to fit a large number of inventory objects onto a much shorter screen. Here's the inventory running on an iPad:

To make it fit on shorter screens, we dynamically change the inventory height, icon spacing, icon size, and text size based on the screen height. It was a bit tricky finding the right balance between spacing and readability, but it worked out in the end.

For our next game, we plan on designing our artwork to fit different aspect ratios from the start, with a more dynamic engine and greater flexibility. Lesson learned!

- David

[dmcondolora]

Today's the day: Doggins has launched on Android! Get it from your choice of storefronts: Google Play, Amazon Appstore, itch.io, or the fancy Humble Widget at dogginsgame.com.

That wraps up this DevLog. We still have ideas for the future of Doggins, but for now, we're moving on to stranger seas…

Thanks for reading!

- David