Как создать успешную игру? Основные секреты и правила
Все мы хотим создавать успешные игры: инновационные, любимые игроками и, конечно же, прибыльные. Вопрос в том, есть ли какой-то путь или рецепт, который позволил бы нам создавать успешные игры? Определенно! Но, чтобы его найти, необходимо более четко определить, что такое успешная игра. Как только нам станет ясна наша цель, мы сможем понять, как к ней идти.
Содержание
- Как выглядит успешная игра с точки зрения игроков?
- Почему и кто?
- Составляющие игры для привлечения игроков
- Выводы
- BENDY and the INK MACHINE
Определение успеха игры с точки зрения прибыли является самым простым, но размышления о прибыли не очень помогают выяснить, какие ингредиенты и процессы необходимо использовать, чтобы игра была успешной. Какой стиль/жанр принесет вам больше прибыли? Это трудно знать и сложно проверить. Кроме того, в некоторых случаях успех может быть связан далеко не с прибылью, а с обучением чему-то, привлечением внимания к чему-то, например, в образовательных, рекламных и других развивающих играх.
Чтобы найти путь к успеху игры, с точки зрения разработчика, то лучше всего считать за успех — вовлеченность игроков. Взаимодействие игроков в большинстве случаев тесно связано с успехом игры, но здесь важно то, что взаимодействие — это то, что мы больше контролируем как разработчики, и это то, что более непосредственно связано с ингредиентами и решениями, с которыми мы имеем дело во время разработки игры. Вопрос о том, какая конкретная история принесёт больше дохода, обычно неясен и его трудно проверить. С другой стороны, вопрос о том, какая история будет более привлекательной для нашей целевой аудитории, не только более ясен, но его и намного легче проверить.
Как выглядит успешная игра с точки зрения игроков?
При разработке успешной игры следует сделать четыре последовательных шага:
- Выделяться: игра должна выделяться и быть заметной. Если никто не знает о вашей игре, никто в неё не будет в неё играть.
- Контактировать: игра должна контактировать с игроками и должна заинтересовать их в получении дополнительной информации. Кто-то, кричащий посреди улицы, будет замечен, но сам акт крика не заинтересует людей. Люди будут реагировать только тогда, когда они объединены или резонируют с тем, что они слышат. То же самое происходит и с играми, которые привлекают ваше внимание в магазине приложений или в первые пару минут игры.
- Вовлекать: игра должна привлекать игроков и удерживать их в процессе игры. Это может быть не для всех игр, но в большинстве случаев, чем больше времени игроки проводят в игре, тем более прибыльной она становится: больше шансов монетизировать, больше шансов продать подписку, больше шансов, что её порекомендуют друзьям и т.д.
- Масштабироваться: наконец, игра должна иметь возможность масштабироваться и увеличивать количество постоянных игроков.
Что полезно в определении этой последовательности, так это то, что теперь можно посмотреть на все составляющие, которые нам понадобятся при разработке игры (арт, механика, история, социальные функции), и выяснить, работают ли они, чтобы помочь игрокам пройти всю игру от начала до конца.
Но, сначала поясним. Почему и Кто
Конечно, ни одна из описанных вещей не имеет никакого значения, если в конечном счете вы не можете достигнуть целей, которые были поставлены вами при разработке игры. Вы можете привлечь игроков и удержать их в игре, но если вы пытаетесь сделать образовательную игру, и ваша игра не обучает, вы не преуспеете, даже если вы собрали тонны игроков, которые проводят время в игре.
То же самое касается монетизации: если у вас сотни тысяч игроков, но вы не монетизируете или не получаете прибыль, которую вы хотели бы получить, то скорее всего вы потерпите неудачу. Вы должны убедиться в том, что ваша игра вовлекает игроков, при этом обучает и/или монетизирует. Это такая большая часть трюка, но о ней мы поговорим в следующей статье. Пока же давайте придерживаться основ: вы должны иметь очень четкое представление о целях вашей игры. Убедитесь, что всё что вы делаете вращается вокруг этих целей.
Не менее важно иметь четкое представление вашей целевой аудитории.
Всё что необходимо для привлечения детской аудитории, очень отличается от того, что необходимо для привлечения молодой и взрослой аудитории. Чтобы понять, какие составляющие необходимо использовать, вам нужно понять, кто ваша целевая аудитория.
Составляющие для привлечения игроков
Существует четыре основных элемента, которые очень эффективно сочетаются для привлечения и удержания внимания игроков: визуальное оформление, забавная механика, интересная история и создание сообщества:
- Визуальное оформление: — это то, что бросается в глаза вашим игрокам и заставляет их захотеть поближе взглянуть на вашу игру. Во-первых, игроки не будут знать много о конкретной механике и истории в вашей игре. Они будут уделять больше внимания эффектам, с которыми им придётся взаимодействовать.
- Развлечения: визуальное оформление, насколько бы оно ни было крутым, не сможет удержать игрока надолго. Забавные и понятные вещи, четкие цели, вот что заставляет игрока проводить больше времени в игре.
- История: даже забавные события надоедают, если за ними нет большого смысла и целей. Игре нужны цели и история, которые будут увлекать игрока и заставят его возвращаться к игре снова и снова. Стрельба, это конечно интересно и весело, но делать это каждый день в течение нескольких часов может быстро наскучить, если всё это не сопровождается какой-то историей, обучением или соперничеством с другими игроками.
- Сообщество: все хорошие истории имеют конец. Поэтому стоит задуматься о возможности создания сообществ для игроков. Игры, к которым мы возвращаемся снова и снова, — это те, которые позволяют нам создавать сообщества и общаться/соревноваться с другими людьми. Поверьте, игроки будут взаимодействовать с вашей игрой годами.
Все эти четыре элемента важны при разработке успешной игры, которая следует последовательности:
- Выделяться.
- Контактировать.
- Вовлекать.
- Масштабироваться.
Важность визуального оформления, веселья, истории и сообщества может переходить от одного шага этой последовательности к другому. Например, отличия больше зависят от визуального оформления, чем от деталей истории. Опять же, вовлеченность зависит гораздо больше от механики и истории, чем от визуального оформления, а масштабирование больше зависит от возможности создавать и развивать сообщества. Существует множество хороших игр, которые не увенчались успехом, потому что им не хватило одного или нескольких из этих важных элементов.
Также стоит отметить, что большинство игр, от бесплатных мобильных игр и до VR и образовательных игр, смогут выиграть при наличии всех этих составляющих. Если вы решите, что вам не нужен один из этих ключевых элементов — если вы думаете, что вам не нужна история или вам не нужна механика построения сообществ — по крайней мере, у вас должна быть очень веская причина, почему нет.
Есть и другие элементы игры, о которых не стоит забывать:
- Монетизация
- Маркетинг
Монетизация имеет важное значение для устойчивого развития игры. Маркетинг может помочь вашей игре быть замеченной. Еще более важным, чем само маркетинговое продвижение, является определение вашей целевой аудитории на рынке, а также получение обратной связи от целевых игроков на протяжении всего процесса разработки. Тогда визуальное оформление, механика, история и социальная механика вашей игры будут резонировать с вашими игроками, и ваш маркетинг будет встроен в другие элементы разработки.
Выводы
Определения 1) Ваша цель и 2) успешная игра (с точки зрения конкретных шагов вокруг взаимодействия игроков) являются наиболее важными первыми шагами в создании вашей дорожной карты по разработке успешной игры.
В качестве второго шага вам нужно посмотреть на все составляющие, которые могут помочь вам найти правильный рецепт: визуальное оформление, механика, история и сообщество. Когда вы объединяете все эти элементы в игру или опыт — визуальное оформление, которое взаимодействует с вашей аудиторией, механика, которая забавна и имеет четкие цели, история, которая вносит смысл и контекст, сообщество, которое заставляет вас чувствовать частью чего-то большего, чем вы сами — ваш игровой опыт становится более интересным.
Важно отметить, что поиск правильного сочетания этих элементов является большей частью проблемы. Какой визуальный стиль использовать? А что насчет механики? Какая будет история и что она раскрывает? Все эти вопросы необходимо решать и тестировать в процессе разработки, а использование правильных процессов облегчает поиск ответов.
Ещё одна важная вещь, которую нужно отметить, что эти элементы гораздо более эффективны, когда они работают вместе. Мультяшный стиль не может быть лучшим вариантом для хоррора, но бывают исключения, например BENDY and the INK MACHINE.
Ваши элементы должны соответствовать и поддерживать друг друга, чтобы общее ощущение от игры было самым лучшим.
Настраиваем геймплей с помощью простой системы сбора и анализа игровых показателей / Хабр
В этой статье, взятой из сентябрьского выпуска 2010 года журнала Game Developer’s Magazine, Chris Pruett, работающий в Google консультантом по разработке игр, рассказывает как он быстро и несложно реализовал удобную систему оценки игрового процесса в своей игре на платформе Android, под названием Replica Island.
Ничто не сравнится с ощущением, которое испытываешь, наблюдая, как кто-то играет в созданную тобой игру. В процессе разработки игры ты играешь каждый день, и вырабатываешь, возможно неосознанно, определённый стиль игры.
Но отдавая свою игру в руки другого человека, ты получаешь возможность увидеть, что происходит с твоим творением, когда им пользуются без такого, как у тебя, ежедневного игрового опыта.
Каждая возникающая проблема, сбой в анимации, непонятный текст в руководстве и периодические ошибки, производят намного сильное впечатление, когда в игру играет новичок. Неважно как долго ты оттачивал игровой процесс и сколько ошибок ты исправил, твой выработанный стиль игры и твоя особая вовлечённость в геймплей, создаваемой тобой игры, может помешать тебе ясно увидеть проблемы, с которыми сразу могут столкнуться другие игроки.
Вот почему тестирование геймплея — это жизненно важная часть процесса создания хорошей игры. Чтобы получить максимальную отдачу от тестирования, нам потребуется сохранять информацию о процессе прохождения игры. Эта статья описывает мой опыт в решении этой задачи.
Начиная с малого
Мои первые шаги в игростроении я делал, создавая игры для Game Boy Advance.
В то время подход к тестированию был довольно простым: мы давали соседским ребятам специальное устройство Game Boy Advance, подключённое к видеомагнитофону, записывали их игру, после чего просматривали записи. Это позволяло нам отлавливать явные и крупные ошибки.
Участки игры, прохождение которых вызывало сильные отрицательные эмоции у ребят, принимались к дополнительной проработке. Когда игрок раз за разом терпит неудачу в определённом месте игры — это ясный сигнал к тому, что эту часть геймплея надо переработать. Несколько игровых прогонов с помощью соседских ребят и мы могли заметно улучшить наши игры.
В настоящее время я работаю консультантом в области создания игр для Google Android. Моя первая игра для этой платформы, аркада Replica Island, не сильно отличается от игр для Game Boy, которые я писал 10 лет назад. Но кое-что изменилось — я не работал больше на компанию, создающую игры, я написал её для себя, с помощью одного художника, в основном работая в свободное время.
Теперь у меня нет доступа к аудитории юных бета-тестеров, что был в то время. И даже будь этот доступ, нынешняя целевая аудитория для игры несколько старше.
В конце концов нет простого способа собирать информацию о прохождении игры на телефоне. Единственный способ — это стоять «над душой» во время игры, но это неудобно, и может влиять на то, как игрок играет, что снижает чистоту эксперимента.
Как-же поступить независимому разработчику? Завершив разработку Replica Island, я понял, что нет никакой гарантии того, что играть в эту игру будет интересно. Игра разрабатывалась «в вакууме» и мне был нужен сторонний взгляд на игровой процесс, прежде чем я мог быть уверен в том, что игру пора выпускать.
Первое, что я попробовал — это были опросы. Я расположил игру на внутреннем сервере компании, где я работал, и разослал письма сослуживцам, с просьбой поиграть и прислать мне свои впечатления. Я даже развернул небольшой форум с вопросами об игре. Этот подход не сработал.
Несмотря на то, что многие скачали игру, очень немногие, менее одного процента от скачавших, потрудились ответить на мои вопросы. К тому-же ответившие на вопросы не дали достаточно информации. Трудно понять, что именно явилось причиной оценки «в игру трудно играть». Явилось-ли причиной неудобное управление в игре, неудачный дизайн уровней, расположение препятствий в игре, руководства к прохождению уровней, либо ещё что-то.
Размышляя над системой показателей
После того случая, я подумал о системе сбора и обработки показателей для игрового процесса, которая была разработана компанией Naughty Dog для игры Crash Bandicoot.
Система записывала статистику о процессе игры на карту памяти. Эти данные потом собирались (в оффлайне) с целью обнаружить трудные для прохождения участки, или участки, где игровой персонаж наиболее часто погибал.
Эти проблемные участки были переработаны, а эта информация была также использована для системы динамической настройки сложности игры.
Одним из интересных принципов, которым я руководствовался при создании своей системы, была идея компании Naughty Dog о том, что надо избегать завершения игры всеми силами. Их конечная цель заключалась в устранении моментов, когда игрок застревал на каком-то этапе и не мог продолжать игру.
Мне понравилась эта идея, но я тогда не понимал насколько это реализуемо для игры на телефоне. Я немного поспрашивал у окружающих, чтобы понять текущее положение с записью статистики для игр с большими бюджетами. И узнал, что многие компании используют механизмы сбора информации об активности игроков.
Несколько человек сказали, что несмотря на то, что они собирают большой объём информации, они испытывают трудности в обработке и в представлении этих данных в форме, удобной для восприятия и понимания того, что надо изменить в исследуемых играх.
С другой стороны некоторые студии обладают инструментами, которые могут воссоздать перемещения игрока по уровню и генерируют статистику о том, какое оружие предпочитают игроки, каких противников труднее победить, и какие части карты явно видимы в том или ином случае.
Складывается впечатление, что формирование набора показателей для игрока применимо для широкого класса игр, но это оправдано только для крупных компаний, которые вкладывают значительные ресурсы для построения инструментария обработки собранных данных.
Пример того, как такой тип систем может быть наиболее эффективно использован, можно увидеть в выступлении Георга Золлера (Georg Zoeller) о замечательной системе телеметрии, которую они используют в BioWare.
Получалось, что сбор данных об игровом процессе — это лёгкая часть задачи, а вот интерпретация этих данных таким образом, чтоб дать понятную и полезную создателям игры картину — это намного сложнее.
Это прозвучало обескураживающе, так как я старался держать свой набор инструментов настолько простым насколько это возможно. Но я решил всё-же поэкспериментировать с некоторыми ключевыми показателями.
У моего Android-телефона не было карты памяти, но было постоянное интернет-соединение. Возможно, подумал я, я смогу фиксировать некоторые важные события в игре, отправлять их на сервер и получать с него результаты.
Моя цель была понять как можно больше о том, как играют в мою игру, при этом оставляя систему настолько простой, насколько это было возможно.
Базовая система
Система, которую я написал, состояла из трёх частей: поток выполнения, который во время игрового процесса собирает данные о действиях игрока и отправляет на сервер, сервер как таковой, и инструмент для обработки собранных данных.
Сервер — это слишком громко сказано, конечно. Мой сервер был представлен 30-ю строчками PHP-скрипта, который проверял GET-запрос по HTTP и записывал результаты в базу данных MySQL. Структура GET-запроса, в свою очередь, тоже была очень простой. Это название события, координаты, версия кода, идентификатор сессии и временная отметка (timestamp).
Эти данные, прямо в поступившем виде, заносились в базу данных. Текущая обработка данных также выполнялась в PHP, когда открывалась специальная страница на сервере. Не очень хороший выбор в долгосрочной перспективе, об этом будет сказано ниже по тексту.
Я начал с регистрации двух событий: гибели игрового персонажа и завершения уровня. Каждый раз, когда игровой персонаж погибал, либо игрок завершал уровень, игра отправляла соответствующее событие на сервер. Из этих данных я впоследствии смог сформировать довольно детальное представление об игровом процессе.
Я смог увидеть, какие уровни требуют наибольшее время для прохождения, на каких уровнях игрок чаще всего погибает, и которые из них слишком быстро проходит. Сгруппировав эти данные по игрокам, я увидел какой процент от всех игроков погибает на том или ином уровне, и среднее значение неудач для каждого игрока.
Анализируя координаты того или иного события, я мог сказать, в каких случаях игровой персонаж погибал от действий врага, а в каких от падения в яму. Для начала моя простая система показателей была неплохо детализирована.
Отмечаем неудачи на карте ярко-красным цветом
Как только моя базовая система стала работать, я выпустил обновление для бета-тестеров и стал наблюдать за поступающими данными.
Довольно быстро были выявлены повторяющиеся ситуации.
На некоторых уровнях почти сто процентов игроков терпели неудачу как минимум один раз, а на других уровнях игроки застревали на несколько часов, что означало неудачно спроектированный уровень, так как его предполагалось проходить в течении нескольких минут. Анализируя эти данные, я получил чёткое представление о том, какие уровни требуют доработки.
Но определение проблемных уровней не было достаточным. Иной раз я не мог сказать почему на том или ином конкретном уровне возникала проблема.
И я продвинулся на шаг вперёд. Используя те-же самые данные, я написал инструмент, чтобы обозначать на карте уровня местоположение гибели игрового персонажа. И я смог увидеть где именно игровой персонаж погибал, а где нет.
Первый прогон системы показал лишь маленькую точку на уровне, где погиб игровой персонаж. Но с увеличением количества игроков я начал получать что-то вроде тепловых карт (heat maps), обозначающих места гибели игроков на картах уровней, которые было намного проще воспринимать.
Глава, посвящённая созданию тепловой карты, будет представлена ниже по тексту.
Тепловая карта, сгенерированная на основе данных о гибели игровых персонажей в Replica Island
Наглядное пособие по просчётам в дизайне игры
Комбинация высокоуровневой игровой статистики и обозначение на уровнях мест гибели игровых персонажей пролила свет на недочёты в игровом дизайне. Я понял, к примеру, что большое количество игроков погибало при встрече с самым первым монстром. Это было не потому, что монстр был очень силён. После детального изучения ситуации я пришёл к выводу, что монстр появлялся в месте, где главный способ атаки — прыжок сверху — был трудно реализуем из-за низко расположенного потолка.
Я также понял, что моя простая система динамической настройки сложности игры сама требовала коррекции. Эта система, не афишируя сего факта, увеличивала продолжительность жизни игрового персонажа и энергию для его полёта после определённого количества последовательных смертей.
Изучая статистические данные я понял, что ей это следовало делать намного раньше.
Также основательные изменения претерпела структура моих уровней. У меня было достаточное количество уровней с высоким временем, которое затрачивалось на их прохождение, но с малым количеством смертей. И я понял, что игроки попросту заблудились на уровне. Я переделал эти уровни, чтобы сделать порядок их прохождения более понятным. В паре случаев я даже полностью переделал уровни с нуля.
Но наибольшей проблемой, с которой я столкнулся были ямы. Replica Island — это платформер, и, как вы можете догадаться, в ней игроку надо делать большое количество прыжков над ямами. В отличие от постоянно вращающихся сумчатых и обитающих в трубах сантехников, у моего игрового персонажа главным способом перемещения был полёт.
Мне была нужна система контроля за игровым персонажем, которая не требовала бы наличия геймпада. Так как главный герой игры, зелёный робот Android использовал ракетные двигатели на ногах, чтобы летать.
Базовая модель движения заключалась в том, чтобы получить импульс ещё на поверхности перед прыжком и, используя этот импульс, с помощью двигателей лететь в нужном направлении. Двигатели расходовали энергию довольно быстро, но энергия возобновлялась при приземлении. И идея заключалась в том, что игрок будет совершать прыжок, а затем, аккуратно расходуя энергию, достигать нужных мест, либо совершать точные прыжки на противников, атакуя их.
Всё это было хорошо, но когда я посмотрел на статистику гибели игровых персонажей, которая приходила от бета-тестеров, я обнаружил, что они, в массе своей, погибали в бездонных ямах. Толпы игроков проваливались даже в самые небольшие ямы. И больше беспокоил тот факт, что с течением игры количество смертей в ямах не уменьшалось. Игроки никак не улучшали свои навыки в преодолении препятствий в течении игры.
После чего я внимательно изучил дизайн игры и дизайн уровней и сформировал несколько теорий. Основной проблемой, по моему пониманию, было то, что игроки не видят ям тогда, когда они находятся в прыжке.
В конце концов, во время прыжка не было заметно наличие простой ямы либо ямы-ловушки на месте приземления. И так как мои уровни зачастую очень высокие, то трудно определить которые ямы вели на подземные уровни, а которые из них вели к страшной смерти.
Вторая и более важная проблема заключалось в том, что поведение камеры, показывающей главного героя игры, было не очень хорошо проработано. Когда главный герой совершал прыжок в высоту, поверхность земли исчезала из поля зрения. В результате чего было трудно определить верное место для приземления.
Известные платформеры вроде Super Mario Bros практически никогда не выполняют вертикальный скроллинг. В Mario есть целый набор сложных правил, определяющих ситуации, когда камера может двигаться вверх и вниз. Однако в моей игре наличие механики полёта означало, что я разрешаю вертикальный скроллинг во всех случаях. После большого количества внесённых исправлений я получил более умное поведение камеры, которая не начинает движение вверх, если только сам игрок не приблизился к границе отображаемой области.
После всех этих изменений я выпустил ещё одно обновление для моих бета-тестеров и сравнил результаты с результатами, полученными от предыдущей версии игры. Перемены были очень многообещающие. Общее количество смертей снизилось, время прохождения уровней, в основном, вернулось в нормальные рамки. И смертность от падения в ямы заметно снизилась.
Я повторил процесс тестирования несколько раз, прежде чем был готов к выпуску окончательной версии игры. С моей системой показателей было легко определить как те или иные изменения влияют на прохождение игры бета-тестерами.
Выпуск игры
Итак, после нескольких тестовых прогонов, мои графики стали показывать стандартное нормальное распределение, к которому я и стремился. Пришло время выпускать игру и я решил оставить систему сбора показателей встроенной в игру. Мне было интересно, будет-ли информация, которую я буду получать от новых пользователей, отличаться от той, которую я получал от группы бета-тестеров.
Был только один способ выяснить это.
Конечно, каждый раз, когда игра отправляет данные на сервер, наилучшим решением будет ставить пользователя в известность.
Первое время после выпуска игры в приветственном сообщении, которое показывается с информацией о последних изменениях, была информация о том, что игра отправляет на сервер анонимную и не персонализированную информацию об игровом процессе, чтобы улучшить игру впоследствии. И игроки, которые не желали этого, могли выключить эту систему через меню.
Этот подход казался лучшим решением. Несмотря на то, что код игры открыт, и любой мог изучить структуру отправляемых пакетов данных (я заранее убедился, что ничего из присылаемых данных нельзя сопоставить с конкретным человеком или устройством), я давал игрокам возможность сказать «нет, спасибо».
Сравнивая количество установок из Android Market с количеством уникальных игроков в моей системе показателей, я пришёл к выводу, что менее 20% от пользователей игры отказались передавать данные об игровом процессе на сервер.
Как закономерный результат я получил огромный объём данных для анализа — более 14 миллионов информационных точек, около гигабайта информации о событиях, которые были сгенерированы пользователями моей игры. На момент написания статьи их количество составляло 1 200 000 игроков.
Фактически такой объём информации сломал мою систему довольно быстро. У меня есть статистика, собранная с первых 13 000 игроков, которую я опубликовал на сайте игры Replica Island. Но после выпуска игры, большинство моих инструментов для анализа перестали работать.
Хорошей новостью был тот факт, что первые 13 000 игроков дали статистическую информацию, которая была очень схожа с меньшей по размеру группой бета-тестеров, что, возможно, говорит о том, что результаты, полученные в тестовой группе, могут быть применены к большим группам игроков.
Так или иначе, этот план сработал
Я был очень удовлетворён моей системой учёта событий в Replica Island. С небольшими усилиями, которые мне почти ничего не стоили (серверная часть, которая фиксирует события, обошлась мне меньше, чем аккаунт в Xbox Live), и используя только два типа событий, я был в состоянии быстро и эффективно определить места в игре, где игроки сталкивались с проблемами.
Кроме того, как только я стал собирать эту информацию, я получил возможность сравнивать сводные данные из моей системы, полученные от разных версий моей игры, что дало мне возможность убедиться в том, что вносимые мной в игру изменения дают положительный эффект.
Применение PHP и MySQL для реализации серверной части было хорошим решением. Фиксирование событий было настолько тривиальным, что я уверен, это могло быть просто реализовано на любом языке. На PHP реализация всей серверной части заняла у меня менее получаса.
Использование отдельного потока выполнения для отправки событий на сервер тоже было хорошим ходом. Я не хотел, чтобы пользовательский интерфейс блокировался во время отправки HTTP-запросов, и вынес процесс коммуникации с сервером в отдельный поток выполнения.
Я поначалу опасался замедления работы игры на устройстве из-за этого, но как оказалось, причин для беспокойства не было. Дополнительная нагрузка была настолько незначительной, что я даже не смог заметить её во время профилирования игры.
В конце концов поддержание всей системы настолько простой насколько это возможно было хорошим решением. Я рассмотрел много различных вариантов событий, который я мог регистрировать в моей игре. Но отслеживание момента гибели главного героя игры и завершение уровня предоставило более чем достаточную информацию для анализа.
Больший объём информации привёл бы к усложнению механизмов обработки данных, и, возможно, сделал бы труднее получение чёткой картины в результате. Теперь, когда у меня есть некоторый опыт в создании автоматической системы сбора и обработки показателей, я, возможно, приму решение увеличить в будущем объём данных, которые я отправляю на сервер. Но начало с простой системы было определённо хорошим ходом, на мой взгляд.
Шишки, которые я набил
Не всё в системе регистрации событий работало хорошо. Я принял несколько решений, которые не дали ожидаемых результатов либо просто были потерей времени.
Решение использовать PHP для серверной части было хорошим ходом.
Однако было ошибкой использовать PHP для обработки полученных данных. Моя идея заключалась в том, чтобы делать всё через веб-интерфейс. Я даже написал свой редактор уровней на PHP и JavaScript.
Но PHP стал тормозить, когда объём данных для обработки значительно вырос. PHP работал в очень ограниченном окружении с точки зрения объёма памяти и вычислительных ресурсов. И я почти сразу столкнулся с этими ограничениями. Как только я стал получать информацию от 20 000 игроков большая часть моего PHP-инструментария попросту перестала работать.
В частности проблематичной оказалась обработка изображений а PHP. Я реализовал весь механизм генерации тепловых карт в PHP, но мне следовало написать что-нибудь, что бы выполнялось локально, вместо того, чтобы выполняться на сервере.
Я столкнулся с большим количеством ошибок в интерфейсе PHP GD (формирование изображений с альфа-каналом попросту не работало), и решил просто уменьшить размер изображений уровней для последующей их обработки.
Для этой статьи я переписал этот инструмент используя Python и ImageMagick.
И результаты оказались впечатляющими. Код этой реализации можно скачать с официального сайта Game Developer magazine.
В итоге, хоть эти данные и говорили мне о том, когда игровой персонаж погибал и сколько требовалось времени для прохождения уровней, они не давали мне информации для того, чтобы определить моменты, не связанные с гибелью главного персонажа игры, когда игроки бросают играть в мою игру (game shelf moments).
Я пришёл к выводу, что я выпустил игру с некоторыми ключевыми просчётами в дизайне уровней, которые моя система показателей никогда не обнаружила-бы. В наиболее крайних ситуациях перед игроками вставала задача, которую они не понимали как решить, и попросту бросали играть, не завершив прохождения уровня.
Это никогда не отображалось в моей системе, так как как условие фиксации события завершения уровня так и не наступало. Я узнал об этом только тогда, когда игроки стали присылать мне жалобы на то, что они застревают на одном и том-же месте при прохождении игры.
Моя автоматическая система хоть и была очень удобной, она не показывала мне полную картину игрового процесса. В моём случае показатели были хороши для определения проблемных мест на уровнях, но бы неэффективны в определении просчётов связанных с порядком взаимодействия элементов игры друг с другом.
Будущее
Для моей следующей игры я снова применю подобную автоматическую систему. В дополнение к фиксированию координат гибели игрового персонажа, я, возможно, добавлю события, базирующиеся на форме настигшей его гибели. Это, возможно, будет полезно знать — как именно игровой персонаж погиб, а не только знать где именно это случилось.
И, в зависимости от игры, может быть полезно отправлять на сервер историю перемещений игрового персонажа перед его гибелью на том или ином уровне.
Однако, ключевой момент подобной системы заключается в её простоте. Сбор данных не имеет смысла, пока не созданы надёжные инструменты для их обработки.
Для своей следующей игры я скорее оставлю нетронутой базовую систему отправки данных на сервер и сохранения их базе данных. И сфокусируюсь на создании лучших инструментов для обработки полученных данных.
Также меня интересует, каким образом сводные данные, полученные по игрокам, могут быть использованы для настройки динамических систем управления сложностью игры.
Если игра будет в состоянии получать сводные данные с сервера, это изменит её игровой процесс, базирующийся не только на результатах игры одного игрока, но и на усреднённых данных миллионов других игроков. На мой взгляд это открывает новые интересные возможности.
Сбор и анализ показателей игрока не являются идеальной заменой пользовательскому тестированию. Но они дают очень полезную усреднённую картину. И так как система показателей позволяют тестировать игру на более крупных группах игроков, чем это возможно при работе с индивидуальными бета-тестерами, то система говорит тебе больше об игре в долгосрочной перспективе.
Полученные от системы показателей выгоды с лихвой перекрывали затраты на неё в Replica Island. Сохранив простоту клиентской и серверных частей, я получил много полезной информации о дизайне уровней игры и привычках игроков, и, как результат, игра только стала лучше.
Единственное о чём я сожалею — это то, что я не реализовал такой системы в своих предыдущих играх. Похоже на то, что она применима практически во всех играх любых жанров для любых платформ.
Как генерировать тепловые карты
Генерация тепловых карт не так сложна, но вот поиск точной инструкции потребовал от меня определённых усилий. Я использовал метод похожий на описанный здесь.
Основные действия заключаются в следующем:
- Генерируем изображение круга в градациях серого, цвет которого изменяется от чёрного в центре до прозрачного у краёв по радиальному градиенту. Это изображение для отображения точки, в которой произошло событие.
- Генерируем прямоугольное изображение с цветным градиентом. Низ изображения пусть будет белым или красным, или любого цвета, который вы выберете как обозначение наиболее «горячего» места на тепловой карте. Верх изображения должен быть чёрным с несколькими цветами в промежутке. Это изображение будет использоваться как «словарь» для формирования графического отчёта по статистическим данным позднее.
- Генерируем список координат прошедших событий.
- Рассчитываем максимальное количество точек возникших событий, которые находятся в непосредственной близости друг от друга. Это будет максимальным значением «тепла» для тепловой карты.
- Для каждого уникального местоположения в списке событий рисуем изображение круга по координатам события. Рисуем изображение с коэффициентом непрозрачности, рассчитываемым по формуле:
(количество событий в этом месте)/(максимальное значение "тепла") * 100%Используем умножающую модель переноса (multiply transfer mode: src * dst) для смешивания точек нарисованных кругов друг с другом.
Накладываем полученное изображение на прозрачную канву (canvas).
Когда процесс будет завершён мы получим изображение с большим количеством тёмных пятен с изменяющейся интенсивностью черного цвета. Это — промежуточное изображение, которое будет подвергаться обработке на следующем шаге.
- Берём изображение полученное на предыдущем шаге и добавляем в него цвет. Берём уровень прозрачности (alpha) для каждой точки и на его основе вычисляем Y-координату в «цветном словаре», построенном на шаге 2 для того, чтобы рассчитать цвет для обрабатываемой точки.
- Берём полученное изображение и накладываем его поверх изображения игрового уровня. Места возникновения событий будут показаны как цветные области, где увеличивающаяся интенсивность цвета показывает области, в которых происходило больше событий.
Низ изображения пусть будет белым или красным, или любого цвета, который вы выберете как обозначение наиболее «горячего» места на тепловой карте. Верх изображения должен быть чёрным с несколькими цветами в промежутке. Это изображение будет использоваться как «словарь» для формирования графического отчёта по статистическим данным позднее.
При выполнении всех этих шагов убедитесь в том, что вы поддерживаете цветовое пространство в диапазоне 8-бит на канал (в частности при расчёте непрозрачности на шаге 5).
Или рассмотрите использование формата, который поддерживает данные с плавающей точкой для формирования изображений.
Можно легко выявить ошибки точности (precision bugs), которые будут заметны при большом количестве событий, так что вклад одного события в общую картину будет менее одного процента.
Инструменты вроде ImageMagick могут помочь вам решить эту задачу.
| ||||||||||||||||||||||
Мы полагаемся на вашу поддержку, чтобы поддерживать наши данные в актуальном состоянии.The Art of Game World Maps
подробно описал свой подход к созданию и планированию миров видеоигр.
Введение
Мои художественные таланты преследовали меня в старшей школе и привели меня к получению степени изящных искусств. Стремление исследовать другие формы самовыражения привело меня к получению степени в области графического дизайна и кино. Затем, когда компьютерная графика стала более распространенным явлением, я в конце концов получил степень в области электронных искусств в Колледже искусств Атланты в 1919 году.97.
В то время я стажировался в CRPG у Д.В. Брэдли из Wizardry. Этот проект позволил мне попробовать себя в различных областях, таких как моделирование и анимация. За эти годы я узнал о Photoshop больше, чем когда-либо в школе! Затем я обнаружил склонность к дизайну уровней. Он использовал весь мой предыдущий опыт с искусством, кино, программированием и даже сборкой Lego в детстве. Это стало моей карьерой на следующие 20 лет.
Пожив в более чем дюжине мест в Соединенных Штатах, вы научитесь видеть, что уникально, а что одинаково, независимо от того, в каком городе или в каком социальном круге вы находитесь.
Добавьте к этому разнообразие степеней, которые я изучил, и у вас есть много перспектив, которые вы можете применить к игровым мирам и нелинейному опыту.
Однако быть гейм-дизайнером рискованно. Пока вы изучаете, как искусство, игровой процесс, код и технологии должны работать вместе, это становится специализированным набором навыков. Художники и программисты имеют больше возможностей для участия и прекращения разработки игр. Дизайнер женат на нем.
Мне посчастливилось прыгать в большие и глубокие миры для разных творческих команд. Моя цель как мирового дизайнера — заставить игроков забыть, что они находятся на задании или задании. Попросите их ткнуть вымышленный мир, чтобы увидеть, как он ткнется в ответ. Пригласите их исследовать следующий угол или вершину холма в поисках новых достопримечательностей и чудес.
Карты мира
Когда вы путешествуете по миру, есть гораздо лучшие способы, чем смотреть на карту. Играя в «игру с мини-картой», постоянно глядя на свою GPS-карту, вы отвлекаетесь от того, что захватывает в окружающем вас мире! Лучший тип игры — это тот, который не дает вам обрывки карты в качестве центра важной информации.
Сказав это, карты служат большей цели и умственному зуду. Обычно они включают в себя тайну неизвестного и предвкушение места назначения. Пунктирная линия к зарытому кладу! Это также изображение закладок и заметок для размышлений. Вы можете положить его в карман и поделиться им с другими, указывая, где произошло все хорошее, плохое и ужасное. Это может быть вашим трофеем воспоминаний, свисающих со стены.
Я всегда начинаю новый игровой мир, нанося на карту горячие точки и пути к ним и от них. Что будет отличать каждый регион или царство друг от друга? Это быстро превращается в 3D-блокаут, чтобы доказать, что у него есть заманчивые вертикальные и горизонтальные складки.
Когда я работал над сиквелом «Страдания», мне дали линейный маршрут по каждому сюжетному и игровому этапу. Жажда превратить его в потенциальную среду-песочницу взяла верх надо мной. В итоге я свернул линейный маршрут вокруг себя, создав петлю. Это также позволило мне позволить игрокам заглянуть в будущие места и оглянуться на прошлые места.
В финальной игре эта петля никогда не использовалась, но она помогла проявить мои инстинкты песочницы.
Насколько важен реализм?
Миры не должны быть скованы реальностью. Однако чем больше он отклоняется от реализма, тем более его диковинные правила должны быть последовательными и иметь смысл. В начале проекта я подталкиваю команду к правдоподобности на 80-90%. По мере продвижения проекта, когда теперь есть прочная правдоподобная основа, позвольте добавить больше экзотических элементов. К концу вы можете отказаться от полуреализма, если это означает, что игра замораживается, и игроки сидят на своем месте. Напомните им, что это не реальный мир, это то, чем он должен быть!
Это одна из причин, по которой я с нетерпением жду DLC… это шанс собрать опытную команду и опробовать безумные идеи, которые изначально не рассматривались. В этот момент игроки становятся фанатами и могут оценить повороты или даже радикальные изменения, чтобы по-новому взглянуть на мир.
Я стараюсь иметь 2-3 изменения состояния мира на протяжении всей основной игры в открытом мире.
Это встряхивает то, как игроки перемещаются по уже знакомым районам и регионам. Что еще более важно, я пытаюсь сделать те изменения, которые вносит игрок, а не сюжетный ход. Тогда им всегда можно будет напомнить, что их действия и сила влияют на мир.
Вы должны бороться за них, поскольку проекты меняются и подвергаются рефакторингу, чтобы уложиться в сроки производства.
В Mafia 3 мы приложили много усилий, чтобы построить северный центр города под линией воды в реке. Я хотел затопить эту область и передвигаться по ней на лодках позже по сюжету. Представьте, что вы мчитесь между двумя небоскребами на фан-лодке, как в Венеции после урагана!
В миссии на другом конце города игроки взорвали грузовое судно на верфи. Первоначальный замысел заключался в том, чтобы этот удар и наполовину погружение в док оставляли шрам на городе. Сюжетные и производственные изменения, к сожалению, убрали обе эти идеи из финальной версии игры.
Чем диковиннее мир, тем более непредубежденные игроки будут принимать то, что он есть.
Чем ближе мир к реальности, тем тщательнее он будет изучаться. Mafia 3 должна была ощущаться, как будто она существовала, если вы путешествовали туда сегодня. Команда приложила много усилий, постоянно проверяя реальность этого. Чешский экипаж был великолепен в этом качестве.
Mafia 3 также дала людям возможность узнать, каково было жить в то время. Тонна реальной истории повлияла на то, каким стал Нью-Бордо. У меня было желание представить все эти знания в виде «Туристических мест», которые игрок мог бы прочитать, встретив их, как газетную Википедию. Игроки могли бы закончить игру с большим количеством реальных знаний, исследуя город. Однако время истекло, и это тоже было вырезано. Ближе всего к этому мы подошли к маркетинговой команде 2K Games, выпустившей социальные сети New Bordeaux.
Я был взволнован, увидев, что Ubisoft сделала что-то похожее на Assassin’s Creed Origins «Режим открытия», чтобы исследовать Египет!
Испытания
Для тех, кто еще не делал игры с открытым миром, это может стать настоящим откровением.
В отличие от линейной игры, вы строите локации, которые вы ожидаете или надеетесь использовать, но в конечном итоге они могут оказаться не такими. Однако, поскольку это среда песочницы, чрезвычайно сложно просто вырезать среднюю часть, потому что никто не использует это пространство и не вклинивает что-то в существующее пространство.
В Mafia 3 штаб-квартира Донована в мотеле изначально располагалась к северу от Фриско Филдс. На полпути разработки Делрей-Холлоу стал стартовой площадкой для первой сюжетной линии игрока после встречи с Донованом. Чтобы было легче увидеть Донована, мы перенесли его оперативную базу прямо в центр Делрей-Холлоу. Эти уникальные активы вызвали волновой эффект и закрыли другие запланированные места, а также натолкнулись на убежище Общинной церкви южнее. Это была непростая задача с таким количеством деталей и технических ссылок, которые уже были наложены сверху. Поговорите со всеми в команде, чтобы свести к минимуму радикальные изменения позже.
Еще одним препятствием было непонимание того, сколько времени потребуется на создание и управление промежутками между квестами.
Изначально мы рассчитали четверть времени, чтобы построить район с половиной населения. На самом деле это было намного сложнее и для игрового процесса. Хотя эти промежуточные пространства были менее важными или создавались вручную, как линейные квесты, они все же должны были поддерживать компетентный бой. Когда игрок входит в переулок пятью разными способами с любым типом оружия и делает бой захватывающим, было трудно сбалансировать!
Запоминающийся мир включает в себя больше, чем привлекательные физические пространства. Он должен работать в гармонии с геймплеем и сюжетом. Вы должны знать, когда места можно использовать и сколько типов геймплея будет использовать это пространство. Это только для перестрелок или по нему придется проехать на машине? Базовый цикл игры в песочнице включает в себя корректировку возможностей игроков с учетом того, что произошло недавно и что должно произойти в ближайшее время.
Создание большого городского города намного сложнее, чем создание большого ландшафта.
Заполнители в дикой природе могут быть случайными и органическими. Вы можете обнаружить множество забавных топографических троп и достопримечательностей с помощью рандомизации. Город, однако… все построено, все есть не просто так, даже если это здание-наполнитель.
Преимущество Mafia 3 в том, что она основана на реальном городе. Все уже знали, что такое современный американский город. Если кто-то не был уверен, какие детали должны появиться на заднем дворе, он мог легко найти сотни примеров изображений в Google. Современный базовый визуальный язык уже существует для таких вещей, как дорожные знаки.
Создание вымышленного диковинного города не имеет ни одного из этих преимуществ. Все должно быть создано с нуля и иметь смысл внутри себя. Вы должны создать историю того, почему что-то было сделано определенным образом, чтобы сделать это правдоподобным. Без этого ваш мир начинает казаться игрой, а не местом. Вся команда должна понимать основу для представления того, что происходит между концепт-артом и основными квестами.
Невозможно найти в Google уникальный стиль и тему команды.
Построение огромного мира
Если у вас настроены процедурные системы, это лучший и самый быстрый способ запустить десятки масштабных макетов. Такие вещи, как City Engine от ESRI, требуют времени для настройки, в зависимости от того, насколько далеко от реальных городов вы находитесь. Если вы создаете место, которого раньше никогда не существовало, вам нужно сначала выяснить, как выглядит базовый городской квартал. Это хоть блок? Только после того, как вы определите, насколько большое или маленькое среднее здание, какой ширины должна быть улица, какими путями игрок будет пересекать это пространство, вы можете затем умножить это, чтобы набросать более крупный город и создать из этого разнообразие?
Сколько городов-песочниц существует сегодня, в которых не воссозданы исторические города, современные мегаполисы или подражание тому, что было в научно-фантастических фильмах и играх? Покажите мне большой полностью реализованный, правдоподобный фантастический или диковинный город, в который люди хотят возвращаться снова и снова, и вы нашли место, построенное множеством преданных своему делу и увлеченных людей, которые не могут просто смотреть на книги по истории или на улицу.
окно. Они хотят, чтобы их мир казался живым, когда вас в нем нет.
При создании нового мира на основе уже существующего места узнайте, что люди помнят об этом месте. Используйте их в качестве палаток для ориентиров и маршрутов. Это сожмет области, которые не будут интересны людям, помогая вам сжать ваш игровой мир во что-то управляемое.
Спланируйте повседневную деятельность города. Это включает в себя то, как разные классы и культуры смешиваются в городе днем и ночью. Так можно закрепить разнообразие и создать конфликтный фон для городской жизни.
Вначале мой общий подход заключается в тесном сотрудничестве с командой повествования и квестов, чтобы понять, что они хотят, чтобы город сделал для них… основные локации и способы, которыми игрок будет взаимодействовать с игрой. Кроме того, поймите или, по крайней мере, предвидите, какие технические особенности или ограничения будут у команды. Построение геометрии города — это только половина того, что в него входит.
Есть звуковые секторы, свет, количество украшений, разнообразие людей, типы транспортных средств и многое другое, что откусывает от пирога производительности.
После того, как вы учтете все эти пожелания и ограничения, создайте простую трехмерную сетку города. После большого количества быстрых итераций попросите Лидов и Директоров подписать масштабы мира. Базовый мир должен быть проверен, прежде чем основные квесты сделают предположения о нем. Убедитесь, что между уникальными локациями достаточно места, чтобы они могли транслироваться без сбоев. Это может повлиять на то, что происходит до и после квеста. Это также может помочь сохранить локальную тему, давая команде то, на что можно опереться и оттолкнуться.
Теперь можно приступать к созданию настоящей игры. Люди могут начать сосредотачиваться на регионах и интегрировать свои собственные идеи поверх этой грубой схемы мира. (Я мог бы написать целую главу о производстве зданий в мире.)
Между прочим, я очень рад увидеть The Sinking City от Frogware.
Они нашли время, чтобы установить технологию и правила для создания своего сверхъестественного города 1920-х годов.
Использование геоконтента
Я видел, как Карты Google разблокировали свой контент для игрового контента! Это была одна из первых вещей, о которых я подумал много лет назад, когда Google Планета Земля позволяла путешествовать по 3D-городам. Я рад видеть, что люди будут делать!
С другой стороны, это зависит от того, какой тип игры будет использовать буквальный макет, какой бы он ни был. Есть причина, по которой Нью-Бордо в Mafia 3 не является точной копией Нового Орлеана. В реальном мире много неинтересного пространства. Например, мне не терпелось побродить по улицам LA Noire только для того, чтобы понять, что это слишком буквально для Лос-Анджелеса и не имеет содержания, поддерживающего что-либо, кроме основной сюжетной линии.
Если мир не является буквально фоном для геймплея, как авиасимулятор или гигантский крушитель монстров, копии городов никогда не будут такими же хорошими, как то, что создано вручную.
Небольшие предметы в игровом мире, такие как мебель для квартиры, могут быть автоматизированы и рандомизированы в наборе правил, чтобы сократить время, необходимое для их создания, и наполнить их взаимодействием. Это макет макроса и темп одной арены и точки интереса, которые необходимо оценивать человеческим глазом, тестировать и настраивать снова и снова, чтобы получить отличный игровой опыт.
Это начальные этапы проекта, когда автоматизированный или скопированный контент — это фантастика! Использование таких инструментов, как Google Maps, — отличный способ просмотреть несколько черновиков, когда вы думаете, что знаете, чего хотите, только для того, чтобы найти что-то лучшее в следующем.
Достопримечательности
Это столбы для палаток, которые влияют на местные темы, привлекают игроков и помогают распространять и сбалансировать мир разнообразием. На самом деле это одна из самых простых вещей, которую можно сделать на раннем этапе. Вы делаете это на этапах составления проекта, о которых я упоминал ранее.
Mafia 3 должна была сбалансировать относительное расположение известных ориентиров с уникальными квестовыми.
Частью этапа разработки является построение правильных путей и маршрутов от одного ориентира к другому. В некотором смысле, вы можете считать основные дороги и ориентиры основой хорошего мира, прежде чем какие-либо причудливые детали будут добавлены.
Город в Mafia 3 претерпел 3 основных изменения, за которыми последовало несколько десятков микропланировок.
Истории
Миру нужна история. Ему нужна история. То, что произошло до того, как история началась, может сильно повлиять и вдохновить то, что происходит во время истории в мире. Мировая история — это то, на что команда может опереться, когда им нужно заполнить пробелы.
При разработке истории найдите способы показать ее игроку, показав, как слои были построены поверх других слоев или оставлены без внимания с течением времени. Примером этого в Mafia 3 является небольшой речной остров посреди города.
Несмотря на то, что он находится между популярными районами Френч-Уорд и Саутдаунс, жители теперь не замечают это место. Когда-то это был активный узел доставки и упаковки, прежде чем гавань Тикфоу стала современным портом. Здания теперь рушатся в тени протянувшегося над ними современного шоссе.
Как и в любой игре, в которой игрок перемещается из одной локации в другую, она может раскрыть невысказанную историю. Кто проложил этот путь? Для чего эта боковая тропа? Даже если вы доберетесь до хижины, и в ней никто не живет, кто это сделал и почему они ушли? Почти у каждой хижины в Mafia 3 была какая-то предыстория.
В пассивном повествовании более сложной задачей является сохранение разнообразия. Не позволяйте каждой области быть всем. Отсутствие чего-то, что вы часто видели в предыдущей области, может подразумевать что-то о вашей текущей области.
В Нью-Бордо есть бедный район на юго-западе Фриско-Филдс под названием Хейвен-Уорд. Именно здесь когда-то жили рабы, когда Фриско-Филдс был плантацией, а затем превратился в пригород среднего класса Hillcrest Estates.
Один из членов команды пытался сделать этот бедствующий район привлекательным, посадив вдоль дороги красивые кусты и цветы. Мне пришлось напомнить им, что Хейвен Уорд пытается найти свою идентичность в округе, который не считает, что афроамериканцы заслуживают равенства. Пусть район отражает их суровую ситуацию.
Делрей Холлоу, напротив, был еще одним афроамериканским сообществом, которое смогло обрести гордость, самобытность и уверенность в себе. Отчасти поэтому он был так далеко от центра Нью-Бордо, вдали от тени настроений белых южан 1960-х годов.
Совет
Трудно понять, насколько большим должен быть мир. Создавайте ожидаемый контент и продвигайте игрока из точки А в точку Б. Четкой формулы не существует, и вы не хотите привязываться к контенту, который никогда не будет использован. Что-то слишком привлекательное, лишенное содержания, завлечет игроков только для того, чтобы разочароваться в том, что там ничего нет — никаких наград за потраченное время.
В Mafia 3 было много пробелов, которые никогда не использовались.
Первоначальная идея заключалась в том, чтобы иметь 3 убежища для каждого района. Это было встроено в каждый район, чтобы найти подходящее повествование, чтобы оно соответствовало известному зданию и достаточному пространству вокруг него для потоковой передачи. Дизайн сместился к двум убежищам, а другое отложили для DLC. Однако его пространство в каждом районе по-прежнему необходимо было поддерживать на протяжении всего развития. Ближе к концу проекта от планов укрытий из DLC отказались в пользу нового контента сюжетной арки. Некоторые места были перепрофилированы для нового DLC, а другие остались нетронутыми.
С другой стороны, вы не хотите быть слишком маленьким, иначе вы столкнетесь с проблемами производительности позже, когда квесты и уникальный контент столкнутся друг с другом. Что-то должно быть вырезано или нужно потратить много времени, разрывая мир на части, чтобы сделать больше пространства между ними.
Так что это всегда игра, если у вас будет слишком много или слишком мало.