Геймдизайн. Рецепты успеха лучших компьютерных игр от Super Mario и Doom до Assassin’s Creed и дальше - Тайнан Сильвестр

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

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

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

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

Популяция лосей значительно выросла. Вскоре огромные стада лосей начали съедать осины и ивы. Это привело к исчезновению бобров, так как у них не осталось достаточно древесины для плотин. Без плотин парк начал пересыхать каждое лето. Для рыбы не осталось водоемов, и вскоре озера опустели. С исчезновением рыбы упала популяция гризли, так как они выживали благодаря пойманной из рек рыбе. С исчезновением гризли и появлением такого количества лосей, на которых можно охотиться, выросла популяция волков. Рост популяции оленей вскоре прекратился из-за волков и выпаса лосей.

И изменения продолжались, распространяясь на всю экосистему…

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

Ключ к ответу на этот вопрос заключается в понимании зависимостей.

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

В геймдизайне все не так. Различные части дизайна часто взаимозависимы. Внешний вид уровня зависит от оформления этого уровня. Оформление зависит от инструментов игрока. Инструменты игрока зависят от базового интерфейса. Если какой-либо элемент изменяется, то изменяется и каждый зависимый от него элемент.

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

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

Стек зависимостей

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

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

Давайте разберем пример. Представьте, что мы делаем Fantasy Castle, легкую игру о строительстве замка в фэнтези-мире. Разработка Fantasy Castle только началась, поэтому команда дизайнеров переполнена идеями, но им не хватает протестированных и проверенных проектных решений. Они написали длинный дизайн-документ. Каждая из 22 подсистем подробно описана на бумаге. Далее следует их краткое изложение в произвольном порядке:

• Персонажи. Могут существовать и перемещаться в окружающей среде.

• Семьи. Персонажи могут вступать в семейные отношения.

• Расы. Замок может быть заполнен большой группой людей, эльфов, гномов и других фэнтезийных рас.

• Межвидовое скрещивание. Различные виды могут скрещиваться, чтобы создать гибриды с общими характеристиками своих родителей.

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

• Сельское хозяйство. Сельское хозяйство и продовольственная система дают населению пропитание.

• Торговля. Персонажи могут торговать с соседними замками особыми или редкими товарами.

• Образование. Персонажи могут получить образование.

• Изобретения. Образованные персонажи могут изобретать новые машины для замка.

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

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

• Друзья. Персонажи могут иметь платонические отношения.

• Романтика. Персонажи могут иметь романтические отношения.

• Строительство. Персонажи могут что-то строить.

• Стены. Персонажи могут строить стены, чтобы остановить врагов.

• Укрепления. Стены можно укреплять и утолщать, чтобы сдерживать гоблинов.

• Ловушки. Персонажи могут устанавливать ловушки или автоматические защиты.