Принципы Симуляции в Геймдизайне

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

Главной идеей я выбрал «симуляцию» как основу для всех принципов: моё убеждение в том, что сейчас это то, куда играм стоит развиваться. Это те атрибуты, которые делают игры наиболее увлекательными. Иммерсивными. В такие миры хочется верить, – они поглощают нас и не отпускают. Тот случай, когда игра это искусство. На этом я и сконцентрируюсь. На атрибутах. На принципах. А не конкретных играх.

Сразу отмечу, что во многом эти принципы основаны на заповедях старой Arkane Studios, не так давно которые перевёл для вас Ярослав Голубев, – мой подписчик, и просто человек с которым интересно обсуждать идеи касательно геймдизайна.

Всё же на мой вкус, хотя в их заповедях действительно дельные мысли, а в совокупности их было аж 20 штук... Непросто удержать в голове двадцать идей одновременно. Хотелось бы объединить их под какими-то категориями и некой общей идеей. Чтобы можно было взглянуть на краткий список, как в шпаргалку, – и сразу вспомнить всё важное, настроить свой мозг, как геймдизайнера, на производство годноты.

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

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

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

Пример: физика движения машин в GTA как бы немножечко «неидеальна», в математическом смысле. Физика не абсолютна, не мгновенна: недостаточно просто затормозить, но есть ещё такая штука как инерция. Тогда как искусственный интеллект сравнительно прост, и не особенно-то учитывает эту инерцию. Если учитывает вообще. Итого, игрок может порой увидеть такую картину: маленькая авария (столкновение), после которого пострадавший водитель выходит из машины, кричит какие-то оскорбления другому, вываливает неприятеля из машины, и затевается драка. Сама по себе эта драка водителей, – это не какой-то отдельный сценарий, напрямую запрограммированный кодом. Это поведение, родившееся из столкновения двух систем: неидеальность физики, неидеальность искусственного интеллекта. И взаимодействие рождается из небольших общих точек соприкосновения с логикой уровня: «Если тебя кто-то ударил, нужно ударить его в ответ».

А чтобы такая ситуация не была уж совсем уникально-редкой, а всё-таки возникала хотя бы просто редко, – неидеальность физики GTA усугубляют специально тем, что делают ИИ немножко более несовершенным чем полагается. Разные NPC имеют разные характеристики, и не все они, как под копирку, хорошо водят. Некоторые реагируют хуже, тормозят позже чем нужно, – и таким образом более склонны попасть в аварию.

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

Многие геймдизайнеры дадут вам определение что-то вроде: «Система это то что работает всегда, тогда как вещи которые работают лишь иногда, – это механики». В сфере программирования есть паттерн «ECS», – Entity, Component, System. В этом паттерне все системы являются неотъемлемой частью так называемого «game loop».

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

Вместо построения систем, игры иногда задают поведение NPC «скриптами», – слово пришедшее из кинопроизводства и по сути означающее сценарий, чёткую последовательность действий. Но такой подход создаёт эффект скорее фильма нежели чем игры. Всё-таки главное преимущество игр в некой необыкновенной динамике между тем что на экране, и игроком. Сценарный подход можно использовать локально, в некоторых местах, – там где хочется добиться конкретных эмоций, создать 100% контролируемый кинематографичный эффект. Сценарий и скрипты тоже важны. А вот лучший способ добиться именно той самой динамики недоступной фильмам и свойственной только играм, – это создание разнообразных систем.

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

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

Существа и активности. Существа должны постоянно иметь дела которыми им стоит заняться, – что-то помимо того чтобы убить игрока. Игрок должен почувствовать что мир крутится не вокруг него, а живёт сам по себе. Враги не должны просто стоять и ждать когда к ним придут их убивать, а должны заниматься какими-то своими активностями: кушать, охотиться, спать, развлекаться-умываться. Дикие животные могут порой подраться друг с другом в конкуренции за добычу, а бандиты могут не поделить между собой награбленное и тоже подраться. Торговцы могут торговать с обычными жителями, а не только с игроком. А когда посетителей нет, торговцы могут иногда ходить по магазину, расставлять или переставлять предметы на витринах, выставляя самые ценные лоты на самые презентабельные места, – возвращаясь к стойке лишь когда к ним зайдёт посетитель.

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

Разумеется этим процессам нельзя мелькать перед глазами игрока 24/7 и тем самым наскучивать игроку. Наоборот, бандиты могут напасть на торговца весьма редко, – а потом долго живиться награбленным. Стражи могут далеко не всегда находить бандитов, если вообще согласиться искать. А война королевств может быть ещё более редким событием, а то и вовсе важным сюжетным поворотом. Но недостаточно просто какое-то событие сделать редким: самих подобных событий должно быть большое разнообразие. Тогда не смотря на то что конкретное индивидуальное событие может случиться редко, – в целом же, постоянно должно происходить что-то интересненькое. Пищевые цепочки позволят обеспечить некоторый минимум взаимодействия мира самого с собой.

Система потребностей. Пить, кушать, – это должно быть не только потребностью игрока, но и NPC. Очень классно система потребностей реализована в серии Sims. Хотя из-за фокуса игры на геймплее уровня «тамагочи», – лично мне «Sims» не нравится, но механизм системы потребностей этой игры весьма гениален, и ему может позавидовать даже система расписаний Radiant AI от Bethesda. Такой подход позволяет грамотно организовать весьма сложные поведения, и практически неограниченно расширять их разнообразие при необходимости.

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

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

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

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

Предположим, когда игрок заходит к торговцу, с 50% вероятностью там появляются покупатели перед ним, и придётся ждать очередь, – то если в первый раз он может обмануться, и подумать: «Какой глубоко проработанный мир, тут даже NPC друг с другом торгуют, что даже возникают очереди», – но как только он понимает что эти очереди возникают не ввиду каких-то естественных причин а буквально спавнятся у него перед носом, то в этот момент игрок может налиться яростью к игре: она его обманывает и попросту тратит его время. Вместо погружения, игрок жалуется на игру и разработчиков: его восприятие уже не внутри мира, а где-то во вне. Иммерсия нарушена. Геймдизайнер облажался.

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

Чтобы что-то появилось, оно должно где-то обоснованно взяться. Так что придётся забыть о спавнящихся по ходу игры существах, предметов, или ресурсов. У торговцев нет бесконечного золота, нет бесконечных товаров, и нет автоматически пополняющихся припасов: товары им должны физически откуда-то завести.

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

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

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

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

Цикл жизни и смерти предметов поможет избавиться от того что называется «инфляция и перепроизводство». Без смерти предметов, экономика встанет, – начиная с заключительных цепочек производства, условных стальных мечей, и далее вниз: сначала все мечи будут выкованы, склады будут заполнены, потом шахтёру некуда будет деть железо, в виду отсутствия работы он перестанет зарабатывать на хлеб, пекарю будет незачем производить этот хлеб потому что его больше не покупают, и так далее. Экономика рухнет. Поэтому у предметов должна быть какая-то форма смерти, желательно несколько видов смерти.

Пример: созданный кузнецом меч, который прошёл через дюжину цепочек производства, – должен так или иначе найти свою смерть. Меч должен испортиться. Тренировочные мечи могут портиться в виду тренировок. А чтобы портились боевые мечи, – должны быть какие-то локальные битвы, сражения с бандитами, и/или война между целыми королевствами. Тогда после баталии будет собрано сломанное оружие, после чего его переплавят обратно в железные слитки чтобы снова из них что-то выковать. Альтернативно, мечники могут уйти воевать в какой-то портал других измерений, – где умрут. Тогда экономика вовсе потеряет меч целиком а не его часть, – что является даже более сильной формой смерти предмета чем просто его порча. Полная смерть предмета даст гораздо больше пространства для возобновления производства. То же касается и жизней воинов.

Всё это такие «трюки» чтобы продлить жизнь мира в целом, и наверное можно его даже таким образом зациклить и создать вечно живущий мир. Для какой-то игры, всё же, вероятно подойдёт вариант ограниченного по жизни мира, где в какой-то момент игры пойдут титры, либо будет показан экран результатов [score screen], – и на этом мир как бы «умрёт». Главное чтобы это было продуманным изначально решением, а не хоть каким-то решением к которому вы пришли просто потому что не справились с созданием экономики.

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

Не обязательно прям полномасштабно симулировать абсолютно всё: это как минимум невозможно. Но и не всё из этого нужно. Например, если от нашего мира вам не нравится что существам нужно какать, – всё, решено: в вами созданном мире никому не нужно какать! И это прекрасно.

Некоторые решения могут тянуть за собой слишком долгие обязательства. Например, если всё-таки NPC должны кушать и пить, и могут умереть если им этого не хватает, – то это требует ювелирной работы над балансом. Такой мир может оказаться весьма хрупок: где-то закончилась рыба и начали умирать рыбаки, а следом за ними и весь город который по сути жил на рыбе. Здесь едва ли что-то можно посоветовать, кроме того, чтобы делать вспомогательные инструменты которые будут помогать выявлять такие проблемы: в идеале, мир должен быть достаточно стабилен хотя бы без игрока. Но даже с игроком мир тоже не должен во мгновенье развалиться. Весьма крутой идеей считается программировать ИИ-игроков, которые на правах игрока, имея все те же самые возможности и способности, – играли бы в игру, пусть даже по упрощенному сценарию. Поскольку всё слишком индивидуально, вам не подойдут какие-то готовые решения: пока что ещё нету ИИ-тестировщиков. Придётся разрабатывать дополнительные инструменты под специфику вашей конкретной игры. Не обязательно полноценных ИИ-игроков, но какие-то автоматизированные проверки, – наверняка. В игровой индустрии это почему-то до сих пор не очень популярно, хотя некоторые пытаются подобные инструменты создавать. В сфере разработки программного обеспечения такие автоматизированные тесты сплошь и рядом: они позволяют добиться стабильности системы. Ведь даже малейшее изменение компонентов системы может повлечь за собой резкие изменения работы системы в целом. Чтобы разрабатывать такой сложный динамический мир, вероятно придётся перенять эту хорошую практику создания автоматизированных систем тестирования из сферы разработки программного обеспечения, – в геймдев.

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

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

Если всё-таки мир получается слишком большим и сложным, и требуется совсем прекратить симулировать существ и прибегнуть к механике спавна-деспавна, то рассмотрите хотя бы вариант фонового режима не на уровне существа, а на уровне поселения или локаций, – где судьбы существ будут высчитываться общим алгоритмом локации, а не индивидуально выделенным алгоритмом под каждое существо. Тогда самих существ можно удалить из мира но оставить слепок информации о них, – который помалу видоизменять общим алгоритмом, а некоторые параметры не придётся просчитывать вовсе. Не придётся симулировать их нужду в еде, например, – эти параметры можно динамически высчитать из общей таблицы на момент спавна. Допустим предполагается что NPC покушает в определённые часы игрового времени: 6 утра, 12 дня, 18 вечера. Это означает, что в эти часы на момент спавна у них должна быть 100% удовлетворена потребность в кушанье, – и этот параметр можно динамически рассчитать на другие часы в процентном соотношении. Такой подход уже ближе к имитации, но всё-таки гораздо лучше чем многим уже привычные весь день рубящие одно и то же дерево дровосеки.

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

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

Если вы делаете например лес, – казалось бы, по своей сути это достаточно скучная и пустая локация: не делайте его слишком пустым! Мы не проектируем скучную реальность, а проектируем интересную симуляцию. Каждый лес старайтесь разнообразить различными животными, – на которых можно, например, поохотиться. Собрать с них мясо и шкуры. Или наоборот: необходимость убегать от них (волки, медведи). Собрать грибы или ягоды. Или зарытый клад, – о котором игрок может знать лишь при определённых обстоятельствах. Или едва заметный проход в подземелье. Каждая такая интерактивность делает локацию более плотной в смысловой сфере. Локация становится слишком населена чтобы назвать это «скучный лес». Он уже вовсе не скучный.

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

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

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

Не стоит забывать о других принципах, напомню: со всеми этими бочками-сундуками, в идеале, должен взаимодействовать и сам мир. Также как с существами, объекты взаимодействия должны существовать не для одного лишь игрока чтобы он их залутал. NPC должны использовать контейнеры тоже: что-то туда ложить а потом оттуда брать. Уж по крайней мере, если это какая-то стойка в таверне или сундук в чьем-то доме, он должен использоваться. И это не просто какая-то прихоть адепта симуляции ради некой «реалистичности». Если у вас например RPG, и есть класс вора, то такая функция создаст дополнительные возможности отыгрывать свою роль игроку: и утащить что-то из ящика, вместо того чтобы рисковать шарить по карманам.

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

Вертолётик в Vice City был бы отличным примером, если бы только столь много людей не жаловались о том какой он сложный. В любом случае, это должно быть что-то что игрок ещё вероятно не делал, или даже вовсе никогда не будет делать за оставшееся прохождение. Не всегда это должны быть крупные и совершенно уникальные механики, по типу управления краном в GTA5, – это крутая возможность, но главное чтобы такое занятие *ощущалось уникальным*. Я привёл в пример вертолётик, потому что по своей сути, он не привносит новую механику: это буквально механика уже имеющегося полноразмерного вертолёта, – лишь в формате миниатюрной модели. Но оттого не менее уникальным и оригинальным ощущался данный опыт, ведь вам нужно пролететь на этом маленьком вертолёте ВНУТРИ ЗДАНИЯ... Ощущается вполне уникально.

Старайтесь чтобы основной сюжет всегда привносил новое. Тогда как необязательным заданиям позволительно быть более репетативными, – например серия уличных гонок, серия контрактов на убийство, серия контрактов на кражу, серия доставок пиццы. Но лучше не делать эти активности бесконечными: даже самый лояльный во всём мире игрок не сможет поиграть в вашу игру бесконечное число раз. Если всё-таки очень хочется сделать активности бесконечным, то мотивируйте пряником: единожды дайте игроку какой-то бонус или ачивку после определённого количества повторений подобных заданий, и как бы намекните игроку:
«Тут ты уже добился всего, и ничего нового здесь ждать не стоит».

Повествовательная срочность. Типичной картинкой будет следующее: главный герой должен срочно кого-то спасти, чаще всего от гибели. Повествовательная срочность. В то время вы, как игрок, ходите-занимаетесь всякими отстранёнными вещами: выпить кружку эля в таверне, поиграть в картишки, снять парочку куртизанок. А потом в первой же катсцене проявляете впечатление истинного спасителя срочно бегущего на помощь, – смысловой конфликт сюжета и геймплея… И это не проблема игрока. Конечно этой проблемы не возникает если игрок игнорирует, собственно, игру, – и просто бежит по сюжету ни на что не отвлекаясь. Но такой подход не должен быть нормой, и разработчики должны как-то это учитывать, по крайней мере в местах где это действительно важно.

Помимо очевидного «обойти проблему» и не вводить повествовательную срочность, – также можно дать игре какую-то возможность отреагировать на поведение игрока. Допустим, есть срочный квест на спасение заложников… Игра тебе не скажет заранее но если ты слишком долго занимаешься какой-то фигней, то по окончанию квеста игра корректно реагирует, и потом какой-то генерал читает тебе лекции что мол ВОСЕМЬ ЧЕЛОВЕК погибли из-за того что ты промедлил, отношения с ключевыми лицами портятся, – а ближе к концу игры эти отношения повлияют, например, на исход сюжета. Тогда уже не возникает такого диссонанса между сюжетом и геймплеем. Разумеется такие ветвления делать сложнее, это дополнительная работа, которую не все игроки увидят, – но такова цена решения о добавлении повествовательной срочности в игру.

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

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

Хорошее поселение, судя по книге «Образ Города» Кевина Линча, должно содержать в себе следующие пять видов элементов:

Узлы, – это пересечения дорог и связанные с ними локации наподобие рынка или таверны. Обычно густо населены.

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

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

Границы, – место где одна среда переходит в другую: стены, забор, ворота или берег. Не обязательно граница должна быть непроходимой: главное чтобы она визуально распознавалась.

Районы, – территории города обладающие некоторой однородностью. Характер района может быть определен архитектурой строений, особенностью функций района, плотностью застройки, социальными характеристиками обитателей, рельефом, степенью ухоженности.

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

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

Одним из таких примеров был упомянут в моей прошлой статье: возможность подпереть дверь предметами в Half-Life. Эта возможность не дана игроку явно, нигде не подсвечена кнопка: «заблокировать дверь предметами». Игроку нужно моделькой своего персонажа дотолкать окружающие предметы к двери, и что особенное здесь: NPC действительно не смогут к вам зайти, и притом они не начинают тупить, и не продолжают долбиться в дверь, – так было бы если ситуация не была продумана геймдизайнером заранее. Вместо этого, они идут на позицию к окну и начинают случайным образом обстреливать внутренности дома в котором находится игрок. Эта игровая функциональность дана игроку неявно.

Ещё одним примером послужит мир монстров Dark Souls, – где было бы странно давать возможность постучать в дверь. Тем не менее, есть в игре одна металлическая дверь в которую всё-таки можно постучать: для этого нужно ударить оружием по двери, и тогда монстры (полые) отреагируют на этот звук, открыв дверь изнутри.

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

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

#геймдизайн #лонг #игры #simulation #immersivesim #gamedesign