Хорошего весеннего дня! В ходе разработки различных механик и других интерактивных функций для компьютерных игр разрабатываются различные схемы-рецепты для реализации необходимого функционала.
Большинство из них не привязаны к конкретному используемому движку/языку.
О некоторых из них я расскажу на примере одного из моих проектов с биомашинами.
Тантрамантра
Начнем с самого проекта.Это полигон нескольких карт мира, где вы сможете покататься на машине-биотрансформере, которая умеет прыгать, кувыркаться, стрейфить и создавать какие-то объекты.
Также управляемый аппарат может принимать различные формы, в том числе предназначенные для полета (не имеющие колес).
На картах есть телепорты (объекты в форме синих звездочек), которые переносят машину в другие миры.
Всего таких миров четыре — стартовый, с водой и камнями, с ровной поверхностью, и ещё один водный.
В стартовом мире игрока быстро начинают преследовать два терминатора, победить которых можно с помощью специального оружия (после чего можно кататься в более спокойной обстановке).
Если они оказываются ловчее, то происходит окончание игры и игра начинается заново.
Проектирование игровых механизмов
Обычно пользователь, в том числе и в любой игре, даже особо не задумывается о том, как все устроено внутри (даже если разработчик играет, все равно нужно настроиться на определенный лад, чтобы воспринимать происходящее более аналитично).Взаимодействие просто происходит, все происходит само собой.
Одним словом – какое-то волшебство, хотя и кажется относительно знакомым.
Сюжеты, персонажи, повествование – это все поверхностно (хотя и важно с другой точки зрения), поскольку игрок способен гонять по экрану даже абстрактные кубики, просто потому, что «клак, щелк, поехали» его уже зацепило и понесло.
его подальше.
При этом игра не обязательно должна быть спинальной — перестановка карточек, нажатие разных переключателей/переключателей и прочие размеренные действия тоже зацепляют пользователя своей обратной связью, ведь она просто существует. Вопросы типа «почему Марио разбивает кирпичи головой» совершенно не волнуют того, кто играет в Супермарио.
Он планирует, в какую трубу прыгнуть, как разбить блок и успеть схватить гриб, как убить назойливую тучу.
По сути, это решение различных задач, представленных в виде символов и внутриигровых отношений.
Символы, конечно, вызывают ассоциации, поэтому заодно можно обсуждать с другими кирпичи, сантехнику, трубы с мухоловками и прочие психоделические вещи, которые происходят (чего на самом деле не происходит, просто это, наверное, более абстрактная и интересная тема, чем обсуждая какие-то скучные повседневные вещи).
Собственно, человек способен придумать себе какое-то абстрактное развлечение по любому поводу буквально на ровном месте, выражается ли это в подсчете ворон, фотографировании, рассматривании проезжающих машин, в каких-то мини-челленджах, например, приходить куда-то вовремя или предпочитать обойтись обычным напильником вместо того, чтобы идти в сервисный центр.
То есть никакой истории нет, просто деятельность, пусть даже и мысленная, и все взаимодействие заключается как минимум в фильтрации поступающей информации (на что обратить внимание, на что игнорировать и так далее).
Итак, хотя внутриигровое действие воспринимается пользователем на уровне достаточно очевидных происходящих событий (нажал это, взял то), за экраном происходят совершенно другие истории, от которых нужно только составить правильное впечатление.
Но быть и казаться — это две разные вещи.
Задача геймдизайна состоит именно в выборе конкретной модели, которая позволит вам создать желаемый интерактивный опыт. Пути решения этих проблем могут быть весьма разными, но нередко можно (и нужно) искать модель, которая просто сформирует желаемую иллюзию, без лишних осложнений.
То есть вам не нужно подключать плагин вывода текста, если вам нужно показать всего пару надписей, а вместе с ними достаточно вывести картинку.
Нет необходимости подключать библиотеку физики, если вся физика в вашей игре представляет собой упрощенную гравитацию за счет смещения объекта вниз в каждом кадре.
И так далее и тому подобное.
Иногда это работает наоборот - когда уже есть какие-то встроенные инструменты, та же физика, то почему бы не сделать через нее какие-то вещи.
Этот же таймер может заменить триггерный кубик, падающий с определенной высоты.
Игрок по-прежнему будет видеть только то, что ему решили показать, и будет воспринимать связи между объектами, которые сформировал для него разработчик.
Придумывая структуру различных законов и связей, действующих в игре, нужно разбить их на отдельные элементы, для начала хотя бы выделив основной и второстепенный функционал.
Съесть слона по частям все же стоит, даже если это вовсе и не слон, но, скажем так.
Грибы
Какое-то время «грибы» в прототипе были декоративным элементом, но сразу подразумевалось, что потом их можно будет хотя бы раздавить.Таким образом, им нужен был следующий функционал: отслеживание столкновений с игроком, чтобы привязать к нему какую-то реакцию.
В качестве мелких деталей: более визуальный эффект разрушения, а также замена фактического разрушения с переходом в неактивную фазу и восстановлением гриба через некоторое время.
В результате столкновения с грибами определяются за счет использования предложенного движком элемента WorldTrigger, который реагирует на пересечения с геометрией.
Все грибы упакованы в местные «сборные дома».
Параметр IntersectionMask, задающий битовые маски для пересечений, не используется в коде гриба, поскольку он был необходим для рейкастов.
В основной части скрипта происходит следующее: при инициализации к триггеру привязывается функция Enter. В основном цикле обновления счетчик раскручивается, если гриб способен «притвориться мертвым».
По истечении этого счетчика гриб меняет свое состояние на «живой» и снова ждет, пока его переедут. В функции Enter фактически гриб временно исчезает и меняет свое состояние на «мертвый».
Чтобы все выглядело еще лучше, можно сначала показать недавно умерший гриб в уменьшенном состоянии, не активируя сам триггер, затем постепенно увеличивать модель гриба и только потом включать триггер.
Если бы в движке не было подготовленных инструментов в виде триггеров и лучей, то можно было бы написать свой вариант расчета столкновений.
Например, вычислить разность координат гриба и автомобиля тривиально.
А поскольку особой точности не требуется, то и этот процесс можно оптимизировать разными способами, например, проверяя расстояние только по двум осям, а на предварительном этапе смотря только по одной, подключая при необходимости проверку по второй.
То есть каждый «гриб» в цикле может проверить, находится ли позиция X машины в пределах его диапазона, и если да, то проверить диапазон Y и принять какое-то дальнейшее решение.
Терминаторы
В игре требовалось какое-то элементарное преследование врагов.Я решил не делать их колесными, а создал несколько простых сфер, которые перемещаются упрощенно.
Таким образом, нужно было запланировать следующее: реализацию прямолинейного движения, движение навстречу игроку.
Второстепенными задачами здесь были: возможность стрельбы и некая дополнительная полировка движения.
Можно было сделать врагов физическими и перемещать их с помощью сил, но для простоты я дал им нефизическое движение, регулируемое лучами.
А вот как работают эти враги - пара сфер и муляж прицела, в который спавнятся выстрелы 
Я не буду приводить весь код; ограничимся анализом параметров.
Пара счетчиков для отслеживания пауз между шотами и рейкастами.
Очки.
Флаги состояния, чтобы определить, когда двигаться прямо (потому что луч не касается земли) и когда на некоторое время переключиться в состояние пролета.
Во время инициализации рассчитывается случайное увеличение скорости, чтобы разные враги двигались с немного разной скоростью и с меньшей вероятностью наползали друг на друга.
Оружие
Машины уже умели стрелять всякими штуковинами, но это были различные спецэффекты – физические кубы, светящиеся сферы и так далее.Для нанесения урона мне хотелось иметь отдельное подбираемое оружие с патронами, как в шутерах.
В первую очередь, чтобы игрок четче понимал, когда можно выстрелить чем-то, производящим реальный эффект. Другим вариантом могло быть назначение стрельбы на конкретную технику, чтобы игрок мог в любой момент переключиться на разрушительные формы.
Оружие нужно было: а) поднять, б) выстрелить.
Это если смотреть с позиции игрока.
Ну а с точки зрения разработчика: а) как-то установить конфликт между оружием и автоматом, б) решить, как именно отобразить, что оружие получено, в) определить правила, по которым оружие используется.
Как видите, сами кадры в этом плане даже не были приоритетом.
Во многом потому, что нерест направленно движущихся объектов самой машиной уже был подготовлен и оставалось только приделать это к реализации оружия.
Точка подбора оружия также использует WorldTrigger для обнаружения столкновений.
И это ее код. Машина обнаружена и ссылка на ее скрипт кэшируется.
Также берётся ссылка на триггер и на этапе инициализации устанавливается обработчик событий для входа объекта внутрь зоны триггера.
Если входящий объект — машина, то внутри ее скрипта вызывается функция newWeapon. Объект, содержащий модель летающей пушки, помещается на уровень и отключается.
В случае столкновения с точкой выбора оружия он включает этот объект и тот под действием своего скрипта управления летит к игроку, после чего следует за игроком дальше.
При этом автомат переходит в боевой режим (меняется один из важных флагов переключения в коде) и в этом измененном состоянии все, что раньше происходило по левому клику мыши, заменяется выстрелами из оружия.
Когда патроны заканчиваются, автомат сам выключает объект с моделью оружия и возвращается в обычный режим.
NodePet — объект, представляющий пушку 
Код NodePet. Точка привязки, за которой он будет следовать, — это макет прицела, висящий на печатной машинке.
А Ротатор - это еще один манекен, уже в центре самой пушки, который копирует вращение этого прицела так, чтобы пушка смотрела в нужную сторону (в качестве бонуса это дает эффект вращения пушки вокруг своей оси при прицеливании).
машина движется).
Здесь реализован принцип координатного слежения – орудие начинает двигаться, если машина отходит от него на определенное небольшое расстояние.
Сначала отклонение отслеживалось только по осям X и Y, а затем для большей точности я добавил еще и Z. Кстати, о кадрах здесь вообще ничего нет. Это потому, что они создаются скриптом самой машины, а не объекта с пистолетом.
Выстрелы
Собственно, сами снаряды.Для начала я дал их терминаторам в упрощенном виде, не нанося урона, и когда они уже работали как надо (включая списание здоровья с автомата, отображаемое в интерфейсе) и механика выбранного оружия тоже была готово, затем дело дошло до ударов игрока.
Эти кадры работают немного по-другому.
Фрагмент сценария выстрелов противника.
Они появляются и начинают лететь в ту сторону, куда смотрел терминатор (то есть на игрока).
Дополнительные действия выстрел начинает выполнять не сразу, а после небольшой задержки (reactionTimer) — простой способ избежать нежелательных столкновений в момент его появления.
После задержки выстрел начинает анализировать пройденные отрезки на предмет пересечений, и если там что-то обнаруживается, оно уничтожается, теряя эффект. Если бы у этого чего-то было RigidBody, то выстрел придал бы импульс там.
А если это еще и машина, то выстрел находит на ней скрипт и вызывает там функцию потери очков жизни.
Поскольку выстрелы противника отслеживают пересечения с большей частью геометрии, зачастую они могут поразить какую-то визуальную часть автомобиля, не достигая его «ядра».
Таким образом, получается, что некоторые выстрелы как будто не пробивают броню.
Фрагмент сценария удара игрока.
Он больше не отправляет RigidBody и не проверяет объект на наличие скрипта.
Здесь в случае попадания создается дополнительный рейкаст, который реагирует только на конкретную маску сферы противника.
Если он обнаружен, выстрел просто выводит его из строя.
Далее включается скрипт самого противника, который следит за состоянием его основной сферы.
Если она окажется отключенной, то противник понимает, что ему нанесен урон, а значит, ему необходимо отнять у себя единицу здоровья и снова включить сферу.
При этом вы получаете визуальный эффект воздействия даже без спауна частиц, только если слишком быстро включить сферу обратно, вы можете не заметить этот момент. Таким образом Терминатора повредить намного проще — он более открыт для ударов, но игроку сложнее прицеливаться из его прямолинейного оружия, поэтому у врагов тоже есть определённые шансы.
?Энергосистема
Некоторые машины имели возможность поливать пространство перед собой физическими кубами.И в один прекрасный момент была придумана игровая механика, с которой эти кубики могли взаимодействовать — это должна была быть небольшая цепочка деактивированных «электростанций», которые можно было починить, кинув в них те самые кубики.
Нужно было подготовить станцию, опять же отслеживать столкновения, какой-то механизм, показывающий ход ремонта и определять другие сопутствующие детали.
На этот раз мы использовали PhysicTrigger с маской, настроенной только для определенных кубов.
Ход строительства я решил отображать кубиками одного цвета, расставив их по кругу у основания станции и отключив.
При попадании куба на триггер станции ее физическое тело отключается (сам визуальный куб продолжает висеть еще некоторое время, как будто попал в какое-то поле), и станция показывает один из своих кубов, пока все не заполнятся.
Как только это произойдет, на станции появится свечение и продлится соединительная линия до предыдущей станции.
Кроме того, каждая станция содержит ссылку на следующую, которую необходимо сделать активной.
И вместо самого последнего активируется телепорт в водный мир, который изначально неактивен.
Возле первой ремонтируемой станции разбросано несколько кубиков, как некий намек на желаемое от игрока действие.
Демо версия
Ниже представлен видеоролик геймплея последней версии прототипа 01_02. Архив с демкой весит 714МБ.
Он работает на 64-битной Windows и доступен для скачивания на странице itch.io (используется движок Unigine, поэтому системные требования не самые маленькие): thenonsense.itch.io/tantramantra 
Больше картинок
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Какая машина вам понравилась? 33,33% Летающий 3 33,33% Вызов других машин 3 44,44% С фонарями 4 44,44% Стеклянный 4 44,44% Рогатый 4 44,44% С цветком 4 33,33% Белый 3 44,44% Черный 4 33,33% Красный 3 33,33% Зеленый 3 33,33% Большой 3 44,44 % Маленький 4 44,44% С частицами 4 33,33% Светящийся 3 33,33% Кость 3 33,33% Металл 3 55,56% С технологическими колесами 5 55,56% С биологическими колесами 5 Проголосовали 9 пользователей.
15 пользователей воздержались.
Теги: #Разработка игр #Игры и игровые консоли #Игровой дизайн #Прототипирование #gamedev #C++ #дизайн #демо #unigine #indie #создание игр #концепции
-
Разъяснение Мыслей О Сетевом Обучении
19 Oct, 24 -
Как Зарабатывать Деньги В Интернете
19 Oct, 24
