Методика разработки игр на Unity

Методика разработки игр в Unity

Когда первый раз начинаешь делать игры на Unity, то не понимаешь с какого конца приступать.

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

Начинаешь с одной сцены — где тестируется ваша корневая механика игры.

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

И не надо боятся делать всё в методике «graybox», когда у тебя лишь треугольники или пирамидки на твоём уровне.

Это даже хорошо, когда ты просто берешь примитивы и делаешь игру.

Ничего не отвлекает от общего процесса игры и разработки её.

Некоторые разработчики даже остаются на минимализме и вполне успешные: Thomas Was Alone, Mini Metro и похожие.

И важный момент — когда ты творишь, даже используя «арт программиста» — то тебя ничто не останавливает.

В момент создания механики или уровня нельзя отвлекаться и раздражаться — плохо скажется на игре.

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

С художниками успеете поработать позже — на этапе полировки.

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

Создаём объект игрока — просто кидаем коробку (или спрайт с квадратом) на уровень и начинаем думать — какое поведение нам надо.

Для каждого поведения и возможности надо создать компоненты: жизнь, передвижение, сенсоры врагов и столкновения с окружением, управляющий модуль (центральный мозг персонажа).

Причём лучше по порядку — от простого: движение и столкновение, а также управляющий модуль.

После этого, а также настроив параметры (благо Unity позволяет играть с параметрами во время теста, а потом сбрасывает при возвращении к нормальной работе) — можно приступать к созданию prefab-а для персонажа.

Prefab — это способ Unity создавать экземпляры вашего объекта динамически, каждый раз не настраивая и обходясь без компоновки.

Расположили и просто играете с ним.

Так как игрок — центральный персонаж, то и уровень для теста у него уже есть.

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

После тестирования объекта (или механики геймплея) можно начать собирать уровень.

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

И пробуете пройти этот уровень от начала и до конца. И выставляете рейтинг.

После можно отдавать на тестирование вашим друзьям или профессиональным тестировщикам.

Как уровень будет готов, его можно положить в папку «К обработке»

В этой папке будут храниться уровни для полировки.

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

Дизайнер уровней тут уже вовсю работает с художником (даже если вы всё сами делаете — это всё равно две разные направленности и их надо разделять)

И вот, когда у вас уже набралось уровней на эпизод, можно их располагать.

Кто делает историю — то в хронологическом порядке выставляете.

Кто просто уровни — то сортируйте по сложности.

Но не забывайте про кривую вовлечённости.

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

Для настройки удобнее всего использовать json или ScriptableObject — тогда вы сможете настраивать геймплей без переработки сцен.

А это очень удобно, когда у вас один префаб на десятке сцен в десятках вариаций.

Последнее время Unity позволяет использовать композицию prefab-ов. И этим стоит пользоваться — поскольку так вы сможете управиться с работой малой командой или один.

Постоянная переработка уровней — основной убийца мотивации. Ты много работаешь, а отдачи нет, а то и сломать можешь.

Поэтому ограничивайте количество итераций.

И по бюджету времени (и денег) это тоже важно — знать когда остановиться (достаточно хорошо уже хорошо).

Перфекционизм до хорошего не доведёт.

И главное — как говорит Джон Блоу: «Не пытайтесь быть как большие компании»

Ваш путь уникален, и копировать коллектив в 10-100 человек, просто надорваться.

Есть поговорка: «Широко шагать — штаны порвать»

Лучше сделать меньше, но в лучшем качестве, чем растягивать резину скуки на много часов.

Для игры отзыв «скучно» — это приговор.

Игры должны развлекать и увлекать. Учить и направлять.

И скука для игрока — это смерть для игры.

Лучше начните другой проект, как этот сделаете.

Хотя некоторые предпочитают вести сразу несколько проектов.

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

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

Через полгода уже делать будешь «через нехочу», что скажется на качестве проекта.

Отсутствие энтузиазма сразу видно.

Когда ты делишься наработками с людьми — они это видят.

А репутация — это пока единственное, что есть у молодой студии (или инди-разработчика игр).

По совету МакМиллена: «Делать надо то, к чему душа лежит. Самые интересные получались именно на взлёте энтузиазма»

Так что заканчивать надо, но при этом поддерживать огонь в душе тоже нужно.

И этот баланс трудно достичь.

Но к нему можно и нужно стремиться.