原文是Thomas Henshell對手機游戲Catch the Monkey的開發總結，由Lyra翻譯。

傳智播客今年6月開始ios培訓（http://ios.itcast.cn）的課程；相對于一些應用，我本人對ios游戲開發更感興趣，這些開發總結并不拘泥于技術，更多的探討了開發過程。過程很重要，過程正確才能保證結果正確，沒有正確的過程，一切方法都是紙上談兵。

聽聽Thomas Henshell的總結：

許多人都想做游戲，特別是移動游戲。好吧，我們是你們中的一員。本文就是為想進入這個行業自己動手做游戲的朋友們寫的。我們的目標有兩個：

1、告訴你這是可能的。

2、分享一些經驗教訓，或許能夠幫助到你。

我們這個叫Mirthwerx的團隊其實只有兩人：Thomas是自學成材的程序員，Alex則是畢業于Sheridan學院傳統動漫專業的美術師。我們是高中同學，20年前就認識，從那會兒開始便試著一起開發游戲。

在著手這個項目之前，我在微軟干了15年，寫一些web和移動終端的商業軟件。因為有這樣的背景，我們知道怎么樣才能妥善地開發軟件[面向對象的編程(OOP)、設計規格、易用性考量]。但后面你會看到，心里明白和實際做到是兩碼事。

策劃和原型

技術

從第一天，我們就知道自己想要兩個東西：

1、安卓是未來，但iPhone是當下。兩個版本我們都會開發。

2、我們想用windows平臺上我們熟悉的環境和工具來做開發。

我買了臺mac-mini來研究Mac平臺和XCode。用了一天ObjectiveC后，我知道自己一點兒也不想用這種語言來工作，它會把我逼瘋的。幸運的是，我們可以用一個辦法同時解決這兩個問題：Marmalade讓使用者能在Visual Studio C++里寫代碼，卻可以在任何平臺運行(包括iOS，安卓，黑莓，Windows Phone，Bada和其他平臺)。模擬器很棒，想要的性能監控應有盡有。對于獨立開發者來說，價格也很合適。

策劃

考慮到這是我們的第一個項目，我們想讓app的設計簡單些。最初的概念是這樣的：農場里有些猴子，玩家劃動手指來撓它們癢癢。每過一關，猴子會來得更快更多。就這么簡單。

在那時，它看起來太容易不過了，因為就倆人，我們覺得沒必要做什么開發規范。我們用了Xmind來畫思維導圖，并把“策劃案”放在那上面。這個游戲最初美術的工作量比較大，所以我們的美術就全職撲到項目上，而我只在下班和周末的時候抽點時間搗鼓一下。

原型

在商業軟件開發里，最初的原型對用戶來說至關重要。它把對文字描述的揣摩和猜測都撇盡了。

我們并沒有真的去做個原型，而是用了GameMaker 8，一個很強大卻不算貴的游戲制作工具。它讓我們可以把畫好的圖形和一些玩法機制湊到一起，來看看是不是已經弄出點好玩的東西來了。我估計我們的首個原型總共就花了20小時。因為它是在windows屏幕上跑的，所以沒法測試真實的觸摸/劃動機制，于是我們就借助點擊，每次點擊模擬一個指劃動作。這樣，最大的問題就變成了：它好玩么？

不，不好玩。我們改了一些數值(猴子的速度、戳戳它們讓它們發笑，一次來多少個猴子)，但還是太簡單了。能做的事情太少，連2分鐘都玩不到。我們不是要做一個“搞笑游戲”，所以又重頭開始。

頭腦風暴過程中，我們想到了一個用不同工具讓猴子們動作的主意。撓癢癢是最初級的工具，一根羽毛，后來你能得到其它工具。這下看起來有點兒戲了。我們于是構思了一些工具類型，刪減到方便放到原型里去的幾種，然后做了第二個原型。在這個版本中，玩家有了一個倉庫來儲藏各種工具。當一種用完時，農夫可以叫他太太來裝滿，每次裝滿之間要隔幾分鐘。這讓玩家會去考慮什么時候用哪種工具。我們也把對農夫的控制交給玩家，他們可以指揮農夫到特定區域把猴子抱回來。最后我們還加入了捕捉星星的概念。每過一段時間，會跳出星星來，玩家需要通過點擊來捕捉它。星星后面對升級會有用，盡管我們從來沒有把它放到原型里去過。那么：這下它好玩了么？

是，也不是。似乎已經有了一個好玩的內核，但一些迷障始終把它困在里頭。我們知道選擇工具(作為策略)很好玩，捕捉星星(它是自然產生的，不同于核心玩法，并且很難)也很有意思。我們去掉了農夫的控制權(太費勁)，和補充工具的概念(太復雜也太隨意)。我們需要一個讓玩家能制定策略和管理資源的游戲機制。

必須指出的是，做原型的時候，我們不只是閉門造車，而是聽取了項目以外其他人的誠懇意見。自己在項目中的太容易對測試的結果心存偏見了。你們后面就會看到我們是怎么在這上面載跟頭的。

小結

在這個階段，我們成天坐在那里進行頭腦風暴。在最后想到《魔獸世界》里的魔法值/冷卻機制前，我們有過許多點子。《魔獸世界》里，玩家不能隨心所欲地釋放魔法，他們有一個魔法條，限定在短時間內能用的魔法值。但有些魔法實在太強大了，如果它們消耗光了魔法條，你就必須等很長一段時間來冷卻，所以大招沒法在一場戰役里反復用。我們覺得，如果每個工具要求一個公共的能量池但冷卻時間不同的話，或許能實現我們一直追求的戰略平衡。有足夠的變數，我們就能讓玩家保持新鮮感和樂趣，這樣他們就能樂在其中了。

另外我們又添加了一項星星能量的概念。原本星星只是用來升級的貨幣，現在星星能量可以讓你花一定的星星就能使用技能。讓星星具有兩種功能，就是要讓玩家做出決策：當下受益還是留待以后。這是個很棒的機制，我們想應用到別的地方去。作為開發者，要把星星能量設計得真的很有用是一項有趣的挑戰，事實上，聰明的玩家只是保守地拿它們來升級。

策劃階段基本完成后(策劃其實無處不在)，我們進入到核心的開發階段。

核心開發

簡介

在第一部分中，我們介紹了Catch the Monkey從最初簡單的概念，到技術選擇，直至原型的過程。到原型完成時，我們已經有了一個進步很大的策劃案。但因為沒有經驗，當時并沒有把它們完整地記錄下來。我們知道有12個工具要開發，有10種不同的猴子，和對商店的不甚清晰的想法。我們想讓商店的購買可以升級，但到底升多少級，以及升級后能干嘛在那時都還不確定。該動手寫代碼了！

我們要不要做？！

正如上文提過，美術同學全職撲在這個項目上，而我作為程序員卻還要干點兒別的，只能兼職寫代碼。項目于是被拖累了，最后到了因為沒有進度項目要被砍掉的地步。所以，我計算了一下繼續做這個游戲需要的時間。6周(50小時x6=300小時)貌似夠了。我做了個艱難的決定：申請了6周的休假，回到自己的小屋子，專心一意搞這個游戲。我太太并沒有大驚小怪，她支持我把游戲完成。是時候“全力以赴”了。回過頭去看，繼續項目的選擇是對的。

最大的失誤

沒有一個合適的策劃文檔看起來成了我們最大的失誤。我只做了個非常簡陋的文本。

如果你研究過《植物大戰僵尸》會發現它有很多類型的僵尸，但他們是由幾個圖形(頭、身體、胳膊、腿)和一些可選的飾物(假肢、頭盔、報紙)組成的。如果把這些部件重新組合的話，你可以得到很多不同類型的僵尸，而只需要很小的存儲空間。我們想要一個類似的做法來畫猴子，使它們擁有各自的能力和缺陷。

然而后來我們痛苦地認識到，如果你想要做到這種重復利用的話，其實需要為每個角色寫下來非常周詳的規則，哪些它們能做哪些不能。請注意，在《植物大戰僵尸》里，僵尸永遠面朝攝像機(就好像2D的《南方公園》動畫)。無論做什么，它們都不會轉過去給你看一個側臉。

可早在我們制作動畫和原型的時候，我們就已經定下來，當一只猴子到達植物時，是一屁股栽下來的，轉過去，開始挖掘。當它挖到土豆后，又會轉身開始吃土豆。發現這個問題之前，我們已經完成了所有普通猴子的美術工作工。當我們想做一個戴帽子的猴子時，以為只要做一個單獨的帽子把它按在猴子頭上就可以了。我們開動了。真的完成后，我們發現，如果猴子從攝像機鏡頭前轉身，帽子(或者背心，或者太陽鏡)也得跟著轉。這就要求每個猴子幀必須對應一個飾物幀以及像素精調，意味著每一幀都要大量苦哈哈的坐標分析，才能讓它看起來比較正常。工作量太大了，我們又不想重畫挖掘的動畫，所以做了一個實驗性的決定：把帽子粘在猴子身上，把普通猴復制到戴帽猴。美術同學就這么干了，如法炮制出另外6種猴子。

這個問題的數學公式如下：

1種猴子有一套行動精靈表(恐懼、愉悅、大笑、走路、攀爬，等等)，需要大概20mb的VRAM空間。

7種猴子x 20mb=140mb VRAM

在iPhone 3GS(iPod 3+)上只有約55mbVRAM(15mb的堆陣)以下的才不會崩潰。

我們最初還考慮過iPod Touch 2+的，可它只有30mb的VRAM，所以沒可能了。因此我們慌忙調整VRAM，使之符合iPod 3+的要求。我們在下文會更多涉及這部分。

因此，教訓是：永遠都要在策劃階段就考慮內存要求，得在你寫代碼之前，而不是事發時，或者干脆事后才發現。我們要早知道猴子轉身會帶來的后果的話，早就在美術上調轉方向了，游戲也不會做得那么辛苦。

可愛的猴子在糟糕的現實世界

我認識的許多商業軟件開發者都是能不寫多線程解決方案就不寫。為什么？因為兩條獨立線程各自運行帶來的競態條件問題對測試來說將會是個噩夢。一旦軟件崩潰，由于存在太多排列組合，你會很難重寫，更不用說永久地修補它。

當談到游戲領域，既然已經決定做即時游戲了，無論如何Update()循環每幾個微秒都會執行一遍。沒有Windows Forms開發中的那種“阻塞調用”概念。這就是游戲的開發模式，我不打算說這個。

我要談的是即時游戲和回合制游戲。回合制游戲會等玩家輸入，然后做出相應回應；在等待玩家互動時，屏幕上會播放一些東西，比如美化效果之類，但實際的游戲狀態不會改變。而在即時游戲系統中，則無論玩家是否有動作，游戲的狀態持續在發生變化。

作為我們的首款游戲，本不應該選擇即時游戲的。

我們為Catch the Monkey做了大量的工作才使得它在持續變化的環境下不出差錯。測試場景數量大概需要回合制游戲的20倍。復制一個場景非常非常困難，甚至到了具體單元程序測試時依然如此。在架構階段有段時間，我都不確定是不是能讓它不再崩潰下去。幸運的是Marmalade有個超級給力的記憶管理工具，我最后還是搞定了(至少我這樣認為)。

這個教訓叫我們吃夠了苦頭，所以接下來一個項目必須是回合制的。

對象層級

顯然，面向對象的編程好處在于可以先編寫點小的、專注的、封閉的對象，然后再提升到更高水平上去。我的目標是創建一個知道如何實例化、移動和自我渲染的對象層級。

在我職業生涯早期并沒有做建模。但當有人給我看了Rational Rose，UML和建模以后，我走上了不歸路。我總是給自己的代碼建個模，就算是沒有別人看的個人項目也這樣。因為我發現這是在寫代碼前厘清思路的最好方式。Rational Rose(或者其他合適的建模工具)幫助你在策劃的時候想清楚策劃的問題。Rational Rose我用了有好幾年，但到做自己項目時，我可付不起2,000美元的授權費。幸運的是Open Source社區的StarUML救了我。StarUML是個強大的免費建模工具。它看起來跟Rational Rose一模一樣(至少和我2003年時用的最后版本是一樣的)。

來看一下分級策劃圖解。請注意兩個基礎對象：游戲對象和UI對象，它們都是從圖形對象派生出來的。圖形對象把所有Marmalade 2D API都封裝起來，所以需要編譯過才知道到底是一只猴子、一段故事板、還是一個文本對象。

游戲對象是在游戲場景(你玩到的那級)里用到的對象。它管理自身的狀態，精靈表，色深計算，比例(基于色深)，點擊操控，和碰撞檢測。所有玩法對象都是從游戲對象派生出來的。UI對象和游戲對象類似，但要輕量化一些，是為非游戲場景設計的，譬如文本、按鈕和商店圖例或工具選擇場景。

設計模式

必要時，我們采用GoF設計模式。例如：

• 我們用“工廠模式”來設計等級；輸入周和日，它就會輸出一個格式化的等級對象，還包含了必要的教程。
• 我們用“圖形管理”和“音效管理”兩個單例模式來捕捉圖像和音效文件。所以盡管每個對象都要對應加載和卸載資源，它們能從這些捕捉中將內存需求最小化。玩家狀態(星星數量、目前進程、已完成的教程、已購買的升級)我們也用了一個單例模式。這樣玩家進度的序列化和反序列化就變得極其簡單。
• 我們用裝飾模式來為所有游戲對象添加圖形效果，比如淡入、淡出、閃爍等等。

我最早的困惑之一是如何把全部類型的畫面(商店、工具選擇、劇情模式、標題畫面、選擇/菜單畫面、游戲模式)放在一起組成一個完美的OOP范例。在查找資料的時候，我從rivermanmedia上找到兩篇iPhone游戲開發者寫的很棒的文章：

The Scene System(場景系統)

The GUI Stack(圖形用戶界面堆棧)

我知道此范例不僅可以用在這個游戲上，還可能用于未來所有游戲。

The Scene System一文把游戲分解成一系列場景。我把Catch the Monkey分解成19種，包括場景標題和場景對話框，每一個都由場景共同界面衍生出來，比如:Init(), Update(), Render(), Shutdown()。我創建了場景管理的單例模式，里面包含了場景創建、關閉和切換有關的所有邏輯。這樣，謝天謝地我的代碼可以對更高一級別在發生什么置之不理。如果想要結束一個場景，開始一個新場景，我就寫：

SM->ChangeScene(new SceneShop());

如果想關注新場景，把它放在現有場景之上，我就用：

SM->AddScene(new SceneOptions());

場景管理器知道目前是不是有其他場景在運行，會讓它們恰到好處地慢下來，從內存里移除它們的資源，做一個淡出過度，啟動新場景。有了這個，即時游戲現在看起來更像是個Windows Form應用了，可以用對話調用對話，剩下麻煩的都讓OS自己去解決。

第二個核心的概念是用戶圖形界面堆棧。用戶圖形堆棧包含在場景管理器里，正如Windows處理表單和對話框那樣復制了“聚焦”的處理方式。通過將場景在堆棧上推送和彈出，我可以控制讓哪個場景調用Update() and Render()代碼。如果一個場景沒有收到Update()命令，它就會被有效地凍結(暫停)住。在純粹的模式中，最上面的場景是唯一接受了Update()調用的，堆棧中所有其它場景則接收了Render()命令。后來在測試中，我為了提高性能移除了堆棧中每個場景的Render()命令。對于需要背景的畫面(比如在游戲畫面上出現對話框)，我用了一個目前狀態的截圖，而不論當前的場景是什么。

在2D中使用Marmalade

如前面提到的，我們想用C++在VS2008里同時開發iPhone和安卓平臺游戲。Marmalade是3D框架，我們知道我們只是做2D，所以專注于lw2D API。我會著重來講用Marmalade的2D API做2D動畫。

你會看到Marmalade工作環境級別相對較低。它不是GameSalad(一個讓做游戲不用寫代碼的軟件，所需要做的僅僅是拖曳到窗口——譯者)，這是我選擇它的理由。我寧愿享受比較低級的API卻擁有自由改寫的權限，而不愿被局限在框架設計者們規定的能做不能做里面。

Marmalade有一個自定義文檔叫MKB，很神。這個文檔讓用戶可以自定義Marmalade程序庫，把源代碼、資源(音效)、字體和材質組導入項目。

Marmalade有一個資源管理器，允許通過在MKB文檔中像下面這樣定義來管理圖片組(材質組UI.GROUP?CIwResGroup?{?name?"UI"?shared?true?useTemplate?"image""image_template"?"./accountbuttons.png"?"./account1.png""./account2.png"?"./account3.png"?"./black.png"?"./bluestarbg.png""./pause.png"

然后你在你的自定義組文檔里定義你的全部圖片：

UI.GROUP?CIwResGroup?{?name?"UI"?shared?true?useTemplate?"image""image_template"?"./accountbuttons.png"?"./account1.png""./account2.png"?"./account3.png"?"./black.png"?"./bluestarbg.png""./pause.png"

在代碼里，你可以測試是否資源組都已經加載到內存，用下面兩個簡單的功能命令加載/卸載它們： if (IwGetResManager()->GetGroupNamed("farm", IW_RES_PERMIT_NULL_F) != NULL) IwGetResManager()->LoadGroup("farm.group");或： IwGetResManager()->DestroyGroup("farm"); 通過以下命令行可以用文件名(不加.png后綴)加載圖片(并自動上傳到OpenGL VRAM): CIw2DImage* img = Iw2DCreateImageResource(name);一旦你的內存里有圖片了，只需要調用某張圖片的繪圖例程就可以簡單地渲染你想要的圖片以及2D矢量單位。 Iw2DDrawImage(img, CIwSVec2(x,y)); Marmalade自動按照你調用的先后順序將繪圖調用排序，你就可以通過首先調用背景繪圖來控制分層。在我運行Render()例程之前，我先按照色深(從低到高)檢索我的對象，然后按照這個順序繪制它們。 完成渲染之前，我調用以下兩個例程，告訴Marmalade我完工了，可以向全世界展示我的成果了： Iw2DFinishDrawing(); Iw2DSurfaceShow();就這樣。每幀都調用這些繪圖例程，你就搗鼓出了你自己的游戲。

簡化精靈序列

這個游戲包含超過4000幀手繪動畫，多數都是猴兒們在它們世界里的表情動作。為了管理所有這些圖片，我們把它們放進了精靈序列。這里需要考慮兩個問題：

• 精靈序列的尺寸不能超過1024(iPhone不喜歡比這更大的材質，于是Marmalade開始檢測這些圖片)
• 精靈序列尺寸需要是2的冪次方(32,64,128,256,512,1024)以用作圖形卡。如果不是，圖形卡會自動把它們拉伸到2的冪次方。

Photoshop里要做個每一幀都長寬統一的精靈序列可不容易。所以我們找到了一個小竅門，為我們節省了幾十個小時：

• 在Photoshop里把每一幀都存成PNG
• 在GameMaker里創建一個精靈，把每張PNG拖出來從文檔系統里，放進GameMaker去，做成一個動畫
• 從GameMaker里把精靈輸出成為一個動畫條，是由每一幀圖片拼成的水平PNG長幅，順序則按照每幀的文件名排列。
• 在動畫條上運行我們的自定義精靈序列程序，這個長幅就會拆成一張張長方形PNG圖片，它們都是最小的2的冪次方尺寸。

聽起來很復雜，但其實我們可以在2分鐘以內就完成從png幀的收集到排好的精靈序列。哪怕只考慮創建精靈序列的能力，GameMaker也值得你擁有！

結論

最挑剔的批評會來自誰？聽眾還是音樂家自己？是音樂家。因為他們知道自己每個彈錯的音符，也知道自己平時練習的時候彈得有多好。所以創作者總是對自己的作品既充滿偏見又很豁達。在他們的初衷和最后實現的結果之間，隔著一個殘酷的現實。我想說，想象中的音樂總是要比實際上的來得甜美。

6周后，我完成了游戲的核心開發，花了大概340小時。我知道自己有偏見，但哪怕在開發過程中把游戲玩了上千次以后，我還是覺得這游戲真的好玩。同時取悅3-5只小猴簡直是奇跡。因為我一直呆在自己的小屋里，所以美術同學只能聽我說說。在部署之前，除了用我的筆記本，他都沒法玩一下。但因為確信我們有一個很好的內核并真心為此驕傲，我們決定開始最艱苦卓絕的戰斗：打磨。

平衡與打磨

簡介

到這里，我們已經有一個可以玩的游戲了，90%特性已經完成。玩家可以開始一個新游戲，玩過每一級，讓所有7種猴子動起來，使用所用10種工具，保存星星，在商店購買28個升級，使用全部4種星星能量，以及保存/繼續他們的游戲。我們跟自己宣布特性完成了。如果起初有寫過更詳細的策劃文檔的話，我們會意識到，沒這回事兒。

最后的10%用了90%的時間

我們不知道建立一個發行商關系需要多久，所以開始把一個早期的原型拿給運營代理看。其中有一個說，游戲內核很好，有AAA游戲的潛質，但還需要做大量潤色工作。當時我們覺得這個說法很蠢，認為平衡性教調和其他一些細枝末節的工作大概再2周時間能完成，然后就可以上線了。

這便是游戲和商業軟件的極大不同。商業軟件的特性完成、所有單元測試完畢后，真的算是已經完成了80-90%的工作。集成測試會發現一些問題，但一般只是開發者和開發規范之間需要解決的誤解。即時游戲集成測試占了全部工作量的大約一半，因為這關系到游戲元素各層之間的相互影響和依存性。

移植到設備

到目前為止，游戲只能在Marmalade的PC模擬器上玩。我們對它在真機上的表現(內存或幀率)心里沒有底。而且因為美術同學完全沒法測試游戲，所以單元測試也頗為受阻。該部署到真機上去了。

蘋果對于什么能放到它們設備上去非常謹慎。這有助于減少盜版，但也因此給開發者帶了緊箍咒，你不得不簽署你的代碼，獲取設備ids碼和證書，才能部署測試到設備上去。

如果你是在mac用XCode(尤其是最新版本)開發，過程就會比較簡捷，XCode會幫你料理好。所有的蘋果文件都會告訴你用XCode每個步驟該怎么做。而如果你是在PC上開發，就等著麻煩來找你吧。

有兩個必須做的事情：1)把你的機器設置成可部署iOS狀態，和2)把你的項目設置成iOS發行狀態。幸運的是，Marmalage 5.2版本里關于如何創建發行的文件比以往的版本要好得多。它包含了從如何創建證書的示范：上傳到蘋果，再下載蘋果的證書，以及把它放在什么地方。

設置PC的時候，項目必須設置和簽署為發行狀態。蘋果的開發者門戶會向應用簽發設備許可的UDID。蘋果提供一個簽署項目用的配置證書。Marmalade有個部署工具，在發布時ARM就會出現。你把配置和OS具體選項輸進這個工具(它會保存自定義的MKB文檔)，它就會神奇地幫你搞定IPA，這樣你就可以通過iTunes部署到你的iOS設備上去。

前前后后，我大概花了10小時才把游戲弄進我的iPod。這是個極其重要的步驟，因為我們需要觸屏來測試手勢。

讓手勢酷起來

如果你還記得的話，我們的策劃核心是玩家用手指劃動來撓猴子癢癢。幾個原型之后，我們需要一些其他工具來區分千篇一律的劃來劃去。最初對我們產生影響的是GameLoft的游戲“財政大戰(Bailout Wars)”。玩家輕點銀行家來干掉他們，但你還可以做其他的動作。

我們研究了許多游戲，最后理出下面這個清單：

• 點
• 點了以后長按
• 水平劃動
• 向下劃
• 向上輕劃
• 畫圈(順時針或逆時針)

我們選擇點、水平劃動、向下劃動和向上輕劃。(我們一開始也采用了點后長按，但后來去掉了。)我們為不同工具設計了相應的手勢：比如紙袋要放到猴子頭上去，所以玩家要把袋子往下劃到猴子的腦袋上。

iOS和安卓支持多點觸控(最多10點)，但我們決定只用一個點。一個觸摸點就好像一次點擊，為此我們審視了Marmalade里的s3ePointerEvent，用下面的代碼行捕捉，放到通用的觸摸變化上：

void SingleTouchButtonCB(s3ePointerEvent* event) { g_Touches[0].active = event->m_Pressed != 0; g_Touches[0].x = event->m_x; g_Touches[0].y = event->m_y; g_Touches[0].when = (int32)s3eTimerGetMs(); g_Touches[0].handled = false; }

現在我們知道手指在哪里了，這很好，但你怎么知道是在做一個手勢呢？答案是，你得自己來編程。

手指觸摸屏幕時，手勢開始。從這時開始，在它放開(手指提起)之前必須每隔一定區間就檢測一遍目前的觸摸點，必須分析其相對于原點的變化、點的進程和終止來確定所做的是什么手勢。我用通用工具類別及其子類里的戰略模式來實施每個手勢識別。

我解釋了創建手勢的原理，但要讓它感覺“順手”還得做許多優化。一樣是簡單的左右劃動，每個人的手勢都會不同，真夸張。有的人只是輕巧地劃動10個像素點，而另一些則會霸氣地橫貫全屏。有人水平地劃，而有些人則喜歡對角劃。有些人劃得太慢，機子記錄不下來，有的人又劃太快記錄不下來(我們發現最“準確”的時間間隔單位是每個點50毫秒)。那天結束后，我們得出了一個非常嚴格的手勢系統，水平劃的像素比垂直多不超過20，已經足夠寬松了。

把劇情放在最后

Catching the Monkey是一個動作游戲。我們要為玩家的動作設定一些故事背景，當然不需要寫個《罪與罰》的小說。最初，我們的故事框架如下：

南非的一個農夫擁有一片土豆田。當他和太太一起坐下來用午餐的時候，有只小猴闖進了田里。他跑過去看住那只猴子，但來的猴子越來越多。最后他趕跑了所有的猴子，回去吃他已經冷掉的午餐。結束。

行了，我們可不是要去獲奧斯卡最佳劇本獎的，對于游戲來說這已經可以讓我們開始了。所以我們把重心放在游戲開發本身上，然后再回頭來看故事劇情。

大錯特錯！

當需要處理劇情邏輯的時候，我叫我的朋友Rob來幫忙。某個晚上，我們坐下來討論故事。他開始問一些基礎問題，而我卻答不上來：

• 這位農夫同學有錢么？
• 他跟他老婆的關系好么？
• 他的行為模式怎樣：是沒頭腦型還是不高興型？
• 他們在那兒住多久了

這些問題看起來無聊到死，愚不可及！但事實上它們不是。從研究中我學習到，寫小說之前，你得先有個角色。于是Rob和我開始定義角色。

整個游戲過程中，玩家可以不停解鎖新工具。怎么來告訴玩家呢？我們決定讓農夫的太太“發現”它們，并把工具放到他的工棚里。我們選擇連續的對話框來介紹工具。然而你不知道角色的說話習慣就沒法寫對話(哪怕是抓小猴的簡單對話)。所以，寫對話之前，我們還真得回答這些無聊的問題。

接下來我們要回答的是兩個大問題：

1)猴兒們為什么會來？(為什么現在，而不是一年前或一年后？)

2)玩家阻止了猴兒們以后會怎樣(在解決了上一個問題之后)？

那個晚上我們想了很多點子，但每個好點子都會改變游戲走向，或者引入新的角色(比如猴王)，而游戲已經進入開發尾聲了，我們不可能做這樣的改變。我們絕對應該在第一周就開這么個會的！

我們在不改動游戲和添加大量新美術資源的前提下寫出了最好的劇情。寫作的第一條軍規是“寫你熟悉的”。最后，我以自己和太太為原型創作了農夫和他太太。趕跑猴子對于農夫而言，開始時很簡單，后來卻越來越難，成為了他的全部人生。這是我的人生隱喻。當農夫為沒玩沒了的猴子痛哭時，正是我為沒完沒了的游戲開發任務抓狂時。而背后，是一位淡定的太太。在她力所能及的地方搭把手，在必要的時候給予鼓勵。游戲里的一些對話其實就是我太太說的。游戲里農夫太太外出參加“女生旅行”的時候，其實是現實中我太太跑出去玩了。

當然，對于一個簡單的捕猴動作游戲，故事有點復雜了，但我還是把它放在了游戲里。

等級和Game Master

我必須先承認：有時候我實在是很懶。但有時懶惰卻是發明之母。

當我們開發第二個原型的時候，每一等級都有自己的腳本了：猴子什么時候從樹上掉下來，猴子的類別，一次來多少猴子，大部分都是時間驅動的。這是個典型的動作游戲，就像Capcom的“1942”。每個過關都是這樣。

希望文章能給你帶來一些幫助。

總結

以上是生活随笔為你收集整理的ios教程，用pc开发ios游戏的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。