Как связываются ресурсы с кодом?

Question

[Виталий]

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

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

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

Не предлагайте движки, типа Юнити: я пытаюсь понять их устройство "под капотом".

Answer 1

[Дмитрий Александров]

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

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

Тут у вас тоже немного неправильное понимание. Привязывается не код к свойствам моделей. Любой контент это просто визуальная часть которой управляет код. Любое свойство это цифровое значение, откуда будет браться это значение совершенно неважно. Таже модель, в общем виде, это просто массив точек в пространсве. Отдельным файлом к ней может быть скелет в котором опять же точка это кость у которой есть вес(грубо говоря радиус по которому она может двигать соседние точки в пространсве). Еще одним файлом может быть анимация которая тоже является уже массивами точек костей в интервале времени. Еще один файл может описывать текстурную развертку над треугольниками построенными по массиву точек модели описывая каждый треугольник в виде координат на 2д текстуре. Все это может быть упаковано как в 1 файл так и в кучу разных. Именно программист в коде описывает загрузку всего этого добра и смешивает\накладывает эти данные слоями друг на друга.
Позже программист берет все эти файлы и реализует к примеру переключение анимации что по факту будет просто назначение нужного файла с анимацией(та о которой говорилось выше).

PS вообще вопрос очень абстрактный и без живых примеров которые будут просто огромные сложно дать простой ответ "вот как это происходит".

Answer 2

[Даниил Басманов]

А вот зря отказываетесь от изучения движков, на живом примере проще понять внутреннее устройство.

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

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

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

Comments

[Виталий]

Ну почему вы решили, что я отказался от изучения движков? Меня Юнити вполне устраивает, я пытаюсь понять некоторые принципы устройства движков просто в теории - это ведь не означает, что я тут же кинусь реализовывать их самостоятельно! К сожалению, всё что вы описали я уже знал, меня интересует именно та часть, которая не раскрыта за предложением "Параметры и связи объектов движка с конкретными ресурсами настраиваются с помощью игрового редактора и сериализации".
Как устроен этот редактор? Экспортирует ли 3dMax какие-то параметры, за которые можно зацепиться программно? Отображаются ли экспортируемые свойства в 3dMax? Понимаю, что вопросы размытые, но вот как-то так - надеюсь, вы меня поняли.

[Даниил Басманов]

Виталий:
Некоторые куски редактора можно подсмотреть рефлектором, но большинство кода скрыто в плюсовых бинарниках. Про сериализацию можно почитать в мануале и блоге юнити:
https://docs.unity3d.com/Manual/script-Serializati...
https://blogs.unity3d.com/ru/2014/06/24/serializat...
Из моделей юнити берёт далеко не всю информацию, практически все фичи специфические для тридэшных редакторов обрезаются, остаётся только полигональный меш, скелет, анимации, блендшэйпы. Опять-таки это описано в специальном разделе мануала:
https://docs.unity3d.com/Manual/HOWTO-importObject.html

Answer 3

[Толстый Лорри]

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

Answer 4

[x67]

При изучении, объект изучения лучше максимально упростить:
Возьмите простейший open-source 2д движок на вашем любимом языке и поймете его устройство.
Поставьте себе задачу сделать пинг-понг в 2д. Создайте необходимую логику - движение, столкновения. Создайте визуализатор всего этого. Не знаю, как сейчас со всякими джваваскриптами и другими высокоуровневыми языками и диалектами, но в свое время у меня эта задача на delphi занимала очень много строчек кода. Больше 1000 уж точно(хотя мне тогда было 14 и хорошо программировать я тогда не умел и не сумел бы). Когда вы убедитесь на своем опыте, что вас это не испугало и вы досконально разобрались во всем, переходите к 3д. Там появятся такие ключевые слова, как ОпенГЛ, директИКС. Скорее всего о них вы услышите еще пока в 2д будете пинг понг рисовать, но при переходе к 3Д вы поймете, что без готовых движков еще одно измерение увеличивает количество кода на целую степень и в ответ на Тостере точно не уместится)

Comments

[Виталий]

Спасибо, но к 2д у меня вопросов нет. Я ведь сказал, что мне нужно базовое понимание теории - я не собираюсь бросаться всё это реализовывать самостоятельно.