企业官网建设流程全解析

Superpowers 这个名字第一次出现在我视野里，是两年前跟朋友临时组队做 Game Jam。我们手头没有统一的本机环境，又想在 72 小时内快速出个小玩意，找了一圈工具，最后还是这个免费开源的游戏制作系统解决了问题。说白了，Superpowers 就是一个“在浏览器里跑起来”的 HTML5 游戏开发环境——编辑器是网页、脚本是 TypeScript、项目天然支持多人实时协作。当时我第一反应是“这不就是个网页版 IDE？”，但真正把它搬到团队协作和快速原型场景里以后，我发现它解决的痛点和传统引擎完全不一样。

这篇文章不是官方手册的复读，而是我基于实际使用把它当成独立项目来“拆解”——包括它适合谁、怎么安装、核心架构里场景和 Actor 怎么配合、脚本怎么挂上去、怎么从零做一个能玩的方块小游戏，以及这两年踩过的不少坑。无论你是搞教育培训、带学生，还是跟朋友 jam 一个周末项目，或者是想低成本验证玩法的独立开发者，这篇文章应该都能给出一些可直接抄作业的结论。

1. Superpowers 到底是个什么项目

1.1 先弄清楚它是“引擎”还是“编辑器”

很多人以为 Superpowers 是某个独立引擎，其实更精确的说法是：它把引擎、编辑器、资源管线和脚本编译这四件事做成了一套“一体化的在线工作台”。创建一个项目后，你不会像在 Unity 里那样面对一个巨大复杂的编辑器窗口，而是打开网页端界面，在里面看到场景树、资源列表、属性和内置的游戏预览。

它的核心定位非常明确——做“面向浏览器的游戏”。也就是说，最终被你 build 出来的东西主要是 HTML5 页面，可以扔到静态服务器、itch.io，或者自己的网站上。它不像 Unity 那样一条龙导出多平台安装包，也不像 Godot 那样给你大而全的物理和动画系统。Superpowers 的取舍是：把一个可以让多人同时动手修改的小型 3D 场景，用最短路径变成可执行的网页。

这种定位带来一个非常现实的好处：上手门槛低。你要处理的是“场景”和“Actor”，操作习惯上有点像 Unity，但没有包管理器、没有复杂的构建管线、没有平台适配问题。我自己的体验是，一个完全没有接触过游戏引擎的编程学习者，大概花半小时就能搞清楚场景里放一个方块、让它动起来的完整路径。

1.2 为什么说它是“多人实时协作”的生态

Superpowers 最让我觉得有价值的地方，是它的协作属性。传统团队的版本控制流程通常是：代码提交到 Git，然后队友 pull，可能会冲突，可能要处理场景文件的二进制差异。而 Superpowers 的做法更像是在线文档：你本地开着编辑器，另一个同事从服务器加入同一个项目，双方修改同一个场景的同一棵节点树时，改动会实时同步。我实际测试下来的感受是，一人拖物体、另一人写脚本、第三人改贴图资源，只要不同时去改同一个脚本文件的同一行，整个过程可以无缝推进。

这个特性的意义在 Game Jam 和教学场景中被放得很大。Game Jam 节奏很快，不太有时间去解决分支冲突；教学场景里老师可以看着学生的场景实时给意见，不需要学生把工程打包发过来。所以我认为，如果你只是自己单机埋头做游戏，Superpowers 的很多优势展示不出来；但一旦你是跟人或多或少的队伍一起做事，这种“实时可协作”的体验几乎是不可替代的。

1.3 技术栈：TypeScript 和网页技术

项目底层肯定是 Web 技术栈，编辑器基于浏览器环境实现，脚本语言用的是 TypeScript。这对我这种本来就写前端的人特别友好：语法不陌生，类型系统还能兜住底层错误。就算你之前只写过 JavaScript，也能很快上手——无非是多了类型标注和类声明。

用 TypeScript 而不是可视化节点脚本，其实是 Superpowers 一个相当聪明的选择。可视化连线看起来很友好，但一旦玩法逻辑复杂，节点的排列会比代码更难维护。TypeScript 至少让逻辑有了文本形态，可以搜索、可以 diff、可以写注释，也可以像普通项目一样做代码审查。对教育用途来说，学生写的是“真正的代码”，养成的习惯能迁移到其他领域，而不是学了某个编辑器里的私有节点语言就完了。

2. 安装前的准备与两种部署方式

2.1 桌面应用：最省事的本地启动方式

“想要安装 superpowers”这个需求我见到最多的，是从官网下载桌面客户端。Windows 下通常是一个压缩包，解压后直接运行里面的可执行文件；macOS 下则是一个常见的 .app；Linux 平台有对应的 64 位版本。安装过程里需要注意一点：Superpowers 的本地工作方式是“桌面程序负责启动本地服务 + 自动打开浏览器进入编辑器”，所以第一次启动不要因为浏览器弹出来就紧张，那个网页就是你真正的操作界面。

安装包本身不大，不需要安装额外运行库。我试过在比较旧的笔记本电脑上运行，启动后内存占用也比主流 3D 引擎低得多。原因很简单，它面对的渲染目标主要是 WebGL 场景，资产规模通常不大，所以各种工具的体量都控制得比较极端。

启动后首次创建项目，软件会让你选项目模板。你不一定非要选带示例的模板，但我建议第一次接触的人先选一个带示例的项目，然后在里面四处删改，看看每个节点到底发生了什么。等弄明白基本套路后，再建一个空项目从头开始不迟。默认项目文件会保存在你的用户目录下，一般叫Superpowers Projects之类的目录，里面每个项目一个文件夹。我后来配合 Git 做版本管理，也是直接把这些项目目录纳入仓库的。

2.2 服务端模式：给团队一个持续在线的工作空间

桌面应用解决的是“单人本地开发”的场景，但如果你想在家里放一台常开的机器，让几拨人轮流上线协作，那就该换成服务端模式。Superpowers 官方对服务端部署提供的是相关服务器程序，另外一款集中式发布包可以在云端。

部署思路其实很简单：把服务端程序跑起来，监听一个端口，然后团队成员在浏览器里填入服务器地址，就能连接到一个项目空间。服务端需要保证能被团队成员访问到，所以常规做法是在内网里跑，或者让一台公网小服务器来跑。这里我不去谈某个具体云厂商，只说原则：服务端对带宽的要求不高，因为同步的不是视频流，而是场景和资源变化的数据包；对内存有一点要求，但远远低于传统游戏服务器。

有一点特别重要：服务端模式并不是把所有逻辑都搬到服务器上执行。它更像是一个“共享的工作区和同步中枢”，每个客户端仍然在自己浏览器里跑游戏逻辑、渲染画面，服务端负责把增量改动分发给其他用户。这跟云游戏完全是两码事，别搞混。

2.3 文件目录构成与版本控制

Superpowers 的项目文件里，场景不是二进制大文件，而是结构化的文本和 JSON 加上资源文件，这意味着放在 Git 里比较友好。我自己的习惯是开仓前先写好.gitignore，把临时目录、缓存文件、服务端生成的文件忽略掉，只保留项目定义、资源和场景描述。

这种结构的另一好处是方便脚本化处理。比如我要批量改一组资源的命名、检查某个行为有没有在多个场景里被用到，可以直接用命令行脚本去扫描文本文件，而不是打开编辑器一个个点。虽然这个特性平时用不太上，但对于要维护大型项目或做自动化打包的人来说，确实是 Superpowers 相对难得的优点。

3. 核心架构拆解：场景、Actor、组件和资源

3.1 场景是“世界的容器”，Actor 是“世界里的物体”

在 Superpowers 里，一个游戏世界通常由若干个场景组成。场景是一个层级结构，里面可以放各种 Actor。Actor 可以理解为一个“空白容器”，它有位置、旋转、缩放这些基本信息，但本身并不负责画东西。真正的画面表现，是通过往 Actor 里挂组件来完成的。

打个比方：Actor 就像现实里的一个空箱子，箱子可以放在某个位置、可以转动、可以放大缩小，但箱子里装什么东西由组件决定。如果挂了一个模型渲染组件，它就是一个可见的物体；如果挂了一个声音组件，它就是一个发声源；如果挂了一个脚本组件，它就有了自己的行为和逻辑。

这套“实体组件”结构的价值在于解耦。你想让一个物体既可见又会发出声音，那就放两个组件；你想让一组物体共享同一段运动逻辑，那就让它们各自挂同一个脚本组件，然后在脚本属性里填不同的参数。不用为了新功能去复制一堆继承类，也不用把一个物体的所有能力都硬编码到一个类里。

3.2 资源面板：一切皆资产

Superpowers 的资源面板管理项目里所有的素材，包括贴图、模型、声音、脚本、场景、字体，甚至 tilemap。资源就像你放在工作台上的原材料，而场景里摆放的 Actor 只是这些原材料的“引用实例”。如果你在资源面板里改了一个贴图，所有使用它的 Actor 都会在下次刷新时看到变化。

这个设计对多人协作特别重要。因为共享的是资源层，一个人上传一张新贴图，其他人不用重新下载整个项目，只要同步那个资源即可。同样，脚本也是一种资源，你可以把脚本从资源面板拖到场景里的某个 Actor 上，让这个 Actor 获得脚本定义的行为。这种方式比“新建一个继承类然后手动挂到对象上”直观很多，也更符合可视化编辑的习惯。

3.3 常用脚本 API 速览

我主要用到的脚本 API 其实不复杂。一个脚本资源本质上是一个继承自Sup.Behavior的类，里面有一些约定好的生命周期方法，比如awake、start、update、onDestroy。update会在每一帧被调用，游戏逻辑的“心脏”基本都放在这里。

下面是我最常用的几种写法，你可以直接抄到空项目里试：

class RotateBehavior extends Sup.Behavior { speed = 0.05; awake() { Sup.log("行为已加载"); } update() { this.actor.rotate(0, this.speed, 0); } }

• Sup.log：在控制台输出信息，调试时看好过用眼睛猜。
• this.actor：拿到当前挂载这个行为的 Actor。
• Sup.Actor.get("名字")：从场景中按名字查找另一个 Actor。
• this.actor.setPosition(x, y, z)：直接设置 Actor 的世界坐标。
• this.actor.move(x, y, z)：相对当前位置移动一段距离。

这些 API 不算丰富，但覆盖了原型开发 80% 的需求。等你想做更复杂的事，再去查具体插件的文档也来得及。我的建议是先把这几个基础动作练熟，不要一开始就到处翻高级 API，否则容易被细节淹没。

4. 完整实操：从空项目到“会动的方块”

4.1 搭建项目与场景

我会用“做一个会旋转、可以前后移动的方块”作为例子，帮你把整个流程顺一遍。

第一步，打开 Superpowers，新建一个空项目。在场景面板里，你会看到一个默认场景，或者一个空的场景列表。我们需要先把默认场景设置为主场景，否则导出的游戏不知道从哪开始。

第二步，在场景里新建一个 Actor。右键选择“新建 Actor”，命名为Block。如果场景里已经有摄像机，你就需要把摄像机位置调到一个能看到方块的角度；如果没有摄像机，那就新建一个摄像机 Actor，并调整它的位置和朝向。这一步不用追求完美效果，只要确定你切换预览画面时能看到方块就好了。

第三步，给它加一个可见组件。常见做法是添加一个 Cube 模型组件，或者用四方体之类的形状组件。挂上之后，场景里立刻会出现一个方格。

到这里，你已经有了一个最基本的“世界”：摄像机、方块、光照。按下预览按钮，你应该能看到一个静止的方块。如果看不到，别急着怀疑项目坏了，先检查摄像机朝向和方块坐标。

4.2 挂载脚本，让方块动起来

接下来我们在资源面板新建一个脚本，命名为MoveBehavior。双击打开，把默认内容替换成下面这段：

class MoveBehavior extends Sup.Behavior { speed = 0.05; direction = 1; update() { this.actor.move(0, 0, this.speed * this.direction); if (this.actor.getPosition().z > 3) { this.direction = -1; } if (this.actor.getPosition().z < -3) { this.direction = 1; } } }

保存脚本后，回到场景面板，把MoveBehavior这个资源拖到Block这个 Actor 上。你会发现在 Actor 的组件列表里多了一个行为组件。再按一次预览，方块应该就会在 z 轴上来回移动了。

这里有两个初学者容易栽跟头的地方。第一个是脚本拖上去以后没有触发update，常见原因是你拖的是脚本资源本身，而不是新建一个行为实例。Superpowers 的编辑器里，拖到 Actor 上时会自动为这个 Actor 创建一个对应的行为组件实例，但如果你发现没触发，可以检查一下 Actor 的电组件面板里是不是真的出现了一个“已完成生成”的状态。第二个问题是speed改得太大，导致每帧移动距离过大，直接穿出了摄像机视野。建议初值保持在小数级别，比如 0.01 到 0.1 之间。

4.3 接入按键输入

脚本动起来后，再往下就可以接输入了。Superpowers 的输入系统需要你先在“输入映射”里定义一些逻辑按键名称，然后把物理按键映射到这些名称上。比如定义一个叫做Forward的逻辑按钮，绑定到键盘上的 W 键。

然后，在脚本里就可以这样写：

class MoveBehavior extends Sup.Behavior { update() { let moveZ = 0; if (Sup.Input.isDown("Forward")) { moveZ = 0.05; } this.actor.move(0, 0, moveZ); } }

这样按 W 时方块前进，松开就停止。和直接判断键码相比，逻辑按键名的好处是以后切换按键方案很方便，不需要改代码，只要在编辑器里重新绑定键位就行。这在我们做多平台适配时省了很多事。

4.4 导出与发布

做完的 HTML5 游戏需要导出才能在浏览器之外的环境运行。导出功能会生成一个包含 HTML、JavaScript 和资源文件的目录。你把这个目录扔到任意静态托管服务，或者直接压缩成 zip 上传到支持 HTML5 的游戏社区平台，别人就能直接玩到了。

我自己的经验是，导出的体积通常不会很大，因为资源都是按需打包的，没有用到的资源不会被打包里。如果导出的文件特别大，先想想是不是不小心把某个大贴图挂在了一个不可见的 Actor 上。

5. 踩坑与问题排查实录

5.1 安装和启动阶段的常见问题

有些人的桌面应用启动后一直停在加载状态，浏览器也没有自动弹出编辑器。我遇到过的原因主要有这几类：

我建议遇到启动问题时，先看一次控制台日志。Superpowers 很喜欢把关键信息写到日志里，端口、地址、错误原因都在里面，能省去大量瞎猜。

5.2 脚本不生效，先查这三件事

脚本是 Superpowers 里最容易出错的一环，因为逻辑写在资源里，生效靠拖拽，调试入口又不明显。我总结了三个排查方向：

• 检查脚本有没有编译错误：控制台通常会直接提示。如果你在代码里少打了个分号，或者类型写错了，整个组件是不会被实例化的。
• 检查是否成功挂到 Actor 上：只是把脚本资源放在资源面板里还不够，必须拖到目标 Actor 的组件列表里。每次修改完脚本内容，要回到场景里确认那个 Actor 的组件状态没有变红或变成缺失。
• 检查是否设置了主场景：如果你忘掉把当前场景设为主场景，运行时看到的可能是默认空场景，你的方块和脚本自然都没出现。

另外，脚本里的update不是越大越好。如果有人让你把游戏循环跑到 60 帧，那你得明白：浏览器里的update帧率并不是稳定值，不同显示器的刷新率不同，所以不要在update里直接加固定数值。如果你需要真实计时，优先用引擎提供的时间相关属性，而不是自己数帧数。

5.3 协作模式的注意事项

协作模式虽然好用，但也要掌握频率。比如两个人同时拖动同一个 Actor，系统会以最后一次改动的用户为准，另一方的改动会被覆盖。这不是 bug，而是实时同步的必然结果。建议团队里约定好：不要太多人同时编辑同一个场景的同一个节点。

另一个常见问题是联网后资源变了，但本地预览没刷新。这不能算 bug，更多是浏览器缓存。我遇到这个情况会直接刷新编辑器页面，或者重启应用。如果是长期合作的项目，最好统一成员的浏览器版本，差的版本在 WebSocket 长连接上偶尔会无缘无故断线。

5.4 不要期待它成为全能引擎

用 Superpowers 做项目这么久，我也要给它泼点冷水。它不适合做大型 3D 小型游戏，不适合需要重度物理模拟的玩法，更不适合想实现复杂 UI 的场景。它的优势带在：快速原型、小体量游戏、多人协作、教学演示。如果你要做有很长流程的角色扮演游戏，或者画面要求很高的动作游戏，主流商业引擎会是更合适的选择。

我见过一些想“把 Superpowers 当成 Unity 替代品”的团队，最后的结论都是失望。工具的定位和工具本身一样重要，找错定位就会放大短板。

最后再分享一个小技巧

最后说一个我实际操作中觉得特别有用的技巧：在协作时给每个成员分工，尽量按“资源类型”而不是“场景区域”来分。一个人专门管脚本和逻辑，另一个人专门管场景摆放和资源处理。因为脚本和场景在底层是不同文件，这样分工可以最大化利用它的实时同步能力，减少两个人同时改动同一个文本资源造成的冲突。

这种做法听起来很朴素，但我在 Game Jam 里用得很顺手：一个队友在预览窗口里往场景里摆障碍物，另一个队友在同一项目里写碰撞逻辑，两边完全不卡壳。互不打扰的同时，协作又能实时可见，这种效率体验让我一直保留着 Superpowers 作为“快速验证想法”的首选工具。