这是一款灵感来自我小时候常玩的“打面包”游戏的简化版本。
这款游戏我在动手前构思了两天，执行用了大约六小时左右所开发出来的成果。除了必要的上网和用电费用之外，没有额外的开销。
也正是因为需要满足使用免费的大模型对话框的刚性指标，我不得不在动手之前认真思考我所构建内容的规模。
因此，我首先从电子游戏最基础的“点按+拖拽”的方向出发进行思考，确定了这种对人好上手，对硬件和AI工具生产压力不大的操作方案；同时避开了常见卡牌游戏需要进行数学建模来强化游戏性的陷阱（我的数学不好是其次，数学建模需要和游戏效果相匹配，迭代难度大而且测试流程会很长，反而不如“点按+拖拽”的玩法更好进行前期调整）。
接着我开始考虑什么规则和形态匹配这种玩法。我最先想到的就是《愤怒的小鸟》（Angry Bird）那种“选中+拖拽+物理特性”的机制，通过命中获得分数以增加满足感和确定性，但额外的物理特性又增加了一层可控的不确定性。
我最初的想法就是“卡牌游戏”，因此顺着这个思路想了下去。从卡牌比大小，到“拍画片”，再到“摔卡”，最终确定了“打面包”的形态。
但由于“打面包”的物理规则较为复杂，因此我开始考虑简化这个模型。结合《愤怒的小鸟》的玩法，我很快确定了“将一张牌覆盖到另一张牌上就算获胜”的玩法。这样就在保留物理特性的同时避免了复杂的物理运算，一方面任何设备都能轻松运行这款游戏，另一方面也大概率不会吃掉我所用AI工具的免费额度。
大致构思的落地过程是我在配家人逛街途中乘坐交通工具时完成的。回家之后，我打开AI工具的第一件事情就是：
编写游戏文档。
正如课代表最近的内容所言，文档对于项目开发至关重要，而对于游戏开发而言，编写文档则是任何项目开战之前最重要的必要工作。
我的思考落地之后，我直接用ChatGPT的对话窗口帮我设计了一版开发文档出来，我的要求是：每做一版开发文档，就找出文档中不确定和设计上相互冲突的部分，列出来并向我提问。
在解决了模糊和设计冲突的问题，迭代了三版文档之后，我把完善过的文档，以及第一版游戏的bug代码都扔给了元宝的Workbuddy，让它继续进行开发。
游戏一共迭代了四版，第一版完善了物理规则的细节和手感，后面三版则是在不断测试AI的聪明程度、胜利目标和增加英语。现在你看到的，就是这个游戏迭代第四版之后的样子，也是我当前已经正式发布的版本：
（背景音乐是我本地播放器的音乐，ChiliChill的专辑，不是游戏自带的(´_ゝ`)此外，若无法观看视频请开启全局代理。）
在游戏完成之后，我也尝试并学习了了如何将其发布到Github上，中间也出现了因为代码中存在大量下划线而导致Jekyll渲染失败的问题，这自然是通过设置静态页面解决了这些小问题。
总体执行下来，我确实能意识到当今游戏从业者特别容易卡在“发布”这一环节的实际状况，因为我在发布的环节同样遇到了一连串问题。其次是游戏本身好不好玩并不是AI决定的，即便这款游戏在手感打磨上比较下功夫，但总体体验并没有真正的“打面包”有趣——当然，也有一些可能过去没有经历过那个年代的小伙伴，在第一次玩到这个游戏的时候会获得一点点乐趣。
以及，由于电子游戏是一个不确定性极强的行业，因此想用一份文档做所有事情反而才是不现实的。每一款游戏，目标不同、玩法不同、手感不同、数值不同，可能除了某些硬件共性之外，绝大多数情况下，游戏的开发文档都是需要从零开始编写的。
如果你对这个小项目感兴趣，不妨亲自上手尝试一下。