Инженеры-программисты, начинающие разработку игр, часто ищут передовой опыт и идиоматические приемы. Вы найдете некоторые авторитетные источники идиоматического развития из выступлений на Конференции Unity Unity, сообщений в блоге Unity и членов сообщества, таких как Jason Weimann. Но разработка игр — это не только проектирование; это тоже искусство. Иногда это означает, что центральное место занимает заставить что-то работать. Вы можете найти много советов в духе делай то, что работает, которые, хотя и верны и полезны, не совсем направляют вас по правильному пути, когда вы все еще учитесь.
Ниже я привожу краткий список методов разработки программного обеспечения, от которых следует отказаться, приступая к разработке игр, тех, которые следует перенять, и тех, которые следует сохранить. >.
Сарай: Держите все это в коде
В программной инженерии часто кажется, что чем больше вы представляете в коде, тем лучше для вас: вы можете проанализировать свой код, чтобы найти ссылки, перейти к определениям и т. д. Инженер-программист может быть склонен представлять свои сцены, объекты и большая часть игры в коде.
Но вы, вероятно, захотите привыкнуть к пользовательскому интерфейсу редактора Unity больше, чем вы ожидали.
Просто установив «Patrol Position» для пустого игрового объекта, вы уже получите удобный опыт визуального редактирования игры.
Unity Engine делает много тяжелой работы в своем коде сериализации/десериализации и в управлении активами. Если вы программируете в Unity (по крайней мере, когда начинаете), вам захочется плыть по течению.
Дизайн игры также по своей сути визуален, обычно. Размещение ваших объектов в 3D-пространстве, построение путей патрулирования охранников или настройка поля зрения для этих охранников — все это проще сделать при визуальном редактировании сцены, чем путем императивной записи координат. Более того, если вам нужно будет изменить эти значения позже, визуально это менее подвержено ошибкам.
Внедрение: напишите свои собственные пользовательские редакторы и ящики свойств
Точно так же одна из первых вещей, которую вы должны сделать, это убедиться, что ваши пользовательские компоненты, типы свойств и активы выглядят как первоклассные граждане в редакторе Unity.
У вас есть собственная структура «Float Range»? Почему бы не убедиться, что вы можете манипулировать им в редакторе с помощью ползунков, которые гарантируют, что минимум всегда меньше максимума?
У вас есть MonoBehaviour с взаимоисключающими полями? Напишите собственный редактор для MonoBehaviour, который отображает их так, как вы хотите.
Создаете собственное дерево диалогов? Представьте это как актив и напишите для него собственный редактор.
Пользовательские редакторы — это не просто отличный способ сделать ваши объекты редактируемыми как первоклассные граждане; они также могут быть способом убедиться, что ваши объекты можно отлаживать и тестировать как первоклассные объекты. Напишите редактор, который показывает вам часть внутреннего состояния вашего объекта в режиме воспроизведения, или добавьте в редактор кнопку, которая запускает состояние контролируемым образом (например, кнопка «Я попал»).
Пример компонента Interactable позволяет устанавливать эффекты, когда игрок инициирует взаимодействие.
Дополнительные сведения см. в документации Unity по разделам Пользовательские редакторы и Списки свойств. Также полезно посмотреть Видео окна редактора Brackeys.
Keep: синглтоны, как правило, пахнут кодом
Если вы следите за учебными пособиями по разработке игр или читаете обсуждения на форумах, вы увидите синглтоны повсюду. Но по тем же причинам, что и в разработке программного обеспечения, одноэлементный шаблон часто бывает негибким, непроверяемым и потенциально может запутать ваши зависимости.
Сарай: освойтесь с некоторыми глобальными переменными
Может показаться заманчивым быть очень строгим в отношении всегда инкапсуляции состояния и полного разделения задач. Тем не менее, в разработке игр я считаю полезным привыкнуть к идее немного совместного использования состояния, чем в какой-либо другой программной системе.
Частично это может быть связано с тем, что в играх действительно более глобальное состояние (например, был ли побежден босс первого уровня, был ли спасен первый город и т. д.?)
Но я утверждаю, что даже состояния, которые вы можете инкапсулировать, могут выиграть от того, что они будут немного более глобальными. Например, вы можете инкапсулировать переменную HP в свой компонент Player и использовать ее для управления логикой. Вам также понадобится компонент Player для управления отображением HP в пользовательском интерфейсе и, возможно, эффектами дрожания экрана, когда игрок получает удар. С другой стороны, наличие глобальной переменной «Player HP», которую вы можете передать игроку, объекта HUD и объекта VFX сотрясения экрана может быть более чистой альтернативой.
Примите: Инспектор может стать вашей системой инъекций
Я упомянул об этом выше, но я думаю, что способ, которым вы можете иметь чистые глобальные переменные, может быть упрощенной формой внедрения зависимостей. Если игроку требуется глобальное значение Player HP, пусть компонент ссылается на сериализованное поле HP и передает его в инспектор. Вы получите некоторые приятные особенности DI (заглушение в тесте, изоляция) без особого «волшебства», которое делает его таким пугающим в использовании.
Подробнее в Докладе Райана Хиппла о Scriptable Objects. Если вы хотите узнать больше о Scriptable Objects, я написал об их сериализации и обзоре их использования в учебнике по Unity.
Keep: модульные и интеграционные тесты всегда хороши
Легко провести много месяцев, читая о разработке игр и лучших практиках, не читая обсуждения тестовых фреймворков. Для этого Unity предоставляет Unity Test Framework. Это руководство Энтони Уччелло содержит обзор того, как начать работу.
Я надеюсь, что это помогло выработать некоторые интуитивные практики, на которые можно опереться. Довериться своему чутью инженера-программиста обычно будет правильным выбором, хотя в некоторых случаях оправдан шаг назад.
Эта статья изначально была частью серии под названием Unity для разработчиков программного обеспечения.
