Cr0c писал(а):Можно же вручную брать из структуры массив байт ((де)сериализатор написать).
Я, когда-то давно, писал такой. У меня первая версия была по 20 кб на запись, а шестая 50+ кб на 100 записей.
Это интересно, но для меня- темный лес. В какую сторону копать? Туториалы, примеры?
Tolking писал(а):Инженер, Используй эту процедуру для заполнения данных и расскажи нам про объём...Синтаксис:Используется csharp
public void SetValue()
{
this.allData = "";
for (int i = 0; i < 11; i++)
{
if (this.allData != "") this.allData += " ";
this.allData += Random.Range(1000000000, 2000000000).ToString();
}
}
P.S. Странный ты... Используешь потоки, пространство имен, знаешь как обозначается время поиска элемента в массиве, опять же сериализация вместо сохранения и при этом задаешь наивные вопросы... Уж не троль ли ты жЫрный?
140 мб. Ну да, это была глупая надежда Просто хотелось понять, в чем дело. Ссылочный тип, теперь все ясно. Я не проф. программист, это мое хобби по вечерам. Поэтому нет глубокого понимания темы
На днях обдумал обходные пути для решения проблемы огромного размера данных, т.к. одним лишь переводом float в byte вопрос не решить. Если есть еще идеи, милости прошу дополнить.
1. Ограничить размер мира до 1-2 км2.
МИНУСЫ: слишком мало.
ОЦЕНКА: вряд ли.
2. Уменьшить количество сериализуемых объектов. Это приведет к обнулению состояния некоторых объектов, от которых игрок отойдет на небольшое расстояние. Например, не сохранять выкошенную траву.
МИНУСЫ: теряется фишка игры.
ОЦЕНКА: если не хранить в файле данные о каждом пучке травы, это уменьшит размер файла в разы. 16 млн объектов брались как раз из расчета на то, чтобы запоминать положение каждого пучка травы. Нужно найти другой вариант, как запомнить, где игрок выкосил траву. Например, с помощью маски, триггера или типа того. Триггеры можно со временем удалять, типа трава выросла обратно и держать их на сцене постоянно, ограничив количество. Иначе не получится строго контролировать количество триггеров и файл сохранения раздуется. Можно найти другие типы второстепенных объектов, которые не сериализовывать.
3. Уменьшить количество сохраняемых значений у объектов.
МИНУСЫ: уменьшать некуда.
ОЦЕНКА: нет.
4. Сохранять каждый чанк мира в отдельном файле, а не в одном общем. Подгружать по мере необходимости асинхронно. Например, кусками 100х100 метров.
МИНУСЫ: чтение/запись даже в отдельном потоке иногда вызывает лаги. Необходимость перепроектирования уже работающей системы, рассчитанной на цельный файл.
ОЦЕНКА: в целом вариант может оказаться рабочим. Но не известно, можно ли решить проблему с лагами. Нужны тесты. Оставлю на крайний случай, если варианта 2 будет не достаточно.
5. Хранить большую часть значений каждого объекта или групп объектов в отдельном файле. Либо хранить все значения каждого объекта в отдельных файлах, т.е. файл мира содержит только ссылки на другие файлы.
МИНУСЫ: постоянно дергать жесткий диск подгрузкой и сохранением сотен микро файлов, даже в отдельном потоке могут быть лаги. Если сохранять в 2 файла (трансформы + параметры), нет выигрыша по памяти. Если группами, то выигрыш есть, но тогда уж лучше весь мир разбить на отдельные файлы (вариант 4). Плюс необходимость перепроектировать уже созданную систему.
ОЦЕНКА: нет.
6. Создать свой (де)сериализатор, как сказал Cr0c. Уменьшит размер файла и время сохранения/загрузки игры.
МИНУСЫ: Не поможет уменьшить объем данных в оперативке. Сложно.
ОЦЕНКА: Займусь, если найду достаточно информации по этой теме.