Для гейм-джемов или бюджетных инди-разработок.
Когда в команде мало не только рук, но и времени, обычно не хватает ресурсов на масштабные уровни с большим количеством локаций, механик и контента. Но когда вы делаете бродилку, адвенчуру или нарративную игру на 10-30 минут прохождения без динамичного геймплея, нужно как-то удерживать внимание и интерес игрока и не утомлять его передвижением по однообразным локациям.
В этом материале я хочу рассказать, как сделать долгий и насыщенный уровень для короткой бюджетной игры на основе однообразных локаций, небольшого набора спрайтов и нескольких механик. Будет полезно начинающим инди-разработчикам и левел-дизайнерам.
Любой уровень начинается с идеи. На первом этапе она формулируется буквально в паре предложений, а уже потом разворачивается в описание локаций, механик, настроения, конкретных объектов и точек интереса игрока. В нашем случае идея выглядела примерно так:
У нас будет уровень-склад. Мы хотим, чтобы игрок провёл там примерно треть времени. Это должно быть что-то вроде лабиринта, и нужна активная механика, чтобы игрок не заскучал.
Дальше идею «долгий уровень-лабиринт» (или подставьте здесь что-то своё) нужно расширить до полноценной концепции. Здесь вам поможет сбор референсов. Это очень важный этап. Практически все идеи, которые приходят нам в голову, уже воплощены другими разработчиками или существуют в реальности — удачными примерами стоит вдохновиться, а из неудачных понять, как делать не нужно, или как их улучшить и адаптировать под свою игру.
Игры такого же или схожих жанров и игры с похожими уровнями. Например, если вы делаете платформер, стоит исследовать платформеры — поиграть, изучить обзоры и прохождения, понять логику и устройство уровней. А если вы делаете уровень в лесу — посмотреть, как леса реализованы в других играх.
Фильмы, сериалы, аниме. Там часто можно встретить проработанные локации, природные ландшафты, необычные архитектурные решения или другие объекты, которые вдохновят вас на новые идеи.
Города, природа, архитектура и интерьеры из реальной жизни. Например, если у вас масштабный уровень в городе, максимально простое решение — взять за основу реально существующий город и адаптировать локации под себя. Если делаете уровень-отель — будет полезно изучить архитектуру и интерьеры реальных отелей.
Но у вас не всегда будет достаточно времени на сбор референсов. Например, на гейм-джемах, когда за 72 часа нужно придумать, реализовать и отполишить игру. Поэтому важно развивать насмотренность — играть в игры, смотреть фильмы, много читать, вдохновляться природой, архитектурой и искусством. Это будет вашей внутренней копилкой, из которой в нужный момент вы сможете достать механику, сеттинг и локацию или переработать что-то уже существующее в новую самобытную идею.
При создании концепции уровня-склада, который должен был быть «чем-то вроде лабиринта», я не стала изобретать велосипед и достала из головы концепцию классических данжей из «рогаликов» и RPG. Здесь мне и пригодилась насмотренность — если бы я не знала, как строятся подземелья в таких играх, я бы вряд ли придумала что-то похожее с нуля.
Дальше начался процесс сбора референсов. Я сразу вспомнила серию The Legend of Zelda, знаменитую своими подземельями, и отправилась на YouTube. Там я нашла канал с рубрикой очень упорного и мотивированного левел-дизайнера (рубрика Boss Keys), который поиграл, кажется, практически во все игры серии и подробно разобрал логику устройства уровней с графиками и схемами.
Я решила, что адаптация данжа — лучшее решение для нашего склада. Постоянное передвижение по однообразным локациям в поисках ключей даст ощущение лабиринта и увеличит время прохождения уровня. Механика битвы (мы её заменили на взломы — это лучше укладывалось в наш сеттинг и бюджет) не даст заскучать. Привязка к сюжету и нарративные детали в каждой локации превратят путешествие по складу в осмысленный опыт и избавят от ощущения бессмысленного гринда. Так идея развернулась в полноценную концепцию.
Когда есть более-менее цельная и понятная концепция уровня, можно приступать к бумажному прототипированию. Бумажный прототип — это уровень, нарисованный на бумаге. Например, если у вас уровень в лесу, вашим бумажным прототипом будет схема этого леса в масштабе листа (например) А4.
По сути, это примитивная схема, которая показывает, что игрок начинает в точке А, проходит через точки B, C, D и завершает уровень в точке Е. При этом через точки он может проходить напрямую, зигзагом или постоянно возвращаясь туда-обратно — все зависит от вашей задумки. На этом этапе ваш лес будет выглядеть как прямоугольник с крестиками, стрелочками, линиями и т.д. То есть, вместо того, чтобы рисовать лесную чащу, сторожку или другой важный объект, вы обозначаете их фигурами и подписываете словами, что здесь у вас деревья, а справа от них стоит дом.
Что важно отразить на бумажном прототипе:
Начало и конец уровня. Где/в какой момент начинается уровень? Где он заканчивается, что нужно сделать игроку, чтобы пройти уровень и что ждет его в финале? В нашем случае началом уровня была первая комната склада-подвала, концом — восьмая комната. Чтобы пройти уровень, игроку нужно было найти ключ от двери восьмой комнаты.
Зоны. В коротких играх обычно 2-4 небольших локации. Но даже если и так, эта локация может состоять из нескольких зон/экранов. Такие зоны нужно разметить на схеме с учетом их приблизительного масштаба относительно друг друга. В нашем случае был один склад-подвал, разделенный на 8 зон-комнат.
Точки интереса. С какими объектами/персонажами и как игроку нужно взаимодействовать, чтобы пройти уровень? Какие задачи нужно выполнить? В каких механиках выражается это взаимодействие? В каких зонах локации/локациях оно происходит? В нашем случае точками взаимодействия были механики взломов, текстовых квестов и открытия дверей ключами, привязанные к конкретным объектам в каждой комнате подвала.
Путь игрока. Как игрок дойдет до конца уровня? Это один линейный путь или есть несколько вариантов, которые в итоге все равно приведут к финальной точке? Игрок посетит локации/зоны уровня последовательно или будет постоянно перемещаться между ними, выполняя задачи? В нашем случае уровень был линейный, но игрок постоянно должен был перемещаться между комнатами подвала.
В итоге у вас получится примерно такая схема.
Пример схемы уровня на бумаге
Но не сразу, потому что невозможно сделать все идеально с первого раза. В этом прелесть бумажного прототипа — можно быстро и дёшево менять количество и расположение объектов, зон и ключевых точек интереса.
На этом этапе главное не бояться переделывать что-то и убирать ненужное — если что-то кажется неподходящим уже на этапе бумажного прототипа, смело от этого избавляйтесь. Фичекат — важная штука, особенно, когда вам нужно сделать игру за 72 часа. Гораздо проще набросать новую схему на бумаге за 10-20 минут, чем тратить часы работы художника или программиста на ненужный объект или механику. Чтобы проверить нужность, спросите себя, какую задачу выполняют этот объект или механика, зачем они нужны на уровне? Если ответ «просто потому что» — убирайте и не жалейте.
Когда бумажный прототип дошел до своей финальной версии, можно переносить его в цифру. Я для этого использую сервис диаграм от Гугла. Он синхронизируется с диском, таблицами, документами и презентациями, схемы можно вставлять в концепт-документ в один клик и там же вносить изменения — это очень экономит время.
Схема в цифре отличается от бумажного прототипа. На ней уже можно и нужно разметить масштаб объектов и локации относительно игрока, разместить нарративные элементы и второстепенные детали.
Пример схемы уровня в цифре
Но перед тем, как делать схему в программе, советую написать концепт-документ уровня. На гейм-джемах этот этап обычно пропускают, потому что на него нет времени, но в остальных случаях он нужен, даже для маленькой инди-игры на 20-30 минут.
Концепт-документ — это инструмент коммуникации между левел-дизайнером и остальными членами команды. Никто не знает, что у вас в голове, и не увидит схему уровня так, как видите ее вы — художникам, программистам и всем остальным нужны развернутые описания и ТЗ.
Общее описание уровня. Действие происходит там-то, игрок начинает в точке Х, чтобы пройти уровень, ему нужно сделать А, В и С.
Список зон уровня с подробным визуальным описанием каждой. Здесь понадобятся референсы для художника, чтобы показать ему задуманную вами атмосферу и настроение. Сюда же — пара слов о темпе и настроении уровня и эмоциях, которые игрок должен испытывать при прохождении.
Список объектов в каждой локации или зоне с референсами для художника. Если игрок может каким-то образом менять эти объекты или взаимодействовать с ними, это тоже нужно описать.
Механики уровня с подробным описанием и референсами.
Нарративные элементы. Если на уровне присутствуют какие-то важные для сюжета объекты или взаимодействия, их тоже нужно описать с референсами.
Последний этап перед финишной прямой — прототипирование уровня в движке или сборка грейбокса. Грейбокс — это уровень, собранный в движке «на кубах». То есть, вместо реальных объектов там будут геометрические фигуры: например, кубы (или квадраты, если речь идет о 2D) вместо домов и машин, круглые столбы вместо деревьев и т.д. При этом все фигуры в нужных масштабах, на них даже могут быть натянуты какие-то простые одноцветные текстуры, чтобы создать ощущение полноценного прохождения.
Пример грейбокса уровня из Uncharted
Грейбокс нужен, чтобы понять, как проходится уровень, увидеть слабые места и ненужные элементы.
Что важно здесь:
Не ждите запрототипированных механик. Для грейбокса достаточно настроенного движения персонажа и камеры. Даже без взаимодействия с объектами можно понять, что в каких-то местах передвигаться по уровню скучно, сложно, слишком долго, или увидеть другие слабые места.
Обращайте внимание на каждую деталь. Все ли объекты действительно нужны на этом уровне (и лучше понять это, пока художник не нарисовал спрайты)? Не выглядит ли локация слишком пустой или, наоборот, загроможденной? Понятен ли путь игрока?
Когда будут готовы механики, можно переходить к более глубоким вещам. Достаточно ли на уровне взаимодействий? Создается ли нужный темп? Атмосфера? Сколько времени занимает прохождение уровня?
Откалибруйте сложность. Здесь важно помнить главное правило — если разработчикам игры сложно, значит, игрокам будет еще сложнее. Поэтому лучше упрощать, чем усложнять.
Если есть время — тестируйте. На джемах обычно нет времени на тесты, но если есть пара свободных часов — стоит потратить их на тест.
Также очень важно, чтобы грейбокс был понятен программисту, художнику и всем остальным членам команды разработки. Размечайте объекты цветами: например, серым — нейтральные, зелёным — те, с которыми игрок взаимодействует, красным — что-то закрытое или недоступное до выполнения определённых условий. Так ваши коллеги смогут сориентироваться в куче геометрических фигур и понять ключевые моменты уровня. Если есть время, можно сделать скриншоты, подписать на них основные объекты и разметить путь игрока (это, кстати, потом пригодится для портфолио).
Вместо саммари всего вышенаписанного, я просто посоветую вам освоить какой-нибудь движок и идти участвовать в гейм-джемах. Дизайнеру уровней важно набивать руку. Сначала у вас будет получаться что-то странное и непонятное, но с каждым разом ваши уровни будут становиться все сложнее, насыщеннее и лучше. Главное — практиковаться, развивать насмотренность и много играть.