Ready, Fire, Aim!

It actually took a while until I started working on the game for real. The deadline for the Google Android Challenge was the last day of February, if I recall it correctly, and although the idea was vividly with me for January I could not get myself to start working on it. I think it had to do with me needing some time to rejuvenate after having stopped working part-time. I almost gave up on the idea with the deadline nearing so quickly, but then Google decided to postpone the deadline to April 14th after they released an update to their SDK. This got me motivated to do it – to take action on the opportunity!

So the work began. I’m a huge fan of Visual Studio and I find that the best way to prototype games and do tools is to use C# .NET. So using Visual Studio Express Edition I finally began working on the game. I had done some physics testing late in 2007, so I knew it would not be a problem to get the rope working. Instead of prototyping the gameplay first I did the editor to create levels. What I needed was:

• A level format with caves constructed out of rocks and an editor that let me easily and quickly create levels. Having great content early on and not having to build levels by manually inputting numbers into arrays is really key to a good kick start.
• An editor where I could import pictures of rocks and create their collision shape. All rocks are built from convex shapes, that way I could use an easy collision detection algorithm called SAT or Separating Axis Theorem.

Steve Pavlina talks about the “Ready, Fire, Aim” method: Independent developers spend so much time on making generic game engines, details and planning ahead that in the end they get nothing done. Often when independent developers use the well known “Ready, Aim, Fire” (Idea, Planning, Execution) method it ends up as: “Ready, Aim, Aim, Aim, Aim, Aim…”. If I happened to need more complex levels and more features I could implement them later. It was important I got a prototype up and running as fast as possible.

The editor probably didn’t take much longer than a couple days to create, the code was horrible, but I wasn’t going to build upon it much in the future anyway. The first prototype came to life quite quickly too. All in all in about a week I’d say, and keep in mind I was a full time student during that time. But I did let my grades suffer; I found it more important to work on this game.

The first prototype consisted of just a level getting loaded and a ship flying forward. Now was the time to implement the physics, which I did with a plain copy & paste from the physics demo I created in 2007. And it worked, although it took some time tweaking to get it just right.

The Asterope level editor early on

The obstacle editor

First prototype up and running

Keeping My Motivation

Something that Eben Pagan, my personal favorite self-help guru, talks about when it comes to challenges to get things done is how 90% of people are not motivated by goals. So if you’re one of them, and you likely are, you will feel unmotivated if you put up a goal to get a game done by a certain date. It’s better to focus on small problems - one problem at the time. Most of us are problem solvers. The idea originates from a book by Bobb Biehl named "Stop Setting Goals If You Would Rather Solve Problems".

So I had an editor and a prototype of the game and I felt that the gameplay worked. Now my problem to solve was making it pretty. Having a good-looking game early on can be a great way to motivate you to get the game done. Although you could have most of the code written, if the game looks bad it will feel far from done. Better to trick yourself into thinking there’s not too much left to do.

I opened my image editor and began to mock-up some graphical designs of the game.

First mockup

This was the first design I was happy with. But after having discussed the art with a friend, Scott Hilbert, we came to the conclusion that the stones needed some shading. So I added shadows to all rocks.

Second mockup - Much better!

After the second mockup I knew the look I was after and I had an algorithm I used to create the rocks (a step-by-step system in Photoshop), so that way they would have a uniform look and I would be able to create the rocks more quickly. Creating the first version of all the art did take some time, but damn I felt happy to see the prototype alive with the new art. Gave me a huge kick of motivation!

Here’s a picture of the final design running in the prototype.

“We are the Androids. And we’re here to take over your world!”

The level editor had most features implemented and now the final challenge was to get the prototype ported and turned into an Android game. I divided the Android application into three logical parts: The world, the physics and the game. The world had the loading and displaying code for the levels, the physics handle the physics and the game handled all the game logic. These parts where implemented as static classes. I kept as many things possible static as it’s a good trick to speed up Java applications. Speaking of optimizations, a mistake I did was to redo the physics code to use fixed pointed math because the Google Android documentation recommended this, as all phones might not have FPUs. This took time, was frustrating and I do not think it had a positive impact on my entry, as the testers did not have any real devices to test the applications on anyway. I changed it back to floating points when I did my iPhone port – lesson learned.

Truth be told, porting it to Android from C# .Net was super easy, as Java and C# are so much alike. When I first got to see a level of my game running on the Android emulator it was a big relief! I knew I could pull it off to get this game done in time for the Google Android Challenge's deadline.

Alive on Android!

Development Part 2