Minecraft assets в S3

Minecraft assets хранятся отдельно от серверной сборки и Java runtime. Один набор может использоваться несколькими профилями с одинаковым assetIndex, поэтому файлы не дублируются в S3 и на компьютере игрока.

Структура S3

launcher/
├── servers/{serverId}/
│   ├── profile.json
│   ├── manifest.json
│   └── files/...
├── assets/{assetIndex}/
│   ├── manifest.json
│   └── files/
│       ├── indexes/{assetIndex}.json
│       └── objects/...
└── runtimes/{runtimeId}/
    ├── manifest.json
    └── files/...

В launcher/servers/{serverId}/manifest.json не должно быть путей assets/**. Assets manifest строится относительно самой папки assets, поэтому его пути начинаются с indexes/ и objects/.

Контракт API

POST /api/launcher/builds/profile возвращает четыре независимых ресурса:

{
  "profile": { "assetIndex": "1.7.10" },
  "build": { "serverId": 4, "releaseId": "release-2", "manifest": {} },
  "assets": {
    "serverId": 4,
    "releaseId": "release-2",
    "id": "1.7.10",
    "revision": "sha256-derived-revision",
    "delivery": "signed",
    "contentBaseUrl": null,
    "manifest": {}
  },
  "runtime": { "serverId": 4, "releaseId": "release-2", "id": "java-17-win32-x64", "manifest": {} }
}

Сервер читает launcher/servers/{serverId}/releases/{releaseId}/assets/{assetIndex}/manifest.json, проверяет наличие indexes/{assetIndex}.json и вычисляет revision из отсортированного списка путей, размеров и SHA-256. Для получения временных ссылок клиент вызывает:

POST /api/launcher/builds/assets/resolve
Authorization: Bearer <launcher-access-token>
Content-Type: application/json

{
  "server_id": 4,
  "release_id": "release-2",
  "asset_id": "1.7.10",
  "paths": ["indexes/1.7.10.json", "objects/ab/abcdef..."]
}

Сервер разрешает только пути, присутствующие в подписанном manifest, и выдаёт S3 URL с коротким сроком действия.

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

{storageRoot}/
├── common/{profile.dir}/
├── assets/{assetIndex}/
├── runtimes/{runtime.id}/
└── metadata/

Minecraft получает абсолютный путь {storageRoot}/assets/{assetIndex} через --assetsDir и placeholder ${assets_root}. Поле profile.assetDir сохраняется в формате профиля для совместимости, но реальное расположение задаётся отдельным assets descriptor. {storageRoot} настраивается пользователем. Поэтому assets не обязаны занимать место на системном диске и переносятся вместе с остальными игровыми данными. Подготовка выполняется последовательно:

client scan/download/verify
→ assets scan/download/verify
→ Java scan/download/verify
→ Guardian policy
→ Minecraft

Rust scanner проверяет весь assets manifest перед каждым запуском. Assets не включаются в периодическую Guardian-проверку во время игры: они не являются исполняемым кодом, а повторное хеширование тысяч объектов создавало бы лишнюю нагрузку. JAR, моды, native DLL и Java runtime остаются защищёнными Guardian.

Генерация manifest

Для подготовленной сборки Architechnica используется скрипт:

cd E:\Wraithbound\wraithbound-launcher-platform\apps\launcher\deployment\launcher
.\build-manifests.ps1

Перед запуском должны существовать:

E:\Wraithbound\assets\indexes\1.7.10.json
E:\Wraithbound\assets\objects\...

Скрипт создаёт отдельно:

servers/4/manifest.json без assets;
assets/1.7.10/manifest.json только для indexes и objects.

Устройство

Игровой контур

Выпуск лаунчера

Структура S3

Контракт API

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

Генерация manifest

​Структура S3

​Контракт API

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

​Генерация manifest

Структура S3

Контракт API

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

Генерация manifest