僵尸生存沙盒《未转变者》官方 SDK 源码（U3-SDK）

Cube Composer（立方体合成器）是开发者 sharkdp 用 PureScript 编写的一款浏览器解谜游戏，作者对它的定位是「受函数式编程启发的解谜游戏」。它并不是让玩家真的去写代码，而是把函数式编程中最核心的几个直觉——函数、映射、组合、类型——转译成看得见摸得着的立方体操作：玩家面对一面由彩色方块堆成的「墙」，只能通过挑选游戏给出的若干个「变换器」来改变这面墙，直到它与目标图案完全一致。理解「一个变换器会作用于整面墙的每一个元素」，本身就是对 map 之类高阶操作最直观的类比。

从玩法结构上看，游戏中的基本数据单位是「栈」（Stack），即一列竖直排列的彩色立方体；若干栈并排组成「墙」（Wall）。README 中给出的类型别名把这一点写得很清楚：Stack 是 Cube 的列表，Wall 是 Stack 的列表，而变换器（Transformer）的类型就是 Wall -> Wall，即「吃进一面墙、吐出一面新墙」的纯函数。玩家每一步的操作，就是从当前章节提供的变换器清单里选一个应用到整面墙上，例如 "map {Yellow}↦{Red}" 这条变换器的语义就是把墙中所有黄色立方体替换成红色（界面上 {x} 会渲染成一个对应颜色的小方块）。由于变换器本身是函数，玩家把多个变换器接连使用，实际上就是在做函数组合，这也是这款解谜游戏在机制层面最巧妙的地方。

关卡被组织成「章节」，每一章在仓库的 src/Levels/ 目录下对应一个独立的源文件，例如 Chapter0.purs；新增章节的做法是复制现有文件、递增章节编号，并把它登记到 Levels.purs 的 allChapters 列表里。章节同时决定了玩家在该章可以使用的变换器集合——这意味着关卡设计者可以通过控制可用工具来塑造解题思路。每个关卡则是一条记录，包含形如 "0.2" 的「章节.关卡」编号、关卡标题 name、显示在右侧面板的帮助文本 help、难度 difficulty（取值为 Easy、Medium 或 Hard），以及初始墙 initial 和目标墙 target 两个二维立方体数组。这种「关卡即数据」的组织方式让内容扩展非常直接，作者也在 README 中明确欢迎通过 Pull Request 提交自制谜题。

核心特性

在技术实现上，项目用 PureScript 编写并编译为 JavaScript 在浏览器中运行，基础变换器的实现集中在 Transformer.purs。本地构建流程是依次执行 npm install、bower install 和 gulp：npm 负责工具链，bower 负责前端依赖，gulp 产出可分发的构建结果，若无报错，直接用浏览器打开 index.html 即可游玩。需要留意的是 Bower 早已停止维护，这套依赖管理方式在今天复现构建时可能需要额外处理，README 并未给出依赖版本锁定之外的兼容性说明，实际能否一次跑通待核验。

项目还附带一个相当实用的关卡验证工具：执行 gulp prod 之后运行 node dist/cli.js，会列出所有关卡及其最短解法。它的用途不只是「看答案」，更在于验证新加入的关卡确实能按设计者的预期被解开，并且不存在另一条更短、或绕过关卡设计意图的旁路解法。对一个以「用有限工具达成目标形态」为核心乐趣的解谜游戏来说，这种穷举式的可解性校验是保证内容质量的关键手段，也是这个仓库在工程设计上值得学习的一点。

试玩方面，README 首屏就给出了在线游玩地址，玩家无需安装任何东西即可在浏览器中开始；本地运行则需要 Node.js 环境与一个现代浏览器，项目本身不产出平台专属的可执行文件，因此不存在传统意义上的 Windows、Linux、macOS 版本之分。国内用户在本地构建时，npm install 与 bower install 都可能因为访问境外源而变慢或失败，通常需要配置 npm 镜像与代理；Bower 的注册表与 GitHub 拉取尤其容易不稳定，具体可用性待核验，若只是体验玩法，直接使用在线地址是更省事的选择。

技术要点

适合哪些人看这个仓库：一是想了解 PureScript 这类强类型函数式语言如何落地成一个完整的前端小游戏的开发者，仓库用极简的类型别名把游戏模型表达得很干净；二是对「数据驱动关卡设计」感兴趣的人，章节文件加关卡记录的结构可以直接照搬到自己的解谜或关卡制项目中；三是想学习如何用命令行工具穷举验证关卡可解性与最短解的内容设计者。需要注意的地方是：README 没有说明总关卡数量与完整玩法细节，这些需要实际游玩或阅读源码确认；Bower 生态过时可能带来构建摩擦；游戏本身是解谜而非编程练习平台，它传递的是函数式思维的氛围而非语法教学。