I created a geolocation game for the iPhone back in 2009. It was called “Journey Tag” and it’s still available on the AppStore, although it does have a few bugs with current iOS versions.

The idea was let players create a “tag” which is tied to a location. Other players would move the tags around the globe, earning points for each mile moved. Players had to physically move the “tags”: walk, drive, or fly kind of move. (It was inspired by Geocaching if you know what that is. ) This seemed like a simple idea, but it turned out to be a lot more complicated as I started building the game.

Technically you do a postmortem soon after the project is finished. It has been 3 years since I finished the game so here it is, better late than never.

The game was split into a client iPhone app and server side web service. The server side used Google App Engine with python and the client was obj-c and UIKit. I spent about 6 months working on the project and the first 2 months was spent just learning the platforms and languages. I’d never worked on either before so there was indeed a bit of a learning curve.

The goals for the project were kind of lame. I never expected any financial success and my ultimate goal was to learn iOS and python, and hopefully walk away with a fun game to play.

The problem with choosing a social/multiplayer game is the need to have many players for it to be fun. Because the game was so hard to figure out, it was kind of doomed from the start.

In the end it had around 500 registered players and 50 – 100 active players. The top 30 players really enjoyed the game and we got a bit competitive at some points along the way.

It definitely had some flaws, and it took a lot of effort for me to make improvements. The largest problem I faced was in explaining how the game worked. This was mainly due to poor UI design.

People did enjoy finding tags and moving them, it was a matter of getting them over the hump of learning to play the game.

So what did I learn? What would I do better next time?

Things I learned

• execution is hard to get right on the first try
• making a game fun and addicting takes much experimentation, so be prepared for a lot of R&D time
• coding the iPhone app, the server, and a test suite made for a lot of work. Testing simple ideas was not a trivial process. I chose a difficult subject matter for my first game.
• seemingly simple features turned out to be very hard to implement without drastically changing the existing game. The rules got complicated fast. This was on top of the fact that each feature essentially took layers of code: client, server, test suite.
• the rules of the game became complicated for such a simple idea. This also hindered progress.

What would I Do better next time?

• design the UI first, then write code
• allow instant play, no sign up screen
• put in single player activities, many players didn’t have anything to do in the areas they were in
• don’t make an app that depends on social or requires a server—this more than doubles the code you must write
• discuss ideas with as many people as you can. Find out who your audience is and see their reaction.

Conclusion

In the end, I was limited on what I could code by myself within the time constraints I had. But, it was a blast making the game and it taught me many important lessons.

I am a working on another iOS game. Just not something that requires a server or a test suite.