游戏开发

本文基于 Tiled 的 Wangset 规范，以 corner 类型为主讲解如何标注 tileset、让编辑器自动选出正确的边角 tile。 一、什么是 Wangset 手动拼 tilemap 时，每次都要自己判断某个位置该用"左上角 tile"还是"上边 tile"——一旦地形形状复杂，就很容易选错。 Wangset 解决这个问题：你只需要一笔刷下去，系统根据周围邻居自动选出正确的 tile。 核心思路是给每个 tile 标注它的每个角/边属于哪种地形颜色，绘制时系统计算当前格子的周围情况，再去 wangset 里找最匹配的 tile。 → 二、三种类型 类型 使用的 bit 适合的地形 corner 4个角（NW/NE/SE/SW） 填充型：城墙、草地、水域 edge 4条边（N/S/E/W） 线条型：道路、河流、栅栏 mixed 全部8个 bit 复杂过渡，需要更多 tile 大多数情况用 corner 就够了。 corner 类型虽然只标角，但通过角的组合，间接表达了所有的边和拐角情况。 ...

调研范围：算法库、引擎内置方案、独立工具、AI 辅助生成 适用决策：2D 游戏/应用中的 Tilemap 自动生成方案选型 三条主路线 当前主流技术路线分三大方向： 约束传播类（WFC 及变体）：以 Wave Function Collapse 为代表，通过样例学习约束规则自动生成视觉一致的 tilemap，是近年最受社区关注的方向，适合有样例地图、追求局部一致性的场景。 传统程序化生成（PCG）：包括 BSP 分割、随机游走、噪声函数（Perlin/Simplex）、房间连接算法等，技术成熟、可控性强，是引擎内置方案的主流实现基础，适合工程化生产环境。 AI/ML 辅助生成：包括 GAN、扩散模型、强化学习等方向，处于学术探索阶段，少数工具已产品化，适合内容需求量极大且愿意投入训练成本的团队。 核心选型建议： 快速上手 + 风格一致 → WFC（fast-wfc 或引擎插件） 工程稳定 + 高可控 → Perlin Noise + BSP/房间算法（引擎原生） 编辑器辅助 + 团队协作 → LDtk + Auto-layer 规则 大规模内容生成研究 → PCGML 方向（学术） 一、约束传播类：WFC 及变体 技术原理 Wave Function Collapse（WFC）由 Maxim Gumin 于 2016 年提出，本质是一种约束传播 + 回溯搜索算法。输入一张样例 tilemap，算法自动提取相邻关系约束，再在新画布上逐格"坍缩"——每格从所有可能 tile 中选一个满足邻居约束的值，直到整张图确定。 核心优势： 无需手写规则，从样例自动学习 输出视觉上与样例风格高度一致 可保证局部邻接关系合法（无穿墙、无悬空） 核心缺陷： 可能出现矛盾（contradiction），需重试 全局结构控制弱（无法保证有入口/出口） 大地图生成速度较慢 主要项目对比 项目 语言 Stars（约） 许可证 特点 适用引擎 mxgmn/WaveFunctionCollapse C# ~23k MIT 原版实现，含 Overlapping 和 Tiled 两种模式 任意（命令行） fast-wfc C++ ~1.1k MIT 性能优化版，支持并行；适合嵌入 C++ 项目 任意 godot-wfc GDScript ~300 MIT Godot 4 插件，直接操作 TileMapLayer Godot 4 unity-wave-function-collapse C# ~800 MIT Unity 集成，支持 3D Tile Unity wfc-rust（多个实现） Rust ~200-400 MIT 高性能，适合服务端生成 任意 Tessera C# ~600 MIT Unity 插件，扩展了 WFC 支持约束自定义 Unity superpositioned TypeScript ~150 MIT 浏览器端 WFC，带可视化 demo Web/JS WFC 变体与改进方向 变体 解决的问题 代表实现 Constraint-augmented WFC 加入全局约束（保证连通性） BorisTheBrave 的多篇博客 + 参考实现 Hierarchical WFC 先生成大结构再细化 学术论文方向，暂无成熟库 WFC + A* 生成后用寻路验证可玩性 需自行组合 Automatic Tiling（Auto-Tile） 非约束传播，基于位掩码规则自动选 tile RPG Maker、Godot Terrain、LDtk Auto-layer 二、传统程序化生成（PCG） 核心算法类型 算法 原理 典型用途 优点 缺点 Perlin/Simplex Noise 连续随机函数生成高度图 地形/海拔/生物群系 平滑自然，速度极快 难以控制宏观结构 BSP（二叉空间分割） 递归分割空间生成房间 地下城、室内关卡 结构规整，无重叠 风格单一，走廊感强 随机游走（Drunkard’s Walk） 随机方向掘进生成通道 洞穴、有机地形 风格有机，实现简单 不可预测，需大量后处理 Cellular Automata 生命游戏规则迭代平滑 洞穴地形、平滑地貌 视觉自然，易于理解 生成结果不确定，难以调控 房间+连廊（Room & Corridor） 先放房间再连接通道 RPG 地下城 可控性强，标准做法 需要额外的装饰逻辑 Voronoi 分割 以随机种子点划分区域 地区划分、生物群系 视觉多样，可配合 Noise 实现稍复杂 L-System 文法规则递归展开 植被、分形结构 视觉有层次感 调参复杂，学习成本高 主要库与框架对比 项目 语言 Stars（约） 定位 主要功能 libtcod C/C++/Python ~1.5k 经典 Roguelike 工具库 BSP、随机游走、FOV、寻路 rot.js TypeScript ~2.3k 浏览器端 Roguelike 工具库 多种地图算法、随机数、FOV gdungeon（Godot） GDScript ~500 Godot 专用地下城生成 BSP + 走廊连接 dungeon-generator（npm） JavaScript ~200 轻量地下城生成 房间+连廊 noise.js / open-simplex-noise JavaScript ~1k+ Noise 函数库 Simplex/Perlin 多维噪声 FastNoiseLite C/C#/多语言 ~3k 高性能 Noise 库 多种 Noise 类型，Unity/Godot 均有移植 mapgen4 C++ ~700 岛屿地图生成 Voronoi + 物理侵蚀模拟 引擎内置 PCG 能力 引擎 内置 Tilemap 生成支持 典型方案 Godot 4 TileMapLayer + Terrain 系统（Auto-tile） 内置地形自动拼接；PCG 需脚本实现 Unity Tilemap + Rule Tile + Scriptable Tiles Rule Tile 可做简单 Auto-tile；复杂 PCG 靠插件 GameMaker 内置 tilemap 函数 需手动实现算法 Phaser 3 内置 Tilemap（配合 Tiled） 无原生 PCG，靠 JS 脚本 LÖVE2D 无内置 tilemap，靠社区库 STI（Simple Tiled Implementation）读取 Tiled 数据 三、AI/ML 辅助生成（PCGML） 技术路线概览 方法 原理 成熟度 代表工作 GAN（生成对抗网络） 训练生成器模仿真实地图分布 🟡 中（学术可用） DCGAN for Mario levels（Volz 2018） VAE（变分自编码器） 学习地图潜空间，插值生成 🟡 中 Latent Variable Evolution 扩散模型（Diffusion） 图像级地图生成，细节丰富 🟡 中（2023-2024 新兴） ControlNet 配合 tileset 风格化 Transformer/LLM 把 tilemap 当序列，自回归预测 🟡 中 GPT-2 生成 level 序列 强化学习（RL） 训练 Agent 设计关卡 🔴 低（难以实用） PCGRL（Khalifa 2020） Markov Chain 基于转移概率的序列生成 🟢 高 简单实现，效果有限 Evolutionary Algorithm 遗传算法优化地图适应度 🟡 中 配合可玩性评估函数 新兴方向：LLM 辅助关卡设计 近期（2024-2025）出现了用 LLM 作为关卡设计助手的实验性方向： ...

游戏看上去不错 tbrain + tclaw 多 Agent 协作开发游戏这件事，之前大概就是验证一下能不能跑通，没想太多。 做了几个游戏下来，发现效果比预期好不少——UI 有模有样，玩法完整。几个 Agent 分工合作，设计、写代码、测试，整个流程下来没有人工干预。 做到这程度，就想继续往下走：tclaw 在游戏开发上，还能做什么？ 有一个短板很明显 但玩着这些游戏，有一个感受挺直接的：游戏能玩，但美术很糙。所有图形都是 AI 自己画的——基础色块、简单几何，能表达意思，但跟真正的游戏差得远。 网上其实有很多优秀的免费美术资源，像素风、卡通风各种风格都有，专门给独立开发者用的，质量很高。 于是就想：能不能让 tclaw 来做这些事——搜索素材、整理素材、管理本地素材库，甚至处理帧动画？ 怎么做 拿这个想法去和 tclaw 讨论，来来回回聊了好几轮。 一开始是从开发者的角度想：这个功能该怎么支持？ 做成独立插件，有自己的窗口——但插件里没有对话，用不了 tclaw 的核心能力；要用就得把对话嵌进插件里，以后每多一个插件就多一个对话框，越来越割裂。 改成全屏扩展页面，像文件浏览器那样接管整个主区域，进去是个独立的世界——用户得在对话和扩展页之间来回切换，体验还是断的。 做一套扩展系统，类似 VS Code 的插件机制，每个 Skill 可以注册自己的 UI 组件——但这意味着要定义扩展 API、生命周期、沙箱隔离……一套新的基础设施，比要解决的问题复杂多了。 怎么想怎么别扭。 后来重新梳理思路，从用户使用的角度出发：用户会怎么用这个功能？在对话框里说"搜个像素风骑士素材"，tclaw 去搜，搜出来的结果直接显示出来，看合不合适，合适就点下载。就这样。 倒推回来——tclaw 本来就是对话驱动的，对话就是入口，这个体验才是最适合的。 方向就出来了：做成 Skill，结果嵌在对话流里展示。 这样下来就需要对现有系统做一些扩充：Skill 现在只能输出文字，素材搜索的结果需要缩略图、下载按钮、动画预览，得让 Skill 支持输出富内容。 想要的效果是这样的： 用户：搜几个像素风骑士的素材 AI：找到这些 ↓ [搜索结果——带预览图、授权信息、下载按钮] 用户：这个不错，下载，帮我切成序列帧 AI：切好了 ↓ [动画预览——GIF 效果、帧分组] tclaw 本来就能把特定代码块渲染成图表。同样的思路可以用在这里——Skill 输出一个特殊的代码块，前端识别后渲染成卡片。 tbrain 源码在这里：tbrain 最兼容 tbrain 的 Agent 运行时是 tclaw，感兴趣可以去 tclaw 体验。 ...