Download to read offline
Uploaded bySperasoft
Организация работы с UE4 в команде до 20 человек
Документ описывает организацию работы в команде из до 20 человек с использованием UE4 и Visual Studio, включая инструменты как Trello, GitLab и TeamCity. Он охватывает роли участников, управление проектом, интеграцию контента, контроль версий и циклы разработки. Основное внимание уделяется правильной организации папок, обучению, рефакторингу и созданию функциональных фич.
![[Data Science MeetUp] Neural Network - Константин Созыкин (RoadAR): Современн...](https://cdn.slidesharecdn.com/ss_thumbnails/deep-learning-frieimvorki-170614085232-thumbnail.jpg?width=640&height=640&fit=bounds)
Организация работы с UE4 в команде до 20 человек
- 1. Организация работы сUE4 (в команде до 20 человек)
- 2.
- 3.
- 4. 1 2 3 4 5 6 7 8 9 UE4 + VisualStudio Trello (Kanban) GitLab TeamCity Confluence Инструментарий
- 5. 1 2 3 4 5 6 7 8 9 Роли + компетенции Геймдизайнеры Программисты+ скриптеры Артовики Менеджемент - ноль
- 6.
- 7. 1 2 3 4 5 6 7 8 9 Отказ от прототипов Видыпрототипа Взвешенные решения Временный арт (но лучше с ним)
- 8. 1 2 3 4 5 6 7 8 9 Интеграция контента Единое дисковоепространство Политики именования Организация папок проекта Коллекции
- 9. 1 2 3 4 5 6 7 8 9 Система контроля версий Git,SVN, Perforce, Plastic SCM Git LFS Множество веток от develop-a Конфликты Мердж .uasset Мердж .umap
- 10. 1 2 3 4 5 6 7 8 9 Короткие циклы разработки TeamCity Dedicatedserver Development build vs Shipping build Torrent Вертикальная интеграция
- 11. 1 2 3 4 5 6 7 8 9 Подготовка билдов Ошибки вBP Локализация Сборка света (в продакшн) Иконки в таск баре
- 12. 1 2 3 4 5 6 7 8 9 Обновление версий движка Следить(читать длинные списки изменений) Ждать первых минорных версий перед полным переездом Не ждать роста разницы Писать плагины
- 13. 1 2 3 4 5 6 7 8 9 Обучать все отделыBP и прочему инструментарию Делать фичи законченными, каждая фича должна иметь осязаемый результат Почаще рефакторить проект, стараться переосмыслять новые изменения Не хранить исходники арта в системе контроля версий Плагины вместо модифицированных версий движка Выводы
- 14.
Editor's Notes
- #3 2 года назад мы запустили большой проект под кодовым названием Echo, это мультиплеерный класс басед шутер с упором на тактику про рыцарей-мехов. Был долгий предпродакшн, Проект находится в активной стадии примерно год. Мы готовим на май закрытый альфа тест.
- #4 HighNoon - это джемовский проект, которым команда занималась некороткое время с ноября по март этого года.
- #5 Максимальное использование движка на всех этапах разработки. канбана: виды все в одной доске и задачу делает ответственная миникомманда (проседает арт) Либо есть доски по отделам Важно чтобы всегда был стабильный и рабочий develop, потому что все остальное идет от него.
- #6 Мы разделяем нашу работу по компетенциям и ролям. Роль - это то, что определяет тебя в пайплайне, компетенция - то что сотрудник может улучшить в проекте. Роль может быть переходящей, интегрировать контент умеют практически все участники процесса, писать фичи умеют как дизайнеры так и скриптеры так и программисты, просто кто-то из участников делает это лучше, поэтому мы стараемся, чтобы фичу делал тот кто наиболее эффективно с ней справляется. С другой стороны, этот подход позволяет развиваться тем, кто не имеют компетенцию, а за счет того, что все находятся в опенспейсе, человек который хочет научится, лего получит помощь. Именно по этим причинам у нас нет острой необходимости менеджмента, так как какждый может взять на себя эту роль и помочь с производством. В ситуации, когда инициатива и возможность взять на себя дополнительные функции поощряется и невозброняется, это в сумме дает прирост в работоспособности и стрессоустойчивости коллектива, хотя мы и можем проседать, если кто-то обучается во время выполнения задачи. Вобщем это то к чему мы стремимся, понятно, что не всегда всё удачно получается. Однако при наеме это мотивирует нанимать разнонаправленно развитых людей, которым условно интересно множество сфер разраб
- #7 Задача должна быть понятна, любому случайному читателю (в идеале) и должна отвечать на вопрос (что сделать?) Все задачи дб законченным целым, поэтому задача не уходит программисту без минимального пака арта. Про тестирование Минимальный размер фичи Фича не может быть не ценной для игрока, от этого все идет: Фичи большие пласты работы В фичу закладывается рефакторниг Тестированние происходит параллельно Синхронизация с двелопом Песочница для песочницы для песочницы
- #8 Есть два вида прототипа: 1. Это фича написанная плохой код, который полностью или частично реализует некторую фичу 2. Это фича сделанная на временном арте или вообще без арта Мы стараемся придежриваться первого варианта и не делать проптотипы потому что: Механика может помочь на в будщем Если механика плохо реализуется, значит были совершены ошибка во время проектирования их всё равно нужно править Если делать прототип на костылях, нужно еще в потора больше времени, чтобы его причесать Экономия прототипа должна заключаться в кол-ве людей на нем задействованных, а не вкол-ве работы. И тем не менее иногда для реализации фичи нужно много арта, поэтому его отсутвие в большинстве случаев не может фатально повлиять на принятие решения оставлять протоип или не стоит.
- #9 Мы не заливаем FBXы и исходные файлы в систему контроля версий. Вместо этого используется сетевой диск. Один для интеграции (для того чтобы пути до исходного FBX файла всегда были одинаковы), другой для хранения исходников. Оба диска бэкапяться раз в три дня. Нет идеальной структуры папок, которая бы казалось идеальной для всех участников. Мы просто разделяем файлы сначала по типу, затем по специфике. Но я рекомендую использовать коллекции для своих нужд.
- #10 Git очень мощный иснтрумент для работы с множеством веток. Но не хватает лока файлов. Perforce нужно серьезно админить и настраивать. Git сильно разрастается и выедает очень много ресурсов на пользовательском PC. Упаковка и распаковка. Для того чтобы избежать этого лучше использовать Git LFS. SmartGit его поддерживает. Самое сложное -- это конфликты бинарных файлов. В случае с uasset-s все более менее ясно. Есть инструмент который показывает разницу. В последнее время он не глючит. С картами всё сложнее их придется лочить, что сильно осложняет разработку. Эпики обсуждают возможность создать сервер совместного редактирования бинарных файлов. Когда разработка в самом разгаре нужно завести ключ на карту и вести все изменения в одной ветке.
- #12 Если проект большой, нужно почаще собирать основную ветку в шиппинг, чтобы быть в курсе возможных проблем. Мы отстраивали автосборку, чтобы ускорить работу и собирать выделенный сервер в любой момент. Минорные ошибки в BP могут не пропустить сборку Shipping версии. Сигнатуры + изменения объектов у которого берутся дефолтные поля Для временных фичей лучше завести ноду IsShipping. Локализацию лучше готовить заранее использовать TEXT вместо String, инсутрементарий крутой. Иконка в таскбаре так и не пофикшена, так что лучше заранее сделать следющее:
- #13 Всё это хорошо работает, если писать плагины и не влезать в код. Держать максимальную развязанность кода и рефакторинг. Не ждать роста разницы с движком, потому что в будущем будет крутая фича, которая обязательно понадобиться, но её не будет. Для того чтобы не исправлять код движка лучше писать плагины. Так эффективнее их можно довести до релиза и продавать.