我之前发了一篇帖子（帖子链接)，关于我写的提示序列以及原型的目的：验证一个游戏是否好，哪里可以改进，还是应该被丢弃。现在，我想展示一个真正好的游戏是什么样子的，我们将在AI游戏节上探讨更多的话题。

Regolith的开发者最近发布了他们的开源游戏，用Opus 5制作的。给他们点赞，他们的游戏做得非常好！图形看起来很棒，任务中的目标工作正常，入门指南清晰。他们做了一个非常好的工作把它放在一起。

所以，我 fork了它，添加了分析工具，放到了 Glitch 上，并对它进行了市场营销。然后，我在1-2 天内获得了以下游戏玩法结果。

https://preview.redd.it/7upwxu6cxdjh1.jpg?width=2133&format=pjpg&auto=webp&s=2580dda11517075e526d36413ee3db289537e829

https://preview.redd.it/ujdrou6cxdjh1.jpg?width=2273&format=pjpg&auto=webp&s=f030cc81b9af419450edcd675a9e704b562cf6b4

我们有大多数用户在玩游戏的时间长达15分钟，为了参考，Glitch上有一个15分钟的时间限制，如果用户注册，就可以继续玩游戏。这个意味着人们在计时器过期前都在玩游戏。

以下是玩游戏时间的含义：

  • 0–1 分钟： 如果这个是你的最大柱子，你的游戏有加载和启动问题需要解决。
  • 2–5 分钟： 如果这个是你的最大柱子，你需要改善你的游戏的入门指南和初始游戏。
  • 5–15 分钟： 人们开始真正地融入你的核心循环，并给你的游戏一个公平的机会。

这个游戏值得投资！开发者已经制作了人们喜欢玩的游戏，并且正在积极地与玩家互动，直到计时器过期。你的游戏如果开始像这样，看起来，你应该停止原型并计划如何正确地加倍。

现在，要真正地推进这个游戏，它需要从工程角度完全被丢弃并重建，或者花费大量的令牌来正确地扩展游戏。原始源代码中没有测试和后端；所有的东西都在浏览器中运行。如果我真的想深入了解工程方面的缺陷：

  • 没有自动测试或质量门槛。
  • 状态被分散在可变全局中。
  • 渲染和游戏逻辑紧密耦合。
  • 测试/调试循环不是确定性的。
  • 隐藏的工具仍然消耗CPU。
  • 适应性管家只考虑了帧缓冲区成本。
  • 有累积的死状态。
  • 没有国际化架构。
  • 没有真正的后端来扩展游戏。游戏数据应该存储在后端，前端不应该是真实的来源。
  • 有不完整的音频生命周期。
  • 包管理是混乱的，我们有东西在vendor文件夹中应该由包管理器管理。
  • 没有文档（变更日志，故障排除指南，测试策略，保存架构文档，兼容性政策，迁移程序等）。
  • 其他缺陷等等。

我认为最大的缺陷是文档和测试，测试对于好的手续或如果他们想要继续开发游戏非常重要。

  • 好的文档会让其他开发者/艺术家或未来AI理解不仅仅是什么被实现的，而且为什么。理解为什么会帮助防止后来坏的假设被做成项目增长。

  • 测试会防止功能工作的东西被破坏，降低新问题被引入的机会。

当我写了提示序列时，它是关于创建原型并在投资大量资源之前验证它，但同时建立一个好的代码库，如果一个游戏显示出有利的可行性，它可以被传递给其他开发者/艺术家来打磨或重写，或者开发者可以继续使用AI。目标是使未来的开发成本更便宜。

如果你不能原型你的游戏，并且你的数据图表看起来像上面这些，你不应该试图优化代码；你没有一个代码问题，你有一个营销和/或游戏玩法问题。

我无法告诉你Steam上的非AI游戏的数量，其玩游戏时间图表看起来像这样，表明人们没有参与游戏，应该在验证阶段进行测试。

https://preview.redd.it/so9v8y8vwdjh1.jpg?width=695&format=pjpg&auto=webp&s=32bc796f2a5744d6c91d018aade713216cdb27fc

但是再次感谢开发者。他们的AI，游戏和工作都与玩家产生了共鸣，这就是制作一个好的游戏的全部。无论它是如何制作的。