Разработка системы сохранения прогресса мобильной игры

Потеря прогресса — худшее, что может случиться с игроком. Прошёл 30 уровней, купил бустеры, разблокировал персонажей — и после переустановки или смены устройства ничего нет. Рейтинг в магазине падает, пользователь уходит. Недавно к нам обратился клиент: после обновления все сохранения оказались битыми, 15% активной аудитории ушло за неделю. После внедрения нашей системы отток сократился до 2%, а рейтинг в магазине вырос с 3.2 до 4.5 звезд. Мы знаем, как этого избежать.

Мы разрабатываем систему сохранения под ключ для игр на Unity, Android, iOS и кроссплатформенных проектах. За 5 лет реализовали более 40 игр, гарантируя сохранность данных и бесшовный пользовательский опыт. Оценим ваш проект — свяжитесь с нами, чтобы обсудить детали.

Какие данные нужно сохранять и где?

Прогресс игры включает несколько типов данных с разными требованиями к надежности и скорости доступа:

• Критические данные: уровень, валюта, покупки. Должны синхронизироваться с сервером — никогда не теряться. Хранятся локально + облако.
• Игровой прогресс: пройденные уровни, достижения, разблокированные предметы. Локально + опциональная синхронизация.
• Пользовательские настройки: громкость, управление, графика. Только локально — потеря некритична.
• Сессионные данные: текущий уровень, позиция, временные баффы. Только в памяти — не требуют персистентности.

Локальное хранение

Для простых игр — JSON-файл или SharedPreferences/UserDefaults. Для сложного прогресса с множеством сущностей — SQLite через Room.

@Entity(tableName = "save_data")
data class SaveDataEntity(
    @PrimaryKey val playerId: String,
    val level: Int,
    val experience: Long,
    val coins: Long,
    val gems: Int,
    val unlockedLevels: String,  // JSON array
    val inventory: String,       // JSON array
    val achievements: String,    // JSON array
    val settings: String,        // JSON object
    val lastSavedAt: Long,
    val version: Int = 1         // для миграций формата
)

Для Unity — PlayerPrefs для простых значений, Application.persistentDataPath + бинарный файл для сложных структур. BinaryFormatter устарел в современных версиях Unity — используем JsonUtility или Newtonsoft.Json + File.WriteAllBytes.

// Unity: сохранение через JsonUtility
[Serializable]
public class SaveData {
    public int level;
    public long coins;
    public List<string> unlockedItems = new List<string>();
    public int[] levelStars; // 3 звезды на каждый уровень
    public long savedAt;
}

public class SaveSystem : MonoBehaviour {
    private const string SAVE_FILE = "save.json";

    public static void Save(SaveData data) {
        data.savedAt = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds();
        string json = JsonUtility.ToJson(data);
        string path = Path.Combine(Application.persistentDataPath, SAVE_FILE);

        // Сначала пишем в temp, потом переименовываем — атомарная операция
        string tempPath = path + ".tmp";
        File.WriteAllText(tempPath, json);
        File.Move(tempPath, path, overwrite: true);
    }
}

Запись через temp-файл с последующим переименованием — защита от корруптированного файла при крэше во время записи.

Облачная синхронизация

Для кроссплатформенных игр — собственный бэкенд. Для iOS-only — Game Center + iCloud. Для Android — Google Play Games Services. Для Unity — обёртки над обоими.

// Android: Google Play Games Services
GamesSignInClient.signIn().addOnCompleteListener { task ->
    if (task.isSuccessful) {
        PlayGames.getSnapshotsClient(activity)
            .open(SNAPSHOT_NAME, true, SnapshotsClient.RESOLUTION_POLICY_MOST_RECENTLY_MODIFIED)
            .addOnSuccessListener { dataOrConflict ->
                if (dataOrConflict.isConflict) {
                    resolveConflict(dataOrConflict.conflict)
                } else {
                    loadFromSnapshot(dataOrConflict.data)
                }
            }
    }
}

Google Play Games Snapshots API автоматически управляет конфликтами при RESOLUTION_POLICY_MOST_RECENTLY_MODIFIED — побеждает более свежее сохранение. Для большинства игр этого достаточно.

Сравните облачные решения:

Согласно документации Apple, CloudKit обеспечивает автоматическое разрешение конфликтов на основе временных меток. В одном проекте внедрение серверной валидации позволило сэкономить более $10,000 в месяц на возвратах от читеров.

Почему важна миграция формата?

Формат данных меняется с обновлениями игры. Нужна миграционная система:

class SaveMigrator {
    fun migrate(data: SaveDataEntity): SaveDataEntity {
        var current = data
        while (current.version < CURRENT_VERSION) {
            current = when (current.version) {
                1 -> migrateV1toV2(current)
                2 -> migrateV2toV3(current)
                else -> throw IllegalStateException("Unknown version: ${current.version}")
            }
        }
        return current
    }

    private fun migrateV1toV2(data: SaveDataEntity): SaveDataEntity {
        // В версии 2 добавили daily challenges progress
        return data.copy(
            dailyChallenges = "{}",
            version = 2
        )
    }
}

Проверяем версию при загрузке — если старая, мигрируем до актуальной и сохраняем заново.

Как обеспечить защиту от читерства?

Для игр с монетизацией — хэш для обнаружения модификации файла:

fun computeChecksum(data: SaveDataEntity): String {
    val content = "${data.playerId}|${data.coins}|${data.gems}|${data.level}|${SECRET_SALT}"
    return MessageDigest.getInstance("SHA-256")
        .digest(content.toByteArray())
        .fold("") { str, byte -> str + "%02x".format(byte) }
}

Серверная валидация — надёжнее. Критические операции (покупка за gems) проходят через сервер, клиент не может просто записать нужное значение в файл. В одном проекте мы снизили количество читеров на 95% всего за месяц после внедрения серверной проверки каждой покупки.

Как выбрать между CloudKit и Google Play Games?

Выбор зависит от платформы и требований. Если игра только на iOS — CloudKit и Game Center. Для Android — Google Play Games Snapshots. Для кроссплатформенного проекта чаще выбирают собственный бэкенд для единообразия. Мы помогаем определиться на этапе аудита — закажите консультацию, чтобы получить оптимальное решение.

Что входит в разработку системы сохранения

Мы предоставляем:

• Анализ требований к данным и выбор архитектуры
• Реализацию локального хранилища (Room, DataStore, CoreData, PlayerPrefs)
• Подключение облачной синхронизации (iCloud, Google Play Games, собственный сервер)
• Механизм миграции формата при обновлениях
• Защиту от взлома (хэши, серверная валидация)
• Тестирование на различных устройствах и версиях ОС
• Документацию и обучение команды

Сроки — от 2 до 4 недель в зависимости от сложности. Мы проводим нагрузочное тестирование: симулируем 1000 одновременных сохранений, чтобы убедиться в отказоустойчивости. Средняя окупаемость инвестиций — 3 месяца за счет лояльности пользователей. Свяжитесь с нами, чтобы получить консультацию и оценку вашего проекта.

Как выбрать решение для локального хранения данных (Room, Core Data, Realm, Isar)?

Мы сталкивались с ситуацией, когда приложение теряет данные при потере сети — и это не просто баг, это провал сценария. Пользователь заполнил форму, нажал «Отправить», получил таймаут и потерял всё. Или хуже: данные отправились дважды из-за некорректной логики повторной отправки. Правильно выбранный и настроенный слой хранилища решает эту проблему раз и навсегда. Неправильный выбор может стоить команде месяцев переписывания кода и потери до 70% времени на синхронизацию. Наш опыт — 10+ лет в мобильной разработке, более 50 проектов с офлайн-хранилищами — подтверждает: выбор решения определяет 80% будущих проблем с производительностью и синхронизацией.

На практике выбор хранилища определяется двумя факторами: типом данных и требованиями к синхронизации, а не популярностью библиотеки.

Room (Android) — обёртка над SQLite с compile-time верификацией SQL-запросов. Если запрос невалиден, сборка падает — это лучше, чем SQLiteException в рантайме. Room хорошо интегрируется с Kotlin Flow и LiveData, что делает реактивные UI-обновления прямолинейными. Основная сложность — миграции схемы. @Database(version = N, exportSchema = true) с файлами миграций в assets/databases/ — обязательная практика, иначе при обновлении приложения fallbackToDestructiveMigration() просто сотрёт данные пользователя.

Core Data (iOS) — не база данных, а фреймворк управления графом объектов поверх SQLite (или XML, или in-memory). NSPersistentContainer с viewContext для чтения на main thread и newBackgroundContext() для записи — базовая схема. Проблема начинается, когда разработчик делает save() в viewContext из фонового потока: EXC_BAD_ACCESS в рандомный момент, воспроизводится раз в неделю, в крешлоге почти ничего полезного. Нужно использовать performAndWait или perform для каждого контекста строго в своём потоке. Apple Core Data Programming Guide рекомендует именно такой подход.

Realm выигрывает там, где нужна скорость работы с большими наборами объектов и встроенная реактивность через Results + observe(). Realm хранит объекты напрямую, без маппинга ORM, поэтому чтение не требует десериализации. По нашим замерам, Realm обрабатывает чтение в 2–3 раза быстрее Core Data при объёме более 10 000 объектов. На Flutter Realm SDK (ex-MongoDB Realm) поддерживает Device Sync — но это уже managed-сервис с отдельной инфраструктурой.

Hive и Isar — Flutter-специфичные решения. Hive — key-value хранилище, быстро, просто, подходит для настроек и кешей. Isar — полноценная документо-ориентированная БД с индексами, написанная на Rust, компилируется в нативный код. Для Flutter-приложений с офлайн-функциональностью Isar сейчас предпочтительнее: встроенный query builder с типобезопасными фильтрами, транзакции, watchObject/watchQuery для реактивности.

Свяжитесь с нами, чтобы получить бесплатный аудит вашего текущего хранилища и рекомендации по оптимизации — это сэкономит вам сотни часов разработки и до 60% трафика на серверные запросы.

Почему офлайн-синхронизация — самая сложная часть?

Локальное хранилище само по себе несложно. Сложность — в синхронизации с сервером при наличии конфликтов.

Самый частый паттерн — optimistic updates с rollback. Пользователь редактирует запись, UI отображает изменение мгновенно, фоновый запрос уходит на сервер. Если сервер возвращает ошибку — откатываем локальный стейт. Выглядит просто. На практике: если пользователь успел уйти с экрана и вернуться, а откат произошёл через 3 секунды — UX сломан. Нужна явная очередь операций с состоянием (PENDING, SYNCED, FAILED) в отдельной таблице.

На Android для фоновой синхронизации используем WorkManager с Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED). Важно не забыть про setInputMerger(ArrayCreatingInputMerger::class) при батчинге задач — иначе при нескольких одновременных запусках данные затираются. Типовая реализация очереди операций:

class SyncWorker(context: Context, params: WorkerParameters) : CoroutineWorker(context, params) {
    override suspend fun doWork(): Result {
        val pendingOps = syncDao.getPendingOperations()
        for (op in pendingOps) {
            try {
                apiClient.send(op.payload)
                syncDao.markSynced(op.id)
            } catch (e: Exception) {
                syncDao.markFailed(op.id, e.message)
                return Result.retry()
            }
        }
        return Result.success()
    }
}

На iOS аналог — BGTaskScheduler с BGProcessingTaskRequest. Ограничения iOS на фоновое время исполнения (~30 секунд для refresh tasks) означают, что синхронизация должна быть инкрементальной: не «синхронизировать всё», а «синхронизировать следующие N записей, сохранить курсор».

Конфликты при мультиустройственной работе решаются одним из трёх подходов:

• Last-write-wins по updated_at (простейший, теряет данные при одновременном редактировании)
• Server-wins (клиент всегда принимает серверную версию)
• Three-way merge (сложно, нужен общий предок — подходит для документов)

В большинстве B2C-приложений достаточно last-write-wins с вектором времени на уровне пользователя, но при совместном редактировании нужен CRDTs-подход — тогда смотрим на Automerge или Yjs с мобильными биндингами.

Как мы строим слой хранилища

Репозиторный паттерн — не опциональный, а обязательный. UserRepository не знает, откуда данные: из Room, Realm или сети. ViewModel вызывает repository.getUser(id), получает Flow/Stream, отображает данные. Логика кеширования — внутри репозитория.

Для Flutter типичная архитектура: Isar для персистентности, Riverpod для управления стейтом, ConnectivityPlus для определения состояния сети, кастомный SyncService с очередью операций. Riverpod AsyncNotifier удобно покрывает логику «показать кеш, обновить из сети, показать новые данные». Пример репозитория с кешированием:

class UserRepository {
  final Isar isar;
  final ApiClient api;

  Future<User> getUser(String id) async {
    // 1. попробовать из локального хранилища
    final cached = await isar.user.where().idEqualTo(id).findFirst();
    if (cached != null) return cached;
    // 2. иначе из сети
    final remote = await api.fetchUser(id);
    // 3. сохранить локально
    await isar.writeTxn(() => isar.user.put(remote));
    return remote;
  }
}

Отдельная тема — шифрование. Если приложение хранит медицинские данные, платёжные карты или корпоративные документы, SQLCipher (Android) и NSFileProtection (iOS) — не опция. Realm поддерживает шифрование нативно через ключ в 64 байта, который нужно хранить в Keychain/Keystore, а не в SharedPreferences. Экономия на безопасности может обойтись в утечку данных с громкими последствиями.

Что входит в работу

Мы гарантируем прозрачный процесс и фиксируем каждый этап:

Хотите избежать типовых ошибок при проектировании хранилища? Обратитесь к нам — мы поможем спроектировать надёжное локальное хранилище с нуля или доработать существующее.

Этапы работы

Начинаем с аудита требований: какие данные, какой объём, нужна ли синхронизация, возможны ли конфликты. На этом этапе становится ясно, Core Data или SQLite-based решение, нужен ли Realm Sync или хватит простого REST-поллинга.

Дальше — проектирование схемы с учётом миграций. Схему меняют в любом проекте — вопрос не «будут ли миграции», а «насколько болезненно они пройдут». Экспортируем схему в JSON, храним в репозитории, пишем тесты на миграцию каждой версии.

Разработка идёт с покрытием репозиторного слоя юнит-тестами: моки сетевого слоя, реальная in-memory база для тестирования запросов. Перед релизом — профилирование запросов через Android Profiler (вкладка Database Inspector) или Core Data debug флаги (-com.apple.CoreData.SQLDebug 1).

Срок реализации слоя хранилища с базовой офлайн-синхронизацией — от 2 до 6 недель в зависимости от сложности схемы и требований к конфликт-резолюции. Стоимость рассчитывается индивидуально после аудита вашего проекта. Закажите разработку под ключ — получите консультацию по выбору оптимального стека и миграциям.