“如果你还在用Superpowers那我不要和你说话”——第一次在游戏开发群里刷到这句话时我以为是哪个老哥喝多了在开地图炮。后来发现这句话已经成了部分开发者之间的“身份声明”一句玩笑里藏了太多东西。Superpowers是什么如果你混过独立游戏圈应该对它不陌生一个开源的、基于TypeScript的协作式游戏开发IDE主打多人实时编程发布到现在快十年了。它现在还能打开、能建项目、能跑几个小人但社区里已经有越来越多的人觉得“还在用它的人跟不上时代了”。这篇文章不是来给Superpowers办追悼会的更不是赞成那句“我不要和你说话”的傲慢。我更想借这个标题聊聊它背后的信息量一个工具是怎么从热门走向“被嫌弃”的以及作为一个开发者面对新旧工具更迭时到底应该怎么选、怎么迁、怎么避免踩坑。适合正在做小游戏、刚入行还在纠结用哪个引擎、或者手头恰好有老Superpowers项目的朋友看。1. 一句调侃背后的“Superpowers”到底是什么1.1 Superpowers的设计亮点一个“像写文档一样写游戏”的IDESuperpowers当年能吸引人核心卖点就俩字协作。那个年代2015年前后大家做独立游戏通常是一个人埋头写代码另一个人单独摆场景互换版本靠U盘和网盘改个素材文件名都能把人逼疯。Superpowers直接把IDE塞进浏览器后来也做了桌面版项目文件统一存在服务器上多人可以像Google Docs一样同时编辑同一个场景、同一段代码。一个人拖着角色另一个人在旁边改对话脚本这种体验在当时简直是降维打击。它的技术选型也相当激进直接用TypeScript作为游戏逻辑语言IDE内置代码编辑器、场景编辑器、资源管理器甚至还有一套基于Actor/Component的实体模型。你不需要额外配置复杂的环境装个客户端打开浏览器就是开发环境。对于只想快速做个小游戏、不太想折腾编译链路的团队来说Superpowers上手门槛确实很低。我当时还拿它做过一个2D平台跳跃原型带物理碰撞、敌人巡逻、简单UI整个流程非常顺。它的“Sup.Actor”模型让每个游戏对象都有清晰的逻辑入口代码组织方式很规范。而且因为是TypeScript写完代码有类型提示对习惯了前端开发的人来说非常亲切。1.2 为什么它会被贴上“过时”的标签时间拉到今天Superpowers的问题就藏不住了。最扎眼的是维护状态。GitHub上最后一次有实质性的release更新已经过去了很多年Issues区积压了大量bug没人处理PR提交上去也没人合并。一个开源工具如果维护者不在了它在开发者心里的“可信度”就断崖式下跌不管功能当初多惊艳都不敢把它用在正经立项上。第二个问题是生态。一个游戏开发工具的价值不只看它的内置功能更看围绕它的内容有多少教程多不多、第三方库全不全、有没有素材商店、社区能不能解答你的问题。Superpowers在这方面的积累一直很薄。当年连官方文档都写得比较简略社区里除了几个入门Demo几乎找不到深度案例。对一个新用户来说学了一套小众语法然后发现资料全靠自己摸索这感觉非常劝退。还有一个容易被忽略的因素技术栈老化。Superpowers基于早期Web技术现在打开它你明显能感觉到启动慢、编辑器界面卡顿、对高分屏支持不佳。而同期成长起来的引擎比如Godot的现代UI、Phaser对现代前端工具链的拥抱都已经进化了不止一个版本。一个还停留在“浏览器插件时代”体验的工具确实很难留住人。2. 从Superpowers到新工具选型该怎么看2.1 工具不是越新越好也不是越旧越要扔那句“如果你还在用Superpowers我不要和你说话”本质上是一种“工具鄙视链”的表达。鄙视链在技术圈一直存在从编辑器、框架、引擎到操作系统总有人以“我用新东西”为荣以“你用老东西”为耻。但作为实际做过项目的人我想说一句公道话工具的新旧本身不决定项目成败。用上古工具做出好游戏的人大有人在用最潮引擎把项目做砸的也比比皆是。选游戏开发工具我建议先回答自己三个问题。第一你的目标平台是什么如果只做网页小游戏Phaser、PixiJS这类轻量框架比全能引擎顺得多如果要做多平台Steam、手游、主机那就得考虑Godot、Unity、虚幻这类引擎。第二你的团队结构是什么一个人单干选一个启动快、资料全的工具两三个人协作就要看版本管理和协作流程是否顺手。第三也是今天特别想强调的这个工具还活着吗判断“活着”不是看官网还在不在而是看commit频率、release节奏、issue响应速度、社区讨论活跃度。一个工具哪怕功能再酷如果已经三年没人维护了那它就不是一个理性选项顶多算个玩具。Superpowers恰好就倒在这一条上。它最打动人的协作特性放在今天也仍然有价值但价值已经被更成熟的工具工作流反超了。现代团队做协作游戏根本不需要“同一个服务器上实时编辑”这种原始形态Git加分支再加CI自动构建既让多人并行写代码互不冲突又留下了完整的版本历史比一个共享空间可控得多。工具本身没有罪但它没能陪大家走到工作流进化的下一步这才是它被嫌弃的根本原因。2.2 几个值得参考的替代选项Godot开源、免费、轻量内置2D和3D编辑器场景系统非常灵活有专门的GDScript语言学习成本很低很多功能都做过视觉化处理也支持C#。近几年的社区活跃度和版本迭代速度都很猛是Superpowers玩家最顺手的迁移目标之一。Phaser一个JavaScript/TypeScript游戏框架专门面向Web游戏。它不提供可视化编辑器但与现代前端工具链npm、Vite、微信小游戏适配结合得很好适合习惯写代码而不是拖节点的团队。Defold同样是开源2D引擎。编辑器和运行时是分开的用Lua写逻辑轻量到极致做移动端2D游戏性能很稳。它内置了一套基于Game Object和Component的模型和Superpowers的Actor模型有一定相似度迁移的时候结构感会比较熟悉。LÖVE一个极其简洁的Lua 2D框架适合快速原型、Game Jam。它不给编辑器、不给UI方案所有东西靠代码拼自由度极高但同时也意味着所有坑都得自己踩。这几个选项定位差异很大没有哪个“绝对最好”。我的建议是先定交付场景再挑工具。比如你想做一个有完整关卡编辑器、能导出到Steam的2D游戏Godot就是性价比最高的选择你只想快速做一个能在浏览器里传播的联机小游戏Phaser配一个实时后端反而比全能引擎更省力。3. 如果你还在用Superpowers迁移完整路径3.1 先评估别急着搬家在动手迁移之前先冷静评估一个问题这个项目值不值得迁、有没有必要迁。如果你只是拿Superpowers做着玩项目颗粒度很小代码量不到几千行资源也只有零星几个那我建议你直接在目标工具里重写一次不要试图做“迁移”重写可能比迁移更快而且更干净。但如果你手头的是一个已经跑了很久、有大量场景配置和资源依赖的项目那迁移前一定要做成本估算。我的经验是迁移成本由三部分构成第一逻辑代码的翻译成本第二资源文件模型、贴图、音频、动画的搬运和规格适配成本第三也是最容易被低估的就是场景结构重建的成本。Superpowers的场景文件里记录着Actor层级、组件参数、碰撞体形状、资源引用关系这些在迁移后都得手动或半自动重建。先盘清楚这三块你再决定是整体迁移还是拿它做参考、干脆在新区重写一版。具体来说什么情况下建议立刻迁只要符合任一条就不要再犹豫项目已经无法稳定打开或频繁崩溃你需要用的第三方接口/插件已经不维护团队成员换了新人完全不想接手一个停止更新的代码库或者你想发布的目标平台比如小程序、手机端Superpowers根本导不出去。反过来如果项目已经接近收尾、马上就能发布那“能用就别动”也是个成熟的选择不要为了用新工具耽误上线。3.2 迁移步骤与关键操作如果决定了要迁我建议按下面这个顺序来能少走不少弯路。第一步导出资源。在Superpowers中把项目里的所有资源有条理地整理出来图片、音频、字体、动画、材质、脚本。图片和音频直接拷原始文件就行Superpowers的素材源文件一般都在项目目录的assets下面不会加密拷出来基本能用。但如果项目里的图集是打包过的就需要重新切片这里建议直接用纹理打包工具重新生成新的图集不要试图逆向解析旧格式。第二步重建场景。先把每个游戏里的场景清单列出来然后在新工具中建立对应的空场景逐个把角色、地形、碰撞区域、摄像机摆放回去。这个过程手动操作占大头但如果你在新工具里已经写好了基础的实体创建脚本也可以批量生成。比如在Godot里可以用一个脚本来读CSV格式的场景配置自动生成基础节点树剩下的再手动调整。第三步改写逻辑代码。这是核心工作。Superpowers是TypeScript和Phaser天然同语言迁移起来最顺如果目标是Godot就需要把TS翻译成GDScript或者C#。举一个简单例子Superpowers里一个角色移动脚本长这样export class Player extends Sup.Actor { speed 0.1; update() { if (Sup.Input.isKeyDown(LEFT)) this.actor.moveX(-this.speed); if (Sup.Input.isKeyDown(RIGHT)) this.actor.moveX(this.speed); } }同样逻辑放到Godot里GDScript版本是这样extends KinematicBody2D var speed : 50.0 func _physics_process(_delta): if Input.is_action_pressed(ui_left): position.x - speed * _delta if Input.is_action_pressed(ui_right): position.x speed * _delta第四步组装和测试。迁移后不能一上来就做全部关卡校验。先挑一个最小的场景把资源、脚本、碰撞体全部跑通确认基本流程没问题后再逐步扩大范围。每迁完一个场景就立刻做一次版本提交坏了也能快速回退。3.3 资源与物理系统的差异坑迁移中最容易翻车的其实是那些“看起来一样但实际不一样”的地方。首先就是坐标系。Superpowers使用的是Y轴向上的笛卡尔坐标系而Godot、Phaser等工具的2D坐标系默认是Y轴向下。所有角色的初始位置、运动方向和碰撞体位置到了新工具里都需要做一次符号翻转处理。如果你项目里存在大量手工摆放好的坐标点一定不要等着到时候手动改要写个脚本统一做坐标转换否则几十个场景能让人改到怀疑人生。物理系统差异同样要命。Superpowers自带的物理系统更接近“刚体触发器”的简化模型而Godot等工具的物理引擎对碰撞层、质量、摩擦力、弹力都有精细参数。旧项目里一个“脚下很滑”的角色到新工具里可能需要额外调节摩擦力才有一模一样的手感。我可以给你一个最简单的建议迁移初期先把所有物理参数设为默认值用同一个操作流程去游戏里跑几遍记录下“感觉不对”的点再逐一调参。不要一开始就迷信旧参数换了一套物理引擎之后旧数值基本没有参考意义。资源引用也是个大坑。Superpowers的内部引用用的是UUID或内部ID直接搬到新工具会变成一串无意义的乱码字符串。我自己的做法是迁移前先建一个“资源映射表”把旧ID和对应的资源文件名一一对应好迁移脚本在处理场景文件时直接查表替换引用路径。这个步骤看起来费时间但能省掉后期海量的资源丢失排查时间。4. 迁移中的常见问题与速查表4.1 几个典型的实际问题我在帮朋友处理Superpowers项目迁移时遇到过几个高频问题这里整理成速查表方便你遇到时对照排查。Superpowers打不开/白屏。可能原因是老项目还依赖特定版本的浏览器WebGL实现。处理办法优先使用桌面版客户端打开桌面版不依赖现代浏览器特性如果还是不行检查系统是否缺少旧的运行时组件。当然从迁移角度看这种问题已经可以作为“必须迁走”的充分理由了。多人协作模式失效。Superpowers的多人协作依赖自己搭服务器或固定公网地址现在很多老地址都已经失效。如果你内部项目还在用这个功能与其折腾内网穿透、服务器恢复不如趁早换成Git工作流。两个开发者各开分支改完合并再配合自动构建和截图预览协作效率只会更高。编辑器运行卡顿。旧工具在编辑大场景时操作会明显掉帧。遇到这种情况不要指望通过配置优化来挽救这属于架构层面的性能瓶颈。4.2 从“共同编辑”到“版本协作”的思路切换这一步其实是最需要“洗脑”的。老Superpowers用户刚切到Git时会有一种强烈的不适感以前我改东西队友能同步看到现在改了代码还要提交、合并这不是退步吗但真用一段时间就会发现这个“退步”恰恰是进步。同步编辑的问题在于实时可见的并发修改很容易互相覆盖特别是当两个人在同一段逻辑上改的时候。Git的合并机制虽然需要一点学习成本但它提供了冲突检测、历史回溯、代码评审和完整的分支策略。你可以先让一个人做最简单的“中央仓库主分支”工作流等习惯了再过渡到功能分支。从长期维护角度看版本协作带来的安全感远大于实时编辑带来的爽感。5. 工具选型背后的决策思维5.1 工具鄙视链的心理机制回到开头那句“如果你还在用Superpowers那我不要和你说话”。为什么一个工具会被拿来当社交筹码因为人很容易把“我正在使用的工具”和“我的身份认同”绑定在一起。嘲讽老工具本质上是在向圈内人传递“我是紧跟潮流的开发者”的信号。这种心态可以理解但很危险——它会逼着你仅仅为了“不被嘲笑”而去更换工具而不是为了项目真实需求去选工具。比“用旧工具被嘲笑”更惨的是被嘲笑完了换了个新工具项目还是做不出来。工具鄙视链的误区在于它把工具当成了终点但工具永远是手段。你真正要解决的是“把一个游戏做出来、做成、发布出去”这个完整闭环而不是“用某个工具”这个单一动作。每当我想通这一点就不会再被那些“不用XX就不是专业开发者”的言论裹挟了。5.2 我做游戏开发时的工具选择心得说点我自己的实践体会。我在评估一个新工具的时候会做一个特别简单的“三看”动作。一看维护活跃度。打开它的版本发布页和代码仓库看最近一年有没有实质更新。一个连续几个月甚至几年没有版本发布的工具我不会认真考虑。这个标准能直接过滤掉大部分“看起来很酷但已死”的项目。二看案例和教程质量。如果一个工具只有官方Demo能看社区里找不到几个非官方的完整项目那说明它缺乏足够的真实落地验证。面向游戏开发这种高度依赖经验反馈的领域案例的丰富程度往往比官网文案重要得多。三看逃生通道。我特别在意一个工具导出和跨平台的实际能力。如果一个工具只能导出到某一两个平台我就基本不考虑至少得能覆盖目标平台而且要紧的时候能把数据搬出来。活着永远是第一位工具只是壳。至于Superpowers我的态度很简单感谢它当年带来的协作理念但“赞美它”不代表“用它”。每个时代都有属于自己的工具组合Superpowers在自己那个时间点是不少人的启蒙这就够了。真正要负责的不是工具本身而是你把游戏做出来的能力。最后再分享一个我自己的小习惯无论换什么工具先把它在官网上的“获取起步”项目从头到尾照着做一遍再把自己以前做过的最复杂的一个角色丢进去重做一遍。两个小项目试完这个工具好不好用、坑在哪里、契合不契合你的习惯基本就有答案了。用这个办法挑工具远比听别人的“不要和用XX的人说话”靠谱得多。