GZH0017 — GameMaker 把 Claude Code 装进了游戏引擎
有一类开发者，他们脑子里有一个游戏的感觉，但手指还停在键盘上——他们知道想做什么，但不熟悉代码怎么敲出来。
这个状态有个新名字，叫「vibe coding」——感觉驱动编程。你只管说出你要什么，AI 来把代码填上。
4月30日，Dundee（英国的 game dev 重镇）的 GameMaker 宣布了一件事：他们把 Claude Code 直接嵌进了游戏引擎的全新命令行工具 GM-CLI。这意味着，从今天起，开发者可以用自然语言在终端里查询项目结构、定位 Bug、管理构建配置——不是演示，是真的在干活。
这篇文章想认真聊一下这件事。但在那之前，我想先说说 GameMaker 本身。
一款让很多人第一次"感觉自己在做游戏"的工具
2012年，一款叫《Undertale》的游戏在 Tumblr 上悄悄走红。制作者 Toby Fox 是个程序员背景，但当时知道他的人不多。后来大家都知道了：这款游戏卖了几百万份，影响了一整代独立游戏创作者。但很少有人知道，Undertale 最开始是用 GameMaker 做的。
在那之前，Spelunky（2008）已经在圈子里传开了，很多人是通过它才知道 GameMaker 的。后来 Hotline Miami（2013）用一种几乎是暴力美学的视觉风格把 GameMaker 能做到的上限又推了一截。Nidhogg、Hyper Light Drifter、VVVVVV——这几款你可能在某个时期反复玩的游戏，背后都是 GameMaker。
这不是偶然。
GameMaker 的创立者是荷兰计算机科学家 Mark Overmars，1999年推出了第一版，取名叫「Game Maker」。他的想法很简单：让没有编程经验的人也能做游戏。2007年，他把公司卖给了一家位于苏格兰邓迪的小工作室 YoYo Games，从此 GameMaker 进入它的第二个生命周期。
2024年，GameMaker 的社区里有人问了一个问题：「有哪些用 GameMaker 做出来的知名游戏？」下面回帖的很多人不是来炫耀的，是来说「我是玩这个长大的」，或者「我就是看了某个游戏才去学的 GameMaker」。
二十六年。一款工具能陪一代人从「第一次觉得做游戏好像是我能做的事」走到「我真的做出来了」，这不是功能能解释的。
那是关于门槛的降低，关于「也许我也可以」的体验，关于有些人第一次在电脑前感觉自己不只是在消费内容，而是在创造东西。
GMRT 来了：桌面版正式脱离 Beta
说回正题。
GameMaker 这次最核心的动作，是一个叫 GMRT 的新运行时环境——GameMaker Runtime。4月30日，桌面版正式脱离 Beta，开放给所有用户下载。
GMRT 不是一个简单的性能更新。它代表 GameMaker 底层架构的一次彻底重建。相比旧的包装器式的运行时，新系统在灵活性上有本质提升——这也是为什么它能在同一个环境里支持多种语言。
另一个关键信息：GameMaker 承诺在 Q2 向所有用户开源 GMRT 的桌面版、移动版和 Web 版源码。对于一个靠闭源商业授权活了二十多年的引擎来说，这是个大动作。开源不是慈善，它意味着他们需要社区帮他们覆盖更多的平台。
Claude Code 嵌在哪里
这里需要说清楚一件事：Claude Code 不是嵌在 GameMaker 的编辑器界面里，而是嵌在 GM-CLI 里。
CLI 的意思是命令行工具。你在终端里跟它对话，它在你的项目目录里帮你跑命令、读文件、改配置。Claude Code 能执行 shell 命令、读写文件、运行构建脚本——它不是在编辑器里给你一个聊天窗口，而是真正进入了你的开发环境。
这个设计选择很有意思。编辑器里的 AI 助手容易变成一个「看起来有用但实际不解决问题」的装饰。CLI 里的 AI 没办法装，它得真的能干活。
对独立开发者来说，这个区别可能就是「会用但效率不高」和「真的能帮我省时间」之间的差别。
多语言支持：GML 不再是唯一选择
GameMaker 传统上只支持一门自己的语言 GML（GameMaker Language）。这对于从小开始用 GameMaker 的人来说是自然的，但对于团队协作或者想要复用现有代码库的开发者来说，是个限制。
这次路线图确认：今年会加入 JavaScript、TypeScript 和 C# 支持。这意味着你可以在 GameMaker 的环境里用你熟悉的语言写游戏逻辑，而不是被迫学一套只在 GameMaker 里才有用的东西。
从行业角度看，游戏引擎开放多语言支持是个趋势。Godot 早就支持 GDScript 和 C#，Unity 一直以 C# 为主。现在 GameMaker 也走上了这条路。对于语言阵容本来就不强的 2D 引擎来说，这是扩大用户基础最实际的做法。
关于「Vibe Coding」的实话，以及那些没说出口的担忧
「vibe coding」这个词最近在游戏开发社区讨论度很高。它的核心逻辑是：把重复性、摸索性的编码工作交给 AI，开发者腾出精力来想创意、调手感、定体验。
这听起来很美好，但有几个现实问题：
第一，AI 生成的代码出了问题，最后还是你来修。 AI 擅长的是把你脑子里模糊的想法转换成可工作的代码，不擅长的是帮你判断这段代码是否符合你的设计意图。你得先知道你要什么，AI 才能帮你造出来。如果你自己都说不清，AI 给你的是一个看似合理但实际上不是你要的东西，你可能要花比不用 AI 更长的时间才能发现。
第二，游戏开发里真正难的部分——手感调优、关卡节奏、叙事结构——都不是代码问题。 AI 帮不了这些。把 AI 当成一个很快的初级程序员是可以的，但把它当成替你做设计决策的伙伴，现在还不行。
第三，有一组数据值得注意。 近期一些开发者社区的报告显示，AI 生成的代码在生产环境中携带安全漏洞的比例相当高——有的统计说 40% 的 AI 生成代码存在可被利用的漏洞。如果你的游戏涉及用户数据、支付信息，或者任何敏感逻辑，这个比例是不能忽视的。你用 AI 写的代码出了问题，法律责任也是你的，不是 AI 的。
GameMaker 集成 Claude Code，是第一步。它的价值不在于替代开发，而在于把那些「我知道要做什么但不知道怎么写」的环节压缩到最短。
这是一件值得认真对待的事，但不需要现在就宣称它改变了一切。
最后说一句。
GameMaker 走了二十六年，出了一个 Undertale、一个 Hotline Miami、一个 Spelunky。这些游戏之所以厉害，不是因为用了什么引擎，而是因为做游戏的人在「感觉」这件事上下足了功夫。
AI 能帮你写代码。但「感觉」这件事，没有人能替你练。
献给所有曾经——或者正在——用 GameMaker 把脑子里那个说不清楚的东西试着变成真的的人。
主编：珊珊 & 小玫