每个人好！ TL;DR, 摘要或完整的技术详解见下文。 我还附上了一个连接到建造系列的链接，供有兴趣的朋友们查看。 对于新来的朋友们，这是建造系列的一部分，记录了ShuffleBall Arena的开发过程，这是一个免费的浏览器游戏，灵感来自于混洗shuffleboard计分和其他游戏的机制，如bumper池、弹球和Frogger。这个项目正在使用AI工具（主要是GPT、Cursor和Fable）进行开发，每个开发会话都使用当天工作的实际对话进行记录。 这个帖子标记了第14天，也是项目的第一个章节的结尾。 在进入今天的更新之前，我只是想说 感谢每个人 已经跟随了这14个帖子。无论是通过评论、DM、问题、反馈还是仅仅花时间阅读它们， 我真的感谢。 这些帖子教会了我一个东西：我虽然喜欢记录建造过程，但我也想有一个地方，讨论可以集中在项目本身。不是花时间争论AI是否应该在第一时间使用，而是关注实际的工程决策、产品权衡、错误和其他所学。因此，大部分我的建造在公共更新将在这里记录。 如果你已经喜欢上这个项目，希望你能继续跟随下一个章节。（如果你已经在跟随的话，很好！） 今天的建造包括 4个对话（4个保存的文件版本），跨越了 5小时 的开发时间。 以下是第14天的过程。 =========================================================== # TL;DR 我想挑战模式基本上是完成的。然后我实际上开始玩它。马上就暴露了一个布局错误，只有在开始挑战时才会出现，导致更深入的修复，其中游戏现在在UI变化时重新计算画布，而不是仅仅在浏览器重绘时。 一旦解决了这个问题，测试就揭示了另一个问题：竞技场机器人实际上是工作的，但它仍然不 感觉 聪明，因为它继续等待安全开口，然后在移动障碍物中射击。 =========================================================== 第14天的总结： 来到今天，我想挑战模式基本上是完成的。UI已经被打磨，引言和结果屏幕已经完成，似乎一切都准备好了。然后我开始玩它。几乎马上就发现了一个错误，游戏画布在开始挑战后没有正确缩放。结果并不是一个CSS问题。布局只有在浏览器重绘时才会重新计算，所以我重构了流程，确保画布在挑战模式状态之间的UI变化时重新计算。 一旦解决了这个问题，我就花了更多时间实际上玩游戏，而不是看代码。就是在那时我注意到了一些东西：竞技场机器人仍然不让人觉得 “这很聪明。”它仍然等待多个安全机会，然后最终射入移动交通中，即使在之前的工作中。技术上它是有效的，但体验仍然不令人信服。这让我将注意力从添加更多功能转移到改进现有的质量。 今天的收获： 有时最有价值的工作就是像真正的用户一样玩你的产品，直到问题暴露出来。 =========================================================== 第14天的完整技术总结（结构化提示输出）： # 部分1：技术分析与总结 # 开始点 在这个会话开始时，挑战模式已经从原型转变为一个成熟的功能。新引言屏幕、结果屏幕、局部最高分和重播专注的UX从第13.2天。期望是这个功能基本上是完成的。接下来的步骤就是进行真正的游戏测试，而不是添加主要功能。 # 会话目标 目标从建造挑战模式转变为确保它在真正的游戏中行为正确。主要目标是： * 修复在开始挑战后出现的画布/布局错误。 * 确保底部过渡正确缩放游戏画布。 * 验证挑战模式流程在从引言到游戏之间的整个流程中是否平滑。 * 评估竞技场机器人在移动障碍物中实际上是什么样的，并找出改善玩家体验的机会。 * 思考如何使游戏更具观赏性和分享性。 # 我们实际上做了什么 # 1. 跟踪一个布局错误，只有在游戏中才会出现挑战模式 UI看起来正确，直到开始挑战。游戏开始后，画布保持了原始大小，因为布局只在浏览器重绘时重新计算。不是调整CSS，修复就变成了确保画布在footer可见性变化时重新计算。 # 2. 重构footer处理来触发画布缩放 在依赖浏览器重绘事件时，scheduleFitCanvas()被添加到footer过渡流程中。这包括： * 广播模式 * 嵌入模式 * 挑战引言 * 挑战游戏底部 * 正常游戏底部 这样做确保了每个UI转换都强制执行一个新布局计算。 # 3. 修复挑战状态过渡 在重要的挑战模式转换之后添加了额外的布局刷新，包括： * 开始一场比赛后 * 直接从挑战引言开始 * 重启当前挑战 每个转换现在都明确重新计算画布，而不是等待浏览器重绘事件。 # 4. 测试完成的挑战模式作为一个真正的玩家 在UI问题解决后，重点从视觉打磨转向游戏玩法。玩多个回合揭示了一个问题：竞技场机器人经常等待多个安全机会，然后最终射入移动交通中。技术上机器人是有效的，但体验仍然不令人信服。这成为下一个主要游戏问题的解决方案。 # 5. 思考未来内容策略 相反于立即添加更多游戏机制，讨论转向玩家参与度。提出的想法包括： * 给竞技场机器人一个性格 * 添加幽默的废话 * 测试概念通过编辑视频，然后再编写游戏代码 * 验证观众兴趣之前投资开发时间 结论是娱乐价值可以成为增长观众的同样重要的因素。 # 阻碍和摩擦 * 画布错误最初看起来像是一个CSS问题，但实际上是一个生命周期问题。 * 布局计算与浏览器重绘事件相关，而不是UI状态变化。 * 挑战模式看起来 “完成” 直到真正的游戏揭示了静态测试无法暴露的问题。 *竞技场机器人按照其逻辑行为，但不是按照玩家期望，突出了功能AI和可信赖AI之间的差异。 # 做出的决策和权衡 # 决策1 代替引入CSS工作-around，布局系统被更新，以确保画布在挑战模式转换时重新计算。权衡：布局调用稍微增加，但预测性渲染更好。 # 决策2 相反于立即实现竞技场机器人声线，想法是首先通过编辑视频验证观众兴趣。权衡：优先学习什么与玩家共鸣之前投资开发时间。 # 决策3 焦点从添加更多游戏机制转向改进现有的游戏体验。 # 创新/教训 最大的认识来自这个会话： - 一个功能不仅仅是代码有效。 - 它完成了，当你像真正的玩家一样玩它时，没有发现新问题。 挑战模式看起来完成了。实际上玩它揭示了布局行为、UI过渡和AI决策问题，这些问题在实施时是不可见的。 # 值得分享的艺术 # 设计规则 “画布应该在UI变化时重新计算，而不是仅仅在浏览器重绘时。” # 实现模式 applyFooterControls(); scheduleFitCanvas(); 在挑战模式转换后添加一个明确的布局刷新解决了缩放/布局错误。 # 产品洞察力 “我正在建立这个世界上最烦人的电动车机器人。我想知道它下一次会说什么。” 这成为探索以性格为导向的内容而不是仅仅展示游戏的基础。 # 最终状态 在会话结束时： * 挑战模式在进入游戏时正确缩放。 * 底部状态变化始终触发画布重新计算。 * 挑战模式转换变得更加可靠。 * 一个新游戏问题被识别：竞技场机器人需要感觉更聪明，而不是仅仅行为正确。 * 未来营销方向出现了，重点是使机器人足够有趣以驱动参与，而不是仅仅依靠游戏片段。 =========================================================== # 第1章所有帖子的链接：对于有兴趣的朋友们，你可以在这里找到第1到13天的所有帖子。 =========================================================== 一如既往，感谢阅读！