Penumbear Music

For Penumbear, we again enlisted the services of our friend Chris Negrini, who did music for FOUR HATS and OMEGAPIXEL as well as a bunch of music for a few games we haven’t gotten off the ground yet. We approached Chris on a whim while working on our first project together knowing he plays guitar and writes some music on his own. We didn’t realize he actually had scores of chiptune demos and was essentially making video game music for a long time just for the heck of it. Sometimes life just throws things together like that.

Chris did a bunch of tunes combining chiptune music and instrumentation for a fighting game that’s just mind-blowing and we haven’t put out yet. Hopefully you’ll get to hear it at some point soon. For FOUR HATS, being the biggest Paul McCartney fan I know, Chris was happy to indulge a Beatles-esque sound for 6 songs he wrote for the game. Omegapixel used one of the more shoe-gaze songs he’d written for the fighting game as well as a few chiptunes. He also worked on 3 versions of “Tiptoe through the tulips” for our game jam Tiny’s World in a weekend. Needless to say, the guy is amazing. 

For PENUMBEAR he worked on a series of more ambient, atmospheric and strange sounding loops that fit the game quite nicely. We asked Chris (who makes game music as “Negapixel”) to talk a bit about the music process for this game.

With Penumbear due to hit the app store this week it's time for some reflections; today let's talk music.  My name is Chris Negrini and I am the Negapixel who composes the music for Taco Graveyard's games.

Whenever Steve and Sal ask me for music, I never have anything specific in mind to begin.  I am always fiddling around with something on some guitar or another; so my mind will tend to jump to my latest music-doodle.  By the time I actually sit down to record, something completely different tends to come out.  Song writing for me is always a simultaneous process of discovery and construction.  The song slowly reveals itself through my constant experimentation where the hypothesis is always, "I bet this will sound cool."

The spirit of experimentation was never more present than on the Penumbear project.  I put away my guitars for the most part and worked with samplers and synthesizers.  The goal, after seeing the creepy vibe that Steve and Sal had fostered, turned away from catchiness and to more ambient music that blended into the haunting environment.

The first song you hear in the game had been a theme that I had fiddled with for years never quite knowing what to do with it.  The reverberating chiminess of the vibes and eerie flute sounds seemed to be perfect for a cute little bear trapped in a twisted dark maze.  The song and the game played off of each other after that point, the music being inspired by the art and vice versa.  When the plan for all the available worlds came together, I had my road map dictating how the music could be inspired.

Even though the levels are starkly different (all in one castle no less!) I still came back to the idea that this little bear is about to poop his scarf.  So I always wanted the music to feel as if it were echoing from far off in the castle and something about it wasn't quite right.  I put together a song for each level as to emphasize the theme of each.  (If you want to know the levels then get the game ya jerk!)

Moving into a sampling and synthesizer based project turned out to be pretty rewarding in the end because it gives me even more versatility for the future.  It's nice to get out of your comfort zone.  Not only did I get to see if I could hack it without my strongest instrument but now I am more inspired to write some good ol' fashioned rock songs again.  Of course, now we'll see what else will creep it's way into my musical arsenal.

What it boils down to though is the game is a ton of fun to play, I could have just farted into a microphone for the music and that would still be the case.  (Maybe that would have turned out better?)  Sal and Steve did a hell of a job putting it together as always.


You can check out the some of the audio from the development of Penumbear on SoundCloud:

Penumbear - Making Maps and Levels

I’ve shown a bit of this in previous posts, but I thought I’d post a few more here. 

Level design in this game was really fun for me and I wish I had more time to do more levels. I had long lists of ideas that I never got to implement. Maybe as DLC or an update I can do some more.

Working out a level for a platformer reminds me a lot of how I used to “make games” when I was a kid. Nintendo Power used to run maps of full levels of games like Super Mario Bros 2 or Duck Tales, and I’d follow along with my finger pretending to play the game when I wasn’t near my NES. My friends and I at school would make up maps on paper at lunch and have bottomless pits, mazes, traps and enemies, and we’d use a lot of imagination to “play” the levels. Really no more imagination than we had to use to make Atari games as exciting as they were.

When I was trying to figure out what kinds of lamps to use and how to make a section of a level interesting, I’d go to paper and it dawned on me that I was doing the same thing I’d done all through middle school. It was fun.

I tried to make the levels interesting, picturing them like large paintings you play through, or a giant prison structure. I tried to think of clever angles for them; one involving dracula’s castle, “alcatraz” being the prison.

Some levels I didn’t get to make, like “Museum” was going to be a series of paintings that would change layouts and color schemes depending on if a switch was up or down. Another was “Eastmost Peninsula,” which would take it’s layout from the first dungeon in zelda. “Tire Fire” was going to have you rolling down a series of corridors on a wheel with hot rocks along the ground. “Traffic” was a level I did a rough draft of in the Cavern where Penumbear had to find his way around a long line of critters moving at a slow volume.

It’s really been a blast working on these, here’s some maps I drew up while working on levels. Should be noted that they did often change during the process, so I’m not giving away too much here!


Old School Penumbear Game Manual

Penumbear will be available in the App Store on February 28th.

Steve and I both love retro games. Nintendo and SNES were a big part of our youth, and experience on those platforms helps shape everything we make. Steve put together a Penumbear game manual in the style of our old SNES manuals.

I hope you love it as much as I do.

You can also grab the whole thing as a PDF:

Penumbear Tools - Level Editor

Penumbear will be released next week on February 28th.

I am a firm believer in using the right tools for the job even if I have to pay for them. I generally prefer open source tools so I can modify them if need be, but the development process would have been much slower without purchasing TexturePacker, ParticleDesign, GlyphDesigner, Spriter, and a number of other utilities. Level design was a huge part of making Penumbear and without a level editor we would never have finished. There are a few level editors out there with tight cocos2d integration, but I didn't love any of them. I decided that for Penumbear I would pay the cost by developing our own level editor.

In an early build of Penumbear we had simple level editor that could be used directly on the iPad. We used UIKit for all of the textfields, sliders, toggles, and selectors to avoid reinventing the wheel. This was a great start but positioning elements with your finger was not always precise enough. It also took a long time to build levels due to swapping between views and dragging pieces into position.

Soon after I ported Penumbear so that it would run on OSX as well. Being able to test things immediately on the desktop without having to load it onto the iPad with every change sped up development by an order of magnitude. The OSX build also spawned its own level editor because running the UIKit version wasn't an option. I maintained both the OSX and iOS level editors for awhile, but it quickly became apparent that we were building all of the levels on the OSX build so I stopped development of the iOS level editor.

Playtesting While Designing

When you shorten the wait times new behaviors develop whether it be from coding to testing, writing to publishing or ordering to having. This held true for level design. Having an editor that supported instant switching between edit mode and play mode allowed me to vigorous test every section of every level as it was built. If a jump distance didn't feel just right or the timing of an event was off, I could immediately edit the level and test it again. Having the editor at my finger tips at all times also allowed me to tweak levels on every single play through of the game. If I ran into a section that didn't look as pretty as I wanted it to, I could open up the editor, clean things up, and then continue on my way.

Keyboard Shortcuts

I am a big fan of the keyboard. Visual UI is great for new users and for certain task types, but when creating (and especially when coding) nothing beats quick access a key stroke away. I added in shortcuts for all sorts of behavior:

  • copying objects
  • deleting objects
  • nudging objects around
  • moving the viewport
  • zooming
  • rotating objects
  • locking object positions
  • toggling edit/play mode
  • changing z-order & layer
  • moving Penumbear

Lighting System

The Penumbear lighting system has a ton of variables:

  • radius
  • starting on/off state
  • color
  • emission angle
  • type: toggle, always on, grow, blink, swing, switched, rotating and timed
  • blink rate and delay
  • grow to and starting radius
  • grow speed
  • timed light duration
  • starting and ending rotation
  • other alternate light type settings ie lasers
  • positioning
  • various performance settings

All of these variables needed to be accessible in the editor. Additionally we needed lights to update in real time so we could see the effect they would have on the geometry of the level as we moved them around.


One of the features I added into the editor was a interface for swapping sound effect files into the game. This was added so that Josh (@OpenHeartSound) could test out sound effects in game without having to wait for a release. One of the great things about building your own editor is that you can add in features like this one to smooth out parts of the development process.


Despite all the great things about the editor, it is full of warts and subpar behavior. I limited myself to fixing up and improving things in the editor that would save us time developing levels. Making Penumbear was a primary goal so with a programming staff of one, I had to sacrifice the level of polish that I would have liked to put into the editor.

OSX Release

We will be running a beta of the OSX version of Penumbear very soon. We will include the level editor with the beta so testers can play around with the editor. I don't think it is polished enough to be released with the Mac App Store version, but we may sell a special edition of Penumbear off our site that includes the editor, the OST, and a few other things for buying it direct. If interest in an editor totally explodes, then I'll dust off my toolmaker hat and make it consumer ready.

Penumbear - The Art Post

With the release of our third iOS game PENUMBEAR right around the corner, I thought I’d talk a bit about my half of the production, the art and animation. Sal could write a lengthy look back on programming and his thought processes and Chris could talk a lot about how he came to make the music, or Josh on the sound effects, so this won’t be a full post-mortem so much as my thoughts on my role in this game’s creation.

Sal and I had done two games for iOS prior to this, FOUR HATS, and OMEGAPIXEL. The majority of FOUR HATS was done in a weekend as part of a Ludum Dare game jam. The main character was fully animated and the 3 other characters had “idle” animations, and assets for the first “zone” were completed. We enjoyed what we had enough to make a full game of it, but set a deadline of one month to wrap it up so we could get back to another project (which remains unreleased.) The characters in FH had animation cycles of usually 3 or 4 frames, the colors were bold but somewhat flat, and compared to what we’d learn on subsequent projects, there was little in the way of particles and a weak physics system. We’ve definitely been learning as we go.

OMEGAPIXEL was a project Sal started and I hopped on to add some art beefiness. Sal did a lot more work on particles and physics in this game, and the 8-bit aesthetic meant I had little to do in the way of animation.

We went through a series of false starts after this, and a lighting system in a zombie project we were working on inspired Sal to do a quick prototype for PENUMBEAR. The prototype had a few lamps this weird pacman-with-feet guy could turn off and on, a key and a door. The lamps would cast shadows off of blocks forming penumbras that the creature could land on.

The idea excited me, as I’d been sloshing my way through a ton of painted zombie frames and feeling like a zombie myself, so my brain wandered with all kinds of ideas. Just to give Sal something to play with while I painted zombies, I sent him some art for the key, door, background, and a few varied blocks.

While I painted zombie frames, Sal added color variety to the lights and started building some test levels. The level “To The Flame” in the finished game was actually redone many times as this early test level. It was already much more fun and interesting than the zombie game was, so we decided to put off the zombie game and go forth on this other thing and see where it leads.

I sketched out some ideas for a main protagonist. For some reason I kept picturing a wizard that could use his wand to turn lights off and on. I tried a Limbo-looking bear and decided the bear was kinda cool. I tried a few varied bears and then tossed the scarf on one. Then I tried this bear with the scarf in a few shades - a white one, a gray one, and a black one. We had the idea for the firefly as a key, and the idea initially was to have the fireflies he collected make him glow a bright green, which looked good with the darker bear. Eventually that was dropped but we kept the dark bear. 

Painting a background:

I have a horrible time with organization, something Sal does not suffer. I frequently forget limitations, save things in varied states sometimes and only in a finished state other times, making editing difficult. As I went through the game I’d learn new techniques or find ways to make things look better, making the assets not quite match. I just can’t seem to help it.

I went to work on assets for the game, first making blocks of different sizes and groupings. For most levels we would have one giant sheet with the majority of items - blocks, decoration for behind the blocks, some foreground items to scatter around and interact with. Then there were enemies, and eventually larger middle-ground assets for some parallax scrolling and depth. Some levels use every inch of space allotted, others much less, in my artist brain I just played it by ear, going with the flow.

Sal would put all these pieces into a level editor, so we could place a start door and end door, and start moving blocks around wherever. With FOUR HATS, Sal did all the level design, but with this one I had some levels I worked on as well. I was excited by the prospects level design opened up, it was like another piece of art for me. Some things that were exciting for me:

Naming levels - I liked the idea of having puns, or clues, or visual motifs by giving them interesting names. Some of the levels I did are named Modern Warbear, Lighthouse, Emptiness, and all 9 circles of hell from Dante’s Inferno. (Also of note, we came up with a cool system of using the actual level layouts in these level select paintings to generate these blotchy works of art, some clues can be found studying them, but they look cool regardless!)

Color Themes - making a level could be like making a painting with the colored lights we used. There could be icy cold blue levels, red hot levels. With the level Lighthouse, I had purple and blues to resemble a sky and a bright white light atop a long pillar to represent the lighthouse. With the level Night N Day, a switch changes the lighting scheme from a few large light blues and a large yellow to a few dark blues and lots of tiny white lights, representing the shift from day to night.

Variation - some levels could resemble platformers, others are deep mazes, some are wide open and others are claustrophobic.

References - I liked to reference other games when possible. It’s a recurring thing in Penumbear, from the way he holds up a Bonus Bear item like Link holding the triforce to the castle level select looking like the castle in Ghosts n Goblins. I tried to take it further, making a level called Samus It Ever Was, in which I tried to mimic the maps of the first Metroid game in level design.

With the level editor, we could also zoom out and see a full level in one shot which makes for some cool images.

At first I liked to really map out my levels on pen and paper, old school. Sal preferred to make up a level as he went so he could keep tossing in surprises and play everything new as he made it. I liked to think of it as building set pieces, with a puzzle here and a color theme there, and it helped me to make maps, like this one for the level Alcatraz in the dungeon.

Once we decided on making multiple zones in the castle, we spent one game jam weekend trying to figure out how to do a boss level. Penumbear is never on the offensive - short of turning on a lamp to kill enemies that die in light, he doesn’t attack or kill anything. His goal is just to find the door. This made bosses a little tricky. What we ended up with are levels like the others, with the addition of a giant creature either chasing or blocking or somehow affecting the layout of the level. Once we had the design for the first boss, a ginormous head with lots of eyes that shoot lasers Penumbear can walk on, we knew bosses would be a really cool addition to the game.

By the time we worked on the second zone, a major tone change had to happen. The basement had been pretty high on exploration and learning the ropes, set to a minimalist haunting music loop our friend Chris Negrini did. With the basement we went for something darker. I decided right away to change the color scheme from the blues, greens and grays of the basement to more purples. The background stayed very dark because the lights popped much better that way. The decoration changed substantially. Instead of stalagmites, columns, and ivy, we had rusty spikes, prison bars, barbed wire and chainlink fences. The music from here on out became a bit more lively and quirky. Also, thanks to the program Spriter, we had larger creatures to animate.

Each zone had it’s own new creatures, in the Dungeon we went from little critters that roll around blocks or march back and forth to larger creatures that pound the ground with their fists and require timing to get around, or another that breathed fire across the room.

As I made assets, Sal would work on new tricks and start making levels, I’d make a few levels and then get onto the next zone. The Cavern was very open and chill compared to the dungeon, followed by the Fireplace, where things got very intense. I did concept art for each zone before working on assets.

All in all we ended up with over 100 levels to play through, in 6 zones.

As we thought of new things for the bear to do or places where he looked awkward, it was easy to add new animations because he was the only character to really need a lot of movement. As it stands there’s about 200 frames of animation, 8 for most of his cycles, walking, running, jumping. He can double jump so there’s 2 jumping animations. Bonking his head, pushing into something, running out of breath, lifting bonus bears, and of course there were a myriad of ways to die took up a lot of animation.

Speaking of the bonus bears, as collectables towards a 100% completion, these were hidden all over the castle as little gray bears with bow ties. Apparently there’s some kind of bear collector living there. One of the later additions were special video game bears that referenced other games and used interesting techniques to find them associated with their game. For instance, a bear dressed up like the main protagonist in Spelunky is hidden deep in a cave. To find the bear with a Mario hat, keep pipes in mind. There are a few Sonic bears that require speed to reach before the bear is no longer obtainable. These were the touches that made this game really feel like something special.

Sal worked on the game full time (which is underselling it, he easily passed 40 hour weeks working on this), while I had to juggle a day job and working on my next book with work on the game, and especially towards the end it got to be pretty stressful. The levels Sal came up with were getting more and more difficult and I wasn’t able to get through them for a good while. I couldn’t test the game and work on the game while juggling everything else going on. I can now say that I have played through each level, but it’s a good challenge for those up for it! We tried to make it worth the effort by hiding all kinds of secrets in the game; there are hidden levels, warp zones, the video game bears, special rare golden bears. Even once you finish the game there’s so much to find. There’s also a second quest - complete with a new protagonist you’d recognize from the game that I won’t spoil here but he has a new mechanic and it changes the gameplay completely. Good luck to anyone who finds all there is to find!

The game was developed for the iPad and OSX; we planned on a large screen for all the detail, and worked on levels on our macs. Sal started fiddling with an iPhone port though, and while a little more difficult to play at that size, with some enlargened controls it was certainly playable, and now we have an iPhone version as well.

The last days of the game’s creation were filled with polish. We added a scramble animation the bear uses that covers up any awkward frames, drips of water, some shading techniques, menu reworking. Sal added a lens flare to the lamps as you run by that I really love, it feels like part of the game now and I’m glad we worked it in. I went in and edited Sal’s effects for fire and water to make them more in my style. We playtested like crazy.

The people that have played it so far seem to really like it. We really set out to make something much bigger than our previous games with PENUMBEAR, we wanted a game that could stand tall with all the great indie games out there and did our best to achieve that. I feel like any project like this takes talent, work, and luck. I feel we’ve proven we can make a good game with this, I think for the time we had and the skills I have as an artist, it’s about as good as it can be. Maybe two years from here I’ve learned a ton and Sal learns a ton and it feels like junk, but I doubt it. From here I think it just takes a little luck and I hope something comes of it, I hope it goes out into the world and it does well, I hope you play it and like it and recommend it, and I hope we can keep making games like this.

For now Sal’s working on the OUYA and is going to do a Penumbear port for that system. This feels like a game worth porting to find its audience. I have to work on a book. So we’re kinda leaving it off here and it feels strange but we’ll see where it all goes. We’re right near release and the future’s wide open.

Thanks for reading all this, and check out PENUMBEAR in early March on your iPad and iPhone.

OUYA CREATE Post Mortem - Duplicity

Making games that I can play on my TV with a controller in hand is something I am totally pumped about. That is why we backed both the OUYA and the iOS GameDock. One of the most exciting parts for me is the option for local multiplayer. I love games that can be a social experience. Super Smash Brothers, Dr Mario, & Golden Eye are some of my favorite games for that very reason.

The OUYA CREATE jam was announced at an incredibly bad time for Taco Graveyard. We were in crunch time for Penumbear and trying our hardest to get it ready for submission (on iOS). Immediately after our submission deadline I (Sal) had a trip planned during the last weekend of the jam. We had our OUYA Dev Kit and had unboxed it, but I hadn't had a chance to compile a sample project or even setup my dev environment for OUYA. The stars were not aligned in our favor.

If it wasn't bad enough to really want to jam and not have the time, I had an idea pop into my head that night. I wrote it down and filed it away into the "someday" folder along with all our other game ideas.

Monday came around and there were a few details that needed to get fixed up for the Penumbear launch, but by early afternoon my schedule cleared up. And so it began…


The tech stack that I decided on using is pretty bare bones. My original plan was to use Unity, but the version I have didn't work with the automatic deployment scripts and I like to have a really tight code->build->deploy->test cycle. I decided to give cocos2d-x a try instead since I have a lot of experience with cocos2d, but first I wanted to get a simple test app up and running. I got a basic Android SDK app running with a rectangle drawn onto the screen using OpenGL.

Once I had that first rectangle on screen, I dropped the idea of using cocos2d-x and just started coding directly with the Android SDK OpenGL API. I ended up building all of Duplicity without using any higher level game framework.

Random Notes:

  • I have a OUYA Dev Kit to test on
  • Testing on device was much faster than on the emulator
  • Having the actual controllers and hardware to test with was a blessing


Once I had a playable prototype it was obvious that there was a flaw in my mocked up design. The solid blocks of color looked nice, but made it tough to quickly assess where your pieces were lined up. I played around with a few options and settled on reducing the value of the color every other row.

When choosing color options, I made sure to run them through Color Oracle to ensure the colors would work for color blind folks.  To quickly explore different options that might work, I used kuler. I was able to quickly browse through schemes that worked well together and then filter it down to color pairs that worked well for Duplicity.

Piece Preview

Another change from the mock up to the prototype was to remove the next piece preview. The game felt good without it. The lack of planning actually led to excitement and a bit of chaos. In this case randomness felt like a good thing.


The first iteration of the game had both sides falling at the exact same time. It was tricky to decide how to resolve cases where pieces from both players fell into each other. I created a number of test boards that covered all the possible scenarios and made sure that everything was well behaved.

Once everything was working properly it was time for play testing. Then things went to crap. There were a number of scenarios that were confusing during gameplay even though the test cases resolved in a sensible way when viewed in isolation. The problem was a difference in perspective. When playing, you tended to only see things from your point of view and your brain didn't have time to reason out the solution from both viewpoints. The system created player frustration despite being consistent and logical.

The solution was to adjust the timing. I adjusted the timing to have the sides take turns instead of having both sides move simultaneously. It is now a rapid succession of turns. That paired with a few sound effects and some visual flare helped everything make sense while playing.

Submission / What's Next

With the colors cleaned up and the timing issue resolved, all that was left was a lot of play testing and minor tweaks. I put a small menu in place and submitted the prototype.

There were a lot of things that I didn't have time to do that need to be completed before the game is release ready:

  • Cleaner menus
  • More visual and audio polish
  • Alternate color schemes
  • Alternate gameplay modes
  • Test alternate mechanics (slams, power ups, locked blocks, etc)
  • A way to pause
  • Playtest, playtest, playtest

Overall I am pretty happy with my submission and what I managed to put together in the time I had. The response to it has been positive which is always nice. Most importantly, I have been having a blast playing it. If nothing more comes out of it than that, then it has been well worth the time.

Please check out the official entry page:

OUYA - Unboxing

Our OUYA Dev Kit arrived yesterday afternoon in the middle of pushing out a Penumbear iPhone build to our beta testers. What horrible timing! I decided to take a few minutes to unbox the thing or I wouldn't stop hearing the beating from beneath the floor boards.

It was shipped in a slick black shoe box, or at least in a box of around that size. There was a nice message embossed in the lid "OUYADEVS: Thanks for believing…".  When you opened the box the first thing you saw was a thank you note. Their gratitude to devs for backing the project was apparent throughout the unboxing and it was a nice touch.


Now on to the meat and potatoes… They shipped a neat special edition translucent case stamped with OUYADEV. The actual console was so little! I already knew how small it would be, but I love holding it in the palm of my hand. When I pulled it out of the box I raised it over my head Link-style, but that picture was mysteriously deleted. The back of the device has all the requisite plugs (Power, USB, Ethernet, HDMI).


The controller gave me my first WTF moment. I had absolutely no idea how I was supposed to power this thing. Then I noticed the battery compartments, one on each side of the controller. They very thoughtfully included batteries which was great since I didn't have time to dig through my collection of rechargeables to find the ones that were actually charged. At this point I had an idea about how to open the controllers but visions of snapping the entire thing in half swarmed in my head. I broke down and used the power of the internet to watch the official OUYA unboxing and watched them open up the battery compartments.

After watching the video I was able to open them up, but it was more painful than I would have liked. The compartments had a clear tab for easy battery removal. It would be nice if that was colored in the final controller. I expected as much pain closing it as opening it, but was pleasantly surprised how it seemed to magically lock back into place. There was no snap or click, I just placed the cover on and that was that.

The controller has a nice feel to it. The batteries give it a good amount of weight so it feels right in your hands. It is hard to say too much about it before using it to play a game, but my initial feedback criticism would be:

  • The joysticks, particularly the right one, would be well served by more texture on the surface.
  • The top two trigger buttons feel shifty and I am concerned about breaking them.
  • The touchpad will only have very niche uses as it is hard to reach.
  • Opening the battery compartments is terrifying.

Overall the controller felt good and I think they have time to address the remaining issues prior to the final build.


Let's get this puppy up and running. It was easy to plug everything in, get the console up and running, and pair the controllers. Nothing unusual or non-standard here.

After connecting the controller I was greeted with a nice thank you video starring Julie.

From there there wasn't much else to see. The store and all the interesting areas to talk about are still in the works. The one pain point I had was keyboard input. My wireless network is hidden and password protected, so to connect to the network I had to bang my head against the on screen keys to type in my SSID.

Kidding. I did have to use the touch pad to move an onscreen cursor to the letters I wanted which was liking banging my head against the screen. What a horrible way to do keyboard input. It would have been a million times better to let me use the dpad to navigate the keyboard. Fortunately as soon as I connected to the network and installed the first update, that problem was resolved and they had a new keypad in place that took dpad input.


Overall the dev kit met my expectations. There are a few rough spots that I hope will get worked out before the consumer version is released. Beyond that, there isn't much to say until I have had some time to look through the software side of things. Once Penumbear is out on iOS and OSX, I'll spend sometime coding up a few little demo projects on the OUYA and then start the grand porting experiment. This will take a bit more work than a port for an Android ready game, but I am looking forward to it.


It is autumn in this part of the world. Leaves are falling. Squirrels are busy packing away nuts for winter. We are chained to our desks trying to get as much done as possible. The 2013 IGF submission deadline was last night and Penumbear has officially been submitted. Here is an updated gameplay video of our submission:

Additionally we have added Penumbear to a new area on Steam's Greenlight that is dedicated to concept work and/or games that are early in development. You can check it out here: Once the PC build of Penumbear is closer to a reality, we will add the project to the main Greenlight area and try to get it on Steam.

We have been horrible at updating the blog but we push out regular screenshots and updates to twitter so if you want more, then follow us there. We will be back here with more soon!