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

 

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


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


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


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


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


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

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


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


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


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

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


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


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


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


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


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

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


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


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

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


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


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


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


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


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


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


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


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

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


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


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


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

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


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


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


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


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


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


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

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


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

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


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


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


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


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


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

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


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


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

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


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

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


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


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

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


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


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


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

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


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

Комментарии

Популярные сообщения