Дневник разработки S.L. #2
В прошлых статьях я писал о выборе движка, создании первых ресурсов и анимации, настало время соединить части воедино, добавив немножко знаний и кода.
Напомню что я создаю игру о сражениях на арене и по моей задумке методы передвижения в бою и вне боя будут отличаться. Всё же прогулочная система перемещения - обязательный каркас для боевой системы перемещения и заняться ей надо в первую очередь.
В этой статье вы узнаете : гениальные методы восприятия устройства ввода движком, основы работы с векторами и мои проблемы с тригонометрией.
Определение ввода в векторную магию
И так начать стоит с кнопочек : вы нажимаете вперед и персонаж бежит.
Вроде всё просто, но способов реализации огромное количество, я приведу два примера :
● Привязка конкретных клавиш. Несовершенно и непрактично, вы как бы закрепляете за определенной клавишей определенное действие, в случае портирования игры на другие платформы всё придется менять, вероятно в более универсальный вариант.
● Тот самый универсальный вариант. В каждом устройстве есть информация, позволяющая компьютеру определить назначение клавиш, так вот движок Unity возьмет эти данные и преобразует во внутренние переменные, которые можно менять. Так например кнопки W и S точно так же как и стрелочки обозначают вертикальную ось, они представлены в виде одной переменной, принимающей значение от 1 до -1. Магия этого способа в том, что вы можете бегать на клавиатуре, потом подключить геймпад где стики определятся во внутренние переменные движка, а потом воткнуть руль с педальками и так же наслаждаться игрой, правда бежать вперед на педаль и поворачивать рулем играя в своеобразный файтинг, такая себе затея.
И так, я раскинул пару кубов (для ориентации и видимости передвижения) на пустынном поле, поставил человечка, которым будем управлять, настало время научить его двигаться.
Любой объект в движке имеет свои координаты в глобальной системе координат (уже сложно, извините). Они представлены в виде вектора в трехмерном пространстве (а значит и переменных у вектора три). Движение персонажа в моем случае основывается на абстрактном изменении вектора позиции, это значит что движок не спрашивает где находится персонаж, он лишь прибавляет/убавляет переменные, изменяя вектор позиции.
Магия №1. Ввод в вектор и передвижение
Внимание сюда :
x и y берут как раз значение тех самых данных устройств ввода. Нажав A, стрелку влево, повернув влево руль или стик на геймпаде, переменная y примет значение -1, так же и в обратную сторону.
Я создал вектор и поместил туда переменные ввода. Теперь этот вектор - своеобразное направление. Нажав, например, две кнопки, результат будет таким :
Я запросил у движка "сырые" значения ввода что отражено в слове GetAxisRAW. Без этой приписки данные могут принимать другие значения, например вполовину наклоненный стик перед передаст значение 0.5, что может быть полезно для интересного игрового опыта. В динамичной же игре я считаю управление должно быть максимально четким.
Так же в Vector3 я поставил Y на место Z, а всё потому что Y будет отвечать не за вертикаль, а за глубину, проще говоря - вперед-назад, а не вверх-вниз.
Магия №2. Плавное перемещение
Перейдем непосредственно к движению. Пока что достаточно будет создать простейшую систему изменения позиции в пару строк.
Первым делом я нормализовал вектор ввода, сделал его более "сырым" если так удобно. Raw функция иногда всё же дает промежуточные значения, нормализовав вектор их количество резко падает.
Далее я поменял его локальное направление, которое теперь зависит от помощника камеры. Зачем? Объясню в последнюю очередь, так будет понятнее.
Получаю плавную переменную currentSpeed (текущая скорость). Плавность заключается в постепенном изменении значения до нужного, математическими методами линейной интерполяции (для юнити-юнца достаточно знать о существовании Lerp и что туда вставлять). Переменная стремится к указываемому значению скорости за определенный отрезок времени.
Изменение координат объекта я сделал возможно туповато. К текущему вектору позиции прибавляется вектор ввода, умноженный на скорость и time.deltatime. Что это такое? Это время, которое понадобилось для прохождения последнего кадра. Программисты Fallout 76 кстати забыли на него помножить, так получилась зависимость скорости перемещения от значения ФПС.
Вернемся ко второй строке. Камера может крутится вокруг героя, а герой в свою очередь должен всегда понимать где для камеры - вперед. Без этой функции, повернув камеру на другую сторону персонажа, при нажатии вперед он бы побежал назад для нас, а для него и глобальной системы координат - вперед.
Магия №3. Поворот в сторону движения
Несколько дней просидел над этой бедой и своим непониманием тригонометрии. Надеюсь этот пример кому-нибудь поможет.
Задача такова : нужно трансформировать вектор направления (ввода) в направление, исчисляемое градусами. Вот как из (1,0,1) получить 45 градусов? Ну вот и я не знал.
Не хочется даже это комментировать, но надо. Нужно было вычислить из векторного значения - градус поворота и плавно повернуть. Коротко :
Вычислил арктангенс из значений ввода. Обычный mathf.atan опирается лишь на одну переменную, здесь же на две.
После я преобразовал получившееся число из радианов в углы и приплюсовал погрешность поворота камеры.
Сам поворот осуществляется плавно по тем же принципам, что описаны выше.
Результат
Работа продвинулась чуть дальше, чем описано в статье и поэтому я не мог себе позволить вставки в абзацах.
Так же я уже прикрутил анимацию, это отдельная и крутая система в движке. Если вы хотите почитать о работе с анимацией, пишите в комментариях, ибо тема глубокая и интересная.
Простота кода увы позволяет допускать такие дела :
Не совсем четко и красиво, верно? Для совершенствования этой системы нужно добавлять множество дополнительных переменных.
Следующим шагом разработки будет создание боевой системы передвижения и настройка поведения камеры, подписывайтесь, следите и оценивайте статьи!
Похожие статьи :
Дневник разработки S.L. #1. Где брать модели людей ?
Как анимируются персонажи? Опыт создания
