webdonsk.ruКак сделать физический движок
Добавил пользователь Morpheus Обновлено: 10.09.2024
Василий разрабатывает игровые движки с 16 лет, с того момента, как дома появился первый ZX Spectrum, — и не представляет, чем еще мог бы заниматься в жизни. Айтишник выпускал мобильные и веб-игры, создавая их в одиночку, а также написал несколько движков (вот один из них). В рамках спецпроекта Onliner и BGaming мы узнали у разработчика этой компании, как устроен игровой движок и что он собой представляет.
Как выглядит движок
— Простым языком: движок игры — что это такое?
— Изначально у тебя есть язык программирования, в котором ты можешь сделать все что угодно. Но примерно ко второй игре становится ясно, что многие вещи повторяются из игры в игру, и чтобы не писать их повторно, ты объединяешь их в некий набор библиотек и инструментов, который и принято называть движком. Хороший движок избавляет от необходимости делать то, что уже сделано раньше, но в то же время оставляет тебе свободу действий. Продвинутый и удобный движок — это не просто набор библиотек, понятный только программистам. Это инструмент, в котором можно увидеть и отредактировать игру. То есть это, если сильно утрировать, как Photoshop или Word, только для игр. Такого пути при разработке движка я всегда придерживался.
Обычно в движке есть окно, в котором ты видишь то же, что и игрок, когда запускает твою игру. С тем лишь отличием, что ты можешь выделить любой объект и изменить его свойства, переставить в другое место. Есть окно, в котором показана иерархия игровых объектов в виде дерева или списка. По большому счету эти два окна позволяют тебе собрать игру как из кирпичей.
Иногда эти кирпичи, то есть объекты игрового мира, нужно настроить, придать им свою логику и свойства. Выглядит это так: создаешь свой новый тип игрового объекта, который наследует свойства одного из стандартных объектов, и дописываешь ему свою логику — то, как объект ведет себя в игре при взаимодействии с другими объектами. Нажимаешь кнопку запуска — и смотришь результат.
— По такому принципу можно любую игру сделать?
— Визуально вся игра сводится к тому, что каждый объект перед каждым кадром обновляет свою позицию. У него есть координаты — X и Y. Если к X прибавить 1, объект сдвинется на один пиксель. А если на каждом кадре прибавлять к X по единице, то объект будет непрерывно двигаться вправо. Вот и все: когда в 16 лет я узнал, как вывести произвольную букву в произвольную точку экрана, мне хватило, чтобы уйти в это с головой. Я составлял человечков из букв, которые бегали по лестницам, собирали монеты и так далее.
Другая, обычная для игры задача — определить момент, когда два объекта друг друга коснулись. В упрощенном виде касание — это когда расстояние между центрами двух объектов стало меньше, чем размер этих объектов. Пересеклись — соответственно, есть касание: наносим урон, добавляем на экран взрывы. Во многих движках это реализовано, и тебе остается написать, что именно произойдет при столкновении.
Универсальность — не всегда хорошо
— Почему нет движков, которые подошли бы под любой игровой жанр?
— Идей очень много, и они всегда выходят за пределы того, на что рассчитывал разработчик движка. Вообще, универсальный движок сводится к простоте: чем меньше функционала, тем он универсальнее. А когда пытаешься все охватить, то универсальность, наоборот, страдает.
— Бывает так, что движок заточен под определенный жанр? Например, для стратегии подойдет, а для гонок — вообще нет.
— Одни заточены, другие нет. Это зависит от количества реализованного в них функционала. Например, есть движок для текстовых адвенчур. Понятно, что там можешь сделать только текстовую адвенчуру. Но вообще, возможности движка ограничены только фантазией разработчика, который его использует: если горишь этим и хочешь что-то сделать, то даже в простейшем движке реализуешь интересные вещи.
В целом при разработке самое главное — не ставить глобальные задачи, пытаясь все охватить. И не пытаться в новой для тебя задаче с ходу сделать что-то фундаментальное и долгоживущее. Нужно подходить экспериментально: двинулся куда-то, понял, что есть проблема, — попробуй другой путь. Если видишь, что идея рабочая — можешь проработать ее детальнее. Свой игровой редактор я создал не с первой попытки. Было множество версий на разных языках, были и тупиковые версии, которые я бросал через две недели после начала разработки, так как понимал, что подход нежизнеспособный.
Кстати, важный момент в любой разработке — скорость итерации, то есть насколько быстро ты увидишь внесенные тобой изменения в действии. Бывают проекты, в которых на компиляцию и запуск игры уходит минута и больше, а бывают такие, где хватает 1—2 секунд. И простая математика: ты сразу становишься в 15—30 раз эффективнее. Даже не в том смысле, что сделаешь в 30 раз больше работы, а в том, что получишь в 30 раз меньше стресса и при этом будешь полон сил двигаться дальше.
— От чего зависит популярность движка? Например, CryEngine, несмотря на технологичность, почти нигде не использовался, а Unreal Engine много где встречается.
— Движков тысячи, есть удобные и не очень. У человека есть какое свойство: когда ты смотришь на что-то новое с большим количеством кнопок — оно тебе всегда не нравится. Допустим, работаешь год в 3ds Max, потом переходишь на Blender — кажется, что это полная муть и его инопланетяне придумали. Только дня через три начинаешь понимать, что к чему. То есть привыкание, инертность играют большую роль. Допустим, появился новый движок — он может быть объективно удобным и хорошим. Но кто захочет уйти от чего-то привычного и понятного? А когда речь идет о крупной компании, все в разы сложнее, тем более если на кону большие деньги.
— Почему многие студии делают собственные движки? Не проще ли лицензировать существующий?
Года три назад при переходе с Flash на HTML я около месяца просидел на Unity в качестве эксперимента. На мой вкус, там слишком много рутинных вещей, игровые объекты избыточно раздроблены на подкомпоненты, и 90% твоего кода занимают связи между этими подкомпонентами. Другие вещи, которые я считаю важными, реализованы не идеальным образом. Возможно, тут сыграла роль та самая человеческая инертность.
— Ты разрабатываешь только движок или игрой тоже занимаешься?
Если делать движок отдельно от игры, то ты не сможешь до конца понять, что именно нужно разработчику, и то, что ты сделаешь, не будет таким удобным и полезным, каким могло бы быть.
Принципы оптимизации
— Как выглядит оптимизация под разные платформы, железо?
— Устройств много, и в первую очередь нужно думать о самых слабых девайсах. Наиболее простой способ оптимизации выглядит так. Допустим, у тебя есть набор анимаций, частиц. Их можно сделать в десять раз меньше по количеству. На маленьком экране разницу даже не заметишь, а нагрузка на железо серьезно уменьшится.
Даже если у тебя игра уже работает максимально быстро и дополнительная оптимизация не дает видимого глазу эффекта, есть батарея телефона, которая будет греться и быстро садиться, если не подойти к вопросу оптимизации с душой или хотя бы с серьезными намерениями.
— Разработчик игры должен быть технарем?
— Человек, отвечающий за программирование, — да. Для художника это не обязательно, но когда он имеет опыт разработки игр собственными руками — это очень сильно помогает и экономит время. Он может заранее организовать слои максимально близко к тому виду, в каком они будут организованы в игре. Не потратит время на то, что будет в любом случае вырезано и реализовано программно.
Даже в отрыве от арта и кода игра — это сложная инженерная система, в которой пересекается множество идей и механик. Если ты не видишь все эти пересечения наперед, всплывает множество неожиданных переделок, которые дорого обходятся.
— По каким признакам можно понять, хороший в игре движок или нет?
— Если движок хороший, то его присутствие в игре не заметно. Бывает, вижу какую-нибудь известную игру, а спустя годы узнаю, что ее сделали в GameMaker.
В 3D-играх возможны некоторые особенности в освещении и цветообработке. Но в случае с 2D все обычно сводится к отрисовке картинки такой, какая она есть, и движок не оставляет своих признаков. У меня была игра Iron Impact: она сделана в 2D с динамическим освещением, то есть каждый спрайт был не плоским, а имел карту высот и нормалей. И если бы на этом моем движке мне показали другую игру, я бы его узнал.
— Что посоветуешь разработчикам игровых движков?
— Начинайте с игры и ее идеи, а не движка. Нельзя сделать движок, а потом думать, какую игру на нем разработать. Только в процессе создания игры будет понятно, в какую сторону двигаться по расширению движка, как его адаптировать и оптимизировать.
Главный совет — не делайте чего-то глобального. Даже если уверены в своих силах, лучше сделать что-то простое, тогда будет шанс закончить дело и выпустить игру. Самое сложное — не начать разработку, а закончить ее. Ведь как все идет: за второй день разработки ты удвоишь объем сделанной работы, и это очень много. А день разработки после трех месяцев работы — это лишь один процент от уже проделанного. Чувство прогресса замедляется, и радость от разработки улетучивается.
BGaming — быстрорастущий игровой провайдер с белорусскими корнями, предлагающий качественные продукты для онлайн-казино по всему миру.
Игрок и его выбор — главная ценность компании, поэтому мы постоянно изучаем и анализируем потребности и предпочтения аудитории, чтобы создавать яркие и запоминающиеся продукты. Студия разрабатывает онлайн-игры на стыке gambling и gaming, в которых идеально сбалансированы визуальные эффекты и математика. Это возможно благодаря команде экспертов с безграничной энергией и более чем 20-летним опытом в индустрии.
Есть о чем рассказать? Пишите в наш телеграм-бот. Это анонимно и быстро
Из этого туториала вы узнаете, как создать игру с использованием Unity3D! Попутно вы узнаете о важности использования физического движка и о том, как это сэкономит бесчисленные часы ручной анимации. Читай дальше!
Какой современный игровой движок будет полным без физического движка? Каждый текущий игровой движок, будь то 3D или 2D, имеет какую-то физическую библиотеку, и Unity не является исключением. Физика в реальном времени идеально подходит для моделирования сложных взаимодействий между объектами в вашей игре. Физический движок может сэкономить много ручного кодирования и анимации для достижения реалистичного движения, может упростить выполнение обнаружения ударов и быстро внедрить множество новых игровых механизмов в ваши игры.
В этом уроке мы будем использовать физический движок в Unity для создания трехмерной игры, похожей на BoomBlox и Angry Birds. Мы научимся придавать объектам разные физические свойства, делать их способными к столкновению и даже позволять им разрушаться, если столкновения достаточно сильны.
Что такое физический движок?
Настройка проекта
Коллайдеры
Удобно, когда бы ни создавался GameObject, ему автоматически назначается соответствующий коллайдер. Куб получает BoxCollider, Сфера получает SphereCollider, Цилиндр получает CapsuleCollider и так далее.
В конечном итоге нам понадобится несколько блоков, чтобы сбить:
Если мы нажмем Play, блок ничего не сделает. Хотя у него есть коллайдер, у него нет твердого тела, поэтому на него не влияют никакие физические силы.
Rigidbodies
Твердое тело — самый важный элемент физического движка. Любой GameObject, к которому он прикреплен, включается в симуляцию.
По умолчанию на твёрдое тело влияют сила тяжести и сопротивление воздуха, также известное как сопротивление. Если мы нажмем Play, блок начнет падать, ускоряться и в конечном итоге достигать конечной скорости, когда сила тяжести и сопротивление уравниваются.
Построить структуру
Нам нужно создать еще несколько элементов, чтобы построить должный уровень. Во-первых, давайте добавим немного земли, чтобы блок мог приземлиться.
Земля автоматически получит MeshCollider, который будет препятствовать прохождению любых твердых тел через нее. Нажмите Play, и блок должен упасть и осесть на землю.
Теперь нам нужна структура, чтобы сбить с ног. Выберите блок и нажмите Ctrl + D в Windows или Cmd + D в OSX, чтобы дублировать блок несколько раз. Используйте инструменты масштабирования и перемещения, чтобы растянуть и расположить блоки примерно в той же конфигурации, что и на рисунке ниже.
Основной целью было выбрать наиболее производительный, удобный и легковесный движок для разработки игр и приложений с использованием симуляции физики.
Является портом Bullet physics engine на javascript с использованием компилятора Emscripten и по заявлению разработчиков обладает практически идентичным функционалом. Функционал Ammo.js действительно обширен. Для работы с ним понадобится отдельная библиотека для визуализации. Чаще всего используется Three.js. При этом каждый цикл перерисовки придётся вручную синхронизировать положение и вращение каждого объекта на сцене с его физической моделью, движок не делает это автоматически.
Что касается производительности, она не слишком высокая, но и заметных просадок fps в большинстве проектов не будет.
API иногда может быть довольно запутанным и документация не особо помогает.
В целом очень хороший инструмент, который продолжает развиваться и дорабатываться.
Cannon.js — легковесный физический движок с открытым исходным кодом. В отличие от предыдущего изначально писался на javascript и позволяет использовать все его возможности и оптимизации. На самом деле сложно сказать, является ли это плюсом или минусом, поскольку скомпилированный код может быть куда эффективнее написанного с нуля. Тем не менее cannon.js по сравнению с ammo.js считается более компактным, более производительным, а также более легким для понимания, но при этом он не обладает таким количеством функций. На практике их производительность часто примерно одинаковая.
Процесс работы с движком довольно прост:
Для работы также требуется сторонняя графическая библиотека, причём придётся каждый цикл отрисовки вручную перемещать соответствующий объект на сцене на место расположения физического объекта.
В данный момент движок практически не развивается, последняя активность в репозитории проекта более 2 лет назад, а на тот момент движок ещё только начинал развиваться, так что в некоторых местах он может оказаться не проработан.
Oimo.js — переписанная на чистом javascript версия движка OimoPhysics. В сравнении с другими решениями, обладает очень хорошей производительностью и точностью, однако поддерживает только примитивную геометрию (кубы и сферы). Включён в состав Babylon.js — фреймворка для визуализации 2D и 3D графики, поэтому каких то дополнительных библиотек не потребуется.
Большим минусом движка является не очень качественная документация, но разработчики продолжают работу над ней.
На данный момент движок продолжает развиваться.
box2dweb — это порт box2d на javascript. Как понятно из названия, специализируется на симуляции 2D физики. Несмотря на это, box2dweb — довольно мощный инструмент, который нисколько не отстаёт от своих трёхмерных аналогов. Например движок включает крайне удобные системы обнаружения коллизий и имитации соединений (constraint).
Что касается производительности, нужно очень постараться писать не оптимальный код, чтобы появились просадки fps.
Из плюсов так же стоит упомянуть простоту API и удобную документацию.
Unity имеет встроенную симуляцию физики, для этого используется встроенный движок PhysX от NVIDIA. PhysX даёт обширный функционал по симуляции физики твёрдых тел, жидкостей и тканей, обладает очень хорошей производительностью, хотя многие плюсы аннулируются при работе на графических ускорителях не от NVIDIA. Крайне приятным фактом является то, что с 3 декабря 2018 исходный код движка доступен под открытой лицензией BSD-3, тем не менее движок слишком сложный, чтобы пытаться переписывать его под себя или разбираться в его устройстве, так что тут лучше поможет документация.
В этом списке Unity оказался, поскольку существует возможность собрать проект на нём под WebGL. Для этого достаточно в настройках сборки выбрать соответствующий пункт.
Сравним производительность движков по тому, как они справляются с обработкой коллизий большого количества объектов. Используемый браузер — Firefox 64.0.2 x64.
По результатам тестов Oimo.js показывает лучшую производительность.
Разумеется, эти результаты не дают адекватной оценки производительности, так как зависят от множества сторонних факторов, но полноценное исследование потребовало бы куда больше времени да и я такой цели себе не ставил. Кроме того заметно, что производительность всех сравниваемых движков довольно невелика, так что данные решения подойдут для написания далеко не каждой игры, но зато хорошо подойдут для создания небольших демо.
Попытки были, средней степени успешности, до LIMBO не дотягивает.
В Limbo, AFAIK, за физику отвечает Box2D (что совсем неудивительно). Поэтому единственный правильный ответ на ОП: никак, взять готовый де-факто стандартный движок.
Скукота же. Может ему в кайф писать движок.
В копилку неправильных советов: изучи common lisp.
Берешь Box2D или Nape, смотришь что там в потрохах, пишешь свой, более хороший.
А вообще держи в курсе. Сам хотел когда-то написать, но времени не было :)
Читайте также: