Организуйте игровое содержание в сцены

Сцены являются фундаментальными стандартными блоками для создания содержания Набора Sprite. При запуске нового игрового проекта одна из задач состоит в том, чтобы определить, какие сцены необходимы и когда переходы происходят между теми сценами. Сцены обычно представляют режимы игры или содержания, появляющегося к проигрывателю. Обычно, просто видеть при необходимости в новой сцене; если Ваша игра должна заменить все содержание на экране, используйте переход к новой сцене.

Разработка сцен Вашей игры и переходов между ними подобна роли контроллеров представления в традиционном приложении для iOS. В приложении для iOS содержание реализовано контроллерами представления. Каждый контроллер представления создает набор представлений для рисования того содержания. Первоначально, один контроллер представления представлен окном. Позже, когда пользователь взаимодействует с представлениями контроллера представления, это могло бы инициировать переход к другому контроллеру представления и его содержанию. Например, выбор элемента в табличном представлении мог бы перевести подробный контроллер представления в рабочее состояние для отображения содержания выбранного пункта.

Сцены не имеют поведения по умолчанию, как раскадровки делают в традиционном приложении для iOS. Вместо этого Вы определяете и реализуете способы поведения для сцен. Эти способы поведения включают:

• Когда создаются новые сцены

• Содержание каждой сцены

• Когда переходы происходят между сценами

• Визуальный эффект раньше выполнял переход

• Как данные передаются от одной сцены до другого

Например, Вы могли реализовать модель, подобную переходу, где новая сцена всегда инстанцируют на переходе. Или Вы могли разработать свой игровой механизм для использования сцен, которые он постоянно имеет в наличии. Каждый подход обладает своими преимуществами:

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

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

Используйте разделение на подклассы для создания собственных способов поведения узла

Разработка новых игр требует, чтобы Вы сделали подклассы SKScene класс. Однако другие классы узла в Наборе Sprite также разработаны, чтобы быть разделенными на подклассы так, чтобы можно было добавить пользовательское поведение. Например, Вы могли бы разделить на подклассы SKSpriteNode класс для добавления логики AI, определенной для игры. Или, Вы могли бы разделить на подклассы SKNode класс для создания класса, реализующего определенный уровень получения в сцене. И если Вы хотите непосредственно реализовать интерактивность в узле, необходимо создать подкласс.

При разработке нового класса узла существуют подробные данные реализации, определенные для Набора Sprite, которые важны для понимания. Но также необходимо рассмотреть роль, которую новый класс играет в игре и как объекты класса взаимодействуют с другими объектами. Необходимо создать четко определенные интерфейсы класса и соглашения о вызовах так, чтобы объекты взаимодействовали без тонких ошибок, замедляющих процесс разработки.

Вот важные инструкции для следования при создании собственных подклассов:

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

• Несмотря на то, что узлы подобны представлениям, Вы не можете добавить новое поведение получения к классу узла. Необходимо работать через существующие методы и свойства узла. Это означает любое управление собственными свойствами узла (такими как изменение текстуры спрайта) или добавление дополнительных узлов и управление их поведением. В любом случае необходимо рассмотреть, как класс собирается взаимодействовать с другими частями кода. Вы, возможно, должны установить свои собственные соглашения о вызовах избежать тонких ошибок рендеринга. Например, одно общее соглашение состоит в том, чтобы избежать добавлять дочерние элементы к объекту узла, создающему и управляющему его собственными дочерними узлами.

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

• Если Вы хотите реализовать обработку событий в классе узла, необходимо реализовать отдельный код обработки событий для iOS и OS X. SKNode класс наследовался от NSResponder на OS X и UIResponder на iOS.

• В некоторых игровых проектах можно полагаться на факт, что определенная комбинация классов всегда будет используемой вместе в определенной сцене. В других проектах можно хотеть создать классы, которые могут использоваться в многократных сценах. Чем более важное повторное использование к Вашему проекту, тем больше времени необходимо потратить разработку чистые интерфейсы для объектов взаимодействовать друг с другом. Когда два класса будут зависеть друг от друга, используйте делегацию для повреждения той зависимости. Чаще всего Вы делаете это путем определения делегата на узле и протоколе для делегатов в реализации. Ваша сцена (или другой узел, такой как родитель узла) реализует этот протокол. Ваш класс узла может тогда быть снова использован в многократных сценах, не будучи должен знать класс сцены.

• Следует иметь в виду, что, когда класс узла инициализируется, это еще не находится в сцене, таким образом, parent и scene свойства nil. Вы, возможно, должны задержать некоторую работу инициализации, пока узел не будет добавлен к сцене.

Рисование Вашего содержания

Значительная часть создания дерева узла организует графическое содержание, которое должно быть нарисовано. Какие потребности быть нарисованным сначала? Какие потребности быть нарисованным в последний раз? Как представляются эти вещи?

Рассмотрите следующий совет при разработке дерева узла:

• Не добавляйте узлы содержания или организации физики к сцене непосредственно. Вместо этого добавьте один или больше SKNode объекты к дереву, чтобы представлять различные уровни содержания в Вашей игре и затем работать с теми расположенными на слое объектами. Можно тогда точно управлять содержанием каждого уровня. Например, можно повернуть один уровень содержания, не поворачивая все содержание сцены. Для Вас также становится проще удалить или заменить части Вашего рендеринга сцены с другим кодом. Например, если игровые очки и другая информация играются в настороженном уровне дисплея, то этот уровень может быть удален, когда Вы хотите взять снимки экрана. В очень сложном приложении Вы могли бы продолжать этот образец глубже в Ваше дерево узла путем добавления дочерних элементов к узлу уровня.

  При использовании уровней, чтобы организовать содержание, рассмотреть, как уровни взаимодействуют друг с другом. Они знают что-нибудь о содержании друг друга? Высокоуровневый уровень должен знать что-нибудь о том, как нижние уровни представляются для рендеринга его собственного содержания?

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

• Каждый раз, когда возможно, узлы, представляющиеся вместе, должны использовать тот же режим смешивания. Если все дочерние элементы узла используют тот же режим смешивания и текстурируют атлас, то Набор Sprite может обычно рисовать эти спрайты в единственной передаче получения. С другой стороны, если дочерние элементы организованы так, чтобы изменения режима получения для каждого нового спрайта, тогда Набор Sprite мог бы выполнить как одна передача получения на спрайт, который довольно неэффективен.

• При разработке эмиттерных эффектов используйте низкие уровни рождаемости частицы, когда это возможно. Частицы не свободны; каждая частица добавляет рендеринг и рисование наверху.

• По умолчанию спрайты и другое содержание смешиваются с помощью альфа-режима смешивания. Если содержание спрайта непрозрачно, такой что касается фонового изображения, используйте SKBlendModeReplace режим смешивания.

• Используйте игровую логику и художественные активы, соответствующие координату Набора Sprite и соглашения вращения. Это означает ориентировать иллюстрации вправо. При ориентации иллюстраций в некотором другом направлении необходимо преобразовать углы между соглашениями, используемыми искусством и соглашениями, используемыми Набором Sprite. Например, если иллюстрации ориентированы вверх, то Вы добавляете PI/2 радианы к углу для преобразования от соглашения Набора Sprite до соглашения искусства и наоборот.

• Включите сообщения диагностики в SKView класс. Используйте частоту кадров в качестве общей диагностики для производительности и узел и получающий количества передачи, чтобы далее понять, как было представлено содержание. Можно также использовать Инструменты и его инструменты диагностики OpenGL для нахождения дополнительной информации о том, где игра проводит свое время.

• Протестируйте свою игру на реальных аппаратных средствах, и на устройствах с различными характеристиками. Во многих случаях баланс ресурсов CPU и ресурсов GPU отличается на каждом Mac или устройстве на iOS. Тестирование на многократных устройствах помогает Вам определить, работает ли Ваша игра хорошо на большинстве устройств.

Работа с игровыми данными

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

• Активы Искусства и требуемые данные для рендеринга тех иллюстраций правильно

• Уровень или разметки проблемы

• Данные раньше конфигурировали геймплей (такой как скорость монстра и сколько ущерба это наносит, когда это атакует),

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

Лучшее место, чтобы хранить игровые данные зависит от того, где те данные используются в Вашей игре. Для данных, не связанных с Набором Sprite, список свойств, сохраненный в Вашем комплекте приложений, является хорошим решением. Однако для данных Набора Sprite, у Вас есть другая опция. Поскольку вся архивация поддержки классов Набора Sprite, можно просто создать архивы важных объектов Набора Sprite и затем включать эти архивы в игру. Например, Вы могли бы:

• Сохраните игровой уровень как архив узла сцены. Этот архив включает сцену, всех ее потомков в дереве узла и все их связанные организации физики, соединения и действия.

• Сохраните отдельные архивы для определенных предварительно сконфигурированных узлов, такого узла для каждого монстра. Затем когда новый монстр должен быть создан, Вы загружаете его из архива.

• Сохраните сохраненные игры как архив сцены.

• Создайте свои собственные инструменты, чтобы создать и отредактировать заархивированное содержание. Затем Ваши разработчики компьютерных игр и художники могут работать в этих инструментах, чтобы создать игровые объекты и заархивировать их использующий формат, который читает Ваша игра. Ваш игровой механизм и Ваши инструменты совместно использовали бы общие классы.

• Вы могли хранить данные Набора Sprite в списке свойств. Ваша игра загружает список свойств и использует его для создания игровых активов.

Вот несколько инструкций для работы с архивами:

• Используйте userData свойство на узлах, чтобы хранить специфичные для игры данные, особенно если Вы не реализуете свои собственные подклассы.

• Избегите ссылок жесткого кодирования на определенные узлы. Вместо этого дайте интересным узлам уникальное name свойство и ищет их в дереве.

• Пользовательские действия, вызывающие блоки, не могут быть заархивированы. Необходимо создать и добавить те действия в игре.

• Большинство объектов узла обеспечивает все необходимые свойства для определения то, что они и как они были сконфигурированы. Однако действия и организации физики не делают. Это означает, что при разработке собственных игровых инструментов, Вы не можете просто заархивировать действия и организации физики и использовать эти архивы, чтобы хранить Ваши данные инструмента. Вместо этого архивы должны только быть окончательным результатом от Ваших игровых инструментов.