Как вы организуете сохранение состояния мира в процедурно-генерируемых играх? Делитесь архитектурой
Рейтинг: 57% · 16 голосов
Войдите, чтобы голосовать
Голосовать «За» и «Против» могут только авторизованные пользователи. Войдите в свой аккаунт — или зарегистрируйтесь, это займёт минуту.
Нет аккаунта? Зарегистрироваться
Как вы организуете сохранение состояния мира в процедурно-генерируемых играх? Делитесь архитектурой
Делаю roguelike с процедурными подземельями на Unity 6. Столкнулся с классической проблемой: как сохранять состояние мира, если он генерируется на лету? Чанки, которые игрок уже посетил, должны сохраняться (сундуки открыты, враги убиты, двери сломаны), а не генерироваться заново при возврате. При этом непосещённые чанки генерировать по сиду. Сейчас у меня каждый чанк сериализуется в JSON при выгрузке, но при большом мире это уже ~40 МБ файла сохранения после часа игры. Интересно, как другие решают эту задачу.
✔ Лучший ответ сформирован автоматически — kickmybox
40 МБ за час — это явно что-то не так с гранулярностью. Зачем сохранять весь чанк? Сохраняй только дельту от seed-состояния. Логика такая: при загрузке чанка генеришь его из сида, потом применяешь список изменений (delta). Delta — это просто список событий: [{ type: chest_opened, id: 42 }, { type: enemy_killed, id: 7 }]. В итоге сохранение чанка, где игрок убил 5 врагов и открыл 2 сундука — это 7…
Re: Как вы организуете сохранение состояния мира в процедурно-генерируемых играх? Делитесь архитектурой
✔ Лучший ответ — сформирован автоматически
40 МБ за час — это явно что-то не так с гранулярностью. Зачем сохранять весь чанк? Сохраняй только дельту от seed-состояния. Логика такая: при загрузке чанка генеришь его из сида, потом применяешь список изменений (delta). Delta — это просто список событий: [{ type: chest_opened, id: 42 }, { type: enemy_killed, id: 7 }]. В итоге сохранение чанка, где игрок убил 5 врагов и открыл 2 сундука — это 7 записей, а не весь чанк целиком.
- regexlover
- Сообщения: 18
- Зарегистрирован: 21 май 2026, 11:59
Re: Как вы организуете сохранение состояния мира в процедурно-генерируемых играх? Делитесь архитектурой
Используем подход с двухуровневым хранением. Первый уровень — SQLite прямо в проекте (через плагин), там хранится таблица chunk_deltas (chunk_x, chunk_y, seed, events_json). Второй уровень — in-memory кеш активных чанков. При сохранении только flush изменённых чанков. SQLite даёт транзакционность, не боишься partial write при краше игры. Размер сохранения у нас после 10 часов игры — около 2 МБ.
Re: Как вы организуете сохранение состояния мира в процедурно-генерируемых играх? Делитесь архитектурой
@regexlover, MessagePack вместо JSON даст тебе сжатие примерно в 3-5 раз без изменения архитектуры. Это не решение проблемы, но быстрая победа пока ты думаешь над нормальной архитектурой. В Unity есть несколько реализаций, K4os.Compression.LZ4 в связке с ним даёт ещё лучше.
Re: Как вы организуете сохранение состояния мира в процедурно-генерируемых играх? Делитесь архитектурой
Важный момент который все забывают: версионирование формата сохранений. Когда ты обновишь игру и добавишь новые типы объектов или изменишь генерацию — старые сохранения сломаются. Заложи с самого начала поле version в формат и migration-логику. Боль от этого в продакшне несравнимо больше, чем размер файла.
Поделиться темой:
✈ Telegram
VK
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей