Я начал читать материал в Википедии, но мне все еще кажется, что я действительно не понимаю, как работает график сцены и как он может обеспечить преимущества для игры.
Что такое граф сцены? A График сцены содержит всю геометрию конкретной сцены. Они полезны для представления переводов, поворотов и шкал (наряду с другими аффинными преобразованиями) объектов относительно друг друга.
Например, рассмотрите резервуар (тип с треками и пистолетом). В вашей сцене могут быть несколько танков, но каждый из них ориентирован и расположен по-разному, причем каждая из них имеет свою башню, повернутую к разному азимуту и с другой высоты пистолета. Вместо того, чтобы точно определить, как пистолет должен располагаться для каждого резервуара, вы можете накапливать аффинные преобразования, когда вы пересекаете граф сцены, чтобы правильно позиционировать его. Это облегчает вычисление таких вещей.
Графы 2D-графики: Использование графика сцены для 2D может быть полезно, если ваш контент достаточно сложный, и если ваши объекты имеют несколько подкомпонентов, которые не жестко привязаны к большему телу. В противном случае, как отмечали другие, это, вероятно, перебор. Сложность аффинных преобразований в 2D довольно немного меньше, чем в трехмерном случае.
Линейный менеджер сущностей: Я не совсем понимаю, что вы подразумеваете под менеджером линейных объектов, но если вы ссылаетесь только на то, чтобы отслеживать, где вещи расположены в вашей сцене, тогда графики сцены могут облегчить ситуацию, если существует высокая степень пространственной зависимости между различными объектами или под-объектами в вашей сцене.
Что такое граф сцены в игре контекст разработки двигателя?
Ну, это какой-то код, который активно сортирует ваши игровые объекты в игровом пространстве таким образом, чтобы легко быстро находить, какие объекты находятся вокруг точки в игровом пространстве.
Таким образом, легко:
И другие вещи. Это о разрешении быстрого поиска в космосе. Это называется разделением пространства. Это о делении и покорении.
Почему я хочу реализовать его для мой 2D-движок игры?
Это зависит от типа игры, точнее от структуры игрового пространства.
Например, игра, подобная Zelda, не могла бы нуждаться в таких методах, если она достаточно быстра, чтобы протестировать столкновение между всеми объектами на экране. Однако он может быть действительно очень медленным, поэтому большую часть времени вы, по крайней мере, настраиваете граф сцены (или пространственный раздел любого типа), чтобы хотя бы знать, что вокруг всех движущихся объектов и тестовых коллизий только на этих объектах.
Итак, это зависит. В большинстве случаев это требовалось для повышения производительности. Но реализация вашего разделения пространства полностью зависит от того, как структурировано ваше игровое пространство.
Используется ли использование графика сцены как альтернатива классическому объекту система с линейным менеджером сущностей?
Нет.
Независимо от того, каким образом вы управляете жизнью объектов объектов вашей игры, пространство-раздел/сцена-граф есть только для того, чтобы вы могли быстро искать объекты в пространстве, не более того. В большинстве случаев это будет объект, который будет иметь несколько слотов объектов, соответствующих различным частям игрового пространства, и в этих слотах это будут объекты, которые находятся в этих частях. Он может быть плоским (например, двумерный разделитель экрана в 2 или 4), или он может быть деревом (например, двоичным деревом или квадрантом или любым другим видом дерева) или любой другой структурой сортировки, которая ограничивает количество операций, которые у вас есть выполнить, чтобы получить некоторую информацию, связанную с пространством.
Обратите внимание на одно:
В некоторых случаях вам даже нужны разные системы раздельного пространства для разных целей. Часто "график сцены" относится к рендерингу, поэтому он оптимизируется таким образом, который зависит от точки зрения игрока, и он предназначен для быстрого сбора списка объектов для рендеринга для отправки на графическую карту. Он не подходит для выполнения поиска объектов вокруг другого объекта, что затрудняет его использование для точного обнаружения столкновений, например, когда вы используете физический движок. Поэтому, чтобы помочь, у вас может быть другая система пространственных разделов только для целей физики.
Чтобы привести пример, я хочу сделать игру "пуля ад", в которой есть много шаров, которые игроку космический корабль должен уклоняться очень точно. Чтобы добиться достаточной производительности рендеринга и обнаружения столкновений, мне нужно знать:
Итак, я рекурсивно вырезаю экран, который является 2D в 4 частях, что дает мне квадрант. Квадтри обновляется каждый тик игры, потому что все движется постоянно, поэтому я должен отслеживать положение каждого объекта (космический корабль, пуля, монстр) в квадранте, чтобы узнать, какой из них находится в какой части экрана.
Достижение 1. легко, просто введите пулю в систему.
Чтобы достичь 2. Я сохранил список листьев в квадратике (квадратные части экрана), которые находятся на границе экрана. Эти листья содержат идентификаторы/указатели пуль, которые находятся рядом с границей, поэтому я просто должен проверить, что они выходят, чтобы знать, могу ли я прекратить их рендеринг и управлять столкновением. (Это может быть немного сложнее, но вы получаете идею.)
Чтобы достичь 3 и 4. Мне нужно получить объекты, которые находятся около космического корабля игрока. Поэтому сначала я получаю лист, где находится космический корабль игрока, и я получаю все объекты в нем. Таким образом, я проведу только столкновение с космическим кораблем игрока на объектах, находящихся вокруг него, а не на всех объектах. (Это немного сложнее, но вы получаете идею.)
Таким образом, я могу убедиться, что моя игра будет бесперебойно работать даже с тысячами пуль, постоянно движущихся.
В других типах пространственной структуры требуются другие типы пространственного разбиения. Как правило, kart/auto games будет иметь "туннельный" график сцены, потому что визуально игрок увидит только вещи вдоль дороги, поэтому вам просто нужно проверить, где он находится, чтобы найти все видимые объекты в "туннеле",.
График сцены - это способ организации всех объектов в среде. Обычно берется организация данных для эффективного рендеринга. Граф или дерево, если хотите, могут отображать право собственности на вспомогательные объекты. Например, на самом высоком уровне может быть объект города, под ним будет много строительных объектов, под ними могут быть стены, мебель...
В большинстве случаев они используются только для 3D-сцен. Я бы предложил не идти с чем-то сложным для 2D-сцены.
В Интернете, по-видимому, существует немало разных философий, посвященных тому, что ответные действия имеют сценарный график. Люди склонны вкладывать много разных вещей, таких как геометрия, камеры, источники света, игровые триггеры и т.д.
В общем, я бы описал сценограф как описание сцены и состоял из одной или нескольких структур данных, содержащих сущности, присутствующие в сцене. Эти структуры данных могут быть любого типа (массив, дерево, Композитный шаблон и т.д.) И могут описывать любое свойство сущностей или любую взаимосвязь между объектами в сцене. Этими объектами могут быть все, начиная от сплошных выталкиваемых объектов и заканчивая коллизионными сетками, камерами и источниками света. Единственное реальное ограничение, которое я видел до сих пор, заключается в том, что люди рекомендуют сохранить игровые компоненты (например, игровые триггеры), чтобы предотвратить проблемы с ситуацией позже. Такие вещи нужно отвлечь, скажем, "LogicEntity", "InvisibleEntity" или просто "Entity".
Вот некоторые общие применения и структуры данных в сценарии.
То, как вы можете использовать сценарий в игре или движке, - это описать отношения между родителями и дочерними элементами между тем, у кого есть позиция, будь то твердый объект, камера или что-то еще. Такая взаимосвязь будет означать, что положение, масштаб и ориентация любого ребенка будут относиться к позиции его родителя. Это позволит вам сделать камеру, следуя за игроком, или включить источник света за объектом фонарика. Это также позволит вам сделать такие вещи, как солнечная система, в которой вы можете описать положение планет относительно солнца и положение лун относительно их планеты, если это то, что вы делаете.
Кроме того, некоторые вещи, относящиеся к какой-либо системе в вашей игре/движке, могут храниться в сценарии. Например, в рамках физического движка вы можете определить простые коллизионные сетки для твердых объектов, которые могут иметь слишком сложную геометрию для проверки конфликтов. Вы можете поместить эти коллизионные сетки (я уверен, что у них есть другое имя, но я забыл это: P) в вашем графическом изображении и попросите их следовать объектам, которые они моделируют.
Другая возможная структура данных в сценарии - это некоторая форма пространственное разделение, как указано в других ответах. Это позволит вам выполнять быстрые запросы на сцену, такие как отсечение любого объекта, который не находится в области просмотра, или для эффективного фильтрации объектов, требующих проверки на столкновение. Вы также можете разрешить код клиента (в случае, если вы пишете движок) для выполнения пользовательских запросов в любых целях. Таким образом, клиентский код не должен поддерживать свои собственные структуры пространственного разделения.
Надеюсь, я дал вам и другим читателям некоторые идеи о том, как вы можете использовать сценарный график и что вы можете в него вставить. Я уверен, что есть много других способов использования сценария, но это то, что я придумал.
На практике объекты сцены в видеоиграх редко организованы в граф, который "ходит" как дерево при рендеринге сцены. Графическая система обычно ожидает один большой массив материала для рендеринга, и этот большой массив проходит линейно.
Игры, для которых требуются геометрические отношения родительских отношений, такие как люди с оружием или танками с башнями, определяют и применяют эти отношения по мере необходимости за пределами графической системы. Эти отношения имеют тенденцию быть только одно-глубокими, и поэтому почти никогда не требуется сколь угодно глубокая древовидная структура.