Difference between revisions of "Making a Mod:ru"

From Valve Developer Community
Jump to: navigation, search
(Various corrections again. It's still not completed. :))
(Замораживание фич)
Line 63: Line 63:
 
К этому моменту shipping'а, за пять недель до выпуска мода, вам нужно также заморозить фичи. это означает, что вам не следует добавлять никаких новых фич в ваш мод, вообще никаких. Есть часть вашей команды не занимается шиппингом, но хочет продолжать работать над модом, то этим члены команды должны работать с отдельной копией контента и базой программного кода. Большая часть пакетов для контроля кода позволяет ветвление кода на этот случай (Да, мы крайне рекомендуем вам использовать что-нибудь для контроля исходного кода). Любое изенение в моде с этого момента должно быть исправлением бага. За этим должен следить SL. Даже если кодер придумает еще одну замечательную фичу, которая, по его словам, займет каких-то 10 минут на программирование, не позволяйте ему добавлять ее. Даже если кодер отправляет код, законченный и проверенный на отсутствие ошибок, не вставляйте его в мод. Оставьте до следующей версии
 
К этому моменту shipping'а, за пять недель до выпуска мода, вам нужно также заморозить фичи. это означает, что вам не следует добавлять никаких новых фич в ваш мод, вообще никаких. Есть часть вашей команды не занимается шиппингом, но хочет продолжать работать над модом, то этим члены команды должны работать с отдельной копией контента и базой программного кода. Большая часть пакетов для контроля кода позволяет ветвление кода на этот случай (Да, мы крайне рекомендуем вам использовать что-нибудь для контроля исходного кода). Любое изенение в моде с этого момента должно быть исправлением бага. За этим должен следить SL. Даже если кодер придумает еще одну замечательную фичу, которая, по его словам, займет каких-то 10 минут на программирование, не позволяйте ему добавлять ее. Даже если кодер отправляет код, законченный и проверенный на отсутствие ошибок, не вставляйте его в мод. Оставьте до следующей версии
  
Для SL разумно придерживаться позиции, что любое изменение в моде с момента начала шиппинга добавит два для к дате выпуска.
+
Для SL разумно придерживаться позиции, что любое изменение в моде с момента начала шиппинга добавит два дня к дате выпуска.
  
 
=== Плейтесты ===
 
=== Плейтесты ===

Revision as of 11:12, 27 September 2008


Эта статья содержит большое количество советов, которые помогут вам в создании собственной модификации на движке Source Engine, или мода. Первая часть содержит советы по набору команды и началу работ. Во второй части собраны полезные рекомендации, касающиеся игрового дизайна. Наконец, последняя часть содержит пошаговое руководство, которое поможет вам заткнуть все дыры и выпустить ваш мод (как правило, это самая сложная часть разработки).

Старт

Итак, первое, что вы должны сделать - собрать команду. Помните, что управление командой отнимает очень много времени, даже если вы все работаете в одном здании. Если же вы работаете с онлайновой командой, то это будет отнимать практически все ваше время, а это значит, что на непосредственную работу над модом у вас времени практически не останется. Причем, чем больше людей будет в команде, тем гарантированно больше головной боли будет у вас, но это вовсе не значит, что работа будет продвигаться быстрее. Основной костяк команды, создавшей Team Fortress состоял всего из трех человек. Counter-Strike и вовсе разрабатывался одним человеком.

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

Дизайн мода

Самый главный вопрос, на который вы, как автор мода, должны ответить: "Почему кто-то должен тратить свое время на мой мод?". Трудно дать честный ответ на этот вопрос, но если вы смогли на него ответить - вы на верном пути! Подумайте, что в вашем моде есть такого, чего нет в других модах. Что может привлечь в вашем моде игрока, занятого игрой в другие моды? Даже если вы не можете пока ответить на этот вопрос, просто держите его в голове и почаще о нем вспоминайте - это пойдет на пользу вашему моду.

Ваше оружие - геймплей

У вас есть преимущество, которого лишены коммерческие разработчики: вы можете безбоязненно экспериментировать с новыми видами геймплея. Коммерческим разработчикам нужно заботиться об окупаемости своего продукта, ввиду чего они не рискуют предлагать в своих играх оригинальный, не виданый ранее геймплей. Именно поэтому, большинство выходящих новых игр представляют из себя незначительные вариации на тему проверенного годами геймплея. Но вы не скованы подобным образом! Вы можете смело экспериментировать с игровым процессом, находя к нему принципиально новый подход, что может даже стать очередным прорывом в игровой индустрии. В этом ваше преимущество перед коммерческими разработчиками. Упростите себе жизнь, сосредоточившись на нем, и не тратьте попусту время, стараясь пролезть в нишу, прочно занятую большими компаниями. Большинство модов не может конкурировать по качеству контента (карты, модели, звук и т.д.) с коммерческими играми, сделанными профессиональными командами художников и моделлеров, имеющими большой опыт в своей работе. Конкурируйте с ними с помощью геймплея. Игроки с радостью будут играть в мод, не отличающийся богатством нового контента, но отличающегося оригинальным, интересным процессом игры. Не многие знают, что в течение года после первого релиза, Team Fortress практически не содержал нового контента.

Release soon, release often

У вас есть еще одно преимущество перед коммерческими разработчиками: вы можете делать многократные и частые релизы вашего проекта. Эту философию можно выразить фразой: "Release soon, release often" (дословный перевод: "Выпускайте скорее, выпускайте много раз"). Коммерческие разработчики работают в течение нескольких лет, выпускают игру и скрещивают пальцы в надежде, что их творение понравится игрокам. Вам идти на такой риск совершенно необязательно. Вы можете реализовать в вашем моде 25% от запланированых фич, довести мод до играбельного состояния и выпустить, сразу же начав получать отзывы и критику игроков. Затем вы можете постепенно реализовывать в вашем моде оставшиеся фичи, выпуская новые версии раз в месяц или два. Вы всегда находитесь в контакте со своими игроками, таким образом вы никогда не окажитесь в ситуации, когда вы потратили кучу времини на что-то, что неизвестно, понравится игрокам или нет.

Не поймите неправильно! "Выпускайте скорее" не означает, что нужно выпустить недоделанный и некачественный мод. Это означает, что создание мода должно продвигаться маленькими, выверенными шагами. Первая версия Counter-Strike не включала в себя и половины фич, которые есть в этом моде сейчас. Команда CS выпустила высококачественный, но не слишком большой мод. В течение последующего времени, они выпускали новые версии мода, добавляя туда новые и новые фичи, что только увеличивало количество их игроков.

Другой - не обязательно значит лучший

Во время разработки мода, не попадитесь в ловушку, начав думать, что другой - значит лучший. Нет причины заменять модель дробовика и переписывать его код, если это не сделает вашу игру интереснее. Всегда помните самый главный вопрос: "Почему кто-то должен тратить свое время на мой мод?" Ответ вроде: "В моем моде новая система движения и боя" не всегда хорош. Хорошо, система боя в вашем моде отличается от системы боя оригинального Half-Life... Но лучше ли она? Это делает геймплей более привлекательным? Новая система движения делает игру в ваш мод интереснее? Помните, что игроки привыкли к традиционной для Half-Life системе движения и боя, поэтому переучивание должно быть оправданно для них. Поэтому, перед тем, как изменять что-либо, убедитесь, что вы меняете это в лучшую сторону, и что это пойдет на пользу вашему моду. Не будет ничего страшного, если вы оставите эту часть такой, как в оригинальном Half-Life.

Не количество, а качество

Подумайте, сколько времени занимает у коммерческих разработчиков создание FPS с 10 видами оружия. Если вы будете делатье мод с 40 видами оружия - вы сильно усложните себе жизнь. Помните правило: "Не количество, а качество". Игроки с скорее предпочтут 10 уникальных, хорошо сбалансированных видов оружия, чем 40 несбалансированных стволов, некоторые из которых являются слегка переработанными версиями других.

Не бойтесь вырезать контент и фичи. Если разработка мода затягиваетсяен, или если что-то не отвечает высоким требованиям качества вашего мода - смело вырезайте это! В процессе разработки Half-Life, по меньшей мере 30% того, что было задумано первоначально, было вырезано из игры, потому что стало очевидно, что нам не сделать этого в реальные сроки, или же потому, что мы посчитали, что эти вещи не стоят того. Как уже было сказано: "Не количество, а качество". Игроки предпочтут увидеть в вашем моде 3 действительно хороших карты и хорошо протестировать их, чем засунуть 10 сделаных на скорую руку, совершенно не протестированных карт.

Изучайте принципы работы движка

Мы настоятельно рекомендуем вам прочитать документацию, включенную в SDK. Вы должны не просто понимать, как заставить движок сделать что-либо, но и наилучший способ реализации этого. Вы можете сделать оружие, выпускающую 50 ракет одновременно, но если если вы не понимаете, как работает движок, то можете сделать ее таким образом, что у пользователей вашего мода заметно возрастет сетевой траффик. Знание движка необходимо не только кодерам. Если ваши левелдизайнеры не будут понимать принципов работы движка, они могут сделать огромные карты, совершенно не задумываясь о том, как это повлияет на траффик. А потом все игроки будут ругать ваш код за то, что он пересылает огромное количество данных по сети. Если вы программист, мы рекомендуем вам подписаться на рассылку HL Coders, где вы сможете пообщаться с программистами других модов, а также с некоторыми сотрудниками Valve. Существует также архив данной рассылки, где вы можете найти кучу полезных решений типичных проблем, возникающих при разработке мода.

Завершение

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

В качестве начальной оценки времени, которое потребуется на переход от обычной разработки к выпуску мода, мы берем пять недель. Очень возможно, что вы будете получать успешные релизы версий в целом лучше, а значит чаще. Если ваш мод масштабнее или ваша команда большей частью интернациональная, то вероятно потребуется больше пяти недель, но последовательность действий будет такой же, как и изложенная ниже. Насколько это возможно, постарайтесь, чтобы в течение этих недель команда каждый день несколько часов уделяла работе над модом. Если некоторые члены команды не могут этого сделать, лучше исключить их из процесса shipping'а (производства финальной версии). Пусть они передадут свои дела кому-то еще в команде, кто может вложить нужные усилия в работу над завершением мода. Шиппинг продукта, даже небольшого, работа тяжелая и требует исполнения важных обязанностей.

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

Есть еще кое-что, в чем заинтересованы будущие члены команды. Одно дело видеть, что разработчик мода сваял что-то крутое. Совершенно другое дело, когда они видят, что они сделали крутой мод, что они его закончили, и люди в него играли. Самый лучший в мире уровень/противник/код/звук и т.д. совершенно бесполезен, если вы не можете сделать последний рывок и выпустить его.

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

Пять недель до релиза

Централизуйте владение проектом

Вам следует назначить одного члена команды как Shipping Leader (SL), руководителя, занимающегося выпуском мода. Он будет заведовать развитием мода в последующие пять недель. Все изменения в моде с этого момента должны происходить только по просьбе SL, а все запросы на изменения должны проходить через него. Ни один член команды не должен вносить никаких изменений в мод, даже самых незначительных, если SL не попросил внести это конкретное изменение. Это не означает, что остальная команда теряет контроль над модом; SL по-прежнему является частью команды, и готов прислушаться к любым рекомендациям. Смысл SL в том, чтобы гарантировать: все изменения в моде проходят через одного человека. Это исключает такие проблемы, как, например, неработоспособность всей игры из-за левелмейкера, сделавшего изменение в последнюю минуту, и не сообразившего, что в коде игры изменяется что-то еще. В течение следующих 5 недель SL всегда будет знать, в каком состоянии находится каждый элемент игры (код, карты, модели, текстуры и т.д.), дабы гарантировать, что такого инцидента не произойдет.

Выбирать Shipping Leader'а непросто. Вот несколько рекомендаций:

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

Установите последовательность процесса сборки

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

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

Shipping Leader должен каждый день собирать мод для плейтестов. Подробнее об этом ниже.

Замораживание фич

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

К этому моменту shipping'а, за пять недель до выпуска мода, вам нужно также заморозить фичи. это означает, что вам не следует добавлять никаких новых фич в ваш мод, вообще никаких. Есть часть вашей команды не занимается шиппингом, но хочет продолжать работать над модом, то этим члены команды должны работать с отдельной копией контента и базой программного кода. Большая часть пакетов для контроля кода позволяет ветвление кода на этот случай (Да, мы крайне рекомендуем вам использовать что-нибудь для контроля исходного кода). Любое изенение в моде с этого момента должно быть исправлением бага. За этим должен следить SL. Даже если кодер придумает еще одну замечательную фичу, которая, по его словам, займет каких-то 10 минут на программирование, не позволяйте ему добавлять ее. Даже если кодер отправляет код, законченный и проверенный на отсутствие ошибок, не вставляйте его в мод. Оставьте до следующей версии

Для SL разумно придерживаться позиции, что любое изменение в моде с момента начала шиппинга добавит два дня к дате выпуска.

Плейтесты

Начиная с этого момента вам надо проводить плейтесты каждый день, или же два дня, если ежедневные плейтесты это слишком много. Плейтесты должны проводиться на инсталлируемых версиях игры, собранных Shipping Leader'ом. Не позволяйте членам команды играть в их версии игры. Все должны запускать версию пода, поставленную их билда, высланного SL (это то, что поставят и во что будут играть ваши игроки, это именно то, что нужно тестировать). Если вы не будете этого делать, то убьете много времени на поиск багов, вызванных несовместимостью версий.

Чтобы упростить эту задачу, мод должен постоянно поддерживаться в играбельном состоянии. Вы должны очень, очень сильно беспокоиться каждый день, когда в мод нельзя проиграть. Если программист или создатель карты делает изменение, которое делает мод неработоспособным, очень хорошо обдумайте его, прежде чем добавлять в билд Shipping Leader'а. Как долго игра останеться неиграбельной? Сколько плейтестов вы пропустите? Сколько членов команды не смогут работать из-за того, что мод не запускается? Для команды сохранение работоспособности мода должно стать культом на время шиппинга.

Когда вы делаете плейтесты, убедитесь, что играет столько членов вашей команды, сколько может. Все, кто работает над игрой, должны регулярно в нее играть. Убедитесь также, что у вас есть и внешние игрока. Включите запись лога консоли сервера (проставьте "log" значение "on" в файле server.cfg). Тогда вся выходная иформация сервера будет выводиться в файл в папке gamedir/logs (имя файла будет соотвествовать дате). Когда бы игрок не обнаружил ошибку, пусть он использует кнопку для "разговора", чтобы сказать "BUG: описание бага". Позже, когда игра окончится, вы можете открывать лог и вытащить все ошибки поиском по слову "BUG".

Баги и изменения

SL должен вести полный список всех ошибок и правок, а также их текущего состояния. Лучше это делать используя какую-то настоящую базу данных. E-mail абсолютно неэффективен для багтрекинга; там сообщения с потрясающей легкостью уходят с первой страницы сообщений и т.п. После каждого плейтеста SL должен добавить баги и необходимые изменения из лога в список и поручить изменения определенным членам команды. После того, как человек внес правку или исправил ошибку, он должен отправить новый конкент Shipping Leader'у, который проверит, что он исправлен, и проапдейтит список ошибок.

Баглист - превосходный инструмент, чтобы оценить, как быстро вы продвигаетесь. Его можно использовать чтобы определить, кто перегружен работой, кто простаивает, кто не исправляет свои ошибки, какая часть мода дальше всего от завершение и т.п. Не удаляйте ничего из баглиста, даже когда оно исправлено (хотя вы, конечно, должны как-то отметить, что оно исправлено). Это очень полезно, чтобы видеть, какие ошибки исправлялись в истории проекта. Что-то может регрессировать, вызвав повторное появление бага. А когда известно, кто исправил ошибку в прошлый раз, легче узнать у него, что же могло вызвать ошибку снова. К концу проекта вы должны иметь возможно увидеть все исправленные баги и все внесенные изменения за время shipping'а. SL не должен вставлять никаких исправлений в свою копию, если оно не описано в баглисте.

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


Большое примечание переводчика: русскоязычным читателям предлагается посмотреть на систему багтрекинга, используемую компанией "Бука", скриншот которой есть в докладе Николая Сафронова с КРИ-2004. Это внутренняя разработка - простая, быстрая и достаточно эффективная. В самом первом приближении это столбцы с номерами багов, описанием ошибки, ее серьезностью и статусом

Вырезание или откладывание неработающих фич

Тяжелейшая, неприятнейшая и, к сожалению, самая необходимая часть shipping'а -- быть реалистом и удалять фичи из проекта. У нас в Valve есть шутка, что у каждого есть любимая особенность, вырезанная из игры. Хотя это и неправда, но она помогает всем подготовиться к тому, что найдутся фичи, которые им нравятся -- или над которыми они долго работали,-- которые будут вырезаны. Ваша игра не может вобрать в себя все-все-все замечательные фишки и все-таки выйти в разумные сроки. SL должен принимать решения о том, что заканчивать, а что вырезать, в зависимости от того, как далеко вы находитесь в процессе создания версии для релиза.

Чем ближе вы приближаетесь к релизу, тем больше должны думать о каждом новом найденном баге. Не обнаружилась ли ошибка в фиче, которая совершенно точно должа быть в этой верси? Сколько дней займет исправление реализации этой фичи? Может ли она быть вырезана или отложена до более поздней версии?

Семь раз отмерь, один отрежь

Как уже было сказано много раз, процесс завершения мода тяжелый, и он становится еще тяжелее, если вы не слишком хорошо обдумываете, над чем именно нужно поработать. Просто много работы никогда не заменит внимательного выбора того, что нужно поправить, что отложить, что вырезать. SL должен быть очень осторожен в выборе того, над какими багами/изменениям следует работать, и кто ими будет заниматься. Не тратьте время на исправление малозаметной ошибки в релизации фичи лишь потому, что фича очень крутая. Правьте вылеты. Правьте баги, которые сильно мешают вам выпустить игру. Правьте баги, которые не дают другим членам команды исправлять свои баги. SL должен разработать деление багов по категориям, чтобы было проще принять правильное решение. Хорошее разбиение по уровням важности может быть таким : Необходимо исправить, Серьезная, Средняя важность, Незначительная, Нулевая, Отложена.

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

Три недели до выхода

Заморозка контента

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

Прекращение работ

Это уже подчеркивалось на отметке за пять недель до релиза, но сейчас это еще важнее. SL единственный, кто должен прикасаться к мастер-копии игры, и он при этом должен просто встраивать в игре баг-фиксы от программистов, которые в свою очередь должны править только те баги, которые он им поручает.

Плейтесты

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

Неделя до выхода

Никаких исправлений в последнюю минуту

Shipping Leader должен оценивать каждое изменение, которое нужно внести, и решать, не следует ли отложить это изменение до следующей версии. Еще раз, здоровый подход - считать, что любое изменени, даже одна строка кода, накинет два дня к дате релиза.

Безопасный двухдневный промежуток

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

Если ваш мод прошел 48 часов тяжелого плейтестирования, и не обнаружилось новых проблем, вы готовы выпускать его!

После релиза

И так, мод вышел, игрокам он очень нравится, а на сайтах пишут, как увлекательно в него играть. Закончена ли ваша работа теперь - решать вам. Наш опыт на ниве мультиплеера показывает, что мод остается популярен пока он поддерживается разработчиками. Неважно какой он замечательный, он не соберет какого-то заметного числа игроков в первой версии. Количество игроков растет со временем, когда вы регулярно выпускаете новый контент, правите ошибки и, разумеется, поддерживаете коммьюнити. И Counter-Strike, и Team Fortress начинали маленькими и выросли со временем. Каждый раз с выпуском новой версии, все больше игроков пробовали их и начинали в них играть.

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

Удачи!

См.также

Template:Otherlang:ru Template:Otherlang:ru:en, Template:Otherlang:ru:fr