We're Kickstartering

Great news! My wife's company, Syslark, Inc., has decided to use Kickstarter to raise the funds to take my FFZ game from amusing prototype to finished game on the OUYA!

She's participating in OUYA's Free the Games Fund, which provides matching funds for games that will be OUYA exclusives for 6 months after launch.

So everyone please have a look and back her if you like what you see.

Hack It, then Refactor It

I've spent the last several days refactoring my OUYA game. It seems strange to spend so many hours working on the code and the great accomplishment is that it still works. I just felt the need to explain why I do this and how it works for me.

I believe that I am a very results-oriented person. Not to say that the ends always justify the means, but I recognized many years ago that getting a product working is much more important that making sure that all the T's are dotted and the I's are crossed. I've also been known to get forgiveness instead of permission on many occasions.

You can be writing the most elegant, perfect, optimized code in all the world but if no one ever sees or uses the product then what have you really accomplished? This is true for everything, not just software products. Once (1998) I decided to replace the stock 3.8L V6 engine in my 1989 Mercury Cougar with a 5.8L small-block V8. I had 3 months until I needed the car to run again so I could go back to college. As far as we could tell, this feat of automotive engineering had never before been accomplished. The engine did not physically fit in the car. But I wasn't building it to put on display, so we hacked and bent and cut and torched and pounded with a hammer. It wasn't pretty, but it ran. I drove it back to college and almost every day while I was there. I also spent the next 3 years fine-tuning it. Parts were replaced with new ones as they were fabricated. The more powerful engine totally blew out the rest of the drive-train in time, but that got fixed as well. I could have spent those 3 years making it perfect before it ever left the garage, but it was much better to be driving it all that time.

Basically, I learned that success means shipping a product. So how does this relate to hacking and refactoring software? It's pretty much the same thing.

I wanted to get stuff on the screen of the OUYA and get things moving around with the controller as quickly as I could. I needed to see it working, even if the code was less than perfect. I needed to see those results so that I could continue. Letting it "sit in the garage" for too long would just discourage me and I would lose interest.

However, I know better than to leave the code that way for too long. If I am going to build a complete game, my code has to be structured such that it can be built on. It can't be brittle. It has to use the proper design patterns. So every few weeks, I stop adding new features and refactor. I clean up the ugly code and make sure I have a solid foundation before building more. But in the mean time I also have something that my kids and I can play (You don't have to release your product to everyone to count it as a release. My Cougar only had one user, after all).

It's just what works for me. And it works for other people as well. Check out the works of Kent Beck and Martin Fowler. They've written lots of stuff on design patterns and refactoring code.

Also, read this paper.

And as for my Cougar, I no longer drive it but it taught me a lot about successful engineering projects.

Getting Started with my OUYA

So now I have my OUYA Dev kit all unboxed and hooked up to the TV and everything. The screens and welcome video look nice, but to load anything on it I needed to get it hooked up to the computer and detected as a valid Android device.

I like to do my development in Eclipse on Windows. I know, I'm crazy. I like my Mac and all, but when I write software (except for iOS of course) I've always been in a Microsoft environment. Maybe it's because my first introduction to programming was BASIC in DOS. Maybe? But from BASIC to Turbo Pascal to C to Java, I've always used a DOS or Windows PC. I'm now on Windows 7 64-bit and of course the OUYA wasn't detected as a valid device when I plugged it in.

The Windows section of the setup information for OUYA devs is a little sparse right now (ok, it's empty) but the forums did provide me with a solution, which I will now share. Hopefully they'll provide some kind of driver with the OUYA when it is released to the general public in a few months, but if not this trick will probably still work.

First, find the Android device driver file provided by Google in your Android SDK. Mine was

C:\Users\User Name\AppData\Local\Android\android-sdk\extras\google\android_winusb.inf

and yours is probably somewhere similar. Open that file up in Nodepad and add these two lines in the [Google.NTx86] section:


%SingleAdbInterface% = USB_Install, USB\VID_0955&PID_7100&MI_01
%CompositeAdbInterface% = USB_Install, USB\VID_0955&PID_7100&REV_0232&MI_01


Then you go to your Device Manager and find the unknown device. It is probably calling itself "Cardhu" or something. I don't know what that's about, but just open that up and click the "Update Driver" button. Choose "Browse my computer for driver software" and then "Let me pick from a list of device drivers on my computer". On the next screen, click on the "Have Disk" button and then browse for the .INF file you edited earlier. Then when asked to pick a model, select "Android ADB Interface". You'll probably get warnings about the driver not being signed. Tell the Windows nanny to take a hike and install the driver anyway.

That's what worked for me.

Unboxing my OUYA Dev Kit

I received my OUYA development kit yesterday! They really shipped them to us when they said they would. These early dev models are special - they have clear casing and say "OUYA DEVS" on them. Here's what was in the box.

Here's a close-up of the back of the console. Power is on the top. Below it is a mini-USB for connecting it to your PC and an Ethernet port. The bottom two ports are the HDMI output and a USB input. I used that one to connect a mouse to navigate the settings screens before I paired the controllers. I actually had trouble getting the controllers paired with the console, and here's why. To put the controller in pairing mode, you hold in the power button for 5 seconds. To shut down the controller, you hold in the button for 7 seconds. I guess I'm not good at counting in my head, so when I would keep the button down just a little too long it would shut down in the middle of pairing. I would like to see a different button used to pair the devices.

Here's a picture of one of the controllers beside the console. They say that the controller design is not final yet, so if you get one in the spring they might look a little different.

OUYA Console and Controller

They even supplied Duracell batteries for the controllers! That was nice, since I don't really have enough batteries in my house right now. And when I was writing this, my wireless mouse needed new batteries.

You put one battery in each side of the controller. I thought that the panels came off a little too easily, and they've already warned us that shaking the controller too hard can pop the batteries out. Hope they address those issues before the final production.

Here's a close-up of a controller. The buttons are labeled O, U, Y, and A. Both sticks are buttons if you push them straight down as well. There's two triggers and two bumpers along the top. My initial impression is that the triggers might be a little hard for me to use but I like the bumper locations.

OUYA Controller