本文记述了《Catch the Monkey》从创意到销售的过程。
Marmalade允许用户使用Visual Studio C++编写，然后在其他系统上运行（iOS、Android、Blackberry、Windows Phone、Bada等）。这个模拟器不错，完全达到期望，所以发现这个技术真是赚了。这个价格对独立开发者而言，也是非常划算的。
我们不是直接编写原型，而是使用了一个相当强大和便宜（注册版仅需40美元！）的游戏制作工具GameMaker 8。 借助这个工具，我们可以把已经绘制好的图像和若干玩法机制组合在一起，看看是否能得到有意思的结果。我们制做第一版原型花了20个小时。因为它是在windows上运行的，没有办法测试真正的触摸/触击机制，所以我们只能用点击模拟触击。所以就出现了一个大问题：这样会有意思吗？
（使用GameMaker 8制作的第一版《Catch the Monkey》的原型）
（使用GameMaker 8制作的第二版《Catch the Monkey》的原型，注意屏幕下方的工具带）
在第一分部中，我们简介了《Catch the Monkey》从简单的概念化到技术选择以及原型制作的过程。在原型制作后期，我们的设计充实了很多，但我们并没有把新设定完全地写进文档里。我们知道有12种工具、10种猴子和若干购买升级道具的商店的模糊概念。升级道具的数量以及各种道具的功能还没有确定下来。现在要开始编写代码了！
在崩溃以前，iPhone 3GS （iPod 3+）只有大约55MB的VRAM可用（15MB的堆）
我们最初希望以iPod Touch 2+为目标设备，但它只有30MB的VRAM，所以不能选它了。我们把系统要求提高到iPod 3+，同时争取减少VRAM。
在《Catch the Monkey》中，玩家要费很多功夫让所有东西在不断变化的环境下发挥作用。测试场景的数量可能20倍于回合制游戏。复制场景是极其困难的，甚至当程序性特殊单位的测试发生时。在构建阶段后期的某一时刻，我不知道怎么让它停止崩溃。幸运的是，Marmalade内置了一些非常了不起的内存监视工具，可以找到所有问题（个人认为）。
在我的职业生涯中，有一段时间我是不做模型的。当我知道Rational Rose、UML和建模时，我就一头扎进建模中去了。我总是自己模拟代码，甚至不对外公开的个人项目也是如果，因为我发现这是在代码建模以前思考问题的最好办法。Rational Rose（或任何合适的建模工具）可以帮助你一边思考一边设计。我使用Rational Rose已经好几年了，但当我准备做自己的项目时，我发现自己承担不起2000美元的版权费。幸好有开源社区提供的StarUML。StarUML是一个强大的、免费的对象建模工具。其实它与Rational Rose差不多（至少我在2003年使用的最新版本是这样的）。
看上图类设计图，注意两个基本对象：GameObject和UIObject。二者都继承Graphic的属性。Graphic包括了所有Marmalade 2D API交互作用，所以无论是猴子、故事板还是文本对象都必须渲染。
Scene系列将游戏分成一系列场景。在《Catch the Monkey》中有19个，如SceneTitle和SceneDialog。这些都从Scene继承通用界面，如Init()、Update()、Render()、Shutdown()。我创建了包含所与场景生成、关闭和转换有关的SceneManager单例。现在，我的代码可以更准确地感知游戏的状态变化。如果我想结束和开始新场景，我可以调用：
正如我前面提到的，我们的目标设备是iPhone和Android。虽然Marmalade是一个3D工具，但我们知道也能用它制作2D游戏，因此我们只要专注于Iw2D API。我会重点介绍使用Marmalade的2D API制作2D动画的基本原理。
# Provide access to resource objects via IDE
useTemplate “image” ”image_template”
if (IwGetResManager()->GetGroupNamed(“farm”, IW_RES_PERMIT_NULL_F) != NULL)
CIw2DImage* img = Iw2DCreateImageResource(name);
How we Built an iOS game on PC
By Thomas Henshell
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.
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
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.
Part 1: Design and Prototyping
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.
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.
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.
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
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.
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.
There was a time in my career where I didn’t do modelling. Once someone showed me Rational Rose, UML, and modelling I never went back. I always model my code, even personal projects no one will ever see, because I find it the best way to think through the problems before the code gets in the way. Rational Rose (or any proper modelling tool) helps you think through the design as you design. I used Rational Rose for several years, but when I went out on my own I couldn’t afford the $2,000/seat license. Fortunately the Open Source community came to the rescue with StarUML. StarUML is a powerful free object modeling tool. It is virtually identical to Rational Rose (at least to the last version I used in 2003).
Looking at the class design diagram, notice the two fundamental objects: GameObject and UIObject. Both of these inherit from Graphic. Graphic encapsulates all the Marmalade 2D API interaction, and therefore is necessary for rendering whether it is a monkey, a story slide, or a text object.
A GameObject is an object used in a GameScene (which is a level you play). It manages its own state, sprite sheets, depth calculation, scaling (based on depth), click handling, and hit detection. All play objects inherit from GameObject. UIObject is similar to GameObject, but is more lightweight and designed for non-play scenes, such as text, buttons, and images in the store or tool selection screens.
We used GoF design patterns as necessary. For example:
We used the Factory pattern for our Level class; feed in a week and day, and it spits out a formatted level object, complete with any necessary tutorials.
We used two singletons for caching image files and sound files called GraphicManager and SoundManager, so even though each object is responsible for loading/unloading it’s assets, it does it through these caches to minimize the actual memory used.We used a singleton for player state (number of stars, current progress, which tutorials have fired, upgrades purchased). This made it extremely simple to serialize/deserialize player progress.
We used the Decorator pattern for adding graphical effects to any GameObject, such as fade in, fade out, flashing, etc.
One of the early conceptual struggles I had was how to bring all the different types of screens (a store, a tool selection, story modes, title screens, option/menu screens, game modes) together into a nice organized OOP paradigm. While researching I found two excellent articles by iPhone game maker rivermanmedia:
The Scene System
The GUI Stack
I knew this paradigm was the way forward not just for this game, but probably all future games.
The Scene system breaks down the game into a series of scenes. In Catch the Monkey I ended up with 19, like SceneTitle and SceneDialog. Each of these inherit a common interface from Scene such as: Init(), Update(), Render(), Shutdown(). I created a SceneManager singleton that contains all the logic related to scene creation, shutdown, and transition. Now my code can be blissfully unaware of what else is going on at a higher level. If I want a scene to end and begin a new scene, I call:
If I want the new scene to be focused and on top of the current scene, I call:
The SceneManager knows if there currently are other scenes involved, winding them down appropriately, removing their assets from memory, doing a fading transition, then initializing and firing up the new scene. With this in place the real-time game now behaves more like a Windows Form application, with dialogs able to call dialogs and just let the OS worry about sorting it all out.
The second key concept is the GUIStack. The GUI Stack sits inside the SceneManager and replicates “focus” of a scene just like how Windows does for forms and dialogs. By pushing and popping scenes onto the stack, I can control which scene has its Update() and Render() code called. If a scene doesn’t receive the Update() call, it is effectively frozen in time (paused). In pure form, the top scene is the only one to have its Update() called, while all in the stack have their Render() called. Later in testing I removed calling Render() to every scene in the stack for performance improvement. For scenes that require a background scene (such as a dialog window appearing over top of the game screen) I Instead take a screenshot of the current state, then display that as a backdrop to whatever the current scene is.
Using Marmalade in 2D
As previously mentioned, we were targeting both iPhone and Android simultaneously with C++ in Visual Studio 2008. While Marmalade is a 3D framework, we knew we were making a 2D title and therefore focused on the Iw2D APIs. I’ll highlight the fundamentals of 2D animation with Marmalade’s 2D API.
As you you’ll see, Marmalade works at a pretty low level. This isn’t GameSalad here, and that is one of the reasons I chose it. Given the choice, I prefer the flexibility and power of a low level API rather than being limited to what a framework designer decided I should be able to do (or not!).
Marmalade works it magic by using a custom make file called an MKB. This file allows the user to define Marmalade libraries to pull into the project, source code, assets (sounds), fonts, and texture groups.
Marmalade has a resource manager that allows the management of image groups (texture groups) by defining them like this in the MKB file:
# Provide access to resource objects via IDE
You then define all your images in custom group files:
useTemplate “image” ”image_template”
Within the code you can test if resource groups are already loaded into memory, and then load/unload them through two simple function calls:
if (IwGetResManager()->GetGroupNamed(“farm”, IW_RES_PERMIT_NULL_F) != NULL)
Images are loaded (and automatically uploaded to OpenGL VRAM) by asking for the image by name (without the .png extension) by using:
CIw2DImage* img = Iw2DCreateImageResource(name);
Once you have an image in memory, it can be rendered simply by calling the image drawing routine with the image you want, and the 2D vector position.
Marmalade automatically queues up all of the drawing calls in the order in which you called them, so this way you can control layering by doing your background draw calls first. So before I would run through my Render() routine I would sort all my objects by depth (lowest to highest) and then draw them in that sequence.
To complete the rendering I call these two routines, which tells Marmalade I’m finished, show it to the world:
That’s it. Call those drawing routines each frame and you’ve got yourself a game.
Simplifying Sprite Sheets
The game comprises over 4,000 frames of hand drawn animation, most is for the monkeys interacting with their world. To manage all these images, we put them into spritesheets. Two issues needed to be considered:
No dimension of the sprite sheet could be larger than 1024 (iPhone doesn’t like textures bigger than this and Marmalade started fuzzing them)
Sprite sheet dimensions needed to be to the power of 2 (32,64,128,256,512,1024) for the graphics card. If they weren’t, the graphics card would pad them out to make them to the power of 2 anyway.
An example of a GameMaker strip.
Photoshop does not have an easy way to make a sprite sheet where each frame is universal in height/width. So we discovered a trick that saved us dozens of hours:
Save each frame in PNG from photoshop
Create a sprite in Game Maker to drag and drop each PNG frame from the file system for a given animation
Export the sprite from Game Maker as an animation strip, which is each frame appended into one long horizontal PNG with the number of frames appended to the file name.
Run our custom sprite sheet program on the strip, which would break it out into a rectangle of the smallest power of 2 dimension as a PNG.
While it sounds involved, we could go from a collection of png frames to a squared sprite sheet in under 2 minutes. Just for its ability to create sprite strips GameMaker is well worth having!
The final spritesheet, power of 2 sized.You can’t tell, but we also dropped the color depth from 32bit to 16bit for memory.
Who is the harshest critic, the audience or the musician? The musician, for they have the double burden of knowing every note they missed and how much better they played during practice. So while the creator is extremely biased and forgiving of their creation, there is a harsh reality of what they intended and what they ended up making. I would say the music is always much sweeter in the imagination than on the page.
At the end of the 6 weeks I had finished building the core of the game. I came in around 340hrs. Knowing I have a personal biased, having played the game over a thousand times during build cycles, I concluded this game is actually fun. There was something magical about trying to entertain 3-5 monkeys simultaneously. Because I was away at the cottage, the artist had to take my word for it. And since I hadn’t yet figured out how to deploy it, he had no way to play it other than on my laptop. But, knowing we had a good core, something we were proud of, gave us the determination for the toughest fight yet: Polishing.(source:gamedev.net)