Jump to content

* * * * * 3 votes

How we Built an iOS game on PC: Part 1/4: Design and Prototyping

iOS C++ iPhone PC
4: Adsense

How we Built an iOS game on PC: Part 1/4: Design and Prototyping
  • Brainstorming free version features
  • 45th in the Family What's Hot
  • Lots of ITunes Stores
  • Tutorial Final
  • Tutorial First Iteration
  • 14 Testflight
  • iTunes Connect
  • We done yet?!
  • Watergun got cut
  • Dialog Sequence
  • Intro Story Board
  • Boots Monkey Feels the Confusion of the Mysterious Paper Bag!
  • The Paper Bag Tool
  • Level Game Master
  • Marmalade Deploying Tool
  • Hat walk sprite sheet
  • Hat walk strip17
  • 8 Scene Management
  • 7 GUIStack
  • 6 Core

This series chronicles Catch the Monkey from ideation to sale worldwide in the App Store.
You can read other articles in this series here:
Part 1: Design & Prototyping
Part 2: Building the Core
Part 3: Balancing & Polishing
Part 4: Testing, Release, and Marketing

You can find out more about Mirthwerx and our projects at our website.

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

Posted Image

About Us
We at Mirthwerx are a team of two: Thomas the self taught programmer and Alex 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.

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).

Posted Image
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.

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.

Posted Image
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.

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?

Posted Image
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?

Posted Image
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.

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.

Posted Image
The final toolbelt design.

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

Next Article
In part 2 we’ll cover the core design patterns, the trouble with real-time systems, and the single biggest mistake we made.

Feb 02 2012 06:40 PM
Thanks for sharing!
Feb 03 2012 06:50 AM
Great article, when is part 2 coming?
Feb 03 2012 10:06 AM
In a week! Check back next wednesday
Feb 04 2012 11:44 AM
I already learned something. I think XMind will be a valuable tool for my projects.
Feb 07 2012 01:54 AM
Agreed, XMind looks very useful. I'm hearing more and more about Marmalade and they all seem to be good things.
Feb 08 2012 10:43 AM
Marmalade is fantastic. In these articles I can't go into all the nitty gritty details, but I'll give just one example. Marmalade tells you if you have a memory leak. Think of how awesome that is in C++ having something that tells you if you forgot to delete a resource properly in your destructor! And not only that, it tells you the ID of the memory allocation you didn't delete, for instance: 2919. This isn't the address, it is marmalade's internal reference number. Then you plug that number into the build config file and the game will stop and break when memory ID 2919 IS ALLOCATED! This made it extremely easy to see what objects I forgot to wind down, a total life saver!
Apr 05 2012 08:14 AM
Hi LordYado,

that sounds really really useful!

Where is the 'build config file' and where/how exactly you "plug the ID number" to it?

May 01 2012 04:34 PM

Hi LordYado,

that sounds really really useful!

Where is the 'build config file' and where/how exactly you "plug the ID number" to it?


I'm not sure what you are referring to. In Marmalade there is an MKB file which holds all your special values, such as your code signing file, or author id, etc.
Oct 09 2014 02:12 PM

You can add memory breakpoint for certain memory allocation using

  1. [UTIL]
  2. MemoryBreakpoint=2

in app.icf.

Note: GameDev.net moderates comments.