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;
《Catch the Monkey》是一款动作类游戏。尽管我们需要创造一些故事去丰富玩家的行动，但是我们也知道这里并不需要犯错与惩罚。从一开始我们便设定了一个较为粗糙的故事线：
《Andrew Rollings and Ernest Adams on Game Design》这本书解释了如何通过减轻或增强每一波的强度去创造乐趣，而不是通过恒定的强度设置。《植物大战僵尸》便是有效地遵循这一原理，即先提供了较大波的僵尸，然后再提供少量的僵尸，让玩家拥有时间去恢复能量。而我们则是通过在GM上添加“情绪”去执行这一原理。基于各种元素，GM将变得更加邪恶，并打破我们所设置的强度规则。但是其它时候它将“非常体贴”，并提供给你喘息的机会。
我在一本讲述小说编写的书籍中看到一句话，每个角色都会认为自己是故事中的英雄，所以请给予他们发光的机会吧。就像在《指环王》中，当Sam带着Mr. Frodo朝着Mount Doom走去时，他便被冠上了英雄的标签。我认为这也适用于游戏功能中，在我们的例子中，每种工具都有可能成为英雄，并变成玩家最喜欢的工具。
在预发行时期，我们拥有一些安装了《Catch the Monkey》4个关卡演示版本的iOS设备。我们在旁边观看玩家是如何首次体验游戏。从中我们学到了两点：人们喜欢与猴子一起游戏，但是他们却不知道该如何做。所以尽管他们感受到了乐趣，但却因为不知道如何使用各种道具而沮丧不已。
《Level Up: Guide to Great Game Design》这本书告诉我们，游戏制作人是最不会判断难度的人。虽然我知道这点，但在实践中还是发现做到这点很难。显然，你最先需要取悦的便是创造游戏的自己，这便是你的第一道质量控制门槛。
我们也会选择小孩进行测试。为什么？因为他们没有其它事可做，可以一整天帮你进行测试。（当然也包括我们设计师的孩子）。我们发现小孩都很喜欢玩《Catch the Monkey》，但是中间游戏内容对于他们来说却太难了。
几天后，我们修正了Level GM AI中的漏洞，并发现它比之前更有效了。所以我们便决定回到简单和一般模式而不是一般和复杂模式。
我们知道，我们的游戏并不能运行于iPhone 3GS或iPod 3以下的设备。我发现其它游戏也会在应用商店中列出这一要求。因为我并未在Marmalade的部署中找到设置方法，所以我便认为应用商店会帮助我做到这一点。
苹果并不允许开发者在应用更新时设置比最初应用更低的限制。也就是，如果你最初的版本能够运行于iPod 2上，你就必须确保之后的更新还能继续运行于iPod 2上。我们便搞砸了应用更新。最终在苹果的支持下，我们将要求添加到了应用描述上。我们当然知道很少有人回去阅读描述，但这却是我们唯一能够补救的方法。
过去iTunes Connect允许你通过http进行上传，但是现在却不可以了。在iOS SDK中还有一个二进制上传程序能够帮助你检查并上传二进制内容到苹果上。不过该上传程序只能用于mac。所以当你是在PC上制作并测试整款应用时，你便需要花10分钟时间在mac上上传你的最终二进制内容。曾经有人建议可以直接到苹果使用演示mac进行上传。不过因为我自己拥有mac mini，所以便不需要担心这一问题。
我们也决定在今后的游戏中将更加注重发行前的市场营销，从而让我们能在游戏发行前获得更大的曝光率。而因为我们在《Catch the Monkey》上投入了太多时间，并且不清楚何时才能真正完成游戏，所以我们便放弃了预发行市场营销。
Part 3: Balancing and Polishing
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
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:
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.
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
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:
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
2) Would we be embarrassed to release without it? Meaning it is obvious we cut a corner.
The second question may sound a little strange. Personal pride and brand reputation are at stake writing a game. If we tried our best and failed, that is ok. Sometimes that is life. But if we cut
corners, therefore reducing chance of success, and we failed, that is just being lazy or foolish.
To reach our timeline some things had to give:
Cut a type of monkey
Cut two tools
We wanted level ranking and gamecenter integration, but we had to cut it
Watergun didn’t make the cut. Maybe there will be a sequel we can put it into!
Finally, the hardest thing we had to do was what I’ll call “compress” the game. Our goal had always been to have 50 levels, each of about 3 minutes (earlier ones are shorter, later ones are longer) for 150 minutes of perfect play.
Upon play balancing we saw there were fun levels and not as fun levels. Fun levels generally had the player getting something new (a new tool, star power, monkey type). So we decided to compress the game by removing the low fun content; 13 levels. It hurt to see all that work go away. But in the end what the player now experiences is peak to peak fun with no valleys.
After spending twice as much time polishing the game as it took to build it, we had a game that was truly feature complete. It was fun, it flowed well, and we are proud of it. It takes some going,
but once you hit the sweet spot mid way through the game it is a ton of fun. We were finally ready for testing with others.
Part 4: Testing, Release, Marketing
We had a game! Hurray! It worked, it played well, it has a beginning, middle, and ending. We were ready to get the sucker out the door. But before release, we had to go through the final stage of development: testing. Wow, what an eye opener!
No one Knows How to Play Your Game, and They Don’t Care to Learn!
I submit I may be the strangest person alive.
I grew up in the 80’s and early 90’s. This is where many of my early gaming habits formed. Back then when I bought a new computer game, such as Civilization, Ultima, or Wing Commander, I would sit down and read the entire manual cover to cover before attempting to play the game. And this was when manuals were works of art: the civilization manual was over 100 pages and filled with fascinating sidebar historical facts. I continued this practice, though I’ve stopped now that the manuals are nothing more than epilepsy warnings and telling me where the square button is on my controller. (Fortunately board games still have amazing manuals, so I can enjoy those )
The good old days when games were hard and manuals were thicker than your arm!
Apparently no one else read manuals so the gaming industry moved away from them altogether. Players want to play, not learn how to play. I sort of knew this, I read about it in game design books, but I didn’t have the experiential knowledge of it. It quickly came.
At our pre-release party (unfortunately 3 months before the actual release, but who’s counting) we had several iOS devices with a 4 level demo version of Catch the Monkey installed on them for people to play. We watched people pick up the game and play it for the first time. We learned two things: people enjoyed playing with the monkeys, but they had no clue how to do it. So while they had fun, they were frustrated not knowing how to use the various tools.
It seems obvious as I write this, but we discovered our need for tutorials built into the game. All I can say is that when you work on something closely for 2 years you lose track of what is “intuitive” and what isn’t. Observe strangers and reality will come crashing in. So, we used our character dialog system to retrofit in a tutorial system.
First Iteration of Tutorials. Nobody reads em.
Weeks before release, we tested with a focus group of teenage girls (our demographic) to see how they enjoyed the game. I squirmed in my seat as I watched them tap “next, next, next” and
completely bypass the tutorial to get on to the game. Once there, they didn’t know how to use certain features, started losing, and became frustrated.
Final version of tutorials. If you can’t follow that, there’s no helping you!!!
We learned valuable lessons as we went through three iterations of tutorials:
People assume they already know how to play your game. I can’t for the life of me figure out why they come with this belief, but they do. Work with it, not against it.
People don’t want to learn (because of the above), they want to play. So teach them one basic thing and set them off playing
When teaching, we observed the average player’s patience is two: Two screens of slides, two steps of interaction, two dialog boxes, then they don’t care anymore and want to skip forward
After playing, people want to learn. There is a correlation between how long they play and how interested they are in learning to play. In the first 2 minutes, they have 0% interest, at 5 minutes they have 10% interest, at 10 minutes they have 50% interest. You have to space your lessons appropriately
Remove all flowery “in character” text from the tutorial, they want to learn as quickly and efficiently as possible and could care less if a character starts each sentence with “<gwok>”
They don’t want to read, they want to do. Make the tutorial visual and interactive
Pre-plan your tutorials into the main story/progression of the game. Don’t do what we did and try to retrofit it in, it was a lot of work after the fact
Testing with Testflight
As previously mentioned, iOS locks down the devices to which you can install a binary. This requires the unique UDID of each device, registering it through the apple portal, including the provisioning profile at compile time into the binary, and then copying a provisioning profile to the device through iTunes (which provides zero feedback if it was done successfully) and finally
copying the binary to the device through iTunes. I can’t think of a process more antithetical to the apple “it just works” mantra. So, you can do all that OR you can use testflightapp.com.
Testflight for build distribution during testing; epic win!
With testflight, you send testers (family, friends, enemies) an email link and they go to it on their device. Testflight takes care of finding the device UDID, os version, make/model of device, and
sending it to you the developer, installing the provisioning certificate. As a developer, all you need to do is register the device id to your binary. Now you can upload a build (with release notes) to testflight, and everyone you autohrize is sent an email a link to download it. It bypasses all the silly itunes file copying. Testflight’s reporting allows you to see who has what installed. Valuable when they start reporting problems as you can definitively say “Oh, that’s because you’re on a build that was so yesterday! That build was terrible! Install the NEW build, it’s wonderful.”
Testing with Non-Gamers
Would you rather know about an issue during development, or once it’s released? Of course during development!
Testing with people who play similar games as the one you are making is very helpful. You can be sure you are meeting your demographics’ demands and they can often make suggestions or give articulate feedback on issues as they have a frame of reference.
However, we found great value in testing with people who have never ever played an electronic game in their life. You know who I’m talking about: your mother-in-law whose only game experience is yahtzee on the dining room table; the friend who didn’t know brick breaker was pre-installed on his blackberry.
The official term is blackbox testing. These people can confirm if your tutorials work, but more importantly they do things you never in a million years would do. But make sure you watch them closely, they won’t be able to tell you what they did or did not do. Here is an example:
We finished our final bug free never crashes build Dec 15. Over the Christmas holidays I showed a non-gamer friend the finished game. Within 2 minutes of playing he crashed it.
How? He never once lifted his finger from the screen. If you recall from part 3 about our gesture system, it tracks the current finger position every 50ms. Well if the player never ever lifts their
finger from the screen, it becomes one giant gesture of 2,400 points after 2 minutes (affecting performance). Even worse, the initial target object of the gesture may be destroyed while waiting for the gesture to finish, resulting in a NULL reference and therefore a crash.
It was relatively easy to replicate and fix once I saw what he did, but I have to admit I never imagined someone not lifting their finger!
How Do You Know When You are Done Testing?
This may seem like a silly question, especially coming from a business software background. In business software you would already have all your test cases written before hand (Right?) and execute them. When they all pass, you know you are good to release. Typically we would then get the customer to test the application in a pilot project, and that is the “real world” test. If it’s good, we release.
Well in games, it’s different. There is no “customer” to sign off and take responsibility that the application is good, you just have to decide at some point: it’s done.
Release too early, and the game will crash or misbehave for customers. Release too late, and you’ve squandered valuable effort that could have gone into another title.
I was listening to the MIT Open Courseware on Game Design and they asked this very question: how do you know testing is done?
Their answer: When you are out of time.
When you can’t take another step forward, you might be done testing.
That seemed like a cheeky answer, but having now lived it, I agree. Now, of course, we made certain all features worked, it was as fun as we could make it, and it didn’t crash. (Of course now as I
write this we’ve heard reports of a bug in one of our tutorials, oops!). The game will never be perfect, there is always more to add, more to test. There comes a point where you have to draw a
line in the sand and ship it. For perfectionists, this is a very difficult thing to do. I am fortunate that I’m not working solo on this project, both the artist and I together were able to agree the game was ready to go out. That gave me confidence I wasn’t deluding myself or just fed up. J For those soloing it, I recommend you ask a friend to be your “quality control” and help give you the thumbs up for releasing.
Judging the Difficulty
I read in the book Level Up: Guide to Great Game Design that the game makers are the worst people for judging the difficulty. So, I knew this going in, but it is still difficult in practice.
Obviously the first people that need to be happy are the ones making the game, that is your first quality control gate.
We also tested on young children (3, 8, and 9). Why? Because they’ll test for free all day long and they have nothing better to do. (And they are the artist’s children). We found that young kids
love to play Catch the Monkey, but the mid game was too hard for them. So thinking this was a secondary market, we created an Easy mode that gives the player more energy and reduces the maximum number of monkeys in the field at a single time. The kids loved the easy mode and were able to finish the game, so we were happy.
Later, when doing focus group testing, two of the teenage girls couldn’t get past a certain level and were getting frustrated. We recommended they restart the game in easy mode. As soon as they started playing in easy mode they said “Oh wow, this is much more fun.”
At this point we had a dilemma: do we make easy mode normal mode, and normal mode hard mode? We did and made all the code changes to reflect this.
Then, a few days later, we fixed a bug in the Level GM AI and found it was working much better than previously. So we flipped it all back to Easy and Normal rather than Normal and Hard.
Now that we have released and friends/family have been buying it, the most common complaint we hear from casual gamers is that it is too hard. When we tell them through facebook to try it on easy mode, they always come back with “Oh wow, this is much more fun.” Even post release we’re still learning things the hard way!
Here are the key lessons we’ve learned:
Make the game too easy, rather than too hard. Too easy can still be enjoyable, too hard never is.
Casual gamers are not looking for a challenge, they are looking to pass the time. Easy fits within this expectation.
Don’t make the game hard with the ability for the player to opt into easy. Make it easy with the ability to opt into hard.
Releasing to the App Store
After making it through the arduous testing phase, we were ready to release this sucker. This has several steps:
1) Making a build signed for App Store, as opposed to ad-hoc provisioning build
2) Uploading the binary to Apple
3) Waiting for approval
It was time to fire up Visual Studio one last time and create an app store build. It was relatively easy to do, I simply copied the deployment options from my test flight build in Marmalade and off I went. Now here’s the thing: you cannot test your app store build before you upload it. Why? Because it can only be installed on a device through the app store. So better get it right!
And we didn’t.
iTunes Connect is how you control your app in the app store
I made two blunders when doing the final build. The first was somehow I didn’t copy the proper icon image settings from the internal build to the final build, so it went to the app store with the
default app icon. Doh! The second was far, far worse.
We knew our game didn’t work on anything below iPhone 3GS or iPod 3. I saw other games show this requirement in the app store along the left column. I didn’t see any way to set this through
marmalade deployment, so I assumed it was done in the app store itself.
Well when you upload an app, especially your first, iTunes Connect walks you through a wizard. The answers you provide can never be changed, you got one shot to do it right. These we did right.
Again, I didn’t see anywhere I could set the requirements, so I figured it was after I uploaded the binary. I uploaded the binary and it went into the queue for review and approval.
Well, 8 days later, it was approved. But still no way to set the system requirements. It wasn’t until later that I found out you need to modify the plist.info file to include the OpenGL ES version
to 2.0 to target the devices we wanted.
No biggie, I modified the plist.info file and proceeded to upload the new binary.
Apple does not allow a developer to set more narrow restrictions on an application update than the app first had. So in short: if your initial version says it will run on iPod 2, you can’t later
do an update that makes it no longer run on iPod 2. We screwed up the one thing you cannot correct through an app update. After much back and forth with apple support we had to resort to putting the requirement right into the app description. We already know people don’t read, but it’s the best we can do at this point.
And one final thing to know about releasing to the app store when you make your app on a PC: you REQUIRE a mac to upload the binary to apple.
ITunes Connect used to allow you to upload through http, but no longer. There is a binary uploader program in the iOS SDK that checks and uploads your binary to apple. That uploader program only works on a mac. So while you can build and test the entire app on a PC, you need a mac for 10 minutes to upload your final binary. I’ve seen someone suggest just going to an apple store and using a demo mac to upload. In my case I already had the mac mini, so it wasn’t terribly inconvenient, but it was a real surprise.
Releasing to the World
By default, all apps uploaded to apple are released to every itunes store in the world, unless you specifically turn a store off.
There be a lot of iTunes Stores. Fortunately you only need 6 translations to cover them all.
We had always intended to release to multiple countries, so we tried to minimize the amount of text in game and use symbols where we could (the monkey story sequences use icons rather than text for this reason, although it actually made more sense conceptually too: how do you write “monkey speak” anyway?!).
The key is to get your app description translated from your native language into the various app store languages. It costs about $100 per language to use a translation service to translate our app description. Of course, the difficulty is we have no way to judge how good the translation is!
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.
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:
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.(source:gamedev)