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…
Technology
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
Colors
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.
Timing
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: http://killscreendaily.com/create/video.php?submissionID=83