我主要是Rails后端开发者,但过去几个星期,我一直在开发一个叫做Turtle Escape的肖像型移动游戏作为一个个人项目。它最初是简单的原型:三条车道,一个海龟,几种危险。它逐渐演变成一个使用Expo、TypeScript和Skia构建的React Native游戏,具有七个地区、确定性的故事水平、进展、集合和一个离线优先的Rails后端。 我在开发过程中使用了AI编码代理,并在部分精灵生产流程中使用了Gemini。游戏本身没有运行任何生成式AI。 我早期的一个最大错误是把提示当作规范。虽然这会产生快速的代码,但“代码工作”还不够。一个变化可能在本地是正确的,但仍然会破坏确定性级别生成、将持久性放在错误的层上、引入未翻译的UI、暴露开发工具或创建只有在实际设备上才能出现的性能问题。 最终的解决方案是把仓库本身当作AI的操作系统。一个共享的指令文件定义了架构、当前优先级、所有权边界、安全规则、确定性要求以及必须永远不发送的所有内容。更大的任务有自己的指南,当前工作与未来想法分开,以便代理不能混淆“有趣”和“批准”。 我也会对每个AI生成的更改视为未信任,直到它产生证据。根据更改的类型,这可能意味着类型检查、linting、确定性模拟测试、服务和持久性测试、本地化检查、浏览器流程测试、截图审查或物理设备上的-profile。艺术管道遵循相同的原则。AI生成候选者,甚至是完成的资产。但是,每个精灵仍然需要手动检查、动画验证、集成和在运行中的游戏中进行审查。 AI在哪里最有价值: * 探索代码库中的未知部分。 * 在现有的架构中实施专注的更改。 * 生成bug理解后回归测试。 * 在多个层次上跟踪问题。 * 比较确定性平衡结果。 我对它信任最少的是: * 产品和游戏玩法决策。 * 范围控制。 * 从代码中仅仅通过难度平衡。 * 可视一致性。 * 本机平台生命周期假设。 * 决定是否应该存在另一个功能。 附带的剪辑显示当前的构建在iPhone上运行。 我还打开了一个外部的TestFlight测试版,让任何人都可以在完成的游戏中进行评估,而不是仅仅评估开发过程。并且创建了一个Discord频道来分享我的开发日志和经验: Discord: https://discord.gg/5wqqhZd8W8 Testflight: https://testflight.apple.com/join/Z3GH3M77 对使用AI的开发者来说,什么是您的接受层?您主要依赖于自动化测试、固定种子、视觉比较、手动审查还是其他什么?
Turtle Escape是一款以AI为基础的三条车道生存跑酷游戏,玩家需要带领一只小海龟从巢穴到海洋,游戏制作时间不到两周。
评论 (0)