構圖和CCSpriteBatchNode遊戲對象

Question

我目前正在iPhone上開發一款遊戲，包含cocos2d和box2d。
我讀了很多關於遊戲代碼組織，遊戲對象結構等的文章。 我首先從繼承自CCSprite的基類本身開始開發我的遊戲對象。 我有一個CCSpriteBatchNode可以在一次繪製調用中繪製玩家可以與之交互的所有遊戲物品。這很容易，因爲我的Item類從CCSprite間接繼承，所以我可以輕鬆地將我的項目添加到CCSpriteBatchNode。最重要的是，我可以依靠cocos2d來保留我的對象。

在閱讀文章後，我明白需要用更多面向組合的風格而不是繼承風格來重構我的代碼。 於是我就從NSObject的，並具有屬性，如一個或多個CCSprite繼承了遊戲對象的基類，一個b2Body等

我現在面臨的問題是，我不能直接我的遊戲物體添加到CCSpriteBatchNode了。我首先想到我可以通過將GameObject的sprite屬性添加到CCSpriteBatchNode來輕鬆解決問題。沒關係，但誰保留擁有CCSprite的對象？我如何輕鬆地從CCSprite訪問原始對象（是userData/Object ok）？

我應該創建一個保存我的項目的數組嗎？ 我想知道如何使用CCSpriteBatchNode這樣的遊戲對象結構？

已經有一個thread關於那個沒有答案，我真的很想聽聽這個問題。不是一個直接的答案，而是一些要進一步的內容。

謝謝。

Answer 1

就我個人而言，我不推薦使用NSObject作爲cocos2d類的基類。僅僅因爲你失去了一些cocos2d的便利功能，如調度，你可以很容易地在腳下拍攝自己，內存管理的明智。

你想要的是一個場景中有一個或多個精靈批處理節點的設置。你可以考慮他們的圖層爲你的精靈。來自CCNode的實際遊戲對象（認爲它們是MVC控制器）可以添加到任何地方，通常直接添加到場景中。

scene 
+ batch node 1 
    + sprite 1 
    + sprite 2 
    + sprite n 
+ batch node 2 
    + sprite 1 
    + sprite 2 
    + sprite n 
+ game node 1 
+ game node 2 
+ game node 3 
+ game node n 

要記住的一點是，每場比賽節點都有一個或多個精靈作爲實例變量，但他們不是節點的孩子的。因此，例如遊戲節點1類可能是這樣的：

game node 1 class 
    CCSprite* sprite1; // instance variable 
    CCSprite* sprite2; // instance variable 

現在，當你初始化遊戲節點1和它的精靈，你的精靈添加到適當的精靈批次節點。通常情況下，您需要像訪問單例一樣訪問您的場景以訪問其精靈批處理屬性。

sprite1 = [CCSprite spriteWithSpriteFrameName:@"doodle.png"]; 
[[scene sharedScene].batchNode1 addChild:sprite1]; 
sprite2 = [CCSprite spriteWithSpriteFrameName:@"splash.png"]; 
[[scene sharedScene].batchNode2 addChild:sprite2]; 

請注意，只要它們是精靈批處理節點的子節點，就不需要保留精靈。 addChild方法會爲您保留它。實際上，它只是將它添加到保留的數組中。此外，如果您仍在考慮「保留」，通過所有方式start using ARC。

您不需要弄清楚如何訪問精靈批處理中的精靈。它可以作爲遊戲節點類的實例變量提供，如果您願意，還可以將其作爲屬性公開提供給其他類。

遊戲節點類顯然運行所有對象的遊戲邏輯，包括定位和修改精靈的屬性。在遊戲節點類中唯一需要關注的是您從批處理節點中刪除精靈，否則它可能會泄漏。要做到這一點，覆蓋清理方法：

-(void) cleanup 
{ 
    [sprite1 removeFromParentAndCleanup:YES]; 
    sprite1 = nil; 
    [sprite2 removeFromParentAndCleanup:YES]; 
    sprite2 = nil; 

    [super cleanup]; 
} 

設置變量爲零是非常重要的，因爲有可能是清理後運行的代碼，包括在dealloc方法的代碼。你也可以在dealloc中刪除精靈，但根據你的設置，dealloc甚至可能不會被調用，因爲遊戲節點類仍然持有的精靈引用。因此，如果精靈不是遊戲節點類的孩子（或孫輩），則使用清理方法通常更安全。