Главная » Статьи » Геймдизайн » Искусство геймдизайна

Глава 8: Игра улучшается итеративно / Искусство Геймдизайна в кратком изложении Дениса Иваныча

Искусство Геймдизайна Джесси Шелла в пересказе Дениса Иваныча

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

+ 4 линзы:

  • Линза #15 Восьми фильтров
  • Линза #16 Снижения рисков
  • Линза #17 Игрушки
  • Линза #18 Страсти

Выбор идеи

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

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

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

Восемь фильтров

Законченный дизайн следует протестировать, прогнав его через то, что Джесси Шелл называет восемью фильтрами.

Фильтр 1: Художественный. Ключевой вопрос: «чувствуете ли вы, что игра хороша?»
Фильтр 2: Демографический. Ключевой вопрос: «понравится ли игра целевой аудитории?»
Фильтр 3: Дизайнерский. Ключевой вопрос: «хорошо ли сконструирована игра?»
Фильтр 4: Инновационный. Ключевой вопрос: «достаточно ли в игре новизны?»
Фильтр 5: Экономический. Ключевой вопрос: «принесёт ли игра доход?»
Фильтр 6: Инженерный. Ключевой вопрос: «возможно ли построить игру с технической точки зрения?»
Фильтр 7: Социальный. Ключевой вопрос: «соответствует ли игра поставленным целям в плане социализации игроков и построения комьюнити?»
Фильтр 8: Плейтестерский. Ключевой вопрос: «достаточно ли игра понравится плейтестерам?»

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

Рассмотрение игры с точки зрения её прохождения через все фильтры – отличная точка зрения и наша следующая линза:

#15   Линза Восьми фильтров

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

Задайте себе 8 вопросов:

  • Чувствуете ли вы, что игра хороша?
  • Понравится ли игра целевой аудитории?
  • Хорошо ли сконструирована игра?
  • Достаточно ли в игре новизны?
  • Принесёт ли игра доход?
  • Возможно ли построить игру с технической точки зрения?
  • Соответствует ли игра поставленным целям в плане социализации игроков и построения комьюнити?
  • Достаточно ли игра понравится плейтестерам?

В некоторых случаях вам потребуется больше фильтров, не стесняйтесь их придумывать. Например, если вы делаете обучающую игру, вам наверняка понадобится девятый фильтр, чтобы ответить на вопрос: «учит ли моя игра тому, чему должна?»


Правило итерации (или «витка спирали»)

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

Конечно, можно погрузиться в работу в надежде, что ваша игра удастся. А если нет? Что если на создание игры уйдёт столько ресурсов, что она никогда не окупится. Дело в том, что процесс создания игры итеративен. Игру, как и ремонт, нельзя закончить. Её разработку можно только прекратить, когда вы признаете свою игру «достаточно хорошей». И это правило итерации:

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

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

  • Вопрос №1: как сделать так, чтобы каждая итерация была важна?
  • Вопрос №2: как итерировать чаще?

Чтобы ответить на эти вопросы разработчики придумали несколько методик.

Каскадная модель (также известная как «Водопад»)

Для начала Джесси Шелл кратко рассказывает про «Каскадную модель» разработки ПО, однако такая модель не учитывает итеративную сущность разработки игр. В том числе и поэтому он считает такую модель разработки ПО устаревшей и неэффективной.

Каскадная модель разработки ПО

Каскадная модель

Спиральная модель

В 1986 году Барри Бим разработал «Спиральную модель». Вообще, почитать про все эти модели можно в интернете (например, эти две иллюстрации взяты из этой статьи на Хабре).

Спиральная модель разработки ПО

Спиральная модель

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

  • Определение задач, альтенатив и ограничений
  • Оценка альтернатив, выделение рисков и способов их снижения
  • Разработка и верификация очередной части продукта
  • Планирование следующих итераций

Разработка с использованием спиральной модели выглядит следующим образом:

  1. Разработка базового дизайна
  2. Определение наибольших рисков в дизайне
  3. Создание прототипов для снижения этих рисков
  4. Тестирование прототипов
  5. Разработка более детального дизайна на основе полученной информации
  6. Возврат к шагу 2

Таким образом, для повышения эффективности работы по спиральной модели нужно:

  • Вопрос №1: как сделать так, чтобы каждая итерация была важна?
    Нужно оценивать и снижать риски.
  • Вопрос №2: как итерировать чаще?
    Нужно строить как можно больше черновых прототипов.

В целом спиральная модель достаточно эффективна, но небольшим командам разработчиков следует обратить внимание на Agile-методы.

Agile методы

В 2001 году разработчики программного обеспечения приняли Agile манифест. Приводить здесь принципы Agile проектирования я, конечно же, не буду. Про Agile существует огромное количество литературы и лекций, в т.ч. и в свободном доступе. Следует отметить, что сам по себе Agile – не методика, это просто набор принципов. Однако эти принципы легли в основу Agile-методик, самой известной из которых стала методика Scrum. Она особенно эффективна для небольших команд разработчиков, до 9 человек. А если подпереть её костылями, то и для большее многочисленных команд.

Кратко пробежимся по основным элементам Scrum.

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

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

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

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

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

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


Оценка рисков и прототипирование

В этом разделе Джесси Шелл приводит пример оценки рисков и создания прототипов для выдуманной им игры Prisoners of Bubbleville про кошку-парашютиста. Желающие подробностей могут припасть к оригиналу, мы же ограничимся очередной линзой:

#16   Линза Снижения рисков

Поскольку мудрец всегда противостоит трудностям, он их никогда не испытывает.

-Дао дэ цзин.

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

Задайте себе следующие вопросы:

  • Что может помешать игре стать великолепной?
  • Как вы можете это предотвратить?

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


Десять советов по продуктивному прототипированию

Совет №1: Ответьте на вопрос

Задача прототипа – давать ответ на чётко сформулированный вопрос. Если вы не можете чётко сформулировать вопрос – у вас обязательно возникнут проблемы. Помните, что прототип должен быть лаконичен. Он должен давать ответ только на ключевой вопрос. Не переусердствуйте при постройке прототипа.

Совет №2: Забудьте о качестве
Чем быстрее вы построите прототип и ответите на свой вопрос, тем лучше. Правило итерации никто не отменял. При этом совершенно неважно, как выглядит прототип.

Совет №3: Не привязывайтесь к прототипам
Не привязывайтесь к бумажным стаканчикам. Они созданы быть одноразовыми. Разумеется, вы можете использовать какие-то части вашего прототипа в будущих прототипах или в вашем проекте. А можете и не использовать.

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

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

Совет №6: Не обязательно делать цифровые прототипы
Очень многое можно запрототипировать в виде простых настольных игр, это называется «бумажный прототип». Многие игры в реальном времени можно преобразовать в пошаговые. Тот же Tetris отлично прототипируется «на бумаге» в виде пошаговой игры. При желании даже шутер от первого лица можно сделать в виде бумажного прототипа в реальном времени при помощи метронома, а искусственный интеллект монстров заменить живыми помощниками.

Совет №7: Прототип не обязан быть интерактивным
Игры являются интерактивным развлечением, однако прототип не обязан быть интерактивным. Даже скетчи и анимация способны дать ответы на многие вопросы. Так, в Prince of Persia механики прыжков и поворота времени вспять были впервые опробованы в виде обычной анимации.

Совет №8: Выберите игровой движок, подходящий для быстрого итерирования
Удобно, когда вы можете тестировать игру, менять переменные и править код одновременно. Это намного удобнее, чем компилировать и перезапускать игру после каждого изменения.

Совет №9: Для начала создайте игрушку
Про разницу между игрой и игрушкой мы писали в Главе 4. Хорошая игрушка может натолкнуть на очень интересные мысли. Так, прототип игры GTA представлял собой типичную игрушку – мир-песочницу, по которому можно было разъезжать на машине. В процессе игры в игрушку разработчикам нужно было решить, что в этом мире было бы интереснее всего делать. Чтобы этот совет лучше запомнился, давайте превратим его в нашу следующую линзу.

#17   Линза Игрушки

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

Задайте себе следующие вопросы:

  • Если бы в моей игре не было цели, было бы в неё интересно играть? Если нет, как мне это изменить?
  • Когда люди видят мои игру, интересно ли им с ней взаимодействовать? Даже до того, как они узнают, что в ней нужно делать? Если нет, как мне это изменить?

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

Совет №10: Используйте любые возможности для дополнительных итераций
Иногда в процессе разработки игры возникают неприятные обстоятельства, из-за которых разработка игры затягивается, но которыми можно удачно распорядиться. Так, игра Halo изначально создавалась для Macintosh, затем разработчики подписали контракт с Microsoft и нацелились на PC, а затем – переориентировали игру на XBOX. Разумеется, релиз игры неоднократно переносился, однако разработчики всякий раз использовали задержки для того, чтобы лишний раз отполировать игровой процесс. Неудивительно, что игра имела огромный успех и стала прародителем целой серии игр.

Окончание итерации

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


Когда стоит остановиться?

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

Джесси Шелл приводит в качестве примера «Метод» (это название такое из одного слова и с большой буквы) Марка Чёрного, который интересным образом разделяет предпродакшен и продакшен. Так вот, с точки зрения Чёрного, пока вы не построили два полностью готовых к изданию уровня своей новой игры, вы занимаетесь предпродакшеном. И именно в момент завершения предпродакшена по Чёрному вы можете прикинуть сроки, в которые вы уложитесь со своей игрой.

Эмпирическое правило гласит, что имея полностью готовые к изданию два уровня, вы освоили приблизительно 30% необходимого бюджета. Так что если это потребовало 1 млн. долларов, готовьте ещё 2.3 миллиона. Верно и обратное: пока вы не потратите хотя бы 30% бюджета вы не узнаете, сколько стоит ваша игра, и сколько времени потребуется на её разработку.

Разумеется, это не единственное эмпирическое плавило. Вот два правила «50%».

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

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


Ваше секретное оружие

За всей этой аналитикой мы как то забыли о самом главном – почему мы делаем игры. Давайте вспомним об этом, и заодно добавим новую линзу.

#18   Линза Страсти

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

  • Сжигает ли вас всепоглощающая страсть от предвкушения того, насколько хороша будет ваша игра?
  • Если страсть куда-то исчезла, можете ли вы её вернуть?
  • Если вернуть страсть не получается, не лучше ли заняться чем-то другим?

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

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


Дополнительная литература к Главе 8:

  • Sketching User Experiences by Bill Buxton – данная книга исследует вопросы скетчевания (или эскизирования, кому как больше нравится) в разных дисциплинах. И да, прототипы – это что-то вроде эксизов.
  • Have Paper, Will Prototype by Bill Lucas – в данной лекции рассматриваются примеры успешного создания бумажных прототипов компьютерных интерфейсов.
  • The Kobold Guide to Board Game Design by Mike Selinker – лучшая книга по дизайну настольных игр.
  • Less Talk, More Rock by Superbrothers – в этой статье утверждается, что игры являются жанром действия, и слишком много разговоров о дизайне может стать для них смертельным.
  • Agile Software Development – статья в Википедии об Эджайле. Она хорошо написана и в ней приведено много полезных ссылок.
  • The 4Fs of Game Design: Fail Faster, and Follow the Fun by Jason Vandenberghe – в данной статье, основанной на идеях Марка Леблана, рассматриваются ключевые аспекты создания хорошего дизайна с вычленением понятных базовых элементов.

Предыдущая глава
Оглавление
Следующая глава

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

Категория: Искусство геймдизайна | Добавил: Иваныч (29 Май 2018) | Просмотров: 92 | Теги: геймдизайн, Джесси Шелл, Книги

Похожие публикации:

Всего комментариев: 0

avatar

HASH(0x2938500)