О книге «Разработка игр на Unity, 4-е изд.»13.03.2025 17:16

Привет, Хаброжители!

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

Готовы вывести свои навыки работы на Unity на новый уровень? Представляем вашему вниманию долгожданное четвертое издание книги «Разработка игр на Unity». Это полноценное руководство, которое поможет раскрыть весь потенциал Unity.

Что внутри книги?

Каждая глава книги построена так, чтобы читатель мог не просто копировать код, а полноценно разработать свою игру, начиная с базовых концепций и заканчивая сложными техниками. Авторы уделяют внимание новейшим возможностям Unity, включая дополненную реальность и оптимизацию производительности с использованием стека технологий, ориентированных на данные (DOTS).

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

Для кого эта «Разработка игр на Unity»?

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

Авторы рекомендуют выполнять все шаги, описанные в книге, параллельно с изучением материала. Это позволит получить практический опыт и глубокое понимание концепций. Файлы проекта организованы по главам, что упрощает отслеживание изменений и позволяет продолжить работу с любой главы, даже если предыдущие не были завершены.

В общих чертах о «Разработке игр на Unity» мы рассказали, а следом предлагаем рассмотреть подачу материала на примере отрывка:

Столкновения и здоровье: точное определение столкновений

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

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

Симуляция физики

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

Начнем с изучения различных видов коллайдеров, которые предлагает Unity, и способов их настройки для обнаружения различных видов физических реакций (столкновений и триггеров). Наконец, обсудим, как игнорировать столкновения между определенными объектами, чтобы избежать таких ситуаций, как нанесение урона игроку его собственными пулями.

Установочные формы

В начале книги вы узнали, что объекты обычно имеют две формы: визуальную (3D-сетка) и физическую (коллайдер, который используется для расчета столкновений). Помните, что идея заключается в том, чтобы позволить вам иметь высокодетализированную визуальную модель, наложенную на упрощенную физическую форму, для повышения производительности.

В Unity есть несколько типов коллайдеров, и сейчас мы рассмотрим основные из них, начиная с примитивных форм — куба, сферы и капсулы. С точки зрения производительности они являются самыми дешевыми, поскольку столкновения между ними рассчитываются по математическим формулам, в отличие от сетчатого коллайдера Mesh Collider, который позволяет задействовать любую сетку в качестве физического тела объекта, но с более высокой нагрузкой на вычислительные мощности и некоторыми ограничениями. Идея заключается в том, что вы должны использовать примитивные коллайдеры для представления объектов или их комбинации. Например, самолет можно сделать с помощью двух кубов: один для корпуса, а другой для крыльев. На рис. 7.1 показан коллайдер оружия, состоящий из примитивов.

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

Теперь добавим необходимые коллайдеры в нашу сцену, чтобы подготовить ее к корректному расчету столкновений. Если вы работаете с пакетом окружения из магазина Asset Store, отличным от нашего, у вас уже могут быть модули сцены с коллайдерами.

Чтобы добавить коллайдеры, выполните следующие действия.

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

2. Один из вариантов — создать префаб и заменить все стены его экземплярами (рекомендуемое решение). В качестве альтернативы можно просто выделить все стены в меню Hierarchy (щелкая на них, зажав Ctrl или command на Mac) и нажать кнопку Add Component, чтобы добавить коллайдер ко всем стенам. Мы используем компонент в виде куба Box Collider, который автоматически адаптирует размер коллайдера к сетке. Если этого не происходит, вы можете вручную изменить свойства Size и Center компонента Box Collider, чтобы охватить всю стену (рис. 7.2).

3. Повторите шаги 1 и 2 для углов, пола и любых других препятствий, которые будут блокировать движение игрока и противника.

Теперь, когда мы добавили коллайдеры к стенам и полу, сделаем то же самое с персонажем игрока и противником. Мы добавим к ним коллайдер Capsule Collider — стандартный коллайдер в виде капсулы для подвижных персонажей, поскольку закругленное основание позволяет объекту плавно подниматься по пандусам. Кроме того, округлая форма капсулы позволяет легко поворачиваться в углах, не застревая.

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

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

Иногда коллайдер плохо адаптируется к визуальной форме объекта. В моем случае коллайдер Capsule не подошел персонажу, и мне пришлось скорректировать его форму, установив следующие значения: Center — 0, 1, 0, Radius — 0.5 и Height — 2 (рис. 7.3).

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

Если посмотреть на компоненты ландшафта, можно увидеть, что у него есть собственный коллайдер — Terrain collider — единственно возможный коллайдер.

Типы физических объектов

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

• Статический коллайдер (Static Collider). Как следует из названия, этот тип коллайдера не должен двигаться (за редкими исключениями). Большинство объектов окружения, такие как стены, полы, препятствия и рельеф, попадают в эту категорию. Эти типы коллайдеров — просто коллайдеры без компонента Rigidbody, то есть они присутствуют в симуляции, но физические силы на них не действуют. Их нельзя сдвинуть другими объектами, и они всегда остаются на своем месте. Учтите, что это не связано с флажком Static в правом верхнем углу редактора — он предназначен для систем, которые мы рассмотрим позже (например, в главе 12), поэтому при необходимости вы можете снять флажок.
• Физический коллайдер (Physics Collider). Это коллайдеры с компонентом Rigidbody, как в примере с падающим шаром, который мы создали в первой части книги. Это полностью управляемые физикой объекты, на которые действует гравитация и другие силы. Такой тип коллайдера можно использовать для игрока, гранат, падающих ящиков или иных объектов, как в играх с сильно выраженной физикой, таких как The Incredible Machine.
• Кинематический коллайдер (Kinematic Collider). Это коллайдеры с компонентом Rigidbody, у которых установлен флажок Is Kinematic. Они не реагируют на столкновения и физические силы, как статические коллайдеры, но могут двигаться, что позволяет физическим коллайдерам правильно обрабатывать столкновения с ними при движении. Такие коллайдеры часто применяются к объектам, которые должны двигаться с помощью анимации или пользовательских скриптов, например в движущихся платформах.
• Статический коллайдер с триггером (Trigger Static Collider). Это обычный статический коллайдер, но с установленным флажком Is Trigger. Разница в том, что когда кинематические и физические объекты проходят через него, автоматически генерируется событие Trigger. Его можно обрабатывать с помощью скриптов для определения, когда что-то вошло в область коллайдера. Это событие можно использовать для создания кнопок, запуска действий, когда игрок проходит через какую-то зону, например порождения волны врагов, открытия двери или победы в игре. Обратите внимание, что обычные статические коллайдеры не будут генерировать триггерное событие при прохождении через этот тип, потому что они не предназначены для движения.
• Кинематический коллайдер с триггером (Trigger Kinematic Collider). Кинематические коллайдеры не генерируют столкновения, но могут генерировать события Trigger, когда проходят через другие объекты. Это можно использовать для создания подвижных бонусов, которые исчезают при соприкосновении с персонажем и приносят очки, или для пуль, движущихся с помощью пользовательских скриптов и без физики, но наносящих урон другим объектам при столкновении.

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

В табл. 7.1 приведена реакция объектов при контакте с различными типами коллайдеров. В строках представлены профили, которые могут двигаться (помните, что статичные профили не должны двигаться), а в столбцах — тип коллайдера, с которым происходит столкновение. Слово «ничего» означает, что объект пройдет сквозь другой без эффекта, «триггер» — что объект пройдет сквозь, но вызовет событие Trigger, а «столкновение» — что объект не может пройти сквозь другой.

Учитывая это, начнем настраивать физику объектов.

Стены, углы, полы и препятствия должны использовать профиль статического коллайдера. Это значит, что у них отсутствует компонент Rigidbody и у их коллайдеров будет снят флажок Is Trigger (рис. 7.4).

Игрок должен двигаться и сталкиваться с объектами, поэтому нам нужно, чтобы у него был динамический профиль (рис. 7.5). Этот профиль вызовет забавное поведение с нашим текущим скриптом движения (проверьте), особенно при столкновении со стенами. Мы разберемся с этим чуть позже.

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

Префаб Bullet перемещается благодаря скрипту (пуля просто движется вперед), а не физике. Нам не нужны столкновения. Мы запрограммируем пулю так, чтобы она уничтожалась при касании чего-либо и наносила урон объекту, с которым столкнется (если это возможно). Поэтому здесь достаточно кинематического профиля с триггером. Мы будем использовать событие Trigger для скрипта реакции на контакт (рис. 7.7).

Теперь, когда мы настроили объекты, проверим, как отфильтровать нежелательные столкновения между определенными типами объектов.

Фильтрация столкновений

Иногда нам нужно, чтобы определенные объекты игнорировали друг друга, скажем, пули, выпущенные игроком, не должны сталкиваться с самим игроком. Этого можно добиться с помощью оператора if в скрипте C#, проверяя, например, является ли попавший объект представителем противоположной команды. Однако эта проверка столкновения между объектами, которые никогда не должны были столкнуться, — пустая трата ресурсов. И здесь нам на помощь приходит матрица столкновений слоев.

«Матрица столкновений слоев» звучит пугающе, но это обычный инструмент системы физики, который позволяет нам указать, какие группы объектов должны сталкиваться с другими группами. Например, пули игрока должны сталкиваться с противниками, а их — с игроком. В данном случае вражеские пули будут проходить сквозь врагов, что для нас является желаемым результатом. Идея в том, чтобы формировать группы, которые в Unity называются слоями, и помещать в них наши объекты. Мы можем создавать слои и присваивать их объектам через свойство слоя (верхняя часть панели Inspector). Обратите внимание, что у вас ограниченное количество слоев, поэтому используйте их с умом.

Вы можете добиться этого, выполнив следующие действия.

1. Перейдите в меню Edit Project Settings и найдите на левой панели пункт Tags and Layers (рис. 7.8).

2. В разделе Layers заполните пустые места, чтобы создать слои. В нашем случае с пулями нам нужно четыре слоя: Player, Enemy, PlayerBullet и EnemyBullet (рис. 7.9).

3. Выберите объект игрока в меню Hierarchy и измените свойство Layer на Player в верхней части Inspector. Также измените слой префаба Enemy на Enemy. Появится окно с предложением изменить дочерние объекты; нажмите Yes (рис. 7.10).

4. В случае с пулей возникает проблема: у нас один префаб, но два слоя, а у префаба может быть только один слой. Здесь два варианта: изменить слой в зависимости от стрелка с помощью скриптов или создать два разных префаба пуль для каждого слоя. Для простоты мы выберем последний вариант, а также применим другой материал к вражеской пуле, чтобы она выглядела иначе.

5. Мы создадим дополнительный вариант префаба пули игрока. Помните, что вариант — это префаб, основанный на оригинальном, подобно наследованию классов. При изменении оригинального префаба изменится и его вариант, у которого, в свою очередь, могут быть свои уникальные отличия.

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

7. Снова перетащите экземпляр в папку Prefabs, на этот раз выбрав в появившемся окне пункт Prefab Variant.

8. Переименуйте его в Enemy Bullet.

9. Удалите экземпляр префаба в сцене.

10. Создайте второй материал, похожий на материал пули игрока, но другого цвета, и примените его к варианту префаба вражеской пули.

11. Выберите префаб пули врага, установите слой EnemyBullet и сделайте то же самое для оригинального префаба (PlayerBullet). Даже если вы измените слой исходного префаба, при модификации варианта будет преобладать измененная версия (или переопределение), что позволит каждому префабу иметь собственный слой.

Теперь, когда мы настроили слои, сконфигурируем систему физики на их использование.

1. Перейдите в Edit Project Settings и найдите параметры физики Physics (не Physics 2D).

2. Прокрутите страницу вниз, пока не увидите матрицу столкновения слоев (Layer Collision Matrix). Каждый столбец и строка матрицы подписаны названиями слоев, поэтому каждый флажок на пересечении строки и столбца позволит нам указать, должны ли объекты сталкиваться. В нашем случае мы настроили матрицу так, как показано на рис. 7.11, чтобы пули игрока не попадали в самого игрока или в другие его пули, а пули врагов не задевали самих врагов и их пули.

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

Теперь, когда мы отфильтровали столкновения, проверим, корректно ли работают наши настройки.

Обнаружение столкновений

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

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

Обработка триггерных событий

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

Эти события делятся на две группы: события столкновения и события триггера, поэтому в зависимости от настроек вашего объекта нужно выбрать соответствующую группу. Обе группы имеют три основных события: Enter, Stay и Exit, которые сообщают нам, когда началось столкновение или триггер (Enter), происходит ли оно все еще или продолжается контакт (Stay) и когда оно завершилось (Exit). Например, мы можем запрограммировать такое поведение, как воспроизведение какого-либо звука при первом контакте двух объектов в событии Enter и его остановка при прекращении контакта в событии Exit.

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

1. Создайте и добавьте скрипт ContactDestroyer к префабу пули игрока. Поскольку префаб вражеской пули является его вариантом, он также будет использовать этот скрипт.

2. Чтобы обнаружить момент срабатывания триггера, как, например, в Start и Update, создайте функцию события OnTriggerEnter.

3. Внутри события используйте строку Destroy(gameObject);, чтобы пуля самоуничтожалась при столкновении с чем-либо (рис. 7.12).

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

На данный момент нам не понадобятся другие события столкновения. Если они вам понадобятся, они будут работать аналогичным образом; просто создайте вместо них функцию с именем OnCollisionEnter.

Теперь рассмотрим другую версию той же функции. Мы настроим ее так, чтобы она не только сообщала нам о том, что мы коснулись чего-то, но и о том, с чем именно был контакт. Мы также настроим Contact Destroyer, чтобы он уничтожал и другой объект. Для этого выполните следующие действия.

1. Замените сигнатуру метода OnTriggerEnter той, что показана на рис. 7.13. Эта версия принимает параметр типа Collider, указывающий на конкретный коллайдер, с которым произошел контакт.

2. Мы можем получить доступ к игровому объекту этого коллайдера через свойство gameObject. С его помощью можно уничтожить и другой коллайдер (рис. 7.14). Если просто вызвать функцию Destroy, передав ей переменную other, она уничтожит только компонент Collider.
3. Сохраните и протестируйте скрипт. Вы заметите, что пуля уничтожает все на своем пути. Убедитесь, что у вашего врага есть коллайдер капсулы, чтобы пуля могла обнаружить столкновение с ним.

Эквивалентная версия, написанная с помощью визуального программирования, выглядит следующим образом (рис. 7.15).

Как видите, мы создали узел On Trigger Enter и связали его с двумя узлами Destroy. Чтобы указать, какой объект будет уничтожен каждым из узлов Destroy, мы дважды использовали узел Component: Get GameObject. Правый узел был создан без узла, подключенного к его левому входному выводу, что означает, что он возвращает игровой объект, который в данный момент выполняет этот скрипт (отсюда и метка This в левом выводе узла), в данном случае пулю. Для второго узла мы подключили выходной вывод Collider справа от узла On Trigger Enter к узлу Get GameObject. Таким образом мы указываем, что хотим получить игровой объект, содержащий коллайдер, с которым столкнулась наша пуля.

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

Изменение другого объекта

Чтобы пуля наносила урон объекту, нам нужно получить доступ к компоненту Life для изменения его количества. Для этого мы создадим компонент Life, который должен содержать поле типа float с показателем здоровья. Каждый объект с этим компонентом будет считаться объектом, которому можно нанести урон. Чтобы получить доступ к компоненту Life из скриптов пули, нам понадобится функция GetComponent.

Если у вас есть ссылка на игровой объект или его компонент, вы можете использовать GetComponent для доступа к определенному компоненту, если объект содержит его (если нет, то вернется null). Посмотрим, как задействовать эту функцию, чтобы пуля уменьшала количество жизни другого объекта.

1. Создайте и добавьте компонент Life с публичным полем типа float под названием amount к префабам игрока и врага. Не забудьте установить значение 100 (или любое другое) в поле Amount на панели Inspector (рис. 7.16).

2. Удалите компонент ContactDestroyer из пули игрока, что также приведет к его удалению из варианта пули противника.

3. Добавьте новый скрипт под названием ContactDamager к врагу и игроку.

4. Добавьте событие OnTriggerEnter, которое принимает другой коллайдер в качестве параметра, и просто вызовите функции Destroy, чтобы пуля уничтожала сама себя, а не объект, с которым сталкивается; наш скрипт будет просто сокращать количество очков здоровья.

5. Добавьте поле типа float под названием damage, чтобы мы могли настроить количество урона, наносимого другому объекту. Не забудьте сохранить файл и установить значение, прежде чем продолжить.

6. Используйте GetComponent для ссылки на другой коллайдер, чтобы получить доступ к его компоненту Life и сохранить его в переменной (рис. 7.17).

7. Перед тем как уменьшить показатели здоровья объекта, мы должны проверить, что ссылка на Life не является null. Это произойдет, если другой объект не содержит компонент Life, как в случае со стенами и препятствиями. Идея заключается в том, что пуля будет уничтожать себя при столкновении с любым объектом, а также уменьшать очки здоровья другого объекта, если это повреждаемый объект, содержащий компонент Life.
8. Поместите врага в сцену и установите его скорость на 0, чтобы он не двигался.

9. Выберите его в меню Hierarchy, прежде чем нажать кнопку Play, и постреляйте по нему.

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

Теперь вы заметите, что количество очков здоровья уменьшается вплоть до отрицательных значений. Однако нам нужно, чтобы объект уничтожался при достижении нулевых показателей здоровья. Этого можно добиться двумя способами: один из них — добавить метод Update к компоненту Life, который будет покадрово проверять, опустились ли очки здоровья ниже 0, а затем уничтожать объект, когда это произойдет.

Второй способ — инкапсулировать поле amount и проверять его значение внутри сеттера, чтобы избежать покадровой проверки. Я предпочитаю второй способ, но мы реализуем первый, чтобы наши скрипты выглядели как можно проще для новичков.

Но прочитать о втором способе подробнее рекомендуем из самой книги. Переходите на наш сайт и ознакомьтесь с «Разработкой игр на Unity, 4-е изд.»

» Оглавление
» Отрывок

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Unity