#5 一个大学生，只靠AI代码，同人游戏能做到什么程度 开发日记

大家好啊，这里是一个想做游戏但是由于没什么做游戏的经历导致没有公司愿意要我去实习只能一个人蹲在寝室里做游戏的苦逼大学生，目前距离上一次更新已经过了差不多一个月了，虽然在开发日记上鸽了点，但是系统我还是在认真写的，今天就和大家伙说说这一个月以来的开发进度。

  现在已经开发了三个月左右了（没想到居然这么长时间没做整理），其实我一直在尝试很多新的东西，比如换用Poe平台来写代码，因为目前的Claude封号比较严重，几乎是开一个号就封一个号，导致原先的账号几乎用不了了，所以我也一直在寻找Claude的替代品，包括测试了Gemini 2.5以及Poe平台等，重新置办了一条可以规避Claude的工作流。

  除此之外，由于这一个月以来的开发内容非常庞杂，而且中途有很多卡顿的地方，导致我有时候红温得厉害，加上做的系统也越来越大，所以写开发日志就没那么简单了，还是蛮费时间的。（我记得我上次说要做地图设计了来着，但是看起来还得再推迟一段时间2333）

  

   目前的开发进度以及项目进展中遇到的困难：

   

    1.背包系统究极Plus+很多杂项的问题修复

     （1）背包系统超突破

    在上一次日志当中，我们已经完成了角色背包的基本所有功能，但当时的效果显然不是我想要的，实在是有点丑得难以直视

第六周的比较残念的背包系统，像是用水泥做的

所以在背包系统完成之后，我们的首要任务其实是尽量让目前的UI变得更好看一些，至少需要让AI帮助我们写一个UI框架，用于接管现有的背包绘制窗口，这样就算AI没办法自己做出好看的UI，我们也可以亲自用手绘的方式去绘制UI。

  不过由于RPGMAKER并不是一个在UI上有很强的可视化编程功能的引擎，所以如果到时候真的要一点一点画+对其UI，其实会非常麻烦，所以我打算直接让AI帮我生成一版更加强大的UI看看效果。

当时的背包系统插件集合

  我有信心让AI直接帮助我们生成UI的关键在于我们曾经做好的系统结构，由于我们采用了分模块分功能的方式来编写插件，所以实际上最主要的功能区块和窗口绘制区块实际上都是由单一的核心插件来管理的，所以让AI读取窗口绘制方式时，我们只需要把核心的插件交给它们就可以了，比如上面提供的这么多插件，实际上需要AI了解的主要功能系统就只有R4B_Core以及R4B_CharCard_Window这两个插件，这给后续修改AI的UI美化插件提供了很多便利。

目前的背包UI效果，和原本的UI图差距还是挺大的

  从结果来看，AI生成的效果其实还是非常不错的，当然这绝对不是第一次就可以生成这样的效果，其实中间起码让AI重新写了五六遍才达到这个效果的一半样子，但是我当时没有把失败案例记录下来，所以就只给你们一张最后已经完工的效果图作为演示，不过就根据这个的测试结果，我可以说对于各个AI有了更深的体会：

  1.Claude最擅长写UI和美化，但是很容易出错。实际上，几乎所有能看的UI效果都是有Claude3.7本体给出的，其他AI给出的效果简直惨不忍睹，尤其是Cursor，虽然其有Claude Max的加持，但是实际结果看下来Cursor的Claude好像就完全不懂该怎么做UI一样，做出来的效果很单薄。Cursor反而在修复Claude给出的UI插件的问题上发挥的还可以，因此我后续采用的方针都是先让Claude出一个比较精致的UI插件，然后让Cursor去修复错误。如果后续结果不太满意，那么让Claude重新再写一个即可。

2.让AI写UI美化插件一定要注意优化和调整问题，Claude虽然写得一手好UI，但是它的问题在于很多时候控制不住自己的手，老是喜欢在后面加一些有的没的，我理解不这么干就写不出复杂的UI，但是有时候它的效果会一言难尽，比如导致游戏根本进不去，背包非常卡顿或者某个光晕效果大得吓人，所以很多时候需要你不停地人为干预。

   我的体会就是开头一定要把要求写得详细一些，包括要预渲染和缓存贴图，同时在主题上只需要给AI一个比较宽泛的主题，比如赛博朋克之类的，AI就可以发挥了，如果实在不行可以让ChatGPT帮我们生成一个UI效果图，然后让Claude去参考，总之就是尽量不要把AI的行为框的太细，给AI一些自由创作的空间，它才能写得更好。

ChatGPT的UI预览图

  不仅如此，AI写完美化插件之后，还需要检查一下UI的效果好不好，因为Claude也经常会产出一些废掉的插件，有些时候这些大型美化插件会有3000到4000行代码之多，出错的概率是很高的，我一般会选择让Cursor修复两到三遍，如果即便是这样还出错，那就直接让Claude重写算了，如果最后发现UI效果不太满意，建议也直接让Claude重写，因为让Claude改一个大型UI插件的细节是比较困难的，不好把控。

3.让AI多提供一些自定义参数。这个其实是非常关键的一步，AI其实完全不知道你的UI是怎么拜访的，它很有可能会把放在顶上的UI挪到最下面，这个时侯如果你想要通过口述指导AI去改正这个问题，真的又麻烦又费力，不如直接让它把这个UI的位置变为自定义参数，这样你就可以直接自己去调整UI位置，这个不仅仅是位置之类的，包括颜色、大小，最好都要让AI写的时候先提前设计好，这样就算AI脑袋抽了把UI放歪了，你还能自己去修复。

非常详细的自定义参数设置

当然这个UI效果差不多花了我整整三天时间才调教出来，包括让AI修改，增加自定义颜色之类的，中间真的遇到不少问题，不过好的地方在于我们在通过Claude生成出一版真正还不错的UI之后，后续去美化角色卡片以及分页栏的位置就比较方便了，因为最主要的UI的绘制方式已经定了下来，所以后续编写其他细节的UI没有遇到太多的问题。

    

  

分页栏

角色卡片框

    （2）一些杂项问题的修复

     在制作背包的时候，我们还遇到了不少小问题，比如角色卡片的心电图效果会不停地叠加且不会清理，结果导致游戏只要运行十几分钟就一定会自动崩溃等问题，加上插件模块相互依赖，改起来很麻烦，必须一个一个谨慎地修复，花了我非常多的时间，这一个月几乎有半个月都在修BUG，但这个过程并没有特别多的技巧，就是把问题提供给AI，然后让AI去帮助你修复这些问题。

     在这个方面，Cursor（Claude模式）和Gemini我都觉得挺不错的,Cursor最好的地方在于不需要你自己去编辑代码，由于我后来发现Cursor每个月的Claude3.7慢速调用居然是不限次数的，所以用它来修复插件也比较频繁，但它的缺点在于很意识流，不一定真能找出引发问题的代码部分，所以很多时候它都比较喜欢写一些预防和检测的方针来防止问题发生，这不是一个很好的解决方案，毕竟问题代码仍然摆在那里。

    Gemini的好处在于它比较理性，逻辑很强，梳理代码结构比Claude要清晰，Claude很可能就看一眼，反正它的深度思考逻辑链里从来不会真的把代码都看一遍，但是Gemini的思考链里是真的把代码都过了一遍才输出的，这让我感到很意外，所以如果遇到Cursor写个半天都解决不好的问题，最好自己上+Gemini辅助，一点一点找到问题的关键点会更快一些。

2.战斗系统大增强

  由于通过不断地调教AI，我们终于获得了一个还算不错的角色背包系统，此时我觉得是时候去完善下一个游戏的核心部分了，就是游戏的战斗环节，由于我们之前一直在制作角色背包系统，所以从实质上来讲，我们目前的战斗系统还是一个非常普通的RPGMAKER回合制战斗，虽然我们使用了VisuStella的战斗核心插件，但这些插件基本上都是对于原有系统的补强，并没有起到真正的异化，所以战斗看起来蛮平庸的。

  基于我们制作的游戏的参考对象——《恐惧与饥饿系列》来看，我们仍然会采用RPGMAKER原始的回合制战斗方法来设计战斗，但是在这个基础上对于原版的系统做一些革新和增强。

 

《恐惧与饥饿》的战斗效果

  我最后选择改进的效果有三个部分：

  1.战斗临场感——加强战斗摄像头的效果，包括打击感、镜头感。给RPGMAKER的场景效果增加摄像头的感觉，让地图场景和怪物看起来更加立体，给玩家带来更强的压力

 2.精简UI，我在原先的测试过程中，一直觉得系统默认的UI效果很挡视野，在恐怖生存游戏当中，过多的UI会削弱玩家对怪物的感知，所以我希望隐藏原先的UI，制作一个和背包系统一样精简的UI效果，让整个场景看起来不会太臃肿。

3.战斗策略性，除了画面、UI上要进行革新之外，最重要的玩法部分也需要强化，我在这里参考了暗黑地牢的压力值系统以及最近新出的33号特遣队的UI效果，新构思出了一个以角色本能为基础的战斗系统（在这里不会细讲）

  确定完我们需要更新的部分，接下来其实就是一步步写代码了，但是首先我比较喜欢先把这些要求交给ChatGPT进行整理，因为这三个部分要分为增强战斗系统的三大功能模块，所以最好提前整理清楚需求，再交给Claude写

ChatGPT按照我的要求构思出的UI草稿

  当我们把需求都整理好了之后，是时候把需求交给Claude了，还是和编写背包系统时一样，由于Claude在代码编写上是老大哥，所以先让它负责一个系统的核心模块的编写，然后再让Cursor去对局部进行修改和增强。

目前的战斗增强插件系统

目前的UI（小人还是系统默认的样子）

  这块部分是上两周的成果，同样在这个过程中我们经历了多次的修改重构，其中我遇到最复杂的问题就是怪物贴图闪烁的BUG。

  这个BUG会导致怪物死亡之后，其原本的贴图还会在原地不停地闪现，本来这一点我们是直接通过检测+实时清除去解决的，但是这样会导致一个非常麻烦的问题——怪物死亡动画消失了，由于怪物死亡之后就会被立刻清除，这导致怪物死亡的动画完全不见了，结果就是看起来非常僵硬，怪物被击杀后像是直接消失了一样，虽然让Cursor去重新写一个死亡动画效果，但是问题在于我们的游戏有连锁死亡机制等非常复杂的死亡效果，

  这些效果如果交由RMMZ原系统去实现并不难，但是如果要通过自制的死亡动画去实现，那简直难到家了。那两周我因为这个问题红温了好几次。如何要在革新了原有的战斗系统的情况下保留敌人死亡的效果呢？我也不清楚，只能一步一步根据自己的猜测去测试。

  这时候问题又来了，由于我们的编写方式是分模块一步一步写的，最后就像垒砖块一样，一步一步垒高，而我们发现这个问题的时候，整个系统已经完成一大半了，而最主要的核心系统嵌套了好几层，没有办法，想要从根源解决问题，我们就必须先回到核心系统，把后续的所有功能先取消了，然后一步一步进行测试，看看问题在什么地方。好在我们的模块比较清晰，虽然中途Cursor一直在犯毛病，但是我们最后还是成功把问题发生的地方都修复干净了，这种感觉就像是我以前玩老滚5的时候装MOD出问题了然后不得不一个一个去排查一样。所以系统最好不要留到最后再修改。

最后的实机演示部分+后续的计划和自言自语：

     对于演示感兴趣的可以看看我B站的视频。

第八周进度演示：

第九周（目前）进度演示：

后续的计划：

    目前经过三个月的铺垫，我们的游戏核心部分算是真正地大功告成了，虽然比预计的要晚了一个月左右，但是我们已经尽力把目前的游戏系统做到完善了，基底打得比较扎实。后续进行内容制作也会更加放心，我接下来就会开始关卡制作以及怪物制作，就是后续美术部分会相当花功夫。可能会画断手咯。

最后我要留一些自言自语的环节，只能说世事变化得太快，赶上经济下行的时代，我其实原本对于游戏制作没有很多的实感，但是这次手操三个月给我带来了很多思考，当然，其实我还是很害怕的，因为我制作的是恐怖游戏+生存游戏，这样的游戏品类很小众，加上现在大环境不好，我这样做多半就是在自讨苦吃，不如早点去游戏二三线厂打工谋求生计。最近小高老师的负债问题也让我很受震撼，我以前一直是弹丸论破的粉丝，觉得像小高和刚这样日本比较知名的制作人，游戏至少能有出路，有人玩，没想到连他老人家现在都要亲自拉下脸来到处进行古法宣传了，非常感慨，很多时候我会反思自己到底在做些什么，为了什么要做游戏，但是我真的不敢给自己答案，因为害怕自己不配得到那个答案，我本身也不是什么天才，记性也不大好，未来也不一定真的会在游戏行业留下自己的名字，那么我做这些事的意义在哪里呢？好吧，咱不胡思乱想了，我希望我的作品最后能有个结果，不论好坏，也算是我大学对游戏理解的总结吧。