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

Сериализация vs. базы данных в юнити (4 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#45
8:13, 6 апр. 2018

Alprog
> как же тогда быть в следующих ситуациях:
детский сад, так и работаем уже 15+ и как то никто никому не мешает, даже не замечает, ключевой момент, что каждый работает над своей задачей

а в Перу работать не надо, пусть или баб тискает, или воду пьет, но нарушать безопасность работы с продуктом не надо

#46
8:17, 6 апр. 2018

tac
> детский сад, так и работаем уже 15+ и как то никто никому не мешает
Ну так поведай нам, как у вас работа организована. Расскажи, что за система контроля версий, сколько у вас комитов в день, каким образом система версий синхронизирована с бд и синхронизирована ли вообще.
Вангую, что у вас SVN. Хотя не удивлюсь, если у вас исходники тупо в Dropbox ваще лежат :D

> а в Перу работать не надо
Ну, здрасти, приехали. Чё мне в России всю зиму сидеть?

#47
8:44, 6 апр. 2018

tac
> все там решаемо .. другой вопрос, согласен, более трудоемко, но и более стабильно
Вот именно, главное отличие сериализации блобами от транзакций над графом - они по-разному скейлятся с ростом структурной сложности игры. Это как insertion sort/quick sort - один растёт как O(n2), второй - как O(n log n). На неограниченно больших массивах, разумеется, эн-логарифм окажется быстрее квадрата, зато при малых эн - наоборот, квадрат оказывается ниже; поэтому большинство реальных функций переключается между алгоритмами в зависимости от размера - большие массивы делит логарифмами, а маленькие кусочки досортировывает квадратом.
То же самое с выбором БД/сериализация - база имеет свои плюсы, которые позволяют ей превосходить сериализацию при хранении больших объёмов информации.
Проблема лишь в том, что сцена в стандартной ААА игре даже близко не подходит к той критической точке, где БД обходит сериализацию.

#48
8:49, 6 апр. 2018

tac
> он отличается от клонирования в памяти
Ты отладчиком разбирал какой формат в памяти? С чего ты вообще взял, что отличается?

#49
9:02, 6 апр. 2018

Delfigamer
> Проблема лишь в том, что сцена в стандартной ААА игре даже близко не подходит к той критической точке, где БД обходит сериализацию.
Даже если сцена начнёт занимать 500 МB, можно разделить объекты сцены на подгруппы, каждая примерно по 1 Mb, сериализовывать только изменившиеся, а записывать в файл чанками по 64 kb (поверх старых, свободных или в конец).
И вот мы ещё на пару порядков допустимый размер сцены увеличили без видимых потерь производительности.

Но дело даже не в этом. Централизованная бд полностью убивает любую возможность распределённой работы над проектом. Откуда вообще такие гениальные подходы? Из 2002 года что ли?

БД применяют в играх для хранения какой-нибудь инфы, которая имеет смысл только в единственном текущем состоянии (то есть не делится на ветки и не скачет по истории), при этом её много и она часто читается и меняется в произвольных местах.
Например, информация об игроках в ММО. Это имеет смысл. Но применять бд для сцен… кем это надо быть?

#50
9:45, 6 апр. 2018

Delfigamer
> Проблема лишь в том, что сцена в стандартной ААА игре даже близко не подходит к
> той критической точке, где БД обходит сериализацию.
ну это спорное утверждение, я уже на нескольких примерах показал как быстро это наступает, у оппонентов же голословные утверждения. Покажите ваш пример такой сцены, где БД будет хуже? еще раз она будет уступать лишь по трудоемкости разработки, а не в работе.

#51
9:50, 6 апр. 2018

tac
> ну это спорное утверждение, я уже на нескольких примерах показал как быстро это
> наступает
Ты не учитываешь стоимость реализации
> — Откат локальных изменений сцены из системы контроля версий;
> — Merge изменений, внесённых на одну и ту же сцену с разных компьютеров;
> — Тестирование внесённых изменений с последующим откатом обратно;
> — Функция «Save as…» с копированием сцены целиком;
> — История изменений для Undo/Redo;
> — Перенос сцены из одного проекта в другой.

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

Alprog
> Даже если сцена начнёт занимать 500 МB, можно разделить объекты сцены на
> подгруппы, каждая примерно по 1 Mb, сериализовывать только изменившиеся, а
> записывать в файл чанками по 64 kb (поверх старых, свободных или в конец).
Ага, а потом мы захотим защиту от падения электричества, начнём дописывать журналы, журналы будут работать через транзакции, и получится по сути ещё одна БД, только велосипедная.

#52
9:51, 6 апр. 2018

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

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

а теперь подумай, зачем вообще ввели систему контроля версий?

#53
9:58, 6 апр. 2018

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

#54
10:18, 6 апр. 2018

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

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

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

Вообщем Так, ты заканчивай "никогда не признавать свои ошибки". А то прямо второй Навальный.

#55
10:30, 6 апр. 2018

Delfigamer
> Ага, а потом мы захотим защиту от падения электричества, начнём дописывать журналы, журналы будут работать через транзакции, и получится по сути ещё одна БД, только велосипедная.
Ну, файлы по 500Mb это в любом случае уже плохая идея. Хотя бы в силу того же git'a. Лучше много-много маленьких. В билде, конечно, слепим, в один файл.

tac
> исходники размещались в сети, но доступ к ним блокировался для редактирования, если кто то уже редактировал
Ну зашибись, Perforce на коленке. Только сейчас 2018 год и лочить файлы позволительно разве что художникам. И то не всем.
А программисты так давно уже не работают. Если ты гавно 20+ лет жрёшь, это не значит, что так и надо.

#56
10:50, 6 апр. 2018

tac
> так зачем у тебя еще каке то сцены, кроме юньковских?
У меня своя компонентная система (не путать с ECS, у меня — просто контейнеры и компоненты). Я упирал на то, что мои сущности сериализуются ровно в той же логике, в которой сериализуются сцены в юнити.
Но ты стал говорить, что сцены юнити тоже надо было, по-хорошему, хранить в бд. С тех пор мы обсуждаем, как же надо всё-таки хранить сцены; потому как от этого строится вся остальная аргументация.

> давай я для начала расскажу
Так всё-таки. Тот проект, где у вас 15+ человек и база данных, у вас там есть система контроля версий или нет? Очень хочется понять.

#57
11:11, 6 апр. 2018

MixeYa
> А то прямо второй Навальный.
Ха-ха, нашел же место втулить религиозную политическую позицию.

Как по мне, на второго Порошенко больше похож. И немножко на третьего Трампа.
#58
11:12, 6 апр. 2018
Про политику не надо больше. Запрещено же у нас.
#59
11:40, 6 апр. 2018

Alprog
Та да. Стоило только помянуть, прибежало тело непонятно откуда что-то тут разжигать.

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

Тема в архиве.