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

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

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

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

Не предлагайте движки, типа Юнити: я пытаюсь понять их устройство "под капотом".
  • Вопрос задан
  • 368 просмотров
Пригласить эксперта
Ответы на вопрос 4
jamakasi666
@jamakasi666
Просто IT'шник.
Тут все немного проще.
Программисты пишут набор утилит. Програмка или плагин для экспорта-импорта моделей\анимаций\партиклов\звуков\текстур.
Дальше программисты описывают формат уровня и редактор для него.
Все это делает этакий "мост" между программистами и всеми остальными.
Программисты дальше уже по известным форматам ресурсов делают загрузку уровней и описывают логику всего в игре и очень часто многие параметры выносят в конфиги или скрипты. Дальше Уже снова дизайнеры\моделлеры и т.д. начинают подбирать параметры, к примеру размеры тех или иных моделей, их физические свойства, уровень здоровья, скорость бега и т.д.

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

PS вообще вопрос очень абстрактный и без живых примеров которые будут просто огромные сложно дать простой ответ "вот как это происходит".
Ответ написан
Комментировать
BasmanovDaniil
@BasmanovDaniil
Геймдизайнер-телепат
А вот зря отказываетесь от изучения движков, на живом примере проще понять внутреннее устройство.

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы