I was interviewed by Corey Paul of Oregon Business Magazine for a story about the latest iterations of the classic Oregon Trail series of games. The article is available online, but I thought readers of this blog might dig my unabridged thoughts on why educational games have trouble making money:

Educational games and profitability is a bit of a “chicken and egg” scenario. If every educational game was as novel, fun and appealing as Oregon Trail, I’m sure they’d have no trouble recouping their cost. But because most educational games are a bit stodgy, focusing less on playability and more on communicating information, they can’t ever compete with titles that aim to be fun first and foremost.

There’s a comic book I love called Usagi Yojimbo by a cartoonist named Stan Sakai. The book is set in feudal Japan, and all of the characters are animals; a samurai rabbit, a pig ninja, a rhinoceros bounty hunter. The stories are fun and full of swashbuckling adventures, humor and dramatic moments. Most readers would never consciously realize that Stan has done painstaking research to insure that his portrayals of that era of Japan are accurate. Just by enjoying the stories, you will learn dozens of Japanese phrases, customs and historical moments, so much so that his comics are often used as textbooks in college courses on Japanese culture and history. Educational games should strive for a similar style of engagement as often as their subject matter allows.

Here’s a drawing of Miyamoto Usagi I created for a 25th Anniversary gift presented to Stan at the 2009 San Diego Comic-Con:

As a kid I remember liking Oregon Trail and Math Blaster, but few other educational titles spring to mind. Which, if any, have you enjoyed?

When I made the original Ramps, I didn’t give much thought to its visual style. It was basically a glorified tech demo, an outlet for the skills I was learning from Keith Peters’ Foundation ActionScript Animation book (which has since been succeeded by an ActionScript 3 edition). I look at the game fondly as the spirited product of an enthusiastic student (albeit one who was way too excited that Flash had support for gradients and bitmap effects).

I’m fascinated by the recent resurgence of pixel art and retro gaming, particularly in wonderful games like The Incident and Scott Pilgrim vs. the World. Nostalgia is certainly a part of the appeal, but a deeper design principle is also at play. I believe the limitations of low-resolution artwork forced the game makers to be extremely selective, resulting in visuals refined in simplicity and character. For example, Shigeru Miyamoto credits dismally low pixel resolutions as the cause for Mario’s distinctive cap and mustache:

The technology of the time really dictated how we did character design. If I gave Mario a lot of hair you have to animate it or it doesn’t look right. By giving him a hat we didn’t have to worry about that. We also didn’t have to draw his eyebrows, his forehead or any of these other things. It was just a really useful tool to help us emphasize what we were trying to do on this small screen.

In designing Ramps for iOS, my goal was (and continues to be) to capture that same focus and restraint while embracing the richness of contemporary displays. I admit the ambitiousness of this challenge, but it’s hard to regret something so fun to pursue.

I honestly didn’t know how well the original game’s piranha enemy would translate to the minimalism of Ramps’ new direction, especially since it relied so heavily on a metallic appearance. I decided to capture the translation from start to finish for posterity, sped up for your convenience and enjoyment. I hope you dig it!

We’ve put a lot into Ramps, and it shows. Our contributions have exceeded 850 hours of work over a duration of 18 weeks. Comprised of 347 design assets and 43,284 lines of code, we wanted to make our first game the absolute best experience possible and neither of us were willing to compromise on much (in fact, we accomplished nearly everything we set out to do!) Tyler and I have both participated in collaborations in the past, some successful and some that haven’t quite got off the ground. So what made Ramps different? Naturally, we put our heart into it and were incredibly pumped to make it happen, but doesn’t every collaboration start out that way?

In my opinion, the biggest contributor to us being able to ship Ramps (which is easily the biggest side-project-turned-Company I’ve ever been apart of) was our investment and buy-in to our process. Though our process developed organically, in hindsight, it wasn’t a pre-conceived effort. Tyler and I have both worked in the tech industry for a long time, and I gravitated towards an agile methodology which is something I’ve grown accustomed to working with during product development for my daytime employer.

Because we were so focused on the product, we never really sat down face-to-face and said, “Okay, let’s put a process in-place and hold each other accountable to it.” I’ve never worked for a full-fledged startup (until now!), but I’d like to think we adopted an approach that many other tech startups take. What worked great for us was to adapt components of a process as they become necessary.

Ramps started out as more of a feasibility exploration and evolved organically. We never really said, “Hey, let’s go make this game!” Tyler and I had chatted about doing a port of his original Flash game, and I spent some time exploring (see also: dinking around) with cocos2d, which is a popular open-source 2D iOS game development platform, and box2d, an immensely popular, open-source, cross-platform physics engine.

Tyler mentioned to me recently that at one point our work, “…stopped existing as merely a tech demo and really became a game.” Once we reached that epiphany, everything started to kick into high-gear. We started gaining momentum, and with that we utilized a number of tools to help us manage the gigantic flow of tasks, bugs, assets and various forms of communication that flew fast and furiously. In hindsight (and foresight.. there’s still a lot more of Ramps left to build!), we adopted a light-weight process that I believe was a hybrid of Scrum and Lean.

The most prominent elements of Scrum we used were daily communication and a consistent feedback loop. Tyler and I chatted online and exchanged e-mails almost every day for the last five months. At the end of each day, we’d give our daily update via e-mail. We’d provide each other code or assets as they were completed, and give each other feedback as soon as we could. If we ran into roadblocks, we’d resolve them immediately by making a joint decision.

Most of our process really embodied the seven principles of Lean, a flavor of Agile.

Eliminate Waste

Don’t make stuff for the sake of making it! From a development perspective, I tried to only create layers of abstraction if I knew for a fact that they would be repeated. As I discovered patterns and found myself in a repetitive rut, I’d re-factor code. Early on, I actually spent an entire weekend (20+ hours) just re-factoring because I saw a more efficient way of working with box2d that I knew we would benefit from long-term. It was nice to really get this right, though because this is the first game I’ve ever developed, I also made a lot of mistakes that I can learn from the next time I use cocos2d and box2d for a new game.

Other elements of eliminating waste we used included quick-turnaround communication and maintaining clear requirements. I felt our successes here pointed back to establishing momentum and being engaged every day. Since we were both thinking and talking about Ramps all the time, this came pretty naturally for us. If we weren’t regularly wired-in, it could have hurt the project.

Amplify Learning

To me, this principle just meant that we needed to always having working code. I fixed bugs early and often, and always had something demo-ready on my iPhone. I treated crashes as show-stoppers. I would literally stop everything I was doing and focus on fixing a crash once it was discovered. This way, Tyler and I were both always playing Ramps, and if something wasn’t a good fit, we could change it immediately to improve the experience.

Decide as Late as Possible

This is the principle of lean I agree with the least, as decisions often go hand-in-hand with trial and error. We were very organized on when we made decisions, in that we’d start the process of making a decision while anticipating how much time we would need to make that decision. For example, we started engaging with Essa, who wrote the super killer awesome score for Ramps, about two months before we launched. This worked out great, as it gave him plenty of time to be creative and produce, but it also gave us enough time to provide feedback and iterate.

Deliver as fast as possible

Really, every night was a delivery for us. We set a target date early-on (Christmas), and went for it (and we made it!!). Instead of worrying about the big picture and over-managing the project, we tackled the project in milestones. I would work on developing a feature, a world, or a set of physics objects. Tyler would focus on designing a character or a scene. As Tyler completed designs, I would implement them. We added a lower-level of project management about six-weeks before launch to make sure we were prioritizing work items in order to hit our target date. We also made sure that we gave ourselves enough time between each milestone (alpha, beta, app submission, etc). Often, our communication mechanism for project management was informal e-mails, but we’d tweak target dates on-the-fly and we both always knew where the project was at.

Empower the Team

I am by no means a designer, but I know when something looks cool and when something looks off. Likewise, Tyler is not a Developer (with a capital D, as he puts it), but he has an eye for what feels right in a game and has plenty of technical expertise to think like a (D)eveloper. That said, in our process there were no stupid questions, no bad feedback, and no impossible ideas (some of them are just really hard/time consuming!). We both own this product, and while we had some definite high and low points, the ownership of making it a great product was on both of us. Keeping cool and remaining optimistic was essential!

Build Integrity In

At first glance, this might seem like Lean is referring to ethical integrity, but really it means the perceived integrity of the system by the customer. As long as the player has a good experience, and that all of the moving parts move well together, then the product has good integrity. To us, this meant that we were putting the customer first and that the experience they interact with is, “solid.” It meant that we wanted you to get lost playing the game, and minimize the number of times you say, “Hmm.. that seems weird.” Seeing as I’m writing this two days before we ship 1.0 (edit: Yes, I spent an insane amount of time on this post), I’m naturally a little nervous about this. But, as Matt Mullenweg says, “If you’re not embarrassed when you ship your first version you waited too long.”

We did a week of beta testing with about 12 people, and fixed over 50 “weird” things people observed (and a couple of show-stoppers), so we feel pretty good about this one. We’ll be fixing more “weird” things as we keep discovering them, as well.

See the whole

Like the Empower the Team principle, this one is really about owning the product. I don’t usually like to sub-contract work unless I have to, and when I do, I’m the most receptive to people that are extremely enthusiastic. We only subcontracted one part of Ramps (the music), and I don’t think we could have found a better fit with Essa. We found him at 8bc.org (Eight-bit Collective), and we were both immediately excited by his work. He only had two tracks posted on the site, but his musical style reminded us both of a classic 16-bit game we both grew up loving.

Ultimately, relationships and the team dynamic truly shape a product. For Tyler and I, and our work with Essa, we were able to consistently portray the experience we wanted to create, and I think that enabled each of us to make key decisions independently and then solicit feedback rather than waiting for a group decision before executing. Maybe that’s why so many people compare Ramps to Sonic the Hedgehog. All three of us grew up loving those games.

Communication is a huge bottleneck for any project, and while we still needed a ton of it for Ramps (and we handled it well), being engaged and iterating often helped strengthen our individual intuition to help us do what’s right for the product.

We love getting feedback from folks who play Ramps. Here’s a particularly awesome message from a 13-year-old fan, Frankie:

First of all, I love your game. It’s innovative and clean, no lag or glitches and I like the music. But if you want to get your game to be more popular, I would suggest a few things to improve it and raise the ratings. The music Is very repetitive. It’s catchy and goes with the worlds but maybe at least 4 or 5 more songs for each world. Also if you really want to make people happy, eventually obviously, you should add a Level creator and make it good Because I love being creative, and I’m sure a lot of other people would like it too! Also you should be able to share the levels worldwide and be able to download other ones too. This is all in good time of course! And with future updates, adding more worlds and levels would be nice. But you guys really did a wonderful job with everything! Go ramps!

P.S. The more improvements you make the more people will buy it which means more cha-ching in your pocket!!

Thanks so much for your email, Frankie! More music and a level creator would be really cool. Tim and I will definitely be thinking about your comments while we work on improving the game.

By popular demand, the following post is penned by Ramps’ composer, Essa!

Despite having dipped my bill into music commissions for a handful of media projects, and having composed in my free time more than enough video game inspired music, Ramps is the first actual game I’ve had the pleasure to score. As we’ve said, this is a labor of love, and I’m not yet getting delusions of grandeur or walking around calling myself a “composer” or anything, but if my twelve year-old self could see me now, he’d flip his lid, and thoroughly look forward to the future.

It may (or may not) be of interest to know that 99% of the virtual instruments used thus far in the Ramps soundtrack have been freeware, and often open-source synthesizers. The music is composed on Cubase 4, and will be available to download once the necessary overhauls have been made to my own site (shouldn’t be long now; I’ll post a link when finished). I don’t know if there’s much interest out there at the moment for the score, but I’ve received enough positive feedback thus far that it seems like I may as well make it available.

One reviewer of the game commented that the soundtrack reminded him of the old Sonic the Hedgehog titles, a compliment of the highest order as far as I’m concerned. Unbeknownst to him, I’d wager, is the integration of the VOPM synthesizer in all the songs: a virtual instrument which emulates nearly perfectly the sound chip found in the Sega Genesis and Master System. While the synth doesn’t take the spotlight in most cases here, it’s at almost all times providing some form of backing, which I’d like to think has given the game a slight flavor of Seganess throughout it. Tyler’s bright world and character design really helps bring that flavor out as well, and my partnership with Backabit came into being over fond memories of the Genesis era games.

For those interested, the VOPM is a freeware instrument, and easily obtained if Googled. My pastime of choice is attempting to recreate the signature sound of the old Sonic tunes in original compositions using this instrument exclusively, a hobby as frustrating as it is gratifying.

It has been, however, a joy to be able to take such influences and stir them into the Ramps music.   Which, presently, is exactly what I ought to be doing instead of sitting here talking shop.  Back to work!