Пройти Game Design and Development на Coursera

Пока эту цель замораживаю (думаю на месяц), придётся сперва разобраться с более насущными делами.

Получил грейд 20/20 по диздоку. Один из оценивавших был ментором проекта. :)

Закрыл первую неделю курса Business of Games and Enterpreneurship, посвящённого материалам в сфере маркетинга и рынка игр.

Скажу так. Это очень важно для девелопера, даже если он не будет конкретно этим потом заниматься (в проект-менеджменте или своем бизнесе). Важно понимать, как именно твои действия и усилия по разработке сказываются на стоимости проекта и возможности его потом продавать и распространять. У меня 0% знаний о бизнесе и продажах (от слова вообще), поэтому было не очень интересно, но материал новый и полезный.

На первой неделе были темы о схеме индустрии, вопросах заключения договоров, авторских прав, патентов и копирайтов. Мне, честно говоря, было скучно это смотреть (я думаю, что, будучи бизнесменом, я бы нанял исполнительного директора, чтобы разбираться с рутинными денежными и юридическими вопросами). Зато вопросы направления движения на рынке, вопросы поиска спонсора или средств на проект - было очень интересно слушать! Мне также было бы интересно самому действовать по вопросам путей развития и управления направлениями деятельности!

Задание на эту неделю было провести SWOT (Strengths - Weaknesses - Opportunities - Threats) для любой нравящейся игры на рынке. Необходимо было указать, в чём сила, слабости, возможности и уязвимости для проекта. Я лично выбрал серию Mass Effect, как показательный случай игры с сильным сюжетом и самодостаточной вселенной, но недостаточной социальной составляющей и закрытым миром.

Отправлю это всё вечером, ибо оказалось, что теперь "по распоряжению службы безопасности" сотрудникам запрещено отправлять любые файлы во внешние источники, видите ли! :) Из-за этого я почему-то должен решать за 7 часов то, что решается в пару минут (интересно то, что аплоадить на курсеру нельзя, а скачивать - пожалуйста). Горите в аду, безопы! :)

Вчера добил наконец дизайн-документ! Заметьте, вместо недели на задание ушло полтора месяца.

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

Ах да, документ полностью на английском и занял 48 страниц. Думаю, это среднее значение для игры моего класса.

Странно, что на это задание отводится только неделя. За неделю его можно выполнить, только если ты профессиональный разработчик игр, если у тебя своя команда или своя студия, если ты делегировал это задание (хотя какой смысл?), или - твоя игра по сложности механик равна тетрису.

Прототипирование на 4й неделе - та же проблема, качественный прототип нельзя сделать за неделю (без этих трёх условий), а некачественный сложно оценить/заценить.

Досмотрел наконец все видео из курса Introduction to Game Design, осталось досдать диздок и прототип.

Последняя часть касалась в основном возрастных ограничений по играм.

Информация была для меня не нова, однако увидел несколько интересных вещей.

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

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

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

Досмотрел видео по дизайну и плейтестингу.

Одно время я интересовался этой темой, поэтому тема UI/UX не была для меня новой. Однако пару моментов для игр я почерпнул.

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

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

С другой стороны, есть маленький недостаток: как согнать с тестового компа подростка, который хочет пройти твою бета-версию на 100% (хотя время теста давно иссякло), и другим желающим поиграть не хватает компов? :)

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

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

У меня часто получается так: я делаю прототип как часть законченного проекта - а потом на его основе пытаюсь соорудить то, что пойдет в продакшн. На самом деле, сложно помнить о том, что прототип всего лишь должен отвечать на определенный вопрос к геймплею, балансу, арту, etc, когда у проекта ограниченные сроки, как правило меньшие, чем ты можешь себе позволить.

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

Ассайнмент на этот модуль - как раз прототип. Надо, конечно, хорошо поразмыслить над тем, как и с помощью чего его делать.

Баланс.

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

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

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

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

Например, возьмем рейтинг побед и поражений. Если, допустим, игрок все время играл с новичками и потому выигрывал, он объективно не является сильнее, чем игрок, который играл с такими же по уровню, как и он, и потому не так часто выигрывал, как первый. Более того, их уровень нельзя сравнивать только по статистике. Куда важнее аналитика вообще всех действий игрока, нахождение закономерностей в его поведении и разрешении типовых игровых ситуаций. Сейчас некоторые новые направления, например Big Data, могут анализировать действия игрока, но критериев, объективно подходящих для всех сторон тактики игрока (то есть охватывающие даже его планы, а не только последовательности нажатия клавиш) пока не разработано.

Далее, решение может быть частично найдено математически, если разрабатывать подстраиваемое под действия игрока окружение игры. Например, компьютерные персонажи имеют ряд альтернативных действий для противодействия любому поступку игрока (а не одно, как сейчас у любых NPC), и могут с легкостью перейти к другой, оптимальной против игрока, тактике, когда текущая будет в данный момент проигрышной. Или еще вариант: игра запоминает тактические приемы игрока с помощью аналитики и потом оперирует врагами и окружением с их учетом, ставя игрока с точки зрения тактики в невыгодное положение. Отчасти, такой подход применялся в XCOM 2, но только для расчетов вероятностей попаданий, а не для общей тактики.

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

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

Есть также балансная тактика "нерфа" - изменения параметров оружия, предмета, врага для того, чтобы сломать выигрышную (и потому имбалансную) тактику игры. Многие, особенно в MMORPG, прибегают к ней, потому что она относительно просто позволяет вернуть игру к абстрактному балансу. Но ее придется часто применять, и вот почему. Проблема в том, что правила игры взаимосвязаны, и так же взаимосвязаны и тактики (ибо основаны на этих правилах). Если понерфить что-то одно, изменения появятся и во всем остальном. Предсказать, какие будут изменения, возможно только приблизительно и в краткосрочной перспективе, ибо неопределенность. Именно поэтому после нерфа одной тактики ее место спустя какое-то время занимает другая: это закономерно, т.к. когда предмет А потерял преимущество перед предметом Б, предмет Б стал лучше чем предмет А (в некотором отношении) и фактически занял место предмета А, и на предмете Б можно основать новую имбалансную тактику, которая займет позицию понерфленной.

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

Нашел наконец время и досмотрел видео по левел-дизайну и балансингу.

Левел-дизайн. Более конкретная область геймдизайна. Здесь более важны практические варианты правил, которые были созданы при проектировании игры.

Схема движения игрока по локации? Карта самой локации? Какие объекты должны там находиться, какая часть сторителлинга должна быть отображена в данной локации?

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

Сразу видно, что левел-дизайн - это не только "сборка" уровня игры в соответствии с документацией либо в зависимости от того, что уже реализовано в движке.

Есть два очень важных тонких момента в левел-дизайне. Первый - как показать игроку, что он делает что-то не то? Возьмем, к примеру, игру Dark Souls. Если игрок делает в ней что-то не то, окружение игры (враги) непременно отправят игрока на "пересдачу", приведя к высвечиванию огромной надписи "YOU DIED", словно бы призванной служить вечным проклятием в начале знакомства с игрой. Вопрос вот в чём: очевидны ли причины проигрыша и смерти игрока? Как быстро можно понять, что конкретно я делал не так и потому умер? С одной стороны да, понимаешь, что если попал под мувсет удара врага и не сблокировал/парировал/увернулся, тебя побьют. С другой стороны - многие приемы, например парирование, далеко не очевидны и поначалу, и для опытных игроков. Кто из игравших может поручиться, что он знает, как отпарировать любого врага даже конкретным оружием/щитом? Даже с прокачанным спинным мозгом и отменной реакцией никто не поручится, удачно ли он парирует следующий удар, что вводит диссонанс между действием и обратной связью от игры.

Второй момент - эстетическая подача локации. То, что чувствует сам игрок, когда видит ее и, самое главное, когда применяет на ней правила геймплея. Возьмем, к примеру, XCOM 2. Сами по себе локации (хотя и глобальная тоже) выбираются из ограниченного набора базового ландшафта с генерируемыми новыми объектами. В целом это хорошо, если смотреть на одну локацию. Но проблема игр серии XCOM заключается в однотипности повторяющихся локаций: в среднем за игру выполняются 40-60 миссий, и уже на 20-м разе ты уже делаешь все на полуавтомате, не особо заморачиваясь с тактикой и стратегией (особенно это актуально, когда все виды врагов ты уже увидел и знаешь, как с ними справиться). А атмосфера спешки из-за ограниченного времени миссии очень часто исключает удовольствие от тактики, которое для всей серии core mechanic.

Сессия нарушила все мои планы, и дизайн-документ никак не успевал дописать, поэтому пришлось переключить сессию на 29 мая - 4 июня.

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

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

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

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

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