You can read previous articles in this series here:
Part 1: Design & Prototyping
Part 2: Building the Core
Part 4: Testing, Release, and Marketing
You can find out more about Mirthwerx and our projects at our website.
At this point we had a working game, around 90% feature complete. The player could start a new game, play each level, interact with all 7 monkeys, use all 10 tools, save up stars, buy 28 upgrades in the store, use all 4 star powers, and save/resume their game. We declared ourselves feature complete. If we had created a more detailed design document we would have realized how untrue that statement actually was!
The Last 10% takes 90% of the Time
We didn't know how long it would take to establish a publisher relationship, so we started showing an early prototype to some publishing agents. One commented that the game core was good, we definitely have a quality AAA title here, but we still have a lot of work left for polishing. We thought that was a rather silly statement, and proceeded to finishing off the loose ends and game balance figuring we would be in the store in about 2 weeks.
This is where games are vastly different than business software. In business software, when we are feature complete with all unit testing completed, 80%-90% of the work really has been done. Integration testing reveals its issues, but they are generally just misunderstandings between developers and spec that need to be resolved. A real-time game integration testing is about 50% of the work because of the layered interactivity/dependencies of the game elements to each other.
Getting it on a Device
Up until this point, the game could only be played in the Marmalade PC simulator. We still had no idea if performance would be an issue (memory or FPS) on real devices. It also severely hampered unit testing as the artist couldn't test the game at all. It was time to deploy to a device.
Marmalade Deployment Tool for making the IPA file
Apple is extremely careful of what can be put onto their devices. This is good as it cuts down on piracy, but it also creates a whole series of hoops you must jump through to sign your code and get device ids and certificates for deploying test builds to a device.
If you are using xCode on a mac (especially the latest version of xCode), it is a relatively straight forward process, where xCode takes care of most of it for you. All of apple's documentation tells you step by step how to do it with xCode. If you are on PC, well prepare for some hassle.
There are two things you must do: 1) Setup your machine for iOS deployments and 2) Setup your project for iOS distribution. Fortunately, the documentation in Marmalade 5.2 for how to create distribution builds is much improved over previous versions. There is a walk through that explains you to create a certificate, which you then upload to Apple, and download the Apple certificate(s) and where to put them.
With the PC setup, the project must be setup and signed for distribution. The Apple dev portal is used to assign UDIDs of devices allowable to an application. Apple provides a provisioning certificate used to sign your project. Marmalade has a deployment tool that appears when making a release ARM build of the project. You enter in provisioning and OS specific options into this tool (it saves the settings to the custom MKB file) and it does the magic of making you an IPA that can be deployed through iTunes to your iOS device.
All in I was able to get the game on my iPod in about 10 hours. This was a vital step, because we needed the touch screen to test our gestures.
Getting Jiggy with Gestures
If you recall, our core design was a player using their finger to tickle a monkey through swiping. After some prototyping, we needed other tools to break up the monotony of constantly swiping back and forth. One of our early influences was a GameLoft game Bailout Wars. The player flicks bankers to their doom, but you also have to make other motions as well.
We studied numerous games and came up with this list:
- Tap & hold
- Swipe Horizontal
- Swipe Down
- Flick Up
- Circle (clockwise or counter clockwise)
We chose Tap, Swipe Horizontal, Swipe Down, and Flick Up. (We also had Tap & Hold, but cut it later.) We tied these gestures to tools that we felt made sense: the paper bag, for instance, is placed on a monkey's head, so the player swipes the bag down onto the head.
iOS and Android support multi-touch (up to 10 points) but we decided to stick to just single touch. A touch is nothing more than a click event, so we inspect the s3ePointerEvent in Marmalade to capture it into a global touch variable like this:
void SingleTouchButtonCB(s3ePointerEvent* event)
g_Touches.active = event->m_Pressed != 0;
g_Touches.x = event->m_x;
g_Touches.y = event->m_y;
g_Touches.when = (int32)s3eTimerGetMs();
g_Touches.handled = false;
While it is all nice to know where a finger currently is, how do you know if they are making a gesture or not? The answer is you have to do that yourself.
A gesture begins when the finger touches the screen. From then on, the current position of that touch must be tracked at a regular interval until it is released (finger is lifted). The difference in origin, progression across the points, and exit must be analyzed to determine what kind of gesture was made. I used the Strategy Pattern in a generic Tool class with the child class for each tool implementing their own unique gesture recognition.
So while this explains the technical on how to do gestures, there was a lot of refinement necessary to get it to "feel" right. It is amazing how different each person performs a simple left/right swipe. Some people do very gentle little swipes of 10 pixels, while others go all the way across the screen. Some do it straight across, others on a diagonal. Some do it so slow it didn't register, and some do it so fast it didn't register (we found the "right" granularity for the timing interval of each point is 50ms). At the end of the day, we went from a very strict gesture system where a horizontal swipe couldn't have more than 20 pixels of vertical movement, to a very loose one where just about anything goes!
Saving the Story To Last
Catch the Monkey is an action game. While we need some sort of story to set the context for the player's actions, we knew we didn't need Crime and Punishment here. From the very beginning, we had a rough story outline:
A farmer in South Africa has a potato farm. As he sits down to lunch with his wife, a monkey is spotted in the field. He goes outside to take care of the monkey, but more and more keep coming. Eventually he overcomes all the monkeys and returns to a cold lunch. Fin.
Ok, so we aren't winning any Oscars for screenplay writing, but it was enough to get going so we focused on building the game and then would circle back to the story.
When it came time to do the story sequences, I decided to involve my friend Rob for help. We sat down one evening to hash out the story. He started asking basic background questions for which I had no answer:
- How well does the farmer do, is he poor or rich?
- How's his marriage, good or strained?
- What's his demeanor: happy or surly?
- How long have they lived in this location?
This may seem like silly fluffy stuff, but it isn't. I knew from research in how to write fiction that before you have a story, you have to have a character. It is the characters that drive the story and we didn't have characters. So Rob and I had to define the characters first.
Throughout the game the player unlocks new tools. How are these communicated to the player? We decided it was by the farmer's wife "finding" them and making them available to the farmer in his tool shed. We chose to use a dialog sequence to put the tool arrival into some context. Well, you cannot write effective dialog (even simple monkey catching dialog) without knowing the characters voice. So these "fluffy" questions had to be answered before we could write a single line of dialog.
We then had to answer the two big questions:
1) Why are the monkeys coming to the farm in the first place? (Why now and not a year ago, or why not a year from now?)
2) How is it that the player stops the monkeys from coming (by resolving #1)?
We went through a lot of ideas that night, but everything good we came up with changed the flow of the game, or introduced new characters (like a boss monkey), and we just couldn't afford to do all those changes this late in the game development. It was overwhelmingly evident we should have had this meeting in the first week of the game, not the last.
Before you can write a line of dialog, you have to know the character's voice
We wrote the best story we could without changing the game or requiring a lot of new art assets. The first rule of writing is "write what you know". In the end, I based the farmer and wife on myself and my wife. The problem the farmer faces of trying to get rid of the monkeys, which seems so simple from the beginning, becomes overwhelming and takes over his whole life. This is actually a metaphor for what the monkey game became to me. When the farmer bemoans the monkeys never ending, that's how I felt about the amount of work the game kept requiring. But in the background, unfazed, is the wife. Helping where she can, encouraging when needed. Many of the lines in the game are verbatim what my wife said. When the farmer's wife goes away on a girl's trip in the middle of it all, this also happened in real life.
Of course, all this is probably far too sophisticated for a simple action monkey catching game, but it is in there none the less.
Levels and the Game Master
I'll admit this up front: sometimes I'm just plain lazy. But sometimes laziness is the mother of invention.
When we built the second prototype each level had scripted events: when a monkey is to be released down a tree, the type of monkey, the size of a wave of monkeys at one time. Most of these events were time driven. This is how classic action games, like Capcom's 1942, are made. Each play through is the same.
It was a lot of work scripting each level with all the events, and frankly I didn't want to do it again in the real game. There are also problems with scripting: how do you know if the player is bored or sufficiently challenged? Releasing a monkey every 10 seconds may be fun for me, but too easy/hard for you.
So we tried to think of an alternative: what if we had a Game Master (to borrow the RPG term) that determines when, where, and type of monkey to release based on how well the player is doing. If a player is doing poorly it won't become ridiculously intense, and if they are doing well it won't get boring. We will define rules for the GM to behave by, and vary those rules from level to level. For instance, some levels the GM will be fast and furious, in others a slow build up. Even better, the GM can monitor things in real time, like the players energy level, and make smart decisions at the time of knowledge rather than guessing with scripting.
This seemed like a radical idea to us, so we weren't sure what the negatives would be to building this dynamic AI "level designer" just so I didn't have to do all that scripting.
I don't remember why, but for some reason I felt I should play Valve's Left for Dead FPS zombie game. I generally don't like zombie shooters so I had never played it before. I got it off steam and noticed somewhere in the description about "The Director", which is essentially a level AI that responds in real-time to the players to give different experiences each play through. Once I saw Valve did it, I knew we were on the right path!
If Valve did it, so can we!
It took a few days to build the Level GM, but once it was done it was a total win. No scripting required, all we had to do was define for the GM the resources it has (types of monkeys, total number of each monkey allowed at a time) and the level of intensity we want (earlier levels are easier than later ones).
In the book Andrew Rollings and Ernest Adams on Game Design (some of it is free on google ebooks) they explain how it is more fun to have waves of intensity followed by relief followed by intensity rather than constant intensity. Plants vs Zombies follows this formula perfectly by providing big waves of zombies followed by few zombies so you can rebuild. We implemented this concept by adding "moods" to the GM. Based on many factors, the GM will "go evil" on you and break the rules of intensity we set out. But at other times it will "go nice" and give you a chance to catch your breath.
We've detailed plenty of our mistakes in these articles, so we're proud to say this is one where we nailed it! We'll be using this approach in our future titles.
Game Balancing: Redeeming Features
Game balancing is tough stuff! There are no strict rules as to what makes something fun, especially in combinations. In the end we had to go with our personal play experience, and then test on others.
It took 6 weeks to make the core game, and another 10 weeks to balance it. As I look over my work logs, up until the last day we were changing cooldowns, upgrade costs, and energy costs. I could give many examples from our time of play balancing, but I believe the most valuable lesson I can share is how we took something that wasn't good and made it great. This at the core is what the balancing phase entails. So here is the brief story of the Paper Bag:
In reading a book on fiction writing it stated every character thinks they are the hero of the story, so give them a chance to shine. Think of how in Lord of the Rings Sam, a tag along character for much of the story, gets to be the hero when he carries Mr. Frodo up Mount Doom. I think this applies to game features, in our case every tool should get to be the hero and legitimate chance of being a player's favorite.
Each tool has its own purpose. Some are for taking out individual monkeys, some are for dealing with groups. Some are to prevent them from coming in, some are for dealing with them as they come in. Some require the player's attention and dexterity, some are great because they don't require any attention.
The paper bag is a high cost high impact tool that completely paralyzes one monkey (intended for a high threat monkey) for a long period of time. It also has an Area of Effect (AOE) which causes other monkeys to be distracted and laugh at the silly monkey stumbling around.
In the first iteration, once the bag was placed onto a monkey's head it immediately made all monkeys in range laugh. Play testing revealed players preferring other tools over the bag. It's not that it was bad, but it wasn't good.
We played around with the cost, cool down, and range. At one point it made all the monkeys in the field laugh. But still the other tools were better.
Then we thought: what if instead of a onetime AOE effect it had a continual AOE? For the entire time the target monkey stumbled around any monkeys in range would be influenced. This changed the best time to use a paperbag from where a lot of monkeys are currently, to where a lot of monkeys WOULD BE. By making this AOE effect continuous we now had a very effective crowd control AOE tool while incapacitating one target monkey.
Now the paper bag is fantastic!
During game balancing some diamonds are in the rough. Some are rougher than others. It requires determination to cut into them to let the inner brilliance shine forth.
Features: Knowing when and how to say NO!
A game can be built forever. Should I even mention the obvious example of Duke Nukem Forever? When the goal is to create a rich enjoyable play experience, the temptation is to keep adding more and more features, because more = better, right?
Sometimes no. In our case we had to ship the game, not just for financial reasons but for psychological ones. After 2 years it is hard to keep up the enthusiasm. As we played and balanced, many ideas would come up. For instance:
- We needed to add an easy (casual) mode for non-gamers or younger children
- We needed a visual and audio warning to the player that they just lost a plant (seems obvious now, but it wasn't added until the second last day)
- We needed more sound effects
- We changed the "level complete" requirement from reaching a certain number of monkeys, to reaching a certain number AND clearing the whole field
All of the above were implemented, but they were unscheduled tasks and our release date kept being pushed further and further out.
To decide what HAD to be done we asked ourselves these two simple questions:
[indent=1]1) Is the game broken without it? Meaning it is too hard to play, or doesn't make sense to the average player, or boring/repetitive
- We needed to add an easy (casual) mode for non-gamers or younger children
- How well does the farmer do, is he poor or rich?
[indent=1]2) Would we be embarrassed to release without it? Meaning it is obvious we cut a corner.