Математическое руководство по созданию компьютерных игр

3-я редакция, переработанная и дополненная

Разработчик:

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

Рецензент:

Кирилл Викторович Орлов, дипломированный кандидат технических наук.

С использованием материалов:

«Искусство программирования» ― 3-е издание, Дональд Кнут. Вильямс, 2007.

«Алгоритмы: построение и анализ» ― 2-е издание. Томас Х. Кормен, Чарльз И. Лейзерсон, Рональд Л. Ривест, Клиффорд Штайн. Вильямс, 2005.

«Как стать создателем компьютерных игр. Краткое руководство» ― В. В. Касихин. Вильямс, 2006.

«Компьютерные игры. Мимо вечности в забвение.» ― А. С. Патрашов. 2009.

«О, рандом! Или мракобесию от программирования посвящается.» ― А. С. Патрашов. 2010.

«USB-flash или маленький конец большого пиратства» ― А. С. Патрашов. 2010.

«Последний день пирата, или интернета, интернета…» ― А. С. Патрашов. 2010.

«Создание концепт-документа игры» ― С. Валиуллин. 2009.

«The art of game design. A book of lenses» ― Jesse Shell. Carnegie Mellon University, 2008.

Если хочешь что-то сделать ― лучше сделать это самому.

Народная мудрость

Не доверяй павиану.

Африканская народная мудрость

Лучший способ в чём-то разобраться до конца ― это попробовать научить этому компьютер.

Дональд Кнут

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

М. В. Ломоносов

Математические формулы не могут «принадлежать» кому-либо! Математика принадлежит Богу.

Дональд Кнут

Компьютерная игра это ожившая математика.

Примечание автора

Предисловие

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

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

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

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

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

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

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

Вступление

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

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

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

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

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

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

Вообще, понятия устаревших игр не существует. Если игра сделана правильно и не на один день, то устаревает она только для тех, кто в неё уже играл и наигрался. Через пять, в крайнем случае десять, лет вырастет новое поколение игроков, которые будут воспринимать её как новую. То, что новое это хорошо забытое старое, подходит и к компьютерным играм. Heroes of Might and Magic II не уходят с мониторов уже пятнадцать лет и не уйдут ещё не одно десятилетие.

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

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

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

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

Работа над сделанными предшественниками ошибками при создании аналогичных игр неизбежна и необходима, а теперь от перечисления того, как не надо делать, переходим к тому, как надо делать. Обычно от просчётов разработчиков страдают RPG, но элементы RPG присутствуют и в тактических и в стратегических играх, принося в них те же беды. Так что за образец для работы мы возьмём RPG. Это не значит, что всё изложенное применимо только к RPG, но просто с RPG легче работать потому, что в них ярче выражены всевозможные просчёты и ошибки.

Порядок разработки новой игры или ни шагу без бумаги

Кто бы и что бы ни говорил, но компьютерная игра это в первую очередь программа и разработка программы это проект, а на разработку проектов уже давно придумали почти всё, что только можно. Если бы мы разрабатывали конструкторскую документацию, то нам бы понадобился ГОСТ 2.103—68 на стадии разработки проекта, но этот же ГОСТ подойдёт нам и для разработки проекта программы. Правда есть ещё ГОСТ 19.102—77, который предназначен уже непосредственно для разработки программ, но он только для программ и предназначен, а у нас будет ещё предостаточно задач кроме программирования. Итак, что нам предписывают в помощь.

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

На этапе замысла игры над проектом работают приблизительно от одного до десяти человек в течении примерно до десяти дней. В работающей над замыслом игры группе могут или должны присутствовать сценарист, дизайнер, художник, программист, писатель, специалист по звуку, моделист, аниматор, маркетолог, руководитель проекта и экономист. Этот состав может меняться в зависимости от размеров и сложности запланированной игры или при необходимости возможно совмещение нескольких обязанностей или специальностей. Обычно трудозатраты на замысел игры укладываются в промежуток от 1 до 100 человекодней. Завершенный замысел игры представляет собой примерно страницу печатного текста без рисунков с достаточно полным для общего представления об игре описанием. По виду замысел игры напоминает её краткое описание на упаковке. Если подобный результат не получен, то этап надо повторять до тех пор пока не получится.

Этап второй: содержание игры. Или эскизный проект. На этом этапе описывается игровая и художественная части проекта. Определяется кто и чем будет заниматься из игровых персонажей, будет ли меняться игровой мир и так далее. Разрабатывается графический интерфейс игры. Определяются списки характеристик персонажей и мобов. Задаются размеры игрового пространства и способ передвижения. Устанавливается тип и класс будущей игры.

Независимо от количества участников предыдущего этапа на этапе содержания игры над проектом работают всё так же от одного до десяти человек, но уже в течение от 10 до 100 дней. Состав рабочей группы может быть и тот же, что и во время работы над этапом замысла игры. Трудозатраты на содержание игры находятся уже в пределах от 10 до 1000 человекодней. После того, как определены все свойства игроков, род их занятий и выбрано взаимодействие пользователя с окружением, а также состав окружения, можно переходить к следующему этапу.

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

Технически это самый сложный этап в разработке игры. Количество участников возрастает и становится приблизительно от 10 до 100, но работа над дизайном ведётся столько же, сколько и над содержанием. Состав работников проекта расширяется и некоторые специальности требуют несколько исполнителей. Участники предыдущих этапов могут войти в этот этап уже руководителями направлений разработки. назначение их руководителями целесообразно с точки зрения лучшего понимания поставленной задачи, а также их более длительного участия. Трудозатраты на дизайн игры составляют уже от 100 до 10000 человекодней. После того, как дизайн игры будет готов, можно переходить уже к непосредственно изготовлению игры.

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

Практически специалисты из предыдущих этапов не задействованы в последнем этапе, но на этапе изготовления количество исполнителей возрастает и становится от 100 до 1000. Для мелких проектов это количество может быть значительно меньше и доходить до нескольких или вообще одного человека. Также возрастает и продолжительность этапа и становится уже от 100 до 1000 дней. И опять же следует заметить, что для мелких проектов это время может сокращаться до нескольких дней или часов. Таким образом трудоёмкость изготовления игры становится от 10000 до 1000000 человекодней и является самой дорогой частью производства игры.

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

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

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

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

Объем документации на данном этапе составляет от 1 строки, до сотен страниц и содержит в себе в основном описание проекта игры и почему вообще стоит им заниматься. Для получения сотен миллионов долларов или евро надо будет писать огромные пакеты документов, со статистикой почему этот проект окупится, анализом спроса, положения на рынке и так далее. Этап выработки концепции может повторяться несколько раз при отказе от текущей концепции с выработкой новой или сразу переходить на следующий этап.

Этап 2. Прототип ― проверка концепции, чаще всего заканчивается провалом вне зависимости от объема первоначальных инвестиций. Друзьям или знакомым ведущего разработчика надоедает или им кажется что идея непригодна для разработки, инвесторы уходят в более доходные другие отрасли и происходят прочие тому подобные разрушения команды. Прототип оказывается совершенно скучным или не удается достичь никакого интересного графического представления. Для создания прототипа используется все, что можно из доступных средств, так как прототип не продают, а исключительно оценивают с его помощью идею игры. Иногда используется разработка прототипа с нуля некомпетентными в разработке или при наличии избыточного финансирования.

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

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

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

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

Объем документации составляет от нескольких до сотен страниц. Этап полировки повторяется после каждого нового функционала для сетевых игр до двух раз. Для не сетевых проектов полировка обычно смешивается с доработкой проекта вообще и поэтому, особенно при отсутствии четких планов, может продолжаться очень долго и хаотично.

Этап 5. Коммерческая реализация ― заработок на проекте. Для не сетевого проекта ― продажи, для сетевого ― выход в открытое бета тестирование. Приложение выглядит цельно, обычно отдаленно похоже на раннюю концепцию или полностью отрабатывает фокус потребительской аудитории. Но от соответствия проекта концепции его успех практически не зависит. Вообще от разработки коммерческий успех проекта зависит приблизительно на 40 или 50 процентов, при условии, что в разработке не было допущено откровенных ошибок. Объем документации складывается от описания реализации, руководства пользователя и, обычно, сайта игры. Для не сетевых игр данный этап не повторяется, но часто выпускаются скачиваемые платные или бесплатные дополнения к проекту и пакеты исправления ошибок. Для сетевых проектов, в зависимости от сложности разработки, выходы новых версий бывают в диапазоне от двух недель, до полугода и реже.

Этап 6. Поддержка ― помощь игрокам остаться в игре. Для не сетевых игр это этап после завершения продаж, когда делается все чтобы игрок и дальше продвигал игру, среди друзей или в многопользовательской среде. Для сетевых игр это параллельный разработке, полировке и коммерческой реализации этап. Объем документации состоит из инструкции, сайта поддержки и прочих подобных средств. Повторение этапа происходит после каждой реализации.

Мир игры или сюжет и вселенная

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

Очевидно, что следующей важной задачей становится поиск внутренних противоречий игрового мира. Каждый, кто хоть час играл в RPG, знает, что утверждение: тяжело в учении ― легко в бою, есть непреложная истина. Так что если в игре у игрового персонажа есть возможность пройти обучение, то игроки ей непременно воспользуются и на последующие задания для новичка с рогаткой выходит ветеран с пулемётом. Это особенно касается, как правило, тех игр, где засчитывается применение умений. Способы, как можно поднять все характеристики до предела, находятся обычно чрезвычайно быстро. Не менее странно будет выглядеть рост умений при повторении одного и того же умения по одной и той же цели несчётное количество раз. Очень часто разработчики сами оставляют дырки в заборах, а потом сами же удивляются, что их за это ругают.

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

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

Борьба с читерством и манчкинством заслуживает особого внимания. Многие игры позволяют полностью сохраняться и загружаться, что делает некоторые возможности просто находкой для прорывов. Это не относится к серверным играм и только частично к играм, сохранённые файлы состояния которых находятся на компьютере, но сохраняется игра только при выходе. Но ничего не мешает выйти из игры и сделать копию файла, чтобы потом начать заново после провала. При наличии в игре азартных игр или возможности выиграть что-то особенное эта возможность будет использована. Одна из причин всех бед том, что к игре предъявляются сразу два взаимоисключающих требования: с одной стороны игра должна длиться долго, а с другой ― каждое задание должно проходиться как можно быстрее. Приходится искать необходимое решение где-то посередине и всегда есть риск от неё отклониться, чему есть много примеров.

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

Мелочи в сценарии могут доводить до изнеможения, но нет ничего важнее мелочей. Промах сценариста может испортить игру больше, чем всех остальных вместе взятых. В Dungeon Lords один король угрожал другому королю всей своей армией, стоял перед шатрами рядом с городом, только армия его куда-то делась из шатров и оставила своего короля одного. В Fallout 3 в убежище 87 появился полковник Отем и его солдаты. Как ему удалось пройти через область смертельной для человека радиации осталось без объяснений, тем более, что выход из убежища был только через пещеры и можно было спокойно встретить Одинокого Странника там. Учитывая беспринципность Анклава непонятно, как уцелели дети в этих пещерах. И если особо выдающиеся игроки сумели дойти до входа убежища 87, то не могли в него войти потому, что дверь не действовала. Да ещё и в месте проникновения полковника осталась дверь с дырой в бездну.

Не менее странно и скомкано выглядела и концовка, когда пришлось лезть к пульту управления очистителем. Причина провала сцены была единственная: на сцене оказалось слишком много действующих лиц и возникла неопределённость. Если бы в зале управления оказалось только двое, то сцена выглядела бы естественно, а создатели игры не добавили бы себе работы в продолжении. А ведь решить вопрос могли два слова: «Оставим твоих друзей снаружи, чтобы они прикрыли нас с тыла и пошли в зал управления.» и тогда концовка была бы вполне уместная.

Уделяя внимание деталям надо помнить о том, что детали должны быть существенные. RPG игру не надо превращать в подобие тамагочи, где надо всё время помнить о сне, еде, воде и всём остальном. Однообразные действия очень быстро надоедают, если не привязаны к игровому сюжету. Если в игре будет затруднительно добывать воду и еду, то есть смысл превратить их добычу в одну из сопутствующих задач, например, как добывание запчастей и боеприпасов. Если выполнить задачу очень просто, то не надо тратить на неё время.

Игровой мир должен быть не только непротиворечив, но и не пуст. Если игра посвящена только истреблению противников, то о прочем наполнении можно забыть, но есть и другие эффективные приёмы заполнения игрового времени. В серии Fallout были многочисленные компьютеры с историей и повествованиями о событиях, а в Morrowind и Oblivion целые шкафы книг всевозможного содержания. Более того: в TES 3 и TES 4 были целые религии, которые способствовали проникновению в дух игры и поглощению её процессом. Создавая основу игры нужно помнить, что кроме необходимых занятий игроку можно добавить ещё и развлечения.

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

Враждебные персонажи или птичку жалко

Изысканная графика имеет и оборотную сторону, когда в игре приходится убивать всё подряд и это всё иногда убивать становится просто жалко. В итоге пережитой драмы настроение может испортиться надолго. Похожая история случается, когда приходится исправлять недобор опыта истреблением всего и вся, но это уже крайний случай. Да, подобные переживания бывают не у многих, но бывают достаточно часто, чтобы их игнорировать. Не так давно Besethda в своём Fallout 3 допустила тот самый досадный промах, когда разнообразие для истребления имеется, а хоть немного настроить его нельзя. И это при том, что все типы лиц для всех безымянных обитателей не меняются и возможность выбора была бы кстати, но этого не сделали, а в итоге могут возникнуть игровые драмы. На рисунках 1—3 показаны примеры. В данном случае речь идёт о впечатлениях только одного игрока, но у каждого игрока свои вкусы и надо уметь их учитывать.

Юридический взгляд тоже приходится часто учитывать. Всё тот же самый Fallout 3 пострадал от мнений критиков, что в нём полно неубиваемых персонажей, а все дети просто бессмертны. А на все эти нововведения пришлось пойти по одной единственной причине: если можно стрелять по детям из пулемёта, то разработчикам и распространителям игры могут предъявить судебный иск о подготовке теракта или ещё чего-нибудь похуже. И хотя законы нельзя нарушать, но под их действие лучше не попадать. Те же самые дети из пещер могли спокойно стать жертвами Анклава, запустившего в пещеры несколько когтей смерти. Более того, особо опасные с юридической точки зрения сцены можно оставлять за кадром и показывать только их последствия.

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