Эта статья довольно объёмная, так что я пытался немного разнообразить сухое изложение. Составляя не "очередной сборник поучений", а нечто более интересное для усвоения, мне хотелось показать взгляд с точки зрения игрока и здравого смысла.
Основной упор сделан на подводные камни модостроения: разные проблемы, которые порой даже неочевидны до момента практики. Материал также будет полезен, если неизвестно, с какой стороны подступиться к работе и чем вообще заняться в данный момент, если хочется взглянуть на собственный мод со стороны, если работа застопорилась из-за какой-нибудь проблемы или выбора.
Может быть, кому-то не хватает фантазии, рисуя карту на бумаге. Кто-то выдумал интересную "фишку", но не знает, как ввести её в игру (любую идею надо адаптировать к реальности). А у кого-то творческий процесс зашёл в тупик, вызывая сомнения насчёт дальнейшей работы.
Во избежание множества претензий, окончательное решение - делать так или иначе - возлагается на читателя.

На основе комментариев Valve, моего личного опыта и впечатлений от игры выделена система из методов работы и неписаных правил. Хотя в большинстве случаев это просто набор фактов и приёмов - чтобы они всегда были перед глазами. И даже не пытайтесь учитывать всё, что так красочно здесь расписано. Элементарно не хватит времени (в разумных пределах). Ведь и коммерческие проекты обладают недостатками, поэтому дотошным "вылизыванием" игры не нужно злоупотреблять.
У меня также есть основательные подозрения, что все приведённые тут советы вместе составят "неудобоваримый коктейль". Поэтому Вам лучше прислушаться к собственному мнению: кое-что игнорировать, а с чем-то соглашаться.

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


Работая над игрой за компьютером, сначала удобно строить геометрию уровня (черновой вариант), отлаживать скрипты и гораздо позже - углубляться в дизайн. Однако, планируя мод на бумаге, приходится делать всё сразу. Хотя здесь проще: трудозатраты ниже и рисовать куда легче, чем в редакторе Hammer или в XSI Mod Tool. В крайнем случае, можно перечеркнуть работу, смять и выкинуть, а затем вновь начать с чистого листа.
Как можно больше деталей желательно рисовать и расписывать заранее (до начала основной работы). Когда наброски местности, персонажей, оружия, устройств, игрового процесса, образцы звуков запечатлены не в уме, а материально - будет больше уверенности в работе, поскольку всегда наготове есть элементы, которые требуются в конкретном месте.
Подробнее о подготовке, рабочем процессе, а также о методах исправления сделанного (если уж так получилось, что надо исправлять) и пойдет речь ниже.


И последнее, что хочется сказать перед началом основной статьи: конечно, изложенный материал рассчитан на создание модификаций под Source (Half-Life 2: Episode Two); учитывается множество особенностей именно этого движка. Тем не менее, любой разработчик 3D-шутера может найти здесь что-нибудь полезное. По моему глубокому убеждению, в серии Half-Life присутствует самая удобная организация игрового мира для жанра "3D-шутер". А более простое управление встречалось мне разве что в играх серии Quake.

Так что, не проходите мимо: кто знает, что Вы найдёте для себя, уделив немного времени на прочтение? В конце концов, это не толстая книжка с объёмистым оглавлением, а всего лишь большая статья.


Содержание:

• О сюжете
• Блокировка проходов и установка границ
• Скриптование во времени и пространстве
• Передвижение игрока
• Нелинейность сюжета и прохождения
• Соотношение сил
• Состыковка областей игры
• Ярко выраженные недостатки и достоинства мода
• Реализм
• Игровой мир
• Неоправдавшиеся надежды и другие крупные проблемы (последний раздел)
  
  
• Вместо заключения

---

О сюжете

Википедия на этот счёт говорит следующее (15.03.2010г.):

Сюжет (от фр. sujet — предмет) — в литературе, драматургии, кино и играх — порядок событий, происходящих в художественном произведении. Сюжет — основа формы произведения.

И далее:

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

Я попробую изложить понятие сюжета более кратко и чётко, применительно к созданию игры:

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


Примеры:

1. Переделка оригинального Half-Life (или Half-Life 2) под новый движок - странный, но пример.
Сюжет остался абсолютно тем же, изменился только внешний вид. То же самое выйдет, если переделать характеристики NPC, текстуры, эффекты, озвучивание. Почти то же самое будет, если переделать смысл диалогов и отдельных фраз на новый лад, если менять поведение NPC или полностью их заменить на другие.
В итоге получаем абсолютно неприемлемый сюжет. Та же игра "в другом обличье", но ни о каком новом сюжете не может быть и речи. Просто не получится с одним и тем же "видеорядом" или "звукорядом" серьёзно изменить смысл происходящего.
Заключение: приведённые виды "манипуляций" с сюжетом не интересны. Остальных составляющих игры (дизайн, игровой процесс, ещё что-то) мы здесь не касаемся.

2. Абсолютно новая игра на том же движке (как Vampire: The Masquerade - Bloodlines на движке Source).
Сюжет в данном случае несколько ограничен возможностями движка (в частности, жанром игры). И какие-то переделки исходного кода не снимают всех ограничений.
Заключение: весьма и весьма приемлемый сюжет. Принципы игры в этом случае сохраняют некоторую общую основу с оригинальной игрой. Если это удаётся "заретушировать" - будет просто замечательно.

3. Новая игра на собственном движке.
Думаю, здесь рассуждения излишни. Разумеется, речь не идёт о подражании уже существующей игре или заимствовании.
Заключение: почти абсолютно приемлемый сюжет. Некоторым игрокам может не понравиться его суть, отсюда слово "почти".

4. Новая игра с подражанием уже существующей игре. Или сильное заимствование сюжета.
И вновь, рассуждения здесь лишние.
Заключение: почти неприемлемый сюжет. Кому-то, возможно, понравится это "ретро", но не большинству.

5. Модификация на основе оригинальной игры (наш случай).
В принципе, это вариант второго примера. Но ограничение сюжета более сильное, и это видно в большинстве модов: обычно рассказывается история из мира Half-Life со второстепенными героями или событиями. Присутствует заимствование.
Заключение: приемлемый сюжет. Хотя он будет актуальным только для обладателей соответствующей игры из серии Half-Life. А уж интересным - кому как.

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


Если Вы прочтёте статью на Википедии по указанной выше ссылке, то узнаете о составляющих элементах и попытках классификации понятия. А здесь я приведу несколько полезных направлений, которых можно придерживаться в поисках достойного сюжета:

• на основе книги или фильма

  как известно, Half-Life в какой-то мере основан на романе С.Кинга "Мгла", а также явно заимствует идеи "засекреченных лабораторий", "опасных экспериментов", "заговора правительства" и прочие интересные вещи. На момент выхода игры всё это еще не приелось игрокам, да и сейчас вполне можно создать ещё несколько отличных игр на базе данных идей. Если, конечно, тщательно разрабатывать (а не "штамповать") игру.
  Важно помнить, что прямое следование взятому сюжету не обязательно. Это даже не рекомендуется, в частности, из-за проблем в реализации. Лучше уж взять "немного оттуда, немного отсюда" и тщательно, аккуратно скомпоновать в единое целое.

• нераскрытые стороны основного сюжета

  Чтобы там ни говорили, это может быть весьма интересным. Если только не пытаться "выезжать" на деталях основного сюжета и хоть немного следовать логике вселенной основной игры.
  Помнится, одна из модификаций брала за основу карты, вырезанные из конечной игры Half-Life 2. Получилось, в общем-то, неплохо, но дело подпортила слабая проработка сюжета.
  В другой модификации сделана попытка рассказать о событиях после Episode Two. В процессе игры мне показалось, что авторам не хватило фантазии на что-нибудь более интересное. А сама реализация неплохая.
  Напоминаю, что мы говорим только о сюжете, не касаясь прочих особенностей.

• истории других NPC из той же игровой вселенной

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

• альтернативное развитие событий

  Обычно главных героев основного сюжета помещают в такие ситуации, в которые они заведомо не могут попасть. Или описываемый сюжет выглядит довольно сомнительным, мало согласуется с основным.
  Направление хорошее, но нужно чётко представлять себе, какое развитие сюжета Вам нужно. У некоторых "моддеров" это получается...
  Опять же, по моим наблюдениям - в этой категории находится большинство "халтур"; нежелание сделать нормальную игру прикрывается идеей "оригинального сюжета".

• развитие в сюжет интересных моментов

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

• грамотная реализация существующей игры на движке Source

  Если Вам очень нравится некая хорошая игра и хочется сделать модификацию по её мотивам - просто необходимо менять сюжет. Иначе выйдет как в примере №4. То же самое можно сказать, когда некоторые локации, сцены, персонажи, оружие делаются на основе существующих игр, фильмов или книг. Пусть отличается хотя бы сюжет или часть его.
  Постарайтесь вообще изменить "глобальные вехи" сюжета и обязательно сделайте другую (и приемлемую) концовку. При этом можно беззастенчиво заимствовать моменты "геймплея" или дизайна, добавляя какие-нибудь свои идеи (действуя наподобие предыдущего пункта).

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


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

• локация, NPC, задача или часть "геймплея", которые не вписываются в общую картину игры и при этом остаются без объяснений.
  Это всё равно, что в какой-нибудь "мрачной" игре (обойдёмся без конкретики) поставить игровой автомат с Тетрисом - "чисто поиграть". Я не спорю: оригинально, "игра в игре" и всё такое прочее... но, допустим, случится подобная ситуация в реальности, разве кто-нибудь остановится возле него? Наверное, только в том случае, если игровой автомат находится в безопасном убежище...
  С другой стороны, есть немало случаев намеренного контраста, своеобразного "подслащения блюда" (Duke Nukem, Bioshock, StarCraft 2). Но при этом игроку и не дают много свободы в этом - только ради атмосферы. Так что, подобные детали как-раз и соответствуют общему впечатлению.
  Вывод: постарайтесь не отвлекать игрока бездумными, "взятыми с потолка" обстоятельствами "ни к селу, ни к городу".
  
  
• игрока подталкивают к действию, но тот никак не может преодолеть некое препятствие, мешающее ему действовать дальше.
  К примеру, надо перебраться через пропасть, чтобы избежать надвигающейся опасности и догнать "своих". А расстояние, которое нужно перепрыгнуть, едва-едва охватывается самым длинным прыжком. Причём, "свои" постоянно зовут игрока, а сзади раздаются предостерегающие звуки. В результате, мало того, что игрок "на взводе", так он ещё отчаянно ругается, в n-ый раз перезагружая карту после того, как сорвался вниз.
  Или такой случай: на HUD-экране настойчиво маячит "срочное задание" (типа: найди проход, отбей атаку и т.п.), а игрок никак не может привыкнуть к особенностям изменённого управления (какие кнопки на клавиатуре нажимать, в каком порядке) или попросту не видит цели (допустим, она нарисована очень небрежно, или поставленна двусмысленно). А если ещё кто-то атакует, получается сплошное безобразие - "тыканье туда-сюда" в поисках решения. Обычно, игрок начинает тупо перебирать возможные действия, т.е. "теряет нить сюжета".
  Таким образом, если некоторое препятствие в процессе тестирования мода вдруг показалось Вам (как разработчику) несколько сложнее ожидаемого, попробуйте как-то заострить на нём внимание игрока. Другими словами, намекать игроку на решение, хотя бы на то, что оно существует в каком-то конкретном виде.
  Для указанных примеров это могут быть: 1) - крики NPC о том, что пропасть широкая, и нужно "брать выше, прыгать дальше"; 2) - указания типа "вход скорее всего замаскирован", разъяснение закономерности нажатия кнопок.
  
  Важное замечание: указания по решению должны быть такими, чтобы игрок хоть как-то связал их со своей задачей. На практике можно обойтись и туманными намёками - лишь бы они были правильно поняты.
  И, кстати говоря, сразу подсказывать не обязательно. Если получится достоверно определять, что игрок "в тупике" - введите подсказку только при выполнении данного условия.
  
  
• однообразие игровых ситуаций - вполне способно отвлечь внимание игрока, который вместо того, чтобы внимать сюжету, будет отвлекаться на второстепенные цели.
  Например, добавив по пути следования игрока множество тайников (вентиляции, за коробками и т.п.), можно "переборщить" с их количеством. В результате игрок начнёт старательно исследовать все подозрительные места, невольно втягиваясь в достаточно скучный процесс второстепенного (по сравнению с сюжетом) значения.
  Злоупотребление "респауном" врагов (когда они бесконечно создаются посредством энтити npc_*maker) также весьма неприятный процесс, который очень плохо сочетается с восприятием сюжета.
  Сомнительное удовольствие от игры даёт и специально вводимая система зарабатывания достижений (якобы для повышения реиграбельности). Может быть эту систему нужно включать (открывать её присутствие для игрока) лишь на втором и следующих прохождениях? В таком случае лучшим решением будет засчитывать достижения сразу, а показывать их только после первого завершения игры.
  Постарайтесь вообще разнообразить игру: она не станет интересной чисто из-за сюжетной линии, но с однообразными действиями. Зацикливание на действиях и приёмах легко реализуемо, но весьма негативно отражается на сюжете.
  
  

---

Блокировка проходов и установка границ

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

Собственно, геометрия карты и определяет границы пространства, которое доступно игроку. А отдельные места - ограждения, запертые двери и прочее - это дополнения к архитектуре уровней.
В общем случае преграда будет либо элементом геометрии (стена, поворот улицы, глубокий овраг, отвесная скала и т.п.), либо элементом дизайна (защитное поле, запертая дверь, завал, обстреливаемый участок и т.п.). То есть, налицо всего два основных принципа ограничения игрового мира. Первый даёт настолько естественные результаты, что они вообще не воспринимаются как преграда; однако эти варианты могут быть только статическими (узкая вьющаяся дорога перед гостиницей в Episode Two). Второй принцип удобен в реализации, т.к. не надо глобально переделывать карту, но результаты не обязательно будут естественными (свалка автомобилей под обстрелом ионных пушек в Episode Two).
Ещё возможны нестандартные способы ограничения, о них будет упомянуто далее.

Вообще, игрокам нравится проникать за допустимые пределы игрового мира, чтобы увидеть так называемое "зазеркалье", обратную сторону декораций (например, см. здесь, здесь и здесь). Нередки и чисто человеческие казусы, если игрок не понимает, что перед ним "закрытая зона", или не знает, куда толком идти (к примеру, побережье вообще или вблизи Нова Проспект - при самом первом прохождении Half-Life 2).
И это "ошибки" самой Valve! Что же говорить о любительских модах, которые, за редким исключением, проходятся один раз…

Есть универсальный метод ограничения пространства: для игрока это браш с текстурой tools/toolsplayerclip, для NPC это tools/toolsnpcclip, общий - tools/toolsclip. Но результат выглядит нелепо: проход закрывает невидимая стенка, хотя впереди свободное пространство. Следовательно, проблему надо решать творчески.
Ниже приведены сгруппированные по принципу действия варианты преград с описанием типичных ошибок. Рекомендуется учитывать приведённые недостатки, чтобы результат выглядел аккуратно и естественно.

• явно тупиковые преграды

  всё, что угодно, что "не перепрыгивается и не проходится". Обычно выбирают объекты, напоминающие барьеры (или являющиеся таковыми) и загораживающие обзор. Это может быть браш (простейший вариант), крутой displacement, более-менее сплошная статическая модель.
  Примеры: баррикады Альянса, стены домов, ограды и сплошные заборы, заблокированная неразрушимая и непрозрачная дверь, скалы и прочие тупики.
  Недостатки:
  - поскольку обычно делать статическую преграду легче всего, есть соблазн повсюду "городить одну и ту же стенку", что выглядит очень небрежно. Следует хорошо постараться, выдерживая аккуратный стиль и изобретая всё новые и новые варианты для разнообразия;
  - преграда не должна быть в виде простой "затычки", её надо сделать более-менее детализованной, вписать в атмосферу игры. Это отнимает больше времени;
  - модель-преграда может быть разрушаемой или проходимой; и хорошо, если это выяснится на этапе тестирования;
  - иногда, в сложной ситуации с ИИ либо скриптом, NPC может разрушить энтити-модель, даже если она сделана неразрушимой путём установки соответствующих атрибутов.

  
  
• смертельные преграды

  обрыв, смертоносное излучение в виде стены (поле) или частой решётки (лучи), радиация, оружие заграждения, ядовитая жидкость.
  Недостатки: аналогично - преграда не должна выглядеть примитивно; улучшение внешнего вида требует времени. Часто бывает необходимо выдумывать местность "по ту сторону" (см. далее - нестандартные методы).
  Также, можно не рассчитать размеры и другие условия преграды, которая не всегда очевидна, и в результате возможно следующее:
  - игрок случайно преодолеет заграждение (построит "мост", урон окажется недостаточным и т.п.);
  - опасная область "просочится" туда, где её не должно быть, а игрок "напорется" на эту преграду и погибнет.

  
  
• загромождение прохода

  обычно это группа плотно расположенных моделей деревьев, машин и других статических или тяжёлых объектов, завалы из обломков или мусора.
  Недостатки: скопление высокодетализованных моделей может значительно нагрузить видеокарту или процессор, снижая плавность игрового процесса; во многих случаях игрок теоретически может расчистить "проход" с помощью взрывов или гравипушки, забраться "на гору по ступенькам". Последние варианты можно отнести к преодолеваемым преградам, если они предусмотрены по ходу игры, но только преодоление завала не должно растягиваться на несколько часов.

  
  
• преодолеваемые преграды

  похожи на предыдущие, только преграда должна быть в виде энтити с заданным именем (параметр Name), чтобы её впоследствии можно было убрать. Обратный случай - скрытая (изменённая) как угодно энтити, которая впоследствии появляется (меняется), открывая новый путь. Дело осложняется тем, что надо придумывать схему отключения преграды или добавления прохода.
  Ещё сюда относятся такие статические преграды, которые игрок может преодолеть на транспортном средстве (например, перепрыгнуть овраг, проехать по ядовитым отходам), но не сможет обойти пешком. Разумеется, возможны обратные варианты, когда преграда существенна только для транспортного средства (а не для идущего пешком игрока).
  Недостатки: все те же. Как было сказано, при наличии транспортного средства отдельные преграды теряют смысл и всего лишь ограничивают свободу действий (см. раздел Передвижение игрока). К тому же, надо учитывать случаи, когда транспортное средство попадает за границы допустимого прохода (не стоит поощрять загрузку предыдущего состояния игры).

  
  
• нестандартные методы

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

  1. очень запутанная структура карты (возможно даже замкнутая геометрия), так что игрок и не замечает ограничений
     Недостатки: сделать это довольно сложно, а игрок всё-таки может обнаружить подвох или заступить границу.
     
     
  2. замкнутая с помощью телепортов карта
     Недостатки: слишком экзотический и неестественный метод; надо каким-то образом скрывать процесс телепортации, чтобы картинка в игре "не дёргалась".
     
     
  3. видимое, но недостижимое пространство (более развитый дизайн, нежели для смертельной преграды)
     Примеры: узкое окно или лаз, обычная решётка, непробиваемое стекло, проход в недоступном месте, поле Альянса, за которыми игрок может разглядывать нечто, похожее на продолжение карты. Однако проникнуть туда он никак не сможет (так как перед ним всего лишь замаскированный тупик).
     Недостатки: это бывает похоже на примитивную преграду и потому легко узнаваемо (например, если это поле Альянса, надо хотя бы добавить стойки-генераторы по краям для маскировки эффекта стенки). "Недоступное место" может оказаться достижимым, если игрок увлечётся поиском пути к нему. Заведомо недоступный участок карты с "приманкой" (аптечками, патронами, оружием и пр.) оставляет неприятное воспоминание.
     
     
  4. сцена с битвой, в которой игроку не имеет смысла участвовать (или пытаться пересечь)
     Примеры: если игрок безоружен, можно загородить ему путь битвой Альянса и зомби - т.е. разделавшись с противником, та или иная сторона займётся игроком; сделать явное теснение дружественных NPC силами противника, призывы уходить; либо дружественные NPC с лёгкостью противостоят враждебным и "просят не мешать им".
     Недостатки: здесь тоже есть видимое, но недоступное место; дополнительное время на продумывание сцены; недостаточно убедительная реализация вызовет противоположный эффект (не забудьте запретить выброс оружия погибшими NPC, если не хотите вооружать игрока).
     
     
  5. NPC, не пропускающие игрока
     Примеры: пост охраны, оцепление, та самая закрытая зона, частные владения, т.е. "сторож" любого рода.
     Недостатки: видимое и недоступное место также присутствует. Скрипты NPC должны быть убедительными (как, например, у охраны в начале Half-Life 2, сделанные с помощью ai_goal_police). Здесь всё может получиться с первого раза, а может уйти много времени на тщательную доводку сцены.
     
     
  6. привязка действия к объекту
     Примеры: прохождение гостиницы на пути к Белой Роще (Episode Two), атака на Цитадель, проникновение на территорию завода, охрана здания или поезда, пересечение местности на время и т.п.
     Игрок вроде бы может пойти, куда ему хочется, но тогда вероятно он провалит задание. А практически, попытки выйти "за границы дозволенного" упираются в ограничения местности.
     Недостатки: видимое и недоступное место снова присутствует, осложнённое небольшими доступными ответвлениями (чтобы сохранить иллюзию большого пространства). Необходимо также ограничить место действия, но существенно отдалить эти границы или хорошо их замаскировать.

Естественный вывод: "дизайнерский" или просто ненадёжный барьер дублируется брашем с текстурой tools/tools*clip - для гарантии, что игрок ни в коем случае "не прорвётся".
Кстати, у clip-текстур есть полезное свойство - игрок и NPC могут ходить по ним, что с успехом кое-где использует Valve.
Для смертельных преград можно использовать брашевый trigger_hurt в качестве ограничителя, присвоив его параметру урона Damage большое значение (также для гарантии непреодолимости).

Примечание: если есть подозрение, либо выяснилось при тестировании, что игрок всерьёз увлекается преодолением преграды, её смысл лучше делать очевидным (т.е. всё-таки поставить явную "затычку"). Также, хорошие результаты получаются при смешивании некоторых типов. К примеру, коридор, набитый прыгающими минами-хопперами - без гравипушки нереально одолеть в одиночку, игрок это поймёт.
Хотя интересный вариант получится, если оставить для игрока возможность преодолеть заграждение (вот будет радости любителю!). Пример можно найти в Half-Life 2 перед началом главы Восточная Чёрная Меза.

Возможно, кто-то интересуется, почему такое внимание уделено "видимому, но недоступному пространству" и подобным деталям. Тогда обратите внимание на непреложную истину: Вам придётся рисовать всё, что только может увидеть игрок. А это дополнительные затраты времени и сил.
Ещё полезно "оживлять" видимые участки скриптами, звуками. Что приводит к тем же затратам.

---

Скриптование во времени и пространстве

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

Сильная привязка скриптов к местоположению и выполняемым действиям "убивает" интерес к игре. Идеальная подгонка места и времени действия теряет свою значимость, поскольку игра больше напоминает просмотр фильма. Смириться с этим помогает лишь очень хороший сюжет.
Абсолютно произвольное срабатывание скриптов часто создаёт опасную ситуацию, особенно когда не учитывается показатель здоровья игрока. Ещё это выглядит несуразно, если наблюдаются паузы вперемешку с кучей выполняемых скриптов или нестыковки действия.
"Невидимые правила" приводят к случаям непредусмотренного отключения скриптов, что особенно критично, если эти самые скрипты позволяют игроку идти дальше.

Примеры: ракета с головокрабами вполне может попасть в игрока, если тот окажется в точке падения раньше или позже "назначенного" времени; атмосфера игры также страдает, если противник появляется "строго по расписанию" или не раньше, чем игрок выполнит набор действий (хотя изредка бывает наоборот); игрок может случайно разбить прибор, которым должны починить его машину, и сцена ремонта не включится - игра "застрянет" на месте; конкретно, в Episode Two страйдер может выстрелить по зданию, когда игрок находится рядом или внутри - с летальным исходом.


Есть разные способы не отклоняться сильно ни в ту, ни в другую сторону:

• автосохранение рядом с потенциально опасной зоной, а также в "точках безопасности" внутри этой зоны. По-видимому, Valve сделала автосохранение более "умным" именно с этой целью - сейчас (09.07.2009г.) есть целых три энтити: logic_autosave, logic_active_autosave и брашевая trigger_autosave;
  
• реакция скриптов на мастерство игрока - это очень сложно реализовать, но возможно;
  
• многоразовая проверка работы скриптов с моделированием различных условий по снаряжению, защите и поведению игрока. Необходимо обеспечить достаточный "запас надёжности" для каждого случая. Метод трудоёмкий, но зато самый лучший;
  
• выбор случайного скрипта из группы (делается через logic_case). То есть вместо одного конкретного действия происходит одно случайное, хотя и выбранное из конкретной группы;
  
• привязка места действия скрипта к энтити func_tracktrain, которая движется по некоторому маршруту (из path_track-ов) - возможна не всегда. В качестве альтернативы можно дублировать скрипт в разных точках, используя затем logic_case;
  
• варьирование пауз между срабатыванием скриптов (делается через logic_timer). Тут главное - чтобы скрипты не "наползали" друг на друга по времени, либо делали это в разумных пределах;
  
• постепенный переход от строгого порядка к произвольному. Чем легче и охотнее игрок воспринимает его, тем лучше;
  
• дополнительные возможности выживания (аптечки и батарейки, укромные места, мёртвые зоны ловушек, участки с возможностью "постоять и подумать" и т.п.). Это универсальный метод - спасает даже в случае непредусмотренных ситуаций. Но необходима проверка: а действительно ли это место - "укромное", зона ловушки - "мёртвая", действительно ли игрок замечает аптечки и патроны и т.д.;
  
• случайными сделать только безопасные и отвлекающие события. Сохраняется атмосфера игры, тестирование отнимает меньше времени. Получается своеобразная маскировка выдержанного порядка запускаемых скриптов;
  
• искать оптимальные варианты, создавая каждую сцену/действие из минимального набора скриптов, либо управление скриптами должно быть простым и очевидным. Таким образом легче ввести случайность. Здесь разве что много времени уйдёт на исследования скриптов и их комбинаций (с целью оптимизации выполнения);
  
• блокировать одни скрипты во время срабатывания других, в идеале - объединяя их в группы, которые "не мешают" одна другой. Упрощённый вариант - энтити logic_relay, сделанная по принципу "одна команда - несколько действий";
  
• скрипты, идущие один за другим, "связывать цепочкой". То есть запускать следующий скрипт на основании состояния предыдущего (например, по окончании). Это намного лучше, чем отмерять интервалы времени из одной управляющей энтити (той же logic_relay). Синхронизация действий будет просто идеальной. Недостатки метода - далеко не каждая энтити поддаётся такому управлению (например, ambient_generic не генерирует событие типа OnEndPlaying) и не всегда удобно рассредоточивать события (Outputs) по разным энтити;
  
• вариации скриптов делать как можно разнообразнее, по возможности, избегая ситуации "шило на мыло". Например, не просто менять количество противника, а ещё сделать разным его появление (с другой стороны, через двери/окна, с проломом стены т.д.), менять тип NPC и т.п. Конечно, если объём работ выходит чересчур большой, можно отделаться простыми вариантами;
  
• даже строго назначенные действия можно привязывать к неочевидным условиям. Пока игрок не поймёт закономерности происходящего, для него эти скрипты будут выглядеть как случайные.
  

---

Передвижение игрока

Как известно, в рамках стандартного арсенала возможны следующие варианты:

- по суше: пешком, на автомобиле, на катере;
- по воде (и другой жидкости): вплавь, на катере;
- особые: прыжки по "уступам", прыжки по "островкам", движение в неконтролируемом транспорте;

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


Особенности "геймплея" при движении:

1. пешком

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

   
   
Примечание: абсолютно недвусмысленный показатель "скучного" участка дороги - когда игрок начинает двигаться с режимом ускорения или шагом с прыжками, вместо того, чтобы идти нормальным шагом (как задумано по сюжету).



2. на автомобиле

   высокая скорость. Дорогу необходимо делать по возможности длинной, чтобы игрок "чувствовал, что он едет". Зато большое и частое разнообразие не критично, наоборот, желательно не отвлекать игрока кучей "фальшстопов". Лучше подкинуть ему NPC-"кегли", преследователей, заградотряды и ещё что-нибудь подходящее к случаю. Остановки на дороге - по сюжету, по развитию действия, для сбора припасов.
   Препятствием на пути будет слишком узкая дорога, тупик, обрыв или глубокий уровень воды; а если надо, чтобы игрок и дальше ехал на машине, придётся решать вопрос о "переброске транспорта на ту сторону" (как подъёмный кран в Half-Life 2). Можно и так: поставить ещё один автомобиль по другую сторону препятствия, но это неоригинально. В случае возможной переправы необходимо удостовериться, что игрок действительно ищет путь, а не бросает транспорт и идёт пешком.
   Не забывайте, что по умолчанию (если не вмешиваться в код) автомобиль-багги неустойчив и может перевернуться во время "крутого трюка". Если у игрока нет гравипушки, придётся решать и этот вопрос.
   Врагов можно сбивать корпусом автомобиля, либо (в большинстве случаев) выйти из машины и далее как в п.1.

   
   
3. на катере

   высокая скорость плюс абсолютная устойчивость к переворотам (опять же по умолчанию) плюс свободное движение по любой жидкости. Продолжительность пути и разнообразие - аналогично предыдущему. Остановки на дороге - по тем же причинам.
   Препятствием будет тупик, обрыв или узкий участок. Аналогично, для продолжения поездки нужно выдумывать, как переправить катер через преграду. И так же необходимо убедить игрока, что далее пока ещё рано идти пешком.
   Врагов можно сбивать корпусом катера, вылезти из него получится не всякий раз (т.к. передвижение будет скорее по той или иной жидкости).

   
   
Замечание: сделать оригинальный способ переправы через преграду нелегко, однако здесь прямая зависимость с интересом от игры.

Замечание: автомобиль или катер может застрять в "физической ловушке" на сложном участке карты, и тогда игроку останется лишь загрузить сохранённую ранее игру (гравипушка выручает не всегда). В крайнем случае, можно расставить на дороге триггеры автосохранения вблизи потенциальных "ловушек".

Примечание: в большинстве случаев данные три способа передвижения позволяют игроку любоваться пейзажами и вообще архитектурой уровня. Определите, куда смотрит игрок большую часть времени, и можете рисовать в той стороне великолепные картины природы (или что там ещё). Конечно, не забудьте и про остальную часть карты.



4. вплавь

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

   
   
5. прыжки

   скорость обычно минимальна, т.к. приходится рассчитывать место приземления. Путь должен быть коротким по времени. Конечно, если мод ориентирован на подобные "трюки" - ничего не поделаешь, но в общем случае для игрока в 3D-шутер прыгать несколько утомительно. Если нет интересных причин двигаться прыжками, это сильно надоедает.
   Врагов убиваем также, как и в п.1.
   Игрок максимально уязвим в большинстве случаев.

   
   
6. неконтролируемый транспорт

   "неконтролируемый" означает частичное или полное неподчинение попыткам изменить направление.
   Игрок обычно либо стоит, либо передвигается как угодно в пределах этого транспорта (основную часть времени). То есть происходит "движение в движении". В этом случае всё зависит от предполагаемого поведения игрока. Если это движение в лифте с ожиданием места назначения - путь должен быть коротким по времени. А если игрок во время поездки может исследовать внешнюю среду или пространство транспорта - путь можно делать сколь угодно долгим, учитывая, как быстро игроку наскучит подобное занятие.
   Препятствия, в общем случае, построены по типам 1-5, поскольку можно сделать как обычный лифт, так и плавучий остров.
   Соответственно, аналогично противодействие врагам. В случае простого лифта можно делать это любыми возможными способами, а усложнение пространства в пределах транспорта накладывает свои ограничения.
   Уязвимость игрока зависит от того, насколько транспорт защищает его от внешней среды, возможно ли проникновение извне, будет ли противник уже присутствовать в транспорте. В общем случае, больший размер или большая защищённость транспорта положительно влияют на выживаемость игрока.
   
   В зависимости от условий, данный способ может стать идеальным для демонстрации игроку красот архитектуры, дизайна и скриптов (вспомните начало Half-Life). Так что совет относительно первых трёх пунктов уместен и в данном случае.

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


В дополнение, рассмотрим кратко тему - направление игрока в нужную сторону.
Я надеюсь, в изложенном выше, а также при чтении раздела про установку границ, отчётливо проступает главная проблема: как же объяснять игроку, куда ему идти? И каким образом сделать этот процесс увлекательным? Блокирование путей - тоже не панацея. Рано или поздно это надоест уже дизайнеру карты.

Если позволяет время и другие ресурсы - можно немного "отступить от стандартов". А именно, добавлять указатели и "запрещающие знаки", вроде следующих:
- особый знак на стене, который понятен игроку ("лямбда" в кружке, череп со скрещёнными костями, силуэты комбайнов и т.п.);
- NPC, словами или жестами указывающие направление ("Сюда!", "Быстрее в подвал...", "На помощь!" и т.п.);
- какие-либо "заманчивые" объекты или явления (тайник с припасами в вентиляции, "светлячок" и т.п.)

---

Нелинейность сюжета и прохождения

Это весьма злободневная тема, хотя, как по мне - ещё не хватает игр с достаточно линейным сюжетом, чтобы думать о нелинейности. Я, конечно, приветствую сюжетные развилки, только один вопрос: преследуют ли они какую-нибудь другую цель, кроме намёка на многократное прохождение? А ведь редкая игра остаётся интересной для вторичного прохождения...

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

Крайних степеней и того, и другого в игре не может быть, хотя бы из следующих соображений:
Максимум линейности - по сути, просмотр "классического" неинтерактивного фильма (в будущем фильмы станут другими?). Невозможно ни малейшего отклонения (поворота/шага/действия) от заранее расписанного порядка. Это уже не игра.
Максимум нелинейности - когда буквально каждый шаг вызывает своё изменение в окружающем мире, причём возможны одновременно сколько угодно действий и вариантов решения любой задачи. Такое достижимо (?) только в реальной жизни.

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

Любой 3D-шутер не линеен уже в силу того, что игроку дана некоторая свобода отклонения от сюжетного пути и действия. А то, что на практике она сводится всего лишь к "прохождению коридора по разным кривым", "отстрелу друзей" и "осмотру достопримечательностей под аккомпанемент диалогов NPC" - другой вопрос.
Так что линейность прохождения или сюжета - вещь относительная. И правильнее наверно будет говорить, что "игра не обладает достаточной нелинейностью".


Замечание: если игра делается сильно нелинейной по сюжету и прохождению, интерес можно поддерживать невероятным разнообразием окружающего мира (что невероятно трудно сделать), который можно исследовать, варьируя свои действия чуть ли не до бесконечности. Либо используется некий "скелет" миссий (возможно, случайно выбранных).

Пример - известная в прошлом игра Elite, в которой на космическом корабле игрок летает от планеты к планете, воюя и торгуя, а изредка ему подкидывают строго упорядоченные миссии. В игре есть какое-то количество способов времяпровождения, одно "но": их слишком мало для разнообразия. Ко времени этак двухсотого перелёта к очередной звёздной системе игрок хорошо исследует границы, в которых держится его мнимая свобода. Что из этого следует, понятно…
Другой пример - игра Spore. Она "страдает той же болезнью" - недостаточно разнообразия. Способов развлечения немало, гораздо больше вариантов, которые можно комбинировать. Но множество деталей ещё не означает глубокое и развитое взаимодействие (на мой взгляд, игра слишком поверхностно затрагивает, в общем-то, интересные темы). Хотя Spore гораздо увлекательнее, чем упомянутая Elite (даже не сравнивая графику).
Конечно, это уже не жанр "3D-шутер", однако примеры дают хорошее представление о практической нелинейности.


Но трудности реализации - половина проблемы (не говоря уже о том, что для каждого ветвления нужно делать заново существенную часть игры). Думаю, большинство игроков сталкивалось с выбором из двух вариантов. Каким же было первое ощущение? Наверняка ведь, такое: "идя по этому пути, я точно пропущу что-нибудь интересное, которое есть на другой дороге"?
Вот где таится "главное зло" нелинейности в 3D-шутерах. Ведь сюжет поторапливает: иди вперёд, у тебя же есть цель! А если я хочу исследовать все варианты прохождения и причём сейчас, в пределах одного сеанса игры? Ответ "пройди игру ещё раз или сохрани/загрузи" меня не устраивает - это не совсем то…
Помнится, исследуя наземный комплекс в Half-Life (где игрок получает винтовку Гаусса), я переживал, как бы не пропустить комнату или коридор. Потом уж ясно стало - путь через комплекс сделан таким образом, чтобы обойти его целиком.

Итак, что же тут можно предпринять? Не забываем, что первая часть проблемы возникает при самом первом прохождении (когда местность и события воспринимаются как ранее неизвестные); вторая часть проблемы актуальна только для последующих прохождений (когда уже просто не так интересно идти "по второму кругу"):

• соединять три пути по принципу "туда - обратно - снова туда" или делать своеобразные "петли"? Занятно, но смахивает на перебор (хотя упомянутый наземный комплекс демонстрирует нечто похожее);
• сделать так, чтобы два разных пути пересекались в некоторых точках? Тоже неплохо, но выходит, что путь то раздваивается, то сходится. И каким же образом игрок догадается, что путей всего 2, а не 3, 4 и больше? Предупредить, что ли?
• сделать переходы между картами в нескольких местах и в разных направлениях? Это и вовсе нехорошо: представьте, что неожиданно начинается загрузка следующей карты - невольно думается: "я же пропустил одно местечко за поворотом!" И если два-три случая простительны, то вся игра - никоим образом;
• показать игроку, что он "ещё вернётся сюда". Весьма неплохо, но этот момент надо хорошо проработать (в Quake 2, например, это показано далеко не убедительно; в Half-Life: Blue Shift - почти идеально);
• делать игру по принципу "зачисти область и иди дальше". То есть игрок перемещается как угодно в пределах одной области, а затем попадает в следующую и так далее. В принципе, тоже хороший метод, однако сюжет всё равно будет развиваться преимущественно линейно. Многие игроки успевают оглядываться на пройденное; заметив подобное развитие действия, они будут ожидать его и далее. И если ожидания оправдаются, легко понять, как это испортит игру;
• внушить игроку, что выбранный им путь - единственный, а на альтернативных путях уже никогда и ничего не произойдёт. То есть, игра для каждого игрока будет своей, неповторимой (хотя бы несколько вариантов разнообразия). Это психологический эффект, взятый из жизни. Было бы интересно посмотреть, кто и каким образом сможет воплотить его в игре...
  Вспоминается прочитанный в детстве рассказ "Космические демоны" Джилиан Рубинстайн, в котором одноимённая игра удаляла себя после собственного "поражения" - забавное решение проблемы; только учтите, что рассказ фантастический сам по себе. Ну, и есть схожий приём из кино: в фильме "Джуманджи" бывшие игроки по завершении игры отказываются когда-либо начинать её снова.
• если варианты прохождения сделаны каждый в своём стиле (например, поездка/прогулка, через тоннель/через лес), неплохо будет показать игроку по кусочку каждого пути (показать в прямом смысле, провести игрока по ним, рассказать на словах, через рисунки и т.п.). В результате игрок выберет наиболее интересный вариант.
  Только не переборщите чрезмерным интересом, чтобы игрок не "маялся" с решением, а уверенно сделал свой выбор.

С другой стороны, сделать малые разветвления нетрудно. Такие развилки существуют в пределах одной карты (от силы двух), выглядят равноценными (должны, по крайней мере) и легко тестируются. Но тогда их можно представить как расширенную в пространстве карту. Это вполне приемлемый способ.
Сюда же включаем игровую сторону дизайна (вспомогательное окружение предоставляет несколько решений задач и даже стилей игры), скрипты (вспомогательные события добавляют случайные "проблемы" и решения). Это можно, в свою очередь, представить как насыщенную дизайном и скриптами карту. Просто замечательный метод повышения интереса к игре, а также дополнительная страховка в случае, когда игрок не догадывается о "правильном" решении какой-либо задачи.
Пример - ситуация с преградой, если не каждый догадывается переправить транспорт на другую сторону. Можно предусмотреть этот вариант и учесть, что оставшуюся часть пути игрок пройдёт пешком. Если говорить о стиле игры, примером будет Bioshock.

Так что, скорее всего, речь идёт не о степени линейности, а о степени проработки игрового мира.
И если уж Valve в чём и виновата здесь, то лишь в чрезмерном упрощении геометрии/дизайна Half-Life 2 и эпизодов - в пользу среднестатистического игрока и его среднестатистического компьютера.

Пример: мне жаль, что я увидел первоначальный вариант битвы в Белой Роще (фрагмент видео до выхода Episode Two), когда наравне со страйдерами и охотниками в бою участвовали солдаты и штурмовики, повстанцев было больше - вообще, всё напоминало сражение со страйдерами из Half-Life 2 вблизи статуи лошади. Тогда, в ролике, проскакивало нечто похожее на выбор: в какую сторону ехать и кому помогать. А вот играя в финальный вариант, возник справедливый вопрос: "И это всё?"

Хочется отметить, что нелинейность сюжета с одними и теми же "ключевыми точками" производит отрицательное впечатление. Что за смысл проходить игру разными путями, если различие между ними чисто косметическое и явно сделано на скорую руку? Это также сомнительное удовольствие - несколькими путями, без серьёзных изменений действия, всякий раз приходить к одному и тому же финалу


Выходит, что сильная нелинейность 3D-шутеру вредит, а не помогает. Точнее - делает из него другой жанр игры.

Вывод: игра обладает идеальным уровнем нелинейности, если игрок удовлетворён сдерживающими его "рамками", принимает как должное все ограничения игрового мира. Ведь хочется полноты ощущений от игры, когда выбор и последствия выглядят единственно правильными. То есть, игра будет интересной, если каждая линия событий выглядит как единственная. А заранее известное множество альтернатив уж оставьте другим жанрам; по-моему, создатели игр просто неправильно понимают задачи нелинейности, делая все пути известными сразу...


Идеальное решение (как вариант): сделать [псевдо]случайную генерацию уровней и сюжетных линий. Игрок проходит игру по одному сюжету и миру - ему подают другой сюжет и другой мир (в зависимости от окончания предыдущего), и так до бесконечности. Но в настоящее время (2010г.) это едва ли достижимо, при условии, что все эффекты, качество реализации и удовольствие от игры будут соответствовать должному уровню.

Реальный компромисс (как вариант): альтернативные пути сделать неочевидными, чтобы в первый раз игрок прошёл "стандартным" путём, а в N-ый раз - с удивлением обнаружил развилку. Скрывать можно как искусной маскировкой, которую разгадает лишь скучающий фанат (принцип тайников в Quake), как развитием сюжета (Half-Life: Blue Shift, хотя лично я сразу "разломал кирпичи"), так и отслеживанием, сколько раз игрок начинал игру сначала (и постепенной разблокировкой всех альтернативных путей).
Те, кто сыграет не больше одного раза - увидят "правильное" развитие событий. А кому захочется большего, смогут "повлиять" на игровой мир. На мой взгляд, от 3D-шутера большего и не требуется.

Интересный вариант: пусть и сюжет зависит от уровня сложности! То есть, при лёгком уровне сложности сюжет подаётся целостно и самодостаточно, возможно и незатейливо. На среднем уровне сложности перед игроком вырисовываются новые и неожиданные грани сюжета, вынуждающие смотреть на происходящее под иным углом. На высоком уровне сложности смысл происходящего меняется сильно, местами - до неузнаваемости.
Конечно, имейте ввиду, что в первоначальном виде сюжет уже должен быть интересным.
Пример: допустим, что игра Half-Life на среднем уровне сложности включает в себя Blue Shift, перемежая приключения Гордона Фримена и Барни Калхуна (вот где можно поговорить насчёт пива!). А на высоком уровне - включает ещё и Opposing Force, добавляя переживания Адриана Шепарда.
Не спорю - это сложно реализовать. Но только представьте себе, сколько удовольствия доставит прохождение одной (!) игры на разных уровнях сложности...

---

Соотношение сил

Обычно союзников и врагов расставляют на карте по сюжету или дизайну. Для разработчиков оригинальной игры это ещё удобно, так как характеристики NPC меняются в процессе создания. Но автор мода эту "роскошь" может позволить себе лишь с оговоркой - необходимо соблюдать некоторый баланс "геймплея".
Мало ли, что хочется поставить вот здесь двух повстанцев-охранников с пистолетами, а вон там отряд элитных комбайнов… А то, что вторые "положат" первых за пару секунд, к делу не относится? Игрок-то как выкручиваться будет?
Приходится оценивать боевые качества всех NPC, которые участвуют в битве. А затем корректировать игровой процесс, стремясь к желаемому результату.

В одних случаях преимущества и недостатки сторон можно увидеть своими глазами (явно). В остальных случаях тоже свои нюансы, но оценить их невозможно, так как они не встречаются в игре (неявные).

Явно силы сторон можно анализировать, когда помимо игрока в бою с неприятелем участвуют дружественные NPC (или просто идёт битва двух-трёх сторон). Например, сражение с солдатами или страйдерами в компании граждан Сити-17, нападение на силы Альянса с командой муравьиных львов и прочее в том же духе.
Правда, есть вероятность, что в "стандартной" битве уже используется та или иная корректировка сил. Но многократное участие в таких сражениях, в разных точках игры, даёт исчерпывающие практические сведения.

Остальные сочетания бойцов придётся разбирать самостоятельно. В оригинальной игре нет ничего для подобного анализа, так как в этом случае игрок сражается в одиночку, либо такой расклад сил не используется.
Чтобы выяснить, допустим, как граждане Сити-17 противостоят муравьиным львам (не используя стационарные пулемёты), придётся смоделировать битву на тестовой карте. И всё потому, что нигде не показано серьёзного сражения между ними (в Episode Two Григгс и Шекли наверняка сделаны бессмертными). Пример, касающийся Episode One: если поставить отряды граждан и метрокопов - при равном количестве перевес обычно на стороне первых, а если метрокопов заменить солдатами (из Нова Проспект или даже элитными) - повстанцев скорее будут "валить штабелями" (что и заметно в конце эпизода). Конечно, существенную роль играет оружие, но это уже один из случаев изменения баланса.


Итак, методы корректировки сил для сражающихся сторон:

• замена оружия по умолчанию на более слабое/мощное, что возможно через соответствующие атрибуты энтити-NPC.
  Недостатки: метод очень уж стандартный и потому - не самый естественный, а некоторые сочетания NPC и оружия выглядят неправдоподобно.
  
  
• добавление новых NPC посредством энтити npc_maker (npc_template_maker), которая может приятно удивить количеством возможностей.
  Недостатки: не зря у npc_*maker есть флаг Don't Spawn While Visible - игрок не должен видеть, как NPC появляются ниоткуда (если только не используется телепортация или нечто вроде); данный флаг не ставится обычно только в тех случаях, когда место появления скрывает естественная преграда - помните об этом. Необходимо также придумывать более-менее логичные объяснения, откуда же берутся новые NPC. Наконец, появление NPC следует делать скрытым не только по местоположению, но и по степени внимания игрока.
  Примеры: сражение игрока со страйдерами в Half-Life 2 перед тем, как он попадает в Цитадель (вблизи статуи лошади) - как правило, на появление новых повстанцев некогда обращать внимание. Место, контролируемое пушками Альянса (в Episode Two, глава "На радаре"), несколько запутано, и появление неизвестно откуда новых зомби выглядит естественным. Равенхольм (Half-Life 2) - пример недостаточно продуманной реализации (если только это не своеобразный чёрный юмор); можно нарочно проходить мимо заведомых тупиков и возвращаться обратно, чтобы увидеть там нового зомби. Муравьиные львы, вызываемые фероподом - интересно и нестандартно (хотя имеются небольшие претензии личного характера к реализации).
  
  
• тактическое преимущество одной из сторон, реализованное через геометрию или дизайн карты.
  Недостатки: трудно придумать что-либо оригинальное, так как многие игры охотно эксплуатируют данный метод. На тестирование и корректировку уходит больше времени.
  Примеры: снайперы, автоматические и ручные стационарные пулемёты за ограждением, нападение противника/союзника с нескольких сторон, физическая недоступность занятой противником точки, расстановка сил и info_node* с учётом особенностей ИИ.
  
  
• изменение программного кода или некоторых файлов с целью корректировки характеристик NPC или оружия.
  Недостатки: требуется больше знаний. Здесь приходится вмешиваться в стандартный баланс, рискуя "в момент развалить карточный домик" - ведь неизвестно заранее, в каких сочетаниях будут взаимодействовать NPC в игре. Есть риск неприятия игры другими людьми - не каждому понравится отступление от "правил Half-Life 2".
  Хорошим решением будет изменение внешнего вида противника, чтобы игрок видел "нового NPC". Удобно также продублировать нужных NPC и переопределить их данные в коде.
  
  
• рассредоточить перевес сил во времени и пространстве, меняя количество NPC и состав их оружия (как это сделано во всех играх серии). В одной локации (одно время) игрок может "не напрягаться", в другой (другое время) приходится быть максимально собранным.
  Недостатки: если использовать стандартные расклады сил, у игрока будет "дежавю" (типа "А! Я уже видел это в Half-Life 2!"), что подрывает интерес к игре.
  
  
• добавить фильтры повреждений (энтити filter_damage_type и атрибут Damage Filter у NPC) либо манипуляции со здоровьем конкретных NPC (можно восстанавливать до 100% по событию OnHalfHealth). При аккуратной реализации будет выглядеть естественно.
  Недостатки: свобода подобного творчества сдерживается участием в бою игрока. Да и бесконечное восстановление жизни NPC выглядит неестественно (кстати, даже Аликс Вэнс может погибнуть, несмотря на "подлечивание").

---

Состыковка областей игры

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


Сначала - методы соединения "по-хорошему":

• просто рисовать эти переходы, как и остальную карту. Если игровой мир уже поделён Вами на известные области, и точно известны начало и конец каждой из них, остаётся спроектировать места перехода. Это могут быть длинные участки, вплоть до отдельных карт с плавной сменой декораций. То есть переходы рисуются на бумаге в числе прочих локаций. Чем сильнее поделён на области игровой мир, чем лучше он продуман - тем легче выдумывать переходы, поскольку в этом случае разница в декорациях меньше и проще для создания;
• поставить на пути игрока тоннель или другой вид коридора (вентиляция, пещера, подводный путь, здание с двумя и более выходами и т.п.). Это решение используется чаще всего, как правило;
• постепенное подмешивание к одной области деталей из следующей области. В конечном счете, перейти к противоположной картине (т.е. подмешивание деталей предыдущей области к следующей). Только старайтесь не допускать "мозаики в виде каши".
  Пример: на свалке рядом с лабораторией Восточной Чёрной Мезы используется частично освещение и предметы из грядущего Равенхольма. Потом идёт "коридор", и в результате следующая глава начинается вполне естественно;
• подобрать несколько пейзажей, которые одинаково хорошо сочетаются с обеими областями, и аккуратно вставлять их посередине. Своего рода коридоры, только более изощрённые.

А теперь рассмотрим варианты "по-плохому". Основной принцип здесь - не показывать игроку момент смены пейзажа (или оправдывать его). Старайтесь применять эти способы в последнюю очередь:

• телепортация без маскировки. Это первое, что приходит в голову, но это и один из слабых приёмов (сюжетный вариант не считается);
• заполнение экрана однородным цветом (плавное затемнение, вспышка света и т.п.) посредством энтити env_fade. После чего происходит телепортация игрока в новую область, и затемнение убирается. То есть, используется "киношный" метод;
• развитие предыдущего: главный герой может оказаться в другой области в бессознательном состоянии (его оглушили, он ослаб от потери крови, провалился в тёмный подвал и т.п.);
• переход в другую область в закрытом средстве передвижения (лифт, зашторенный салон автомобиля, поезда или самолёта, каюта морского или космического судна, закрытая капсула или вагон поезда Альянса и т.п.);
• сгущение дыма или тумана. Правда, сильный туман или дым при качественной реализации отнимает больше ресурсов.

Напоследок, рассмотрим несколько случаев, решение которых склоняется к выделению областей:

- действие происходит сначала в окрестностях некоего здания, а затем внутри него. Это весьма непростая ситуация, которая прямо-таки вынуждает действовать "шиворот-навыворот": реализовать сначала внутреннюю структуру здания, а потом уже местность снаружи. Если Вы хорошо ориентируетесь в масштабировании плана карты на рабочее пространство редактора Hammer - конечно, можно заранее нарисовать как планировку здания, так и внешнее окружение. Но, в общем случае, приходится рассматривать здание как одну игровую область, а его окрестности - как другую;

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

---

Ярко выраженные недостатки и достоинства мода

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


Следующие особенности игры можно отнести к недостаткам:

• участок карты сделан таким образом, что игрок раз десять (или больше) погибает в поисках решения задачи, прежде чем сообразит, что нужно сделать. Если это не ключевая особенность мода, а произвольно случающееся явление, оно воспринимается весьма болезненно;
• игрок вынужден искать неочевидное решение или выполнять сложные манипуляции "на ходу" и с нехваткой времени, попутно отстреливая врагов и/или передвигаясь в транспортном средстве. Собственно, чем сложнее задачи, которые нужно решать, тем больше этот случай похож на предыдущий;
• автор мода, даже не спросив мнения одного-двух тестеров, наводнил игру неприятными моментами (например, группа быстрых зомби вслед за группой ядовитых головокрабов). И всё лишь потому, что ему понравилось ставить эксперименты, делая игру с точки зрения маппинга, либо показалось очень интересным разнообразить приключения таким вот образом. А что до игрока, то это его проблемы, как он будет выкручиваться;
• геометрия уровней достаточно разветвлённая, а переходы между картами никак не выделяются. Этот один из вариантов нелинейности, о котором упоминалось выше. Игрок неизбежно пропустит какую-то часть мода (возможно, недостающая аптечка роковым образом повлияет на продолжение игры). В общем, получается навязывание игроку вторичного прохождения без особого удовольствия, что само по себе некрасиво. Пусть хотя бы заранее выводятся предупреждения на экран, даже если они примитивные (типа "здесь переход", "пропущен тайник" и т.п.), либо встреченные NPC сообщают об этом, либо от этого зависит возможность продвижения дальше;
• не работает несколько очевидных способов решения задачи, притом, что правильный вариант лишён нормальной логики и смысла. Если только это не особенность мода, лучше заранее предупредить игрока, намекнуть на решение. Помните: что очевидно для одного человека, не обязательно поймёт другой;
• мод подразумевает необычные выходы из ситуаций, но при этом в некоторых случаях надо "тупо" выполнить "стандартное" действие (случай, обратный предыдущему). Особенно плохо, когда игра ждёт это действие, чтобы запустить очередной скрипт. Разумным решением может быть только одно - убрать такие моменты из игры (или заменить). Если всё же решено дать подсказку игроку, сделайте её как можно понятнее;
• для запуска мода предлагаются хитрые манипуляции, вроде копирования игровых файлов в разные папки, включения консоли и запуска игры через map <имя карты>. Мало того, что требуется аккуратность и необходимость позже "вылавливать" удаляемые файлы (а не просто одну папку с названием мода, как в нормальном варианте), так ещё создаётся впечатление "сырой", недоделанной игры. Впрочем, если мод состоит всего из одного файла - карты в *.bsp-формате, это ещё простительно;
• карты изобилуют прямоугольными комнатами или даже "загонами", текстуры наложены методом "тяп-ляп", невероятно пустые комнаты или огромные территории, иногда (или часто) происходят "дикие слайдшоу". Всё это недостатки дизайна, когда у автора не хватило времени разобраться с проблемами или не было желания возиться с прорисовкой. На самом деле, это терпимо при условии более-менее хорошего сюжета. Но, во-первых, такое сочетание почти не встречается, а во-вторых, ситуацию нетрудно исправить (displacement, выравнивание текстур, добавление энтити-декораций, поиск утечек, расстановка func_areaportal[window], выравнивание брашей и другая оптимизация геометрии), нужно лишь терпение. Необходимо отметить, что звуковой кэш, создаваемый движком автоматически для любой карты, весьма неоптимален по наполнению. Оптимизация кэша вручную позволяет значительно улучшить производительность системы во время игры (ссылка);
• скриптовые события работают "со скрипом", замирая при любом отклонении действий игрока от "стандартных". Здесь та же проблема, что и в дизайне: хорошее скриптование - как хороший дизайн - требует времени и терпения, которых не хватило автору мода. Исправить ситуацию обычно помогает богатое воображение маппера или банальное тестирование сторонним игроком (снижает вероятность ошибок). Ну, и конечно - хороший опыт, мастерство работы со скриптами;
• игровой процесс очень напоминает полосу препятствий: игрок отстреливает кучку врагов, появляется следующая; идёт дальше, встречает новую группу, сразу после отстрела которой появляется ещё одна группа, и так далее. То есть, появляется устойчивое ощущение, что враждебные NPC как один сговорились "все на игрока" и выступают по-очереди, чтобы "не мешать" друг другу. Стоит хотя бы изредка добавлять взаимодействие NPC между собой (сражения, разговоры и пр.) - как всё приходит в норму, ощущение "тира" пропадает;
• однообразие действия или противников. Хорошо такие вещи заметны, если карты весьма большие и, безусловно, были созданы маппером для собственного удовольствия. А вот на хороший "геймплей" автору не захотелось тратить время, в результате - никакого удовольствия от игры;
• игрок получает неадекватную награду за выполненную задачу. Это может быть мизерный результат (удовлетворение) значительных усилий, отсутствие передышки после тяжёлого боя, тупиковое состояние после довольно продолжительной игры (вынуждает загружать раннее сохранение игры, причём едва ли не час назад) и др.
  Например, в Half-Life 2 игрок отражает атаки Комбайнов, в то время как Аликс пытается открыть дорогу к мосту; откровенно говоря, ждал большего эффекта, чем просто закрытие ворот перед носом у солдат.
  Исправить положение можно за счёт добавления/убирания энтити, скриптов, NPC и эффектов, расстановкой триггеров автосохранения. Не исключены и серьёзные переделки игрового пространства, учитывая конкретную ситуацию;
• бóльшую часть времени игрок чувствует себя либо вполне безопасно, либо в крайней опасности. Иначе говоря - либо почти нет активного действия, либо сражения идут почти без передышки (или приходится всё время ожидать атаки). Постоянное спокойствие с редким действием или постоянное напряжение с редкой передышкой - не лучшее времяпровождение для игрока.
  Можно и поспорить с этим доводом, но достаточно вспомнить игры, которые получили высокую оценку большинства людей. Практически в каждой из них происходит активное, интересное развитие событий, а также даётся время относительно спокойно обдумать ситуацию, прикинуть дальнейшую стратегию.

Замечание: можно сделать плавное усложнение игры в нужную сторону, давать подсказки/предупреждения или даже реализовать привязку к уровню сложности (см. чуть ниже). Таким образом, игрок вникает в процесс, и многие виды недостатков становятся незаметными или превращаются в достоинства "геймплея".


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

• есть привязка к уровню сложности не только в виде урона, наносимого противником или оружием игрока, эффективности зарядных устройств и подобных вещей, которые и так уже сделаны Valve по умолчанию. Интересно, когда сложность учитывается на уровне маппинга и улучшения ИИ, то есть индивидуально для каждого мода. Например, появляется больше врагов, противник действует умнее, открываются секретные места, некоторые задачи "теряют" простое решение, требуя большего напряжения мысли, и т.д. (хотя бы, как дополнительные режимы игры в Portal). Вот это действительно реальный и хороший стимул для повторного прохождения игры.
  Практическая реализация требует значительных усилий разработчика. Даже если рассматривать учёт лишь через маппинг, понадобится небольшое дополнение программного кода. В качестве примера, как можно ввести проверку сложности на уровне маппинга (к сожалению, используя перекомпиляцию движка Source), в сборник включена статья Проверка уровня сложности через энтити;
• анимированная заставка в главном меню, т.е. загружается карта с неким пейзажем, помещением или просто картинкой, возможно озвученная. Главное - есть на что посмотреть "в предвкушении". Совсем замечательно, если заставок несколько, и они открываются по мере прохождения глав игры (как в оригинале от Valve);
• окружающий мир в игре нарисован "с душой", в нём приятно странствовать, исследуя каждый уголок. Здесь, правда, возникает чисто техническое препятствие - увеличиваются требования к мощности системы (из-за повышенной детализации). А поскольку "глобальные эксперименты" проводить бессмысленно, не увлекайтесь большими размерами карт (также см. последний раздел);
• NPC в игре совершают удивительно естественные поступки, делающие их более одушевлёнными. Самый наглядный пример - поведение Аликс Вэнс (подбадривает игрока в Half-Life 2, пугает "голосом зомби" в Episode One, плачет в конце Episode Two). Чтобы такие вещи удавались, нужно воспринимать игровой процесс в целом, также как видит его любой игрок (не одержимый манией "скорее дойти до конца"). Нужно чувствовать атмосферу игры, вникать в происходящее, угадывать мысли игрока в конкретный момент. Поэтому лучше отложить эти дополнения к моду ближе к концу работы, когда карты выглядят почти готовыми или появляется ощущение цельной игры. Исключение составляют достаточно сложные и длинные сцены с NPC, которые присутствуют в игре безусловно;
• при возникновении в игре напряжённой атмосферы (за счёт музыки, звуков, явлений, событий, голосов и пр.) в определённый момент ожидание игрока оправдывается каким-либо мрачным событием, важным известием, появлением опасного противника, особенно если это новый вид NPC (не из серии Half-Life, т.е. нововведение мода). Между прочим, не обязательно знать программирование - приличные результаты получаются и в пределах маппинга;
• в начале игры действие разворачивается постепенно, атмосфера накаляется. То есть отсутствует ситуация "с корабля на бал"; даже первые враги нападают не сразу.
  Если этот принцип соблюдается - значит, автору (авторам) точно есть, что показать игроку;
• в конкретной области игры можно точно сказать, насколько "заумные" действия требуется выполнять. А усложнение действий происходит всегда в большую сторону (например, от локации к локации).
  Примеры: тестовые камеры Portal. Другая ситуация - когда заядлый игрок в Quake переходит на Half-Life; кнопки, рычаги и прочее уже не "толкаются", а приводятся в действие командой "использовать". Также, если играть в какой-либо старый 3D-шутер впервые после современных игр, в тупиковой ситуации невольно исследуется каждая деталь, каждый выделяющийся квадратик принимается за кнопку - до тех пор, пока не сообразишь, что решение "лежит на поверхности".
  То есть, игрок должен хорошо понимать, насколько интеллектуальные (просьба не смеяться) задачи ожидают его в конкретной точке игры. А то, бывало, сядешь за мод с примитивным отстрелом, а через десять минут начинаешь лихорадочно обшаривать доступные уголки в поисках "кнопки", т.к. развитие событий неожиданно стопорится. И всё потому, что уже не ждёшь от авторов чего-либо оригинального.
  Между прочим, я склоняюсь к мысли, что именно поэтому авторы рецензий на моды отмечают сочетание мысли и действия довольно "блёкло", если так можно выразиться. То есть, далеко не каждый моддер сумеет подобрать удачное сочетание простых и мудрёных действий - такое, чтобы оно было замечено.

В заключение этой части хочу посоветовать: многие проблемы и особенности реального мира не стоит переносить в мир игровой, с целью реализма или "вживания" игрока в игру. Во многих случаях детали становятся лишними, мешают удобной и нормальной игре.
Сравним те же Bioshock и Dead Space. В первом разделили оружие и "магию" на две части, используются "пассивы" и доработка оружия, поиск средств пополнения боеприпасов. В общем, неслабая нагрузка к беготне со стрельбой. Во втором заставили игрока смотреть на "себя" сзади, "строить микросхемы" для модификации оружия и брони, добавили области вакуума с убывающим запасом кислорода и др. Конечно, реализма больше, но вышло так, что ради небольшого эффекта нужно прилагать значительные усилия. К тому же, нахождение боеприпасов могло быть оригинальнее. А спустя несколько глав лично мне стало скучно, так как враги частенько "брали количеством". Собственно, вопрос: нужно ли вводить какое-то новшество в ущерб всему остальному?
Конечно, рассмотренные игры сделаны не из рук вон плохо (наоборот, весьма добротно). Но… недостатки остаются недостатками, а Bioshock выигрывает, как менее насыщенный реалистичными подробностями.
Вот и думайте, стоит ли усердствовать в деталях.

---

Реализм

Раз уж была упомянута реалистичность, рассмотрим её с другой, более привлекательной стороны. Имеется в виду реализм действия, происходящего в игровом пространстве.
Обстановка, союзники, противники, эффекты, звуки могут быть сколь угодно фантастическими, с полным отсутствием логики. Это не так уж критично: игрок примет на веру происходящее. Если такова суть мода, хуже он не станет.
Гораздо важнее то, что даже фантастический мир подчиняется определённой логике и управлению, "живёт" по собственным правилам. И если мод сделан не по принципу "иди вперёд без оглядки", когда не всё, что происходит, случается лишь вокруг игрока - игра обретает особый колорит, мир "оживает по ту сторону монитора".

Ниже приведены весьма эффективные методы, придающие выразительность игре. Некоторые из них трудны в реализации, но они стоят вложенных усилий.

1. появление NPC в уже пройденных областях - довольно простой, а также "затасканный" способ (энтити npc_*maker). Простейший способ: запуск npc*_maker в одной точке при касании игроком триггера где-либо в другой точке.
   Пример: зомби в Равенхольме (Half-Life 2).
   
   
   
2. небольшое развитие событий в уже пройденных областях - по сути, добавляется работа со скриптами. Разнообразить происходящее не так уж сложно, но затраты времени уйдут на то, что игрок скорее пропустит, чем увидит.
   Пример: в Half-Life 2 игрок проходит по каналам из помещения, в котором прячется повстанец ("…у этого неудачника вообще нет шансов…"), и встречает группу мэнхэков. Если вернуться назад после этого - повстанец лежит убитый, а рядом летает ещё один мэнхэк.
   Замечание: можно добавить не само действие, а только конечное состояние, что на порядок легче и быстрее.
   
   
   
3. имитация "жизни" NPC. То есть, окружающие не стоят "столбами", ожидая действий игрока или какого-нибудь скрипта, а "занимаются своими делами", "ведут разговоры" и т.п.
   Пример: лаборатория Восточной Чёрной Мезы - вортигонт ходит туда-сюда, "печатает на клавиатуре и следит за оборудованием".
   Здесь сложность заключается в реализации поведения. Нужно ухитриться разбить его на простые, легко добавляемые детали, которые легко отладить, перетасовать и т.д. Вот образец, как это можно сделать (применимо и к сцене в FacePoser):
   
   
   • выполнить анимацию (scripted_sequence);
   • подойти к цели №1 (например aiscripted_schedule);
   • сказать фразу, выполняя анимацию (ambient_generic + scripted_sequence);
   • выждать случайное время (logic_timer);
   • если выполнено условие №1, подбежать к цели №2 (logic_relay или триггер + aiscripted_schedule)
   
   и так далее, в том же духе.
   
   Некоторые простые вещи уже сделаны Valve. К примеру, npc_citizen переговариваются между собой в нейтральной ситуации, npc_pigeon ходят в разных направлениях и "клюют что-то на земле".
   
   
   
4. больше случайности в происходящих событиях - как в наблюдаемых, так и "за стенкой".
   Иногда требуется сочетание звука и действия (гроза, прибой и др.). Удобно использовать в таком случае logic_timer со случайными значениями интервалов, которые проходят между наборами событий.
   
   
   
5. звук весьма заметно разнообразит игру. Не даром Valve столь хорошо развила систему саундскейпов. И пренебрегать озвучиванием локаций настоятельно не рекомендуется. Почаще используйте саундскейпы.
   
   Пример: если в комнате (в зале, на улице и т.п.) слышны посторонние звуки - ощущается присутствие жизни, самостоятельное развитие игрового мира. А в случае, когда тишина ничем не нарушается (либо только отдалёнными звуками) - комната выглядит покинутой, место - безлюдным, жизнь вокруг словно замирает.
   Это можно отнести даже к одному из приёмов дизайна.
   
   
   
6. Если добавляются новые модели (неважно - NPC или неодушевлённые предметы), причём добавляются в систему уже существующих - необходимо хорошо изучить то, что уже есть. А новые модели создавать таким образом, чтобы они соответствовали неким общим правилам данной системы. То есть, вписывались в уже созданный мир.
   
   Например, при добавлении новых элементов оформления Цитадели необходимо изучить её обстановку, какие материалы используются для интерьера, оборудование и принципы его работы. При добавлении нового вида войск Альянса необходимо придерживаться стиля, в котором выдержаны метрокопы, солдаты, синтеты, заграждения и APC.
   
   NPC или модель, относящиеся к определённому классу или типу дизайна, но сильно выделяющиеся неким собственным стилем, выглядят не лучшим образом. Иногда это смотрится хорошо, но чаще всего полученный результат выглядит неестественно при любых условиях ("белая ворона"). И никакие оправдания не заставят игрока рассматривать нововведение как часть системы.
   
   Замечание: не обязательно "тупо копировать технологии". Можно уловить мелкие детали, оттенки и даже намёки на стиль, присущий данной системе.
   Немаловажно и чувство меры. Не злоупотребляйте "пиханием" новых элементов везде, где только можно. Например, один вид новых противников лучше подходит для уличных боёв, другой - в лесу, третий - внутри помещений; аналогично с новыми эффектами, текстурами, звуками и так далее. Здесь тоже нужна своеобразная логика.

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

Например, в Half-Life после того, как игрок попадает в мир Xen, уже не встречаются стационарные зарядные и лечебные устройства. И большинство необходимых припасов лежат вблизи погибших учёных и солдат. Ещё встречаются небольшие "ванночки", медленно пополняющие здоровье.

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


Полезный приём: рассматривать события игры с точки зрения каждой из сторон, которые участвуют в том или ином действии.
Например, пусть на конкретной местности игрок сражается с комбайнами. Можно проанализировать территорию на предмет тактики, которой будет следовать Альянс, чтобы не пропустить игрока: отвлекающие манёвры, засады, особая расстановка сил, вмешательство скриптов по некоторым условиям и т.д.
Для большей ясности возьмём гостиницу на пути к Белой Роще (Episode Two) - там даже есть комментарии Valve насчёт разнообразия тактики. А именно: часть комбайнов отвлекает игрока, в то время как остальные пытаются зайти с тыла. Этому способствует наличие подвала и нескольких входов/выходов. Изменяется и расположение солдат.
Даже в то время, когда я не знал о такой постановке "геймплея", усложнение игры было заметно. И до сих пор меня "выбивает из колеи" происходящее в гостинице - налицо изменение тактики Альянса (обычно не слишком умной).


Наконец, поговорим о том, зачем всё-таки надо выдумывать историю каждому NPC в игре (союзникам и противникам), зачем вообще нужно собирать материалы по каждой локации и так далее.
Допустим, Вы придумали нового NPC - со своими особенностями передвижения, атаки, внешним видом. Необходимые модели откомпилированы, добавлен код поведения, создана тестовая карта. И началась проверка: как же это всё выглядит в игре... Однако возникает странное впечатление: NPC выглядит словно упомянутая выше "белая ворона" (даже при том, что подгоняется под систему) или вообще как-то безлико, небрежно; появляется устойчивое ощущение, что в облике NPC чего-то не хватает или наоборот лишнее.
Если произошла такая ситуация, я готов поспорить, что Вы не потрудились придумать хотя бы одно предложение, описывающее историю этого NPC. Не объяснили самому себе, для чего был добавлен NPC в игру (кроме того, что вносит разнообразие в "геймплей" или просто "круто выглядит"). Именно пропуск столь необходимого звена планирования таким вот образом откликается впоследствии. А раз так, то уж постарайтесь выдумывать таких NPC, которые в первую очередь интересны Вам самим - чтобы с удовольствием сочинять им историю, рисовать модели, разрабатывать код, подбирать звуки...
И, кстати, не только NPC заслуживают столь пристального внимания. Как живой пример - в некоторых модификациях авторы добавляют или меняют вид оружия; при этом используются какие-то сторонние наработки (скажем, берут материалы из учебного примера). В результате получается, что "новое" оружие здесь "ни к селу ни к городу". Да, можно создавать собственный мод, чтобы добавить туда понравившуюся вещь; но ведь не только же ради этого! Неужели авторам не хочется добавить что-то от себя?


Многие игровые области могут запросто поставить в тупик ещё до начала проектирования: как строить геометрию уровней? Какие "комнаты" и в каком порядке размещать? Где будут уместны коридоры? Как загораживать "ненужные" проходы? И другие в том же роде.
Чтобы не быть в растерянности и начать хоть с чего-нибудь, попробуйте развёрнуто ответить на следующие вопросы:

Цель: для чего была построена локация?

Подробное описание первоначальной цели с точки зрения "жителей" игрового мира, действия, работы, которые там происходят в обычном порядке.

Что происходило (произошло) перед появлением игрока?

Возможно, какое-то значительное событие (и не одно) произошло в данной локации перед тем, как туда пришёл игрок.

Что происходит во время путешествия игрока в данной области?

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

---

Игровой мир

Можно выделить три главных составляющих (трёх китов?), которые обеспечивают успех практически любой игры:

• сюжет;
• дизайн и геометрия;
• игровой процесс

Если "дать слабину" даже в одной из них, игра выглядит ущербной. Это очень существенный повод, чтобы не беспокоиться во время работы. По той же причине выделены три части последнего раздела.

О сюжете уже говорилось в самом начале - немного, но уже кое-что. Трудно советовать что-то конкретное по "геймплею" - многое зависит от способностей разработчика (собственно, эта информация рассредоточена по всей статье). А вот для работы над геометрией и дизайном, определённо, можно использовать очень сильный приём: выдумывание игрового мира до мелочей.

Бывают ситуации некоего "творческого бессилия" - вроде бы есть настроение работать, но что конкретно делать в данный момент - неизвестно. Или "полный тупик", когда надо рисовать модель, карту, а где, что или как - ни тени мысли. Или ещё более конкретная ситуация: придумана общая геометрия карты и теперь нужно "чем-то заполнить пространство".
В таком случае выручает максимально проработанный игровой мир - вообще для игры и персонально для каждой локации. Чем подробнее расписаны детали, тем быстрее найдётся решение (при условии, что Вам хватает фантазии).

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


Этап 1:

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

Для реального стиля можно собирать "скриншоты" игр, фотографии, картины художников, энциклопедические статьи, описания в книгах, фрагменты из фильмов, готовые 3D-модели и звуки, собственные работы.
Для фантастического стиля можно собирать "скриншоты" игр, зарисовки в художественной литературе, картины художников, описания в фантастической литературе, фрагменты из фантастических фильмов, игр, готовые 3D-модели и звуки, собственные работы.
Как можно заметить, списки имеют много общего. И зачастую единственным критерием выбора служит уклон в сторону реальности или фантастики.
Несколько проще будет в том случае, когда планируется создавать мод, не выходя за пределы оригинальной игры. Текстуры, звуки, модели, скрипты, образцы дизайна - всё уже будет наготове. Понадобится лишь выделить нужные Вам ресурсы.

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

Пример: рассмотрим воображаемый путь действия Valve при создании интерьера Цитадели. На данном этапе кратко расписываются основные детали: механизм удержания равновесия, мосты, силовые поля (возможно управляемые), редкие лифты-платформы, вертикальные шахты со многими выходами, мрачная и "неземная" музыка, гулы, шумы механизмов и т.д. Более мелкие детали: аппараты лечения/зарядки, мониторы и консоли, светильники, капсулы, провода, трубы, вой сирен, "странные голоса" и т.п.

Этап 2:

обычно далее следует рисование выбранных деталей, наброски моделей на бумаге или в графическом редакторе. Обратите внимание: только наброски, а не готовый материал.

Используйте больше фантазии, воображения; не стесняйтесь отметать лишнее, выдумывать детали (для фантастики), делать выводы и обобщения (для реальности). Реальную картину достаточно описать приближённо, но при этом так, что у игрока будет возникать иллюзия реальности. Фантастическую картину можно вообще дорабатывать до того, как она станет интересной и логичной (хотя последнее необязательно).
Примерно то же самое относится и к созданию отдельных моделей. В этом случае материал должен быть с уклоном в наглядное описание, поскольку нужна основа, с которой позже будет создана игровая модель. Дополнительно, необходимо будет найти (или создать) подходящие текстуры, а также "образцы" движений (если потребуется делать анимацию).

Этап 3:

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

Здесь настаёт время создавать готовый материал: присутствует "нечто", от которого можно оттолкнуться. Более-менее ясна конечная цель, представление игры обретает цельность. Одновременно, на данном этапе подготовка материала достигает максимальной загруженности. Это самая долгая часть.

Пример: в пещерах - капающая вода, обвалы, летучие мыши и пр. Для ранее приведённого примера о Цитадели - летающие изредка сканеры, проезжающие составы, движущиеся капсулы и т.д.

Этап 4:

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

Пример: достаточно прочитать комментарий Valve о том, что на протяжении всей игры в первом эпизоде использовался оранжевый оттенок, а во втором - синий. Действительно, это разумное дополнение ощущений от игры.
Также, Цитадель в Half-Life 2 имеет характерный оттенок бирюзового цвета, присущий многим элементам; наверное, стоит только добавить где-либо подобную текстуру металла или стекла - и локация мода будет восприниматься "цитадельной", типично альянсовской.

Этап 5:

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

В качестве примера можно привести Half-Life: Blue Shift - в первых сценах игры появляется некоторое количество людей со своими личными заботами, отношениями; в дальнейшем игрок пересекается с сюжетными линиями более ранних игр. И даже в Half-Life 2, откуда были изъяты целые области, события "второго плана" довольно заметны. Для той самой Цитадели - бегущие куда-то солдаты, вылетающие на битву корабли, конвейеры с крабами-синтетами и мортирами-синтетами, сталкер, который транспортируется куда-то, запертый в капсуле.
В отличие от третьего этапа, такие события будут немногочисленными или даже единичными. Как следствие, они не примелькаются и будут заметными на фоне всего остального.

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

Заключение: деление на этапы не обязательно ревностно соблюдать. Может быть, Вам будет удобнее смешивать этапы, вести параллельно или пропускать.
Собственно, конечный вид локации (модели) покажет, насколько хорошо постарался автор мода. Что ж, посмотрим…

---

Неоправдавшиеся надежды и другие крупные проблемы

Напоследок, поговорим о тех случаях, когда результат тщательных стараний выглядит в конечном счёте неуместным в игре (даже в лучшем случае). Или когда "не стыкуются" интересные элементы, которые прекрасно выглядят по-отдельности.
Это самые печальные события в процессе разработки мода. Собственно, только из-за их возможности стоит заранее тщательно продумать элементы сюжета, геометрии и "геймплея". Требуется хорошее воображение, чтобы "прокрутить в уме" очередную идею или участок карты.
Полезно иногда видеть собственное творение со стороны. Можно представить себя в роли человека, впервые проходящего игру. Как правило, где-нибудь всплывают определённые несуразности, несостыковки действия или сюжета, отсутствие логики и т.п.


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

Пример: "мод" Opposing Forces (Half-Life). Слово "мод" присутствует намеренно: разработчики делали игру по принципу модификации, но хорошо развили сюжет, вследствие чего изменили возможности игрока, состав NPC, оружия и другие детали. В результате вышла практически отдельная игра, со своим взглядом на мир Half-Life. Конечно, самостоятельной её не назовёшь, но проходится игра "на одном дыхании". А вот Blue Shift (Half-Life) выглядит именно как мод - хорошо проработанный, но всё же мод.


А теперь представим, что в результате игра оказалась скучной, само построение сюжета неинтересно. Как же спасти положение?


Сначала - меры предосторожности:

• рекомендую в первую очередь заняться процессом игры, вкратце наметив основную линию сюжета. Т.е. придумать несколько карт, "фишки геймплея", удачные заимствования, "изюминки", новые NPC, декорации, оружие и т.д. Затем хорошо проработать и отладить всё это, точно установить, что все эти вещи интересны для игры. А уже потом тщательно разрабатывать и развивать сюжет, увязывая с игровым процессом. В последствии где-то можно и "геймплей" подгонять под сюжет;
• если начать с глубокой проработки сюжета (сделать наоборот), есть вероятность недооценить трудности. Поскольку одно дело - выдумать нечто, теоретически интересное, а совсем другое - придумать, как сделать это практически. Велик риск "сворачивания" сюжета ради лёгкости в реализации. Хорошее знание маппинга, программирования и других нужных вещей не гарантирует, что Вы никогда не зайдёте в тупик. Даже при отсутствии знаний разработчики обычно рисуют грандиозные замыслы. То есть, как правило, человек "замахивается" на нечто, большее его способностей, а доучивается уже "в процессе";
• удобно (ещё раз) сначала обрисовать сюжет в самых общих чертах. Позже, начав реализацию отдельных моментов, Вы придёте к необходимости согласования - сюжета и действия, происходящего на карте. То есть конкретные особенности "геймплея" будут логично объясняться сюжетом. Таким образом, сюжет уточняется и "шлифуется" ближе к концу работы над модом, вплоть до деталей. Получается, что "геймплей развивает сюжет, сюжет развивает геймплей" и так далее;
• если планируется (по сюжету или дизайну) большое количество энтити, брашей, источников света и прочего на одной карте - сначала проверьте, будет ли это "чудо" хотя бы компилироваться. Для этого всего лишь надо сделать простую "комнату" и поместить внутри нужное количество деталей, а лучше увеличить его примерно в 1,5-2 раза. Если карта нормально откомпилируется, запустится и не будет "тормозить" или "вылетать" - можно надеяться на успех.

Если всё-таки самое страшное уже произошло - перед тем, как окончательно забросить мод, попробуйте следующие методы:

• новые идеи ведения боя, принципы игрового процесса. Немало игр, в общем-то, примитивных, обрело известность таким образом (скажем, Тетрис или Zuma Deluxe);
• разбивка больших/гигантских локаций на части, с переходами-загрузками. Относительно малые и простые карты легче запомнить в уме и подправить с целью изменения сюжета, проще выкинуть из финальной версии (постарайтесь не жалеть откровенно неудачные места);
• красивый дизайн. Если игроку приятно смотреть по сторонам, если чувствуется старание дизайнера - как правило, это положительно сказывается на впечатлении от игры;
• тщательно проработанная, насыщенная атмосфера игры (дизайн + звук + скрипты). Сделать едва ли не сложнее, чем хороший сюжет; на это уйдёт много времени. Зато включается воображение игрока, позволяя мириться с неприятным, "кривым" или очень примитивным сюжетом.

И помните, что разработчику бесплатного мода это будет простительно (в отличие от коммерческой фирмы, которая получает деньги за игру).


По сюжету можно сказать ещё кое-что: немало художественных фильмов (и сериалов) сняты по ранее изданным книгам. И что же мы обычно видим? В книге сюжет раскрывается гораздо подробнее, глубже и понятнее. А фильм обычно воспринимается зрителями поверхностно; технические особенности съёмок или выражения авторской мысли существенно ограничены. Если учесть, что режиссёр ещё может и переиграть оригинальный текст, тогда вообще "зритель, держись"...
В общем, старайтесь дополнять и расширять сюжет в процессе разработки, потому что забегания вперёд здесь неизбежны. А потому, что-то неминуемо придётся выкинуть (в угоду той самой реализации). Страшно представить, что останется от сюжета в глазах конечного игрока!


Геометрия и дизайн: создатель карты видит её главным образом сверху или сбоку, игрок видит карту всегда "изнутри". Поэтому хорошо бы мысленно пройти по нарисованной на бумаге карте, "спуститься с высоты птичьего полёта". Если у Вас хорошие способности к рисованию и есть время - можно отдельные кусочки набросать в изометрической проекции. Это способствует большему погружению в игровой мир, потом станет легче рисовать карты в Hammer-е.

Чтобы не забросить мод раньше времени, продумайте его как скромный набор карт, в которых сосредоточено всё действие. И это вовсе не обязательно непрерывное игровое пространство - представьте, что игрок телепортируется из локации в локацию. Позже будет виднее, как соединять разные карты (см. раздел Состыковка областей игры) или дорисовывать игровой мир.
Весьма нежелательно рисовать наспех геометрию сразу нескольких карт, не утруждая себя их детализацией. Если неохота придумывать дизайн сейчас, откуда возьмётся желание потом? Ещё раз повторюсь: на бумаге лучше рисовать максимально возможный готовый вид - очень помогает, когда Вы сядете за практическую реализацию.
С другой стороны, очень полезно рисовать карту уровней также в крупномасштабном виде - указывая основные пути следования в виде линий, практически без детализации. В этом случае действует тот же принцип, что и с сюжетом - Вы намечаете "глобальные вехи" игрового пространства, а затем на их основе создаётся уже детальная карта местности.

Не думайте также, что плохой дизайн будет "вытянут" сюжетом. Почему-то ещё ни одна игра не демонстрировала плохо нарисованный мир и действительно хороший сюжет (вот наоборот - это бывает). То есть, дизайн в какой-то мере переплетается с сюжетом, а если уж хватило сил на хороший сюжет - должно хватить и на хороший дизайн.
Только не приводите в пример старые игры - в своё время никто не говорил, что у них примитивный дизайн. Я и сам удивляюсь, как можно было тогда восхищаться 16-цветной графикой. Но это же сравнение с настоящим временем!
Сейчас даже игровые приставки, даже телефоны развиваются в сторону более качественной картинки. А многофункциональное устройство не ценится, если каждая его функция сделана "на троечку".
То есть, для своего времени, нарисовано, а не набито деталями и эффектами, было хорошо. Что и требовалось доказать.

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


В неблагоприятной ситуации опять на первое место выступает игровой процесс. Это главный и самый эффективный метод скрашивания недостатков.

Рассмотрим несколько примеров (по сути, приёмов игры):

• можно заставить игрока проползти по "туннелю" без приключений, а можно устроить мини-аттракцион (как в Episode One, с заслонкой от энергетических шаров);
• пожалуй, муравьиные львы, появляющиеся из-под земли (Half-Life 2), задуманы как основное развлечение во время поездки на багги;
• существенная часть Episode Two, по сути - поездка в Белую Рощу, "разбавленная" приключениями на дороге. Надо же показать игроку, что место назначения далеко (обратите внимание, какая получается разница с поездками в Half-Life 2);
• предыдущее можно обобщить: 3D-шутер, в целом, представляет собой "дорогу к главному боссу/заданию, разбавленную вторичными приключениями".

То есть, вывод понятен - можно сделать пустой коридор от начала игры до её конца, а можно искусно заполнить его монстрами, триггерами, ловушками и другими приключениями. Конечно, я утрирую понятие "геймплея", но Вы всё-таки примите к сведению.


Если Вы чувствуете будущие проблемы или сомневаетесь, что задуманное будет реализовано, попробуйте метод разработки - упрощённое приближение. При этом вначале некоторая сложная система (деталь, NPC, оружие, эффект, сцена и т.д.) делается в примитивном виде. Расчёт такой, чтобы в дальнейшем было возможно легко и без особых проблем усложнять конструкцию до нужной "кондиции".
Из-за нехватки ресурсов (умения, времени и пр.) можно остановиться на текущем, более простом варианте. А если ресурсы позволяют - можно совершенствовать текущую конструкцию.


Игровой процесс ("геймплей"): самый тяжёлый случай, поскольку это главное, ради чего делается игра. Если работа зашла в тупик, возможно, лучше бросить всё, и пусть мод пребывает в безвестности. По идее, сюжет в этом случае тоже является слабым и не стоит упоминания. Да и качественный дизайн мало что меняет.

Благодаря некоторому упрощению процесса разработки игры, любой шедевр наших дней обзаводится целым вагоном "клонов" с аналогичной (ну, пусть немного изменённой) схемой действия. И главное - ни один "клонодел" не терзается муками совести! Ладно, если оригинальная игра обладает плохой реиграбельностью. От скуки можно примириться с "очередным родственником".
Но зачем же копировать удачную схему? Делать косметические или другие малозначительные изменения и "спускать на поток"? Говорить "мы сделали лучше"?
Жаль, что нельзя (в рамках закона) платить за игры столько, сколько они этого заслуживают, по мнению конечного игрока…

Тем меньше оправданий бесплатному моду с "унылым геймплеем" (никакой двусмысленности). Для чего он тогда делался? Приходим к ответу - лишь бы сделать.

Вообще, Valve многое сделала для того, чтобы процесс игры не напоминал медленную пытку. Мапперу остаётся только следовать правилам расстановки вспомогательных энтити (info_node*), да проверять время от времени свои карты в игре, чтобы сложность не вышла за разумные пределы.
Проще всего добавить "записных врагов Фримена" - солдат Альянса, муравьиных львов (в отсутствие феропода), охотников или зомби. Далее, расставленные ноды завершат остальное. Противник сам найдёт игрока и начнёт его "обрабатывать".
Именно за счёт этого выдерживают критику незамысловатые модификации. Незамысловатые они в том смысле, что могут представить красивые пейзажи, ненулевой сюжет, но… ничего более. А враги там расставлены "по вкусу дизайнера", возможны небольшие эксперименты с энтити npc*_maker. Весь "геймплей" сводится к отстрелу мишеней.


Но, как показала реальность, и здесь умудряются "наломать дров":

• например, если автор мода имеет завышенное понятие о сложности игры, приходится встречать яростное сопротивление многочисленного противника, который лезет буквально отовсюду. Патроны ценятся на вес золота, а в отдельных случаях приходится использовать режим неуязвимости и другие нечестные приёмы. Даже без динамического пополнения врагов играть сложно, а уж когда маппер "снизойдёт" и до этого…
• если наоборот, автору показалась сложной Half-Life 2 и прочие - совершается прохладительная экскурсия по моду. Повсюду кучи оружия и патронов, либо каждый встреченный противник "валится с одного пинка". Конечно, не обязательно это сознательное упрощение: возможно, маппер витал мыслями в иной реальности, когда делал карты;
• в ином случае просто диву даёшься, откуда столько "камикадзе" вокруг? Выползают из самых невероятных закутков, под боком у своих заклятых врагов, и яростно кидаются на игрока... Вероятная причина: NPC выступают в роли живых декораций, без особой логики (в смысле - почему они здесь, как сюда попали и как случилось, что их ещё не обнаружили). Всё это обычно "режет глаз", когда в игре проглядывается или навязывается вполне осмысленный сюжет.

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

Простые способы облегчения игры: уменьшить количество противников, случайных скриптов, добавить аптечек, батареек, патронов, укрытий. Соответственно, для усложнения игры: добавить больше противников, случайных скриптов, убрать несколько аптечек, батареек, патронов, укрытий.
В крайнем случае, постоянно сравнивайте трудность прохождения мода с оригиналом.

Разумеется, когда лёгкий вариант игры определённо "утверждён", уровень игры примерно выровнен - можно переходить к средней и высокой сложности. Но здесь, скорее, идёт проверка с целью убедиться, что никаких разногласий между установленным и наблюдаемым уровнем игры не имеется. Хотя, если скриптов на карте много...


Теперь поговорим о более сложных нюансах.
Если вспоминать незамысловатые игры прошлого, есть одна любопытная деталь: некоторые игры с так называемым "платформенным скроллингом" (когда экран всё время движется) можно гораздо легче проходить, всего лишь заняв некую позицию в определённой точке экрана (как правило, у его края). Либо достаточно всё время нажимать одну и ту же последовательность кнопок ("аркадные драки").
С дальнейшим развитием игр тактика "выигрыш дурака" также усложнилась (или упростилась?), но всё-таки осталась. Например (что мне не очень-то нравится), есть своеобразный "спорт": прохождение игр на скорость. Если конкретно - можно скачать видео скоростного прохождения Half-Life (Half-Life за 30 минут). Используя особенности движка, игрок значительно сокращает путь, иногда пропуская целые области игры.
Бывает и так, что единственное оружие в игре настолько удобно, что игрок перестаёт менять его на другое и всю оставшуюся часть игры проходит с этим оружием.

Конечно, скоростное прохождение игры - само по себе неестественно и рассчитано на любителя. Но все остальные моменты довольно неприятны, когда их обнаруживаешь. Как правило, они сигнализируют о несбалансированности "геймплея". Рекомендуется отслеживать такие вещи уже на стадии планирования новых деталей игры (оружия, NPC). А дальше можно либо избавляться от недостатков, либо уравновешивать их подходящим образом.


Пример: гравипушка - весьма и весьма желанное оружие, поскольку она:

- обладает бесконечным зарядом энергии (бесконечные "патроны");
- достаточно мощная (позволяет убивать с одного удара);
- достаточно универсальная (в качестве снарядов можно выбрать большинство незакреплённых предметов);
- является одновременно инструментом (подобрать далёкий предмет, обезвредить мину, перенести тяжёлую вещь и пр.);
- позволяет отбивать любые снаряды, кроме пуль и некоторых других (либо перехватывать и отбрасывать)

Не исключено, что я даже упустил что-нибудь. Как Вы помните, в Цитадели гравипушка остаётся единственным оружием игрока - вот до чего довели разработчики её универсальность!

Тем не менее, присутствуют мощные ограничения на использование гравипушки:

- нельзя поднимать и кидать слишком тяжёлые предметы;
- очень лёгкие снаряды наносят мало повреждений;
- многие NPC проще убиваются взрывными снарядами, так что необходимо ещё наличие специфических предметов (бочек или канистр с топливом, мин и т.п.);
- радиус поражения бросками не очень велик, да и сила удара уменьшается с расстоянием

На практике, ограничений достаточно, чтобы игрок не зацикливался на гравипушке.

Примечание: в идеале, каждый новый вид оружия должен вносить ощутимые изменения в игровой процесс (а не просто ещё один набор спецэффектов и убойной силы).


Ещё один случай - когда геометрия или дизайн карты позволяют найти "выигрыш дурака" (о котором сказано выше). Это выявляется уже на практике, при тестировании, однако и довольно легко исправляется.


Как улучшить впечатление от неудачного "геймплея":

• добавить больше атмосферности игре. Это могут быть звуки, переговоры, непонятные явления, откровенно мрачная или весёлая музыка - всё, что задействует воображение. Конечно, со временем обман раскроется, но так всё равно интереснее;
• изменить "физические законы" в игре, добавить "интересные штуки". Например, брашевые триггеры с изменённой гравитацией, с толканием игрока и NPC в определённую сторону (типа ветра) и др.;
• поступить от обратного, т.е. добавить, например, "NPC из воздуха" (энтити npc*_maker, работающие на виду у игрока), кучи врагов и взрывоопасных предметов, захламление местности произвольными энтити и элементами дизайна. Конечно, есть риск "запороть" сюжет (когда он есть), превратив игру в сплошную "чернуху" или "веселуху", но с другой стороны - кто-нибудь да оценит Ваши старания;
• добавить свои текстуры, звуки, эффекты, модели, скрипты и прочее. Как вариант - хорошенько порыться в файлах игры и найти вообще не встречающиеся (или редкие) элементы. Хотя это всегда можно сделать просто для удовольствия (такого рода новинки воспринимаются игроками положительно);
• расставить триггеры в таких местах, что даже бывалый игрок (или маппер) не ожидает их там встретить (раньше или позже "положенного", за поворотом или по другую сторону стены от события, с "извращённым" смыслом и т.п.).
• избегайте "тупых" решений. Лучше одно "умное", чем десять "тупых".
  То есть, уменьшение своего/увеличение вражеского урона - "тупой" способ регулирования сложности игры (это весьма и весьма приелось, ни капли оригинальности). Достижения в игре - преимущественно "тупой" способ повышения реиграбельности (особенно для однопользовательских игр, или когда после получения этих достижений не даётся никаких игровых преимуществ/новинок).
  Регулировка трудности прохождения количеством противника или усилением его способностей или просто добавлением "шаблонных" способностей противника - довольно "тупой" метод модификации игрового процесса. "Шаблонные" способности подразумевают добавление противнику того, что игрок уже и так видел раньше (например, дать гранаты полицейским с дубинками из Сити-17, хотя так может и выйдет что-нибудь интересное). "Нешаблонные" способности - это добавление противнику каких-то скриптовых трюков поведения или не встречаемых раньше игроком способностей (например, муравьиные львы, плюющие кислотой).
  Выдача желаемого за действительное - однозначно "тупое" решение. Многие разработчики выносят на первый план то, что в итоге понравится узко ограниченной аудитории игроков - т.н. "казуалам" или наоборот "упёртым фанатам", игрокам-временщикам, игрокам "не в теме" и т.п.; да и сама особенность, на которой сделан акцент, может быть наигранной, "высосанной из пальца" и вообще мешает получать удовольствие от игры.
• если некоторые задумки выглядят "ну очень интересными" в теории, а реализация пока не оправдала надежд, попробуйте отложить их на будущее - для сюжетного продолжения мода. Я полагаю, что удачное продолжение (дополнение, следующая часть) какой-либо игры выходит не обязательно потому, что разработчики решили "срубить денег". Скорее всего - это возможность показать доработанные идеи, которые не вошли в предыдущую часть лишь потому, что их не успели отладить или довести до окончательного лоска.
  К примеру, Episode One и Episode Two весьма органично укладываются в общую линию сюжета. Я бы сказал, что общая картина выглядит довольно гладко. Из чего делаю вывод, что в создании этих двух дополнений использованы наработки со времён Half-Life 2, которые наконец-то удалось привести в нормальное состояние.
  Отсюда, надо думать, проистекает долгое молчание разработчиков относительно мира Half-life (это я о возможном Episode Three) - попросту не осталось в запасе каких-либо "полуфабрикатов", новые идеи нужно делать с нуля. Но это, разумеется, чисто мои предположения.

---

Вместо заключения

Используйте воображение, чтобы комбинировать приёмы и импровизировать на ходу - вот и всё, что я могу сказать напоследок. Практически из каждого раздела описанные приёмы можно смешивать и выискивать интересные сочетания. Но даже это не сравнится с Вашими собственными приёмами - теми, которые "взяты из головы". Хотя бы потому, что в этом будет отход от стандартов, навязываемых чтением данной статьи.
Обратите внимание: материал статьи дан с целью "разгона", "включения в процесс" разработки. Я вполне мог что-нибудь упустить, даже очевидные вещи. Можно найти что-то своё, оригинальное, развивая исходные темы. Основные направления должны быть понятны.
Так что - удачных тебе модификаций, читатель!

Номер статьи: 37