10 самых распространенных ошибок разработчиков Unity

13 минут читать

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

Unity — отличный и простой инструмент для использования в многоплатформенной разработке. .
Содержание
  1. Распространенная ошибка Unity №1: недооценка этапа планирования проекта
  2. Распространенная ошибка Unity №2: Работа с неоптимизированными моделями
  3. Распространенная ошибка Unity №3: построение архитектуры взаимозависимого кода
  4. Распространенная ошибка Unity №4: потеря производительности
  5. Циклы обновления
  6. Создание экземпляров
  7. Рендеринг
  8. Вызовы рисования
  9. Проблемы с перерисовкой
  10. Шейдеры
  11. Распространенная ошибка Unity № 5: игнорирование проблем со сборкой мусора
  12. Распространенная ошибка Unity № 6: оптимизация использования памяти и пространства в последнюю очередь
  13. Распространенная ошибка Unity №7: Общие ошибки физики
  14. Распространенная ошибка Unity № 8: тестирование всей функциональности вручную
  15. Распространенная ошибка Unity № 9: думать, что плагины Unity Asset Store решат все ваши проблемы
  16. Распространенная ошибка Unity № 10: нет необходимости расширять базовые функциональные возможности Unity
  17. Заключение

Распространенная ошибка Unity №1: недооценка этапа планирования проекта

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

С технической точки зрения, необходимо заранее настроить весь рабочий процесс создания ресурсов и моделей, предоставляя их программисту , с особым вниманием к процессу итерации, когда модели потребуют дополнительных изменений и уточнений. У вас должно быть четкое представление о желаемой частоте кадров и бюджете вершин, чтобы 3D-художник мог знать, в каком максимальном разрешении должны быть модели и сколько вариаций LOD он должен сделать. Также следует указать, как унифицировать все измерения, чтобы иметь согласованный масштаб, и процесс импорта во всем приложении.

Способ разработки уровней имеет решающее значение для будущей работы, потому что разделение уровень сильно влияет на производительность. При разработке новых уровней вы всегда должны помнить о производительности. Не допускайте нереалистичных видений. Всегда важно задавать себе вопрос: «Можно ли этого достичь?» В противном случае вам не следует тратить свои драгоценные ресурсы на что-то труднодостижимое (если, конечно, это не является частью вашей бизнес-стратегии, чтобы это было вашим главным конкурентным преимуществом).

Распространенная ошибка Unity №2: Работа с неоптимизированными моделями

Очень важно, чтобы все ваши модели были хорошо подготовлены, чтобы их можно было использовать в сценах без дальнейших изменений. Хорошая модель должна выполнять несколько вещей.

Важно правильно установить масштаб. Иногда невозможно правильно настроить это с помощью программного обеспечения для 3D-моделирования из-за различных единиц, используемых в этих приложениях. Чтобы все было правильно, установите коэффициент масштабирования в настройках импорта моделей (оставьте 0,01 для 3dsMax и Modo, установите 1,0 для Maya) и обратите внимание, что иногда вам потребуется повторно импортировать объекты после изменения настройки масштаба. Эти настройки должны гарантировать, что вы можете использовать только базовый масштаб 1,1,1 в своих сценах, чтобы добиться согласованного поведения и отсутствия проблем с физикой. Более вероятно, что динамическое пакетирование будет работать правильно. Это правило также следует применять к каждому подобъекту модели, а не только к основному. Когда вам нужно настроить размеры объекта, сделайте это в отношении других объектов в приложении для 3D-моделирования, а не в Unity. Тем не менее, вы можете поэкспериментировать с масштабированием в Unity, чтобы найти подходящие значения, но для конечного приложения и согласованного рабочего процесса хорошо все хорошо подготовить перед импортом в Unity.

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

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

Распространенная ошибка Unity №3: построение архитектуры взаимозависимого кода

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

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

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

Распространенная ошибка Unity №4: потеря производительности

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

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

Циклы обновления

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

Создание экземпляров

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

Рендеринг

Используйте методы отсечения окклюзии или LOD, чтобы ограничить рендеринг части сцены. Попробуйте использовать оптимизированные модели, чтобы иметь возможность контролировать количество вершин в сцене. Имейте в виду, что количество вершин — это не просто количество вершин на самой модели, на него влияют другие вещи, такие как нормали (жесткие края), UV-координаты (UV-швы) и цвета вершин. Кроме того, ряд динамических источников света в сцене будет значительно влиять на общую производительность, поэтому старайтесь запекать все заранее, когда это возможно.

Вызовы рисования

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

Проблемы с перерисовкой

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

Шейдеры

Оптимизируйте шейдеры для повышения производительности. Уменьшите количество проходов, используйте переменные с меньшей точностью, замените сложные математические вычисления заранее созданными текстурами поиска.

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

Распространенная ошибка Unity № 5: игнорирование проблем со сборкой мусора

Необходимо понимать, что, несмотря на то, что сборщик мусора (GC) сам по себе помогает нам быть действительно эффективными и сосредоточенными на важных вещах в программировании, есть несколько вещей, о которых мы должны четко знать. . Использование GC платное. Как правило, нам следует избегать ненужного выделения памяти, чтобы сборщик мусора не запускался слишком часто и, таким образом, снижал производительность из-за скачков частоты кадров.. В идеале вообще не должно происходить регулярного выделения памяти в каждом кадре. Однако как мы можем достичь этой цели? Это действительно определяется архитектурой приложения, но есть некоторые правила, которым вы можете следовать, чтобы помочь:

  • Избегайте ненужных выделений в циклах обновления.
  • Используйте структуры для простых контейнеров свойств, поскольку они не размещаются в куче.
  • Попробуйте предварительно выделить массивы, списки или другие коллекции объектов вместо того, чтобы создавать их внутри циклов обновления.
  • Избегайте использования моно проблемных вещей (например, выражений LINQ или циклов foreach), потому что Unity использует старую, не идеально оптимизированную версию Mono (на момент написания это модифицированная версия 2.6 с обновлением в дорожной карте) .
  • Кэшировать строки в методах Awake () или в событиях.
  • Если необходимо обновление свойства строки в цикле обновления, используйте объект StringBuilder вместо строки.
  • Используйте профилировщик для выявления потенциальных проблем.

Распространенная ошибка Unity № 6: оптимизация использования памяти и пространства в последнюю очередь

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

Для поиска истощителей ресурсов вы можете используйте журнал редактора, где вы можете видеть (после каждой новой сборки) размер ресурсов, разделенных на отдельные категории, такие как аудио, текстуры и библиотеки DLL. Для лучшей ориентации в Unity Asset Store есть расширения редактора, которые предоставят вам подробную сводку со ссылками на ресурсы и файлы в вашей файловой системе. Фактическое потребление памяти также можно увидеть в профилировщике, но рекомендуется протестировать его при подключении для сборки на вашей целевой платформе, потому что существует много несоответствий при тестировании в редакторе или на чем-либо, кроме вашей целевой платформы.

Самыми большими потребителями памяти часто являются текстуры. Предпочтительно использовать сжатые текстуры, поскольку они занимают гораздо меньше места и памяти. Сделайте все текстуры квадратными, в идеале сделайте длину обеих сторон равной двум (POT), но имейте в виду, что Unity также может автоматически масштабировать текстуры NPOT в POT. Текстуры можно сжимать, когда они находятся в форме POT. Текстуры атласа вместе, чтобы заполнить всю текстуру. Иногда вы даже можете использовать альфа-канал текстуры для получения дополнительной информации для ваших шейдеров, чтобы сэкономить дополнительное пространство и производительность.. И, конечно же, старайтесь как можно чаще повторно использовать текстуры для своих сцен и используйте повторяющиеся текстуры, когда можно сохранить хороший внешний вид. Для бюджетных устройств вы можете уменьшить разрешение текстур в настройках качества. Используйте сжатый аудиоформат для более длинных аудиоклипов, например фоновой музыки.

Когда вы имеете дело с разными платформами, разрешениями или локализациями, вы можете использовать пакеты ресурсов для использования разных наборов текстур для разных устройств или пользователей. Эти пакеты ресурсов можно динамически загружать из Интернета после установки приложения. Таким образом, вы можете превысить ограничение в 100 МБ, загрузив ресурсы во время игры.

Распространенная ошибка Unity №7: Общие ошибки физики

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

Чтобы изменить положение объекта с помощью Rigidbody на нем, всегда устанавливайте Rigidbody.position , когда новая позиция не следует за предыдущей, или Rigidbody.MovePosition , когда это непрерывное движение, которое также учитывает интерполяцию. При его изменении всегда применяйте операции в FixedUpdate , а не в функциях Update . Это обеспечит согласованное физическое поведение.

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

Распространенная ошибка Unity № 8: тестирование всей функциональности вручную

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

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

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

Распространенная ошибка Unity № 9: думать, что плагины Unity Asset Store решат все ваши проблемы

Поверьте мне; они не будут. Работая с некоторыми клиентами, я иногда сталкивался с тенденцией или пережитками прошлого использовать плагины хранилища активов для каждой мелочи. Я не имею в виду, что в Unity Asset Store нет полезных расширений Unity. Их много, и иногда даже сложно решить, какой выбрать. Но для каждого проекта важно сохранять согласованность, которая может быть нарушена неразумным использованием разных частей, которые плохо сочетаются друг с другом.

С другой стороны, для функциональности, которая потребует много времени Для реализации всегда полезно использовать хорошо протестированные продукты из Unity Asset Store, которые могут сэкономить вам огромное количество времени на разработку. Однако выбирайте осторожно, используйте проверенные, которые не принесут много неконтролируемых и странных ошибок в ваш конечный продукт. Пятизвездочные обзоры — хорошая мера для начала.

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

Распространенная ошибка Unity № 10: нет необходимости расширять базовые функциональные возможности Unity

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

Заключение

Я надеюсь, что эти темы будут вам полезны при дальнейшем продвижении ваших проектов Unity. Есть много вещей, которые относятся к конкретному проекту, поэтому они не могут быть применены, но всегда полезно иметь в виду некоторые основные правила, пытаясь решить более сложные и конкретные проблемы. У вас могут быть разные мнения или способы решения этих проблем в ваших проектах. Самым важным является поддержание единообразия ваших идиом на протяжении всего проекта, чтобы любой член вашей команды мог ясно понять, как должна быть правильно решена конкретная область.

Оцените статью
techsly.ru
Добавить комментарий