Загрузка...
 
Печать
ИГРОКОДИНГ  »  ИГРОКОДИНГ: Учебный курс  »  Введение (общее)  »  Готовим дизайн-документ игры

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


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

Дизайн-документ игры(external link) (Game Design Document) - это детальное описание разрабатываемой компьютерной игры. Диз. док. создается и редактируется командой разработчиков и в основном используется в индустрии видеоигр для организации работы разработчиков. Документ создается в результате сотрудничества между дизайнерами, художниками и программистами как руководство, которое используется в процессе разработки. Когда издатель поручает создание игры разработчикам, команда разработчиков должна создать документ, который часто связан с соглашением между издателем и разработчиком; разработчики должны придерживаться дизайн документа во время процесса формирования игры.
По теме дизайн-документирования написана не одна сотня книг. Почти все они на иностранных языках и никогда не издавались в России. Так вот, в каждой из них утверждается, что без дизайн-документа невозможно создать сколько-нибудь полноценную игру. Это всё равно что начать строительство многоэтажного дома, не вырыв предварительно котлован для его фундамента.
Дизайн-документ, как правило, создаётся по определённым правилам и имеет чёткую структуру.

Для примера рассмотрим основные пункты дизайн-документа гипотетической игры в жанре стратегия в реальном времени (Real Time Strategy)1. Содержание дизайн-документа может отличаться даже у игр одного жанра. Но есть пункты, присущие играм всех жанров.

Содержание

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

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

Жанр сюжета (The Story Theme)

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

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

Существует множество других тем и вселенных, в рамках которых разворачивается сюжет игры. Основная идея здесь - выбрать одну из них и уже с ней работать. Возьмём к примеру игру "Star Wars: Galactic Battlegrounds", основанную на известной книжной саге "Звёздные войны" Джорджа Лукаса. Конечно, она относится к жанру научной фантастики.
Другой пример игровой вселенной - "Stronghold", где всё крутится вокруг создания своих средневековых зАмков и захвата чужих. Рекомендуем выбирать тему сюжета, которая в самом деле нравится и интересна. Так новые идеи будут приходить куда быстрее.

Элементы сюжета

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

  • фабула (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), как например постройка адекватного жилья, сбор необходимых ресурсов, а также покупка необходимых апгрейдов для инвентаря. И вот, набор игровых задач готов! Погружаясь в игру с головой, обнаруживаешь множество других задач, которые прямо или косвенно ведут игрока к победе. Важно чтобы этот набор был максимально простым. Большинство игроков отнюдь не жалют сотни внутриигровых задач. Принимая это во внимание, начинаешь осознавать, что самая продаваемая стратегическая игра всех времён и народов обладает довольно простым набором внутриигровых задач.

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

На основе вышеизложенного материала разберём сюжет игры Empire Earth(external link) и выделим из него несколько игровых задач (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).

Закрыть
noteРаш

Термином "раш" (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
PPS43 (пистолет-пулемёт Судаева) 700
81-мм мортира (mortar) M1 18

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

Тип урона (Damage type)

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

Специальный урон (Special damage)

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

Скорость полёта снаряда (Weapon Veloсity)

Само по себе оружие не имеет скорости как таковой. Но скорость имеют снаряды, выпущенные из него. Данный параметр является одним из ключевых в любой стратеической игре, т.к. сильно влияет на геймплей. Например лазерный луч из ружья футуристического солдата имеет наибольшую возможную скорость, т.к. лазер распространяется со скоростью света.
Расчёт скорости полёта снаряда
Скорость полёта снаряда во многом схожа со скоростью перемещения юнита. Необходимо разработать стандартную систему скорости, применимую ко всем снарядам в игре. Рекомендуем использовать шкалу в пределах от 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). Если процесс сбора ресурсов будет слишком медленным, игра станет скучной и монотонной.

Закрыть
noteОбрати внимание

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

Деревья технологий в 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 игру не стоит создавать свой уникальный язык для неё.

Закрыть
noteСовет

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

Технологии усоврешенствований (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)

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

Background
  World War II
    Patton's battles
    Accurate. Игровой мир смоделирован после реальных исторических событий. (Modeled after real-worlds events.)
  Битва (Combat)
    Brigade level
    Сделать упор на механизированные единицы. (Focus on mechanized units.)
    Команды отдаются отряду. (Commands given down to squad level.)
  Realism
    Fog of War ("Туман войны"; Игровая карта открывается постепенно.)
    Проблемы со связью. (Communication problems.)
    Отсутствие снимков местности со спутника.
    Возможные пути следования. (Routes possible.)
    Необходимы пути доставки провизии. (Supply routes required.)
  Players
    Single player (Одиночный режим)
    Режим кампании (Campaign game)
    Multiplayer (Режим многопользовательской игры.)
      Skirmish battles
      Single-campaign events

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

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

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

Требования к мультиплееру (Multiplayer Requirements):
  1. Поддержка от 2 до 16 игроков.
  2. Игру можно сохранять и загружать.
  3. Выделенный сервер для игры не обязателен (optional).
  4. Администратор игрового сервера может кикать (kick) и банить (ban) игроков.

Каждый пункт подробно расписывается. Нет ничего хуже, чем документ с неясно обозначенными требованиями. Напомню, это единственный документ, по которому работают программеры. Поэтому, если вдруг что-то упустил из виду и не указал здесь, потом не удивляйся, что не увидишь этого в игре.
Прежде чем рассматривать фазу технических требований, убедись, что соотнёс основные пункты фазы видения с соответствующими пунктами фазы требований. Просто размести каждый из них в списке требований и напиши по ним развёрнутые пояснения. Нередки проекты, на разработку одной только фазы требований которого уходит 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), программист может возвращаться к предыдущим версиям кода. Иногда это необходимо.

Закрыть
noteЛюбопытный факт

Утилита WinDiff включена во все выпуски Windows 2000/ME/XP. Т.е. для её вызова достаточно было нажать Пуск (Start) -> Запуск (Run), набрать WinDiff и нажать "OK". В Windows 7/8 и более поздних версиях ОС программа WinDiff отсутствует. К счастью, её нетрудно найти в Интернете.

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

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

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

Main.cpp
  Version 1.4
  Version 1.3
  Version 1.2
  Version 1.1
  Version 1.0
Main.h
  Version 1.2
  Version 1.1
  Version 1.0

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

Main.cpp
  Version 1.4
  Version 1.3 BETA
  Version 1.2
  Version 1.1
  Version 1.0
Main.h
  Version 1.2 BETA
  Version 1.1
  Version 1.0

Теперь достаточно выбрать все файлы с пометкой 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)

Процесс тестирования модулей трудно переоценить.

Источники


1. Todd Barron. Strategy Game Programming with DirectX 9.0. - Wordware Publishing Inc. 2003

ИГРОКОДИНГ  »  ИГРОКОДИНГ: Учебный курс  »  Введение (общее)  »  Готовим дизайн-документ игры

Contributors to this page: slymentat .
Последнее изменение страницы Пятница 09 / Ноябрь, 2018 00:10:26 MSK автор slymentat.

Хостинг

Помочь проекту

Яндекс-деньги: 410011791055108