Я нахожусь в процессе превращения 2d сверху вниз игры, над которой я работаю, в настоящий физический движок твердого тела, такой как Farseer. До сих пор я просто взламывал собственный физический код, где это было необходимо.
Я пытаюсь научиться правильно делать вещи здесь.
Как правильно заставить ИИ следовать по заданному пути, когда вы сделаете их твердыми телами внутри физического движка?
Если у меня есть путь навигационных узлов на моей карте, по которому мне нужен AI, ранее я просто перемещал их по пути вручную, вычисляя следующую позицию, в которой они должны находиться для следующего шага времени, и вручную устанавливая их в эту позицию ,
Но теперь они являются твердыми телами и подвержены столкновениям и любым силам, которые могут поразить их и сбить с пути.
Таким образом, чтобы заставить ИИ двигаться, я считаю, что теперь я должен применять импульсы / силы к ним? Мне больше не нужно вручную устанавливать свою позицию в каждом кадре.
Поэтому я думаю, что мне нужно выйти из детерминированного мира, где я заставляю ИИ строго следовать по пути к недетерминированному миру, где они могут попасть в любую сторону, если ударить, и я просто подталкиваю их к следующему узлу на пути. заставить их двигаться.
Это правильно? Это как другие люди делают это?
Это поднимает некоторые вопросы о том, как избежать того, чтобы ваш ИИ застрял на углах пейзажа, когда они не идут по точному пути, как вы, ребята, справляетесь с такими вещами?
Или лучше как-то смешать их, и все же ваш ИИ будет следовать по фиксированному пути, устанавливая их положение вручную, и реагировать только на другие силы только при определенных обстоятельствах, которыми вы легко можете управлять?
Спасибо за любые советы, ребята.
Ответы:
Поведение рулевого управления очень хорошо работает в сочетании с физическим движком, поскольку обычно оно реализуется таким образом, что оно возвращает «рулевую силу», которая затем может быть применена к вашему физическому телу.
Чтобы заставить юнит следовать по пути, вы можете использовать Seek, чтобы перейти от path-node к path-node (убедитесь, что вы избежали перерегулирования), а затем использовать Arrival на последнем узле вашего пути.
Что касается ваших опасений застрять: моделирование следования по пути с использованием сил должно быть достаточно точным. Вы правы в том, что объект может быть сброшен с пути, если он столкнется с другим объектом, но, поскольку вы будете вычислять усилие рулевого управления при каждом обновлении, объект должен снова быть на дорожке в кратчайшие сроки. Если отклонение от траектории после столкновения потенциально может быть огромным, тогда я предлагаю вам вспомнить свою последнюю позицию при каждом столкновении, а затем направить объект обратно в эту последнюю позицию перед продолжением обычного маршрута.
источник
Я бы сказал, что вы на правильном пути, вы можете посмотреть на эту статью:
http://www.policyalmanac.org/games/aStarTutorial.htm
Он объясняет некоторые основные способы предотвращения столкновений и поиска путей с использованием алгоритма A *.
Редактировать:
Если вам действительно нужен только лучший способ продвижения ваших объектов в правильном направлении, то вы должны использовать силу (скажем, MovementForce или что-то еще), указывающую в направлении лучшего пути, который вы нашли, используя алгоритм поиска пути вашего выбор
источник
Судя по тому, что @davidluzgouveia прокомментировал пост анонимно, я приведу свой проект. Следование по пути и поиск пути очень разные, хотя. Поиск пути - это больше того, о чем анонимно публиковалось, и для поиска пути я бы заглянул в алгоритм Дейкстры. Для следования пути я полностью использую свой физический движок. То, как я это настроил, заключается в том, что каждая локация, по которой идет класс юнитов, настраивается в своем подклассе пути с помощью 2D-смещений, да, они 2D, а не 3D, это из-за того, как я настроил свою физику в своей игре ,
Объяснение 3D: у каждого подразделения есть только один главный коллайдер, который специально настроен для столкновения с объектами местности и мира. Это капсула, имеет радиус и высоту, говоря програматически. Он построен в центре модели и должен проходить сразу за передней и верхней частью модели. Но у меня также есть поверхностное смещение для того, как далеко он находится от земли, и всплеск того, сколько ему позволено скользить вниз, прежде чем слегка подпрыгивать, за раз. Звучит так, будто я прибегаю к какому-то искаженному решению проблемы столкновения с землей, но у меня есть свои причины.
В любом случае, вы должны приложить силу к этому объекту капсулы, и он должен постоянно зависать над землей. Это не значит, что оно не может быть выше, просто оно не может быть ниже. Причина, по которой он должен зависать (в моем случае), заключается в том, что в физическом двигателе с твердым телом и рэгдоллом ноги моих юнитов процедурно анимированы. Таким образом, применяя простую силу к капсуле, ноги моей сущности сами переместятся. У них также будут свои отдельные приложения силы тяжести! Это позволяет, если мой персонаж находится под наклоном, одна нога может находиться на более низком уровне, чем другая.
Это именно то, как вы должны это сделать. Судя по тому что ты спрашиваешь. Если вы хотите пропустить некоторые функции, это, безусловно, хорошо, особенно если это RTS или FPS, и никто никогда не увидит ноги юнитов или все равно будет заботиться. Но в целом у юнита должен быть один ГЛАВНЫЙ объект столкновения, который почти исключительно работает с движением персонажа.
В частности, 2D: у вас все еще должна быть основная точка или просто какое-то указание, чтобы двигатель двигался вперед, для движения юнита. Вы могли бы дать каждому подразделению подкласс пути, который имеет несколько местоположений, которые ему нужно пройти, вы можете указать его в коде уровня (например, location1 (x, y) location2 (x, y) и т. Д.) Наилучшим образом (я не знаю не знаю, над какой игрой вы работаете), вероятно, будет указывать места на уровне и иметь, что каждый юнит будет обрабатывать их в порядке, определяемом уровнем, и после того, как он достигнет каждой локации, он заменит желаемое место на следующий он должен добраться до.
Есть множество способов изменить это, например, иметь список мест на первом месте для каждого юнита, так как это означает, что не все юниты должны идти в одни и те же места. Однако таким же образом вы можете сделать это и в коде уровня (unit1.location1 (x, y) unit1.location2 (x, y) grunt.l1 (x, y) knight.loc3 (x, y) без разницы)
Всего несколько идей! Я предлагаю вам прочитать 3D-версию, хотя она гораздо менее актуальна.
РЕДАКТИРОВАТЬ: Я решил просто предоставить оба для тех, кто мог бы прочитать это (да, это правда) .... (Первоначально я только просмотрел ваш вопрос и не понял, что это было довольно 2D-специфика, пока я не перечитал его>.>)
источник