6 программных практик, которые нужно сохранить, адоптировать и принять в Unity
Это вторая часть моей серии статей Unity для разработчиков программного обеспечения. Ознакомьтесь с первой статьей о шести фундаментальных концепциях Unity. Серия специально разработана для тех, кто лучше всех учится, как я: начиная с основных принципов и постепенно продвигаясь вверх.
Инженеры-программисты, начинающие с разработки игр, часто ищут передовой опыт и идиоматические приемы. Вы найдете некоторые авторитетные источники идиоматических разработок из выступлений на конференции Unite, сообщений в блоге Unity и таких членов сообщества, как Джейсон Вейманн. Но разработка игр - это не просто инженерия; это тоже искусство. Иногда это означает, что главное - заставить что-то работать. Вы можете найти множество советов типа «делай то, что работает», которые, хотя и действительны и полезны, не совсем направляют вас на правильный путь, когда вы еще учитесь.
Ниже я привожу краткий список практик разработки программного обеспечения, от которых следует отказаться, начиная с разработки игр, тех, которые вам следует принять, и тех, которые вы должны сохранить.
Shed: Храните все в коде
В разработке программного обеспечения часто кажется, что чем больше вы представляете в коде, тем лучше вам: вы можете анализировать свой код, чтобы найти ссылки, перейти к определениям и т.д. Инженер-программист может быть склонен представлять свои сцены, объекты и большую часть игры в коде.
Но вы, вероятно, захотите привыкнуть больше полагаться на пользовательский интерфейс редактора Unity, чем вы ожидали.
Unity Engine выполняет много тяжелой работы в коде сериализации / десериализации и в управлении активами. Если вы программируете в Unity (по крайней мере, когда начинаете), вам захочется плыть по течению.
Как правило, игровой дизайн по своей сути визуален. Размещение ваших объектов в трехмерном пространстве, построение путей патрулирования или настройка поля обзора для этих объектов - все это проще сделать при визуальном редактировании сцены, чем путем обязательной записи координат. Более того, если вам понадобится изменить эти значения позже, визуально это будет менее подвержено ошибкам.
Adopt: напишите свои собственны свойства и структуры
пишите свои собственные триггеры
В том же духе, одно из первых действий, которое вы должны сделать, - это убедиться, что ваши пользовательские компоненты, типы свойств и активы ощущаются как первоклассные граждане в редакторе Unity.
У вас есть собственная структура «Float Range»? Почему бы не убедиться, что вы можете управлять им в редакторе с помощью ползунков, которые гарантируют, что минимальное значение всегда меньше максимального?
У вас есть взаимоисключающие поля MonoBehavior? Напишите собственный MonoBehavior, который отображает их так, как вы хотите.
Сворачиваете собственное дерево диалогов? Представьте это как актив и напишите для него собственный редактор.
Пользовательские триггеры - это не просто отличный способ сделать ваши объекты доступными для редактирования для первоклассных граждан; они также могут быть способом убедиться, что ваши объекты можно отлаживать и тестировать как объекты первого класса. Напишите триггер, который показывает вам некоторое внутреннее состояние вашего объекта в режиме воспроизведения, или добавьте кнопку в свой триггер, которая запускает состояние контролируемым образом (например, кнопка «Я получил удар»).
Keep: Синглтоны имеют тенденцию быть запутывать код
Если вы следите за руководствами по разработке игр или видите обсуждения на форумах, вы увидите синглтоны повсюду. Но во многом по тем же причинам, что и в разработке программного обеспечения, шаблон singleton часто негибкий, непроверенный и может запутать ваши зависимости.
Shed: освоитесь с некоторыми глобальными объектами
Может возникнуть соблазн быть очень строгим в отношении постоянной инкапсуляции состояния и полного разделения проблем. Однако в разработке игр я считаю полезным освоить идею немного большего разделения состояний, чем вы хотели бы в какой-либо другой программной системе.
Частично это может быть связано с тем, что в играх действительно существует более глобальное состояние (например, был ли побежден босс первого уровня, был ли спасен первый город и т.д.?)
Но я утверждаю, что даже заявления о том, что вы можете инкапсулировать, могли бы выиграть, если бы стали немного более глобальными. Например, вы можете инкапсулировать переменную HP в свой компонент Player и использовать ее для управления логикой. Вам также понадобится ваш компонент Player для управления отображением HP в пользовательском интерфейсе и, возможно, эффектами дрожания экрана, когда игрок получает удар. С другой стороны, наличие глобальной переменной «Player HP», которую вы можете передать игроку, объекта HUD и объекта VFX с дрожанием экрана, может быть более чистой альтернативой.
Adopt: Инспектор может быть вашим фреймворком для инъекций
Я упоминал об этом выше, но я думаю, что способ создания чистых глобальных объектов может быть упрощенной формой внедрения зависимостей. Если игроку требуется глобальное значение HP игрока, позвольте компоненту ссылаться на сериализованное поле HP и передать его в инспектор. Вы получите некоторые из приятных вещей в DI (заглушки в тесте, изоляция) без особой «магии», которая делает его таким устрашающим в использовании.
Keep: модульные и интеграционные тесты всегда хороши
Легко потратить много месяцев на чтение о разработке игр и лучших практиках, не читая обсуждений фреймворков тестирования. Для этого Unity предоставляет Unity Test Framework. В этом руководстве Энтони Уччелло содержится обзор того, как начать работу.
В заключение
До сих пор в этой серии мы рассмотрели основы Unity и некоторую интуицию в отношении практик, на которые можно опираться. Далее мы расскажем, как ориентироваться в редакторе Unity и пройдемся по самому минимуму, который вам нужно знать, чтобы разблокировать себя в качестве программиста-одиночки, работающего с освещением, анимацией, вводом и другими инструментами Unity.
