Difference between revisions of "Making a Mod:ru"

From Valve Developer Community
Jump to: navigation, search
(Russian translation of "Making a Mod" introductory article)
 
(Замораживание особенностей)
 
(27 intermediate revisions by 15 users not shown)
Line 1: Line 1:
[[Category:Modding|Категория:Создание модификаций]]
+
{{otherlang2
Эта статья написана, чтобы помочь вам сделать модификацию для движка[[Source Engine Features|Source Engine]], или ''[[mod|мод]]''. В начале она содержит советы по тому, как начать создание мода и собрать команду. Затем собраны полезные рекомендации по игровому дизайну для вашего мода. И наконец, в этой статье во второй половине пошаговое руководство, которое поможет заткнуть все дыры и закончить мод, что является, на самом деле, самым сложным в создании модификации.
+
|title=Создание Модификации
 +
|en=Making_a_Mod
 +
|de=Making_a_Mod:de
 +
|es=Making_a_Mod:es
 +
|fr=Making_a_Mod:fr
 +
}}
 +
 
 +
Эта статья призвана помочь вам сделать [[Source Engine Features|Source Engine]] модификацию, или ''[[mod:ru|мод]]''. Сперва рассматриваются советы по началу разработки и набору команды. Далее - советы касательно игрового дизайна. В завершении предоставлено пошаговое руководство по организации финальных изменений и релиза вашего мода, что является самой трудной частью.
  
 
== Старт ==
 
== Старт ==
Сначала обсудим как собрать команду. Ваше первое правило -- команда должна быть и оставаться маленькой. Управление командой это работа на полную занятость, даже если вся она работает в одном здании. Если вы работаете с онлайновой командой, то можете запросто потратить все свое время на руководство, а это означает, что на создание мода времени у вас не останется. То, что вы наберете больше людей, вовсе не означает, что будет сделано больше работы для мода. Чем больше у вас людей, тем больше времени уходит на руководство командой. В основную команду Team Fortress входило три человека. Костяк команды [[Counter-Strike]] состоял из одного человека.
+
Давайте начнем с того, как собрать команду. Основное правило - сделать ее маленькой. Управление командой подобно полному рабочему дню, даже если вся команда находится в одном здании. Если вы имеете дело с онлайн командой, все ваше время уйдет на управление, и это означает, что у вас не останется время на непосредственное участие в создании мода. Если в команде много людей, это не означает, что работа будет двигаться быстрее. Чем больше людей вы контролируете, тем дольше вы тратите на это время. Основная команда по созданию Team Fortress - 3 человека. Основная команда по созданию [[Counter-Strike]] - 1 человек.
 
 
Когда вы будете искать людей для команды, старайтесь набирать только тех, без кого точно не сможете обойтись. Первым порывом будет брать в команду всех, кто может писать код, моделировать, делать карты и т.п. Но для первой версии, вероятно, вам не понадобится больше одного человека каждой профессии (код, звук, модели, уровни). Возможно, вам даже не понадобятся новые модели, звуки или карты. Не берите никого, пока не увидите примеры их работ. Убедитесь, что у них есть действительно законченные работы. Если они все моделлеры с 20 моделями, среди которых нет ни одной готовой, то они вам не нужны.
 
  
 +
При поиске членов команды, старайтесь нанимать людей, без которых вы точно не сделаете мод. Вашим первым членом команды может стать любой, кто может программировать, делать модели, создавать карты и т.д. Но для первой версии, вам, вероятно не понадобится более одного человека на каждую часть вашего мода (код, звуки, модели, карты). Вам не нужно думать о новых полноценных моделях, звуках, или картах. Не нанимайте людей, чьих работ вы не видели. Убедитесь, что они привыкли завершать свои проекты. Если человек сделал 20 моделей, но не закончил их - он вам точно не нужен.
  
 
== Дизайн мода ==
 
== Дизайн мода ==
Если вы автор мода, тогда лучший вопрос, который вы можете себе задать -- "Почему кто-то должен играть в мою модификацию?" На этот вопрос тяжело отвечать честно, но если вы можете на него дать хороший ответ -- вы на верном пути. Подумайте, какие еще есть моды. Подумайте, что они могут предложить игрокам. Может ли ваш мод предложить им что-то новое? А то, что в вашем моде есть, -- его достаточно, чтобы привлечь игроков, которые уже заняты игрой в другие моды? Даже если вы не можете ответить на этот вопрос, просто принимайте его во внимание. Это может сделать ваш мод лучше.
+
Как автор мода, самый полезный вопрос который вы можете задать самому себе - "Почему кто-либо должен играть в мою игру?" Это достаточно сложный вопрос, чтобы ответить на него правдой, но если вы сможете ответить, вы на правильном пути. Подумайте чего нет в вашем моде, или что в нем есть такого, чего нет в других модах. Было ли сделано что-либо новое для игроков? Сделано ли достаточно, чтобы привлечь игроков, играющих в другие игры? Даже если вы не можете ответить на этот вопрос, просто думая об этом, вы сможете улучшить вашу модификацию.
  
=== Конкурируйте геймплеем===
+
=== Ваше оружие - геймплей ===
У вас есть возможность, которой комерческие разработчики лишены: вам не нужно беспокоиться о коммерческой жизнеспособности нового геймплея. Коммерческим разработчикам нужно думать о привлекательности для розничной продажи, об окупаемости их продукта и других непростых вещах, из-за чего большинство игр основаны на слегка измененном годами проверенном геймплее. Но вам это не нужно. Вы можете экспериментировать с действительно новыми подходами к игровому процессу, с идеями, которые могут оказаться следующим прорывом в играх. Это ваше преимущество перед коммерческими разработчиками. Упростите себе жизнь, сконцентрируйте свои усилия именно на этом преимуществе. И не тратьте попусту время, стараясь конкурировать с очень сильными сторонами коммерческих продуктов. Большая часть модов не может сравняться с коммерческими играми по качеству контента (карты, модели, звук и т.д.). Их делали команды художников и моделлеров с годами опыта. Обыграйте их геймплеем. Игроки с радостью будут играть в мод, в котором мало нового контента, но зато есть увлекательный геймплей. Многие не понимают, что в течение года после первого релиза Team Fortress 1 в нем почти не было новой графики.
+
У вас есть то, чего нет у коммерческих разработчиков: Вам не придется беспокоится о коммерческом успехе нового стиля игры. Коммерческим разработчикам приходится думать о привлечении розничных продавцов, безубыточности и о многих других неприятных вещах, и именно поэтому многие игры являются лишь немного измененными классическими жанрами. Но вас это не касается. Вы можете пробовать новые идеи, развивать их и сделать что-то новое, что изменит игровую индустрию. Это ваше преимущество над коммерческими разработчиками. Облегчите вашу работу, сконцентрировавшись на этой грани, и не тратьте свое время на конкуренцию с коммерческими продуктами, которые явно добились успеха. Большинство модов не могут конкурировать на уровне содержания (карты, модели, звуки и т.д.) с коммерческими продуктами. Над ними работают художники с многолетним опытом. Победите их вашим геймплеем. Игроки будут играть, даже если не планируется улучшений, но имеется интересный геймплей. Многие люди не понимают, почему в течении года после релиза Team Fortress 1 в него ничего не добавлялось.
  
=== Выпускайте скорее, выпускайте чаще ===
+
=== Выпускайте скорее! Выпускайте чаще! ===
У вас есть еще одно преимущество перед разработчиками коммерческих игр. Вы можете выпускать свой продукт гораздо, гораздо быстрее, и намного чаще, чем могут они. Мы выразили эту философию разработки модов фразой, вынесенной в заголовок: "Выпускайте скорее, выпускайте чаще". Коммерческие разработчики работают 2-3 года, выпускают свою игру, после чего им остается только молиться, что людям она понравится. Вам не нужен этот решительный шаг в неизвестность. Вы можете придумать дизайн всего мода, воплотить 25%, отполировать эти 25 процентов до играбельного состояния, а потом выпустить мод и начать немедленно получать обратную связь от пользователей. Затем вы можете постепенно добавлять оставшиеся кусочки дизайна в ваш мод, в то же время учитывая отзывы пользователей первой версии, и продолжать выпускать новые версии каждые один-два месяца. Вы всегда рядом с игроками, поэтому вы никогда не окажетесь в ситуации, когда много времени ушло на разработчку чего-то, в чем вы не уверены, и что может не понравиться вашим игрокам. Фокус в том, чтобы разделить мод на маленькие части. В первую версию должно быть интересно играть, но в то же время ей не нужны все до единой фичи, которые вы задумали.
+
Вы имеете огромное преимущество над коммерческими разработчиками. Вы можете выпускать обновления гораздо чаще, быстрее и больше, чем они. Мы совместили эту философию разработки мода в одну фразу - "Release soon, Release often." Коммерческие разработчики работают 2-3 года, чтобы выпустить их игру, и надеются на бога, чтобы людям она понравилась. Вам не нужно верить. Вы можете разработать идею мода, сделать 25% от всего, затем предоставить результат игровому сообществу, и они сразу же свяжутся с вами. После этого вы можете добавлять остальной контент по частям, в это же время получая мнения о первой версии, и продолжать выпускать новые версии каждые один-два месяца. Вы всегда находитесь на связи со своими игроками, так что вы не попадете в ситуацию, когда вы потратили много времени на то, что игрокам может не понравится. Весь фокус в том, чтобы уменьшить количество недочетов в финальной версии. Первоначальная версия должна быть веселой и играбильной, но не содержащей попытки реализовать все придуманные вами функции.
  
Будьте острожны. "Выпускайте скорее" не означает, что нужно выпустить недоделанный и некачественный мод. Эта фраза означает, что создание мода должно продвигаться маленькими, выверенными шагами. Первая версия [[Counter-Strike]] не имела и половины фич, которые есть сейчас. Команда CS выпустила высококачественный, но не слишком большой мод. В течение последнего года они регулярно добавляли все новые и новые фичи, в результате количество игроков все продолжало и продолжало расти вместе с внесением новых изменений.
+
Будьте осторожны. "Быстрый выпуск" не означает, что вы должны выпускать не качественные версии, нужно делать небольшие, но качественные изменения. Первая версия [[Counter-Strike]] не имела и половину от того, что она имеет сейчас. Команда CS делала высококачественные, но не большие модификации. В последний год они добавляли все больше функций, и в ответ на это, все больше игроков становились их фанатами.
  
=== По-другому не значит лучше ===
+
=== Другой - не обязательно лучший ===
Когда продумываете геймплей, не попадите в ловушку, свято веря, что "По-другому -- значит лучше". Нет причины переписывать код дробовика и вставлять новую модель дробовика, если геймплей не станет от этого интереснее. Всегда помните самый первый вопрос, который вы должны себе задавать: "Почему кто-то должен играть в мой мод?" Ответ "В моем моде новая боевая система и новая система передвижения" не обязательно хороший. Значит, ваша боевая система не такая, как в Half-Life. Ладно. А... она лучше? Ваш мод с ней становится увлекательнее? Новая система передвижения делает игру интереснее? Игроки уже привычны к существующим системам, и изучение новой должно по крайней мере быть для них оправдано. Поэтому перед тем, как думать о изменении каких-то элементов, убедитесь, что будете менять их к лучшему, и что модификация от этих изменений выиграет. Не бойтесь просто оставить что-то таким, каким оно было в Half-Life.
+
Когда вы думаете над игровым дизайном, не попадитесь в ловушку, полагая, что "Различие - это хорошо". Нет смысла переделывать код и модель дробовика, если он не влияет на общую концепцию вашей игры. Всегда держите в памяти вопрос, "Почему кто-либо должен играть в мою игру?" Ответ, "Мой мод имеет новую боевую систему и новую систему передвижения", не всегда является лучшим ответом. Ваша боевая система отлична от Half-Life? Хорошо... но она лучше? Сделает ли она вашу игру более интересной? Сделает ли новая система передвижений вашу игру более веселой? Игрок использует уже существующие системы, и делая что-то новое, изучите, что игроку будет полезно. Поэтому, прежде чем изменять что-либо, убедитесь, что изменения приведут к лучшему результату, и сделают вашу игру более веселой. Не бойтесь оставлять все тоже самое, что было в Half-Life.
  
=== Реалистичные цели ===
+
=== Реальные цели ===
Ставьте перед собой реалистичные цели. Подумайте, сколько времени коммерческие разработчики тратят на FPS с десятью видами оружия. Если вы делаете мод с 40 стволами, то сильно усложняете себе жизнь. Имейте в виду -- "лучше меньше, да лучше". Качество гораздо важнее количества. Игроки предпочтут 10 уникальных, сбалансированных экземпляров оружия, с которыми интересно играть, а не 40 несбалансированных экземпляров, некоторые из которых являются незначительно переработанными версиями других.
+
Создавайте для себя реалистичные цели. Подумайте о том, сколько занимает коммерческая разработка FPS шутера с 10 пушками. Если ваш мод будет иметь 40 единиц оружия, вы действительно усложните себе жизнь. Всегда помните, что "Качество превосходит над Количеством." Игроки предпочитают иметь 10 уникальных, сбалансированных и веселых, чем 40 не сбалансированных единиц оружия, некоторые из которых чуть лучше других.  
  
Не бойтесь вырезать контент и фичи. Если возникает впечатление, что мод никогда не будет закончен, или если какой-то контент кажется вам неподходящим по качеству к остальному моду, начните вырезать ненужное. В процессе разработки Half-Life 2 по меньшей мере 30% исходных фич дизайна были удалены, потому что стало очевидно, что они нереализуемы за отведенные нам сроки или потому что мы решили, что результат не будет стоить потраченного на разработку времени. Как уже было сказано, "лучше меньше, да лучше". Игрокам 3 действительно хороших, протестированных карты понравятся больше, чем 10 непротестированных, и из-за этих трех карт ваш мод получит хорошую репутацию за качество контента. Пусть мир никогда не увидит худшее, на что вы способны.
+
Не бойтесь вырезать контент и особенности. Если мод выглядит не законченным, или какой-либо контент не соответствует качеству остального контента - начните вырезать. В ходе разработки HL около 30% из оригинальной идеи были вырезаны, потому что их было не возможно закончить в сроки. Как мы уже говорили, "Качество превосходит над Количеством." Игроки предпочитают играть в 3 действительно хороших, протестированных карты, чем в 10 плохо разработанных, и это даст вашему моду репутацию качественного мода. Не позвольте миру увидеть ваши худшие разработки.
  
=== Поймите работу движка ===
+
=== Понимание движка ===
Вам действительно нужно прочитать [[SDK_Docs|документацию]], включенную в SDK. В основном, изучая ее вы поймете не принципиальную возможность реализовать X с помощью движка, а то, как нужно реализовать X так, чтобы оно хорошо работало. Вы можете сделать пушку, которая выпускает 50 ракет разом, но если если вы не понимаете, как работает движок, то можете сделать ее таким образом, что у пользователей вашего мода заметно поднимится сетевой траффик. Это важно для всех, кто работает над модом. Если ваши левелдизайнеры не понимают движок, они сделают огромные карты, вообще не задумываясь, сколько данных на этих картах будет передаваться в сети между пользователями. И все игроки будут ругать ваш код за то, что он слишком сильно загружает сеть. Если вы программист, то будет не лишним подписаться на рассылку HL Coders, где вы сможете пообщаться с многими программистами модов, а также с несколькими сотрудниками Valve. У этой  рассылки за долгое время накопились архивы, где есть много полезных решений распространенных в создании модоа проблем.
+
Вы действительно должны прочитать [[SDK_Docs:ru|документацию]], включенную в SDK. Вы должны не просто понимать как делаются вещи в движке, но и как сделать их правильно. Вы можете сделать оружие, стреляющее 50 ракетами, но если вы не понимаете, как работает движок, то можете сделать это таким образом, что мод будет использовать большое количество сетевого трафика. Это важно для каждой модификации. Если создатели карт не понимают движок, они будут делать огромные карты, не задумываясь о том, сколько данных будет посылаться пользователям, играющим в нее, и каждый будет винить ваш код за слишком интенсивное использование сети. Если вы программист, хорошей идеей будет присоединится к рассылке списка HL Кодеров, где вы сможете поговорить с многими другими программистами, а так же с некоторыми сотрудниками Valve. Рассылка списка имеет большие архивы, в которых содержится много полезных решений общих проблем моддинга.
  
 
== Завершение ==
 
== Завершение ==
Мы видим множество модов с хорошим стартом, создатели которых делают много прекрасного контента, но так никогда и не делают самый последний шаг. Шаг к тому, чтобы их мод попал к игрокам. Этот раздел поможет вам подойти к работе непосредственно перед выходом вашей модификации, когда вы постоянно приближаетесь к завершению релизной версии мода.
+
Мы видим много сильных модов, содержащих большие объемы потрясающего контента, но так и не попавших в руки игрокам. Этот раздел поможет вам начать подготовку к выпуску финальной версии вашей модификации.
  
В качестве начальной оценки времени, которое потребуется на переход от обычной разработки к выпуску мода, мы берем пять недель. Очень возможно, что вы будете получать успешные релизы версий в целом лучше, а значит чаще. Если ваш мод масштабнее или ваша команда большей частью интернациональная, то вероятно потребуется больше пяти недель, но последовательность действий будет такой же, как и изложенная ниже. Насколько это возможно, постарайтесь, чтобы в течение этих недель команда каждый день несколько часов уделяла работе над модом. Если некоторые члены команды не могут этого сделать, лучше исключить их из процесса shipping'а (производства финальной версии). Пусть они передадут свои дела кому-то еще в команде, кто может вложить нужные усилия в работу над завершением мода. Шиппинг продукта, даже небольшого, работа тяжелая и требует исполнения важных обязанностей.
+
Мы выбрали пять недель в качестве точки старта, этого времени достаточно, чтобы перейти от режима разработки к выпуску мода. Вполне возможно у вас будет получатся лучше и быстрее с новыми версиями. Если ваш мод масштабный, или если ваша команда из разных стран, то вероятно, потребуется больше пяти недель, хотя шаги будут похожи на следующие. Если это возможно, попробуйте уговорить команду работать над проектом ежедневно в течении пяти часов в этот период. Если некоторые из членов команды не способы на это, лучше будет исключить их из процесса подготовки к выпуску. Пусть они передадут свои наработки другим членам команды, кто сможет вложить необходимые усилия. Подготовить продукт, даже маленький продукт - очень сложно и требует некоторых обязательств.
  
Многое в этом разделе может показаться вам неприятным или слишком строгим. К несчастью, это лишь отражает то, насколько тяжел процесс. Советы здесь это итог опыта, полученного в процессе выпуска многих продуктов. Большей частью это результат крайне болезненных ошибок, сдвигавших наши релизы. Когда вы интересуетесь, действительно ли нужен здесь какой-то из советов, вполне возможно, что мы однажды добавили к нашей дате выхода недсколько недель из-за того, что не воспользовались им.
+
В этом разделе есть много вещей, которые могут показаться резкими или жестокими. Это печально, но это отражает сложность процесса. Здесь представлен опыт, сформированный из уроков, полученных нами в процессе подготовки к выпуску многих продуктов, большинство из которых явились результатом болезненных ошибок, срывавших даты выхода. Вас может это удивить, но действительно важно следовать определенному совету - вполне возможно, что мы были вынуждены отодвигать наши даты выхода на недели только потому, что мы не воспользовались им.
  
Есть еще кое-что, в чем заинтересованы будущие члены команды. Одно дело видеть, что разработчик мода сваял что-то крутое. Совершенно другое дело, когда они видят, что они сделали крутой мод, что они его закончили, и люди в него играли. Самый лучший в мире уровень/противник/код/звук и т.д. совершенно бесполезен, если вы не можете сделать последний рывок и выпустить его.
+
Это связано так же с тем, что потенциальные работодатели так же чрезвычайно заинтересованы в скором выходе. Одно дело, видеть как создатель мода сделал кучу интересных вещей, и другое дело - видеть как было сделано несколько интересных вещей и люди играли именно в это. Самые класные карты/модели/код/звуки и т.д. бесполезны, если вы не можете доделать их в последний момент.
  
Не бойтесь, процесс становится проще, после того как вы уже несколько раз через него прошли. К третьему или четвертому релизу вашего мода вы будете экспертом!
+
Не бойтесь, становится гораздо проще, когда вы прошли через это несколько раз. На ваш третий или четвертый мод вы станете экспертом!
  
 
== Пять недель до релиза ==
 
== Пять недель до релиза ==
=== Централизуйте владение проектом ===
+
=== Централизуйте управление ===
Вам следует назначить одного члена команды как [[Shipping Leader In Detail|Shipping Leader]] (SL), руководителя, занимающегося выпуском мода. Он будет заведовать развитием мода в последующие пять недель. Все изменения в моде с этого момента должны происходить только по просьбе SL, а все запросы на изменения должны проходить через него. Ни один член команды не должен вносить никаких изменений в мод, даже самых незначительных, если SL не попросил  внести это конкретное изменение. Это не означает, что остальная команда теряет контроль над модом; SL по-прежнему является частью команды, и готов прислушаться к любым рекомендациям. Смысл SL в том, чтобы гарантировать: все изменения в моде проходят через одного человека. Это исключает такие проблемы, как, например, неработоспособность всей игры из-за левелмейкера, сделавшего изменение в последнюю минуту, и не сообразившего, что в коде игры изменяется что-то еще. В течение следующих 5 недель SL всегда будет знать, в каком состоянии находится каждый элемент игры (код, карты, модели, текстуры и т.д.), дабы гарантировать, что такого инцидента не произойдет.
+
Вы должны назначить одного члена вашей команды как [[Shipping Leader In Detail|Shipping Leader]] (SL). Этот человек будет управлять процессом разработки на протяжении следующих пяти недель. Все изменения, вносимые в мод должны будут производиться только по просьбе SL, а так же все запросы изменения направляются на этого человека. Не один человек из команды не должен самостоятельно изменять что-либо, не зависимо от того, насколько значительно изменение в моде, только если это не является просьбой SL. Это не означает, что остальная часть команды теряет контроль над процессом разработки; SL это все еще часть команды, и он должен выслушивать все отзывы. Назначение SL - сделать так, чтобы все изменения проходили через одного человека. Это позволит избежать таких проблем, как сделанное создателем карт в последнюю минуту изменение, повлекшие за собой не работоспособность какого-то участка кода. SL будет знать состояние каждого компонента игры (код, карты, модели, текстуры, и т.д.) на протяжении всех 5 недель, чтобы нечего не случилось.
 
 
Выбирать Shipping Leader'а непросто. Вот несколько рекомендаций:
 
* Не надо сразу полагать что человек, занимающийся модом сейчас, и есть лучший кандидат на роль лида, особенно если над модом уже работали месяцами, и нисколько не приблизились к выпуску.
 
* Кодеры, видимо, лучший выбор. Когда shipping подходит к концу, большая часть изменений делается в игровом коде
 
* SL должен быть высоко мотивированным, дисциплинированным, организованым и как можно больше самоотверженным. Он должен быть готов отдать пять недель своей жизни этому процессу.
 
* SL должен уметь принимать глобальные решения, касающиеся мода. Ему следует понимать, что они зачастую потребуют вырезания фич и контента, чтобы выпустить мод.
 
  
=== Установите последовательность процесса сборки ===
+
Выбор SL не легок. Вот несколько советов:
Вам нужно создать процедуру, с помощью которой вы собираете мод. Сборка (building) означает, что вы берете всю свою работу и делаете устанавливаемую, работоспособную версию мода (как правило в виде инсталляционного файла). Это должен делать в течение следующих пяти недель исключительно SL, и у него должна быть строгая последовательность действий, которой он всегда придерживается. Создание жестко заданной последовательности действий гарантирует, что вы не будете часами вылавливать баги, являющиеся лишь результатом того, что кто-то собирал мод не так, как это делали до него.
+
* Не надо сразу полагаться на человека, который в настоящий момент работает над модом, особенно если работа над модом велась несколько месяцев, и он ни насколько не приблизился к релизу.
 +
* Кодеры, возможно, являются лучшим выбором. Когда подготовка к релизу подходит к концу, большинство изменений делается именно в игровом коде.
 +
* SL должен быть высоко мотивированным, дисциплинированным и организованным насколько это возможно. SL должен отдать проекту пять недель его или ее жизни.
 +
* SL должен быть способным принимать глобальные решения касательно мода. Sl должен понимать, что часто требуется вырезать особенности и контент мода, чтобы успеть к дате выхода.
  
SL начиная с этого момента нужно заниматься релиз-кандидатом мода у себя. Все изменения следует отсылать ему, и он должен их встраивать в свою копию мода один за другим, каждый раз полностью осознавая, как внесенные изменения влияют на все составляющие мода. Не забывайте регулярно делать бэкапы своего кода и контента!
+
=== Установите последовательность разработки ===
 +
Вам необходимо создать последовательность разработки мода. Разработка представляет собой принятие всех работ и делает устанавливаемую, рабочую версию мода (как правило, в виде установочного файла). Это должен делать только SL на протяжении следующих пяти недель, и SL должен действовать по строгой последовательности действий, которых он всегда придерживается. Создание последовательности действий позволяет не тратить часы на исправление ошибок, являющихся результатом действий, отличных от действий другого человека.
  
Shipping Leader должен каждый день собирать мод для плейтестов. Подробнее об этом ниже.
+
SL должен постоянно поддерживать финальную или кандидата на релиз версию мода. Все изменения должны отправляться к нему, и он должен включать их в свою копию мода с полным пониманием влияния этих изменений на остальные части мода. Не забывайте постоянно делать резервные копии!
  
=== Замораживание фич ===
+
SL должен ежедневно делать работоспособную версию мода для игрового тестирования. Подробнее об этом позже.
Шиппинг это процесс завершения и закрытия частей вашего мода. "Закрытие" означает, что начиная с момента закрытия это трогать нельзя. Об ошибках, найденных в закрытых для изменений кусочках вашей модификации нужно хорошенько думать перед правкой. Если баг не является действительно фатальным (устойчиво воспроизводящаяся системная ошибка), просто запишите его себе и поправьте в следующем обновлении мода. Каким бы сильным не был соблазн сделать это "маленькое исправление", размораживания частей мода для изменений следует избегать всеми силами.  
 
  
К этому моменту shipping'а, за пять недель до выпуска мода, вам нужно также заморозить фичи. это означает, что вам не следует добавлять никаких новых фич в ваш мод, вообще никаких. Есть часть вашей команды не занимается шиппингом, но хочет продолжать работать над модом, то этим члены команды должны работать с отдельной копией контента и базой программного кода. Большая часть пакетов для контроля кода позволяет ветвление кода на этот случай (Да, мы крайне рекомендуем вам использовать что-нибудь для контроля исходного кода). Любое изенение в моде с этого момента должно быть исправлением бага. За этим должен следить SL. Даже если кодер придумает еще одну замечательную фичу, которая, по его словам, займет каких-то 10 минут на программирование, не позволяйте ему добавлять ее. Даже если кодер отправляет код, законченный и проверенный на отсутствие ошибок, не вставляйте его в мод. Оставьте до следующей версии
+
=== Замораживание особенностей ===
 +
Подготовка к выходу - это процесс замораживания недоделанных частей вашего мода. "Замораживание" означает, что недоделанные части не трогаются вообще. Ошибки найденные в замороженных частях требуют тщательной обработки. Если ошибка действительно важная (устойчиво воспроизводящаяся), просто подметьте ее и исправьте в следующем обновлении вашего мода. Независимо от соблазна "легкого исправления", размораживание частей вашего мода необходимо избегать насколько это возможно.  
  
Для SL разумно придерживаться позиции, что любое изменение в моде с момента начала шиппинга добавит два для к дате выпуска.
+
К моменту выпуска, за пять недель, вы так же должны заморозить особенности мода. Это означает, что вы не должны их изменять. Если часть вашей команды не хочет принимать участие в выпуске, но хочет продолжить работу по разработке мода, они должны работать с отдельной копией контента и базой программного кода. Большая часть пакетов для контроля кода позволяет ветвление кода на этот случай (Да, мы крайне рекомендуем вам использовать что-нибудь для контроля исходного кода). Каждые изменения сделанные в моде отныне должны только исправлять ошибки.За этим должен следить SL. Даже если кодер придумал какую-либо класную возможность, думая, что она делается всего за 10 минут, не позволяйте ему добавлять ее. Даже если кодер отправляет код, законченный и проверенный на отсутствие ошибок, не вставляйте его в мод. Оставьте до следующей версии.
  
=== Плейтесты ===
+
Для SL разумно придерживаться позиции, что любое изменение в моде с момента начала процесса выпуска добавляет два дня к дате выпуска.
Начиная с этого момента вам надо проводить плейтесты каждый день, или же два дня, если ежедневные плейтесты это слишком много. Плейтесты должны проводиться на инсталлируемых версиях игры, собранных Shipping Leader'ом. Не позволяйте членам команды играть в их версии игры. Все должны запускать версию пода, поставленную их билда, высланного SL (это то, что поставят и во что будут играть ваши игроки, это именно то, что нужно тестировать). Если вы не будете этого делать, то убьете много времени на поиск багов, вызванных несовместимостью версий.
 
  
Чтобы упростить эту задачу, мод должен постоянно поддерживаться в играбельном состоянии. Вы должны очень, очень сильно беспокоиться каждый день, когда в мод нельзя проиграть. Если программист или создатель карты делает изменение, которое делает мод неработоспособным, очень хорошо обдумайте его, прежде чем добавлять в билд Shipping Leader'а. Как долго игра останеться неиграбельной? Сколько плейтестов вы пропустите? Сколько членов команды не смогут работать из-за того, что мод не запускается? Для команды сохранение работоспособности мода должно стать культом на время шиппинга.
+
=== Игровое Тестирование ===
 +
С этого момента, вы должны проводить игровое тестирование каждый день, или каждый второй день, если изменения не значительные. Игровое тестирование основывается на установочной версии игры, создаваемое SL. Не позволяйте членам команды играть в свои версии игры. Каждый должен запускать версию мода, созданную SL (это то, что будет предоставлено публике во время установки и использования, вот что означает тестирование). Вы будите тратить много времени на поиск ошибок, связанных с несовместимости версий, если в не сделаете этого.
  
Когда вы делаете плейтесты, убедитесь, что играет столько членов вашей команды, сколько может. Все, кто работает над игрой, должны регулярно в нее играть. Убедитесь также, что у вас есть и внешние игрока. Включите запись лога консоли сервера (проставьте "log" значение "on" в файле server.cfg). Тогда вся выходная иформация сервера будет выводиться в файл в папке gamedir/logs (имя файла будет соотвествовать дате). Когда бы игрок не обнаружил ошибку, пусть он использует кнопку для "разговора", чтобы сказать "BUG: описание бага". Позже, когда игра окончится, вы можете открывать лог и вытащить все ошибки поиском по слову "BUG".
+
Чтобы облегчить эту задачу, мод должен поддерживаться в играбильном состоянии все время. Очень, очень сильно переживайте за каждый день, в который мод стал не играбильным. Если кодер или создатель карт сделал изменение, которое портит мод, хорошо подумайте, прежде чем включать изменения в SL сборку. Как долго игра будет неиграбильна? Сколько игровых тестов вы пропустите? Сколько членов команды не смогут работать, потому что мод не запускается? Не нарушаемая разработка должна стать религией для команды.
  
=== Баги и изменения ===
+
Когда вы начинаете игровое тестирование, убедитесь, что максимальное количество членов вашей команды может провести тестирование вместе с вами. Каждый работающий над игрой должен регулярно в нее играть. Так же убедитесь, что у вас есть внешние тестеры. Включите логирование сервера (установите "log" на "on" в файле server.cfg). Вся выходящая информация в сервере будет записываться в файл в директорию gamedir/logs (Имя файла будет совпадать с датой). Всякий раз, когда игрок замечает ошибку, пусть он использует кнопку "say" чтобы сказать "BUG: описание бага". Затем, когда игра закончится, вы можете открыть лог файл и посмотреть все сообщения о багах, использовав поиск по слову "BUG:".
SL должен вести полный список всех ошибок и правок, а также их текущего состояния. Лучше это делать используя какую-то настоящую базу данных. E-mail абсолютно неэффективен для багтрекинга; там сообщения с потрясающей легкостью уходят с первой страницы сообщений и т.п. После каждого плейтеста SL должен добавить баги и необходимые изменения из лога в список и поручить изменения определенным членам команды. После того, как человек внес правку или исправил ошибку, он должен отправить новый конкент Shipping Leader'у, который проверит, что он исправлен, и проапдейтит список ошибок.
 
  
Баглист - превосходный инструмент, чтобы оценить, как быстро вы продвигаетесь. Его можно использовать чтобы определить, кто перегружен работой, кто простаивает, кто не исправляет свои ошибки, какая часть мода дальше всего от завершение и т.п. Не удаляйте ничего из баглиста, даже когда оно исправлено (хотя вы, конечно, должны как-то отметить, что оно исправлено). Это очень полезно, чтобы видеть, какие ошибки исправлялись в истории проекта. Что-то может регрессировать, вызвав повторное появление бага. А когда известно, кто исправил ошибку в прошлый раз, легче узнать у него, что же могло вызвать ошибку снова. К концу проекта вы должны иметь возможно увидеть все исправленные баги и все внесенные изменения за время shipping'а. SL не должен вставлять никаких исправлений в свою копию, если оно не описано в баглисте.
+
=== Баги и Изменения ===
 +
SL должен вести полный список ошибок и изменений, и их текущее состояние. Предпочтительно, чтобы это делалось с помощью настоящей базы данных. E-mail является совершенно не допустимой для отслеживания ошибок; слишком просто переместить новое сообщение с первой страницы пользователя и т.д. SL должен после каждого игрового тестирования добавлять в список баги и необходимые изменения из лог файла, и сообщать о них членам команды. Когда член команды исправил баг или сделал изменение, он должен послать новый контент SL, который должен убедиться, что ошибка исправлена и изменить ее статус в списке ошибок.
  
Существует софт, который помогает вести и содержать список багов. В качестве альтернативы можете с тем же успехом использовать электронные таблицы. Еще раз повторюсь, e-mail для этого не подходит.  
+
Список ошибок это фантастический инструмент позволяющий отслеживать ваш прогресс. Он может быть использован для определения, кто загружен работой, кто нечем не занят, кто не исправил свои ошибки, как далеко ваш мод от завершения и т.д. Не удаляйте ничего из списка ошибок, даже когда ошибка была исправлена (конечно, ее следует помечать как исправленную). Это очень полезно, чтобы отслеживать список всех ошибок которые были исправлены на протяжении всей истории проекта. Что-то может регрессировать, пересоздав баг, и зная, кто исправил ошибку в прошлый раз, можно узнать у него причины появления ошибки. В конце проекта, вы должны видеть все исправленные ошибки и каждое изменение сделанное в вашем моде в течении периода подготовке к выпуску. SL не должен включать в свою копию любое изменение мода, если оно не описано в баглисте.
  
 +
Существует программное обеспечение, помогающее в создании и ведении списка ошибок. Кроме того, обычная таблица будет прекрасно работать. Опять же, электронная почта является плохим выбором.
  
''Большое примечание переводчика: русскоязычным читателям предлагается посмотреть на систему багтрекинга, используемую компанией "Бука", скриншот которой есть в [http://www.kriconf.ru/2004/rec/KRI-2004.ProjectManagement_06.ppt докладе Николая Сафронова с КРИ-2004]. Это внутренняя разработка - простая, быстрая и достаточно эффективная. В самом первом приближении это столбцы с номерами багов, описанием ошибки, ее серьезностью и статусом ''
+
''Русскоязычным пользователям предлагается посмотреть на систему багтрекинга, используемую компанией "Бука", скриншот которой есть в [http://www.kriconf.ru/2004/rec/KRI-2004.ProjectManagement_06.ppt докладе Николая Сафронова с КРИ-2004]. Это внутренняя разработка - простая, быстрая и достаточно эффективная. В самом первом приближении это столбцы с номерами багов, описанием ошибки, ее серьезностью и статусом ''
  
=== Вырезание или откладывание неработающих фич ===
+
=== Вырезание или откладывание особенностей ===
Тяжелейшая, неприятнейшая и, к сожалению, самая необходимая часть shipping'а -- быть реалистом и удалять фичи из проекта. У нас в Valve есть шутка, что у каждого есть любимая особенность, вырезанная из игры. Хотя это и неправда, но она помогает всем подготовиться к тому, что найдутся фичи, которые им нравятся -- или над которыми они долго работали,-- которые будут вырезаны. Ваша игра не может вобрать в себя все-все-все замечательные фишки и все-таки выйти в разумные сроки. SL должен принимать решения о том, что заканчивать, а что вырезать, в зависимости от того, как далеко вы находитесь в процессе создания версии для релиза.
+
Самая трудная, скверная, и к сожалению, наиболее необходимая часть подготовки к выпуску - быть реалистом, и вырезать не готовые части. Мы в Valve шутим, что у каждого есть своя любимая особенность игры, которая в конечном счете была вырезана. Хотя это не так, это помогает каждому подготовить себя к тому, что они будут иметь функции, которые они хотели -- или на что они потратили много времени--, но могут быть вырезаны. Ваша игра просто не может иметь все класные функции и выпуститься в разумные сроки. SL должен принимать решение о том, что необходимо вырезать, основываясь на том, как далеко вы зашли в процессе создания и как далеко до даты выпуска.
  
Чем ближе вы приближаетесь к релизу, тем больше должны думать о каждом новом найденном баге. Не обнаружилась ли ошибка в фиче, которая совершенно точно должа быть в этой верси? Сколько дней займет исправление реализации этой фичи? Может ли она быть вырезана или отложена до более поздней версии?
+
Чем ближе к выпуску, тем больше вы должны думать над каждой обнаруженной ошибкой. Является ли это ошибкой в функции, которая обязательно должна входить в игру? Сколько дней понадобится, чтобы исправить эту функцию? Можно ли вырезать эту функцию, или ее можно отложить до более поздней версии?  
  
 
=== Семь раз отмерь, один отрежь ===
 
=== Семь раз отмерь, один отрежь ===
Как уже было сказано много раз, процесс завершения мода тяжелый, и он становится еще тяжелее, если вы не слишком хорошо обдумываете, над чем именно нужно поработать. Просто много работы никогда не заменит внимательного выбора того, что нужно поправить, что отложить, что вырезать. SL должен быть очень осторожен в выборе того, над какими багами/изменениям следует работать, и кто ими будет заниматься. Не тратьте время на исправление малозаметной ошибки в релизации фичи лишь потому, что фича очень крутая. Правьте вылеты. Правьте баги, которые сильно мешают вам выпустить игру. Правьте баги, которые не дают другим членам команды исправлять свои баги. SL должен разработать деление багов по категориям, чтобы было проще принять правильное решение. Хорошее разбиение по уровням важности может быть таким : Необходимо исправить, Серьезная, Средняя важность, Незначительная, Нулевая, Отложена.
+
Как мы уже говорили снова и снова, процесс подготовки сложный, и он становится еще сложнее, если вы неправильно управляете приоритетами разработки. Долгая работа никогда не заменит внимательного выбора того, что необходимо исправить, что отложить, что вырезать вообще. SL должен быть очень осторожен при выборе над какими ошибками/изменениями надо работать, и кому. Не тратьте неделю на исправление небольшой проблемы в функции просто потому, что она класная. Исправьте ошибки завершающие игру (crash bugs). Исправьте ошибки, наименее мешающее подготовке к выпуску. Исправьте ошибки, мешающие другим членам команды исправлять свои ошибки. SL должен разработать категории ошибок для принятия правильных решений. Хорошее разбиение по уровням важности: Должно быть исправлено, Тяжелые, Средние, Незначительные, Нулевые, Отложенные.
  
Когда проект приближается к выходу, SL нужно вдумчиво оценивать каждую ошибку, которая будет замечена. Помните, что любое исправление бага приводит к дополнительному плей-тестированию, и обычно -- к большему числу ошибок. Если у вас осталось две недели до релиза, а у вас баг, требующий для исправления трех дней работы и 500 строк кода, вы точно не успеете до релиза, если не вырежете или не отложите этот фрагмент игры до следующей версии.
+
Так как проект становится ближе к выпуску, SL должен тщательно оценивать каждую появляющуюся ошибку. Помните, что каждая исправленная ошибка ведет за собой больше игровых тестов и обычно - к новым и новым ошибкам. Если у вас осталось две недели до релиза, а у вас баг, требующий для исправления трех дней работы и 500 строк кода, вы точно не успеете до релиза, если не вырежете или не отложите этот фрагмент игры до следующей версии.
  
== Три недели до выхода ==
+
== Три недели до релиза ==
=== Заморозка контента===
+
=== Заморозка контента ===
К этому моменту нужно стремиться к завершенности контента. Это означает, что все контент в игре находится в закрытом состоянии, за исключением самого игрового кода. Все уровни, модели, текстуры, звуковое оформление, руки игрока, стартовые сцены и т.п. должны быть закончены и находиться в мастер-копии у Shipping Leader'а.
+
К этому моменту нужно стремиться к завершенности контента. Это означает, что весь контент игры, кроме игрового кода заморожен. Все карты, модели, текстуры, звуки, HUD арт, Launcher арт и т.д. должны быть завершены и находится в копии у SL.  
  
 
=== Прекращение работ ===
 
=== Прекращение работ ===
Это уже подчеркивалось на отметке за пять недель до релиза, но сейчас это еще важнее. SL единственный, кто должен прикасаться к мастер-копии игры, и он при этом должен просто встраивать в игре баг-фиксы от программистов, которые в свою очередь должны править только те баги, которые он им поручает.
+
Это уже подчеркивалось на отметке за пять недель до релиза, но сейчас это еще важнее. SL должен быть единственным человеком, которому разрешено изменять мастер-копию игры, и он должен просто встраивать исправления ошибок от кодеров, которые должны исправлять ошибки полученные только от него.
  
=== Плейтесты ===
+
=== Игровое Тестирование ===
Мод должен проходить плейтесты каждый день, минимум по два часа. С этого момента и до самого выхода вам нужно как можно больше людей, которые занимаются вашим модом. Слишком поздно вносить какие-либо крупные изменения игрового дизайна - даже не надейтесь.
+
Игровое тестирование мода должно проводится каждый день, по крайней мере два часа. С этого момента и до самого выхода вам нужно как можно больше людей, которые занимаются вашим модом. Слишком поздно вносить какие-либо крупные изменения игрового дизайна - даже не надейтесь.
  
== Неделя до выхода ==
+
== Одна неделя до выхода ==
 
=== Никаких исправлений в последнюю минуту ===
 
=== Никаких исправлений в последнюю минуту ===
Shipping Leader должен оценивать каждое изменение, которое нужно внести, и решать, не следует ли отложить это изменение до следующей версии. Еще раз, здоровый подход - считать, что любое изменени, даже одна строка кода, накинет два дня к дате релиза.
+
SL должен оценивать каждое изменение, которое должно быть сделано, или же они должны быть отложены до следующих версий. Опять же, здравый подход - считать, что любое изменение, даже одна строка кода, добавит два дня к дате релиза.
  
 
== Безопасный двухдневный промежуток ==
 
== Безопасный двухдневный промежуток ==
  
Когда исправлены все ошибки, которые будут исправляться в этой версии, а все оставшееся отложено, -- это еще не конец работы. Нужно выждать еще как минимум 48 часов, в течение которых вы должны плейтестировать игру как сумасшедший. Попытайтесь, чтобы все играли в игру столько времени, сколько могут. Если найдете еще баги, которые нужно исправить, исправьте их и начните 48 часов заново.
+
Когда все запланированные ошибки исправлены,а все остальное было отложено, это еще не конец. Теперь подождите 48 часов, в течении которых вы должны проводить игровые тестировании как сумасшедшие. Постарайтесь, чтобы все играли в игру столько времени, сколько могут. Если нашли еще ошибки, которые могут быть исправлены, исправьте их, и начните 48 часовой процесс снова.  
  
Если ваш мод прошел 48 часов тяжелого плейтестирования, и не обнаружилось новых проблем, вы готовы выпускать его!
+
Если в течении 48 часового игрового тестирования не было найдено никаких новых ошибок, вы готовы к релизу!
  
== После релиза ==
+
== Пост-Релиз ==
И так, мод вышел, игрокам он очень нравится, а на сайтах пишут, как увлекательно в него играть. Закончена ли ваша работа теперь - решать вам. Наш опыт на ниве мультиплеера показывает, что мод остается популярен пока он поддерживается разработчиками. Неважно какой он замечательный, он не соберет какого-то заметного числа игроков в первой версии. Количество игроков растет со временем, когда вы регулярно выпускаете новый контент, правите ошибки и, разумеется, поддерживаете коммьюнити. И Counter-Strike, и Team Fortress начинали маленькими и выросли со временем. Каждый раз с выпуском новой версии, все больше игроков пробовали их и начинали в них играть.
+
И так, мод вышел, игрокам он очень нравится, а на сайтах пишут, как увлекательно в него играть. Закончена ли ваша работа теперь - решать вам. Из нашего опыта в области онлайн-игр, мод остается популярен, только когда вы его поддерживаете. Не важно, насколько хорош ваш мод, он не соберет какого-то заметного числа игроков в первой версии. Количество игроков будет увеличиваться посредством выпуска нового контента, исправления ошибок, и, конечно, поддерживаемого сообщества. Counter-Strike и Team Fortress начали с самого малого и росли каждый день. С каждой новой версией все больше игроков начинали в них играть.
  
Знание того, что нужно исправить, что нужно изменить и как прислушиваться к коммьюнити, приходит с опытом, в процессе продолжительного самообучения.
+
Знание что исправлять, что изменить, и как прислушиваться к сообществу приходит с опытом, в процессе продолжительного самообучения.  
  
 
Удачи!
 
Удачи!
  
== См.также ==
+
== См. также ==
* [[Shipping Leader In Detail|Подробности о работе Ship Leader'а]]
+
* [[Shipping Leader In Detail:ru|Работа Shipping Leader'а в подробностях]]
* [[Mod Packing & Shipping|Запаковка и выпуск мода]]
+
* [[Mod Distribution:ru|Запаковка & Выпуск Мода]]
* [[:Category:Modding|Категория:Создание модификаций]]
+
* [[:Category:Modding:ru|Категория:Моддинг]]
 
   
 
   
{{otherlang:ru}}
+
[[Category:Modding:ru]]
{{otherlang:ru:en|Making a Mod}},{{otherlang:ru:fr|Making a Mod:fr}}
+
[[Category:Russian]]

Latest revision as of 17:00, 3 December 2016

English Deutsch Español Français

Эта статья призвана помочь вам сделать Source Engine модификацию, или мод. Сперва рассматриваются советы по началу разработки и набору команды. Далее - советы касательно игрового дизайна. В завершении предоставлено пошаговое руководство по организации финальных изменений и релиза вашего мода, что является самой трудной частью.

Старт

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

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

Дизайн мода

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

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

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

Выпускайте скорее! Выпускайте чаще!

Вы имеете огромное преимущество над коммерческими разработчиками. Вы можете выпускать обновления гораздо чаще, быстрее и больше, чем они. Мы совместили эту философию разработки мода в одну фразу - "Release soon, Release often." Коммерческие разработчики работают 2-3 года, чтобы выпустить их игру, и надеются на бога, чтобы людям она понравилась. Вам не нужно верить. Вы можете разработать идею мода, сделать 25% от всего, затем предоставить результат игровому сообществу, и они сразу же свяжутся с вами. После этого вы можете добавлять остальной контент по частям, в это же время получая мнения о первой версии, и продолжать выпускать новые версии каждые один-два месяца. Вы всегда находитесь на связи со своими игроками, так что вы не попадете в ситуацию, когда вы потратили много времени на то, что игрокам может не понравится. Весь фокус в том, чтобы уменьшить количество недочетов в финальной версии. Первоначальная версия должна быть веселой и играбильной, но не содержащей попытки реализовать все придуманные вами функции.

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

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

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

Реальные цели

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

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

Понимание движка

Вы действительно должны прочитать документацию, включенную в SDK. Вы должны не просто понимать как делаются вещи в движке, но и как сделать их правильно. Вы можете сделать оружие, стреляющее 50 ракетами, но если вы не понимаете, как работает движок, то можете сделать это таким образом, что мод будет использовать большое количество сетевого трафика. Это важно для каждой модификации. Если создатели карт не понимают движок, они будут делать огромные карты, не задумываясь о том, сколько данных будет посылаться пользователям, играющим в нее, и каждый будет винить ваш код за слишком интенсивное использование сети. Если вы программист, хорошей идеей будет присоединится к рассылке списка HL Кодеров, где вы сможете поговорить с многими другими программистами, а так же с некоторыми сотрудниками 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). Вся выходящая информация в сервере будет записываться в файл в директорию gamedir/logs (Имя файла будет совпадать с датой). Всякий раз, когда игрок замечает ошибку, пусть он использует кнопку "say" чтобы сказать "BUG: описание бага". Затем, когда игра закончится, вы можете открыть лог файл и посмотреть все сообщения о багах, использовав поиск по слову "BUG:".

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

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

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

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

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

Вырезание или откладывание особенностей

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

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

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

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

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

Три недели до релиза

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

К этому моменту нужно стремиться к завершенности контента. Это означает, что весь контент игры, кроме игрового кода заморожен. Все карты, модели, текстуры, звуки, HUD арт, Launcher арт и т.д. должны быть завершены и находится в копии у SL.

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

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

Игровое Тестирование

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

Одна неделя до выхода

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

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

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

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

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

Пост-Релиз

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

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

Удачи!

См. также