Коллективная работа над проектами
Автор: Андрей Эдуардович Яроменок
RCS in gamedev
it's just a test of RSS. no tags/out-of-date for now
Организация работы с данными в компании-разработчике компьютерных игр.
1. Введение
2. Система контроля версий
2.1. Общие положения.
2.2. Типы RCS.
2.3. Распределение по типам данных.
3. SVN (SubVersion).
3.1. SVN (SubVersion)
3.2. Детали реализации SVN.
4. Пример реализации.
5. Требования к культуре работы.
6. Выводы.
7. Ссылки.
Приложения
A. иллюстрации
Б. cоглашение об именовании
1. Введение
Организация работы с данными является важной составляющей конечного успеха отдельно взятого проекта и компании в целом. Специфическим для направления разработки игр следует признать наличие нескольких типов данных, включающих в себя как текстовые файлы, так и графические (как растровые, так и векторные) файлы, а также разный уровень общей компьютерной грамотности сотрудников. Также немаловажным является сохранность данных, не очень высокая изначально ввиду постоянной экономии на качественном оборудовании для работы.
2. Система контроля версий
(Revision Control System)
2.1. Общие положения.
Система контроля версий (здесь и далее для краткости – RCS – revision control system) файлов является неотъемлемым атрибутом работы с данными на компьютере в течение длительного времени. В течении этого времени шло постоянно усовершенствование программ, обеспечивающих выполение этих функций.
Исторически их можно разделить на два типа:
- системы контроля версий, используемые для написания ПО(cvs, sourcesafe, svn)
- системы контроля версий офисных документов, реализованные неявно через Groupwise ПО (Plato, Lotus Notes).
В пределах этой статьи в основном рассматриваеться первая группа, хотя в обзоре аналогичных решений включён и Lotus Notes.
Существует типичное заблуждение, выражающееся в том, что RCS необходима только программистам. И хотя это заблуждение имеет под собой исторические(сложность эффективной реализации работы с бинарными данными, к которым в большинстве своём принадлежат графические файлы) и психологические (творческие натуры дизайнеров не терпят порядка) корни, его необходимо искоренить для организации эффективной работы.
Итак, что же собственно даёт применение системы контроля версий:
возможность исправить сделанные ошибки, использовав предыдущую версию(«откат»);
возможность наблюдать динамику изменений и их соответствие планам;
возможность работать нескольким членам команды одновременно и синхронизированно;
избыточная сохранность файлов с данными.
Остановимся на каждом пункте конкретно, применителько к контексту игроделания.
2.1.1. Возможность исправить сделанные ошибки, использовав предыдущую версию (так называемый «откат»), является очень важным в предверии критических по срокам сдач проетов, как промежуточных, так и финальных. Наврное многим встречались ситуции, когда код и графический контент, сделанный в последний день-два-три, имеет явные огрехи из-за недостатка времени и усталости, и уже никто не пониит, что было точно модифицировано. Безболезненный откат на предыдующую версию спасёт от 100% взбучки со стороны начальства/издателя. (за пределами этой статьи останется моё мнение о среднем менеджере проекта в постосоветском игроделании, доводящем до таких критических ситуаций)ю.
2.1.2. Возможность наблюдать динамику изменений и их соответствие планам важны как менеджерам, так и коллегам по работе. Если первые лишь проверюят соответсвие человека получаемому им уровню зарплаты, то вторые, имея тесную завязку на задачи друг друга, и получая текущие изменения данных по почте, могут не дёргать друг дурга постоянными окликами – актуально как для компаний, не запрещающих своим сотрудникам использовать наушники в рабочее время, так и просто крупным компаниям, имеющим 2 и более помещения для работающих(особенно, при работе, требующей взаимодействия программистов и художников).
2.1.3. Возможность работать нескольким членам команды одновременно и синхронизировать свои труды. Если для программистов это само сабой разумеещеся на уровне исходных кодов, то для дизайнеров, работающих, например, с общими текстурами это единственный способ уберечься от пложения ненужных копий.
2.1.4. Избыточная сохранность файлов с данными обеспечивается храниением на каждом компьютере практически полной копии данных касательно его части проекта. Таким образом, получается (минимум) по 2-3 компьютера с данными текущего дня + сервер. Такой стебильности может не обеспечить и RAID0 массив, особенно в условиях эконоимии на них :-).
2.2. Типы RCS.
Сушествует два типа RCS - Lock-Modify-Unlock (LMU - Заблокировать-Модифицировать-Разблокировать) и Copy-Modify-Merge (CMM - Скопировать-Модифицировать-Объеденить).
к LMU относятся SourceSafe, SVN 1.2 with optional locking (reserved checkouts)
кCMM относяться CVS, SVN (классический)
2.3. Распределение по типам данных.
Оптимальным является использование обоих типов RCS для данных, используемых в игровой индустрии, а именно:
1) для текстовых файлов, таких как исходных кодов программ, скриптов: 1)
2) для бинарных файлов, таких как 3D сцены и растровые изображения - 2).
Файлы, относящиеся к документации проекта, а также некоторые форматы 2D/3D графики могут быть одинаково эффективно использованы с обоими типами RCS в силу возможности сохранения как в бинарной, так и в текстовой форме(Maya Binary/Maya ASCII, RTF/txt).
Единственным пакетом, предоставляющим одновременно возможность работать с обоими типами RCS – это SubVersion (или SVN, как он и будет упоминаться в дальнейшем – для краткости).
3. SVN (SubVersion).
3.1. SVN (SubVersion)
одна из наиболее новых систем контроля версий, созданная с учётом опыта предыдущих систем и идущая на замену широко используемому сейчас CVS, а начиная с версии 1.2 и SourceSafe.
Основными отличиями SVN являются:
- продуманная архитектура;
- общий номер ревизии для репозитория;
- реализация обоих стандартов RCS;
Более подробно по пунктам:
1) При проектировании системы был учтён многолетний опыт работы с CVS, реализованна небывалая гибкость в работе, например, как использование протокола TCP (c Apache), работа по своему собственному протоколу SVN и возможность локального расположения репозитория(может быть очень полезна freelancer'рам-одиночкам)
2) Номер ревизии теперь общий для всех фалов в репозитории, что даёт возможность выбрать все данные на какой-то момент времени. Очень важно в критических по времени ситуациях(перед meelstone).
3) Начиная с версии 1.2, SVN реализует оба стандарта RCS, что позволяет его использовать и для бинарных, и для текстовых файлов в пределах проекта. Также может быть использованно программистами, привыкшими к SourceSafe.
SVN поддерживается на многих платформах, таких как MS Windows, Linux, MacOS X, Solaris, и прочих, как для клиента, так и для сервера. Реализация состоит из командно-строчнох утилит и front-end в виде интеграции SVN в MS Windows Explorer, MS Visual Studio, Eclipse, KDevelop и других.
Общая структура SVN представлена на рисунке №Х
3.2. Детали реализации SVN.
Данная информация носит лишь ознакомительную цель – за более подробной информацией обратитесь к официальным руководствам, ссылки на которые приводяться в конце статьи.
3.2.1. Сервер SVN разработан в тесной интеграции с HTTP сервером Apache(Apache2), использует часть его низкоуровневых интерфейсов, но сохраняет возможность отдельной от него работы.
В качестве репозитория могут быть использованы:
- база данных berkleyDB;
- файловая система(в том числе и локальная – вариант, интересный для начинающих занкомиться с RCS).
В качестве протокола обмена могут быть использованы:
- HTTP протокол (только совместно с Apache);
- SVN протокол;
- file протокол для локальных данных.
4. Пример реализации.
1) репозиторий для исходных кодов(C/C++, Cg/HLSL/GLSL, LUA/Pyton).
2) репозиторий для бинарных сборок исходных кодов (движок, редакторы, утилиты).
3) репозиторий для исходных текстур (TGA, TIFF, EXR)
4) репозиторий для 3D файлов (Max/Maya/XSI/LW);
5) репозиторий для документации (Word/Project/html)
6) репозиторий для сборки уровня(ей) игры (level1, level2)
[схема репозитория]
Из специфического оборудования, необходимого для реализации можно отметить лишь желательное наличие сети со скоростью передачи в 1Гб/с и увеличенное количество оперативной памяти на серверах RCS (по сравнению с таковым для RCS для исходных кодов программ) в связи возросшими объёмами данных.
Типичным для рабочих станций под ОС Windows является использование GUI клиента к Windows Explorer [TortoiseSVN], а также клиента к Visual Studio.
Наличие коммандно-строчный реализации SVN (а также открытые исходные кода) позволяет написать клиент для любого ПО (с соответвующей лицензией распространения), использованного в делопроизводстве. В качестве примера прилагается MEL скрипт для интеграции в Alias Maya [детали установки].
5. Требования к культуре работы.
При совместной работе требования к культуре работы многократно повышаются. Если для программистов умение владением одной из RCS является типичным (в т.ч. является вопросом на собеседовании :-) ), то для очень многих дизайнеров это будет их превый опыт работы с RCS. Естественно, в начале внедрения таковой системы на уровне проекта возникают сложности взаимодействия(люди по привычке перекидывают файлы по сети в обход RCS, устно уведомляют об изменения, забывают обновить файлы и т.д.), что создаёт дополнительную нагрузку на лицо, ответсвенное за внедрение RCS (одним из решенний является закрепление "шефства" программистов над художниками).
Внедрение соглашения об именовании на комментарии к RCS поможет команде (и, особенно, её руковдителю) лучше остлеживать ход выполения проекта.
Пример такого соглашения можно найти в приложении Б.
4 ноября 2005 (Обновление: 2 мая 2006)