Дизайн-документ игры

В данной статье нет ни единой строки кода, т.к. дизайн-документ представляет собой обычный текстовый документ с детальным описанием будущей игры. Начинающие игрокодеры часто им пренебрегают. Тем не менее, мировая практика доказывает, что наличие дизайн-документа очень важно на любом этапе разработки игры. Без него в игрокодинге не обойтись. Даже при создании небольших инди-проектов.
Дизайн-документ игры¹ (Game Design Document) - это детальное описание разрабатываемой компьютерной игры. Диз.док. создается и редактируется командой разработчиков и в основном используется в индустрии видеоигр для организации их работы. Все участники проекта по созданию игры должны иметь доступ к нему и строить свою работу, исходя из информации, изложенной в нём. Например, когда программисту необходимо узнать, какой тип движка сражений (combat engine) будет использоваться в игре, он, конечно же, обратится к дизайн-документу и выяснит там, что игра применяет 3D-движок с использованием перемещающейся камеры (moving camera), текстурированными 3D-персонажами и приятными графическими эффектами. Возможно, он даже посмотрит несколько концепт-артов, нарисованных дизайнерами. Если проект коммерческий, то в дизайн-документе обязательно будет пункт по маркетингу игры, включающую основные фичи игры и, конечно, дату выхода игры в свет.
В то же время дизайн-документ не может охватить все аспекты будущей игры. Он лишь призван помочь упростить процесс разработки. Любопытно, что подобно тому как продюссеры и киноактёры часто воспроизводят один и тот же сценарий по-разному, разработчики игр также могут неоднозначно использовать информацию в дизайн-документе, оставляя за собой право на (небольшую) импровизацию.
Когда издатель поручает создание игры разработчикам, команда разработчиков должна создать документ, который часто связан с соглашением между издателем и разработчиком. Разработчики должны придерживаться дизайн документа во время процесса создания игры.
По теме дизайн-документирования написана не одна сотня книг. Почти все они на иностранных языках и никогда не издавались в России. Так вот, в каждой из них утверждается, что без дизайн-документа невозможно создать сколько-нибудь полноценную игру. Это всё равно что начать строительство многоэтажного дома, не вырыв предварительно котлован для его фундамента.
Дизайн-документ, как правило, создаётся по определённым правилам и имеет чёткую структуру.
Содержание дизайн-документа может отличаться даже у игр одного жанра. Но есть пункты, присущие играм всех жанров.

Дизайн-документ игры в жанре RPG (Role Playing Game)

Для масштабных игровых проектов, к которым обычно относятся практически все ролевые игры, необходимо создавать не один, а несколько дизайн-документов, в каждом из которых будет описан один из её аспектов. Это означает, что каждый компонент дизайн-проекта (история, дизайн, музыка и т.д.) делится на категории и размещается в отдельном дизайн-документе, которые часто называют книгами (books) или библами (bibles)¹ Опытные RPG-игрокодеры в общем случае рекомендуют создавать 6 таких библов:

• Мастер-библ (Master Bible)
• Арт-библ (Art Bible)
• Библ сюжета (Story Bible)
• Дизайн-библ (Design Bible)
• Библ звукового оформления (Sound Bible)
• Библ с техническими спецификациями (Tech Bible).

Каждый библ содержит информацию только по одной определённой теме.

Содержание Мастер-библа (Master Bible Content)

ГЛАВА	ОПИСАНИЕ
Содержание (Table of Contents)	Оглавление документа.
Предложение (Proposal)	Коммерческое предложение по игре, в случае представления продукта потенциальному издателю.
Введение (Introduction)	Введение в данный библ и обзор его содержания.
Концепт(Concept)	Концепт игры и её суть (idea; кратко и простым языком). Обычно здесь указывается название игры и её жанр.
Краткий сюжет (Story summary)	Краткое пересказание сюжета, с упоминанием ключевых моментов.
Представление персонажей (Character Introduction)	Список главных героев игры.
Ключевые моменты (Highlights)	Ключевые элементы игры. Например: поворотные моменты сюжета, лицензируемые движки и технологии, применяемый стиль графического оформления.
Описание игры (Game Description)	Описание того, как будет выглядеть игра.
Элементы игры (Game Elements)	Список актуальных игровых элементов, разделёный на темы (геймплей, внутриигровые персонажи, искусственный интеллект и т.д.).
Системные требования (Hardware Specification)	Необходимые требования к компьютеру (проц, видеокарта и т.д.).
Расписание (Schedule)	Временной график основных этапов разработки и конечная дата выпуска игры.
Бюджет (Budget)	Полная смета ожидаемых расходов.
Участники команды (Team Members)	Список участников команды разработчиков, либо список требуемых специалистов (с указанием необходимых знаний и навыков работы).
Маркетинг (Marketing)	Полная смета ожидаемых расходов. Информация по продвижению игры (сравнительный анализ продуктов конкурентов, целевая аудитория, ожидаемые продажи и т.д.).

Содержание Арт-библа (Art Bible Content)

ГЛАВА	ОПИСАНИЕ
Содержание (Table of Contents)	Оглавление документа.
Концепт (Concept)	Рисунки, скетчи, наброски, которые могут войти, а могут и не войти в создаваемую игру.
Сюжетная линия (Storyboard)	Цепочка событий сюжета, от которой отталкиваются художники.
Персонаж (Character)	Изображения персонажей игры.
Предметы (Items)	Изображения (подбираемых) предметов игры.
Игровые уровни и ландшафты (Levels & Terrains)	Изображения и рекомендуемые наброски карт и объектов ландшафта (деревьев, зданий и т.д.).
Волшебные эффекты (Magic effects)	Изображения магических эффектов (обычно во время сражения).
Битва (Combat)	Изображения сцен сражений (террейны, эффекты и т.д.).

Содержание Библа сюжетной линии (Story Bible Content)

ГЛАВА	ОПИСАНИЕ
Содержание (Table of Contents)	Оглавление документа.
Замысел (Idea)	Пара параграфов основного замысла игры. В свободной форме.
Общие сведения об игре (Summary)	Рассказ об игре, с упоминанием основных фич (например описание сражений, используемый игровой движок а также общей концепции игры).
История игры (Game Story)	История игры от начала и до конца.
Сюжет игры (Plots)	Список основных сюжетных событий с описанием.
Диалоги (Dialogues)	Полный сценарий с указанием каждого слова, произнесённого в игре.
История персонажей (Character history)	Бэкграунд-рассказ о каждом игровом персонаже.
Прелюдия (История для мануала по игре)	Вступительная история, которая заинтересует игрока сыграть в игру. Обычно такие истории пишутся в инструкции к игре или во вступительной видеозаставке.

Содержание Дизайн-библа (Design Bible Content)

ГЛАВА	ОПИСАНИЕ
Содержание (Table of Contents)	Оглавление документа.
Замысел (Idea)	Все идеи и решения, способные сподвигнуть художников рисовать арты к игре.
Геймплей (Gameplay)	Описание игрового процесса.
Система управления (General control)	Описание процесса управления персонажем/юнитом в игре. Например прицип перемещения персонажа с одного уровня на другой + набор команд и приёмов для сражений.
Персонажи (Characters)	Описание игровых персонажей + вся необходимая инфа по ним. Например их HP (health points, т.е. уровень здоровья), опыт, допустимое оружие и т.д.
Предметы (Items)	Список всех внутриигровых предметов + детальное описание каждого из них (например принцип использования в игре).
Магические заклинания (Magic Spells)	Список всех магических заклинаний в игре + их подробное описание (например сколько очков магии отнимают, какой дают эффект и т.д.).
Игровые уровни (Levels)	Детальное описание каждой игровой локации (уровня). Их основные фишки, в какой местности расположены, какой ландшафт и т.д.

Содержание библа звукового оформления (Sound Bible Content)

ГЛАВА	ОПИСАНИЕ
Содержание (Table of Contents)	Оглавление документа.
Звуковые эффекты (Sound effects)	Список всех звуковых эффектов игры, не являющихся голосовой речью.
Музыка (Music)	Список всех музыкальных композиций игры.
Голосовая озвучка (Voice overs)	Список всех голосовых записей (например диалоги).

Содержание библа с техническими спецификациями (Tech Bible Content)

ГЛАВА	ОПИСАНИЕ
Системный движок (System engine)	Описание основ текущего движка игры.
Графический движок (Graphics engine)	Описание графического движка игры.
Звуковой движок (Sound engine)	Описание звукового движка игры.
Система ввода (Input engine)	Описание системы ввода игры.
Сетевой движок (Network engine)	Описание сетевого движка игры.
Главная система (General system)	Описание всех остальных систем игры, не упомянутых выше.
Система графического интерфейса пользователя (GUI system)	Описание интерфейса пользователя (меню) игры.
Система скриптов (Scripting system)	Описание системы скриптов игры.
Система управления персонажем (Character control system)	Описание системы управления персонажем.
Система искусственного интеллекта (AI system)	Описание системы искусственного интеллекта, задействованного в игре.
Боевая система (Combat system)	Описание боевой системы игры.

Основы написания сюжетной линии (story) игры²

Какая игра обходится без сюжетной линии и предыстории (background story), предшествовавшей цепочке событий, имеющих место в игре? Это всё равно что герои книжного романа, появившиеся из ниоткуда.

Тема сюжетной линии (The Story Theme)

Первым делом стоит определить тематику игры. Вот несколько вариантов тем и жанров для примера:

• Научная фантастика (Science fiction)
• Средневековье (Medieval)
• Вестерн (Western)
• Постапокалипсис (Post-apocalyptic)

Существует множество других тем и вселенных, в рамках которых разворачивается сюжет игры. Основная идея здесь -выбрать одну из них и уже с ней работать. Возьмём к примеру игру "Star Wars: Galactic Battlegrounds", основанную на известной книжной саге "Звёздные войны" Джорджа Лукаса. Конечно, она относится к жанру научной фантастики. Другой пример игровой вселенной - "Stronghold", где всё крутится вокруг создания своих средневековых зАмков и захвата чужих. Рекомендуем выбирать тему сюжета, которая в самом деле нравится и интересна. Так новые идеи будут приходить куда быстрее.
Допустим, твоя игра про то, как злой волшебник (evil wizzard) терроризирует маленький городок и герой должен уничтожить его (волшебника). Такая тема слишком пространна (broad, широка) и её необходимо сузить. Почему волшебник творит свои злые дела? Что привело к такой ситуации и причём тут главгерой? У всего происходящего должны быть свои причины. Даже в то время как многие игры не раскрывают этих причин, у героя должна быть веская причина оказаться в нужное время в нужнм месте. Мысленно развивай эту идею. Например, главгерой был совсем ребёнком, когда злой волшебник был игнан (banished) из города. Продолжай делать наброски к тексту, пока не почувствуешь, что уже достаточно информации для перехода к следующему шагу.

Элементы сюжетной линии

Существует два основных элемента без которых не обходится написание любого сюжета:

• фабула (plot);
• цель (purpose).

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

Фабула (Plot)

У любого хорошего сюжета обязательно есть фабула (или "зачин"). И игровой сюжет здесь не исключение. Фабула придаёт сюжету глубину и значимость. Игроки более мотивированы играть и выигрывать, когда у них есть причины для этого. Один из лучших примеров этого - игра "Command & Conquer" (Westwood Interactive). В ней братство NOD сражается с альянсом GDI за контроль надо полями тиберия (tiberium; что-то вроде ядовитого минерала). Если из игры убрать тиберий, то игроки будут немало удивлены, зачем вообще NOD и GDI сражаются друг с другом.
Фабула определяет серию событий, ведущих к главной цели игры. Наличие фабулы даёт твоему дизайн-документу и игре вцелом хорошую сюжетную подоплёку (story foundation), с которой будет вестись работа. На чём бы ни была основана фабула, будь то война, обман (deception) или даже финансы, - она безусловно очень важна.

Цель (Purpose)

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

Обозначаем игровые задачи (objectives)

Когда сюжет готов, мы можем на его основе обозначить непосредственные игровые задачи, вытекающие из главной цели игры. Раз у игрока есть главная цель (purpose), то каковы же задачи (goals)? Наличие хорошо продуманных задач очень важно для игр многих жанров (Action, FPS, стратегии и др.). Ты же не хочешь, чтобы в процессе игры игрок без конца задавался вопросом "что тут нужно делать?"? Лучший способ обозначить игровые задачи - это выписать основную идею победы и затем разделить её не несколько простых шагов.
Возьмём, к примеру, небезызвестную игру "Warcraft" (Blizzard Entertainment). В ней основная цель - побороть орков или людей, в зависимости от того, за какую расу играет игрок. Пока всё звучит довольно просто, так что давай разобъём эту цель на более простые задачи (goals).
Первая задача - построить город, пригодный для создания армии. Эта задача, в свою очередь, состоит из нескольких других подзадач (subgoals), как например постройка адекватного жилья, сбор необходимых ресурсов, а также покупка необходимых апгрейдов для инвентаря. И вот, набор игровых задач готов! Погружаясь в игру с головой, обнаруживаешь множество других задач, которые прямо или косвенно ведут игрока к победе. Важно чтобы этот набор был максимально простым. Большинство игроков отнюдь не жалют сотни внутриигровых задач. Принимая это во внимание, начинаешь осознавать, что самая продаваемая стратегическая игра всех времён и народов обладает довольно простым набором внутриигровых задач.

Правила написания хорошей истории

Это, скорее, рекомендации. Самые крутые истории часто выходят за рамки любых правил.

• Не перестарайся (Don't overwrite). Как только история приобретает форму и близится к концу, начни вырезать "пустые" ("dead-weight") и малозначимые эпизоды. Оставь только тот контент, который идеально ложится в канву повествования.
• Не вдавайся в подробности (Don't explain too much). В нашем безумном мире каждый предмет имеет свою собственную историю. Переизбыток всего может заметно поубавить жажду дальнейших открытий. Здесь необходимо решить, какие из аспектов истории заслуживают более детального объяснения, а какие нет. Что игроку важно знать, а что нет.
• Будь последовательным (Be consistent). Допустим, ты ужк выбрал подходящий голос, установки персонажа, атмосферу сюжетной линии. Лучший совет здесь - "прилипнуть" (stick) к ним. Ничто так не разрушает работу надо сюжетной линией как отстранение от заранее намеченного пути. Не переключай сцены в неподходящие для этого моменты, не излагай факты в неподходящей для этого обстановке, не меняй личных качеств персонажей и/или их голоса.
• Излагай историю доступным языком (Use good language structure). При написании своего первого черновика используй сокращения, аббревиатуры, символы и простые фразы для уменьшения временных затрат. При написании второго черновика убедись, что заменил все сокраения на корректные предложения.
• Будь аккуратнее со "специями" (Don't over or under spice). Приправив сюжетную линию хитрыми словами, ты можешь иной раз придать ей особенное креативное звучание. Но тут важно не переборщить. Если читатели (и игроки) будут вынуждены лезть в словарь чаще, чем 1 раз за 1 игровой экран, то это сильно уменьшит привлекательность игры вцелом. Если ты искушённый писатель, помни, что повара тратят уйму времени на то, чтобы выработать идеальный рецепт лучшего вкуса. Писателю тоже требуется потратить некоторое время на достижения баланса в текстовом творении. Работай над текстом пока не убедишься, что уровень специй как раз тот, что нужен.
• Излагай чётко, последовательно и по делу (Be clear, concise and to the point). Это правило обретает силу уже после первого черновика. Перечитай свой текст и убедись, что хорошо понимаешь написанное (допустим, можешь расшифровать хотя бы половину слов из текста). Убери ненужные слова и убедись, что оставшийся текст передаёт суть.
• Продвигай свои собственные мнения и взгляды на происходящее (Don't force your opinios or views). Жизнь невероятно трудна, когда кто-то постоянно говорит тебе, что делать, говорить, думать или чувствовать. Читатели достаточно умны, чтобы самостоятельно выбрать свой собственный путь. Поэтому не форсируй собственные убеждения в тексте, который будут читать ничего не подозревающая публика. Особенно не стоит сообщать читателям своё скромное мнение о событиях, которые вообще не входят в сюжетную линию игры. Позволь читателям сформировать своё собственное мнение. Другими словами, пиши свою сюжетную линию так, чтобы воображаемые читатели самостоятельно могли строить свои догадки и суждения о происходящем в игре.
• Веселись (Have fun). Если ты не получашь удовольствие от того, что пишешь, то зачем вообще этим заниматься? Твоё отношение к своему тексту видно читателю. И если тебе нравится текст,он непременно заметит это.
• Бэкграунд-истории (Back-stories). Владельцы антикварных лавок нередко подлавливают зазевавшихся посетителей, уставившихся на тот или иной экспонат и начинают часами рассказывать бэкграунд-историю, связанную с этим предметом. Нетрудно догадаться, что свою бэкграунд-историю имеет каждая вещь вокруг. Твои персонажи имеют прошлое - т.е. причины оказаться в нужное

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

Изучаем сюжет игры "Empire Earth" (RTS, Sierra Inc.)

На основе вышеизложенного материала разберём сюжет игры Empire Earth g1 и выделим из него несколько игровых задач (objectives). За основу возьмём задачи одиночного режима против компьютера (single player skirmish).

Описание (Description)

Игра "Empire Earth" очень похожа на "Age of Empires" (Microsoft). Здесь игрок развивает цивилизацию в течение нескольких эпох (Каменный век, Тёмное время, Средневековье и др.) Основное отличие "Empire Earth" от своего более старшего собрата заключается в том, что ты развиваешь свою цивилизацию намного глубже и дольше, чем в "Age of Empires". Фактически можно развиться до технологий будущего. В игре есть несколько задач.
Игроку необходимо не только строить свою цивилизацию на протяжении нескольких эпох, но и вести войны с другими цивилизациями до тех пор, пока тот не выйдет из них единственным победителем. Существует много способов победить в игре. Один из самых широко применяемых - военный поход с целью стереть врагов с лица Земли.

Начальные задачи (Early goals)

Игра начинается незатейливо. Перед игроком небольшая столичная деревушка с пригоршней жителей (citizens). В таком виде цивилизация явно долго не протянет. Одной из первых задач является сбор ресурсов для развития города. В свете того, что местные здания строятся из дерева, очевидно, что первой задачей будет отправить граждан в лес для рубки близлежащих деревьев.
Из этой задачи вытекает другая. Что поможет быстрее и эффективнее валить лес? Самое простое - увеличить число граждан, занятых на лесоповале. Вариант покупки бензопил для пещерных людей не рассматривается.
Обратной стороной покупки дополнительных граждан является то, что для них потребуется больше еды. Как видим, еда также является жизненно необходимым (vital) ресурсом. Поэтому игрок всё время балансирует между увеличением числа рабочих и объёмов производимой еды. Задачи по увеличению численности рабочих и наращиванию производства еды для них называются взаимозависимыми (interdependent).
В процессе развития, игрок понимает, что для полноценного развития инфраструктуры города также необходимы другие ресурсы. Главные из них - железо (iron) и золото (gold). Без них игрок не сможет покупать многие вещи, без которых невозможно выжить. Таким образом дописываем ещё одну цель - добыча железа и золота.

Ключевые задачи (Milestone goals)

Игра "Empre Earth" начинается в доисторический период. Для перехода в следующую эпоху необходимо собрать определённое количество еды. Это вполне логично: развитие цивилизации невозможно без достаточного количества съестных припасов. Когда цивилизация готова перейти в очередную эпоху, игрок тратит необходимые для этого ресурсы и ждёт какой-то короткий промежуток времени. Самое приятное, что после перехода в новую эпоху игрок получает возможность строить новые виды зданий и сооружений, которые, в том числе, позволяют тренировать улучшенных пехотинцев. Значит перейти в очередную эпоху является т.н. ключевой задачей. Всего в игре "Empire Earth" представлено 13 эпох. Каждая из них даёт определённые преимщества игроку и развивает игровой процесс (gameplay). Несмотря на то, что ключевые задачи - это море веселья, их не должно быть много. Сведя количество ключевых задач к минимуму, ты не позволишь игроку зпутаться в них. Прожжённые игроки, конечно, не тупые. Но ты должен создать игру, начать играть в которую будет интересно любому.

Конечные задачи (Finihing goals)

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

Боевые единицы (Combat Units)

Есть множество стратегических игр, где боевые единицы поросту отсутствуют (SimGolf, SimThemePark, Sims и др.). Но здесь мы обсуждаем стратегию с боевыми единицами (юнитами).
Все военные (combat-oriented) стратегии имеют определённый набор боевых юнитов. В одних играх их содержится больше сотни различных видов (Total Annihilation), другие - обходятся десятком видов. Главное здесь - соблюсти игровой баланс. При разработке собственной системы юнитов советую выбрать 1 вид, который нравится больше всех. Кроме того желательно чтобы его существование не зависело от других юнитов. Самолёт на авианосце - плохой выбор. В то время как танк - вполне подойдёт.
Следующий шаг - сделать зарисовку (скетч, набросок) выбранного юнита. (Да, можно на обычной бумаге.) Во время рисования ты самостоятельно выберешь наиболее подходящее вооружение для него, размеры а также вид шасси, которые он использует. Вышеперечисленные пункты являются ключевыми элементами при разработке т.к. подавляющее большинство боевых единиц всегда имеет следующие 4 характеристики: стоимость (производства), скорость движения, уровень брони (armor) и огневой мощи (firepower, ammo).

Стоимость юнита (Unit Cost)

Производство любого боевого юнита должно стоить игроку определённого количества ресурсов. Если боевые единицы будут достаточно дёшевы в производстве, то игрок изготовит целую армаду железных монстров и будет активно использовать общую игровую тактику под названием "раш" (rushing).

Раш (Rush)

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

Скорость передвижения юнита (Unit Speed)

Любой юнит должен обладать скоростной характеристикой (speed factor). Типичным подходом в RTS является делать большие юниты более медленными, а малые и менее защищённые - более быстрыми. Чаще всего это работает неплохо. Но рекомендуется, конечно, принимать в расчёт и другие характеристики юнита, а не только его размеры. Другим фактором, влияющим на скорость юнита, является его проходимость (способность перемещаться) по разным видам твёрдой поверхности либо водной глади. Если это морской юнит, то он изначально будет медленнее своего наземного собрата.
Что касается математического обоснования скорости юнитов, рекомендую разработать простую систему от 1 до 100, где 1 -самая малая сорость, 100 - самая большая. С помощью такой системы ты легко можешь вычислять скорость движения юнита по любой из поверхностей путём обычного её перемножения на коэффициент "пробуксовки" (propulsion).

Броня юнита (Unit Armor)

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

Вид брони (Armor)	Повреждения открытым огнём	Баллистические поврежд. (пули, снаряды)	Химические поврежд.
Пеший солдат	0.1	0.2	0.5
Тяжёлый танк	0.9	0.7	0.8
Лёгкий танк	0.7	0.6	0.7

Здесь перечислены 3 типа брони у трёх разных юнитов и степень повреждений, наносимых соответственно открытым огнём, баллистическими снарядами и химическими веществами. Отсюда можно легко вывести простой алгоритм расчёта нанесённого урона. Допустим, степень повреждения умножаем на коэффициент защиты (armor rating) и вычитаем полученное произведение из количества очков брони юнита. К примеру, допустим, вышеупомянутый огнемётчик попадает в пехотинца, причиняя ему 100 очков повреждений. По следующей формуле вычисляем: 100 (нанесённый урон) х 0.1 (рейтинг брони) = 10 очков урона отражено бронёй.
Отсюда получаем, что пехотинец получает след. уровень повреждений: 100 (нанесено) - 10 (отражено) = 90 очков урона получено.
Как видно из вышеприведённого примера, огнемётчик очень эффективен против брони пехотинца. А теперь подсчитаем, какой урон он нанесёт танку:
100 (нанесено) х 0.9 (рейтинг брони) = 90 очков урона отражено. 100 (нанесено) - 90 (отражено) = получено 10 очков урона.
Броня танка более эффективна к открытому огню и, как результат, урон минимален. При этом мы пока не касались темы хитпоинтов.

Хитпоинты (Hit Points)

Термин "хитпоинты" берёт своё начало в олдскульных ролевых играх (необязательно компьютерных). Но он активно применяется и по сей день при разработке огромного числа военно-тактических компьютерных игр. Теперь ты знаешь, как подсчитать уровень защиты (брони). А теперь рассмотрим вопрос, какой именно урон способен выдержать каждый из юнитов, прежде чем будет уничтожен.
Здесь нет каких-либо сложных алгоритмов расчёта. Просто каждый юнит имеет определённое количество хитпоинтов, истратив которые он умирает/взрывается.
Вернёмся к примеру с бронёй. Пехотинец (infantryman), который получил 90 очков урона (points of damage), при этом изначально имея всего не более 50 очков, погибает. Танк, получивший 10 очков урона и имеющий изначально 1000 очков, останется на ходу.
Для простоты расчётов рекомендуем в игре создавать шкалу от 50 до 5000 хитпоинтов. В этом случае самый слабый юнит будет иметь 50 очков, самый сильный - 5000.

Огневая мощь юнита (Unit Firepower)

Угрозой для брони является огневая мощь. Начинающие игрокодеры должны с осторожностью наделять юниты этим параметром. Если огневая мощь юнита окажется несбалансированной, все игроки будут использовать только один это юнит и игра станет скучной. У огневой мощи есть несколько составляющих: скорострельность (rate of fire), тип урона (damage type), спецурон (special damage) и скорость полёта снарядов (velocity).

Скорострельность (Rate of fire)

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

Расчёт скорострельности
Самый верный способ рассчитать скорострельность оружия - это определить, сколько выстрелов в минуту из него можно произвести. Это даёт нам хорошую основу для разработки собственной системы выставления параметра скорострельности (Rate of Fire, ROF; Rounds per Minute, RPM). Вот несколько примеров скорострельности реального оружия:

Вид ружия	Выстрелов в минуту (Rounds per minute)
Пистолет калибра 9мм	120
30-мм пулемёт (machine gun) M1917A1 с водяным охлаждением	400-600
PS43 (пистолет-пулемёт Судаева)	700
81-мм мортира (mortar) M1	18

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

Тип урона (Damage type)
Частично мы упоминали об этом, рассматривая броню юнита. Каждое оружие должно иметь свой собственный тип повреждений, ассоциированный с ним. Автоматическое оружие будет иметь снарядный (projectile-based) тип повреждений, огнемёт - огневой (fire-based). Общий совет: выпиши типы повреждений для каждого из своих юнитов в общую таблицу. Позднее она тебе пригодится.

Специальный урон (Special damage)
Специальным называют урон, причинённый непрямым действием оружия. Яркий пример - взрывная волна, которая разбрасывает в стороны живую силу противника и повреждает рядом стоящие здания. Другой пример - ядовитый минерал Тиберий (Command & Conquer). При прохождении солдат по полям Тиберия их хитпоинты заметно убавляются сами по себе, т.к. (согласно сюжета) в таких районах присутствует ядовитый газ. Можно придумать множество других источников специального урона. Для простоты изложения специальный урон в книгах часто называют дополнительным.

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

Менеджмент ресурсов в RTS (RTS Resource Management)

Какая же Real Time Strategy обходится без менеджмента ресурсов? Именно он лежит в сердце большинства успешных RTS. В "Warcraft" в качестве ресурсов выступали древесина, золото и камень, в "Command & Conquer" - Тиберий, в "Age of Empires" -древесина, золото, камень и еда. Этот список можно продолжать долго.
Кто-то скажет, что систему менеджмента ресурсов в игре разработать нетрудно. В той же "Empire Earth" система менеджмента ресурсов сложна и разветвлена. В предыдущих главах мы рассмотривали её с точки зрения игрока. Теперь рассмотрим с точки зрения разработчика.

Выбери свой яд (Pick your poison)

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

Определение видов ресурсов в игре (Defining resources)

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

Сбор ресурсов (Gathering Resources)

После определения внутриигровых ресурсов, необходимо решить, каким образом игрок будет их добывать. Начнём с еды (food).
В случае с игрой в sci-fi-вселенной (в жанре научной фантастики) не стоит отправлять людей на сбор урожая. Вместо этого применим т.н. гидропонику (hydroponics). Т.е. еду собирает некий гидропонический механизм (hydroponics machinery). Вся соль кроется в том, как они её могут построить. Будет чересчур скучно, если игрок сможет строить машины для производства еды (food machines) в любом месте игровой карты. Поэтому ограничим места их работы специальными участками (patches), на которых произрастают водоросли (algae). Теперь игра уже станет чуточку интереснее. Даже имея в игре всего один ресурс, мы усложнили задачу, разрешив игроку ставить фабрики по производству еды лищь в определённых участках карты. Отсюда можно выписать ещё одну игровую задачу - обнаружить участки произрастания водорослей, на которых затем построить машины по производству еды.
Второй ресурс - руда (ore). Его добычу организуем по схожему принципу. Только теперь вместо машин по производству еды игроку понадобится построить шахтовые сооружения (mining equipment). И строить он их сможет лишь в специальных участках - миниеральных месторождениях (mineral deposits). Уже на этом этапе, работая над игровыми ресурсами, мы можем генерировать новые игровые задачи.
Последний ресурс - топливо (fuel). Его добычу организуем схожим образом. Для производства топлива игроку необходимо построить нефтеперерабатывающие заводы (refinery). И, конечно, строитб их можно только на нефтяных месторождениях. Таким образом процесс определения игровых ресурсов сводится к следующим шагам:

• Определить необходимые в игре ресурсы.
• Определить методы их добычи.
• Определить ограничения (constraints) для сбора ресурсов.

Баланс ресурсов (Resource Balance)

Баланс - является ключевым аспектом любой RTS-игры. Игровые ресурсы также нуждаются в балансировании.

Пример несбалансированной игры (Unbalanced Example)

В качестве примера рассмотрим старую игру "Total Annihilation" (Cavedog Entertainment). В ней игрок добывает металл (metal) и энергию (energy). Всего два ресурса - проще некуда!
Главная проблемы игры состоит в том, что игроки никак не ограничены в сборе ресурсов. Машины, вырабатывающие энергию и перерабатывающие металл, могут быть размещены где угодно на карте. Кроме того игрок может создавать их в неограниченных количествах. Это создаёт некоторые проблемы, связанные с тем, что игрок может наглухо отгородиться от соперника, собрать все необходимые ресурсы и затем атаковать противника, встретив минимум сопротивления. Из этого делаем вывод, что создатели TA просто упустили из виду один из шагов во время определения игровых ресурсов при разработке дизайн-документа. И этот шаг как раз связан с созданием ограничений (defining constraints). Если у игроков не будет ограничений в способах и времени сбора ресурсов, то такая игра быстро лишится баланса.

Пример сбалансированной игры (Balanced Example)

Большинство коммерчески успешных игр отлично сбалансированы. Яркий пример - игра "Command & Conquer" (1995, Westwood Ent.). Деятельность игроков на игровой карте сильно зависит от местного особо ценного минерала Тиберия (Tiberium). Тиберий может распространяться по земной поверхности ("разрастаться"), правда очень медленно. Поля Тиберия не могут однозначно принадлежать кому-либо из игроков хотя бы потому, что на них нельзя строить сооружения, а пешие солдаты, оказавшиеся в зоне действия газов Тиберия, получают отравления и их хитпоинты уменьшаются буквально на глазах, причём даже без единого вражеского выстрела. Вот и ещё одно отличное ограничение - запретить игрокам безнаказанно обладать источником ресурса. Когда жизненно необходимый ресурс будет иметься на игровой карте в ограниченном количестве, игрок будет с бОльшим азартом решать игровые задачи.

Скорость сбора ресурсов (Gathering Rate)

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

Деревья технологий в RTS (RTS Technology trees)

В то время как ресурсы являются "сердцем" любой RTS-игры, дерево технологий представляет собой её "скелет". Абсолютно всё, что происходит в RTS-игре зависит от дерева технологий. Дерево технологий определяет развитие (эволюцию) технологий в RTS-игре.
Возьмём, к примеру, огонь, являющийся основным строительным блоком технологического развития человечества. От технологии "огонь" можно ответвить две других технологии: "пар" и "металлургия", т.к. обе они использую огонь. От "пара" можно ответвить технологию "паровой двигатель" (steam engine). Логично предположить, что раз люди изобрели пар, то вскоре изобретут и паровой двигатель.
Один только этот пример показывает, какое место развитие технологий занимает в игре. Игрок начинает с базовой технологии (иногда с нескольких) и затем развивается, постепенно достигая новые и новые игровые цели. Так например в серии игр "Цивилизация" (Sid Meyer's Civilization) одни игроки выберут развитие инфраструктурных технологий, другие будут развивать военные ветви.

Различные типы технологий (Different types of Technology)

Для разработки дерева технологий в своей игре, необходимо сперва рассмотреть, на какие типы они подразделяются. Вот наиболее часто встречающиеся в играх типы технологий:

• Инфраструктура (Infrastructure),
• Оружие (Weapons),
• Усовершенстования (Upgrades).

Инфраструктурные технологии

Данный базовый тип технологий имеет дело с инфраструктурой цивилизации, развиваемой игроком, с её строительными блоками. Без инфраструктурных технологий игрок не сможет создавать какие-то более продвинутые вещи. Например, в игре "Age of Empires" (Microsoft Games) игрок попросту не сможет купить кавалерию (cavalry), пока не построит конюшни (stable). В совю очередь конюшни не смогут быть построены, пока не будет "исследована" вторая эпоха (second age). Перечисленные здесь технологии являются основой инфраструктурного узла дерева технологий.

Оружейные технологии (Weapon Technology)

Во всех великих стратегических играх присутствует оружие. Следовательно наличие "оуржейного" узла (weapon node) в твоём дереве технологий очень важно. Его важно создавать максимально логичным и доступным для понимания. Была такая прикольная игра "Alpha Centauri" (клон Цивилизации на первооткрытой планете у одной из ближайших к нам звёзд Альфа Центавра). В ней было очень запутанное дерево технологий. В свете того, что игра создавалась во вселенной научной фантастики (Science Fiction), все здешние технологии носили фантастические названия, весьма оторванные от современной действительности. Это создавало проблему, когда дизайнеры знали, что имели в виду, но большинство игроков просто не понимали, что они имели в виду. Отсюда можно сделать вывод, что создавая Sci-fi игру не стоит создавать свой уникальный язык для неё.

Технологии усоврешенствований (Upgrade Technology)

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

Цена технологий

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

• Убедись, что разработка новой технологии занимает определённое время. Чем ценнее и сложнее технология, тем больше времени требуется на её "исследование".
• Убедись, что технология требует ресурсов, с которыми она так или иначе связана. Другими словами, не требуй для исследования технологии ресурсов, которые в принципе там не нужны.
• Убедись, что технология стоит резонного объёма ресурсов. Более ценная технология должна стоить немало. Конечно, здесь тоже важно знать меру. Хуже всего, когда технология стоит больше ресурсов, чем она впоследствии способна дать.

Режим кампании (Campaign Game)

Как только ты выбрал основную тематику своей игры, наметл основные игровые цели (goals), определил ресурсы и набросал на бумаге дерево технологий, пора перейти к разработке режима кампании. Уверен, ты хоть раз проходил кампанию в RTS-играх за ту или иную сторону. В общих чертах кампанией называют серию срежиссированных (prescripted) игр, которая постепенно раскрывает перед игроком детали сюжета игры. А режиссируют эту серию как раз разработчики. В отличие от мультиплеера (multiplayer) или скирмиша (skirmish), кампания намечает возможные риски и награды, связанные с ними. К примеру в игре "Emperor: Battle for Dune" (Westwood Ent.) режим кампании требует от игрока проявить преданность выбранному Дому, возглавив небольшой отряд пехотинцев в битве. По ходу развития сюжета будут ставиться и более сложные задачи. Как правило, со временем задачи (tasks) становятся более продолжительными и сложными.

Редактор миссий (Mission Editor)

Каждая отдельная игра (карта, этап) кампании называется мИссией (mission). Очевидная причина такого названия является тот факт, что ты (как разработчик) отправляешь игрока на задание, в котором есть как риск (risk), так и вознаграждение (reward). Ну чем не миссия? Обычно миссии жёстко заскриптованы (prescripted). Поэтому наша первоочередная задача как разработчиков - создать редактор миссий. Обычно редактор миссий встроен в основной внутриигровой редактор. Ниже мы рассмотрим лишь теоретические основы создания редактора миссий.
Большинство стратегических игр содержат 20-30 одиночных миссий (single-player missions). Обычно этого для игроков достаточно, пока не подоспеет очередной add-on c пачкой новых миссий (mission pack). Ты всегда должен планировать в своих играх возможность последующего расширения в степени, достаточной для установки дополнительных пачек миссий или сиквелоа (sequels). За примером далеко ходить не надо. Всё та же "Age of Empires" довольно быстро "обросла" множеством эддонов. Другой пример - игра "RollerCoaster Tycoon". Если изучить всю серию этих игр, можно обнаружить сотни всевозможных эддонов для неё.

Цели миссий (Mission Goals)

Мы довольно подробно разобрали игровые цели (задачи, goals) чуть выше, но до сих пор не рассмотрели их в отношении отдельных миссий. В отличии от игровых целей, которые являются общими сразу для всех миссий в игре, цели миссий уникальны. При разработке игровых миссий подумай, что необходимо сделать игроку для продвижения по основному сюжету (stroy line) игры.
Миссии не должны сводиться к тривиальному "сделать что-то". Вместо этого миссии должны укладываться в общую канву сюжета.
В каждой миссии должна быть хотя бы одна специфичная цель (goal). Будь то спасение заложника, разгром танковой колонны или обнаружение секретного убежища противника, - цели миссий очень важны для геймплея.

Режим мультиплеера (Multiplayer gamning)

Многие игроки даже не заглядывают в режим кампании, сразу переходя к многопользовательским игрищам через Интернет. В любой хорошей RTS-игре обязательно пристусттвует мудьтиплеер через Интернет или локальную сеть (LAN). Технологически сетевое взаимодействие обычно происходит посредством технологии низкоуровневых сетевых сокетов (Sockets) либо с применением DirectPlay.
В зависимости от сложности игры, многопользовательский режим как правило поддерживает одновременную игру 4-8 игроков одновременно. Главным ограничивающим фактором здесь выступает максимальное число юнитов, разрешённое для каждого игрока. Если в игре ожидается до 200 юнитов у каждого игрока, присутствие на одной карте сразу 8 игроков может создать кучу проблем. Для начала рекомендую сделать поддержку 6 игроков. А там посмотришь по обстоятельствам. Существует множество технических трудностей, связанных с реализацией в игре многопользовательского режима. Одна из них - поддержка сохранений в режиме мультиплеера. Очень немногие игры поддерживают такую фичу. Одна из самых известных - "Age of Empires II". Между тем, данная опция крайне необходима. Ведь многие сетевые баталии длятся по нескольку часов подряд.

Планирование проекта игры (Planning Game Project)

• Часто называют менеджментом проекта (Project mamagement).
• Необходимо при разработке любой игры.

Между тем, многие разработчики часто пренебрегают планированием, сразу переходя к кодингу. Обычно такой подход приводит к упущенным вехам развития (milestones), хаотичной разработке, измотанным участникам команды разрабов и даже к отмене всего проекта. Даже если в твоей команде всего 1-2 человека и вы пишете очередной клон Tetris, обязательно удели время планированию будущего проекта. Результат не заставит себя долго ждать.
Каждый разработчик (или команда) имеет свой собственный подход к менеджменту проекта. Так что представленный ниже план можно просто взять за основу. В этой главе мы рассмотрим следующие аспекты планирования проекта:

• Фаза обсуждения вИдения будущего проекта (Envisioning phase)
• Фаза требований (Requirements phase)
• Фаза подготовки технической документации (Technical documentation phase)
• Фаза разработки (Development phase)
• Фаза тестирования (Unit Testing phase)
• Фаза релиза (Production phase)
• Дистрибюция (Distribution).

Но обо всём по порядку.

Фаза обсуждения вИдения будущего проекта (Envisioning phase)

Это тот самый момент, когда ты стоишь на краю бездны. Только ты и твой ум устанавливают границы того, что лежит за её пределами. Часто данный этап называют креативной фазой (creative phase). Именно здесь ты должен озвучить свою суперидею игры, которая сразу затмит все остальные идеи. Идею, которая приведёт к твоим дверям миллионы игроков. Идею, которая навсегда изменит мир компьютерных игр! Если, конечно, ты не Сид Мейер или Джон Кармак, то можешь сделать свои планы чуточку приземлённее. Например, изменить часть мира компьютерных игр. Хотя кто его знает, всякое может случиться.
Так вот. На стадии обсуждения видения будущего проекта ты выступаешь с идеей своеей игры. Раз уж здесь мы говорим об играх жанра стратегии в реальном времени (RTS), перед выступлением постарайся ответить на следующие вопросы (даже самому себе):

• Какого типа будет данная стратегическая игра: в реальном времени или пошаговая (turn-based)?
• Игра будет основана на реальных или выдуманных (fiction) событиях?
• В какой исторический период развернутся действия игры: Средневековье, Гражданская война 19 века, Вторая мировая война или в далёком будущем?
• Будет ли это одиночная игра, мультиплеерная либо будет сочетать в себе оба режима.
• Графика в игре будет 2D, 3D (трёхмерная) либо в игре будет сочетание обоих видов графики?
• Сколько времени в среднем занимает прохождение одной миссии (карты)?
• Какова цель (goal) игры?
• Игра будет больше стратегической или тактической?
• Игра будет простой или сложной (complex)?
• Как можно выиграть в игре?
• Как можно проиграть в игре?
• Сколько времени потребуется для прохождения всей игры?

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

Наброски видения (Envisioning Outline)

Лучший метод систематизации идей - это выписать их на обычном листе бумаги. Взгляни на этот пример:

Готово! В результате перед нами простой набросок будущей игры. Из наброска видно, что в планах создать игру по мотивам сражений известного генерала Паттона в период Второй мировой войны (World War II). Также можно отметить, что сражения (combats) будут основываться на пеших юнитах с поотрядным контролем. Черновик утверждает, что игра тяготеет к реализму. Реализм будет достигаться путём создания т.н. "Тумана войны" и путей доставки провианта и боеприпасов. Читая данный черновик, можно выявить основную идею игры - реалистичную танковую стратегию во вселенной Второй мировой войны. Конечно, осталось определить ещё сотни других аспектов. Но для первой фазы этой информации вполне достаточно.

Фаза требований (Requirements phase)

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


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

Фаза технических требований (Technical Requirements)

Менеджеры по продукту (Product Managers) и дизайнеры завершили свою работу. Теперь за дело берутся программеры. Их задача - на основе документа с требованиями к игре создать документ с техническими требованиями. Если при планировании игры ты пропустил какой-либо пункт в документе с требованиями, не удивляйся потом, что его не окажется в документе с техтребованиями, в котором те же самые пункты расписываются с точки зрения программиста (Например: "Данная фича требует отдельного приложения, которое содержит только код сетевой игры..."). Ни слова про маркетинг и прочую "чепуху"! Только програмистские штучки.
В отличие от документа с требованиями, документ с техтребованиями не так гибок. Оно и понятно, переделывать исходный код, в случае появления исправлений, куда сложнее, нежели править черновики.

Фаза разработки (Development phase)

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

• Контроль исходного кода (Source code control)
• Менеджмент релизных меток (Release Label management)
• Отслеживание багов (Bug tracking)
• Тестирование модулей (Unit testing).

Рассмотрим каждый из них подробнее.

Контроль исходного кода (Source code control)

Контроль исходного кода обычно представляет собой размещение кода в файле виртуальной библиотеки. С каждой глобальной (major) ревизией или багфиксом (bug fix) игрокодер проверяет исходный код библиотеки, вносит изменения и снова проверяет. Каждый раз при проверки кода и внесении изменений создаётся т.н. "ревизия" (revision). Применяя данный метод (обычно выглядит как специальное дополнение контроля версий к IDE либо отдельное приложение вроде WinDiff), программист может возвращаться к предыдущим версиям кода. Иногда это необходимо.

Существует множество программных продуктов, помогающих контролировать исходный код.

Менеджмент релизных меток (Release Label management)

С его помощью ты получаешь преимущество чётко помечать релизы исходного кода. Обычно, когда ты достигаешь определённого этапа (milestone) в разработке, ты проверяешь весь исходный код и ставишь на него специальную метку (label). Это позволяет возвращаться назад и проверять все предыдущие версии исходного кода, необходимые для его компиляции на определённом чекпоинте (checkpoint). Рассмотрим для примера список:

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

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

Отслеживание багов (Bug tracking)

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

• Трэкинг (Tracking)
• Трэкинг исходного кода (Sourcecode Tracking)
• Метрики качества (Quality metrics)

Трэкинг (Tracking)
Сводный список всех багов позволяет легко увидеть проблему, которая возникла во время разработки. Это бывает крайне полезно, когда требуется вернуться назад и просмотреть каждый, обнаруженный ранее баг. Эту информацию обычно используют для неповторения одних и тех же ошибок в будущих проектах.
Трэкинг также полезен для того, чтобы просто не забыть исправить тот или иной баг. Во время разработки ты можешь столкнуться с кучей проблем и посерьёзнее. Уверен, один баг не приведёт к падению приложения, но он по-любому должен быть пофиксен.
Большинство систем отслеживания багов (bug tracking systems) позволяют указывать т.н. "важность" (severity) бага, т.е. выставлять приоритет.
Другим преимуществом таких систем является то, что сведения о багах могут добавлять обычные пользователи (например, через Интернет). Даже если ты планируешь самостоятельно тестить свою игру, настоятельно рекомендуется пользоваться системой отслеживания багов. Неплохой вариант такой системы под названием TestTrack можно поискать на сайте производителя www.seapine.com.

Трэкинг исходного кода (Sourcecode Tracking)
Большинство систем отслеживания багов позволяет привязать к багу исходный код, в котором он возник. Метрики качества (Quality metrics)
Одно из преимуществ ведения истории багов - это то, что на её основе можно создавать т.н. метрики качества (Quality metrics). Так ты можешь возвращаться во времени назад и видеть, на какой стадии возникло наибольшее количество багов. Было ли наибольшее кол-во багов во время системных тестов? Или они обнаружены только на стадии бета-тестирования? Обнаружены ли они в финальном релизе? Ответив на данные вопросы ты можешь найти дыры в своих стандартах качества и попытаться залатать их. Если наибольшее кол-во багов было найдено на стадии системных тестов (systm test), то необходимо выяснить, почему разработчики отправляют такой недоработанный софт системным тестерам. Если большинство багов было найдено в бета-версии, необходимо выяснить, почему системные тестеры отправили столько багов бета-тестерам, не выявив их самостоятельно. Если большинство багов найдено в финальном релизе (production), необходимо выяснить, почему команда бета-тестеров упустила их из виду. Самая фиговая ситуация, когда баги добираются до финального релиза, т.к. фиксинье каждого бага на этой стадии может стоить кучу денег.
В итоге получаем, что метрики качества позволяют устранять неэффективное тестирование и улучшает качество конечного продукта.

Тестирование модулей (Unit testing)
Процесс тестирования модулей трудно переоценить. До того, как игра отправится к команде системных тестеров (system testers team), разработчики должны сначала проверить самих себя. Вот несколько советов по данному этапу:

• Прогони исходный код в однопоточном (singke-threaded) режиме не менее 5 миллионов раз без единого сбоя.
• Исходный код должен работать неделю без единого сбоя.
• Исходный код должен пройти тест на полную регрессию (full regression test) без сбоев.

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

Фаза тестирования (Testing Phase)

Если твой исходный код дошёл до этой стадии, то он как минимум стабильно компилируется и работает. Он может не иметь всех фич, но важен сам факт работоспособности. В данной фазе команда системных тестеров прогоняет программу через различные тесты.
Как правило у команды системных тестеров есть документ "Регрессионный план" (Regression plan), в котором содержится список тестов, которые необходимо пройти твоей программе. Если она проходит тесты без ошибок, то твоему коду открыта прямая дорога к бете (beta).
Системные тестеры также часто применяют т.н. "отрицательное тестирование" (negative testing). Допустим в игре есть поле ввода числа пехотинцев, которые зачисляются в боевое подразделение. Тестеры могут запросто указать там букву алфавита просто чтобы посмотреть, что будет. Кроме букв часто вносят отрицательные или просто очень большие значение, чтобы посмотреть, не разорвут ли они твой код в клочья. В этом и есть вся суть отрицательного тестирования - проверить самые неожиданные ситуации. Впрочем, конечные пользователи будут проводить тесты и похлеще этих.

Фаза выпуска (Production Phase)

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

Дистрибьюция (Distribution)

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

• Условно-бесплатная версия (Shareware)
• Сайты-аукционы (Auction sites)
• Издатель (Publisher)

Условно-бесплатная версия (Shareware)

• Самый простой способ распространения собственной игры.

Существует множество веб-сайтов с программами (download sites), готовые бесплатно разместить твою игру у себя. Всё, что необходимо сделать - это упаковать её в самораспаковывающийся архив или создать инсталлятор, с помощью стороннего ПО. В самой игре остаётся лишь прописать адрес, куда отправлять пожертвования (donations). Единственная проблема данного способа это то, что вероятность сделать на этом реальные деньги стремится к нулю.
Альтернативным способом является размещение урезанной (cut-down) версии игры. Допустим, твоя стратегия рассказывает о битвах Второй мировой войны. Включи туда лишь несколько сценариев и вставь запрос на приобретение полной версии игры. Это отличный способ показать свою игру и даже продать несколько копий.

Сайты-аукционы (Auction sites)

Другой способ продать свою игру - это записать её на диск и продать на eBay или на любом другом похожем сайте-аукционе. Конечно, больше 10 USD за копию не выручишь, но вцелом данный подход окупает затраченные на него усилия. Единственная проблема здесь это то, что видимость такого предложения в Интернете очень ограничена. Для расширения потенциальной аудитории демо-версию игры дополнительно распространяют на сайтах с условно-бесплатным ПО (Shareware sites). В демоверсии размести ссылку на сайт с полной версией игры.
Сегодня большинство пишущих CD/DVD-приводов вполне доступны по цене, как впрочем и чистые CD/DVD-болванки. Себестоимость записи игры на носитель как правило меньше 2 USD. Как видишь, прибыль с продажи каждой копии получается вполне ощутимой. Главное - перед началом продаж представь (exposure) свою игру в как можно большем количестве мест.
Ты даже можешь организовать скачивание цифровой копии игры после предварительной оплаты. Есть даже специальные сайты, готовые организовать это (digibuy.com).

Издатель (Publisher)

Если по твоему мнению игра достаточно хороша для её показа издателю, их без труда можно найти в Интернете. Одна из таких компаний Garage Games, которая опубликует твою игру за небольшой процент. Если ты хочешь, чтобы твою игру выпустил именитый издатель, вроде Electronic Arts, тебе лучше сделать передовую игру. В этом случае тебя попросят озвучить бизнес-план, а для его составления тоже необходим немалый опыт. Вообще, если ты новичок в игровой индустрии, вероятность отказа у таких издателей будет близка к 100%.

Источники:

---