• Create Account

$10 ### Categories (See All) Like 31Likes Dislike # How we Built an iOS game on PC By Thomas Henshell | Published Apr 08 2013 08:05 PM in Mobile Development game monkey marmalade design player scene time tool png ios  If you find this article contains errors or problems rendering it unreadable (missing images or files, mangled code, improper text formatting, etc) please contact the editor so corrections can be made. Thank you for helping us improve this resource This article chronicles Catch the Monkey from ideation to sale worldwide in the App Store. You can find out more about Mirthwerx and our projects at our website. ## Intro Many people want to get into making games, specifically mobile games. Well, we were one of you! This series is for anyone who wants to jump in and do it. Our goal is twofold: 1) To demonstrate that it is possible 2) To share lessons we learned that will hopefully benefit those starting out ## About Us We at Mirthwerx are a team of two: Thomas the self taught programmer and Tsung the artist who studied classical animation at Sheridan. We met 20 years ago in highschool and have tried to make a game ever since. Before we embarked on this project, I had been writing business web/mobile software with Microsoft technologies for about 15 years. With this background, we knew how to build software properly (OOP, design specs, usability concerns). But you will see later how we failed to apply it. # Part 1: Design and Prototyping ## Technology From day one, we knew we wanted two things: 1) Android is the future, but iPhone is the now. We will build for both 2) We want to build on a windows platform with familiar environment and tools I started investigating the Mac platform and XCode by buying a mac-mini. After spending a day with ObjectiveC I knew I did not want to work in that language at all, it would drive me batty. Fortunately we could address both goals with one solution: Marmalade (formerly called Airplay before Apple started calling everything Airplay). Here you can see using VS2008 C++ debugging and tracing in real time with an iOS emulator Marmalade allows the user to write once in Visual Studio C++ and run anywhere (iOS, Android, Blackberry, Windows Phone, Bada, and more). The simulator is excellent, with all the performance monitoring you’d expect, so it was a total win finding this technology. The pricing for independent developers is also very reasonable. ## Design Given this was our first title, we wanted to keep the design of the app simple. The initial concept was this: The player swipes their finger to tickle monkeys in a farmer’s field. The monkeys come more and faster in each level. The end. It seemed so simple at the time, and there were only two of us, that we thought we didn’t need a proper specification document. Instead we used Xmind (free!) for mind mapping all our ideas and kept “the design” in there. The game was intentionally art heavy, as our artist was able to work full time on this project, but I was only able to work after hours/weekends. Mind Mapping is a powerful way to capture ideas quickly and organize them well for later reference. Xmind is a free open source tool for mind mapping. ## Prototype In business software an initial prototype for the users is critical. It removes all the guess work that comes from reading and interpreting a Word document. Rather than programming a prototype for real, we used an extremely powerful and inexpensive ($40 for a registered version!) game making tool called GameMaker 8. This allowed us to throw together the graphics that had already been drawn with a few play mechanics and see if we had something fun or not. I think all in the first prototype took 20 hours. Since it was running on a windows screen, there was no way to test the actual touch/swipe mechanic, so we just resorted to clicking, each click simulating a swipe. So the big question: Is it fun?

First prototype of Catch the Monkey made in Game Maker 8

No. It was not fun. We changed around several variables (speed of monkey, clicks to make them laugh, number of monkeys at one time) but it was just too simple. There wasn’t enough to do. We couldn’t see playing it for more than 2 minutes. We had no desire to make a “gag game” so we went back to the drawing board.

In our design brainstorming session we came up with the idea of using different kinds of tools to interact with the monkeys. Tickling was just the initial tool, a feather, but later you could get other tools. This seemed to have some promise. So we thought up several types of tools, narrowed it down to a few that were easy to put into a prototype, and then made prototype 2. In this version the player has an inventory of each tool. When one ran out, the farmer would call his wife for a refill which would appear in a few moments. It made the player have to think about what tool to use when. We also gave the player control of the farmer, they could direct the farmer to walk to certain areas or pickup a certain monkey. Finally we added the concept of catching stars. Every so often a star would pop out and the player would have to click it to catch it. Stars would be used later for upgrades, though we never built it into the prototype. So: Is it fun?

Prototype 2 Made with Game Maker, notice the inventory counts for the differing tools

Yes and no. There was a kernel of fun in there that was trying to get out, but there were still many things blocking it. We knew choosing (essentially strategizing) between tools was fun and catching stars was fun (it was spontaneous, different, and difficult). We dropped controlling the farmer (too cumbersome), dropped the refill concept (too complex and arbitrary). We needed a game mechanic to allow the player to strategize and manage resource(s).

I must note that when we prototyped, we didn't just do it amongst ourselves, but with others who were not involved in the project to get their honest feedback. Those working on a project are too biased to give a proper perspective to what they are testing. You’ll see later how this also came to bite us in the butt.

## Conclusion

At this stage we sat down for our third and final all day brainstorming session. We went through many concepts before considering the mana/cooldown mechanic in WoW. In WoW the player can’t just cast all the spells they want, they have a mana bar limiting the number that can be used in a short period of time. But some spells are so powerful that while they do use up mana, they must cool down for a long time (several minutes) so they cannot be used in a single battle. We felt if every tool required a common energy pool, but had varying cooldowns, we could strike the strategic balance we were looking for. By having enough variables we could keep things fresh and interesting for the player, and therefore they would be engaged and have fun.

One additional thing we decided was to create Star Powers. Stars to this point were only used as a currency to purchase upgrades, but a Star Power is a special ability that can help you now mid level for a certain cost in stars. By making stars dual purpose, and facing the player with a decision for a momentary benefit now rather than a long term pay off later, is a great mechanic we tried to bring to other aspects. It became a fun challenge for us as designers to make star powers that were really really useful, but the smart player only uses sparingly so they can get all the upgrades.

The final toolbelt design.

With the design phase basically finished (design happens all the way through), we proceeded into building the core game.

# Part 2: Building the Core

## Intro

In the first article, we covered how Catch the Monkey started from initial simple concept, to the technology we chose, through the prototyping phase. At the end of prototyping we had a greatly increased design, but despite knowing better, we didn’t document it thoroughly. We knew we had 12 tools to create, 10 types of monkeys, and some vague concept of a store which would allow the purchase of upgrades. How many upgrades and what they would do was not finalized. It was time to start coding!

This article is longer than the previous, I have attempted to keep it of reasonable length by highlighting only the most interesting aspects from the core construction phase. If you have a specific question, just post a comment and I’ll respond.

## We Going to Do this or Not?!

As mentioned in the first article, the artist was working full time but I as the programmer was only able to work part time as I was required by other aspects of the business. The project dragged. It finally reached a point where the project would be cancelled due to lack of progress. Instead, I mapped out the time remaining to build the game. About 6 weeks (50hrs x 6 = 300hrs) should do it. I made an extreme decision: I booked a 6 week hiatus from work to go to my cottage and focus 100% on the game. While my wife was less than thrilled, she was supportive of seeing me get the game done. It was time to go “all in”. Hind sight confirms this was the right way to recover the project.

## Our Single Biggest Mistake

Not having a properly defined design document would appear to be our largest mistake, but we made one that completely dwarfed it.

If you study the zombies in Plants vs Zombies, you will see there are many types of zombies, but they are made up of several graphical parts (head, body, arm, arm, legs) and several optional decorators (pylon, helmet, paper). By reusing and varying these components you can have many different types of zombie with minimal memory requirements. We wanted a similar approach with many kinds of monkeys each with varying abilities and weaknesses.

However, and we painfully learned this later, if you want to have this kind of reuse, you have to lay down very specific rules of what the characters can and cannot do. Notice in plants verses zombies that the zombies always face the camera (like the 2D South Park animation). No matter what they do, they never turn away from the camera to a profile view.

Well, early on in our animation and prototyping we decided when the monkey arrives at a plant he will plop down, TURN HIS BACK, and begin digging. Then when he gets a potato, he will TURN BACK and proceed to eat it. We completed all the artwork for the regular monkey before we discovered what a problem this was. When we wanted to have a hat monkey, we thought we would just create a separate hat object, attach it to the monkey, and off we go. Well as we did it we realized the hat (or vest, or sunglasses) has to turn with the monkey as he turns away from the camera. This requires one decorator frame per monkey frame and pixel perfect alignment. This means a whole host of painstakingly researched coordinates per frame to get it all to look right. It was so much work, and we didn’t want to redraw the digging animation, so we made an expedient decision: just duplicate all the frames for the regular monkey to the hat monkey with the hat pasted right into the frame. The artist went ahead and did this for each of the 6 additional types of monkeys.

Here is the math of why this was such a problem later:
1 monkey has a set of interaction sprite sheets (fear, ducky, laughing, walking, climbing, etc.) taking about 20mb of VRAM memory.
7 monkey types x 20mb = 140mb VRAM
The iPhone 3GS (iPod 3+) only has ~55MB of VRAM available (with a 15MB heap) before it starts crashing.
We had initially wanted to target the iPod Touch 2+, but it has only 30MB of VRAM and it became impossible. So we increased the system requirements to iPod 3+ and scrambled to get the VRAM down. We’ll talk more about this in the next article.

So the lesson is always map out memory requirements during the design phase, before you build it, rather than in the middle, or after. Had we of known the ramifications of the monkey turning away from the camera we would have gone a different direction with the art and the game wouldn’t be noticeably different.

## Cute Monkeys in a Nasty Real-Time World

Many business developers I know avoid writing multi-threaded solutions when they can avoid it. Why? Because the race conditions that can occur between two separate threads doing their own thing are a nightmare for testing. There are so many permutations of what could be happening simultaneously in the application that if it crashes, it is difficult to reproduce never mind fix permanently.

When it comes to games, they are already real-time in that the Update() loop is executed every so many milliseconds not matter what. There is no concept of “blocking” calls like there is in Windows Forms development. This is just the way games are, and this is not what I’m referring to.

I’m talking about a real-time game verses a turn based game. A turn based game waits for user input, then responds accordingly; while waiting for user interaction there may be things happening on screen, nice effects and such, but the actual state of the game doesn’t change. In a real-time system the game state is constantly changing regardless of player interaction.

For our first time game, we NEVER should have chosen to do a real-time game.

Catch the Monkey was an incredible amount of effort to make everything work in a constantly changing environment. The number of testing scenarios is probably 20 times greater than a turn based system. The ability to replicate scenarios is extremely difficult, even when programming specific unit tests to occur. There was a point late the construction phase I wasn’t sure I could ever get it to stop crashing. Fortunately Marmalade has some amazing memory monitoring tools built into it I was able to find all the issues (I think!).

We learned this lesson so bitterly the next title we are currently working on is turn based.

## Object Hierarchy

Obviously the power of OOP is the ability to build small, focused, encapsulated objects and then work with them at a higher level. My goal was to create an object hierarchy that knew how to instantiate, move, and render itself.

## Initial Marketing

As I write this fourth part, our game has been out in the world for 22 days. Sales haven’t skyrocketed, so we’re in no position to advise on how to market a game. However, there are two things we can share.

First, Apple controls the app store. They make their decisions based on volume. The sections like “What’s Hot” and “New and Noteworthy” are driven by volume. The more volume you can drive in the initial days, the more likely you are to appear in those sections. Obviously the key is to get into the “Top 100 Free” or “Top 100 Paid”. The only way you get there is through volume.

We've made it to #45 in the Family What's Hot. Go little monkey! Go!

Secondly, we knew review sites are important to get initial buzz going, but how do you find all the review sites out there? A google search will return some of the biggies, but also blogs that haven’t been updated in 2 years. So we devised a clever way to make a short list of review sites: most games put their reviews or quotes from review sites in the top part of their app description. By clicking through about 20 apps we were able to compile a list of 41 respectable mobile game review sites.

Most if not all review sites work from a backlog of about 3-4 weeks. And they all want a promo code to get the game for free, they won’t pay money for your app. Apple allows you 50 promo codes per release. Once you make a new release, the unused promo codes are invalidated.

In the 3 weeks we’ve been waiting, we’ve had 1 review come back. Fortunately it was a good one.

For our next title we’ll be doing more on the pre-release marketing side to get the game buzz out before release. As we were taking so long on Catch the Monkey and we didn’t really know if or when we would be done, we had to forgo pre-release marketing.

## Conclusion

Well, there you have it: a summary of our ups and downs over roughly 2 years trying to make an iphone game.

We set a goal, and despite great difficulties, achieved it. Beyond this, three things have brought great satisfaction:

1. Our first review came in:
http://cdn.famigo.com/static/images/famigo-approved.png
We received 4/5 stars and an editor’s choice award from the family mobile gaming site famigo.com. It’s nice to know someone objective thinks what we made is good!

2. A review someone wrote on the US store:
How fun can catching monkeys be? Hours of fun! I love this game because it's something for my kids to do that's different from princess games and phonics—and it’s something that I can do when I’m commuting, waiting for my next appointment, or just to relax. This has got to be one of the best non-violent games I’ve ever seen. Great graphics, good story, and entertaining for everyone.

3. The popularity of these articles.
When we first set out to talk about our experience, we didn’t know who would be interested. Over 3,000 reads and counting on the first article makes all this writing effort worthwhile! Thanks!

What’s next for Mirthwerx?

We’re currently working on a few things:
• Playbook version (taking full advantage of having used Marmalade)
• Android version (dido)
• Free version (different from a lite version, it’s a different but similar game)
• And our second title which is a puzzle game for the masses (remember, turn based!)
I’ve enjoyed writing these articles, I hope they’ve been of benefit. I have some ideas for maybe doing an “encore” 5th article next week, but I’d be looking for questions or comments from people before I decide to do it.

Until next we meet,
Lord Yabo

## About the Author(s)

We at Mirthwerx are a team of two: Thomas the self taught programmer and Tsung the artist who studied classical animation at Sheridan. We met 20 years ago in highschool and have tried to make a game ever since.

This is a great article. Thanks =D
5/5
Great article indeed. You stated that the tools allow you to develop for wp7, too? I'd love to see this game on my Lumia.
Great write up, thank you!

Great article indeed. You stated that the tools allow you to develop for wp7, too? I'd love to see this game on my Lumia.

While the tools allow us to deploy anywhere, the hardware requirements do not. CtM is so chock full of animation that we aren't able to bring it to many other devices. We couldn't get the android tablet version to run on the asus transformer, but we could get it to run on the playbook. It has to do with how the OS/Device allocates memory and our way of utilizing it.
Can you break down the 2 years of development? Like how long it took to write the tool, design..etc.

Great article.
Very useful article, and well written too - many thanks!
/ Babs
thanks SOO much for the article! i love to hear updates on how the game is doing.

great article!!
/ usmanjin
My typical app development workflow involves brainstorming, idea formation, validation, feature selection, design iteration and eventually, development, a chain of events that usually takes atleast a month.........

gold miner , guitar hero online , facebook timeline covers

Great  artricle!!!

Just a note.. this is an older article (last year) but we wanted to reprint it using our newer article system as we didn't promote articles very well a year ago (we're still working on that!).

This is an engaging, informative and refreshingly honest article. Best of luck with all of your releases.

now this is something useful. great stuff!!

Well, I'm currently moving from an business-software centered Information Systems Engineering degree into game development and this article has just about every piece of advice I was looking for! (even thought I will be using a quite different set of technologies for a very similar purpose)

Thanks!

PS: I had already dicided my first title'll be turn-based for the same stated reasons, yay for planing!

Thank you!

I found this SmartUML's link is broken.  And you guys could get startUML here :

http://sourceforge.net/projects/staruml/

Very very Nice and helpful.

Thanks.

/ SPIDER2016

عمل جيد وممتاز مرحبا بكم جميعا في العاب بنات

Note: GameDev.net moderates article comments.