Нужно ли геймдизайнеру программирование?

Недавно я общался в комментариях и прозвучала классическое в среде геймдизайнеров утверждение, что "программирование полезно, но не нужно". Этой статьёй, я попробую объяснить почему программирование для ГД это больше чем просто самому собрать прототип.

Соответствует ли оно реальности? Если мы посмотрим на качество игр, то закрадывается впечатление, что не всегда, олдфаги подтвердят. Потому, разберу это утверждение подробно.

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

Да, так же, как и сказителю не обязательно знать грамоту - зрителю всё равно представление, а писарь - запишет.

Каждая профессия тянет за собой шлейф разнообразных навыков, которые необходимы для качественной работы. Так программирование тянет за собой такие вещи как "принципы программирования", т.е. KISS, DRY, SOLID. Так же, в зависимости от кучи факторов, программист может разбираться в том, чем отличается функциональное, объектное (изначальное), объектное (современное) и процедурное программирование. Каждый из этих принципов оказывает влияние на мышление: опытный дальнобойщик не жмёт на тормоз резко, он предпочитает проехать светофор не останавливаясь.

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

Фанатичное следование этому принципу ужасает и перегружает, но тем не менее, начиная с определённого момента оно позволяет очень дёшево наполнить игру контентом.

Например в Cyberpunk 2077 было несколько сцен с поеданием/выпивкой. Но они были повторены в коде сюжетки игры, а не были посажены поверх обычного взаимодействия в игре, по сути - авторы игры повторили несколько раз одну и ту же работу - а мы получили только сюжетку. Если бы они "нанизали" поведение Джеки не на сюжет как таковой, а на стойку бара - то мы бы получили кучу вариантов взаимодействия без дополнительного кода.

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

Ну или "single responsibility, open–closed, Liskov substitution, interface segregation и dependency inversion".

Набор принципов, при котором каждая часть системы замкнута на себя и позволяет заменить себя как по частям, так и "в сборе". По Солиду написаны полноценные статьи, потому не буду разбирать это подробно. Для ГД SOLID даёт более чистое исполнение системы игры, однако при слишком фанатичном исполнении способен приводить к "стерильным" проектам, где отдельные части никак не взаимосвязаны.

Чтобы этого не допустить, сцена должна являться местом смешения механик и требовать от них определённой роли, а не зависеть от них, как TES Blades от монетизации.

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

Каждый персонаж/объект/механика дёргается по мере надобности и кормится с ложечки всеми данными. Выполняет свою функцию, возвращает результат, и ждёт следующей ложечки.

Каждый персонаж/объект/механика это "космический корабль", который как-то должен принять сообщение и отреагировать на него согласно роли, отправив ответные сообщения согласно того как он там "думает". Персонаж лишь катит шар событий...

По сути то же самое, но все взаимодействия - конкретные и предсказанные заранее, с возможностью прямого изменения сцены/сюжета/прочего. Персонаж вершит дела сам или пинает менеджера

Я не готов переводить слово "монады" на русский язык, потому скажем просто: персонаж/объект/механика лениво ждёт в рутине, пока что-то не достанет его (не заполнит требуемые данные) и он не начнёт вершить дела.

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

Это утверждение растёт из былинного холивара (ибо был первым) между математиком Чарльзом Бэббиджем, который утверждал, что программирование это не слишком квалифицированная работа, с которой справятся и практиканты, и программистки-фрилансера Ады Лавлейс, которая в 1843-м году выдала такой перл, над которым в приличном обществе можно было бы только посмеяться:

Однако уже спустя 100 лет над этими словами смеяться невозможно. Примерно через 120 лет была создана первая компьютерная игра и сегодня, спустя всего 178 лет, мы почти не можем жить без подобной техники. Потому я повторюсь и поддержу Аду Лавлейс в её замечании Бэббиджу.

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

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

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

С другой стороны, опыт в программировании даёт возможность смотреть на задачи ГД именно с позиции "структуры данных", а не с позиции "набора данных".

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

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

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

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

Так же и умение программировать - ГД начинает видеть структуры данных и течение времени пользователя в его же эмоции.

Казалось бы, я бы не хотел тут придираться, ведь всё правильно. Но есть пара моментов.

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

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

То есть по сути - ГД не справился с тем, чтобы единица времени приносила определённый объём эмоций как только игрок утыкается в пейволл.

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

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

"Геймплейно плохой" может быть игра, в которой механики плохо сплетены и их использование не образует интересных для игрока паттернов. Например, у нас есть стрельба и управление машиной. Если ГД не сплёл стрельбу и езду/выход из машины (например, персонаж после выхода из машины 5 секунд разминается) - то пусть каждая из механик будет хорошей, но играть в это будет сложно.

"Тактильно плохой" может быть игра, в которой всё более-менее нормально, но у неё тупо модели "ватные" и не настроенные. Либо стеклянные стены/кривые коллайдеры как в Psychonauts или WoT (камень на кишке вдоль воды на Монастыре).

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

...а ещё может быть штробление и залагайки (оптимизация графики), у игрока может быть эпилепсия и он полезет в ночной клуб (Cyberpunk2077), сценарий может оказаться слишком аутичным (Stronghold Warlords) или слишком хитрозакрученным (Disco Elysium)...

Потому "скучная" и "не доставляющая удовольствия" игра - это не только плохо скрученные механики. Это может быть плохо скрученный проект "в целом".

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

Иными словами, ГД должен разбираться в нюансах каждой из работ, которыми он де-факто руководит. Если он решает (по факту) за архитектуру проекта - он должен понимать каждый свой шаг. Если он доносит мнение - он должен уметь общаться на языке тех, с кем он говорит.

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

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