Методика разработки игр на Unity
Методика разработки игр в Unity
Когда первый раз приступаешь к Unity, то не понимаешь с какого конца приступать.
После некоторого времени и множества прочитанных книг и форумов начинаешь понимать методику разработки.
Начинаешь с одной сцены - где тестируется ваша корневая механика игры.
Если это платформер - то один длинный уровень с минимальным набором механик (прыжок, упасть и разбиться и простой враг).
И не надо боятся делать всё в методике «graybox», когда у тебя лишь треугольники или пирамидки на твоём уровне.
Это даже хорошо, когда ты просто берешь примитивы и делаешь игру.
Ничего не отвлекает от общего процесса игры и разработки её.
Некоторые разработчики даже остаются на минимализме и вполне успешные: Thomas Was Alone, Mini Metro и похожие.
И важный момент - когда ты творишь, даже используя «арт программиста» - то тебя ничто не останавливает.
В момент создания механики или уровня нельзя отвлекаться и раздражаться - плохо скажется на игре.
Поэтому рисуйте или используйте готовые шаблоны и создавайте такой геймплей как вам нужно.
С художниками успеете поработать позже - на этапе полировки.
После того, как вы определились с уровнем, и накидали базовых коллайдеров, можно переходить к созданию механик.
Создаём объект игрока - просто кидаем коробку (или спрайт с квадратом) на уровень и начинаем думать - какое поведение нам надо.
Для каждого поведения и возможности надо создать компоненты: жизнь, передвижение, сенсоры врагов и столкновения с окружением, управляющий модуль (центральный мозг персонажа).
Причём лучше по порядку - от простого: движение и столкновение, а также управляющий модуль.
После этого, а также настроив параметры (благо Unity позволяет играть с параметрами во время теста, а потом сбрасывает при возвращении к нормальной работе) - можно приступать к созданию prefab-а для персонажа.
Prefab - это способ Unity создавать экземпляры вашего объекта динамически, каждый раз не настраивая и обходясь без компоновки.
Расположили и просто играете с ним.
Так как игрок - центральный персонаж, то и уровень для теста у него уже есть.
Для мелких механик, врагов и опасностей надо собирать отдельный тестовый уровень, чтобы проверить как они работают по отдельности, а также в совокупности (чтобы можно было использовать комплексы механик для разнообразия геймплея)
После тестирования объекта (или механики геймплея) можно начать собирать уровень.
Это уже сильно проще - надо собрать базовый уровень и накидать туда различных врагов, препятствий, настроить периодичность волн (если у вас они присутствуют - защита башнями или бит-ем-апы часто используют волны)
И пробуете пройти этот уровень от начала и до конца. И выставляете рейтинг.
После можно отдавать на тестирование вашим друзьям или профессиональным тестировщикам.
Как уровень будет готов, его можно положить в папку «К обработке»
В этой папке будут храниться уровни для полировки.
Из них, вынимаешь уже когда почти все уровни готовы и начинаешь вставлять графику, и заполнять деталями.
Дизайнер уровней тут уже вовсю работает с художником (даже если вы всё сами делаете - это всё равно две разные направленности и их надо разделять)
И вот, когда у вас уже набралось уровней на эпизод, можно их располагать.
Кто делает историю - то в хронологическом порядке выставляете.
Кто просто уровни - то сортируйте по сложности.
Но не забывайте про кривую вовлечённости.
Она должна быть в виде возрастающей кривой с падением после климакса, чтобы игрок чувствовал, что он преодолевает проблемы, а потом выходит победителем из главной схватки.
Для настройки удобнее всего использовать json или ScriptableObject - тогда вы сможете настраивать геймплей без переработки сцен.
А это очень удобно, когда у вас один префаб на десятке сцен в десятках вариаций.
Последнее время Unity позволяет использовать композицию prefab-ов. И этим стоит пользоваться - поскольку так вы сможете управиться с работой малой командой или один.
Постоянная переработка уровней - основной убийца мотивации. Ты много работаешь, а отдачи нет, а то и сломать можешь.
Поэтому ограничивайте количество итераций.
И по бюджету времени (и денег) это тоже важно - знать когда остановиться (достаточно хорошо уже хорошо).
Перфекционизм до хорошего не доведёт.
И главное - как говорит Джон Блоу: «Не пытайтесь быть как большие компании»
Ваш путь уникален, и копировать коллектив в 10-100 человек, просто надорваться.
Есть поговорка: «Широко шагать - штаны порвать»
Лучше сделать меньше, но в лучшем качестве, чем растягивать резину скуки на много часов.
Для игры отзыв «скучно» - это приговор.
Игры должны развлекать и увлекать. Учить и направлять.
И скука для игрока - это смерть для игры.
Лучше начните другой проект, как этот сделаете.
Хотя некоторые предпочитают вести сразу несколько проектов.
И это тоже выход - прокрастинируя на одном проекте от другого в сумме получится сделать оба.
Да, времени уйдёт больше - но если не отдыхать, сменяя деятельность, то проект может ждать участь многих заброшенных. Постепенно теряешь энергию, а на воле далеко не проедешь.
Через полгода уже делать будешь «через нехочу», что скажется на качестве проекта.
Отсутствие энтузиазма сразу видно.
Когда ты делишься наработками с людьми - они это видят.
А репутация - это пока единственное, что есть у молодой студии (или инди-разработчика игр).
По совету МакМиллена: «Делать надо то, к чему душа лежит. Самые интересные получались именно на взлёте энтузиазма»
Так что заканчивать надо, но при этом поддерживать огонь в душе тоже нужно.
И этот баланс трудно достичь.
Но к нему можно и нужно стремиться.
Комментарии
Отправить комментарий