Создание игры. Игровой уровень.
Игровой уровень это небольшая часть игры, которая, обычно, является небольшой частью всего игрового мира. Практически все игры, в том или ином виде, используют игровые уровни. Разбиение создаваемой игры на уровни позволяет: разбить игру на отдельные независимые части-уровни, уменьшить время загрузки игры, точнее контролировать перемещение игрока по общему игровому миру, выполнять независимый дизайн каждого уровня, контролировать сложность игры (повышение от уровня к уровню), посадить за работу одновременно несколько дизайнеров игровых уровней (каждый дизайнер работает над своим уровнем игры), уменьшить потребление ресурсов игрой (каждый игровой уровень грузит только те данные, которые нужны для этого уровня игры и не более), упростить АИ (требуется обрабатывать только тех монстров, которые находятся на текущем игровом уровне). Раз игровые уровни так удобны – давайте добавим их и в нашу игру.
Из чего состоит игровой уровень
Из каких же компонент состоит игровой уровень? Обычно как минимум из следующих компонент:
- Описание расположения игровых объектов – враги на уровне, стены и прочие препятствия, игровые бонусы и т.д.
- Описание целей уровня – как правило, это условия при которых игровой уровень считается завершённым (пройденным).
- Описание логики работы игрового уровня – чаще всего это скрипты, определяющие игровую логику данного уровня
Естественно, помимо всего этого частью игрового уровня так же считаются разного рода игровые модели, текстуры, звуки и т.д. – в общем всё то, что составляет визуальную и звуковую часть любой игры. Эти компоненты могут быть как уникальными для текущего уровня игры (скажем, уникальный босс в конце уровня), так и общими с другими уровнями (скажем, обычная стенка, астероид, спрайт выстрела или рядовой враг).
Создание игрового уровня
Обычно игровые уровни создаются в специальных программах-редакторах, которые называются редакторами игровых уровней или просто редакторы уровней. Обычно редактирование уровня в таких программах максимально упрощено и автоматизированно, для того, что бы максимально упросить и ускорить создание очередного уровня для игры. Однако, редактора у нас пока нет (позже будет урок по созданию редактора игровых уровней), потому придётся обходиться подручными средствами. Наиболее удобным из таких средств являются те самые xml-файлы, работу с которыми мы рассмотрели в нашем предыдущем уроке “PugiXML: XML-файлы”.
Нам тоже пора бы уже ввести понятие игровых уровней, потому что случайная генерация врагов – это, конечно, хорошо, но хотелось бы иметь с нашей стороны над тем, что происходит в игре. Итак, очередным этапом создания игры будет создание игровых уровней, а точнее пока только одного из них.
Поскольку наш корабль летит “сквозь” игровой уровень, наверное, самым логичным и правильным будет решение размещать врагов, просто задавая их координаты, т.е. положение в пространстве игрового уровня. Получится xml-файл примерно вот такого вида:
x="100" y="100">Enemy01 > x="700" y="100">Enemy01 > x="400" y="150">Enemy02 > // и так далее
Всё, что нам нужно будет сделать для создания игрового уровня – это записать в этот файл координаты всех врагов.
Класс игрового уровня
В данный момент наш игровой уровень должен содержать лишь минимальный набор данных, а именно: данные о расположении наших противников на уровне. Код совсем не сложен:
class CGameLevel { struct LevelObject { D3DXVECTOR2 m_pos; std::string m_strType; LevelObject(const std::string& sType, D3DXVECTOR2 pos); }; //! Что бы было удобнее использовать - новый тип typedef std::vectorLevelObject> LevelObjectsArray; //! вектор со списком объектов на уровне LevelObjectsArray m_vecObjects; public: CGameLevel(void); ~CGameLevel(void); //! Функция загрузки уровня из файла bool Load(const std::string& strFileName); //! Получить список объектов в заданном интервале Y void GetObjectsInYRange(float fYStart, float fYEnd, LevelObjectsArray& arrOut); };
Загрузка игрового уровня в игру
Поскольку в предыдущем уроке мы уже научились читать xml-файлы, загрузка уровня из xml-файла не представляет из себя никакой проблемы:
bool CGameLevel::Load( const string& strFileName ) { // удаляем всё, что было загружено ранее m_vecObjects.clear(); // резервируем место - так быстрее потом будет добавление работать m_vecObjects.reserve(4096); // читаем сожержимое файла const string strContents = GetFileAsString(strFileName); if (strContents.length()==0) return false; // что-то пошло не так pugi::xml_document doc; pugi::xml_parse_result result = doc.load_buffer_inplace( (void*)strContents.c_str(), strContents.length()); if (!result) return false; // Ошибка парсинга данных XML // Парсим документ for (pugi::xml_node item = doc.first_child(); item; item = item.next_sibling()) { const char* name = item.name(); if (strcmp(name, "enemy")==0) { D3DXVECTOR2 pos(0,0); // читаем координаты stringstream(item.attribute("x").value()) >> pos.x; stringstream(item.attribute("y").value()) >> pos.y; // добавляем врага в список m_vecObjects.push_back( LevelObject(item.child_value(), pos) ); } } // функтор сортировки struct sort_by_y { bool operator() (const CGameLevel::LevelObject& a, const CGameLevel::LevelObject& b) { return (a.m_pos.yb.m_pos.y); } } sort_object; // на всякий случай сортируем объекты по возрастанию Y // если они вдруг не были отсортированы в файле sort(m_vecObjects.begin(), m_vecObjects.end(), sort_object); return true; }
Получение объектов из игрового уровня
Для того, что бы нам рождать новых врагов, при движении нашего корабля в пространстве игрового уровня, нам нужна функция, которая позволила бы получить конкретно тех врагов, которые должны появится в данный момент.
Каждый кадр игровой уровень смещается в на некоторое расстояние по оси Y, точнее это наша “игровая камера” смещается. Если на предыдущем кадре мы видели часть уровня, которая начинается в какой-то позиции Y_пред_кадра, то в следующем кадре эта позиция будет уже Y_пред_кадра+дельта, где дельта обычно равна скорости нашего корабля.
Итак, напишем функцию получения списка тех врагов, которые станут видимы (появятся в пределах экрана) благодаря этому смещению, она получилась вообще элементарная:
void CGameLevel::GetObjectsInYRange( float fYStart, float fYEnd, LevelObjectsArray& arrOut ) { struct filter_by_y { float m_fYstart, m_fYEnd; filter_by_y(float fYStart, float fYEnd) : m_fYstart(fYStart), m_fYEnd(fYEnd) {} bool operator() (const CGameLevel::LevelObject& a) { return (a.m_pos.y>=m_fYstart && a.m_pos.ym_fYEnd); } } filter_object(fYStart, fYEnd); // копируем с использованием бэк-инсёртера // без него будет ошибка, т.к. целевой массив, // по идее должен быть пустым и там нет места // для записи новых элементов copy_if(m_vecObjects.begin(), m_vecObjects.end(), back_inserter(arrOut), filter_object); }
Я хочу сразу уточнить, что этот код будет работать, но при больших размерах уровня (тысячи/десятки тысяч объектов и более) – она начнёт тормозить, т.к. её придётся каждый кадр проверять все объекты в уровне и смотреть, попали ли они в заданный нами промежуток. Пока объектов на уровне не много – нас это мало волнует, но в будущем нам придётся оптимизировать эту функцию.
И алгоритм copy_if не относится (уж не знаю по каким причинам) к стандартным алгоритмам STL, потому я написал его сам:
templatetypename ForwardIter, typename OutputIter, typename UnaryPred> OutputIter copy_if(ForwardIter begin, ForwardIter end, OutputIter dest, UnaryPred f) { while(begin != end) { if(f(*begin)) *dest++ = *begin; ++begin; } return dest; }
На этом с загрузкой самого игрового уровня мы закончили. Исходники пока не прилагаю – они будут в след. уроках, пока же попробуйте сами разобраться в том, что я описал в этой статье – если поймёте, то легко сможете сами внедрить этот код в наши предыдущие исходники и посмотреть как оно будет работать.
Михаил Кадиков
Создание компьютерных игр — дело непростое. В наши дни это довольно комплексный и трудоёмкий процесс, который включает в себя участие целой команды разработчиков. Как правило, это специалисты в самых различных областях, каждый из которых играет свою роль в общем деле — сборке сложного механизма под названием компьютерная игра.
Чтобы выяснить, что такое дизайн уровней, давайте обратимся к основам создания любой игры и определим, какое место занимает дизайнер уровней в процессе разработки.
На трех китах
Разработка любой игры основывается на трех базовых элементах — игровой концепции, технологии и визуальном стиле. Словно три кита, держащие на себе мир, эти три элемента символизируют незыблемую опору, без которой реализация игрового проекта не представляется возможной.
Первым элементом является игровая концепция, которая определяет правила игры и механику взаимодействия игрока с виртуальным миром. Как быстро игрок бегает и как высоко он прыгает? Какие препятствия и каких персонажей он встретит на своём пути? Каким образом он будет с ними взаимодействовать? На все эти вопросы отвечает геймдизайнер (от англ. «game designer» — проектировщик игры), именно он и занимается созданием игровой концепции.
Второй элемент — это технология, которая представляет собой техническую базу для реализации игры. Основной функционал обеспечивает игровой движок (от англ. «game engine»), а дополнительные инструменты позволяют дизайнерам и художникам создавать и редактировать содержимое игры. Созданием технологии, инструментария, а так же реализацией игрового функционала и механики обычно занимаются программисты, без которых любые, даже самые смелые идеи геймдизайнера так и останутся на бумаге.
Третий базовый элемент, лежащий в основе любой игры, — это визуальный стиль, который определяет облик игры. Созданием визуальной части занимается широкий круг художников, работающих в самых различных областях компьютерной графики. Например, концепт-художники придумают уникальный облик игрового мира. Виртуальные скульпторы слепят модели персонажей, аниматоры «оживят» их, придав каждому движению свой неповторимый характер. А художники по игровому окружению создадут все необходимые детали для декорирования уровней и наполнят его спецэффектами.
Все эти три элемента в совокупности служат одной цели — созданию игрового процесса, направленного на развлечение игрока.
Что такое геймплей?
Для обозначения процесса взаимодействия игрока с игрой существует специальный термин «геймплей» (от англ. «gameplay» — игровой процесс).
Геймплей — это то, что отличает компьютерную игру от таких неинтерактивных видов развлечений, как книги или кино. Смотря кино или читая книгу, человек является лишь сторонним наблюдателем. В случае с геймплеем мы получаем возможность напрямую взаимодействовать с игрой, решая поставленные геймдизайнером задачи при помощи игровых механик.
В любой игре можно выделить два основополагающих типа геймплея — геймплей, составляющий ядро игры, и геймплей на уровнях. В английской терминологии эти два типа чаще всего называют «core gameplay» и «level gameplay».
Геймплей, составляющий ядро игры (core gameplay) — это набор базовых правил и механик, которые доступны игроку по умолчанию. Например, этот тип геймплея определяет характеристики персонажей, их способности, а также то, как они взаимодействуют друг с другом. Все эти основные правила создаются геймдизайнерами и являются отправной точкой для работы дизайнера уровней — геймдизайнера, который специализируется на проектировании виртуального пространства.
Хорошим примером уровня без геймплея является чистое поле или пустая комната, где игрок может использовать только данные ему по умолчанию способности, то есть бегать, прыгать и стрелять. Следовательно, от дизайнера уровней требуется спроектировать такую локацию, которая обеспечит достаточное количество интересных игровых ситуаций для применения каждой базовой механики. Таким образом, оперируя пространством, объектами и настройками виртуального мира, дизайнер создает геймплей на уровнях (level gameplay), позволяющий подарить новый уникальный опыт взаимодействия с игрой.
В играх-стратегиях уровни называют картами (от англ. «map»), где геймплей создается за счет различных особенностей ланшафта, местоположения игроков и ценных ресурсов. В гонках уровни представляют собой трассы с большим разнообразием маршрутов и препятствий на них. В приключенческих играх геймплей строится на том, какие препятствия, ловушки, головоломки и враги встретятся игроку. Таким образом, в играх разных жанров уровни по своей структуре и внешнему виду могут кардинально отличаться друг от друга и носить различные названия (карты, миссии, зоны, этапы, задания), но вместе с тем выполнять одну и ту же функцию — дополнять, развивать и создавать вариативность базовому геймплею.
Итак, рассмотрев ключевые элементы процесса разработки компьютерной игры, мы выяснили, что в индустрии видеоигр существует специальная отрасль под названием «дизайн уровней», занимающаяся проектированием игровых уровней. А дизайнер уровней — это разновидность геймдизайнера, который создает геймплей на уровнях, позволяющий основным игровым механикам раскрыть весь свой потенциал и подарить интересный игровой опыт.
В чём секрет хорошего левел‑дизайна: объясняют авторы Atomic Heart, Encased и One Day More
Шесть эссе разработчиков о левел‑дизайне, ощущении потока и важности левел‑арта.
Иллюстрация: Unsplash / Polina Vari для Skillbox Media
Владимир Шумилов
Журналист, автор статей, посвящённых игровой индустрии.
Дизайн уровней — одна из основных составляющих любой игры, которая не заканчивается на визуальных решениях и красоте локаций. Так, Михаил Кадиков, работавший над уровнями в Hunt: Showdown, The Climb и Might & Magic Heroes 7, в своей книге «Проектирование виртуальных миров» пишет, что левел-дизайн «совмещает в себе десятки аспектов, таких как геймплей, архитектура, освещение, спецэффекты, звук и многое другое».
В понимании Михаила, дизайнер уровней — своего рода геймдизайнер, «который создаёт геймплей на уровнях, раскрывает потенциал основных механик и дарит игрокам новый опыт». Но как этот самый опыт спроектировать и перенести в трёхмерное пространство? Как сделать уровень не только удобным и «правильным», но и интересным?
Мы пообщались с дизайнерами уровней, руководителями разработки и 3D‑художниками: спросили у них, в чём секрет хорошего дизайна уровней? По уже сложившейся традиции ответы получились разные, и в этом их главная ценность. Каждое эссе здесь — в первую очередь личный опыт, знания и приёмы, которыми разработчики хотят поделиться.
Василий Скобелев
Дизайнер уровней, научный редактор
(Vector, Shadow Fight 2, Atomic Heart)
Я занимаюсь разработкой игр больше восьми лет, и, знаете, на протяжении всего пути люди спрашивают меня: «А как сделать идеальный уровень?» Очень часто в ответ они ожидают услышать или, ещё хуже, слышат примеры из ААА-тайтлов, на которых разработчики разбирают матчасть по знанию софта или конкретных приёмов дизайна.
Это не совсем натягивание совы на глобус, но мне кажется, что секрет всё-таки не в знании трендового софта и даже не в набивании руки на сотне блокаутов уровней. Он в подходе, в культуре разработки.
Что я имею в виду? Да всё очень просто. Чтобы это эссе было и правда полезным, я не буду срывать покровы с разработки контента в конкретном жанре, под конкретную платформу или на определённом движке. Таких гайдов и так много в Сети. Но я постараюсь сформулировать несколько простых правил, которые будут справедливы для левел-дизайнеров всех мастей. Погнали.
Самое главное, сакральное правило — не работать на скорость. Единственное задание, в котором вас могут закономерно попросить сделать работу быстро, — это тестовое при приёме на работу. Ну просто так исторически сложилось, что соискателя таким образом мотивируют не затягивать.
Во всех остальных случаях работайте на качество, а не на срок. Как только начинается работа на скорость — качество неизбежно страдает. Помните, например, в каком состоянии вышла Diablo 2: Resurrected? Помните, сколько было критических ошибок в игре по сети? Не думаю, что был хоть один человек на планете, который сказал: «Зато смотри, как быстро они выполнили работу». Ни в одной сфере искусства при оценке работы автора не учитывается то, как быстро он её делал. Скорость в данном случае не несёт художественной ценности, в отличие от того, насколько круто вы сделали работу.
Человек не может работать всегда с одинаковой эффективностью, и это нормально. Когда не идёт, не выжимайте из себя человеко-часы. Просто возьмите паузу, чтобы проветрить мозги, восстановиться и подумать над дизайном. Бывает, что и целый день может быть просто «не ваш». Это тоже нормально. Вам нужна крутая локация, вам нужен хороший результат, а не вымученная копипаста лейаута уровня.
Тут мы подбираемся ко второму правилу. Работайте на идею. Всегда стоит помнить, ради чего вы собираете локацию, какую идею или идеи вы обыгрываете. Ваша локация должна на эти идеи работать, а не просто быть.
Помните Red Dead Redemption 2? В ней ведь полно как плюсов, так и минусов: затянутое повествование, медленные анимации, непредсказуемое загрязнение оружия и прочее. Но все, абсолютно все элементы работают на цель проекта: подарить аутентичное ощущение вестерна, будто вы — герой подобного произведения.
Вот так же и с локациями. Сделайте список идей, с которыми вам хотелось бы поработать. Эдакий список испытаний. От очень общих, типа «сделать цилиндрическую локацию» или «выдержать два яруса по высоте», — до самых мелких деталей вроде «лестницу в точке X загнуть под необычным углом» или «не забыть поставить укрытие в проход Б». Зарисуйте схему уровня.
Это может быть простая так называемая молекулярная схема (именованные узлы типа «мост», «маяк» и так далее) или более подробная схема местности в пропорциях. Можно даже зарисовать вид локации с перспективы конкретной точки в пространстве. Например, как её будет видеть игрок на входе. И обязательно возвращайтесь к своим записям в процессе работы. Что-то точно забудется, но бумага поможет всё вспомнить.
И тут мы приближаемся к менее очевидному пункту. Быть автором локации не значит быть автором каждого решения в ней. Не бойтесь делиться принятием решений. Не бойтесь плейтестов. Как ни удивительно, вы не должны продумывать каждую кочку и каждый поворот на уровне сами.
Возьмите обратную связь у коллег. А ещё лучше — питчите свои идеи по локации прежде, чем их выполнять. Если хотите максимально интересный опыт, рекомендую проверять свои идеи на разных коллегах, причём индивидуально. Таким образом, вы получите фидбэк без лишнего эффекта привязки. Позвольте людям «надиктовать» вам локацию.
В конечном счёте вы всё равно будете её автором, потому что именно вы запустили все эти процессы и собирали итоговую версию в игровом редакторе. Только теперь в ней будет сразу учтена обратная связь, а ваши тиммейты будут чувствовать свою причастность. А в отдельных случаях — даже ответственность за часть решений.
Пробуйте, ищите, и обязательно найдёте. Главное — не опускать руки!
- Страница Atomic Heart в Steam
- Блог Василия Скобелева в Telegram
Мария Обложко
3D-художник (One Day More)
Меня зовут Маша, я 3D-художник и латентный левел-дизайнер. В нашей студии существует негласное правило: «Если не умеешь, то научись». Поэтому, если получаешь задачу, которой раньше не занимался, — самое время начать развиваться в новой, незнакомой области. Так было и со мной.
One Day More находилась на начальной стадии разработки. Локации были собраны из кубов, а персонаж передвигался в Т-позе, без анимаций. Большинство уровней были готовы с концептуальной стороны — оставалось только сесть и делать.
Но один уровень, четвёртый, вызывал множество вопросов и непоняток. Если говорить проще — никто не знал, с чего начинать, на что опираться и что в него закладывать. Была известна только сюжетная составляющая. Четвёртый уровень рассказывает часть истории, в которой главная героиня, Ханна, сочиняет песню. Героиня хочет выступить на концерте и исполнить её вместе со своими друзьями.
Было понятно, что это должен быть максимально абстрактный уровень. Я начала работу, когда уже существовал первый прототип. В нём не было механик и внятного геймплея, а на просто красивой локации выехать не удастся. На этом уровне игрок мог двигаться вперёд, вправо и влево, слушать мелодию на фоне — и всё. Позже мы попробовали добавить туда объекты, но проблему «пресности» они не решили. В итоге пришлось перекроить уровень заново.
Это очень странное чувство, когда перед тобой только пустая сцена в Unreal Engine, комок неясных идей и задача — сделать уровень. Так с чего же начать? Конечно, с поисков референсов!
Как можно изобразить процесс создания музыки, визуализировать идею как сущность, сделать такую локацию, словно игрок находится у кого-то в голове? Действительно есть над чем подумать. После бурных брейнштормов мы сели за новый прототип: геймдизайнеры обдумывали механики, композитор искала решения озвучки, а дизайнер (это я) — обдумывала визуальную часть.
Я собрала несколько мудбордов с атмосферой уровня и его архитектурой. На этом этапе появилась идея стилизовать уровень под программу для звукозаписи. Наша композитор сделала несколько скетчей, где изобразила миди-«бруски», левитирующие в пустом пространстве уровня, как будто Ханна едет внутри программы для работы со звуком. Потом добавила элементы диджейского пульта: нобы, фейдеры и пэды.
И вот спустя некоторое время готов новый прототип. Понятно, что делать, куда двигаться, на что обращать внимание. Нам казалось, что вроде бы даже можно посидеть над головоломками. На этом этапе уровень преобразовался в раннер: игрок должен был постоянно ехать вперёд, параллельно решая загадки и расчищая путь. Концепция строилась вокруг непрерывности движения — так мы хотели показать поток мыслей при создании музыки.
Обрадовавшись, мы презентовали прототип остальным коллегам и с замиранием сердца смотрели, как его тестируют. По реакции коллег мы видели: им неинтересно. Скучные и элементарные загадки, посредственный визуал, не хочется проходить до конца. Вы не подумайте, они все на самом деле милейшие люди!
Сложно работать, когда в голове крутятся мысли о том, что ничего не получается. Всё, что я делаю, не цепляет, геймплей не захватывает, а уровень никак не выстраивается в последовательность удачных элементов, не сбивающих темп. Это ведь нужно смириться, снова сесть, снова открыть пустую сцену и снова усиленно думать и придумывать.
Однако этот процесс сильно развивает. Очень часто приходится переделывать что-то, будь то игра, мультфильм, конкретный персонаж или что-то другое. И на самом деле тестирование и оценка вашей работы — это тяжёлый, но важный этап в создании по-настоящему хорошего и качественного продукта. Вы можете смотреть на работу с другой стороны — противоположной вашей точке зрения. Это толчок вперёд, его нужно уметь принимать и анализировать. К слову, даже у этого эссе было несколько итераций.
Проектов на тот момент было очень много, людей не хватало, поэтому на плечи дизайнера уровней легла ответственность и за геймдизайн. Сложно, непонятно, но интересно. Что я, далёкий от этой области человек, могу привнести в игру?
Я начала собирать новые мудборды и очередной прототип. Правда, в 3D-софте, потому что на тот момент работать с физикой и логикой Unreal Engine мне было трудно. Я опиралась на отвергнутый коллегами вариант уровня, стараясь изменить его по комментариям, но не уходить далеко: наша задумка мне всё ещё нравилась.
Вместе с композитором мы продумали новую основную концепцию: ушли от пространства — имитации звуковой программы, оставив элементы диджейского пульта. Добавили абстрактные формы музыкальных инструментов, вписав их в загадки.
И вот оно, долгожданное «одобрено»! Переношу прототип в движок, зову всех геймдизайнеров, слёзно прошу их помочь настроить техническую часть, тестирую и… есть несколько правок. Не отчаиваемся, переделываем, тестируем — и так по кругу пару-тройку раз. Помним, что это залог хорошей игры, как я писала ранее.
Было решено большую часть придуманных мною загадок заменить на более… загадочные или модифицировать уже готовые. Однако я всё равно сильно горжусь той малой частью оставшихся нетронутыми пазлов, которые дожили до релизной версии игры.
Была проведена огромная работа по озвучиванию уровня. Из-за того, что локация была завязана на музыке, нам нужно было объединить звук и геймплей для лучшего погружения. Наша команда придумала условные порталы, проезжая сквозь которые Ханна запускает звуковую волну. Та расходится по всему уровню и заставляет объекты поочерёдно подпрыгивать. Также порталы служат неким достижением для Ханны. Когда героиня их пересекает, помимо уже упомянутой волны, запускается новый звуковой луп в саундтреке: барабаны, скрипка, мелодия…
На уровне обычно около 15 порталов. В начале мы слышим только эмбиент (шум для атмосферы), однако, когда Ханна преодолевает последний портал, музыка складывается в итоговую версию. В этот момент игрок впервые целиком слышит песню, которую главная героиня придумала для выступления.
Что мы получили в итоге? Абстрактный уровень, собранный из элементов диджейского пульта и кусочков сэмплов музыкальных инструментов, с поэтапным собиранием финальной песни. Начало уровня символизирует «белый лист», и чем дальше игрок продвигается, тем больше деталей появляется на этом «листе». В конце мы попадаем в локацию, созданную по референсу города Санторини в Греции. Так мы проходим путь от полной абстракции до мира, близкого к реализму.
На вопрос, в чём секрет хорошего дизайна уровней, могу ответить так: в поиске, переосмыслении и референсах. Это если кратко.
Не устану повторять, что крайне важно переделывать готовую работу, особенно если для вас там на первый взгляд всё идеально. Найдите вдохновение, насобирайте кучу референсов и воплотите некоторые из них, для теста. Потом уже выбирайте, что смотрится лучше, и доработайте до финала. Создание хорошего дизайна — это не навык, а итог длительного поиска.
- Страница One Day More в Steam
- Группа One Day More во «ВКонтакте»
Как создаются уровни для игр
Паттерн 1: Указание направления Дизайн-паттерны должны решать задачи игрока
В процессе прохождения уровней игроки могут столкнуться с ситуациями, когда становится непонятно куда идти дальше, что особенно актуально в проектах, где пользователям доступно исследование окружающего мира. Чтобы избежать таких неприятных ситуаций используется паттерн «указание направления», который, в отличие от инструкций и туториалов, дающих человеку четкие указания действует невербально.
Один из наиболее простых способов указать пользователю верное направление — использовать твердые тайтлы. Хороший пример реализован в игре Super Mario World, где геймер четко видит куда его персонаж может запрыгнуть и двигается в нужном направлении. Запутаться в таком случае достаточно сложно.
Еще один часто применяемый вариант — направлять игрока с помощью собираемых предметов: монет, фруктов и прочего. Фактически такие элементы демонстрируют основной маршрут и сообщают о местах, которые пока не видны пользователю — например, когда нужно совершить прыжок, но место куда персонаж сможет приземлиться находится за пределами экрана.
Также такая техника нередко используется для того, чтобы предотвратить неверные решения со стороны игрока, к примеру прыжок с обрыва где нет собираемых объектов сам по себе выглядит довольно опрометчиво и опасно. Такой паттерн применяется во многих играх, например Jungle Adventure, Super Mario, Red Ball и прочих.
Еще один распространенный способ указания направления — размещение опасностей. Это могут быть сильные NPC или объекты, столкновение с которыми может привести к проигрышу. Анализируя зоны к которым нельзя приближаться человек может выбрать верное направление. Однако здесь стоит заметить что размещение врагов, в том числе особо опасных, может использоваться и с прямо противоположной целью — для привлечения внимания геймеров, поскольку победа над ними зачастую связана с получением ценных наград.
И последний способ указания направления который мы рассмотрим — использование подсказок в окружении. Такой паттерн может быть реализован с помощью изменения освещения, цвета, текстур и прочего. Принцип его работы основан на том, что более яркие элементы привлекают внимание человека и стимулируют любопытство, подталкивая изучить эту зону подробнее.