По процессу
1. Избегайте разветвленных ассетов.
Всегда, должна быть только одна версия, любого ассета. Если вам абсолютно необходимо ответвить новую версию префаба, сцены или сетки, следуйте процессу, это сделает ясным, какая версия является правильной. «Неправильная» версия должна иметь броское имя, например, использовать двойное подчеркивание префикс: __MainScene_Backup .
2. Каждый член команды, должен иметь второй экземпляр проекта для тестирования, если вы используете систему контроля версий.
Все изменения должны делаться, и тестироваться в нём, и затем вносится в «чистовую» версию. Никто не должен делать какие-либо изменения в их «чистовых» экземплярах. Это особенно полезно, чтобы отловить недостающие ассеты.
3. Рассмотрите возможность использования внешних инструментов для редактирования уровня.
Юнити не лучший инструмент для этого. Например, мы использовали TuDee для создания уровней на основе 3D-тайлов, где есть такие полезные функции, как: привязка к сетке, 2D вид, быстрый выбор тайлов. Простое инстанцирование префабов из XML-файлов.
4. Рассмотрите сохранение уровней в XML, а не в сценах.
Это прекрасный метод:
- это избавляет от необходимости настраивать каждую сцену;
- это делает загрузку намного быстрее (если большинство объектов являются общими для всех сцен).
- это делает легче объединение сцен.
- это делает более легким отслеживание данных уровня.
Вы по-прежнему сможете использовать Unity в качестве редактора уровня (хотя и не должны). Вам нужно будет написать код для сериализации и десериализации данных, для загрузки уровня в редакторе и во время выполнения, а также для сохранения уровня в редакторе. Вам также может понадобиться, имитировать ID систему Unity, для поддержания ссылок между объектами.
5. Рассмотрите написание пользовательского инспектора.
Написать пользовательский инспектор довольно просто, но система Unity имеет много недостатков:
- Он не позволяет воспользоваться преимуществами наследования.
- Он не позволяет определить компоненты инспектора на уровне поля, только на уровне класса. Например, если каждый игровой объект, имеет поле типа SomeCoolType , который вы хотите отобразить в инспекторе иначе, вы должны написать инспектор для каждого класса.
Вы можете решить эти вопросы, повторной реализацией системы инспекторов. Используя несколько приемов рефлексии, это не так сложно, как кажется. Детали, представлены в конце статьи.
Организация сцены
6. Используйте именованные пустые объекты, как папки.
Тщательно организовывайте свои сцены, чтоб облегчить поиск объектов в них.
7. Помещайте при редактировании свои префабы и папки (пустышки) в нулевые координаты (0, 0, 0).
Если префаб/пустышка редактируется не для позиционирования, он должен быть в нуле. Таким образом, уменьшается вероятность возникновения проблем с локальными и мировыми системами координат, и код как правило проще.
8. Минимизируйте использование смещений для компонентов GUI.
Смещения должны использоваться для компоновки компонентов, только относительно их родительского контейнера; они не должны полагаться на позиционирование своих прародителей. Смещения не должны отменять друг друга, чтобы правильно отображаться. Это в основном для предотвращения такого рода вещей:Родительский контейнер произвольно размещен в (100, -50). Ребенок, предназначенный для позиционирования в точке (10, 10), помещен в (90, 60) [относительно родительского].Эта ошибка распространена, когда контейнер невидим, или не имеет визуального представления вообще.
9. Размещайте вашу землю на y=0.
Это облегчает задачу размещение объектов на земле.
10. Делайте игру, готовую к запуску в каждой сцене.
Это значительно сокращает этап тестирования. Для этого нужно сделать 2 вещи:
Во-первых, предоставить в сцене все данные, требующиеся от предшествующих сцен, если они не доступны.
Во-вторых, создайте объекты, которые должны сохраняться между загрузками сцены, следующим образом:
myObject = FindMyObjectInScene();
if (myObjet == null) { myObject = SpawnMyObject(); }
