Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / База данных игровых объектов: архитекстура системы сериализации и репликации произвольных объектов (2 стр)

База данных игровых объектов: архитекстура системы сериализации и репликации произвольных объектов (2 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
ZabПостоялецwww31 мая 20188:27#15
Delfigamer
> А причём здесь геймдев, сериализация и RPC?
При том, что внутри девэкспресовские библиотеки очень похожи на то, что ты описал. Сериализация там тоже везде есть и она вот такая.
ZabПостоялецwww31 мая 20188:32#16
У Оракла есть своя система подготовки кадров, возможно там обучают, не знаю.
Откуда то ведь берутся спецы, выстраивающие структуры баз данных, состоящие из сотен и тысяч таблиц. Там без порядка никуда, наивные методы не работают. Или спецы такого уровня тоже все самообучившиеся?
DelfigamerПостоялецwww31 мая 20189:46#17
Zab
> Развивает технологию группа наверняка известного тебе Гради Буча.
Что? Я не знаю никаких градей и бучей. А почему я должен знать? Он сделал что-то хорошее для геймдева?

Zab
> Откуда то ведь берутся спецы, выстраивающие структуры баз данных, состоящие из
> сотен и тысяч таблиц.
Про таблицы уже подробно обсудили здесь. Пришли к выводу, что реляционные БД лучше оставить для тех задач, для которых реляционные БД предназначены, а в игровом движке лучше применить специально оптимизированное для игрового движка решение.
Задачи моей системы:
- хранение игровых ресурсов - текстур, мешей, звуков и прочих ассетов - на жёстком диске,
- - желательно, чтобы с выходом новой версии движка старые ассеты по-прежнему открывались,
- - желательно, чтобы на этапе разработки, с ассетами можно было работать напрямую - отредактировал png-файл в папке, запустил игру - и тут же увидел изменения,
- - желательно, чтобы на этапе реализации, ассеты можно было запаковать в архив, который займёт меньше места на диске и который быстрее загружается, за счёт отсутствия необходимости парсить текст,
- - желательно, чтобы перемещения ассетов из папки в папку не ломали ссылки на них (которых может быть неизвестно сколько неизвестно где неизвестно в каком моде неизвестно какого чувака),
- - было бы неплохо, если бы ассеты можно было редактировать сами по себе, без реверс-инжиниринга форматов через код движка,
- - было бы неплохо, если бы ассеты играли по-хорошему с системами контроля версий, типа git и svn,
- хранение игровых сцен - уровней, префабов, сейвов игрового состояния,
- - с теми же бонусами за стабильность, редактируемость, оптимизируемость и поддержку сторонними инструментами,
- передачу объектов через сеть - как недостающих ассетов (спреи, кастомные карты, звуки, модели), так и инстансов RPC,
- - желательно, чтобы избыточность была сведена к минимуму - трафик был минимизирован - на том же канале можно будет транслировать больше динамических объектов,
- - желательно, чтобы разные версии движка могли свободно общаться между собой по сети,
- - желательно, чтобы репликация не занимала много ресурсов сервера - было бы неплохо, если бы спецификация оставляла возможность оптимизации вплоть до О(0) на промежуточные абстракции.
Я считаю, моя система - это достойная альтернатива системам, реализованным в UE4, Unity и Source для решения тех же задач.
За счёт разделения между редукцией/реконструкцией и кодеками, я упрощаю обе части системы как для разработки, так и для дальнейшего сопровождения и расширения. При этом, если профайлер впоследствии покажет затык на этом месте - остаётся возможность применить кодогенерацию и заставить классы дёргать кодеки напрямую, без сооружения физического промежуточного представления в памяти. Но только, если профайлер действительно покажет затык.

ZabПостоялецwww31 мая 20189:54#18
Delfigamer
> Что? Я не знаю никаких градей и бучей. А почему я должен знать? Он сделал что-то хорошее для геймдева?
Может скажешь еще что не заешь что такое объектно-ориентированное программирование? Буч - автор одной из ключевых монографий по объектно-ориентированному программированию. Ты как-то умудрился пройти мимо нее?

Правка: 31 мая 2018 9:54

gamedevforПостоялецwww31 мая 201811:56#19
Delfigamer
> Мне кажется, за счёт такой декомпозиции система получится, наоборот, проще, чем
> обычно получается.

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

Sh.Tac.Постоялецwww31 мая 201813:29#20
Zab
> объектно-ориентированное программирование?
ООП не нужно, и да, Гради Буч ничего не сделал хорошего для геймдева : )

Typical C++ Bullshit

Правка: 31 мая 2018 13:31

DelfigamerПостоялецwww31 мая 201813:48#21
gamedevfor
> Мне не нравится, лучше пройтись по дереву объектов в глубину которые
> автоматически запишут себя в поток данных.
Delfigamer
> - - желательно, чтобы с выходом новой версии движка старые ассеты по-прежнему
> открывались,
Если в новой версии у SpotLight появится параметр ProjectionTexture - мне вставлять в сериализатор спотлайта проверку на ProjectionTexture? Написать отдельную утилиту-конвертер? Послать всех на три буквы и пусть переделывают свои карты по-новой?
Delfigamer
> - - желательно, чтобы на этапе разработки, с ассетами можно было работать
> напрямую - отредактировал png-файл в папке, запустил игру - и тут же увидел
> изменения,
> - - желательно, чтобы на этапе реализации, ассеты можно было запаковать в
> архив, который займёт меньше места на диске и который быстрее загружается, за
> счёт отсутствия необходимости парсить текст,
> - - желательно, чтобы избыточность была сведена к минимуму - трафик был
> минимизирован - на том же канале можно будет транслировать больше динамических
> объектов,
Мне теперь делать по три сериализатора для каждого класса? Или в жопу геймплей, будем передавать текст по HTTP?

gamedevfor
> Информацию о типах лучше вообще не писать так как объект и сам знает что там
> должны быть за типы.
Не всегда. О фактическом типе актёров на уровне знают только сами актёры - Level знает только то, что у него куча Actor.
А в следующей версии, я расхочу хранить поворот в кватернионе - лучше сохранять общую 4*4 матрицу со скейлом и ништяками. Или решу, что события между актёрами должны передаваться не по ссылкам, а по тегам. Или сделаю ещё какое-нибудь изменение. Откуда мне знать, в каком месте я накосячу? И как по твоей схеме я должен определить, в каком виде хранятся позиции на этой конкретной карте? Хранить номер версии и проверять в каждом из трёх десериализаторов?
Ну и кроме того,
Delfigamer
> - - было бы неплохо, если бы ассеты можно было редактировать сами по себе, без
> реверс-инжиниринга форматов через код движка,

Zab
> Может скажешь еще что не заешь что такое объектно-ориентированное
> программирование?
Про ООП вроде слышал. Это когда ты для каждого класса описываешь свой собственный интерфейс? Или когда ты делаешь private: int x; public: int getx(); void setx(int newx);? Или это когда class Math {public: static float sqrt(float) throws(NegativeSqrtError);};? Не уверен, что это тот ООП, которым пользуюсь я.
Zab
> Буч - автор одной из ключевых монографий по объектно-ориентированному
> программированию. Ты как-то умудрился пройти мимо нее?
Ну как "умудрился", я её никогда и не искал.
Сегодня нашёл, глянул первую главу - говорит, компьютерные программы есть вещи сложные. Выглядит правдиво. Напоминает другую книжку, где автор рассказывал, что ПО - вещь сложная, а когда за сложностью не следят, она взлетает выше крыши и проект становится неподдерживаемым. Вроде, это был Steve McConnell, хотя могу и ошибаться.
Соответственно, контролем сложности я и занимаюсь - за счёт декомпозиции, я ограничиваю сложность отдельных компонент за счёт сужения круга задач, решаемых этими компонентами. Редуктор занимается только редукцией объекта до стандартной формы, и больше ничем. Реконструктор - напротив, получает уже готовую стандартную форму, и создаёт из неё объект. По другую сторону - разные кодеки, каждый работает исключительно со своим форматом, и только со ограниченным числом физических типов.
Собственно, "стандартная форма" - это граница (так же известная в некоторых кругах как "интерфейс") между объектом и форматом, которая не даёт особенностям одной стороны повлиять на другую. В результате, вместо одного большого и сложного модуля получаем несколько модулей поменьше и попроще - что, как правило, приводит к упрощению программы в целом.

gamedevforПостоялецwww31 мая 201814:18#22
Delfigamer
> Если в новой версии у SpotLight появится параметр ProjectionTexture - мне
> вставлять в сериализатор спотлайта проверку на ProjectionTexture?

Зачем? В старой версии игноришь, в новой юзаешь.

Delfigamer
> Не всегда. О фактическом типе актёров на уровне знают только сами актёры -
> Level знает только то, что у него куча Actor.
> А в следующей версии, я расхочу хранить поворот в кватернионе - лучше сохранять
> общую 4*4 матрицу со скейлом и ништяками. Или решу, что события между актёрами
> должны передаваться не по ссылкам, а по тегам. Или сделаю ещё какое-нибудь
> изменение. Откуда мне знать, в каком месте я накосячу? И как по твоей схеме я
> должен определить, в каком виде хранятся позиции на этой конкретной карте?
> Хранить номер версии и проверять в каждом из трёх десериализаторов?

Тогда лучше взять СУБД. Хотя и там менять структуры таблиц и связей это довольно болезненный процесс но там хоть есть для этого SQL.
Я хочу сказать что пытаться создать универсально гибкий всемогутер это плохая идея, у тебя должен быть хоть какой то железобетонный фундамент на который ты cможешь опереться иначе ты утонешь в поддержке этого дерьмеца.

gudleifrПостоялецwww31 мая 201814:22#23
DelfigamerПостоялецwww31 мая 201814:55#24
gamedevfor
> Зачем? В старой версии игноришь, в новой юзаешь.
Ты не понял. Я новой версией - где есть новое поле ProjectionTexture - открываю старый левел - где подобных текстур ещё не было даже в планах.
И откуда мне знать, что надо читать, а что - игнорить?

gamedevfor
> Тогда лучше взять СУБД.
А тут мне даже ничего придумывать не надо, всё уже было проаргументировано другими:
gamedevfor

там менять структуры таблиц и связей это довольно болезненный процесс

Alprog
По факту БД нужно как раз тогда, когда есть сервер, во всяких ММО, браузерках и социалочках. Там, где реально надо хранить большие объёмы данных, получать небольшое их количество и транзакционно изменять. Здесь же вообще история совершенно другая.

Здесь есть рантаймовые классы, дизайн которых никак не связан с нормальными формами и прочим гавном. Рантаймовые классы задизайнены таким образом, чтобы достигать максимального перформанса и удобства использования. Какая-то информация может дублироваться, например. Банальное кэширование, допустим. Но удобство даже важнее. Полями класса являются не какие-то там первичные ключи из другой таблицы, а тупо сами живые объекты (указатели на память). Во-первых, индиректов меньше; во-вторых, и это более важно, повышается читабельность и семантика кода. То есть логика рантайма вообще не заботится о том, в каком виде данные хранятся на диске. Она не кровоточит sql-запросами или ORM-дерьмищем. И потому её сложность растёт сильно медленнее с течением времени, и проект не захлёбывается. А ведь если ты хочешь проект закончить, то очень важно, как с этим всем будет работаться через годик, и насколько это будет гибко.

Сериализация тут подходит идеально. Она решает задачу "взять состояние игры в памяти, перенести его в некое промежуточное представление, и затем восстановить" (и NoSQL тут опять же ни при чём, не знаю, зачем ты это приплёл). Это может происходит во время сейвов; это может происходить во время разработки контента; также если мы коннектимся к каким-то локальным тулзам и плюёмся сообщения. Это банально происходит в момент нажатия кнопки Play в юнити-редакторе, чтобы сохранить состояние до игровой сессии и восстановить её по возвращению в edit-mode. Это же делаю и я в те же моменты, когда юнити это делает со своими данными. И заметь, сцены юнити сериализует в yaml. Догадываешься почему они не юзают БД? А я свои данные, которые, как и сцены, тоже, безусловно, являются контентом, также сериализую в свой формат. И не только юнити со мной солидарна. Я не знаю ни одного движка во всей индустрии, кто бы для этих целей использовал БД. Даже не слышал о таком.

(А затем он же рассказывает про проблемы монолитного сериализатора:
Alprog

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

)
gamedevfor
> Я хочу сказать что пытаться создать универсально гибкий всемогутер это плохая
> идея, у тебя должен быть хоть какой то железобетонный фундамент на который ты
> cможешь опереться иначе ты утонешь в поддержке этого дерьмеца.
А я и не создаю универсально гибкий всемогутер, я решаю чёткий набор задач для конкретной игры (тебе геймплей рассказать?). Просто по счастливой случайности и благодаря моему архитектурному гению система получилась такой универсальной и гибкой.
Или, по-твоему, неодноразовая игра с мультиплеером эти задачи не решает?
_

Что за хрень творится в сообщениях Така? Почему его текст вдруг подсвечивается рыжим? Это у тего так демоны просачиваются?

Правка: 31 мая 2018 15:04

gamedevforПостоялецwww31 мая 201817:07#25
Delfigamer
> Ты не понял. Я новой версией - где есть новое поле ProjectionTexture - открываю
> старый левел - где подобных текстур ещё не было даже в планах.
> И откуда мне знать, что надо читать, а что - игнорить?

Ну вот веброузеры как то открывают старый HTML и ты так же открывай. А если нужна точность то виртуализируй версии броузеров. Или нужно делать какой то автоматический конвертатор на лету.

А ты какое решение предлагаешь для этой проблемы?

DelfigamerПостоялецwww31 мая 201817:16#26
gamedevfor
> Ну вот веброузеры как то открывают старый HTML и ты так же открывай.
Вот только веб-браузеры как раз-таки работают через промежуточное представление, а не через
gamedevfor
> пройтись по дереву объектов в глубину которые автоматически запишут себя в
> поток данных, а информацию о типах лучше вообще не писать

gamedevfor
> А ты какое решение предлагаешь для этой проблемы?
Delfigamer

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

По сути - так же, как и веб-браузеры, через полные аннотации объектов и атрибутов внутри сериализации.
gamedevforПостоялецwww31 мая 201817:59#27
Delfigamer
> gamedevfor
> > Ну вот веброузеры как то открывают старый HTML и ты так же открывай.
> Вот только веб-браузеры как раз-таки работают через промежуточное
> представление,
>а не через
> gamedevfor
> > пройтись по дереву объектов в глубину которые автоматически запишут себя в
> > поток данных, а информацию о типах лучше вообще не писать

Одно другому не противоречит так как объект может себя записать в поток данных в виде XML или HTML.
Теги в документе и есть тот фундамент на котором можно произвольно менять их зависимость или вложенность без ущерба получить: invalid format.
Так что круче XML или HTML по гибкости формата сейчас сложно что либо придумать.

DelfigamerПостоялецwww31 мая 201818:03#28
gamedevfor
> Одно другому не противоречит так как объект может себя записать в поток данных
> в виде XML или HTML.
А читать как собрался? Регэкспами?
ZabПостоялецwww31 мая 201818:10#29
Delfigamer
Так, ты не программист, что ли? Нигде не учился?
А как игры писать собираешься? Уровень "основ программирования" общеинженерной подготовки тут явно недостаточен. Если не учился централизованно, значит самому все изучать придется. Очень много чего изучать... И уйдет на это в разы больше времени, чем если бы ты на программиста пошел учиться.
Страницы: 1 2 3 4 5 6 7 Следующая »

/ Форум / Программирование игр / Общее

2001—2018 © GameDev.ru — Разработка игр