Godot 实现多可选存档选择界面：扩展现有单存档读写逻辑

核心改造思路 #

当前的单存档逻辑本质是写死了固定文件名路径，要实现多存档槽只需要把固定路径改成按槽位ID动态拼接的格式，不需要重构原有读写逻辑的核心流程。 #

第一步：重构存档路径管理规则 #

• 提前统一定义存档存储的根目录、文件前缀、最大可用槽位数，避免后续写代码硬编码路径
• 为每个存档槽分配唯一的数字ID（从1开始计数即可），每个ID对应独立的json文件

第二步：替换原有读写逻辑，支持按槽位操作 #

直接基于现有代码改造，不需要额外搭建复杂架构：

# 统一存档存储配置
const SAVE_DIR = "user://saves/"
const SAVE_FILE_PREFIX = "game-data-slot-"
const MAX_SAVE_SLOTS = 3 # 根据需求调整存档槽总数

var player = {
    "collected_level_one": false,
    # 额外预留存档元数据字段，用于选择界面展示进度
    "save_meta": {
        "save_time": "",
        "play_time": 0,
        "current_scene": ""
    }
}

# 辅助方法：自动创建不存在的存档根目录
func _ensure_save_dir():
    var dir = Directory.new()
    if not dir.dir_exists(SAVE_DIR):
        dir.make_dir(SAVE_DIR)

# 改造后的存档方法：支持指定要写入的槽位
func save_to_slot(slot_id: int):
    # 先校验槽位合法性，防止越界写文件
    if slot_id < 1 or slot_id > MAX_SAVE_SLOTS:
        printerr("非法存档槽位：", slot_id)
        return
    
    # 写入前自动更新元数据，供选择界面展示
    player["save_meta"]["save_time"] = Time.get_datetime_string_from_system()
    
    _ensure_save_dir()
    var file_path = SAVE_DIR + SAVE_FILE_PREFIX + str(slot_id) + ".json"
    var file = File.new()
    var open_err = file.open(file_path, File.WRITE)
    if open_err != OK:
        printerr("存档文件打开失败，错误码：", open_err)
        return
    file.store_string(to_json(player))
    file.close()

# 改造后的读档方法：支持指定要加载的槽位
func load_from_slot(slot_id: int):
    if slot_id < 1 or slot_id > MAX_SAVE_SLOTS:
        printerr("非法存档槽位：", slot_id)
        return null
    
    var file_path = SAVE_DIR + SAVE_FILE_PREFIX + str(slot_id) + ".json"
    var file = File.new()
    if not file.file_exists(file_path):
        # 无存档时返回空值，供界面展示“空存档槽”状态
        return null
    
    var open_err = file.open(file_path, File.READ)
    if open_err != OK:
        printerr("存档文件打开失败，错误码：", open_err)
        return null
    
    var data = parse_json(file.get_as_text())
    file.close()
    if typeof(data) == TYPE_DICTIONARY:
        player = data
        # 返回解析后的存档数据，供界面读取元数据展示
        return data
    else:
        printerr("槽位", slot_id, "的存档数据损坏")
        return null

第三步：匹配存档选择界面逻辑 #

• 界面渲染时，给每个存档选择卡片绑定对应的数字槽位ID，玩家点击卡片的“存档”按钮就调用save_to_slot(当前卡片槽位ID)，点击“读档”就调用load_from_slot(当前卡片槽位ID)
• 每次打开选择界面时，循环遍历1到MAX_SAVE_SLOTS的所有槽位，逐个调用读档方法拉取元数据：拉取到有效数据就展示对应存档时间、当前进度；拉取到空值就渲染成“空存档槽”，引导玩家开启新游戏

落地最佳实践 #

• 单独建saves文件夹存放所有存档，不要把所有文件直接堆在user://根目录，避免和配置文件、缓存文件混杂
• 写存档时可以加临时文件中转逻辑：先把内容写到.tmp后缀的临时文件，写入完成后再重命名为正式存档文件，防止游戏崩溃导致正在写入的存档直接损坏
• 在存档字典里预留固定版本号字段，后续游戏迭代修改存档结构时，可以根据版本号做旧存档的兼容迁移，不会出现老存档加载报错的问题
• 严格把存档数据层和UI层解耦，读写函数不直接调用界面元素的方法，后续要接入云存档、拓展更多存档槽时不需要重构核心逻辑

内容的提问来源于stack exchange，提问作者zak_250