Войти
ПрограммированиеФорумОбщее

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

Страницы: 1 2 3 4 5 6 7 Следующая »
#30
18:16, 31 мая 2018

Delfigamer
> А читать как собрался? Регэкспами?

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


#31
18:31, 31 мая 2018

Zab
> Так, ты не программист, что ли? Нигде не учился?
А чтобы быть программистом, надо обязательно где-то выучиться?

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

#32
18:49, 31 мая 2018

Delfigamer
> Окей, ты получил DOM, а дальше что?

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

#33
(Правка: 18:55) 18:54, 31 мая 2018

gamedevfor
> Читаешь DOM, определяешь тип объекта по XML тегу и передаешь ссылку на XMLNode
> во внутрь создаваемого объекта, а потом внутри объекта опять читаешь XMLNode и
> снова определяешь тип объекта и так рекурсивно в глубину воссоздаешь своё
> окружение из XML.
И чем это отличается от
Delfigamer

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

?
#34
18:58, 31 мая 2018

Delfigamer
Наверное тем что ты изобретаешь колесо. )))

#35
19:02, 31 мая 2018

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

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

#36
(Правка: 19:43) 19:32, 31 мая 2018

Zab

+ Показать
#37
(Правка: 20:29) 20:29, 31 мая 2018

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
> Про сиплюсплюсников слышали?
А это вкусно?

#38
21:58, 31 мая 2018

Delfigamer
> У XML есть один существенный недостаток - он слишком многословен для сетевого
> обмена.

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

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

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

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

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

#39
22:34, 31 мая 2018

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

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

#40
22:41, 31 мая 2018

Delfigamer
Если сделать всё через жопу то и бинарный формат не поможет достичь производительности по сети.
Так что формат сообщений это низкоуровневая и преждевременная оптимизация.

#41
1:44, 1 июня 2018

Delfigamer
> Если что - это был сарказм. Я прекрасно понимаю, что ООП
дофига noexcept : )

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

#42
2:47, 1 июня 2018

Delfigamer
наукообразный бред это, а не архитектура

#43
2:51, 1 июня 2018

Delfigamer
> Я не знаю никаких градей и бучей. А почему я должен знать? Он сделал что-то
> хорошее для геймдева?
шутка не удачная

#44
2:58, 1 июня 2018

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

Страницы: 1 2 3 4 5 6 7 Следующая »
ПрограммированиеФорумОбщее