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

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

Страницы: 1 2 3 4 5 6 7 Следующая »
gamedevforПостоялецwww31 мая 201818:16#30
Delfigamer
> А читать как собрался? Регэкспами?

Если XML не большие то можно обойтись TinyXML работая через XMLDOMParser, а если большие то нужно уже искать XMLSAXParser.

DelfigamerПостоялецwww31 мая 201818:31#31
Zab
> Так, ты не программист, что ли? Нигде не учился?
А чтобы быть программистом, надо обязательно где-то выучиться?

gamedevfor
> Если XML не большие то можно обойтись TinyXML работая через XMLDOMParser, а
> если большие то нужно уже искать XMLSAXParser.
Окей, ты получил DOM, а дальше что?

gamedevforПостоялецwww31 мая 201818:49#32
Delfigamer
> Окей, ты получил DOM, а дальше что?

Читаешь DOM, определяешь тип объекта по XML тегу и передаешь ссылку на XMLNode во внутрь создаваемого объекта, а потом внутри объекта опять читаешь XMLNode и снова определяешь тип объекта и так рекурсивно в глубину воссоздаешь своё окружение из XML.
Конечно не самый эффективный способ но самый простой и понятный. Самый эффективный это когда ты можешь сохранить образ памяти на диск и потом с диска сразу же прочитать и замапить этот образ поверх своих структур данных в RAM. Но такой хардкор был только до 2000-х.

DelfigamerПостоялецwww31 мая 201818:54#33
gamedevfor
> Читаешь DOM, определяешь тип объекта по XML тегу и передаешь ссылку на XMLNode
> во внутрь создаваемого объекта, а потом внутри объекта опять читаешь XMLNode и
> снова определяешь тип объекта и так рекурсивно в глубину воссоздаешь своё
> окружение из XML.
И чем это отличается от
Delfigamer
Десериализация производится в два этапа - сначала по считаной из источника (файла, сообщения) информации строится стандартная форма сущности, затем на основе этой формы конструируется рабочий инстанс. Конкретная процедура конструирования идентифицируется логическим типом сущности.
В общем случае, при конструировании инстанса, в агрегате ищутся заранее заданные пары <имя, логический тип>. Неизвестные пары имя-тип игнорируются (даже если имя известно). Если имеющихся пар имя-тип недостаточно для осмысленного реконструирования объекта - сообщается ошибка.

?

Правка: 31 мая 2018 18:55

gamedevforПостоялецwww31 мая 201818:58#34
Delfigamer
Наверное тем что ты изобретаешь колесо. )))
ZabПостоялецwww31 мая 201819:02#35
Delfigamer
> А чтобы быть программистом, надо обязательно где-то выучиться?
Если не в университете, то самостоятельно. Что-то я плохо представляю современного программиста, не только не умеющего применять ООП, но и с трудом представляющего что это такое.

Понятно, что и в университете можно так учиться, что ничего не усвоить, но занимаясь самостоятельно проблема в том, что ты не знаешь куда смотреть, что изучать. В результате много лет в никуда уходит. Сам ты до всего не дойдешь, открывать все в мире самостоятельно повторно - это и в 1980м не прокатывало, а сейчас в десятки раз больше всего в отрасли.

gudleifrПостоялецwww31 мая 201819:32#36
Zab
+ Показать

Правка: 31 мая 2018 19:43

DelfigamerПостоялецwww31 мая 201820:29#37
gamedevfor
> Наверное тем что ты изобретаешь колесо. )))
У XML есть один существенный недостаток - он слишком многословен для сетевого обмена. Алгоритмы сжатия общего назначения на RPC-сообщениях не сработают - они слишком короткие, а если объединить сообщения в один поток - начнутся проблемы с UDP и доставками.
Поэтому, у меня выделяется отдельный кодек для сетевого обмена. В общем случае, в нём передаётся обычная двоичная сериализация - что приемлимо для загрузки кастомных карт; тогда как для частых команд типа "мой чел прошёл на 10 метров вперёд" вводятся сокращённые формы.
А поскольку сериализация в XML уже подразумевает в себе промежуточное представление - DOM - то логично определять сокращённые формы в терминах DOM, просто потому что в DOM на порядки меньше терминов, чем в самом коде игры.
А раз у нас появляется два разных метода перехода между DOM и байтами - имеет смысл абстрагировать "переход между DOM и байтами" в отдельную операцию.
А раз нам в любом случае, как минимум для сетевых сообщений, понадобится собственный формат - то и зависимость от XML оказывается не нужна, а раз нет связи с XML - то и вместо DOM можно взять такую промежуточную форму, которая точнее опишет структуру объектов. Отсюда - и "стандартная форма", которая в 90% случаев кодогенерируется из рефлексии и атрибутов.
Ну и в конечном итоге приходим к тому, что описано в #0.
gamedevfor
> лучше пройтись по дереву объектов в глубину которые автоматически запишут себя
> в поток данных
На самом деле - это почти рабочий вариант. Редукцию вполне можно реализовать как
void AProjectile::serialize(Archive& archive)
{
  auto scope = archive.structscope(SFTypeTraits<AProjectile>::id); // 'scope' is an RAII helper object
  scope.write(NAME("position"), this->position);
  scope.write(NAME("velocity"), this->velocity);
  scope.writereference(NAME("shooter"), this->shooter);
  scope.writeint(NAME("team"), this->team);
}

а в методах XMLArchive на каждый writexxx тут же выливать теги в завёрнутый внутрь поток. Но опять же, общение между объектом и кодеком всё равно происходит через стандартную форму - благодаря этому, у нас будет единственный метод serialize, который через единственный интерфейс будет писать и в XML, и в двоичные паки, и в сетевые сообщения с автоматическими сокращениями.
С другой стороны, работа каждого отдельно взятого кодека тоже ничего сложного не представляет - потому что ему достаточно сериализовать шесть разных объектов, и его работа выполнена.
А если эти простые компоненты собрать вместе - получится мощный и гибкий инструмент, что некоторые даже назовут его универсальным и всемогутером, хотя это вовсе не верно. Например, он не создан для работы с десятками и сотнями тысяч таблиц - с этой задачей реляционная БД справится намного лучше. Зато для задач, описанных в #17 - подходит очень хорошо.

Zab
> Что-то я плохо представляю современного программиста, не только не умеющего
> применять ООП, но и с трудом представляющего что это такое.
Если что - это был сарказм. Я прекрасно понимаю, что ООП - это всего лишь один из способов линеаризовать матрицу тип/поведение, тогда как второй способ - это структурное программирование.
А ты, кстати, это понимаешь?

gudleifr
> Про сиплюсплюсников слышали?
А это вкусно?

Правка: 31 мая 2018 20:29

gamedevforПостоялецwww31 мая 201821:58#38
Delfigamer
> У XML есть один существенный недостаток - он слишком многословен для сетевого
> обмена.

А это scope.writereference(NAME("shooter") не многословно? Ты не можешь определить shooter по смещению?

> Алгоритмы сжатия общего назначения на RPC-сообщениях не сработают - они
> слишком короткие,

Самому нужно жать.

>а если объединить сообщения в один поток - начнутся проблемы
> с UDP и доставками.

В любом случае нужно сообщения формировать по приоритету, а не валить всё сообщения в одну кучу. Потому что есть сообщение часто отправляемые, а есть редкоотправляемые для которых и TCP/IP сойдет.

DelfigamerПостоялецwww31 мая 201822:34#39
gamedevfor
> А это scope.writereference(NAME("shooter") не многословно? Ты не можешь
> определить shooter по смещению?
Без разницы, этот код генерируется кодогенератором и разруливается компилятором.

gamedevfor
> Самому нужно жать.
Читай внимательнее - я про это и говорю, что самого по себе XML настолько недостаточно, что можно от него отказаться вообще и почти ничего не потерять.

gamedevforПостоялецwww31 мая 201822:41#40
Delfigamer
Если сделать всё через жопу то и бинарный формат не поможет достичь производительности по сети.
Так что формат сообщений это низкоуровневая и преждевременная оптимизация.
Sh.Tac.Постоялецwww1 июня 20181:44#41
Delfigamer
> Если что - это был сарказм. Я прекрасно понимаю, что ООП
дофига noexcept : )

я на это дело забивал в силу ретрогадства, потом понял что и правильно : )
вот например чувак пишет, что спецификатор нужен ровно для одного случая
https://akrzemi1.wordpress.com/2014/04/24/noexcept-what-for/

tacПостоялецwww1 июня 20182:47#42
Delfigamer
наукообразный бред это, а не архитектура
tacПостоялецwww1 июня 20182:51#43
Delfigamer
> Я не знаю никаких градей и бучей. А почему я должен знать? Он сделал что-то
> хорошее для геймдева?
шутка не удачная
tacПостоялецwww1 июня 20182:58#44
Delfigamer
> Что за хрень творится в сообщениях Така? Почему его текст вдруг подсвечивается
> рыжим? Это у тего так демоны просачиваются?
похоже кто то нажрался до чертиков :)
Страницы: 1 2 3 4 5 6 7 Следующая »

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

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