给一个文字人生模拟游戏补多语言，起初我以为工作量主要在翻译表：按钮翻成英文，剧情读取对应 JSON，再给页面加语言路由。

实际迁移中发现一个更隐蔽的问题：同一份中文存档，换成英文恢复，继续作出相同选择，后面的人生数值可能发生分叉。

定位后发现，姓名音译会影响重名检查，重名检查会多消耗随机数，继而改变后续事件。

这篇文章以我们对《80 亿分之一》相关项目的二次开发为例，介绍这个问题的成因、兼容方案和回归测试。重点讨论有随机事件、长期存档和动态文本的模拟游戏。原作是 [1in8b.life](https://1in8b.life/)，项目魔改版是[80亿分之一（魔改版）](https://onein8b.app/zh)，文中的语言与存档适配属于我们的后续修改。

## 1. 先把要保持不变的东西写下来

这个游戏按年龄推进，状态包括健康、幸福、知识、人际关系，以及工作、收入、家庭等信息。遇到抉择时，玩家选择一个选项，规则层更新状态并生成记录。

我们已经拆出了共享核心，网页通过 React 展示核心提供的数据。相关目录如下：

```text
packages/
  game-content/locales/       剧情语言包
  game-core/src/              模拟规则、随机进程、快照
  game-rendering/src/         像素及分享图渲染
src/
  components/reference/      React 界面和语言上下文
  engine/companions.worker.js 同龄人物后台模拟
tests/
  reference-language.test.ts 多语言与存档兼容测试
```

迁移的约束是：同一段人生在切换显示语言之后，只要后续命令一致，年龄、数值、工作和随机进程就应该一致。

可以把它表达成一个测试条件：

```text
原语言核心.restore(snapshot)
新语言核心.restore(snapshot)

对两者依次执行相同命令
每步比较 simulationState 和 randomState
```

这里不能比较完整展示文本，因为文本正是我们希望改变的部分。

## 2. UI 字典和剧情字典分开接入

按钮和帮助文字由界面语言上下文提供；剧情则由核心读取对应语言包。我们整理的英文剧情包覆盖了固定版本资源中的 12,853 个翻译键。这是翻译键数量，不代表分支或事件数量。

核心创建入口支持注入语言数据。下面是与实际入口对应的简化示意，省略了城市别名和姓名表配置：

```ts
const languageData = runtime.languageData ?? (
  runtime.language === 'en' ? englishData :
  runtime.language === 'zh-Hant' ? traditionalData :
  undefined
);

return createRuntimeCore({
  ...runtime,
  catalog: runtime.catalog ?? catalog,
  languageData,
});
```

共享核心仍保留原来的中文默认值，以兼容既有调用；网页根路径显式传入英文。Web Worker、存档预览、出生档案也必须传递语言，否则主界面是英文，后台生成的同龄人物故事仍可能是中文。

另一个容易漏掉的地方是 Canvas 分享图。它不经过 React，不能依赖组件上下文。因此渲染器额外接收翻译函数：

```js
referenceCardBlob(data, { translate: t });
birthCardBlob(data, { translate: t });
```

默认翻译行为继续兼容原调用，网页宿主则显式传入当前语言。

## 3. 为什么姓名会影响随机进程

假设原来的姓名生成过程类似下面的伪代码：

```ts
do {
  name = sampleName(random);
} while (familyNames.has(name));
```

重复一次，就多消耗一轮随机数。不同语言中的姓名字符串与音译可能具有不同的重合关系，姓与名的拼接方式也可能不同。

于是，即使恢复了相同的随机状态，切换姓名表之后，未来创建家庭成员时仍可能发生不同次数的重抽。后续健康事件、职业和财务抽样使用的随机位置也就发生偏移。

这揭示了旧核心里一个边界问题：看起来属于展示的姓名字符串，实际上参与了模拟控制流。

更彻底的长期方案是给人物使用稳定 ID，并让姓名抽样拥有明确的身份数据模型。如果整个旧核心大量依赖姓名字符串，直接改动可能破坏既有存档和复现结果。我们这次先采用兼容性更强的处理。

## 4. 把显示语言与姓名生成规则分开

我们增加了可选的快照字段：

```ts
interface SnapshotV2<State> {
  state: State;
  randomState: number;
  familyAgeSeen: { age: number; keys: string[] };
  nameLanguage?: 'en' | 'zh-Hant';
  // 其余既有字段略
}
```

恢复存档时，先恢复这一生采用的姓名生成规则，再恢复状态：

```ts
setNameLanguage(saved.nameLanguage || 'zh-Hans');
```

旧中文存档没有这个字段，按原中文姓名表处理；新建的英文、繁体人生才记录对应值。玩家切换显示语言时，未来 NPC 仍沿用这一生原有的姓名规则。

因此，恢复一段中文人生后切换英文，姓名可能继续保留中文。这是我们为存档兼容作出的明确取舍。新剧情可以变成英文，但不能因重名重抽而改变这段人生的随机序列。

城市也有类似的问题：旧数据中的本地化城市名参与规则匹配。我们补充了城市别名映射，避免切换语言后因字符串不匹配而走到不同的地理规则。

## 5. 已经弹出的选择，不能重新掷骰

旧存档保存了待选决定及其展示文本。只切换 UI 字典，已经弹出的决定仍会保持中文；但如果完整重新生成决定，又可能改变选项资格、成本或随机状态。

我们的处理是按稳定选项键 `k` 重新投影文字，保留原来的选项集合与非文本字段：

```js
const translated = new Map(
  rebuilt.choices.map(choice => [choice.k, choice])
);

const choices = pending.view.choices.map(choice => {
  const text = translated.get(choice.k);
  return text ? {
    ...choice,
    label: text.label,
    sub: text.sub,
  } : structuredClone(choice);
});
```

这是从实际实现提炼的片段。实际调用放在只读投影包装中：使用隔离的状态和随机进程构建展示，再恢复运行现场，避免旧的构建函数对游戏产生副作用。标题、正文和事实说明也一起投影。

已有的人生日志则保留原文。旧日志已经是生成后的文字，并不都保有足够的模板参数；强行反向翻译会丢失信息。我们的兼容策略是：历史记录保持原样，当前决定按所选语言显示，新事件使用所选语言。

## 6. 不启动游戏，也能测试到人生结束

为了发现这种延迟分叉，仅测“出生证明变成英文”不够。我们增加了跨语言续玩的回归测试。

测试从中文或英文核心开始，推进到约 30 岁，保存快照；再用另一种显示语言恢复。之后两边每次执行相同选项，或推进相同时间，直到人生结束。

下面的断言接近实际测试，只展示关键循环：

```ts
while (original.state.phase === 'life') {
  if (original.state.pending) {
    const key = original.state.pending.view.choices[0].k;
    original.choose(key);
    translated.choose(key);
  } else {
    original.tick(200);
    translated.tick(200);
  }

  assert.deepEqual(
    physics(translated),
    physics(original),
  );
}
```

实际测试带有步数上限，防止异常循环；`physics` 提取阶段、年龄、时间、工作、资产、收入、房产、家庭经济档位、状态值和 `randomState`。

针对跨语言续玩，我们覆盖了中国、日本、韩国，以及中转英、英转中两个方向。另有 12 条英文／繁体完整人生测试，检查恢复一致性、结局可生成、运行中没有缺失的剧情翻译键。

还需要单独检查两个不变量：

```ts
const before = core.snapshot();
const view = core.decisionView();

assert.deepEqual(core.snapshot(), before);
assert.deepEqual(
  view.choices.map(choice => choice.k),
  before.state.pending.view.choices.map(choice => choice.k),
);
```

一个检查读取不修改存档，另一个检查语言切换不改变待选键。完整测试文件运行方式：

```sh
npx tsx --test tests/reference-language.test.ts
```

这类测试能验证特定样本和命令路径的一致性，不能证明所有国家、所有决定组合都没有问题。未来增加内容时，仍需要扩大种子和命令覆盖。

## 7. 这次改造的边界

目前的网页通过 Next.js / OpenNext 部署，核心可以脱离浏览器运行。本文讨论的是语言与模拟状态之间的边界，不涉及 AI 实时生成剧情。

仍有几项后续工作：姓名和城市继续向稳定 ID 迁移；历史日志逐步保存模板键与参数；语言资源按需要加载；增加更广的跨语言回归样本。

这次最有价值的经验是：在有长期存档的模拟系统里，展示数据可能已经进入规则控制流。做国际化之前，先找出字符串参与比较、去重和随机重试的位置，再用相同快照、相同命令验证后续状态，往往比检查翻译覆盖率更能发现兼容问题。


给一个文字人生模拟游戏补多语言，起初我以为工作量主要在翻译表：按钮翻成英文，剧情读取对应 JSON，再给页面加语言路由。

给人生模拟游戏切换语言，为什么会改变结局？一次存档兼容实践

一次文字模拟游戏的国际化改造：为什么切换姓名语言会改变重名重抽次数，并让后续随机事件分叉？本文结合实际代码，介绍姓名规则与显示语言分离、旧快照兼容、待选决定的只读投影，以及跨语言续玩到结局的回归测试。

人工智能

模拟游戏多语言迁移的隐蔽风险：存档恢复后随机序列分叉。问题源于姓名音译影响重名检查消耗随机数，进而改变后续事件。解决方案是分离显示语言与姓名生成规则，用快照字段记录原规则。增加跨语言续玩回归测试，验证相同命令下状态一致，确保长期存档兼容性。

回归测试

代码解释

JavaScript

TypeScript 

路由

ReAct 

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

给人生模拟游戏切换语言，为什么会改变结局？一次存档兼容实践-腾讯云开发者社区-腾讯云

给人生模拟游戏切换语言，为什么会改变结局？一次存档兼容实践

给人生模拟游戏切换语言，为什么会改变结局？一次存档兼容实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐