#AltDevBlogADay

I seem to be on a ‘Lessons Learned’ kick lately and so I thought I’d take a look at our most recently released game and see what lessons could be learned from its development.

Wikipedia.

How It All Began

In late November 2010 I saw some kids playing some silly smart phone game docs when my wife walked in and asked what I was reading.

“Oh, Android.” she said, “My friend just got one and was raving about it. But she was disappointed she couldn’t find any Montessori apps for it.” At that moment I heard a “ding” in my head and started a google search. She was right; there were no Montessori apps at all for Android except for one that simply contained quotes from Maria Montessori and other educators (Link). There was a gap in the Android market and I just had to be the one to fill it.

Problem #1 – Getting Started

I started by digging deeper into the Android API docs and learning how to access OpenGL, receive input, and play sounds. ^{Mistake #1:} Next, I opened Eclipse and started writing a game engine. However, 30 minutes into it I sat back in my chair and thought, “What am I doing? This is stupid! I want to make a game, not a game engine. A game engine will take too long.” So I began a google search for android game engines.

Corona, and a few others. ^{Mistake #2:} I found myself lost in the details of evaluating game engines by comparing (cool) features and prices, but since I failed to define my game requirements I had no clue which engine was suitable. After about an hour with a spreadsheet I sat back in my chair and thought, “This is stupid! I’m choosing a game engine and I don’t even know my game requirements!”

By this time I had “wasted” about 2 hours and I wasn’t any closer to a game. So I took a step back and did something that caught me by surprise: I shut down the computer! Oh the Horror of it all! It was tough to see the little blinking lights grow dim and fade to black. I nearly shed a tear. But I collected myself and sought out my wife to tell her what just happened. She said something that made a lot of sense, “Maybe you should make a small scale prototype first.”

We’re both electrical engineers and making prototypes of various electronic assemblies is something I know how to do well. Why I didn’t think to build a software prototype is beyond me; I guess my wife is just smarter than me.

I sat down with my wife and over the next few hours we hashed out the basic parameters for the prototype

• What basic set of functionality will the prototype have?
• What are the actions and reactions of the basic functionality?
• What’s the look and feel of the prototype?
• What’s the time-frame for the prototype?

The toughest question to answer was the time-frame because I had never written a line of Java before. I wanted to challenge myself, but I didn’t want to make it an impossible deadline. Java seemed similar enough to C++, so I set the deadline for 12 hours from the time my first line of Java hit the editor. If I exceeded the deadline the plan was to drop the project and move on to something else.

Next came choosing a game engine. Answering the above questions made it easier to evaluate the choices. I found myself torn between AndEngine and rokon. After trying out the demos and reading what other people were saying about both engines, I chose AndEngine.

LESSONS LEARNED:

1. Prototype first!
2. Figure out the minimal set of requirements for the prototype and then pick a time-frame for building the prototype.
3. Don’t start by building or choosing a game engine.
4. Do 1 – 3 before writing a single line of code.

Problem #2 – Look At My Elegant Pretty Code That Doesn’t Do Squat For The Prototype!

With prototype details in hand, a fresh Eclipse Android project, and AndEngine ready to go I started coding. I created a new Java class and suddenly realized that Java is more different than I thought. I have 20 years of C++ and 25 years of C, but not one line of Java. It took me about an hour to come up to speed with Java and was happily coding away, ^{Mistake #3} writing elegant, well formatted and pretty code … for a prototype!

I was 3 hours into coding and found myself futzing around with ^{Mistake #4} XML loaders … any good game needs a way to load in levels, right? So I’m sitting there with a completed XML parser for the game, and then thought, ^{Mistake #5} “now for the component system”. It was at that very instance a tweet flashed in TweetDeck that read:

link and started reading. Five minutes into the blog I came to a line that stopped me…

“As programmers, we have a tendency to try to generalize our code, and make it elegant and be able to handle every situation. We find that an itch terribly hard not (to) scratch, but we need to learn how. It took me many years to realize that it’s not about the code, it’s about the game you ship in the end.”

And if that wasn’t enough to kick me out of my pretty code stupor…

“Don’t write an elegant game component system, skip the editor completely and hardwire the state in code, avoid the data-driven, self-parsing, XML craziness, and just code the damned thing.”

“XML craziness” echoed through my dense head.  I never even stopped to ask if my prototype needed an XML parser. Noel nailed me. I had lots of pretty code that didn’t do squat for the prototype. Noel was right; I just needed to “code the damned thing.”

Lessons Learned:

1. Ask yourself if you really need that code for the prototype.
2. Cut the crap and just bloody code the prototype.
   

Problem #3 – Would Someone, Anyone, Please Help Me Test the Prototype?

Once I got my head past the systems oriented mess and the mounds of utterly useless pretty code, it took me about 8 hours to finish the functioning prototype; that was just under my 12 hour deadline. But now I faced another problem, all of my testing up to this point was on the emulator that comes with the Android SDK and I really needed to test it on a real phone. So what’s the problem? … I didn’t have an Android, ^{Mistake #6} I had no way to test the prototype on the target platform.

Eventually I found a friend with an Android who offered to test the app for me, and it worked flawlessly, but it was still a stressful time.

Lesson Learned:

1. Make sure you can test the app on the target platform.

Problem #4 – I finally got an Android

The kids who played with Mobile Montessori on the emulator seemed to like the game very much. So I spent the next few weeks cleaning it up and adding graphics and more mini-games.

Three months after the ‘finished’ game was released I purchased an android. When I played Mobile Montessori myself for the first time on an actual device I was surprise to find some things didn’t work quite as well as they did in the emulator. First, the touch areas for some objects were much too small. Even the small fingers of a child were not small enough to activate some of the touch areas. Second, the ad-banners caused some objects to become unresponsive to touch. It worked fine in the emulator but it was failing on hardware. Third, the movable blocks in the game were so small that you couldn’t see them under your finger, making it difficult to maneuver the blocks to the right positions.

Some of the testers (and customers) reported some of these issues but they didn’t really make sense to me because I lacked context. Having an Android in my hand provided context and I was able to fix the issues in short order.

Lesson Learned:

1. Make sure you can test the app *yourself* on the target platform.

Summary

To summarize these lessons learned:

1. Prototype first!
2. Figure out the minimal set of requirements for the prototype and then pick a time-frame for building the prototype.
3. Don’t start by building or choosing a game engine.
4. Do 1 – 3 before writing a single line of code.
5. Ask yourself if you really need that code for the prototype.
6. Cut the crap and just bloody code the prototype.
7. Make sure you can test the app on the target platform.
8. Make sure you can test the app *yourself* on the target platform.