2019獨角獸企業重金招聘Python工程師標準>>>

隨著蘋果公司不斷地創新與發展，新的iPhone 5、iPad 4以及iPad mini產品相繼問世，包括iOS與Xcode在內的開發環境和開發工具也都有了更新和進步。相信有不少開發團隊正緊鑼密鼓地在iPhone 5和iPad mini上部署自己的應用，一切都是那么令人激動！而隨著iOS 6的推出，cocos2d游戲引擎又有了新的發展。在IT行業，可謂唯一不變的便是變化。日新月異的技術需要同為開發者的你我保持強盛的好奇心和完美的學習狀態，只有這樣，才能不斷進步，開發出更酷的游戲或應用。相信這本書的再版，一定能使你受益匪淺，幫助你實現夢想。

你的第一個游戲??? 第四章

在本章中，你將編寫專屬于你的第一個完整的游戲。它不會為你贏得什么獎項，但從中可以學到cocos2d基本要素的使用方法，而且這個游戲是很容易修改的。實際上，本書之前版本的讀者已經制作了這個游戲的幾個修改版并發布到了App Store中。
這個游戲是著名的“Doodle Jump”游戲的“倒版”，它被貼切地命名為“DoodleDrop”。玩家通過旋轉屏幕盡可能躲避落下的障礙物。游戲的最終版本如圖4-1所示，你可以在此提前了解一下將在本章創造的作品。

圖 4-1? “DoodleDrop”游戲的最終版本

4.1? 創建DoodleDrop項目
在第2章我們學習了如何創建支持ARC的Kobold2D和cocos2d項目。
Kobold2D從運行Kobold2D啟動應用程序開始，然后選擇Empty-Project 模板(見第2章中的圖2-2)。使用DoodleDrop作為項目名稱，基本工作就完成了。剩下的事就是選擇應用程序的目標程序，選擇Supported Device Orientation的portrait mode圖標(見第3章中的圖3-17)。由于DoodleDrop是設計在Portrait模式下玩的，因此不選擇landscape mode圖標。
下面的部分僅適于cocos2d用戶——Kobold2D用戶可以略過。

4.2? 從一個支持ARC的cocos2d項目開始
cocos2d用戶要創建支持ARC的cocos2d項目，就應該依照第2章中的指導內容來做。如果已經做過了，就只要把已經創建的項目復制一遍。這樣做可以節省時間：保留一份由原始cocos2d項目模板轉換得來的支持ARC的未修改版本，這樣每次創建新項目時就會比較簡單快捷。
提示：
在這本書的源代碼中，可以在Cocos2D_ARC_Template_Projects文件夾下找到支持ARC的cocos2d模板項目。
在完成第2章中的指導內容之后，就有一個支持ARC的cocos2d項目了。我的項目取名為cocos2d-2.x-ARC-iOS。用Xcode打開之前先簡單地將包含.xcodeproj文件的文件夾拷貝一份。但是不要自己重命名.xcodeproj文件，因為那樣做會導致文件不可用。
現在你可以通過Xcode來重命名項目，這同樣也會重命名.xcodeproj文件。在Project Navigator中選擇cocos2d-2.x-ARC-iOS項目(第一個條目，見第2章中的圖2-5)，帶延遲地雙擊來編輯該條目。就是單擊一次，停頓兩秒，再單擊一次。這樣項目名稱就可以編輯了。輸入DoodleDrop作為這個項目的名稱。
按下Enter鍵確認修改之后，Xcode會問你是否確認重命名圖4-2所示的那幾項。確認則單擊Rename。否則Xcode 仍然會重命名項目，但是其他名稱不變。所以就算你這個時候發現了拼寫錯誤，或者突然不喜歡這個名字了，也都應該單擊Rename。重命名之后考慮到Prefix.pch文件，可能還會出現警告：“New name for file can not be the same”。無視這個警告即可，因為不會有什么問題。
還有最后一個需要手動重命名的條目：應用程序的計劃方案。應該仍然名為cocos2d- 2.x-ARC-iOS，也就是你命名項目時用的那個名稱。選擇Product Manage Schemes來查看方案列表。延遲雙擊方案名稱來選擇并編輯，重命名為DoodleDrop。完成之后，關閉scheme列表。

圖4-2? 確認重命名項目以及相關文件
由于DoodleDrop是Portrait模式應用程序，因此需要編輯AppDelegate.m 文件。修改shouldAutorotateToInterfaceOrientation方法，使之返回YES以僅用于Portrait模式：
return UIInterfaceOrientationIsPortrait(interfaceOrientation);
現在，在Run和Stop按鍵右邊的下拉菜單中選擇DoodleDrop的項目方案，然后運行，確認一切工作正常，如圖4-3所示。

圖4-3? 開始游戲吧！DoodleDrop項目基于第2章中的cocos2d ARC
???? 項目，Kobold2D的Empty-Project模板也不會有太大區別
4.3? 創建DoodleDrop場景
下一步你要作如下決定：是使用已有的HelloWorldLayer作為起點，之后再把名字改成現在的項目名稱呢？還是創建自己的場景？是我就選擇后者。因為你遲早需要添加新的場景，所以還不如現在就學習如何從頭創建新的場景。
請確定已選擇你準備添加新場景類的組，然后選擇File | New | New File或者右擊Project Navigator樹中的合適位置，在彈出的菜單中選擇New File，打開如圖4-4所示的New File 對話框。

圖4-4? 添加新的CCNode派生類的最好方式是通過使用cocos2d或Kobold2D提供的類模板。
????? 在這個例子中，因為我們要創建新的場景，所以選擇的CCNode類是CCLayer的子類
cocos2d和Kobold2D為大多數重要的節點和類都提供了類模板，不使用它們太浪費了！另外，Xcode自帶的Objective-C類也是很好的模板——只需要手動將基類由NSObject 改為CCLayer即可。在cocos2d v2.x的模板部分選擇CCNode類，單擊Next按鈕，再次單擊Next 按鈕會彈出如圖4-5所示的Save File對話框，在此之前，確認將該類設置為CCLayer 的子類。
我是將新建的文件命名為GamLayer.m。整個DoodleDrop游戲邏輯都在這個文件中實現，所以這個名字還十分合理。確保DoodleDrop目標程序復選框被選中(見圖4-5)。
注意：
不檢查目標設置的話可能會導致文件沒有被添加到正確的目標程序里。這會引起一系列問題——其中編譯錯誤和“file not found”錯誤是常見的典型錯誤。這種情況有時還會導致游戲運行時崩潰。把文件放進完全不需要這些文件的目標程序里，只會浪費空間。

圖4-5? 給新場景命名，并且確保它被添加到正確的目標程序中
目前，我們的GameLayer類是空的，為了將它設置為場景，我們要做的第一件事是在里面添加+(id) scene方法。我們在這里插入的代碼和第3章的基本上一樣，只是層的類名不同而已。幾乎在任何一個類中都需要-(id) init方法。添加-(void) dealloc方法也無傷大雅，要是能輸出對象被正確銷毀的日志就更好了。監視dealloc方法能有效提前做出系統預警，防止內存泄漏。
我也是一位很謹慎的程序員，決定將第3章中介紹的日志語句添加進來。程序清單4-1是完成后的GameLayer.h，程序清單4-2是完成后的 GameLayer.m。
程序清單4-1? 帶場景方法的GameLayer.h
#import < Foundation/Foundation.h>
#import "cocos2d.h"

@interface GameLayer : CCLayer
{
}

+(id) scene;

@end
程序清單4-2? 帶場景方法以及一些標準方法的GameLayer.m
#import "GameLayer.h"
@implementation GameLayer
+(id) scene
{
CCScene *scene=[CCScene node];
CCLayer* layer=[GameLayer node];
[scene addChild:layer]; return scene;
}

-(id) init
{
if ((self=[super init]))
{
?????? CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);
? }
??? return self;
}
-(void) dealloc
{
??? CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);
}
@end
現在可以安全地刪除HelloWorldLayer類。在彈出的對話框中選擇Move to Trash選項，將文件徹底刪除。選擇HelloWorldLayer.h和HelloWorldLayer.m兩個文件，在頂部菜單中選擇Edit | Delete，或者右擊選中的文件，在彈出的菜單中選擇Delete選項。
Kobold2D用戶現在只需要打開Resources組中的config.lua文件，修改FirstSceneClassName即可，如下所示：
FirstSceneClassName = "GameLayer",
但是在純cocos2d應用程序中，必須修改AppDelegate.m，將文件中所有的HelloWorldLayer修改成GameLayer。程序清單4-3中已經突出顯示了要對#import和pushScene語句進行的必要修改。
程序清單4-3? 修改AppDelegate.m 文件，用GameLayer類代替HelloWorldLayer
// replace the line #import "HelloWorldLayer.h" with this one:

#import "GameLayer.h" - (BOOL)application:(UIApplication *)application??
??? didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
...
// replace HelloWorldLayer with GameLayer
??? [director_ pushScene:[GameLayer scene]];
}
編譯并運行，應該能看到空白場景。成功了！如果碰到什么問題，請將你的項目與本書附帶的DoodleDrop01項目進行比較。
提示：
應用程序成功生成但是運行失敗？別忘了，一個Xcode 項目中有多個目標程序，甚至一個目標程序也會有多個方案。檢查Xcode 工具欄中Run 和Stop 按鈕右邊的方案選擇/部署目標程序下拉菜單(見圖2-6)。下拉菜單的左邊部分用于選擇當前方案。要確保選擇的是DoodleDrop。大多其他方案，比如cocos2d-library是靜態庫。你可以生成靜態庫，但是不能運行它們。刪除、隱藏和選擇方案這些都只能由用戶自己設置完成。其他的問題我都已經為你解釋清楚了。
4.4? 添加Player Sprite
接下來將添加Player Sprite(玩家精靈)并使用加速計控制它們的動作。要添加玩家圖像，請在Xcode中選擇Resources組，然后選擇File | Add Files to“DoodleDrop”，或者右擊并從菜單中選擇Add Files to“DoodleDrop”來打開選擇文件的對話框。如果不小心把文件添加到了錯誤的組中，那么可以在Project Navigator中把它重新拖動到正確的組中。Resources組并沒有什么特別的地方，它就是按照定義應該保存不是源代碼的文件的地方。
玩家圖像alien.png和alien-hd.png就在隨書附帶的DoodleDrop項目的Resources文件夾中。也可以挑選你自己的圖像，只要圖像的尺寸是64×64像素或128×128像素(HD格式，帶有-hd后綴)即可。cocos2d自動為帶有Retina顯示屏的iPhone和iPod Touch設備使用HD文件，標準分辨率(SD)的文件只用于iPhone 3GS。cocos2d還能識別另外兩種文件后綴：-ipad用于iPad和iPad 2，-ipadhd用于帶有Retina顯示屏的第3代(或更新的)iPad。
對于專用于Retina設備和iPad的資源，cocos2d默認使用帶有-hd、-ipad和ipadhd后綴的文件。普通的iOS應用程序不會使用它們。這些應用程序要想使用高分辨率圖像，必須使用蘋果公司的@2x文件擴展名。雖然在cocos2d應用程序中也可以使用@2x擴展名，但是cocos2d的文檔警告用戶不要使用該擴展名。
提示：
一個常被問起的問題是在非Retina設備上簡單地縮小HD圖像是否合適。這么做是不合適的，原因有兩個。一個原因是內存限制。即使最早的Retina設備的內存也是非Retina設備的2倍以上。讓非Retina設備加載HD圖像，占用的內存將是已被縮小并打包的SD圖像的4倍。另一個原因是，加載Retina圖像的時間要比加載SD圖像長得多，在較老、較慢的設備(比如沒有Retina顯示屏的那些設備)上這個問題更加明顯。
反過來，在應用程序中只使用標準分辨率的資源也不是十分合適。這樣將無法利用Retina顯示屏的高分辨率，而且應用程序的圖像質量在Retina設備上不如高分辨率的圖像。放大和圖像處理算法再好，也不能讓標準分辨率圖像在Retina設備上呈現清晰而鮮明的效果。正因如此，應該將游戲的所有資源設計為使用高分辨率，然后在需要的時候再縮小其大小。唯一需要注意的是，尺寸大小應該能夠被2整除。
Xcode隨后會詢問添加文件的方式和位置細節，如圖4-6所示。確保在Add To Targets區域選中了所有會使用該文件的目標程序，當然在這里只有DoodleDrop，不過在Kobold2D項目中最好也把該文件添加到Mac OS X目標中。如果文件還沒有存儲到項目的文件夾中，就應該選中“Copy items into destination group’s folder(if needed)”復選框。如果無法確定，就選中該復選框，最壞的情況也就只是有相同文件的副本。如果不選中該復選框，那么最壞的情況會是把項目添加到源代碼管理程序或者在壓縮并分享項目時發生文件丟失錯誤。
提示：
iOS游戲首選的圖像文件格式是PNG(Portable Network Graphic，便攜式網絡圖像)。這是一種壓縮文件格式，然而與JPEG文件不同的是，PNG采用了無損壓縮，保留了原始圖像的所有像素。你也可以保存不經壓縮的JPEG文件，不過對于同一圖像，PNG文件的大小明顯要比未經壓縮的JPEG文件小。但是這只會影響應用的大小，而不會影響紋理對內存(RAM)的使用。不使用JPEG文件的另一個原因是，cocos2d在iOS上加載這些文件的速度很慢。我上次測量的結果是它們比PNG文件慢8倍。第6章將介紹TexturePacker，一個用于管理圖像的工具。它允許將圖像轉換為各種壓縮格式或減少圖像的色深，同時通過抖色和其他技術保留盡可能高的圖像質量。

?

圖4-6? 每次添加資源文件時都會出現這個對話框，大多數情況下你都應該使用默認設置
現在我們要向游戲場景中加入玩家精靈了。我會將它們作為CCSprite*類型的成員變量加入到GameLayer類中。就目前來看，這樣做比較容易，而且游戲也足夠簡單，可以將所有組件都加入到相同的類中。通常不推薦這種方法，在之后的項目中我們將會創建單獨的類來保存每個游戲組件，以符合好的代碼設計要求。
程序清單4-4展示了如何在GameLayer的頭文件中添加CCSprite*類型的成員變量。
程序清單4-4? 將CCSprite*類型的成員變量添加到GameLayer類中
#import < Foundation/Foundation.h>
#import "cocos2d.h"

@interface GameLayer : CCLayer
{
CCSprite* player;
}
+(id) scene;

@end
程序清單4-5是加入到init方法中的代碼，它的功能是初始化精靈，將精靈賦給成員變量，并設置精靈到屏幕底部中間的位置，同時還啟用了加速計輸入功能。
程序清單4-5? 啟用加速計輸入，創建并定位玩家精靈
-(id) init
{
if ((self = [super init]))
{
CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);

self.isAccelerometerEnabled = YES;

player = [CCSprite spriteWithFile:@"alien.png"];
[self addChild:player z:0 tag:1];

CGSize screenSize = [CCDirector sharedDirector].winSize;
float imageHeight = player.texture.contentSize.height;
player.position = CGPointMake(screenSize.width / 2, imageHeight / 2);
}

return self;
}
玩家精靈已添加為層的子節點，它的標記值是1，隨后我們將使用這個標記值識別它并把它與其他的精靈區分開。這里的文件名使用了標準分辨率圖像的文件名，即alien.png。在Retina設備上，cocos2d會自動加載alien-hd.png。如果沒有對應的-hd文件，cocos2d會加載標準分辨率圖像。此時，圖像在Retina設備上看起來比在非Retina設備上小。提供所有圖像資源的-hd版本是一種很好的做法。
警告：
記住，在iOS設備上文件名是區分大小寫的。如果你試圖加載Alien.png或ALIEN.PNG，在模擬器上會成功加載文件而在iOS設備上則不會，因為文件真正的名字是alien.png，字母全部小寫。這就是堅持統一的命名約定——例如強制所有文件名使用小寫字母——的意義所在。為什么要用小寫？因為全部大寫的文件名很難辨認。
我們將position屬性的x值設為屏幕寬度的一半，從而使玩家精靈的初始位置水平居中。在垂直位置上，我們想使玩家精靈紋理的底端與屏幕底端對齊。如果你記得前一章的內容，就會知道精靈紋理是以其中心點作為位置坐標值的。將精靈的垂直位置設為0會導致紋理的下半邊陷入屏幕底端。這不是我們想要的，我們要把它往上挪半個紋理的高度。
可以通過調用player.texture.contentSize.height返回精靈紋理的內容尺寸。什么是內容尺寸？在第3章中，我講到iOS中紋理尺寸的大小只能是2的方冪。但是實際的圖像尺寸可能會比紋理尺寸小。例如，如果原始圖像的尺寸為100×100像素，那么紋理尺寸就是128×128像素。紋理的contentSize屬性會返回原始圖像的尺寸，也就是100×100像素。大部分情況下，處理的都是內容尺寸而不是紋理尺寸。即使圖像是2的冪，也應該使用contentSize，因為紋理可能是包含多個圖像的紋理圖冊。第6章將詳細討論紋理圖冊。
將圖像高度的一半設為position屬性的y值后，精靈圖像恰好能與屏幕底端對齊。
提示：
無論何時都要盡量避免使用固定的位置值。如果你只是把玩家位置設為(160，32)，此時你就做了兩個本該避免的假定。第一，你假定了屏幕寬度為320像素，但并不是每個iOS設備都是這樣的。第二，你假定了圖像高度是64像素，然而那也是可能會改變的。一旦你開始像這樣做假定，代碼就會喪失一部分靈活性，修改起來需要很多時間。
我用了很多代碼來定位對象，但長遠來看這樣做會節約大量時間。可以將項目部署到不同的設備，也可以使用不同尺寸的圖像，無論如何項目都會正常運行。你不再需要修改這段特別的代碼了。程序員面對的最費時的壞事情之一就是——不得不修改那些依據假定而編寫的代碼。
4.5? 加速計輸入
最后一步，我們來使玩家精靈能夠左右傾斜。在第3章中我已經說明，應該為接收加速計輸入的層添加accelerometer方法。這里我使用了acceleration.x參數，將它乘以10后加到玩家精靈的位置值上，從而加速玩家精靈的運動：
-(void) accelerometer:(UIAccelerometer *)accelerometer
didAccelerate:(UIAcceleration *)acceleration
{
CGPoint pos = player.position;
pos.x + = acceleration.x * 10;
player.position = pos;
}
注意到奇怪之處了嗎？上面的三行代碼用一行就能寫好：
// ERROR: lvalue required as left operand of assignment
player.position.x += acceleration.x * 10;
然而，與其他編程語言(如Java、C++或C#等)不同，像player.position.x += value這樣的語句對Objective-C中的屬性是不起作用的。position屬性的類型是CGPoint，這是一個普通的C結構體。Objective-C中的屬性不能直接向結構體的域賦值。問題出在Objective-C中屬性的工作方式，以及Objective-C所基于的C語言的賦值機制。
player.position.x語句實際上是調用了position的getter方法[player position]，這意味著你實際上獲得了一個臨時的position值，并試圖改變這個臨時的CGPoint對象的x成員變量。但之后這個臨時的CGPoint對象會被丟棄。于是position的setter方法[player setPosition]就不會自動被調用了。所以只能直接對player.position進行賦值，在本例中就是賦給它一個新的CGPoint對象。在使用Objective-C時，你必須接受這個令人遺憾的問題，而且如果你有過編寫Java、C++或C#的經歷，沒準還得改變你的編程習慣。
因此，前面的代碼必須創建一個臨時的CGPoint對象，修改position的x域，然后把臨時的CGPoint賦給player.position。在Objective-C中是必須這么做的。
4.6? 首次測試運行
現在你的項目應與本章附帶的DoodleDrop02項目不相上下。馬上測試一下吧。你要確認已選擇在設備上運行應用，因為模擬器不會獲得加速計輸入。檢驗當前版本中的加速計輸入表現如何。
如果尚未在Xcode中為這個項目安裝你的開發授權，將會產生“code sign”錯誤。在iOS設備上運行程序時需要代碼簽名證書。請查閱蘋果公司的文檔以了解如何創建和安裝必要的開發授權文檔(http://developer.apple.com/ios/manage/provisioningpro?les/howto.action)。
4.7? 玩家速度
注意到加速計輸入哪里不正常了嗎？是的，它反應遲緩，移動不暢。這是因為玩家精靈并沒執行真實的加速和減速。讓我們修改一下它。修改后的代碼在DoodleDrop03項目里。
實現加速與減速的概念不在于直接改變玩家的位置值，而是使用單獨的CGPoint變量作為速度矢量。每次接收到加速計事件時，速度矢量就加上從加速計得到的輸入。當然，這意味著我們必須把速度限制在一個任意的最大值內，否則減速時就要花點時間了。不管有沒有接收到加速計輸入，在每一幀都把速度加到玩家位置上。
注意：
為什么不使用動作來移動玩家精靈呢？無論何時你需要頻繁地——如每秒數次——改變對象的速度或方向，使用move動作都不是一個好的選擇。動作適用于相對使用期較長的一次性對象，所以頻繁創建新對象在分配和釋放內存上增加了額外開銷，這會使游戲性能大幅下降。
更糟糕的是，如果不為動作留出一點時間，動作是不會執行的。這就是在每幀添加新動作來替換前一個卻沒有任何效果的原因。很多cocos2d開發者都曾偶然發現過這個看似古怪的現象。
例如，如果在每幀都停止所有動作并為對象添加一個新的名為MoveBy的動作，對象不會有一丁點的移動！MoveBy動作只會在下一幀改變對象的位置。但是在下一幀你已經停止所有動作，并加入另一個新的MoveBy動作了。這樣做下去只會讓對象寸步不移。這就像老生常談的關于驢的那一套故事：推得越使勁它就越犟，并且在原地不動彈。
讓我們來看一下對代碼所做的修改。在頭文件中加入了playerVelocity變量：
@interface GameLayer : CCLayer
{
CCSprite* player;

CGPoint playerVelocity;
}
你可能想知道為何使用CGPoint替代float。這是考慮到你以后可能會加速或減速一點點。為今后的擴展做些準備總沒有壞處。
程序清單4-6是加速計的代碼，其中使用速度代替了對玩家位置的直接修改。這段代碼采用了三個設計參數：減速值、加速計靈敏度和最大速度。這些參數沒有最優值；你需要調整數值，找到最適合你游戲的設置，因此得名“設計參數”。
減速是指減少當前速度，之后速度將加上新的加速計值與靈敏度相乘后的數值。減速值越低，玩家精靈操作外星人改變方向的速度就越快。靈敏度越高，玩家精靈對加速計輸入的反應就越敏感。由于這些數值是對同一數值進行修改，它們相互作用且相互影響，因此一定記得每次只調整一個值。
程序清單4-6? 通過GameLayer實現得到playerVelocity
-(void) accelerometer:(UIAccelerometer *)accelerometer
didAccelerate:(UIAcceleration *)acceleration
{
// controls how quickly velocity decelerates (lower = quicker to change direction)
float deceleration = 0.4f;
// determines how sensitive the accelerometer reacts (higher = more sensitive)
float sensitivity = 6.0f;
// how fast the velocity can be at most
float maxVelocity = 100;

// adjust velocity based on current accelerometer acceleration
playerVelocity.x = playerVelocity.x * deceleration + acceleration.x * ?
sensitivity;

// we must limit the maximum velocity of the player sprite, in both directions
if (playerVelocity.x > maxVelocity)
{
playerVelocity.x = maxVelocity;
}
else if (playerVelocity.x - maxVelocity)
{
playerVelocity.x = - maxVelocity;
}
}
現在playerVelocity能夠改變了，但如何把速度加到玩家精靈的位置值上呢？可以在GameLayer的init方法中指定如下update方法：
// schedules the –(void) update:(ccTime)delta method to be called every frame
[self scheduleUpdate];
同樣需要添加–(void) update:(ccTime)delta方法，如程序清單4-7所示。已指定的update方法在每一幀都會被調用，而那就是我們要在玩家精靈的位置值上加上速度的地方。這樣我們就可以做到：無論加速計頻率的大小如何，都能產生流暢平滑的運動。
程序清單4-7? 用當前速度更新玩家精靈的位置
-(void) update:(ccTime)delta
{
// Keep adding up the playerVelocity to the player's position
CGPoint pos = player.position;
pos.x + = playerVelocity.x;

// The Player should also be stopped from going outside the screen
CGSize screenSize = [CCDirector sharedDirector].winSize;
float imageWidthHalved = player.texture.contentSize.width * 0.5f;
float leftBorderLimit = imageWidthHalved;
float rightBorderLimit = screenSize.width - imageWidthHalved;

// preventing the player sprite from moving outside the screen
if (pos.x < leftBorderLimit)
{
pos.x = leftBorderLimit;
playerVelocity = CGPointZero;
}

else if (pos.x > rightBorderLimit)
{
pos.x = rightBorderLimit;
playerVelocity = CGPointZero;
}

// assigning the modified position back
player.position = pos;
}
邊界檢查可以防止玩家精靈顯示在屏幕外。我們不得不再一次把玩家精靈紋理的contentSize(內容尺寸)考慮在內，因為玩家精靈是以精靈圖像的中心為準計算位置的，我們不希望圖像的任何一邊離開屏幕。為此，計算imageWidthHalved的值，然后用它檢查剛剛更新的玩家位置是否在左右邊界之內。上面的代碼稍顯冗長，但這樣更容易理解。現在構建并運行項目，體驗能夠控制玩家精靈的感覺。
提示：
如果玩過Tilt to Live之類的游戲，可能會注意到這里實現的簡單的加速計控制無法像在那些游戲中一樣有一種動態的感覺。這是因為要實現流暢、動態的加速計控制，需要對加速計輸入進行過濾。在Kobolds2D中，使用KKInput類的屬性可以獲得高通(瞬時)和低通(平滑)過濾后的加速計輸入：
float smoothed = [KKInput sharedInput].acceleration.smoothedX;
利用加速計控制的游戲通常會使用低通過濾器。“低通”意味著過濾掉加速度突然且極端的變化，從而使得到的結果值十分平滑。下面是由加速計輸入值(rawX/rawY)和常量filterFactor(范圍為0.0~1.0)得到新的smoothedX/smoothedY值(示例變量)的低通過濾器。0.1是一個不錯的過濾因子，表示在新的平滑后的值中只考慮了10%的當前原始加速計值：
smoothedX = (rawX * filterFactor)? +? (smoothedX * (1.0 - filterFactor));
smoothedY? =? (rawY * filterFactor)? +? (smoothedY * (1.0 - filterFactor));
4.8? 添加障礙物
在往游戲中加入一些讓玩家躲避的東西之前，這個游戲還沒有什么可玩性。接下來在項目里加入一些令人憎惡的東西：六足人造蜘蛛。有誰不想躲著它們嗎？
與玩家精靈一樣，需要把spider.png和spider-hd.png加入到Resources組中。然后在GameLayer.h的接口中加入3個新的成員變量：在程序清單4-9中出現的NSMutableArray類引用spiders，以及在程序清單4-12中使用的spiderMoveDuration和numSpidersMoved：
@interface GameLayer : CCLayer
{
CCSprite* player;
CGPoint playerVelocity;

NSMutableArray* spiders;
float spiderMoveDuration;
int numSpidersMoved;
}
警告：
在代碼中應該避免使用CCArray。CCArray是NSArray和NSMutableArray的快速替代版本，但是它只是快了一點點，使用它幾乎不會對幀率產生影響。而它的一些方法(如insertAtIndex或removeObjects)要比NSMutableArray的相同方法慢得多。CCArray最大的問題是過去已經存在一些嚴重的bug，比如與ARC的兼容性問題。它也不能支持NSArray/NSMutableArray的全部功能。例如，無法枚舉帶有block對象的CCArray，這使得它不適合用于并行處理(例如，通過Grand Central Dispatch來完成)。整體上看，NSMutableArray要比CCArray更可靠，兼容性更好，并且缺陷更少。任何時候，我都愿意用降低一些性能來換取高可靠性。cocos2d在內部使用了CCArray，不過就內部使用來看，CCArray經過了大量測試，證明沒有問題，所以這種用法我是可以接受的。
與此同時，在GameLayer的init方法中，在scheduleUpdate后面加上對initSpiders方法的調用，我們將在后面討論它：
-(id) init
{
if ((self = [super init]))
{
...
[self scheduleUpdate];
[self initSpiders];
}
return self;
}
隨后，我們會向GameLayer類中加入一大段代碼，先從initSpiders方法開始，它創建了蜘蛛精靈，如程序清單4-8所示。
程序清單4-8? 為了更好地進入，蜘蛛精靈被初始化并添加到NSMutableArray中
-(void) initSpiders
{
CGSize screenSize = [CCDirector sharedDirector].winSize;

// using a temporary spider sprite is the easiest way to get the image's size
CCSprite* tempSpider = [CCSprite spriteWithFile:@"spider.png"];

float imageWidth = tempSpider.texture.contentSize.width;

// Use as many spiders as can fit next to each other over the whole screen width.
int numSpiders = screenSize.width / imageWidth;

// Initialize the spiders array using alloc.
spiders = [NSMutableArray arrayWithCapacity:numSpiders];
for (int i = 0; i < numSpiders; i++)
{
CCSprite* spider = [CCSprite spriteWithFile:@"spider.png"];
[self addChild:spider z:0 tag:2];

// Also add the spider to the spiders array.
[spiders addObject:spider];
}

// call the method to reposition all spiders
[self resetSpiders];
}
這里要說明的是，創建名為tempSpider的CCSprite對象只是為了獲得精靈圖像的寬度，然后用它決定蜘蛛精靈的數量。獲得圖像尺寸最簡單的方法就是創建臨時的CCSprite對象。注意，我沒有把這個tempSpider對象作為子節點加到任何其他節點上，也沒有把它分配給實例變量。這意味著當程序執行離開initSpiders方法后，ARC會知道tempSpider對象已經不再使用，并自動釋放其內存。
與其形成對比的是名為spiders的數組，我用它來保存對所有蜘蛛精靈的引用。這個數組被分配給實例變量spiders，因此，在GameLayer對象本身被釋放以前，ARC不會釋放該數組對象。使用ARC時，不需要自己以任何方式釋放spiders數組。
在程序清單4-8的結尾，調用了[self resetSpiders]方法，這個方法的代碼在程序清單4-9中。將精靈的初始化和定位分開處理的原因在于：游戲總會結束，之后游戲將被重置。最為高效的做法就是將所有游戲對象移動到它們的初始位置。然而，一旦游戲趨于復雜，這種做法將不具備可行性。最終，最簡單的做法就是以玩家的等待為代價重新加載全部場景。
警告：
在重新加載場景時，你可能想使用[[CCDirector sharedDirector] replaceScene: self];來重新加載同一場景。但是這會導致程序崩潰，因為self是當前正在運行的場景。在cocos2d中嘗試用正在運行的場景替換其自身會導致程序崩潰。實際上，必須創建GameLayer類的新實例：[[CCDirector sharedDirector] replaceScene:[GameLayer scene]];。
程序清單4-9? 重設蜘蛛精靈的位置
-(void) resetSpiders
{
CGSize screenSize = [CCDirector sharedDirector].winSize;

// Get any spider to get its image width
CCSprite* tempSpider = [spiders lastObject];
CGSize size = tempSpider.texture.contentSize;
int numSpiders = [spiders count];
for (int i = 0; i < numSpiders; i++)
{
// Put each spider at its designated position outside the screen
CCSprite* spider = [spiders objectAtIndex:i];
spider.position = CGPointMake(size.width * i + size.width * 0.5f,?
screenSize.height + size.height);

[spider stopAllActions];
}

// Schedule the spider update logic to run at the given interval.
[self schedule:@selector(spidersUpdate:) interval:0.7f];

// reset the moved spiders counter and spider move duration (affects speed)
numSpidersMoved = 0;
spiderMoveDuration = 4.0f;
}
我再一次臨時獲取了某個已有的蜘蛛精靈，然后通過紋理的contentsize屬性獲得它的圖像尺寸。這里我沒有創建新的精靈，因為已有同類精靈存在了，并且由于所有的蜘蛛都使用相同尺寸大小的同一圖像，我甚至不用關心獲取的是哪個蜘蛛，因此我只是簡單地獲取了數組的最后一項。
接下來修改每個蜘蛛的位置，使它們整體橫跨整個屏幕的寬度。還是同樣的原因，蜘蛛精靈的紋理以其中心點作為位置，position屬性的x值加上了圖像寬度的一半。至于高度，每個蜘蛛也被設為高于屏幕頂端一個圖像高度。這個數值是任意的，這里我要使圖像不可見，能達此目的者均可。由于重置后蜘蛛仍然可能在移動，因此要停止它的全部動作。
提示：
如果不是絕對必要的話，為了節約CPU資源，最好不要在for或其他循環語句中使用方法調用作為循環條件。本例中創建numSpiders變量來保存[spiders count]的調用結果，然后將其用作for循環的循環條件。由于在循環過程中數組本身并未被修改，因此數組的計數值保持不變。這就是為何我能保存這個值并在for循環中省去對[spiders count]的重復調用。
我還指定spidersUpdate:選擇器每0.7秒運行一次——這是另一個蜘蛛從屏幕頂端落下的時間間隔。如果選擇器已被指定，cocos2d會用一條日志消息指出這一點，你可以忽略這條消息。cocos2d并不會再次指定選擇器，而是會更新已指定選擇器的時間間隔。如程序清單4-10所示，spidersUpdate:方法會隨機挑選一個已經存在的蜘蛛，檢查它是否空閑，然后使用一系列動作操作它從屏幕上方落下。
程序清單4-10? spridersUpdate:——讓蜘蛛頻繁下落的方法
-(void) spidersUpdate:(ccTime)delta
{
// Try to find a spider which isn't currently moving.
for (int i = 0; i < 10; i++)
{
int randomSpiderIndex = CCRANDOM_0_1() * spiders.count;
CCSprite* spider = [spiders objectAtIndex:randomSpiderIndex];

// If the spider isn't moving it won't have any running actions.
if (spider.numberOfRunningActions == 0)
{
// This is the sequence which controls the spiders' movement
[self runSpiderMoveSequence:spider];

// Only one spider should start moving at a time.
break;
}
}
}
我還從未對任何程序清單置之不理，是吧？你也許想知道為什么這里我要循環迭代10次來得到一個隨機的蜘蛛。原因在于，我不知道隨機生成的索引值對應的蜘蛛是不是活動的，所以要確認最終隨機選出的蜘蛛當前是空閑的。如果10次之后——當然，這個數字是任意的——仍然沒有隨機選出一個空閑的蜘蛛，就會跳過這次更新，然后等待下一次。
也可以使用do/while循環進行不斷嘗試，直到找到空閑的蜘蛛為止。但有一種可能，即此刻所有的蜘蛛都在移動——這取決于設計參數，如新蜘蛛落下的頻率。游戲會為嘗試尋找空閑的蜘蛛而無限循環，從而鎖死。此外，我并不喜歡太賣力；對于這個游戲而言，另一個蜘蛛等個幾秒再落下也并無大礙。雖然如此，如果查看DoodleDrop03項目，就會發現我加入了日志記錄語句，輸出找到空閑蜘蛛的重試次數。
由于蜘蛛執行的唯一動作就是一系列的運動，我只要檢查蜘蛛當前是否執行任何動作即可。如果沒有執行動作，我就假定它是空閑的。然后執行程序清單4-11所示的runSpiderMoveSequence方法。
程序清單4-11? 通過動作序列控制蜘蛛的運動
-(void) runSpiderMoveSequence:(CCSprite*)spider
{
// Slowly increase the spider speed over time.
numSpidersMoved++;
if (numSpidersMoved % 8 == 0 && spiderMoveDuration > 2.0f)
{
spiderMoveDuration - = 0.1f;
}

// This is the sequence which controls the spiders' movement.
CGPoint belowScreenPosition = CGPointMake(spider.position.x,?
-spider.texture.contentSize.height);
CCMoveTo* move = [CCMoveTo actionWithDuration:spiderMoveDuration
position:belowScreenPosition];

CCCallBlock* callDidDrop = [CCCallBlock actionWithBlock:^void(){
// move the droppedSpider back up outside the top of the screen
CGPoint pos = spider.position;
CGSize screenSize = [CCDirector sharedDirector].winSize;
pos.y = screenSize.height + spider.texture.contentSize.height;
spider.position = pos;
}];

CCSequence* sequence = [CCSequence actions:move, callDidDrop, nil];
[spider runAction:sequence];
}
runSpiderMoveSequence方法記錄下了落下的蜘蛛數目。每落下8個蜘蛛，spiderMove- Duration就降低，從而增加所有蜘蛛的速度。你也許不熟悉%，它被稱為求模操作符。求模運算的結果是左操作數除以右操作數的余數，即如果numSpidersMoved可以被8整除，那么求模結果為0。
動作序列只包含了一個CCMoveTo動作和一個CCCallBlock動作。動作還有改進的空間，可以使它就像真正的六足蜘蛛人那樣，下落一點點，停住，然后一路下到底。這個任務就留給你了，不過在最終版的DoodleDrop項目中，你可以找到一個示例實現。
到目前為止，唯一重要的是知道我選擇了在傳遞給CCCallBlock動作的block函數中重置了蜘蛛的位置。這個block函數可以簡單地使用與runSpiderMoveSequence方法相同的spider變量。它在蜘蛛的運動完成后調用，即蜘蛛已經掉到了玩家角色的下面。通過使用這個block函數，你就不需要花大力氣找出正確的蜘蛛。而后，將蜘蛛的位置重置為屏幕上方。程序清單4-12將程序清單4-11中的block函數單獨列了出來。
程序清單4-12? 在CCCallBlock中重設蜘蛛位置，使之可以從屏幕上方重新落下
CCCallBlock* callDidDrop = [CCCallBlock actionWithBlock:^void(){
// move the droppedSpider back up outside the top of the screen
CGPoint pos = spider.position;
CGSize screenSize = [CCDirector sharedDirector].winSize;
pos.y = screenSize.height + spider.texture.contentSize.height;
spider.position = pos;
}];
到目前為止，一切順利。我猜你一定迫不及待地想試玩一下。我想你會很快注意到游戲還是缺了些東西。小提示：看一下下面的標題。

?

《ios cocos2d 2 游戲開發實戰（第三版）》試讀電子書免費提供，有需要的留下郵箱。

?

?

?

轉載于:https://my.oschina.net/louiseliu/blog/304218

總結

以上是生活随笔為你收集整理的iOS cocos2d 2游戏开发实战(第3版)---你的第一个游戏！的全部內容，希望文章能夠幫你解決所遇到的問題。

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