https://preview.redd.it/hk0xyun7exnh1.png?width=1918&format=png&auto=webp&s=51ec723b1432603c5805ebf6a5793a2fcf27fdba

大家好，我叫J，在codex的帮助下，我制作了一个等距RPG的垂直切片，这是我长期以来一直试图制作的游戏。我的开发经验非常有限，只有一些基本的逻辑理解，以及很久以前做过HTML/CSS/JS的工作。我想在这里发帖，询问大家对我开发过程和所写代码的反馈，并听听你们在尝试制作游戏时的一些经验。这是一个新的Reddit账号，以防你们太凶地欺负我，哈哈。

展望未来，我正试图创建我将用于充分完成游戏的系统。虽然这个游戏有意做得规模较小，但它应该足够通用，以便将来在续集或不同故事场景中使用这个引擎。

仓库：
https://github.com/jwaynegravesjr-ctrl/RPG-Feedback

提示框架说明：
我当前的提示框架设置围绕Token效率，使用Astra Medium（之前的Sol Medium）作为编排者，为Sol Medium、Terra High和Luna High定义任务。我还尝试通过鼓励系统在适当的地方构建共享数据工件、自动化和脚本来节省LLM的使用，这似乎已经取得了一些实质性的好处。此外，根据在这里读到的一些建议，我对开发仓库进行了索引，以减少搜索成本。

从我所看到的情况来看，出了问题的地方：

  1. 验证和确认测试：这些测试消耗了大量Token，我们还发现测试的设计虽然独立运行时有效，但一旦组合起来就会出现新问题。展望未来，测试将在流程后期而非开始阶段设计，并且会设计为测试系统内部交互。
  2. 开销成本：提示框架虽然非常有用，但在项目初期由于过度依赖LLM导致Token膨胀。我们尝试通过三个主要支柱来解决这个问题：脚本自动化（使用Python和Bash自动化文件夹/文件特定操作）、共享工件（将我们包含在提示中的许多上下文信息移动到.md文件中，仅在任务需要时读取）以及对仓库进行索引（很多Token消耗在浏览文件夹上）。
  3. 测试阶段需要我具备我不具备的技术知识：一开始我们设置了许多测试，这些测试要求我找到特定文件、运行特定代码或测试，并在之后查看非常奇怪的文件以获取信息。我们努力修改测试，加入小脚本或GUI以适应我作为普通人的天性，哈哈。展望未来，我会更具体地说明我们应为人机审查设计的测试类型。
  4. 权威所有权：存在一些问题，不同的代理会覆盖文件而事先不读取更改，或者一条信息从多个来源获取，而这些来源受到不同流程的影响。我们现在强调权威所有权和沟通指标。

从我所看到的情况来看，做得好的地方：
1. 它实际上是可玩的，并且包含了我在最终游戏中想要的一些机制。
2. 它基于Godot，依赖项很少且非开源，我计划根据你们/GPT/朋友们的反馈将最终代码开源（对此我还有点犹豫）。
3. 我学到了很多关于提示框架和反馈循环的知识，其中一些对我工作有帮助。
4. 我认为我学会了如何更好地发现、诊断问题并提供可操作的反馈，不仅在代码方面，在一般问题上也是如此。我的沟通能力提高了。

我还没有真正处理（但会处理）的问题：
1. 资源管道——目前只有一个基本的Imagen设置。
2. 内容管道——我想构建输入表单，以便我/我的朋友可以用来编写角色/对话树/位置。

我想下一步做什么（在反馈阶段之后）：
1. 制定计划，用于完成完整的游戏机制和内容。

当前Bug：
1. 保存/加载似乎不起作用，我相信这可以修复，只是我还没有修复。

这是一套我与GPT合作生成的指令，用于对抗我在其流程中观察到的“不良”行为：

结果与权威优先

定义目标、约束条件、权威来源和验收标准。在安全范围内，尊重用户意图和明确的仓库指令；通过正确性、兼容性、可维护性、最小化，然后效率来解决剩余权衡。

按比例检查

只读取任务所需的内容：相关指令、工作树更改、代码、测试、配置和已建立的命令。保留无关工作，识别预先存在的失败，并验证实质性假设。

重用合适的内容

在满足需求时，优先使用支持的仓库组件、平台功能和已建立的接口。仅当生命周期收益超过安全、许可、锁定和维护成本时，才添加或替换依赖项。

做出最小的完整更改

以最小的一致范围解决潜在需求，包括所需的测试、文档、迁移、兼容性和清理。避免推测性的抽象、重复实现、不必要的包装、无关的重构、占位符和额外内容。

自动化稳定的重复

将重复的、稳定的过程转化为少量的、可发现的确定性命令，这些命令组合现有工具并暴露失败。仅在歧义或判断显著增加价值时才在运行时使用LLM。

安全交付和证明

使用可用工具完成工作，并提供可运行的输出或权威操作链接。在采取破坏性、不可逆、外部、凭据性、财务影响重大或主要偏好依赖的操作前，寻求批准。说明推导出的假设，验证变更后的行为和实质性失败模式，区分已运行和未运行的检查，绝不捏造成功。

每个事实保持一个权威

更新需求、决策、状态和输出的权威所有者；避免重复状态。仅在仓库或部署需求合理时才提交生成的文件，并在可行时保持生成可重现。

完成即止

在验收标准通过、会话创建的临时工作清理完毕、剩余风险披露后停止。未经证明的需求，不扩大范围。

另外，Astra非常棒，基本上就是AGI。我很确定它比我聪明。