Encased (4 стр)

fantomass
О свой человек, также добавлю удобно делать поиск и массовые правки.

ReeV
> Кстати, мы в ATOMе, выбрали ручную сериализацию, что бы иметь больше контроля. Это уже дало свои плоды, когда приходиться поддерживать старые версии сейва.
У меня есть сериализация пропертей, что даёт ту же ручную сериализацию там, где это нужно (настоящие поля не сохраняются, а сериализуются приватные проперти, которые служат для них ридерами/райтерами).
Если вдруг и это становится неудобно, то всегда можно для класса вообще отдельный форматтер написать. Но для большинства случаев это не требуется и достаточно правильно расставить атрибуты.
Что касается версионности, то переделки атрибуции на манер протобуфа как раз для поддержки версионности я и делал. В этом смысле всё ок.

fantomass
> Для дебага - в джейсон. В релизе в джейсоне оставить только схемы, по которым грузить из бинаринка.
Здесь бинарник по сути вариация BSON, так что его всегда можно в виде JSON представить. Единственное, там будет мешанина из служебных цифр и без схемы её разобрать невозможно (а схемой служит на самом деле сама кодобаза с атрибутами). Но для дебага я хочу сделать аннотированный вариант JSON-представления с именами полей. Это будут лишь human-readable подсказки, которые на сами данные не будут никак влиять (система спокойно переживает переименование любого поля).

tac
> попробуй напиши зачем тебе сериализация, и почему ты не используешь базы данных, тогда и увидем кто дурачок? а то что хам уже видно.
Да-да, разумеется, базы данных это чудо невероятное, решающее все проблемы и не имеющее недостатков, и его надо безмозгло тащить в любой проект, потому что ты где-то там у себя применил и на твоём проекте тебе норм. Особенно всё хорошо у них с интеграцией с системами контроля версий и никаких проблем при мёрдже конфликтов, и вообще БД совсем не вносит лишних сущностей и зацепления между классами совсем не плодит. И раз ты всё для себя уже давно понял, то предлагаю пойти уже обратно в свой манямирок ахитектурной астранавтики; тем более, что здесь только хамы какие-то собрались совсем ничего в геймдеве не соображающие.

Горячий стиль!

Supperfrak
Мы парни горячие, зимой без шапки ходим, ага :D

Alprog
> здесь только хамы какие-то собрались совсем ничего в геймдеве не соображающие
ну похоже конечно на правду, но заметь это твои слова

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

поэтому если и обсуждать, то Реляционные базы данных vs. объектные ... сериализация то вообще то появилась для клиент- серверных архитектур, но что то я сомниваюсь, что у вас сетевая игра .. поэтому меня очень напрягают люди которые не знают что такое 3 нормальная форма, а все тутаже json им не такой, и для хрени не стоящей выяденного яйца занимаются сериализацией ради сериализации .. это хрень собачья .. учите ну например sqlite на клиенте и не занимайтесь хренью

и заметь, ни каким проблем у sqlite с контролем версий нет

tac
> очень напрягают люди которые не знают что такое 3 нормальная форма
О да, первая лекция по БД в универе — это великое знание, которое нам, простым смертным, недоступно. Клоун.

Alprog
> JSON
Ну кстати есть ещё один забавный и ленивый вариант - гзипить. Получается нечто среднее и часто работает шустрее, чем не гзипнутый бинарник, например.

fantomass
Не пробовал архивировать бинари, но пакует данные месаджпак довольно эффективно. Например, интовые значения он записывает кусками по 7 бит (8 бит указывает, нужно ли продлевать на следующий байт).
То есть каких-то участков повторяющихся данных типа нулей там почти не будет и вряд ли сильно пожмётся. А текстовый JSON мессаджпак даже читать не умеет (его парсить было бы слишком медленно всё равно).

Alprog
Ну да, бинарники поэтому и не жмут, что там энтропия значительно ниже. Больше времени на распаковку уйдёт, чем на загрузку с тормозных накопителей. А джейсон - стопицот одинаковых полей. Прочитал 10кб и в шустрой оперативке распаковал в 110кб. Только на тексте такое и прокатывает..

Но это да, это я плохой пример привёл таки с гзипнутым бинарником :)

То есть, суммируя: гзип быстрее не гзипа джейсона, но не быстрее бинарника. НО! Бинарник - не гибок, когда джейсон - очень гибок. Поэтому, если охото сохранить гибкость без особых усилий, с приемлемой производительностью - гзип среднее, ленивое, а значит - идеальное решение ;D

Alprog
Клоун тут только тот, кто не применяет знания полученные в универе .. вот реально бездарь .. по сути то тебе и ответить нечего, юзай свой велосипед, вот только нахрена тут этим грузить других? реально впечатление получается как от двоешника

расскажи местным студентам, как ты в сериализации достиг 3 нормальной формы .. поржем вместе, двоешник

fantomass
Ты не понял, бинарник повторяет структуру JSON. То есть в любой момент времени ты можешь бинарник сконвертировать в JSON, имея на руках только сам бинарник (безо всяких схем). Но этот JSON тоже не будет содержать информацию о названиях полей, там будут только сами значения, иногда индексы и другие служебные инты, которые мало что объясняют. Бесконечно повторяющихся стрингов, которые хорошо жмутся, там тоже не будет :) Но для дебага, как я уже говорил, планирую писать дополнительную инфу.

tac
> Клоун тут только тот, кто не применяет знания полученные в универе .. вот реально бездарь
Распространённое заблуждение. Сколько таких было, которые в продакшен тащили академку. Мой любимый пример это когда идиоты, позаканчивав универы, начинают применять свои знания по ИИ:
— Как же так, — мол, — какие вы тут бездари, не знаете о том, что в универах учат. Сейчас мы, — говорят, — быстренько сбацаем вам, как в лучших домах Парижа и Лондона нейронку или экспертную систему.
Ну и естественно, когда дело доходит до боевого применения, никуда, кроме как в унитаз, эти их замечательные нейронки не идут.
Твой пример пусть не столь яркий, но из той же оперы. Наслушался в своё время чё-то там про данные, и пихаешь теперь всюду, чуть что хоть как-то связано с хранением данных в святой убеждённости, что умнее всех. Это с первой твоей фразы в треде, в принципе, было понятно. А по факту БД нужно как раз тогда, когда есть сервер, во всяких ММО, браузерках и социалочках. Там, где реально надо хранить большие объёмы данных, получать небольшое их количество и транзакционно изменять. Здесь же вообще история совершенно другая.

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

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

На самом деле, мне вот совсем не интересно спорить лично с тобой. Мне важно было свою позицию донести до остальных читателей треда. Но каждый раз тратить на тебя время не охота.
Предлагаю тебе сказать (если есть желание) своё последнее слово, и отправится по своим делам.

Alprog
> мне вот совсем не интересно спорить лично с тобой. Мне важно было свою позицию
> донести до остальных читателей треда
аналогично, ты лишь один из треда, мнение которого я реально не понимаю ..
Про ИИ ты мимо, я как то так получилось, что автор ряда научных статей в ИИ, но отчетливо понимаю, что многие бредят нейронками, т.к. в них не понимают /про нейронки я тут только с kipar буду обсуждать, если он пожелает/ .. Аналогия хромает ..

Alprog
> Здесь есть рантаймовые классы, дизайн которых никак не связан с нормальными
> формами и прочим гавном
а что так? конечно ля ля можно просто .. но у тебя что простые классы, приведу простой пример, расскажи как его сериализуешь

class A {
public string Aa;
}

class B {
public List <A<A>> BList;

}

class C
{
public List<A<A>> CList;
}

давай, только серьезно расскажи, как это не имеет отношения к 3 нормальной форме? Ну или расскажи как ты сделал такой подвиг, что у тебя объекты классов не вступают в отношения 1: ко многим, более 1 раза. Расскажи как твои классы кровоточат атрибутами? Расскажи какую крутую оптимизацию ты сделал, сохранив данные по значению 100500 раз?
И напиши, как универсально круто это сериализуется не думая о смысле того, что сериализуется.

Ну или опиши как ты сделал базу данных на коленке, у тебя появились первичные ключи для представленного примера? ну тогда рассказывай это, а не те общие слова, которыми ты кормишь детей.

И тебе пусть студенты расскажут какого хрена им это надо? Где ты экономишь? На святой вере, а не на науке. Поэтому не спорь, иди учись.

Alprog
Да не, я понял о чём там у вас. Я больше гипотетически, для общих случаев. Всё же смысл использовать джейсона - это больше дебаг, когда надо зайти и ручками поковырять или прочитать что там засериализовалось, либо/и как универсальный протокол обмена данными. А когда протокол устоялся и отдебажился - оптимизировать в бинарники. А сразу в бинарник или в обфусцированном виде.. хмхмхм.. и теперь дописывать ещё обёртку?.. Ну надо подумать ))

tac
> но отчетливо понимаю, что многие бредят нейронками, т.к. в них не понимают
Дело не в том, что нейронки пытаются делать те, кто в них не понимает. Дело в том, что те, кто разбирается в нейронках, тащат их туда, где они неприменимы. Проблемы с ними начинаются, когда, например, нужно внести костыльные правки в логику по воле геймдизайнера. А научные статьи это, конечно, восхительно. Но есть тут у нас форумный сумасшедший, тоже из научной сферы, который пишет всякие руководства, как делать игры по госту; со всякими расчётами и научными выкладками. Александр Патрашов у него ник, если не ошибаюсь. Стоит ли говорить, что там полная ахинения? Из твоих речей у меня пока нет оснований считать, что ты сильно далеко ушёл.

> приведу простой пример, расскажи как его сериализуешь
А что тебя тут смущает? Цикличные ссылки что ли? Объект по значению сериализуется только один раз. В дальнейшем будет писаться только ссылка на него. Или ты про строки? Ну, если в памяти реально представлено 100500 одинаковых строк, то они 100500 раз сохраняться на диск. Оптимизации я тут не делаю. Да и не зачем.

> Поэтому не спорь, иди учись.
Ты мне всё-таки назови хоть одну компанию-разработчика игр, которая бы сцен-граф геометрии уровня хранила бы не в сериализованном xml/json/yaml, а в базе данных. Valve? Blizzard? Naughty Dog? Все выдумывают какую-то ерунду, чтобы базы данных не учить, верно? Исчезни уже, грамотей.

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