1. Superpowers 是什么，它到底解决了什么问题
我最早听到“Superpowers”这个名字，是在一个游戏开发社群的聊天记录里。有人甩了一句“我们要不要试试用Superpowers做个小游戏”，后面跟着一串链接。当时我以为是某种营销噱头，还专门去查了一下，结果发现它是个开源的、自托管的实时协作游戏开发环境。名字起得非常直白——superpowers，翻译过来就是“超能力”。这个工具最大的卖点，就是让你在浏览器里和别人像写文档一样协作去开发游戏，而且开发的是真正的 2D/3D HTML5 游戏。
刚接触的人最常问的问题是：它和 GameMaker、Unity、Godot 这些有什么不同？
这里要先说一个核心背景。Superpowers 的设计目标不是做一个单机编辑器，而是做一个“自带同步能力的游戏开发平台”。它由服务端和客户端两部分组成。服务端运行在你的电脑或者你的一台服务器上，所有开发数据都存放在服务端；客户端就是一个网页，你和你的队友通过浏览器连接到服务端，就能同时编辑同一个项目。这就像一群人围在同一个桌子上画同一张画，别人动笔你立刻能看见。
这种模式解决的痛点非常具体：传统游戏引擎在多人协作时，绕不开版本管理、分支冲突、资源同步这些问题。虽然有 Git 这类工具，但对于非程序员出身的策划、美术来说，Git 的学习成本实在不算低。Superpowers 直接把这个环节搬到了编辑器内部，实时同步操作记录，连资源文件都一起同步，你说它是不是省了半个运维的工作量。
它有 3D 和 2D 两套引擎，脚本语言统一用 TypeScript。编辑器自带资源管理、场景编辑、脚本编辑器、模型查看器，甚至还能直接编辑地图块。一个项目从建场景、摆模型、写逻辑、调动画到最终导出发布，全过程可以在一套体系里完成。对比其他引擎，它更像是一个“轻量但五脏俱全”的独立工具链。
适合谁用？我认为三类人最有必要尝试：一是想和朋友快速做个网页小游戏、不想折腾 Git 协作流程的团队；二是想从零学习 TypeScript 游戏编程、但又嫌 Unity 太重的新手；三是对工具本身有研究兴趣，想看看“把编辑器搬进浏览器”这条路到底能做到多极致的开发者。如果你是这三类人之一，这篇文章能帮你少踩很多坑。
2. 核心架构与设计思路
2.1 自托管服务模式：为什么把编辑器做进浏览器
Superpowers 的架构一句话概括：服务端负责存储和构建，浏览器负责编辑和展示。所有项目数据保存在服务端，客户端通过 WebSocket 与服务端保持长连接，实时同步操作流。
我第一次接触这个思路时，第一反应是：直接在本地跑一个 Electron 类桌面应用不是更省事吗？为什么不干脆做成一个单机软件？
后来我理解了开发者们的坚持。把编辑器放进浏览器的好处，比我们想象的实用得多。你不需要给每个团队成员安装编辑器，打开浏览器输入网址就能开工；无论对方用的是 Windows、macOS 还是 Linux，只要浏览器支持 WebGL 就行；服务端统一管理数据，备份只备份一台机器即可。这就是典型的“瘦客户端”模式——每一台开发机不需要关心项目文件在哪、要不要做同步，这些都由服务端处理。
这样的模式也有代价。编辑器完全在浏览器中运行，意味着编辑器本身的代码量必须控制在合理范围内，功能不能像传统大厂引擎那样无限堆特性。Superpowers 选择走“够用、顺手、可扩展”的路线，核心功能都做好了，但没有那么多复杂弹窗和菜单。
从玩法和场景来说，这种架构特别适合教学环境。我可以把服务端部署在一台内网服务器上，教室里十几台电脑同时连接同一个地址，学生各自操作、互相可见，老师能实时看到每个人的改动。这比让学生各自装软件、再逐个导入项目要顺畅太多。
2.2 TypeScript 作为唯一脚本语言的取舍
Superpowers 没有像 Scratch 那样提供可视化编程，而是直接把 TypeScript 作为唯一的脚本语言。这个选择在综合考量上是合理的。
用 TypeScript 而非 JavaScript 的优势很明显：类型系统在团队协作时能减少大量低级错误。场景里定义一个实体的属性，在编辑器里会有自动补全，写错属性名或类型不匹配会立刻在编辑器的错误提示面板里标红。对于刚开始学编程的同学，这种“编译时反馈”非常友好的，错误写出来就能看见，不必等到运行时去猜。
当然，强制只用 TypeScript 也意味着你要先学一点编程语法。这在项目设计中是一个有意识的取舍，想插上“超能力”必须使用与它配套的语言。但话说回来，TypeScript 本身在 Web 开发领域已经是现代前端的主流标配，学会了它不只是能用 Superpowers，之后做其他 Web 项目也能直接上手，这笔技术债不亏。
脚本的使用流程通常是：在场景里选中一个实体，在编辑器右侧面板中挂载一段脚本组件；然后编辑代码，脚本逻辑就会绑定到这个实体上。绑定后的实体就像一个“角色卡”，你想让它移动、旋转、碰撞、播放动画，都可以写在同一个脚本里，非常直观。
2.3 编辑器内嵌一切：资源、场景、脚本一体化
用过传统引擎的人都知道，Unity 和 Godot 虽然功能全面，但资源导入、场景编辑、代码编写往往分布在不同的面板和窗口，新手经常在混乱的 UI 里迷路。Superpowers 做了很强的整合：左侧是项目资源树，中间是 3D 场景视图，右侧是当前选中的实体属性与脚本编辑区，所有工作都集中在同一个界面里。
它还内置了素材商店（Asset Store）相关的独立生态体系。你可以从在线资源库中下载他人共享的模型、贴图、音效和脚本包，也可以做成自己的可复用部件。这种“边做边攒积木”的体验，非常适合做 Game Jam 这种短平快开发场景。你不需要从零打磨美术资源，用现成素材拼搭原型，重点是快速验证玩法。
值得单独一提的是对 Markdown 的支持。Superpowers 内置了 Markdown 组件，可以在项目里写文档、写设计稿、写流程说明。这看起来只是个加分项，实际用处很大。我在实际协作时，就直接把游戏设计文档和策划表放在项目里一起管理，成员打开编辑器就能看到，不用切到群文件去翻 PDF，减少了信息不同步造成的返工。
3. 手把手安装 Superpowers：从零启动到浏览器打开编辑器
3.1 环境准备：Node 版本与下载方式
Superpowers 的服务端基于 Node.js，所以需要先安装 Node.js 环境。这里有一个容易被忽略的版本注意点：别看它出来得早，它需要的 Node 版本并不要求最新，但如果你的环境是特别新的 Node LTS 版本，反而可能遇到某个依赖编译不兼容的问题。按长期实践来看，装一个 LTS 版本（例如 18 或 20 系列）通常最稳。
下载方式通常有两种。一种是从它的官方仓库或发布页下载对应平台的压缩包，解压即用；另一种是通过 npm 全局安装命令。我个人的建议是先走压缩包路线，原因很简单：它自带运行所需的核心文件，不会受全局环境中其他依赖版本的干扰，对动手能力还在锻炼阶段的玩家来说是最好维护的方式。如果你走 npm 全局安装，注意记得在后续执行时使用与全局安装匹配的 npm 环境变量。
在正式启动之前还要确认，你需要一个不被防火墙拦截、可供浏览器访问的本地端口。Superpowers 默认端口是 4237，数据接口和部分通信也会用相邻端口，所以你不光要放行 4237，还要留意是否有别的进程占用了它。
3.2 启动服务端：命令、日志与默认端口
在安装目录下找到可执行文件。注意不要直接双击图形化的启动脚本，建议打开终端进入安装目录，执行对应的启动命令。第一次启动时，它会自动初始化数据目录，生成一些配置文件和日志文件。
启动成功后，终端会打出类似“服务已启动”的日志，接着会告诉你打开浏览器访问的地址，一般是http://localhost:4237。如果你是在远程服务器上部署，访问地址就要替换成服务器的公网或局域网 IP。
我实际部署中还发现了一个细节：如果你把服务端放在一台长期开机的服务器上，建议搭配 pm2 或 systemd 来做进程守护。因为这些工具没有内置的崩溃自恢复机制，一旦进程退出就彻底停了。写个简单的 systemd 服务脚本，每次开机自动拉起，比手动去开工要省心得多。
3.3 客户端访问与账户初始化
服务端跑起来之后，打开浏览器访问上面的地址，就能看到客户端界面。这里有一个专门设计的步骤：第一次打开时需要填写一个用户名和密码，用来注册一个本地管理员账户。这里的账户并不是对外发布的玩家账号，而是用来管理项目成员的一种开发权限体系——只有登录了管理员账户，才能创建项目、添加其他成员。
创建完成后的界面可能会让你有点陌生，因为它不像 Unity 那样给你一个默认的空白场景。你需要自己新建一个项目，并在项目里新建场景。这也是新手容易卡住的第一道坎：找不到“新建项目”的按钮在哪里。按照我摸索出来的路径，进入主界面后找到“新建项目”，输入项目名称，选择 2D 或 3D 模板，确认后就能自动打开一个包含基本场景的编辑器界面。
从这一步开始，Superpowers 真正的工作舞台就搭好了。接下来就是往里填东西。
4. 从一个空白项目到可玩 Demo
4.1 创建项目与场景基础操作
进入项目后，你会看到一个默认的 3D 场景。场景里通常有一个地面或网格，方便你用它作为参考线来定位。我们需要做的第一件事，是学会用鼠标控制场景视角：按住鼠标中键拖动是平移视角，右键拖动是旋转视角，滚轮是缩放。对于习惯 Blender 或 Unity 3D 操作的人，这套按键基本不需要适应期。
在左侧资源树中找到“场景”目录，双击场景文件打开后，就可以在场景中放置实体了。这里的“实体”是一个非常泛化的概念，可以是一个模型、一束光、一个空对象，也可以是一个挂载了脚本的逻辑载体。选中实体后，右侧面板会出现它的属性区，你可以在这里修改位置、旋转、缩放这些变换参数，也可以通过拖拽的方式把资源库里的模型拖到场景中。
一个小技巧：给实体起名字不要懒。默认生成的实体名都是“Entity 1”“Entity 2”，一旦脚本里要引用这些实体，或者队友帮你调试时，满屏的“Entity 13”会让人抓狂。养成给实体起语义化名字的习惯，后面能省一整晚的定位时间。
4.2 给实体写第一个 TypeScript 脚本
现在来写一个最简单的脚本，让一个方块绕 Y 轴旋转。这个例子虽然基础，但能帮助你走通“挂载脚本—编辑代码—运行查看”的完整闭环。
在场景中创建一个立方体实体，然后在实体上添加一个“脚本”组件。Superpowers 会为这个实体生成一个新的脚本文件，并自动在右侧打开代码编辑区。默认生成的代码框架看起来可能是这样的：
// 这里是一个简单的示例脚本 // 你可以在函数里写自己的逻辑 class MyBehavior extends Sup.Behavior { update() { // 每帧调用 } } Sup.registerBehavior(MyBehavior);如果要在 update 里实现旋转，直接对实体的本地旋转做累加即可：
class MyBehavior extends Sup.Behavior { update() { this.actor.rotate(0, 0.02, 0); } } Sup.registerBehavior(MyBehavior);update方法会在每一帧渲染前被调用，等同于 Unity 里的 Update。在里面写连续的小角度增量，就能让实体平滑旋转。0.02这个数值就是旋转弧度，数值越大转得越快。之所以不直接改this.actor.position去做移动示例，是因为旋转涉及更多坐标系概念，写起来比移动多一个层次。
写完脚本之后，点击界面上的运行图标，或者按快捷键启动预览模式，你会发现场景里的方块开始缓缓旋转。如果你修改脚本里的数值并重新运行，旋转速度会立刻变化。这套“改代码—运行—看效果”的循环非常短，非常利于反复验证玩法逻辑。
4.3 协作开发实战：两个人同时改一个场景
Superpowers 的核心卖点就是协作，所以这一段我们要真正把它用起来。你在场景里开着一个方块，让队友也打开同一个项目、同一个场景，双方就能看到对方的操作光标和实体边框。
我在团队协作中实际用到的流程是这样的：队友负责搭建场景美术，我负责写核心玩法脚本。我们同时编辑一个场景，他调整实体位置时，我如果恰好在写引用该实体位置的逻辑代码，不用等待他保存，我调用的数据就是最新的。这让“我在等他的坐标值”这种阻塞完全消失了。
不过协作也不总是顺风顺水。有一次我和队友同时给同一个实体挂脚本，他挂了一个，我也挂了一个，运行效果叠加起来，行为完全失控。后来我们约定了一个简单规则：每个实体上的脚本组件一个人负责，别人不碰；如果确实需要改动，就在项目文档区里留一条备注，让对方来改。这个约定不起眼，但避免了大量无意义的互相干扰。
4.4 导出与发布：从本地到可访问链接
开发完项目后，下一个问题是：怎么让别人玩到？
Superpowers 提供了一套导出功能，可以把当前项目打包成可部署的静态 Web 文件。导出方式在项目管理菜单里，生成的文件是一个 HTML 入口加若干 JS、资源文件的集合。把它放到任意静态托管服务上——GitHub Pages、个人服务器，或者对象存储静态网站——用户就能在浏览器里直接打开游玩。
导出过程有几个我踩过的提醒。第一，导出前一定检查项目里所有资源是否有引用损坏。如果存在找不到的贴图或模型，导出过程中可能不会报错，但游戏运行时画面会出现异常。第二，如果你用了外部字体或其他资源，确认许可证允许再打包分发。第三，导出的首屏加载依赖文件较多，如果放在国内访问较慢的服务器上，可以构建一次后再用压缩工具优化文件体积，体验差距很明显。
5. 常见问题与排查实录
5.1 服务起不来或端口被占用
这是新手遇到频率最高的问题。启动后日志显示端口绑定失败，基本都是 4237 端口被占用了。用常用的端口排查命令netstat -ano | findstr 4237（Windows）或lsof -i:4237（macOS/Linux），找到占用进程后决定是结束它，还是改 Superpowers 的配置端口。
这里给一个经验：不要在服务端运行时直接改端口配置。需要先停掉进程，修改配置文件中对应的端口，再重新启动。改端口后访问地址也要对应变化，别再用老地址去连。
如果服务启动时提示缺少某个依赖文件，十有八九是解压不完整。先把整个目录关闭，重新解压一次。我记得自己在压缩包下载中因为网络中断，解压出一个不完整的包，折腾了快一个小时才想到重新下载对版本。
5.2 模型导入与材质丢失
使用第三方模型时，材质变黑或显示异常是常见现象。Superpowers 对模型格式的支持有自己的边界，很多通用三维软件默认导出的格式未必能完美兼容。遇到这种情况，我建议先在三维软件中把模型拆分成基础组件，再尝试用通用格式导出，注意检查是否包含了纹理贴图文件，以及贴图路径有没有中文或特殊字符。
我的一个踩坑记录是：模型明明带了贴图，导入后仍然看不到材质。后来排查发现是贴图格式为 TGA，而引擎对 TGA 支持不及更通用的 PNG/JPG 格式。把贴图用图片工具批量转成 PNG 后重新导入，问题立刻解决。所以在项目初期，所有美术资产统一规范格式能省很多麻烦。
5.3 多人同时操作导致的同步异常
虽然 Superpowers 对实时同步做了很多优化，但极端情况下仍会出现状态不一致。例如两个成员同时删除一个实体，服务端可能显示一方操作失败；或者两个人都改了同一个脚本，形成覆盖。
我给团队定的章程是：删除操作要在场景操作前口头沟通一句，或者直接在协作面板里发消息确认；对脚本文件的修改，尽量采取“一个人主写，其他人只在必要节点提建议”的方式。如果真的出现了不同步，最直接的解决思路是刷新浏览器，让它从服务端重新拉取全量状态，很少有状态会顽固到刷新都解决不了。
另外，我建议团队成员养成定期把项目复制一份备份的习惯。Superpowers 虽然自带了简单的版本历史，但最稳妥的保障，还是服务端的整个数据目录被定期打成压缩包存到别处。这个实操习惯我踩过坑之后才补上：有一次服务端所在的磁盘坏了，连续两天的开发内容全部丢失，从那以后我每天结束工作前都会手动跑一次备份脚本。
6. 我的实际使用心得与建议
6.1 用了一年之后，我对它优劣势的重新理解
刚上手时，我总拿它和 Unity 做对比，总觉得它哪里不够。使用一段时间后，我才逐渐理解了它的产品定位：它追求的不是功能大而全，而是在“Web 协作开发”这条赛道上的小而精。它的核心价值是所有开发键都围绕“协作”设计，在多人同屏、快速迭代和轻量分享这些场景下，它的优势非常明显。
它的短板也很明确：3D 图形渲染和物理模拟能力相对弱，复杂的大型商业项目做起来会比较吃力。如果你的目标是做精致的 PC/主机游戏，Superpowers 大概率不是合适的选择。但如果你只是想快速验证玩法、做教学演示、做线上游戏编辑器原型，这套工具的性价比极高。
6.2 后续扩展方向与进阶资源
玩透了 Superpowers 基础功能后，我建议深入研究的几个方向如下。
第一是插件机制。Superpowers 有插件系统，你可以自己写新的资源类型、组件类型，扩展编辑器的能力上限。做了一些基础玩法后，为了让项目支持更规范的存档结构，我花了两个晚上研究插件文档，最终实现了自定义数据组件的读写。虽然是耗费精力，但研究透后会感觉工具的上限又抬高了一大截。
第二是自定义资源库。团队内部的公共模型、公用脚本片段，放到自己的服务器上配置成私有资源库，可以极大减少重复造轮子。这个方法特别适合持续迭代多个小项目的团队。我把常用碰撞逻辑、移动控制脚本都沉淀进去之后，新项目起步速度快了很多。
第三是服务器运维。如果你把 Superpowers 部署在一个常开的云服务器上，建议学一点基础的进程守护、日志巡检和定期备份操作。这些运维知识虽然初学起来有一点门槛，但它能直接降低项目托管出去后出问题的概率。这一整套内容做下来，你收获的就不只是会做几个小游戏，而是一套从开发到协作、到发布再到维护的完整项目能力。
