Организация разработки мода
Эта статья призвана помочь вам в создании модификации (сокращённо мод) для GoldSrc, Source и Source 2. Сначала мы разберём советы по запуску проекта и сбору команды. Затем пройдёмся по полезным рекомендациям, которые помогут определиться с геймдизайном вашего мода. В завершение вы получите пошаговое руководство о том, как подтянуть хвосты и довести мод до релиза — что является самой сложной частью разработки.
С чего начать
Давайте для начала разберёмся, как собрать команду. Главное правило здесь — она должна быть маленькой. Управление командой — это полноценная работа на весь день, даже если вся команда сидит в одном здании. Если же вы руководите онлайн-командой, вы запросто можете тратить всё своё время только на управление ею, а это значит, что времени на саму разработку мода у вас не останется. Расширение штата вовсе не означает, что работа пойдёт быстрее. Чем больше у вас людей, тем больше времени уходит на координацию их действий. Основная команда Team Fortress состояла всего из трёх человек. Основная команда Counter-Strike и вовсе из одного.
При поиске участников команды старайтесь привлекать только тех, без кого вы точно не сможете обойтись. Первым порывом может быть желание нанять любого, кто умеет программировать, моделировать или создавать уровни. Но для первой версии проекта вам, скорее всего, понадобится не больше одного человека на каждое направление (код, звук, модели и карты). Возможно, на старте вам вообще не пригодятся новые ресурсы. Не берите никого в команду, пока не увидите примеры их работ. Убедитесь, что они умеют доводить свои проекты до конца. Если перед вами моделлер, который сделал 20 моделей, но все они брошены наполовину — в вашей команде такому человеку делать нечего.
Геймдизайн мода
Самый важный вопрос, который вы как автор мода должны себе задать: «Зачем кому-то играть в мой мод?» Ответить на него честно бывает трудно, но если вы сможете, то вы на верном пути. Подумайте о существующих модах и о том, что они предлагают. Даёт ли ваш проект игрокам что-то новое? Достаточно ли сильна ваша главная фишка, чтобы переманить игроков, которые и так заняты другими модами? Даже если вы не можете ответить на этот вопрос прямо сейчас, сами размышления о нём пойдут вашему проекту на пользу.
Ваше оружие — геймплей
У вас есть суперсила, которой лишены коммерческие разработчики: вам не нужно беспокоиться о рыночной окупаемости новых игровых стилей. Крупные студии обязаны думать о розничных продажах, выходе в безубыточность и прочих финансовых ограничениях — именно поэтому большинство игр представляют собой лишь слегка изменённые версии уже проверенного геймплея. Но вы от этого свободны. Вы можете пробовать по-настоящему новые геймплейные идеи, которые вполне могут стать следующим громким хитом. Это ваше главное преимущество перед коммерческими разработчиками. Облегчите себе жизнь, сделав упор именно на это преимущество, и не тратьте время на попытки конкурировать в тех сферах, где сильны коммерческие продукты. Большинство модов просто не способны тягаться с профессиональными играми на уровне контента (карт, моделей, звуков и т. д.) — у студий есть штаты художников с годами опыта за плечами. Сделайте геймплей своим главным козырем. Люди будут играть в мод, где почти нет нового контента, если сам игровой процесс чертовски увлекателен. К примеру, у оригинальной Team Fortress вообще не было своего собственного контента в течение целого года после первоначального релиза.
Выпускайте скорее, выпускайте чаще!
Вы имеете огромное преимущество над коммерческими разработчиками. Вы можете выпускать обновления гораздо чаще, быстрее и больше, чем они. Мы совместили эту философию разработки модификации в одну фразу — «Выпускайте скорее, выпускайте чаще!». Коммерческие разработчики работают 2–3 года, чтобы выпустить их игру, и надеются на бога, чтобы людям она понравилась. Однако вы можете разработать идею модификации, сделать 25% от всего, затем предоставить результат игровому сообществу, и они сразу же свяжутся с вами. После этого вы можете добавлять остальной контент по частям, в это же время получая мнения о первой версии, и продолжать выпускать новые версии каждые один–два месяца. Вы всегда находитесь на связи с игроками, так что вы не попадёте в ситуацию, когда вы потратили много времени на то, что игрокам может не понравится. Весь фокус в том, чтобы уменьшить количество недочётов в финальной версии. Первоначальная версия должна быть весёлой и играбельной, но не содержащей попытки реализовать все придуманные вами особенности.
Будьте осторожны: «Быстрый выпуск» не означает, что вы должны выпускать некачественные версии, нужно делать небольшие, но качественные изменения. Первая версия 
Counter-Strike не имела и половину от того, что она имеет сейчас. Команда Counter-Strike делала высококачественные, но небольшие модификации. В последний год они добавляли всё больше особенностей, и в ответ на это, всё больше игроков становились их фанатами.
Другой — не обязательно лучший
Когда вы думаете над игровым дизайном, не попадитесь в ловушку, полагая, что «Различия — это хорошо». Нет смысла переделывать код и модель дробовика, если он не влияет на общую концепцию вашей игры. Всегда держите в памяти вопрос: «Почему кто-либо должен играть в мою игру?». Ответ: «В моём моде есть новая боевая система и новая система передвижения» — не всегда является лучшим. Ваша боевая система отлична от 
Half-Life? Хорошо… но она лучше? Сделает ли она вашу игру более интересной? Сделает ли новая система передвижений вашу игру более весёлой? Игрок использует уже существующие системы, и делая что-то новое, изучите, что игроку будет полезно. Поэтому, прежде чем изменять что-либо, убедитесь, что изменения приведут к лучшему результату, и сделают вашу игру более весёлой. Не бойтесь оставлять всё то же самое, что было в Half-Life.
Реальные цели
Создавайте для себя реалистичные цели. Подумайте о том, сколько занимает коммерческая разработка Шутер от первого лица с 10 пушками. Если ваш мод будет иметь 40 единиц оружия, вы действительно усложните себе жизнь. Всегда помните, что «Качество превосходит над количеством». Игроки предпочитают иметь 10 уникальных, сбалансированных и весёлых, чем 40 не сбалансированных единиц оружия, некоторые из которых чуть лучше других.
Не бойтесь вырезать контент и особенности. Если мод выглядит не законченным, или какой-либо контент не соответствует качеству остального контента — начните вырезать. В ходе разработки Half-Life около 30% из оригинальной идеи были вырезаны, потому что их было невозможно закончить в сроки. Как мы уже говорили, «Качество превосходит над количеством». Игроки предпочитают играть в 3 действительно хороших, протестированных карты, чем в 10 плохо разработанных. Это даст вашей модификации репутацию качественной модификации. Не позвольте миру увидеть ваши худшие разработки.
Понимание движка
Вам действительно стоит прочитать документацию, включённую в SDK. Вы должны не просто понимать как делаются вещи в движке, но и как сделать их правильно. Вы можете сделать оружие, стреляющее 50 ракетами, но если вы не понимаете, как работает движок, то можете сделать это так, что мод будет использовать большое количество сетевого трафика. Это важно для каждой модификации. Если создатели карт не понимают движок, они будут делать огромные карты, не задумываясь о том, сколько данных будет посылаться пользователям, играющим в неё, и каждый будет винить ваш мод за слишком интенсивное использование сети. Если вы программист, хорошей идеей будет присоединиться к рассылке списка Half-Life программистов, где вы сможете поговорить с многими другими программистами, а так же с некоторыми сотрудниками Valve. Рассылка списка имеет большие архивы, в которых содержится много полезных решений общих проблем.
Завершение
Мы видим много сильных модов, содержащих большие объёмы потрясающего контента, но так и не попавших в руки игрокам. Этот раздел поможет вам начать подготовку к выпуску финальной версии вашей модификации.
Мы выбрали пять недель в качестве точки старта, этого времени достаточно, чтобы перейти от режима разработки к выпуску модификации. Вполне возможно у вас будет получаться лучше и быстрее с новыми версиями. Если ваш мод масштабный, или если ваша команда из разных стран, то вероятно, потребуется больше пяти недель, хотя шаги будут похожи на следующие. Если это возможно, попробуйте уговорить команду работать над проектом ежедневно в течение пяти часов в этот период. Если некоторые из членов команды не способы на это, лучше будет исключить их из процесса подготовки к выпуску. Пусть они передадут свои наработки другим членам команды, кто сможет вложить необходимые усилия. Подготовить продукт, даже маленький продукт — очень сложно и требует некоторых обязательств.
В этом разделе есть много вещей, которые могут показаться резкими или жестокими. Это печально, но это отражает сложность процесса. Здесь представлен опыт, сформированный из уроков, полученных нами в процессе подготовки к выпуску многих продуктов, большинство из которых являлись результатом болезненных ошибок, срывавших даты выхода. Вас может удивить, но действительно важно следовать определённому совету — вполне возможно, что мы были вынуждены отодвигать наши даты выхода на недели только потому, что мы не воспользовались ими.
Это связано так же с тем, что потенциальные работодатели так же чрезвычайно заинтересованы в скором выходе. Одно дело, видеть как создатель модификации сделал кучу интересных вещей, и другое дело — видеть как было сделано несколько интересных вещей и люди играли именно в это. Самые классные карты, модели, код, звуки и т. д. бесполезны, если вы не можете доделать их в последний момент.
Не бойтесь, становится гораздо проще, когда Вы прошли через это несколько раз. На момент третьй или четвёртой модификации Вы станете экспертом!
Пять недель до релиза
Централизуйте управление
Вы должны назначить одного члена вашей команды как Shipping Leader (SL). Этот человек будет управлять процессом разработки на протяжении следующих пяти недель. Все изменения, вносимые в мод должны будут производиться только по просьбе SL, а так же все запросы изменения направляются на этого человека. Ни один человек из команды не должен самостоятельно изменять что-либо, не зависимо от того, насколько значительно изменение в моде, только если это не является просьбой SL. Это не означает, что остальная часть команды теряет контроль над процессом разработки, так как SL это всё ещё часть команды, и он должен выслушивать все отзывы. Назначение SL — сделать так, чтобы все изменения проходили через одного человека. Это позволит избежать таких проблем, как сделанное создателем карт в последнюю минуту изменение, повлёкшее за собой неработоспособность какого-то участка кода. SL будет знать состояние каждого компонента игры (код, карты, модели, текстуры, и т. д.) на протяжении всех 5 недель, чтобы ничего не случилось.
Выбор SL не лёгок. Вот несколько советов:
- Не надо сразу полагаться на человека, который в настоящий момент работает над модом, особенно если работа над модом велась несколько месяцев, и он ни насколько не приблизился к релизу.
- Программисты, возможно, являются лучшим выбором. Когда подготовка к релизу подходит к концу, большинство изменений делается именно в игровом коде.
- SL должен быть высоко мотивированным, дисциплинированным и организованным насколько это возможно. SL должен отдать проекту свои пять недель жизни.
- SL должен быть способным принимать глобальные решения касательно модификации. SL должен понимать, что часто требуется вырезать особенности и контент модификации, чтобы успеть к дате выхода.
Установите последовательность разработки
Вам необходимо создать последовательность разработки модификации. Разработка представляет собой принятие всех работ и делает устанавливаемую, рабочую версию модификации (как правило, в виде установочного файла). Это должен делать только SL на протяжении следующих пяти недель, и SL должен действовать по строгой последовательности действий, которых он всегда придерживается. Создание последовательности действий позволяет не тратить часы на исправление ошибок, являющихся результатом действий, отличных от действий другого человека.
SL должен постоянно поддерживать финальную или предварительную версию модификации. Все изменения должны отправляться к нему, и он должен включать их в свою копию модификации с полным пониманием влияния этих изменений на остальные части модификации. Не забывайте постоянно делать резервные копии!
SL должен ежедневно делать работоспособную версию модификации для игрового тестирования. Подробнее об этом позже.
Замораживание особенностей
Подготовка к выходу — это процесс замораживания недоделанных частей вашей модификации. «Замораживание» означает, что недоделанные части не трогаются вообще. Ошибки найденные в замороженных частях требуют тщательной обработки. Если ошибка действительно важная (устойчиво воспроизводящаяся), просто подметьте её и исправьте в следующем обновлении вашей модификации. Независимо от соблазна «лёгкого исправления», размораживание частей вашей модификации необходимо избегать насколько это возможно.
К моменту выпуска, за пять недель, вы так же должны заморозить особенности модификации. Это означает, что вы не должны их изменять. Если часть вашей команды не хочет принимать участие в выпуске, но хочет продолжить работу по разработке модификации, они должны работать с отдельной копией контента и базой программного кода. Бо́льшая часть пакетов для контроля кода позволяет ветвление кода на этот случай (мы крайне рекомендуем вам использовать что-нибудь для контроля исходного кода). Каждые изменения сделанные в моде отныне должны только исправлять ошибки. За этим должен следить SL. Даже если программист придумал какую-либо классную возможность, думая, что она делается всего за 10 минут, не позволяйте ему добавлять её. Даже если программист отправляет код, законченный и проверенный на отсутствие ошибок, не вставляйте его в мод. Оставьте до следующей версии.
Для SL разумно придерживаться позиции, что любое изменение в моде с момента начала процесса выпуска добавляет два дня к дате выпуска.
Игровое тестирование
С этого момента, вы должны проводить игровое тестирование каждый день, или каждый второй день, если изменения незначительные. Игровое тестирование основывается на установочной версии игры, создаваемой SL. Не позволяйте членам команды играть в свои версии игры. Каждый должен запускать версию модификации, созданную SL (это то, что будет предоставлено публике во время установки и использования, вот что означает тестирование). Вы будете тратить много времени на поиск ошибок, связанных с несовместимостью версий, если не сделаете этого.
Чтобы облегчить эту задачу, мод должен поддерживаться в играбельном состоянии всё время. Очень, очень сильно переживайте за каждый день, в который мод стал не играбельным. Если программист или создатель карт сделал изменение, которое портит мод, хорошо подумайте, прежде чем включать изменения в SL сборку. Как долго игра будет неиграбельна? Сколько игровых тестов вы пропустите? Сколько членов команды не смогут работать, потому что мод не запускается? Не нарушаемая разработка должна стать религией для команды.
Когда вы начинаете игровое тестирование, убедитесь, что максимальное количество членов вашей команды может провести тестирование вместе с вами. Каждый работающий над игрой должен регулярно в неё играть. Так же убедитесь, что у вас есть внешние тестеры. Включите журнал сервера (установите «log» на «on» в файле server.cfg). Вся исходящая информация сервера будет записываться в файл по пути «Папка игры\logs» (имя файла будет совпадать с датой). Всякий раз, когда игрок замечает ошибку, пусть он использует кнопку «Сказать» чтобы сказать «ОШИБКА: описание бага». Затем, когда игра закончится, вы можете открыть log файл и посмотреть все сообщения о багах, использовав поиск по слову «ОШИБКА:».
Ошибки и изменения
SL должен вести полный список ошибок и изменений, и их текущее состояние. Предпочтительно, чтобы это делалось с помощью настоящей базы данных. Электронная почта является совершенно не допустимой для отслеживания ошибок; слишком просто переместить новое сообщение с первой страницы пользователя и т. д. SL должен после каждого игрового тестирования добавлять в список ошибки и необходимые изменения из log файлов, и сообщать о них членам команды. Когда член команды исправил ошибку или сделал изменение, он должен послать новый контент SL, который должен убедиться, что ошибка исправлена и изменить её статус в списке ошибок.
Список ошибок это фантастический инструмент позволяющий отслеживать ваш прогресс. Он может быть использован для определения, кто загружен работой, кто ничем не занят, кто не исправил свои ошибки, как далеко ваш мод от завершения и т. д. Не удаляйте ничего из списка ошибок, даже когда ошибка была исправлена (её следует помечать как исправленную). Это очень полезно, чтобы отслеживать список всех ошибок которые были исправлены на протяжении всей истории проекта. Что-то может регрессировать, пересоздав ошибку, и зная, кто исправил ошибку в прошлый раз, можно узнать у него причины появления ошибки. В конце проекта, вы должны видеть все исправленные ошибки и каждое изменение сделанное в вашем моде в течении периода подготовки к выпуску. SL не должен включать в свою копию любое изменение модификации, если оно не описано в списке ошибок.
Существует программное обеспечение, помогающее в создании и ведении списка ошибок. Кроме того, обычная таблица будет прекрасно работать. Опять же, электронная почта является плохим выбором.
Вырезание или откладывание особенностей
Самая трудная, скверная, и к сожалению, наиболее необходимая часть подготовки к выпуску — быть реалистом, и вырезать не готовые части. Мы в Valve шутим, что у каждого есть своя любимая особенность игры, которая в конечном счёте была вырезана. Это помогает каждому подготовить себя к тому, что их особенности, которые они хотели видеть в игре (или на которые они потратили много времени), могут быть вырезаны. Ваша игра просто не может содержать все классные особенности и выпуститься в разумные сроки. SL должен принимать решение о том, что необходимо вырезать, основываясь на том, как далеко вы зашли в процессе создания и как далеко до даты выпуска.
Чем ближе к выпуску, тем больше вы должны думать над каждой обнаруженной ошибкой. Является ли это ошибкой в особенности, которая обязательно должна входить в игру? Сколько дней понадобится, чтобы исправить эту особенность? Можно ли вырезать эту особенность, или её можно отложить до более поздней версии?
Семь раз отмерь, один раз отрежь
Как мы уже говорили снова и снова, процесс подготовки сложный, и он становится ещё сложнее, если вы неправильно управляете приоритетами разработки. Долгая работа никогда не заменит внимательного выбора того, что необходимо исправить, что отложить, а что вырезать вообще. SL должен быть очень осторожен при выборе над какими ошибками и изменениями надо работать, и кому. Не тратьте неделю на исправление небольшой проблемы в функции просто потому, что она классная. Исправьте ошибки которые заставляют игру вылетать. Исправьте ошибки, мешающие подготовке к выпуску. Исправьте ошибки, мешающие другим членам команды исправлять свои ошибки. SL должен разработать категории ошибок для принятия правильных решений. Хорошее разбиение ошибок по уровням важности:
- Должно быть исправлено
- Тяжёлые
- Средние
- Незначительные
- Нулевые
- Отложенные
Так как проект становится ближе к выпуску, SL должен тщательно оценивать каждую появляющуюся ошибку. Помните, что каждая исправленная ошибка ведёт за собой больше игровых тестов и обычно — к новым и новым ошибкам. Если у вас осталось две недели до релиза, а у вас ошибка, требующая для исправления трёх дней работы и 500 строк кода, вы точно не успеете до релиза, если не вырежете или не отложите этот фрагмент игры до следующей версии.
Три недели до релиза
Заморозка контента
К этому моменту нужно стремиться к завершённости контента. Это означает, что весь контент игры, кроме игрового кода, должен быть заморожен. Все карты, модели, текстуры, звуки, HUD арт, Launcher арт и т. д. должны быть завершены и находится в копии игры у SL.
Прекращение работ
Это уже подчёркивалось на отметке за пять недель до релиза, но сейчас это ещё важнее. SL должен быть единственным человеком, которому разрешено изменять мастер-копию игры, и он должен просто встраивать исправления ошибок от программистов, которые должны исправлять ошибки полученные только от него.
Игровое тестирование
Игровое тестирование модификации должно проводится каждый день, по крайней мере в течении двух часов. С этого момента и до самого выхода вам нужно как можно больше людей, которые занимаются вашим модом. Слишком поздно вносить какие-либо крупные изменения игрового дизайна — даже не надейтесь.
Одна неделя до релиза
Никаких исправлений в последнюю минуту
SL должен оценивать каждое изменение, которое должно быть сделано, или же они должны быть отложены до следующих версий. Опять же, здравый подход — считать, что любое изменение, даже одна строка кода, добавит два дня к дате релиза.
Безопасный двухдневный промежуток
Когда все запланированные ошибки исправлены, а всё остальное было отложено, это ещё не конец. Теперь подождите 48 часов, в течении которых вы должны проводить игровые тестирования как сумасшедшие. Постарайтесь, чтобы все играли в игру столько времени, сколько могут. Если нашли ещё ошибки, которые могут быть исправлены, исправьте их, и начните 48-часовой процесс снова.
Если в течении 48-часового игрового тестирования не было найдено никаких новых ошибок, вы готовы к релизу!
Пост-релиз
И так, мод вышел, игрокам он очень нравится, а на сайтах пишут, как увлекательно в него играть. Закончена ли ваша работа — решать вам. Из нашего опыта в области онлайн-игр, мод остаётся популярным, пока вы его поддерживаете. Не важно, насколько хорош ваш мод, он не соберёт какого-то заметного числа игроков в первой версии. Количество игроков будет увеличиваться посредством выпуска нового контента, исправления ошибок, и, конечно, поддерживаемого сообщества. Counter-Strike и 
Team Fortress Classic начали с самого малого и росли каждый день. С каждой новой версией всё больше игроков начинали в них играть.
Знание что исправлять, что изменить, и как прислушиваться к сообществу приходит с опытом, в процессе продолжительного самообучения.
Удачи!