Физика в компьютерных играх проект. Примеры превосходной игровой физики. Упрощённая физика машин и персонажей в Grand Theft Auto V

Источник: codingclub

ВОЗМОЖНОСТИ СУЩЕСТВУЮЩИХ ДВИЖКОВ

НЕ ИМЕЕТ СМЫСЛА МНОГО ГОВОРИТЬ О ТОМ, ЧТО В СОВРЕМЕННЫХ ИГРАХ ОЧЕНЬ ЧАСТО ИСПОЛЬЗУЮТСЯ ФИЗИЧЕСКИЕ СИМУЛЯЦИИ РАЗЛИЧНОГО РОДА. ФИЗИКА УЖЕ ДАВНО (И НАДОЛГО) ПРОТОПТАЛА ДОРОЖКУ В СИМУЛЯТОРЫ, В ОСНОВНОМ АВТОМОБИЛЬНЫЕ

Физика используется и как основной элемент геймплея (хардкорные симуляторы), и как средства к получению дополнительных эмоций у игрока (различного рода разрушения). Также есть ряд жанров, в которых массовое применение физики началось сравнительно недавно - это прежде всего шутеры и игры с видом от третьего лица. Спектр использования физических эффектов в них очень широк: от достаточно простых rag-dolls и пинания ящиков до попыток завязать часть геймплея на физику (Half-life 2, Psi-ops и т.д.). Кроме всего перечисленного, существует ряд игровых жанров, в которых физика не нужна в принципе, к примеру в пошаговых глобальных стратегиях. В целом на сегодня физика в играх является важнейшим элементом, но несмотря на это раскручена не так, как графика.

немного терминологии

физический движок (фд)

ФД - библиотека, которая рассчитывает физические взаимодействия между объектами игрового мира (симулируется физика, описываемая законами Ньютона). Физические движки, используемые при разработке игр, как правило, не симулируют физические процессы игрового мира со 100% точностью, а лишь производят достаточно точную аппроксимацию физических законов. Современные игровые физические движки состоят из двух частей: подсистемы определения столкновений и подсистемы расчета физических взаимодействий.

подсистема определения столкновений

Основные два параметра подсистемы определения столкновений: скорость работы и точность определения столкновений. Недостаточная точность приводит к появлению разных артефактов, таких как перекрытие объектов, неопределение столкновений при существенно разных размерах и скоростях объектов и т.д. Для ускорения работы подсистемы столкновений используют различного рода разбиения пространства на подпространства, такие как quadtree (рекурсивное деление пространства на четыре подпространства) или осtree (деление на восемь подпространств), для снижения количества проверок столкновений. Системы столкновений работают дискретно - столкновения рассчитываются через определенные промежутки времени. Итак, такого рода системы могут приводить к тому, что столкновения с участием быстро движущихся объектов не фиксируются - для борьбы с подобного рода артефактами некоторые системы столкновений поддерживают так называемый continuous collision detection (CCD) (системы непрерывного отслеживания столкновений). Суть метода continuous collision detection заключается в том, что проверка столкновений между двумя объектами производится не между ними самими в дискретные моменты времени, а между вытянутыми объемами, которые представляют движение объектов в течение всего временного шага.

подсистема симуляции (пс)

ПС, помимо скорости работы, характеризуется таким параметром, как стабильность симуляции. Этот параметр влияет непосредственно на достоверность самой физической симуляции: если симуляция нестабильна, видны разные артефакты, например подергивающиеся объекты. Симуляция дискретна, то есть программист извне задает шаг времени, который необходимо рассчитать. От размера этого шага и зависит стабильность симуляции. Соответственно, чем больший размер шага позволяет устанавливать движок, тем лучше.

Подавляющее большинство физических движков может (с различным успехом) симулировать физику твердого тела (Rigid body simulation). Твердое тело - это тело, которое не меняет свою форму (к ним можно отнести кирпич, стол, стену и т.д.). На данный момент подавляющее большинство игр использует именно физику твердого тела, главным образом потому, что с приемлемой производительностью может обсчитываться лишь физика твердого тела. Для представления объема твердых тел, в зависимости от движка, могут использоваться как различные примитивные тела (прямоугольники, сферы, цилиндры, конусы и т.д.), так и более сложные (карты высот, выпуклые многогранники или невыпуклые многогранники). Если используются только примитивные тела, более сложные тела описываются с помощью аппроксимации примитивами. Для описания свойств твердых тел используется понятие материала, который описывается параметрами: коэффициент трения (может быть два: коэффициент трения покоя, который показывает, как тяжело сдвинуть тело, и коэффициент трения движения, который показывает, как тяжело удерживать тело в движении), упругость (сколько энергии остается после столкновения с другим телом). Помимо этих параметров, могут быть и другие. Твердое тело также имеет массу. Движение твердых тел описывается при помощи линейной, угловой скорости и ускорения. Хотя движки позволяют устанавливать эти параметры непосредственно, воздействия на тела, как правило, осуществляют при помощи приложения либо физических сил (влияют на ускорения тел), либо импульсов (влияют на скорости).

На базе физики твердого тела реализуется также физическое поведение персонажей и широко известный эффект тряпичной куклы (rag-doll), который заключается в том, что персонаж (чаще всего мертвый) падает вниз, как тряпичная кукла. Для реализации подобного рода поведения только твердых тел недостаточно. Используются так называемые сочленения (joint) или ограничения (constraint).

Джоинт - это точка, которая соединяет два твердых тела (соединение обычно задается относительно точки джоинта) и накладывает ограничения на положение тел в пространстве друг относительно друга или на скорости тел относительно друг друга. Типов джоинтов много (некоторые движки позволяют писать собственные). Для реализации рэгдолов используют ball-joint и hinge-joint. Ball-joint - это шарнирное соединение двух тел, оно ограничивает перемещение тел друг относительно друга и налагает ограничение на то, как повернуты тела относительно друг друга по трем осям (при помощи джоинтов такого типа в регдолле крепится плечо или голова к телу). Hinge-joint - это петельное соединение двух тел, которое ограничивает повороты тел относительно друг друга одной осью. В целом же спектр применения джоинтов очень широк и не ограничивается только созданием rag-dolls.

Помимо физики твердого тела, различные физические движки могут реализовывать дополнительные возможности: специальную поддержку симуляции движения автомобилей, симуляцию воды и прочих жидкостей, симуляцию тканей и одежды, симуляцию частиц, дополнительную поддержку для симуляции персонажей - высокоуровневые контроллеры персонажей, встроенную поддержку rag-dolls, поддержку анимации и т.д.

физика и разработка игры

Наличие физики в игре накладывает отпечаток на весь процесс разработки. В зависимости от того, каков объем и характер физических фич, могут быть затронуты практически все аспекты производственного процесса - от геймплея до контента.

Как делать физику - этот вопрос требует решения. На одном полюсе - решение о том, чтобы писать физику самостоятельно. На другом полюсе - покупка готового решения, которое полностью покроет спектр поставленных задач. Где-то посредине находится такой вариант: модифицировать существующий, но далеко не на 100% подходящий движок. Как и в остальных областях разработки ПО, данное решение зависит от множества факторов: наличия средств, наличия персонала, наличия подходящих решений и т.д.

В зависимости от выбора и требований к физике сложность разработки может значительно колебаться. Если же рассматривать одну и ту же игру с физикой и без нее, при прочих равных, то вариант с физикой (достаточно объемной) затронет всех участников производственного процесса. Наличие физики прежде всего влияет на архитектуру кода игры: введение такой сложной подсистемы влияет и на графику, и на искусственный интеллект, и даже на ввод пользователя.

Помимо архитектурных моментов, в команде разработчиков появляется новая роль - программист физики, который будет вынужден заниматься вопросами реализации воплощения физических фич (эта доля тяжелая и неблагодарная). Наличие физики повлияет и на геймдизайн. С одной стороны, можно будет добавлять различные физические геймлей-фичи, с другой стороны, появится дополнительная забота о том, как физика скажется на остальном геймплее. Также физика затрагивает и производство контента для игры: придется создавать физические модели объектов, настраивать материалы, rag-dolls и джоинты.

Добавление физики в игру усложняет процесс разработки продукта и требует дополнительных ресурсов.

обзор существующих решений

До недавнего времени ситуация на рынке физических движков была довольно стабильна. Существовало несколько бесплатных физических движков (разного качества), а также ряд коммерческих физических движков. Однако в ушедшем 2005 году компания AGEIA анонсировала первый в истории игровой индустрии ускоритель физики, который снимает с центрального процессора задачу расчета физики. Ускоритель пока еще не появился в продаже, но его создатели утверждают, что их продукт будет способен обсчитывать порядка 40 000 объектов (на данный момент количество физических объектов, обсчитываемых на ПК, составляет десятки).

Ниже рассмотрим основные физические движки, которые существуют на сегодня. Помимо чисто физических движков, существует масса игровых движков, которые содержат физические подсистемы, написанные поверх одной из библиотек (на www.devmaster.net/engines можно ознакомиться с игровыми движками).

PhysX (www. ageia.com, коммерческий)

Эта физическая технология предоставляется компанией AGEIA и как физический движок, и как АПИ для работы с их физическим ускорителем. На данный момент ряд игровых компаний заявили о поддержке этой технологии в своих продуктах (в том числе Unreal Engine).

Возможности PhysX:

СИМУЛЯЦИЯ ТВЕРДЫХ ТЕЛ, В КАЧЕСТВЕ ФИЗИЧЕСКОГО ПРЕДСТАВЛЕНИЯ МОГУТ ИСПОЛЬЗОВАТЬСЯ ПРИМИТИВЫ (ПЛОСКОСТИ, БОКСЫ, КАПСУЛЫ) И ВЫПУКЛЫЕ МНОГОУГОЛЬНИКИ, А ТАКЖЕ ИХ КОМБИНАЦИИ;

ПОЛНОСТЬЮ НАСТРАИВАЕМЫЕ ДЖОИНТЫ С ШЕСТЬЮ СТЕПЕНЯМИ СВОБОДЫ;

СИМУЛЯЦИЯ ЖИДКОСТЕЙ;

ФИЗИЧЕСКОЕ ВЗАИМОДЕЙСТВИЕ МЕЖДУ ЖИДКОСТЯМИ И ТВЕРДЫМИ ТЕЛАМИ;

КОНТРОЛЛЕРЫ ПЕРСОНАЖЕЙ (ПЕРСОНАЖ МОЖЕТ СОСТОЯТЬ ИЗ БОКСОВ И КАПСУЛ), ПОЗВОЛЯЮЩИЕ АВТОМАТИЧЕСКИ ПЕРЕМЕЩАТЬСЯ ПО ЛЕСТНИЦАМ;

АВТОМОБИЛИ НА ОСНОВЕ ТРЕЙСИНГА ЛУЧА;

ПОДДЕРЖКА НЕСКОЛЬКИХ СЦЕН;

СИСТЕМА СТОЛКНОВЕНИЯ ПОДДЕРЖИВАЕТ НЕПРЕРЫВНОЕ ОТСЛЕЖИВАНИЕ СТОЛКНОВЕНИЙ;

МУЛЬТИПЛАТФОРМЕННОСТЬ;

МНОГОПОТОЧНОСТЬ.

Havok (www.havok.com, коммерческий)

Один из старейших физических движков. На нем сделаны десятки игр (посмотреть их список можно по адресу www.havok.com/content/blogcategory/29/73). Недавно Havok анонсировал новую технологию расчета физики Havok FX, которая производит расчеты физики на видеокартах используя шейдеры 3.0.

Возможности Havok:

ФИЗИКА ТВЕРДОГО ТЕЛА;

ДЖОИНТЫ;

КОНТРОЛЛЕРЫ ПЕРСОНАЖЕЙ (ПОЗВОЛЯЮТ ПЕРСОНАЖАМ ПЕРЕМЕЩАТЬСЯ ПО ЛЕСТНИЦАМ);

МУЛЬТИПЛАТФОРМЕННОСТЬ;

МНОГОПОТОЧНОСТЬ.

Trueaxis (www.trueaxis.com)

Бесплатный для некоммерческого использования. Исходники закрыты.

Возможности:

ФИЗИКА ТВЕРДОГО ТЕЛА;

СИСТЕМА СТОЛКНОВЕНИЯ ПОДДЕРЖИВАЕТ НЕПРЕРЫВНОЕ ОТСЛЕЖИВАНИЕ СТОЛКНОВЕНИЙ;

В КАЧЕСТВЕ ПРЕДСТАВЛЕНИЯ МОГУТ ИСПОЛЬЗОВАТЬСЯ ВЫПУКЛЫЕ МНОГОУГОЛЬНИКИ, КАПСУЛЫ, ЦИЛИНДРЫ И СФЕРЫ;

ПОДДЕРЖКА СИМУЛЯЦИИ АВТОМОБИЛЕЙ;

ДЖОИНТЫ.

ODE (www.ode.org, BSD, исходники открыты)

Единственный в списке движок с открытыми исходниками, что позволяет ему служить в качестве базы для построения собственного физического движка (небезызвестный проект S.T.A.L.K.E.R. использует модифицированный ODE), а также просто для изучения того, как оно все внутри устроено. ODE очень часто используется различными игровыми движками в качестве физической подсистемы.

Возможности:

ФИЗИКА ТВЕРДОГО ТЕЛА;

ДЖОИНТЫ;

СИСТЕМА СТОЛКНОВЕНИЙ ОТДЕЛЕНА ОТ ФИЗИЧЕСКОЙ СИМУЛЯЦИИ, ЧТО ПОЗВОЛЯЕТ ИНТЕГРИРОВАТЬ ODE С РАЗНЫМИ СИСТЕМАМИ СТОЛКНОВЕНИЙ.

Tokamak (www.tokamakphysics.com, беcплатный, исходники закрыты)

Возможности:

ФИЗИКА ТВЕРДОГО ТЕЛА;

ДЖОИНТЫ (ВСЕГО ДВА ВИДА: BALL И HINGE - ДОСТАТОЧНО ДЛЯ ПОСТРОЕНИЯ RAG-DOLLS).

Newton (www.physicsengine.com, беcплатный, исходники закрыты)

Возможности:

СИСТЕМА СТОЛКНОВЕНИЯ ПОДДЕРЖИВАЕТ НЕПРЕРЫВНОЕ ОТСЛЕЖИВАНИЕ СТОЛКНОВЕНИЙ;

ФИЗИКА ТВЕРДОГО ТЕЛА;

ПОДДЕРЖКА СИМУЛЯЦИИ АВТОМОБИЛЕЙ.

физика на примере

Для практического примера возьмем демонстрационную программу из OPAL (open physics abstraction layer: http://ox.slug.louisville.edu/opal/wiki) - это открытый физический движок, предоставляющий единый высокоуровневый интерфейс для работы с другими физическими движками. На данный момент существует единственная реализация поверх ODE, в разработке находится оболочка над TrueAxis. Для работы необходимо скачать сам движок - ?download.

Нас интересует дема, которая находится в папке opal-0.3.1-srcsamplessimple и показывает базовые аспекты работы с физическим движком OPAL, демонстрируя работу с твердыми телами. В качестве визуализатора используется библиотека SDL (www.libsdl.org/index.php). Приложение состоит из единственного файла main.cpp и нескольких h-ков. При старте появляется статический бокс. При нажатии клавиши «пробел» на этот бокс падают твердые тела, представляемые при помощи различных примитивов. Рассмотрю файл main.cpp и прокомментирую те его части, которые относятся к физической симуляции.

набор глобальных переменных

std::vector gEntities;

opal::Simulator* gSimulator = NULL;

Переменная gSimulator типа opal::Simulator указывает на экземпляр физического движка OPAL. Тип opal::Simulator - собственно, и есть сам физический движок. Он инкапсулирует внутри систему расчета столкновений и подсистему расчета физики. Как правило, в приложении достаточно одного экземпляра физического движка. Подобного рода архитектура, при которой существует некий объект, содержащий информацию обо всех физических объектах игрового мира, и производит обсчет физики и используется практически во всех высокоуровневых физических движках.

Переменная gEntities содержит список сущностей типа opalSamples::Entity, которые имеют физическое представление. Сам класс и его наследники мало интересны, так как они в данной программе служат для отрисовки симулируемых объектов. В самом классе opalSamples::Entity интересует нас одно поле - opal::Solid* mSolid. Тип opal::Solid представляет твердое тело в физическом движке OPAL. Твердое тело обладает позицией, скоростью, ускорением и является базовой единицей симуляции - такого рода сущность есть в любом физическом движке. В данной программе для рисования сущности необходимо знать позицию твердого тела - эта информация получается путем вызова метода getTransform у mSolid.

содержимое функции main

gSimulator = opal::createSimulator();

gSimulator->setGravity(opal::Vec3r(0, (opal::real)-9.81, 0));

В первой строчке создаем экземпляр симулятора при помощи функции opal::createSimulator(). Во второй строчке устанавливаем силу гравитации для этого симулятора при помощи метода setGravity и передачи в качестве параметра вектора силы тяжести. Заметь, что можно задать гравитацию, отличную от земной, или установить ее равной нулю. С точки зрения физической симуляции, гравитация - это всего лишь одна из сил, действующих на тело, подобного рода метод применяют из соображений удобства и эффективности, так как, как правило, в симулируемом мире гравитация присутствует.

1. opal::Solid* platformSolid = gSimulator->createSolid();

2. platformSolid->setStatic(true);

3. opal::BoxShapeData boxShape;

4. boxShape.dimensions = gGroundDimensions;

5. platformSolid->addShape(boxShape);

В приведенном куске кода создаем объект в виде прямоугольной коробки, который служит в качестве земли. В первой строчке создаем твердое тело в нашем симуляторе (это твердое тело будет обрабатываться именно данным симулятором и никаким другим).

Во второй строчке делаем тело статическим, то есть таким, которое не может менять свою позицию (обладает бесконечной массой), но может взаимодействовать с другими физическими телами. Как правило, в играх такие статические тела используются для симуляции неподвижных объектов локаций, таких как земля, стены и т.д.

В третьей строчке создаем экземпляр структуры boxShape, которая описывает трехмерный прямоугольник (бокс).

В четвертой строчке устанавливаем его размеры по трем осям, а в пятой - устанавливаем этот прямоугольник в качестве объема для нашей земли, вызвав метод addShape. Заметь, что можно добавлять сколько угодно разных фигур (Shapes), описывая таким образом сложный объем. В OPAL, помимо боксов, в качестве объема можно использовать сферы, цилиндры, плоскости и многоугольники, причем и выпуклые, и невыпуклые. Все фигуры имеют, помимо специфичных для каждой фигуры параметров (как dimensions в нашем примере), ряд общих полей:

Matrix44r offset;

Material material;

Поле offset задает смещение фигуры относительно центра твердого тела, поле material задает свойства материала фигуры. В OPAL"е материал имеет следующие свойства:

hardness - от 0 до 1. Показывает, насколько допустимо перекрытие объемов тел.

friction - от 0 до 1, трение движения. Чем больше это значение, тем быстрее будет останавливаться движущееся тело.

bounciness - от 0 до 1, упругость. Чем больше значение, тем больше энергии будет поглощаться при соударении.

density - плотность материала. На основании этого параметра и объема фигуры вычисляется масса фигуры.

основной цикл программы (вернее, те его части, которые представляют интерес в контексте рассматриваемого вопроса)

opal::real dt = (opal::real)timer.getElapsedSeconds();

gQuit = processInput();

gSimulator->simulate(dt);

Нам интереснее всего вот эта строчка:

gSimulator->simulate(dt);

В метод simulate передаем единственный параметр - время, которое прошло в «физическом мире». Именно внутри этого вызова происходит расчет столкновений и расчет взаимодействия физических объектов, происходит обновление позиций, скоростей и т.д.

gSimulator->destroy();

Заключительная строчка программы вызывает метод destroy объекта-симулятора, тем самым освобождая все ресурсы, занятые им, и уничтожая все физические объекты, созданные через методы симулятора, подобные createSolid.

В примере я рассмотрел весьма простое приложение. В реальной игре больше задач, эти задачи сложнее. Тем не менее, даже если судить по этому приложению, можно сказать, что на сегодня не нужно быть специалистом по высшей математике и физике только для того, чтобы писать приложения, включающие в себя физические симуляции.

  • Tutorial

Мой странный творческий путь занес меня в разработку игр. Благодаря отличной студенческой программе от IT-компании, название которой СостоИт из одной Греческой МАленькой буквы, сотрудничающей с нашим университетом, удалось собрать команду, родить документацию и наладить Agile разработку игры под присмотром высококлассного QA-инженера (здравствуйте, Анна!)

Без особо долгих размышлений, в качестве движка был выбран Unity. Это замечательный движок, на котором действительно быстро и легко можно сделать очень плохую игру, в которую, в здравом уме, никто и никогда не будет играть. Чтобы создать хорошую игру, все же придется перелопатить документацию, вникнуть в некоторые особенности и набраться опыта разработки.

Наша игра использовала физический движок неожиданным для него способом, что породило множество проблем с производительностью на мобильных платформах. В этой статье, на примере нашей игры, описана моя борьба с физическим движком и все те особенности его работы, которые были замечены на пути к жизнеспособной бета-версии.

Игра

Гифка с игрой


Пару слов о том, как она сделана.
Сделана с помощью Blender и пары скриптов на питоне. На время съемки, в углу экрана находились 16 квадратиков, цвет которых кодировал 32 бита числа с плавающей запятой - вращение телефона в данный момент времени. R, G - данные, B - четность. 0 - 0, 255 - 1. Снятое на компьютере видео разбивалось на кадры с помощью ffmpeg, каждому кадру рендера в соответствие ставился расшифрованный угол. Такой формат позволил пережить любое сжатие в процессе съемки и поборол тот факт, что все программы имеют несколько разные представления о течении времени. В реальности игра играется так же как и на рендере.


Самолетик летит по бесконечной и непредсказуемой пещере, в которой есть бонусы, всякие монетки и враги, в которых можно стрелять самонаводящимися ракетами. Врезался в стену - сразу проиграл.
Отличительная особенность игры в том, что уровень прибит к горизонту и управление в ней гироскопическое, причем, абсолютное. Наклонил телефон на 45 градусов - самолетик полетел под углом 45 градусов. Нужно сделать мертвую петлю - придется крутить планшет. Никакой чувствительности нет, только хардкор.
Выделим две основные и очевидные проблемы для разработчика:
Проблема 1: Бесконечность
Unity хранит и обрабатывает координаты объектов в виде обычных 32-битных float, имеющих точность где-то до 6 знака после запятой. Проблема в том, что игра у нас бесконечная и, если мы достаточно долго будем лететь, начнутся различного рода безумные баги, вплоть до телепортации сквозь стены. Есть несколько подходов к решению этой проблемы:
  1. Игнорирование. В Minecraft, например, ошибки округления лишь сделали игру интереснее, породив феномен «Далеких Земель» .
  2. Телепортация в (0;0;0) при слишком сильном удалении самолетика от начала координат.
  3. Смена точки отсчета. Движется не самолет, а уровень вокруг него.
В нашем случае, единственный допустимый вариант - третий, который и был реализован. О реализации - чуть позже.
Первый - игнорирование - абсолютно недопустим. Создание робота, который сможет вечно играть в нашу игру - интересная (и весьма простая) задача, которую кто-нибудь решит. Да и обычных корейских игроков недооценивать не стоит - самолетик быстрый, уровень генерируется непредсказуемо. И если до прохождений сквозь стены лететь и лететь, то куда более точная стрельба начнет очевидно подглючивать уже через 5 минут полета.
Второй - телепортация игрока и всего мира - ставит мобильные устройства на колени, в некоторых случаях - где-то на полсекунды. Это очень заметно, а потому - недопустимо. Но это вполне приемлемый вариант для простеньких бесконечных игр для ПК.
Проблема 2: Генерация уровня

Есть несколько основных подходов к строительству endless runner"ов:

  1. Использование готовых сегментов уровня, которые стыкуются случайным образом. Так сделано, например, в Subway Surfers. Это просто реализовать, но игрок к этому быстро привыкает и знает, к чему готовиться, что скучно.
  2. Уровень - просто прямая, на которой случайным образом расставляются препятствия. Так сделано в Joypack Joyride и Temple Run. В нашем случае, это сильно ограничило бы количество маневров.
  3. Все генерируется случайным образом. Самый сложный, непредсказуемый и интересный для игрока вариант.
Конечно же, мы выбрали самый сложный вариант. В его сердце находится весьма сложная машина состояний, которая выполняет по ним случайные переходы. Но в рамках данной статьи интересен не механизм, а процесс генерации уровня и его организация, с учетом выбранной точки отсчета.
Структура уровня

Летим мы в пещере, она имеет пол и потолок - пару блоков, элементарных строительных единиц. Блоки объединяются в сегменты, которые бесшовно стыкуются друг с другом. Сегменты, как единое целое, вращаются вокруг самолета и двигаются по его вектору скорости, создавая иллюзию полета. Если сегмент выходит из поля зрения камеры - он очищается от блоков, пристыковывается к последнему сегменту уровня и заполняется новыми блоками, согласно указаниям генератора. Совокупность таких сегментов - и есть уровень.

Опытные Unity-разработчики могли вполне оправданно поморщиться, прикинув объем работ и все возможные подводные камни. Но на словах все просто, а опыта разработки у меня не было…

Основные Законы Физики в Unity

За месяц разработки, экспериментов и чтения документации, я выделил три основных закона физики в Unity. Их можно нарушать, но плата за нарушение - производительность. Движок никак не будет предупреждать вас о допущенной ошибке, а без профайлера вы можете никогда о них и не узнать. Несоблюдение этих законов может замедлить вашу игру в десятки раз. Как я понял, нарушение любого закона приводит к тому, что физический движок помечает коллайдер-нарушитель как некорректный и пересоздает его на объекте, с последующим пересчетом физики:
1. Коллайдеры не должны двигаться, вращаться, включаться\выключаться и менять размер.
Как только вы добавили коллайдер на объект - забудьте про какое-либо воздействие на него или объекты, в которых он содержится. Обычный коллайдер - исключительно статический объект. Дерево, например, может быть с одним коллайдером. Если дерево может упасть на игрока - дерево будет падать вместе с производительностью. Если это дерево растет из волшебного питательного облака, которое коллайдера не имеет, но может перемещаться - это будет сопровождаться падением производительности.
2. Если объект движется или вращается - он должен быть твердым телом т.е. иметь компонент Rigidbody.
Про это написано в документации, да. Которую не обязательно вдумчиво читать, чтобы начать делать игру, потому Unity очень прост и интуитивно понятен.
Rigidbody меняют отношение физического движка к объекту. На него начинают воздействовать внешние силы, он может иметь линейную и угловую скорости, а самое главное - твердое тело может двигаться и вращаться средствами физического движка, не вызывая полный пересчет физики.
Существует два типа твердых тел - обычные и кинематические. Обычные тела взаимодействуют друг с другом и обычными коллайдерами - одно тело не может пройти сквозь другое. Кинематические тела следуют упрощенным правилам симуляции - на них не воздействуют никакие внешние силы, гравитация - в том числе. Они свободно могут проходить друг через друга и коллайдеры, а вот обычные твердые тела они отталкивают, как будто имея бесконечную массу.
Если объекты не жалко отдать под контроль физического движка - используйте обычные твердые тела. Например, если вам нужно красиво скатить камни со скалы. Если ваши скрипты или аниматоры управляют объектом напрямую - используйте кинематические тела, так вам не придется постоянно бороться с движком и случайными столкновениями объектов. Например, если у вас анимированный персонаж или управляемая ракета, взрывающаяся при контакте с чем-то.
3. Если объект является твердым телом - двигаться и вращаться он должен через методы твердого тела.
Забудьте про прямое обращение к Transform"у объекта сразу же после добавления к нему коллайдера. Отныне и навсегда, Transform - ваш враг и убийца производительности. Перед тем как написать transform.position =… или transform.eulerAngles = ..., произнесите фразу «я сейчас абсолютно четко понимаю, что делаю, меня устраивают те тормоза, которые будут вызваны этой строкой». Не забывайте про иерархические связи: если вы, вдруг, сдвинете объект, содержащий твердые тела - произойдет пересчет физики.
Есть три уровня управления твердым телом:
- Самый высокий и, следовательно, естественный, уровень - через силы. Это методы AddForce и AddTorque. Физический движок учтет массу тела и правильно посчитает результирующую скорость. Все взаимодействия тел происходят на этом уровне.
- Средний уровень - изменение скоростей. Это свойства velocity и angularVelocity. На их основе вычисляются силы, влияющие на тела при их взаимодействии, а также, очевидно, их положения в следующий момент времени. Если у твердого тела очень маленькая скорость - оно «засыпает», для экономии ресурсов.
- Самый низкий уровень - непосредственно координаты объекта и его ориентация в пространстве. Это методы MovePosition и MoveRotation. На следующей итерации вычисления физики (это важно, поскольку каждый последующий вызов метода в рамках одного кадра заменяет вызов предыдущего) они выполняют телепортацию объекта в новое положение, после которой он живет как раньше. В нашей игре используется именно этот уровень, и только он, потому что он предоставляет полный контроль над объектом.

Что остается за бортом? Включение\выключение объекта и масштаб. Я не знаю, есть ли способ изменить размер объекта, не смущая движок. Вполне возможно, что нет. Выключение объекта проходит безболезненно, а включение… да, вызывает пересчет физики, в окрестностях включенного объекта. Поэтому старайтесь не включать одновременно слишком много объектов, растяните этот процесс во времени, чтобы пользователь не заметил.

Есть закон, не влияющий на производительность, но влияющий на работоспособность: твердое тело не может быть частью твердого тела. Родительский объект будет доминировать, поэтому ребенок будет или стоять на месте относительно родителя, или вести себя непредсказуемо и неправильно.

Есть еще одна особенность Unity, не относящаяся к физике, но достойная упоминания: динамическое создание и удаление объектов через методы Instantiate/Destroy - БЕЗУМНО медленный процесс. Я боюсь себе даже представить, что там происходит под капотом во время создания объекта. Если вам нужно создавать и удалять что-то динамически - используйте фабрики и заправляйте их нужными объектами во время загрузки игры. Instantiate должен вызываться в крайнем случае - если у фабрики вдруг закончились свободные объекты, а про Destroy забудьте навсегда - все созданное должно использоваться повторно.

Применение законов на практике

(в этом разделе находится ход рассуждений при создании игры и ее особенности)

Уровень, очевидно, должен вращаться и двигаться.
Облегчим себе жизнь навечно, разместив ось вращения уровня - самолетик - в начале координат. Теперь мы сможем вычислять расстояние от точки до него, вычисляя длину вектора координат точки. Мелочь, а приятно.
Совместное движение объектов легко реализуется через иерархию объектов в Unity, потому что дети являются частью родителя. Например, описанная структура уровня логично реализуется следующим образом:
- Ось вращения
- - \ Уровень
- - - \ Сегмент 1
- - - - \ Блок 1 (Collider)
- - - - \ ...
- - - - \ Блок N
- - - \ Сегмент 2 ...
- - - \ Сегмент 3 ...
- - - \ Сегмент 4 ...
(Можно даже обойтись без объекта уровня)

Скрипт на оси получает данные с гироскопа и выставляет ей соответствующий угол… И нарушает сразу множество правил, потому что вращение передастся по иерархии на коллайдеры, что сведет физический движок с ума. Придется делать ось твердым телом и вращать ее через соответствующий метод. Но что с движением уровня? Очевидно, что ось вращения и объект уровня перемещаться не будут, каждый сегмент нужно двигать персонально, иначе мы сталкиваемся с проблемой бесконечности. Значит, твердыми телами должны быть сегменты. Но у нас уже есть твердое тело выше в иерархии и твердое тело не может быть частью твердого тела. Логичная и элегантная иерархия не подходит, все придется делать руками - и вращение, и перемещение, без использования объекта для оси вращения. Будьте готовы к такому, если у вас уникальные геймплейные фичи.

Если двигать непосредственно сегменты пришлось бы и так, то вращать их придется вынужденно. Основная сложность в том, что в физическом движке Unity нет метода «вращать объект вокруг произвольной точки» (он есть у Transform, но не искушайтесь). Есть только «вращать вокруг своего центра». Это логично, потому что вращение вокруг произвольной оси - одновременно и вращение, и движение, а это две разные операции. Но его можно имитировать. Сначала вращаем сегмент вокруг своей оси, потом вращаем координаты «своей оси» вокруг самолета. Благодаря тому, что самолет у нас в начале координат, не придется вспоминать даже школьную геометрию и лезть в википедию, в Unity уже все есть. Достаточно перевести угол поворота в кватернион и умножить его на координаты точки. Кстати, узнал я об этом прямо во время написания статьи, до этого использовалась матрица поворота.

У нас есть враги, которые отталкивают самолет в стену, надеясь убить. Есть щит, который отталкивает самолет от стен, помогая выжить. Реализовано это тривиально - есть вектор смещения, который каждый кадр прибавляется к координатам каждого сегмента и сбрасывается после этого. Любой желающий пнуть самолетик, через специальный метод, может оставить вектор своего пинка, который прибавится к этому вектору смещения.

В конечном итоге, настоящие координаты сегмента, каждый кадр, вычисляются центром управления движением уровня как-то так:
Vector3 position = segment.CachedRigidbody.position; Vector3 deltaPos = Time.deltaTime * Vector3.left * settings.Speed; segment.truePosition = Quaternion.Euler(0, 0, deltaAngle) * (position + deltaPos + movementOffset);
После всех вычислений и костылей, необходимых для работы точной стыковки сегментов при регенерации, segment.truePosition отправляется в метод MovePosition твердого тела сегмента.

Выводы

Насколько все это быстро работает? На старых флагманах - Nexus 5 и LG G2 - игра летает на 60 FPS, с еле заметной просадкой во время включения новых коллайдеров во время генерации сегмента (это неизбежно и никак не обходится) и выдвигания червяков из земли (можно нагородить какой-то ад, чтобы это обойти, но сейчас там осознанное нарушение третьего закона). 40 стабильных FPS выдает любое устройство с гироскопом, которое нам попадалось. Без знания и учета всех законов, производительность была, мягко сказать, неудовлетворительной и телефоны перегревались. Настолько, что я думал написать свой простенький специализированный движок для 2д-физики. К счастью, физика в Unity оказалось достаточно гибкой, чтобы все проблемы можно было обойти и создать уникальную игру, достаточно было лишь пары недель экспериментов.

Теперь, зная все главные подводные камни физического движка Unity, вы сможете быстро склонировать нашу игру, разрушив мечты, жизни и веру трех бедных студентов в человечество. Я надеюсь, эта статья сэкономит вам много времени в будущем и поможет найти не совсем очевидные нарушения законов производительной физики в своих проектах.

Читайте документацию и экспериментируйте, даже если пользуетесь простыми и интуитивно понятными инструментами.

Модуль поиска не установлен.

Физика в компьютерных играх

Лев Симонов aka LEVel

За последние несколько лет игровая индустрия достигла небывалых результатов в реалистичности графики в компьютерных и "приставочных" играх. Во многом этому способствовало развитие 3D-ускорителей, появление новых методов в обработке графики, появление и бурное развитие новых технологий, в качестве примера последних можно привести не так давно появившиеся шейдеры.

История моделирования физики на компьютере, как и история игровой физики, уходит далеко в прошлое, но наверное не стоит уделять ей особого внимания, ведь нас больше интересует, каково современное положение дел в этой области. Ну и, естественно, что нас ждет в недалеком (да, впрочем, и далеком) будущем.

Что мы имеем

Довольно логично начать повествование с описания существующих моделей, вот только есть тут одно "но": подробное описание любой из них напрашивается не просто на отдельную статью, а на целый ряд статей или докторскую диссертацию. Так что придется ограничиться поверхностным упоминанием и такой же поверхностной оценкой. Итак, для начала надо вспомнить игру Half-Life 2, надеюсь, воспоминания о ней еще не преданы забвению. Мне, например, на ум сразу же приходят всяческие хитроумные головоломки, построенные на основных физических законах. Ну и, естественно, легендарная гравипушка, позволяющая испытать на прочность (реалистичность) местную физику. К чему я это все говорю? Очень просто. Это наглядно показывает возможности (кстати говоря, не все) одного из лучших игровых физических движков - Havok"а, который часто используется при создании игр высшего класса. Из примеров использования можно также упомянуть Max Payne 2, который тоже на физику не жаловался. Но в глубине монстра с названием Havok бьется сердце, называемое ODE (Open Dynamic Engine). ODE - еще один движок, гораздо менее проработанный, но зато бесплатный и "опенсорсный" ("open source" - с открытыми ресурсами), т.е. любой может бесплатно скачать себе его исходный код и изменить, как ему захочется. Именно так, например, поступили разработчики XPand Rally. Помимо этих двух наиболее ярких представителей семейства физических движков существует и множество других, менее ярких. Тут можно вспомнить Tokamak, Novodex и Newton Dynamics. Это также достаточно известные реализации, обладающие, правда, меньшими возможностями, да и их исходники всем подряд не дают. Вот примерно такая вырисовывается картина. Ну и справедливости ради надо сказать, что существует также целая армия маленьких самописных движков, написанных независимыми программистами для конкретных игрушек. Или просто для удовольствия.

И как оно работает?

Если независимые одиночки пишут свои движки, значит, они знают, как это делать. А значит, каждый может это узнать, так? Отчасти да. Но в основе современных реализаций лежат такие мощные математические модели, основанные на таких глубоких физических знаниях, что человеку несведущему разобраться трудно, если вообще возможно. Еще есть проблема информации, которой, вообще-то говоря, маловато. Но, сейчас нас подобные сложности особенно не беспокоят, так как мы будем рассматривать не математические выкладки, а основные принципы.

Для начала поделим все методы на две большие группы: пружинные каркасы и твердые тела. Пружинные каркасы представляют собой группу точек, связанных пружинами - связями, пытающимися сохранить свою первоначальную длину. Внешне это очень похоже на вершины, из которых состоит меш-сетка, ребра которой обозначают пружины. На каждом шаге моделирования рассчитываются все силы, действующие на все точки каркаса. В результате мы получаем новое состояние тела. Обычно такой принцип моделирования используют для создания мягких тел и поверхностей, например тканей, резины и т.п. Твердые тела представлены всего одной точкой, но тут появляется достаточно сложное вращательное движение. Такой метод, как понятно из его названия, используется для представления твердых тел, не изменяющих свою форму. Естественно, оба метода можно использовать одновременно.

Теперь поделим на части методы моделирования (взаимодействия?) твердых тел. Тут существует два основных метода: импульсная модель и модель, основанная на ограничениях. Импульсная модель наиболее проста, здесь надо только найти столкновения объектов (впрочем, это приходится делать в каждом методе) и приложить к ним силы, высчитанные по закону сохранения импульса. Такой метод очень удобен, если между телами нет каких-нибудь связей, хотя и их тоже можно реализовать на импульсах, правда, не совсем точно и правильно. Поэтому для систем, содержащих множество связей различной сложности, был придуман другой метод - ограничения. Метод, построенный на ограничениях, - это пример системного подхода к моделированию физики. Все соединения и контакты описываются математически как ограничения и добавляются в общую систему уравнений. Решив эту систему, мы получим новое состояние для каждого тела. Этот метод удобен в первую очередь тем, что с его помощью можно создавать любые ограничения. Эти возможности получили наибольшее применение в технологии Rag Doll.

Куклы

Замысловатое словосочетание Rag Doll переводится на русский язык как "тряпичная кукла". Итак, чтобы было понятней, начнем наше беглое описание данной сравнительно новой технологии сразу с практической части. Если мысленно перенестись в не очень далекое прошлое (примерно в 2000 год), то можно вспомнить, что в большинстве шутеров тела поверженных врагов (или монстров) лежат очень неестественно: они погружаются по пояс то в стену, то в дверь, то они повиснут над лестницей, как будто лежат на невидимых столах... Но вернемся в наши дни. Подавляющее большинство современных шутеров показывают гибель вражеских солдат очень реалистично: бедняги прислоняются к ближайшим стенам или картинно скатываются с лестниц. Почему? Потому что используют технологию Rag Doll.

Суть идеи заключена в том, что строится иерархия физических тел, соединенных подвижными связями. Их расположение и соединения напоминают расположение костей скелета для скелетной анимации. Затем эта группа объектов объединяется со скелетом персонажа, чтобы совместить физическую и графическую сущность человечка (ну или другого существа). Теперь все просто. Как только персонаж умирает, "физический скелет" принимает позу неудачливого бойца и загружается в физический движок. Теперь все движения "куклы" обусловлены физическими законами, тело упадет на землю так, как это было бы в жизни.

Интересно отметить, что тут нет абсолютно никакой разницы, какой метод моделирования использовать, - главное, чтобы он смог правильно смоделировать все необходимые нам тела и соединения.

Железо

Несложно догадаться, что все эти радости требуют затраты огромных ресурсов памяти и процессора. А ведь в современных компьютерных играх помимо физики надо рассчитывать просто горы информации: графика (хотя она почти полностью лежит на видеокарте, но все-таки затраты производительности CPU требуются немалые), искусственный интеллект, интерфейс и многое другое. Но при повышении реалистичности физики повышаются и требования к компьютеру, т.е. все более и более сложные физические модели требуют от системы все больше ресурсов. Что же делать? Когда-то давно подобная проблема возникла в области графики. Тогда судьбу центрального процессора облегчили, добавив принципиально новое устройство - 3D-ускоритель, процессор которого (GPU) взял на себя значительную часть вычислений, связанных с расчетами в области построения 3D-картинки. Теперь похожая ситуация повторяется и с физикой. Поэтому, для того чтобы снять с CPU обязанность рассчитывать медленную физику, в ближайшем будущем планируется повсеместное введение физического процессора (PPU - Physic Processor Unit). Первые реализации уже появились, но они еще не очень распространены, да и игр с их поддержкой совсем немного. Но все-таки эта технология рано или поздно приобретет ничуть не меньшее признание, чем аппаратное ускорение трехмерной графики. Первое "физическое ядро", разработанное сравнительно молодой компанией Ageia, называется PhysX. По заявлениям разработчиков, сделанным на конференции GDC (Game Developers Conference - конференция разработчиков игр), он позволяет честно смоделировать в реальном времени систему из 50 000 тел (это против 10-50 тел современными программными способами!) без особых потерь в скорости выполнения программы.

Взгляд в будущее

Итак, что же ждет нас в будущем? В этом вопросе я соглашусь с человеком, чье имя знакомо каждому разработчику игр и некоторым продвинутым геймерам - Джоном Кармаком (John Carmack). На конференции разработчиков игр GDC-2004 он сказал: "...d будущих поколениях игр появится моделирование погоды, моделирование жидкостей, моделирование пылевых облаков, переносимых ветром и огибающих окружающую среду". Сейчас мощности среднего персонального компьютера недостаточно для правильного моделирования таких сложных систем в реальном времени, тем более в компьютерных играх, но в будущем такое станет возможным. Это принесет еще больше реалистичности в компьютерные игры. С введением и развитием PPU будет достигнут новый уровень взаимодействия графики и физики: все процессы в окружающей героя среде будут подчиняться соответствующим законам физики, и выглядеть это будет максимально реалистично. Так что ждем-с.


Учителям остаётся только выбирать, если они, конечно, готовы к этому выбору. Сегодня мы предлагаем вашему вниманию 13 различных приложений и игр, которые могут пригодиться при изучении физики. Впрочем, они настолько интересны, что вполне подойдут не только ученикам и студентам, но и всем, кому интересно устройство нашего мира.

Snapshots of the Universe – удивительное приложение для iOS, не так давно выпущенное самим Стивеном Хокингом совместно с компанией Random House . Приложение состоит из восьми экспериментов, которые дают пользователям возможность не только получить базовые знания по физике, но и познакомиться с принципами, управляющими нашей Вселенной. В рамках предложенных экспериментов игроки могут отправлять ракеты в открытый космос, собирать собственные звёздные системы, искать и изучать чёрные дыры. Каждый эксперимент можно проводить бесчисленное количество раз, изменяя физические параметры и наблюдая за появляющимися эффектами. Чтобы лучше понять эксперименты, можно зайти в раздел объяснения результатов и посмотреть видео. Приложение доступно на iTunes . Cтоимость игры от великого физика составляет всего лишь $4,99.

Это игра с уникальным сочетанием особенностей аркады и головоломки, место действия которых – мир субатомных частиц. Взяв под контроль одного из кварков, вы должны вести переговоры с фундаментальными силами Вселенной. Другие частицы будут притягиваться и отталкиваться, соединяться и изменять полярность, задача несчастного кварка - не терять контроль и избегать разрушения. Через всю игру красной нитью проходит история Элисон – молодого физика с нелёгким прошлым. Её путешествие через субатомный мир протекает в воспоминаниях и в конечном счёте приводит к удивительным открытиям. На сайте представлена бесплатная демо-версия, за полную придётся заплатить от 5-ти до 50-ти долларов – в зависимости от особенностей вашей системы.

Игра от первого лица, разработанная лабораторией игр (MIT), даёт возможность игрокам познакомиться с восприятием пространства на околосветовых скоростях и понять теорию относительности. Задача игрока – перемещаться по 3D-пространству, собирать сферические объекты, которые замедляют скорость света на фиксированные значения, что даёт возможность наблюдать за различными визуальными эффектами эйнштейновской теории.

Чем медленнее движется излучение - тем яснее проступают некоторые физические эффекты. К 90-му собранному камню свет будет распространяться со скоростью пешехода, что заставит вас почувствовать себя героями сюрреалистического мира. Среди явлений, с которыми может познакомиться герой во время игры, эффект Допплера (изменение при движении игрока длина волны регистрируемого им света, что приводит к изменению окраски видимых предметов, которая смещается в ультрафиолет и инфракрасную область), абберация света (увеличение яркости света в направлении движения), релятивистское замедление времени (различия между субъективным ощущением времени игрока и протекании времени во внешнем мире), преобразование Лоренца (искажение пространства на околосветовых скоростях) и т.д.

Crayon Physics Deluxe - это 2D-пазл/игра «в песочнице», которая даёт возможность испытать игрокам, что было бы, если бы их рисунки могли превращаться в реальные физические объекты. Задача игрока – помогать шарику собирать звёздочки, рисуя подходящие для его движения поверхности – мосты, переправы, рычаги и т.д. Всё происходит в волшебном мире детского рисунка, где инструментами игрока являются восковые карандашики. Как минимум игра развивает художественное видение и творческие способности, как максимум – позволяет познакомиться с основами механики - гравитацией, ускорением и трением. Для теста на сайте представлена демо-версия , полную версию для PC, Mac и Linux можно приобрести за $19,95, приложения на Android и iOS обойдутся в $2,99.

Впрочем, для тех, кто только приступил к изучению движения тел и различных физических сил, будет также интересно ознакомиться с образовательной видеоигрой Physics Playground. Игра представляет собой площадку, на которой игроку нужно выполнять достаточно простые действия – с помощью зелёного шара сбивать красный воздушный шарик. Вот тут-то и начинается классическая механика: без правильного применения законов Ньютона игрокам вряд ли удастся сконструировать в интерактивной среде механизмы, которые помогут привести в движение шарик. Впрочем, можно пользоваться и интуицией – главное, что на протяжении 80-ти уровней интуитивные знания, позволяющие достигать цели, постепенно приводят к пониманию закономерностей, которые лежат в основе классической механики. Игра разработана компанией Empirical Game , которая занимается созданием развивающих образовательных игр. В открытом доступе её, к сожалению, нет, однако разработчики предлагают связаться с ними, если вас заинтересовал этот продукт. В полной версии можно отслеживать успехи игроков с помощью анализа журналов лог-файла.

«Наука, индустрия развлечений и игра слились в красивом уникальном творческом опыте Newton’s Playground. Манипулируйте Вселенной, создавайте невероятные сочетания планет и запускайте гравитацию», - говорят создатели приложения. Newton’s Playground – интерактивное приложение, которое базируется на моделях, отражающих гравитационную взаимосвязь различных тел. Имитируя гравитационные отношения планет, небольшое приложение Newton’s Playground даёт своим игрокам возможность понаблюдать за взаимодействием сфер, плавающих в открытом пространстве, или же самому поэкспериментировать с массой и плотностью различных тел и создать собственную Солнечную систему. Все расчёты основаны на исследованиях института астрономии Sverre Aarseth"s. Стоимость приложения в App Store – $1,99.

«Algodoo создает новую синергию между наукой и искусством», - гласит надпись на одной из страниц игры. Algodoo – это уникальная платформа 2D-моделирования физических экспериментов от Algoryx Simulation AB . С помощью мультяшных образов и интерактивных инструментов Algodoo позволяет создавать удивительные изобретения, разрабатывать игры для использования в классе или специальные эксперименты для лабораторных занятий по физике. В процессе своих естествоиспытаний и создания различных механизмов участники игры могут использовать жидкости, пружины, шарниры, двигатели, световые лучи, различные индикаторы, оптику и линзы. Моделируя различные конструкции и меняя параметры, игроки изучают трение, преломление, силу тяжести и т.д. Для новичков на сайте представлено подробное руководство , а также создан канал Youtube , на котором можно посмотреть десятки видео по теме. Для Windows и Mac доступны бесплатные версии игры, приложение для iPad стоит $4,99.

Autodesk ForceEffect – приложение для инженеров, которые занимаются различного рода проектированием. С помощью Autodesk ForceEffect можно делать инженерные расчёты прямо на мобильном устройстве. Это существенно облегчает работу по дизайну на стадии создания концепции, так как мгновенно определяет жизнеспособность конструкции. Впрочем, приложение будет интересно и тем, кто хотел бы узнать, как различные силы влияют на объекты. Таким энтузиастам вместо схемы дома для эксперимента можно взять обычный велосипед и на основе его фото провести ряд экспериментов, которые покажут, какую нагрузку он способен выдержать и что влияет на равновесие велосипеда. Особенно приятно, что приложение находится в открытом доступе и бесплатно доступно для Android , iOS .

Физика способна сделать взрывы и смерти врагов более впечатляющими по сравнению с заготовленными анимациями, и она отлично подходит для симуляции движения боевых снарядов и распространения огня. Но физику можно использовать далеко не только для красоты – она может быть основным инструментом гейм-дизайна.

Физика может определять центральные игровые механики, как в Portal и Where’s My Water?, или поддерживать их – например, постройка башен в World of Goo и потрясающее разрушение мира в Red Faction Guerilla. Она может даже передавать эмоции – когда в Limbo вы тянете паука за ногу, можно почувствовать, как он напрягается от боли. Может служить для усиления эстетического удовольствия, как .

Физика помогает вызывать восторг и удивление. Помогает добиваться реализма или же сюрреализма. Вообще, при правильном её применении, игры становятся интереснее. И она запросто может привлекать аудиторию не только к головоломкам, но и к симуляторам, платформерам и даже шутерам.

Мы попросили нескольких разработчиков привести примеры умелого или креативного вплетения физики в игровые механики, после чего составили данный список. Каждый из семи примеров выходит за привычные рамки, чтобы радовать и восхищать игроков, и как результат, каждый стал новшеством в той или иной степени.

Гравитация в Mario Galaxy

Разработчик Gravity Ghost Эрин Робинсон (Erin Robinson) называет Super Mario Galaxy основным источником вдохновения для своей механики передвижения. Возможно, прыжки по планетоидам в этой игре и нарушают законы физики, но использование гравитации позволило воплотить в жизнь великолепный дизайн уровней.

Марио повторяет изгибы рельефной поверхности маленьких небесных тел произвольной формы благодаря хитроумному трюку в движке. Опустив технические подробности, скажу, что упрощённая версия реальной гравитации всегда притягивает его ноги к земле, даже когда он висит вверх ногами или боком на неестественно вогнутой планете.

Что интересно, эта гравитация действует не на все объекты в игре.

В Super Mario Galaxy нечто, настолько простое и обыденное, как передвижение, кажется волшебным. Марио чувствует себя как дома, прыгая, бегая и скользя по круглым, конусообразным, полым и ещё менее геометрически-дружелюбным мирам. Это кажется оригинальной идеей даже сегодня, по прошествии восьми лет, и элегантная реализация позволяет необычной механике выглядеть естественно.

Гравитации необязательно быть реальной, и она не обязана воздействовать на весь игровой мир. Также она помогает реализовать смелые и нестандартные идеи для дизайна уровней.

Портальные пушки в Portal, нарушающие законы физики

Замечательная гравипушка из Half-Life 2, позволяющая хватать, перемещать и швырять объекты окружения, получила достойного идейного наследника в играх Portal. Портальная пушка создаёт червоточину размером с человека, позволяющую переноситься из одной видимой точки в другую. Эта возможность искривлять реальность (игровую) позволила команде разработчиков придумать по-настоящему оригинальные головоломки.

Разработчик Manifold Garden Уильям Чир (William Chyr) говорит, что Portal служит моделью для обучения непривычной физике. «Игра разбивает концепцию на несколько базовых шагов, которые понятны всем», – говорит он, – «и при этом не затягивает с обучением». Механика порталов так бережно согласована, что ошибки относительно безболезненны, а решения всегда логичны (особенно радуют продвинутые манёвры – например, когда помещаешь порталы один над другим, чтобы Челл набрала скорость для прыжка через широкую пропасть).

Физику можно сделать совершенно нереальной, если этого требует интересная механика, только следите, чтобы всё оставалось согласованным, иначе между игроком и вашим дизайном возникнет излишнее недопонимание.

Симуляция физики как игра в Turbo Dismount (и не только)

Реалистичная физика может быть увлекательна сама по себе. Игры без чёткой цели, вроде Garry’s Mod, BeamNG.drive и Turbo Dismount (среди прочих) полностью полагаются на забавы с системой игровой физики.

В Garry’s Mod заложена мощная строительная составляющая, позволяющая манипулировать с любыми моделями и объектами; BeamNG.drive – просто игровая площадка с автомобилями, повреждения которых основаны на гиперреалистичной физической модели. Ну а в Turbo Dismount вы наслаждаетесь не столько строительством и передвижением, сколько поиском всё более изощрённых способов поиздеваться над ragdoll-персонажем. Если заглянуть в мир цифровых игрушек поглубже, можно найти Earth Primer, которая учит геонаукам посредством весёлых взаимодействий в небольшой песочнице.

Генеральный директор Bossa Studios Энрике Олифьерс (Henrique Olifiers) отмечает, что подобные игры наглядно демонстрируют развлекательную самодостаточность симуляции физики. «Физика сама по себе может быть интерактивным развлечением», – полагает он. Turbo Dismount и другие подобные игры – по сути просто набор базовых взаимодействий, реакция на которые определяется системой физики, и уже это способно увлекать на долгие часы.

Симуляция физики может быть не только вспомогательной системой, она может быть и целой игрой. Гидродинамика, ragdoll-анимация, столкновения мягких тел и разные виды гравитации могут самостоятельно предоставить совершенно новый опыт, и взаимодействия, которые они подразумевают, могут быть увлекательны сами по себе.

Упрощённая физика машин и персонажей в Grand Theft Auto V

Являет нам особую вариацию физики, которая делает игровой мир реалистичнее, но в то же время позволяет вытворять нелепые и нереальные безумства. «Всё вокруг изо всех сил старается изображать реальность, до тех пор пока эта «реальность» не встаёт на пути весёлого геймплея», – объясняет Олифьерс. Физика движения персонажей и автомобилей – равно как баллистика и взрывы –«нормальна» именно по меркам Лос-Сантоса.

Наверное, так и задумано, что различные крайности обладают особенно высоким потенциалом для забав с физикой. Олифьерс замечает, что GTA V – опора сабреддита /r/GamePhysics, благодаря мириадам интересных особенностей, багов, эксплойтов и невероятных трюков, связанных с физикой.

Разработав систему физики, которая с радостью портит всё погружение при первой же возможности устроить полнейший хаос, Rockstar гарантировала, что в открытом песочном мире Grand Theft Auto V всегда найдётся место гонкам и разрушениям.

Полёты на вингсьюте в Just Cause 3

Такое бодрящее передвижение игрока, как в , встретишь не в каждой игре. Здесь можно летать, сколько душе угодно, благодаря комбинации парашюта, верёвки с крюком и вингсьюта. Первые два добавлены специально, чтобы сломать систему – чтобы игрок мог выполнять сумасшедшие развороты и рывки в воздухе, открывающие простор для всевозможных способов ведения боя. А вот третий – вингсьют – олицетворяет абсолютную свободу и наслаждение полётом.

Дизайнер QWOP и профессор кафедры Game Center в Нью-Йоркском Университете Беннетт Фодди (Bennett Foddy) называет вингсьют «образцом идеально отлаженной игровой механики, гармонирующей с системой физики». Он вызывает чувство постоянного баланса на грани катастрофы, неважно, парите вы аккуратно, устремляетесь вниз орлом или резко взлетаете на склон. Но учиться им управлять, понимая особенности набора высоты, торможения и инерции – в особенности, осваивая костюм в сочетании с крюком – значит учиться летать. Немногие игры подарят вам это ощущение.

Если главным приоритетом выступает удовольствие от игры, разрабатывайте механики, избавляющиеся от полной достоверности. Но сохраняйте их правдоподобными и гармонирующими с игровым миром. Just Cause 3 тому пример – одна основанная на физике механика способна полностью вас очаровать.

Эластичный и пружинистый мотоцикл в Elasto Mania

Некогда бывшая сферой интереса студентов по всему миру, Elasto Mania остаётся выдающимся образцом геймплея, основанного на физике. Похожая на более свежую серию Trials, но более абстрактная и ориентированная на головоломки, Elasto Mania даёт вам мотоцикл и отправляет в причудливый мир, напоминающий лабиринт с зазубренными платформами и разбросанными повсюду яблоками. Игра ставит простую задачу: коснуться цветка (и ничего простого в этом нет). Чтобы добраться до цветка, нужно двигаться вдумчиво и аккуратно, поскольку ваш байк не только растягивается, как резинка, и чувствителен к малейшему ускорению, но и сам гонщик толщиной с бумагу умирает от малейшего контакта головы с землёй.

Фодди говорит, что прелесть Elasto Mania заключается в том, как она «демонстрирует, какой может предстать новая комплексная механика, когда физический движок взаимодействует с продуманным дизайном мира». Пять доступных действий (наклон вперёд-назад, ускорение, торможение и смена направления) – это всё, что нужно для управления эластичным заднеприводным мотоциклом на пути через множество препятствий, когда разнообразные решения поставленной задачи подразумевают грамотное использование крутящего момента, гравитации и физики упругих тел (байк, по большому счёту – пружина на колёсах).

Комплексность естественным образом возникает из простого набора взаимодействий физически смоделированного движения персонажа с миром, где доступному пространству уделяется самое пристальное внимание.

Конструирование ракет в Kerbal Space Program

Обычно основанная на физике игровая механика подразумевает, что вы будете работать рука об руку с физической системой. Вы либо играете с самой физикой, либо используете её для получения каких-либо преимуществ. Но Kerbal Space Program – одна из тех редких игр, где вам нужно активно бороться с физикой, чтобы сделать хоть что-нибудь. Здесь ключевые механики не просто основаны на физике или подкрепляются ей; здесь они ей противостоят.

Олифьерс описывает физику в Kerbal как основную цель. Он говорит, что каждую секунду вы пытаетесь «разобраться, каким образом ваши стратегии и решения победят непрекращающееся земное притяжение». Битва с непоколебимой гравитацией приводит к непредсказуемым результатам, что делает непредсказуемость частью геймплейного цикла. Олифьерс называет это «волнующим ожиданием представления, в котором каждая ваша задумка по противодействию законам физики будет играть против каждого недостатка вашей инженерии».

Физика может быть грозным противником, одновременно непреклонным в своём постоянстве и до любопытства непредсказуемым – малейшее изменение в ваших действиях может оказать побочные эффекты, ведущие к совершенно иному результату.

Заключение

Физика может пригодиться не только в эстетических, но в геймплейных целях.

Сегодня основные инструменты для создания игр уже включают в себя физический движок, так что извлекать пользу из физики стало проще. Только не останавливайтесь на улучшении анимации. Физика может дать вам гораздо больше. Олифьерс говорит, что его команда обширно использует физику из-за её способности привносить в игры нечто новое. Она непредсказуема и вмешивается в привычный ход вещей, но она не выглядит нечестной. Олифьерс объясняет: «В физике есть некий обуславливающий аспект, который игроки расшифровывают на подсознательном уровне».

Мы заранее многого ждём от системы физики, и от этого игра в наших глазах сразу становится лучше. Вы, как разработчик, выглядите умнее, а ваш дизайн выглядит правильным.

Статьи по теме: