Лучшая практика в Cocos2d

Question

Я нахожусь в начале моего приключения по cocos2d, и у меня есть несколько идеологических вопросов.Я делаю небольшую космическую стрелялку, правильно ли я использую следующую структуру классов?

• Сцена
  • Фоновый слой
    • Фон бесконечного параллакса
  • Игровой слой
    • Космические корабли
    • Пули
  • Контрольный слой
    • Джойстик
    • Кнопки

и дополнительный вопрос - каков наилучший способ доступа к объектам из других слоев?Например, когда джойстик обновляется, он должен вращать космический корабль и перемещать фон.Оба из них находятся в других слоях.Есть ли какой-нибудь рекомендуемый способ для этого или я должен просто получить нужные объекты по тегам и оперировать ими?

Answer 1

Cocos - это большая система, основанная на одиночном коде, которая может не понравиться некоторым разработчикам, но часто используется в приложениях Cocos и является фундаментальной архитектурой платформы. Если у вас есть одна основная сцена и много последующих слоев, добавленных к этой сцене, и вы хотите, чтобы элементы управления из одного слоя влияли на спрайты или логику на других слоях, в действительности нет ничего плохого в том, чтобы сделать вашу главную сцену одиночной и отправить информацию с джойстика слой обратно на сцену для обработки других слоев или спрайтов. Я делаю это все время, и эта техника используется в бесчисленных уроках Cocos в книгах и онлайн, так что вы можете почувствовать, что не нарушаете слишком много правил, если вы делаете это таким образом (и это также довольно легко сделать).

Если вместо этого вы решите использовать указатели в одном слое для отправки данных в другие слои, это может доставить вам массу неприятностей, поскольку одному узлу никогда не следует владеть другим узлом, с которым у него нет определенных отношений родитель-потомок , Это может привести к сбоям и проблемам с собственными методами очистки Cocos при последующем удалении сцен и, возможно, к утечке памяти. Вместо этого вы могли бы использовать слабую ссылку в таком случае, но это все еще зависит от одного слоя, ожидающего, что другой слой всегда будет вокруг, что может быть не так.

Отправка данных обратно на главную игровую сцену для последующей отправки и использования соответствующим образом действительно эффективна.

Answer 2

Что касается тегов, один метод, который я использую, чтобы удостовериться, что номера тегов, которые я назначаю, являются уникальными, определяет перечисление следующим образом:

typedef enum
{
    kTag_BackgroundLayer = 100,
    kTag_BackgroundImage,
    kTag_GameLayer = 200,
    kTag_BadGuy,
    kTag_GoodGuy,
    kTag_Obstacle,
    kTag_ControlLayer = 300
    kTag_Joystick,
    kTag_Buttons
};

В большинстве случаев я также просто устанавливаю zOrder и свойства тегов CCNodes (т. Е. CCSprites, CCLabelTTF и т. Д.) Одинаковыми, поэтому вы также можете использовать enum для определения своего zOrder.

Answer 3

Это кажется вполне разумным способом упорядочить ваши объекты, я использую этот метод.

Для доступа к объектам я бы сохранял явную ссылку на объект как переменную-член и использовал бы его напрямую.(Использование тегов не является плохим вариантом, я просто нахожу, что это может стать немного грязным).

@interface Class1 : NSObject
{
    CCLayer *backgroundLayer;
    CCLayer *contentLayer;
    CCLayer *hudLayer;

    CCSprite *objectIMayNeedToUseOnBackgroundLayer;
    CCNode *objectIMayNeedToUseOnContentLayer;

}