游戏概述
游戏名称：TRAE宝奇遇记
游戏玩法：策略卡牌闯关游戏
背景介绍：TRAE 公司的秘密实验室中，一具沉睡万年的机械体猛然苏醒。核心引擎重新点火，轰鸣声响彻整座实验室，TRAE宝的探险就此展开。
开发工具：TRAE SOLO + Godot
《TRAE宝奇遇记》是一款融合了《炉石传说》和《杀戮尖塔》体验的卡牌游戏：战斗内，玩家可以召唤随从、释放法术、规划费用和目标；战斗外，则通过地图节点推进，遭遇事件、进入商店、休息强化、收集遗物，一步步构筑自己的卡组与路线。
下面给出游戏链接，欢迎大家体验并在评论区分享体验或者提出建议：https://traebao.jinlongchaogu.cn/
游戏还在继续打磨中，如果有BUG也可以告诉我，我会尽快修复。
游戏截图
万事开头难？一句话启动SOLO！
作为一名游戏策划，我脑海里一直有很多玩法点子，但真正动手时，总会遇到那个经典问题：
我真的能一个人把它做出来吗？
直到我打开 TRAE SOLO 网页端，这种畏难感突然被拆掉了。因为我不需要一开始就准备完整架构图，也不用先把每个系统想得滴水不漏。只需一句话，就能开启我的游戏制作之旅。
点击输入框，开启了Plan模式后，我的游戏就正式启动了！
仅仅喝杯咖啡的功夫，SOLO 就生成了一个可运行的游戏原型。虽然第一版界面还很朴素，但主菜单、战斗、卡牌、单位、基础交互都已经具备。对独立开发来说，这一步非常关键：它让我不是面对一个空文件夹，而是面对一个可以继续迭代的游戏。
选择 Godot作为游戏引擎
在 SOLO 帮我完成原型后，我选择用 Godot 继续推进项目。Godot 是开源引擎，场景、脚本、资源组织都比较透明，非常适合和 AI 协作。
我提出策划需求，SOLO 修改脚本和场景；我在本地拉取代码测试，再把问题反馈给云端的 SOLO 继续处理。设计、实现、测试、修正可以形成一个很快的循环。
动动嘴皮子完成 Git 版本管理
写代码痛快，但整理 Commit 提交往往让人觉得繁琐。我的项目使用 Git 进行版本控制，现在，当我在 SOLO 网页端完成一个功能迭代时，只需在对话框输入：
“SOLO，帮我把当前版本上传到 Main 分支。”
SOLO 会自动分析差异，生成规范的 Commit Message，并无缝同步到我的 GitHub。
像素级UI设计：别让 AI 猜你的坐标
很多人会觉得 AI 写 UI 容易“布局乱飞”。我的经验是：不要让 AI 猜你的心思，直接给它明确的坐标系、尺寸和约束。
比如战斗界面，我先在 Axure 中做好原型图：
然后给 SOLO 一段非常具体的提示词：
以左上角为瞄点，修改下游戏内场景
1.天栏和遗物区域为独立场景，先不用管
2.我方分为英雄和随从，敌方分为怪物和爪牙。英雄和怪物的大小为100x130，随从和爪牙的大小为75x100，单位面板大小为100x160，单位区域大小为900x185，单位面板在单位区域内居中，间距为25px。
3.无论是英雄、随从、怪物还是爪牙，表现形式都是MinionStylePreview.tscn，英雄和怪物为HeroFrame，爪牙和随从为UnitFrame，嘲讽为TauntFrame。
4.结束回合按钮设置为100x60，坐标(1050,450);结束回合文字在按钮正中，20号字体。
5.水晶显示区域大小(75x75)，坐标(50,450)
6.弃牌堆区域和抽牌堆大小(50x50)，弃牌堆坐标(1150,550)，抽牌堆坐标(0,550)
7.手牌区大小为600x120，单张手牌大小为180x240，扇形显示在手牌区，手牌区坐标(300,480)
尝试下来，这样的效果意外的好，对 AI 来说，越明确的布局约束，越容易生成稳定、可迭代的界面。
半天搞定卡牌战斗框架
卡牌游戏的精髓在于各种机制的交织与结算，战斗底层框架可谓是重中之重。我曾参与过商业卡牌游戏的策划，当时和程序员老哥肝了整整三个月，从零搭起了一套像样的战斗框架，那时我还觉得这速度已经很快了，可谓是相当骄傲。然而到了2026年的今天，我试着让SOLO做一套卡牌战斗框架，我提供思路，它负责实现，不到半天就完成了基础框架的搭建，后续修修补补也用不了太长时间，让我曾经的骄傲瞬间破碎，留下的只有对SOLO的敬畏感。
主要思路
《TRAE宝奇遇记》的底层思路是表格驱动。项目里有一整套 CSV 配置：
- card.csv 配置卡牌名称、类型、费用、品质、描述、技能和效果。
- skill.csv 配置技能目标、选取方式、结算类型、公式、表现方式。
- effect.csv 配置触发时机、效果类型、参数和目标。
- unit.csv 配置英雄、随从、怪物、行为技能序列。
- relic.csv 配置遗物效果、计数方式、商店价格。
- events.csv 和 jueze.csv 配置事件文本与抉择结果。
- map.csv 配置地图层数、节点类型、宽度区间和怪物等级。
举个例子，卡牌 防火墙护盾 在表里配置为 1 费技能牌：获得格挡，并抽 1 张牌。它的卡牌技能指向 skill.csv，技能效果再指向 effect.csv。也就是说，策划只要改表，就能组合出新的卡牌逻辑。
技能公式也做成了可配置表达式，例如：
施法者[攻击]*技能参数[0]
代码中的 Formula.gd 会把它转成可计算变量，例如攻击、防御、技能参数等。这样一来，不同单位、不同技能等级、不同状态影响，都可以通过配置和运行时数据共同结算。
真正执行战斗的是 CombatResolver.gd。它处理了目标选择、嘲讽过滤、技能释放、伤害、格挡、治疗、状态、召唤、抽牌、弃牌、费用变化、遗物计数、卡牌发现、升级、移除等效果。触发时机也被拆成了配置项，比如： - 回合开始时生效
- 回合结束时生效
- 打出卡牌时生效
- 造成伤害前生效
- 造成伤害后触发
- 单位上阵时生效
- 获取卡牌时触发
项目打包及部署
Web 版本我没有完全依赖 Godot 编辑器里的手动导出，而是写了脚本流程，这是我探索多次后的最终决定。
Godot导出工具有一个弊端是如果想要把项目多个资源包拆开打包，需要手动操作多次，而直接用Godot控制台进行打包，就可以省略这个过程。分包的目的也很简单，降低玩家的加载时间，让比如事件的背景图片等资源可以等到玩家需要的时候再去加载。
部署平台我最终选择的是火山引擎的IGA Pages。一开始我是打算用Vercel的，但我如此多的资源根本无法上传上去，这时我急于寻求一个可替代的平台，便打开了豆包。豆包正好告诉了我火山引擎的IGA Pages，尝试了一下，支持单包1G容量上传，正好满足了我的需求。那天下午TRAE也发表了在TRAE中一键部署IGA Pages的公众号文章，可谓是非常巧了，有兴趣的读者可以去TRAE的公众号再去看看那篇文章，部署方法写的很详细。
总结
在有了SOLO的加持下，一个单人项目，真的可以不是从“宏大计划”开始，而是从一个能跑起来的原型开始。
然后一点一点去推动，借助SOLO强大的能力，完成路径中的每一小步。
最后把它从一个概念，慢慢变成一个真正的实现。
与其感慨路难行，不如马上出发！
如果你也对用 TRAE 制作游戏感兴趣，欢迎加入 TRAE 官方游戏交流群一起探讨：
