每个人都好吗？ TL;DR, 摘要和完整的技术分解在下面。 背景： 我最近在Day 1中发表了有关我一项副业项目ShuffleBall Arena的帖子（它是一款免费的浏览器游戏，将混淆分数与其他游戏如弹球、弹球和青蛙的疯狂性结合起来）。 这个项目正在使用AI（主要是GPT/指针/Fable）帮助开发。 我正在努力定期发布内容。 我想发表有关该项目的第1到14天的帖子，并希望能够添加一些价值。 为了加速追赶，我使用了一个结构化提示，回溯我的GPT会话并提取有用的信息。 希望这个提示可以帮助那些试图跟踪或从过去的AI项目会话中提取价值的人。 说到 Day 12 的更新。 今天有5个会话要处理（2个保存的文件版本）在3个小时内。 Day 12 的情况： =========================================================== # TL;DR Day 12 的重点是简化产品而不是扩展它。 * 重设计音乐系统，让它在开始屏幕上存活下来，而不是使用游戏内弹出窗口。 * 重用现有的下拉式UI以保持界面一致。 * 规划该功能作为结构化的实施而不是快速修复。 * 丢弃了对大型挑战模式平台的计划。 * 替换了几个月的潜在基础设施工作用一个小的v0.1实验来验证玩家是否真正想要挑战之前建造领先板、上传或账户。 今天的教训： 先建造最小的版本来回答最大的商业问题。 =========================================================== Day 12 摘要： 我从开始屏幕上选择音乐开始。看起来像一个简单的“添加音乐？”弹出窗口，变成一个更好的解决方案：将音乐选择移到开始屏幕上作为一个下拉菜单，匹配现有的板子选择器。 结果是一个干净的流程，没有中断游戏或延迟第一次射击。 更大的讨论围绕着挑战模式。 我最初 envision 了一整个平台，包括录制、上传、公共领先板、管理和社交集成。 在退后后，我意识到我还没有证明玩家是否想要参与挑战。 相反，我缩小了这个想法，仅仅是一个小的v0.1实验，专注于一个问题：如果有人看到一个挑战链接，会不会点击、玩和再试一次？ 这个决定大大减少了范围，同时为我提供了更快的路径来验证需求。 =========================================================== Day 12 完整的技术总结（结构化提示输出）： # 部分1：技术分析和回顾 # 开始点 Day 12 以 ShuffleBall Arena 已经可玩的公共状态开始，具有分析、广播模式、旋转板、声音和演变的UI。 焦点从核心游戏转向改进玩家第一次体验，同时改进产品决策。 两个更大的讨论也出现了： * 是否应该在比赛开始前配置音乐。 * 是否太早了就建造一个完整的挑战/领先板平台。 # 会话目标 最终会话围绕三个目标： 1. 改进游戏的首次体验通过重新设计音乐选择。 2. 决定挑战模式是否应该成为一个大的功能，还是从一个更小的实验开始。 3. 继续打磨周围的产品（网站、UI、营销策略和Webflow）。 # 我们实际上做了什么 # 1. 重新评估音乐体验 原本的想法是：开始比赛 → 询问“添加音乐？” 代替立即建造它，UX 首先被讨论。 结论： * 弹出窗口会中断玩家期望的游戏开始时刻。 * 它会复杂化第一次射击计时器。 * 它会添加一个决定在玩家已经承诺开始后。 决定： 将音乐选择移到开始屏幕上。 # 2. 重设计开始屏幕 相反使用弹出窗口，开始屏幕被重设计为： 板子 [ 混淆所有 ▼ ] 音乐 [ 关闭 ▼ ] 开始比赛 这样就将音乐选择移到正常的游戏设置流程中，而不是中断游戏。 # 3. 进一步优化音乐UI 更多的实现想法使用了两个按钮： 关闭 混淆 那被拒绝。 代替的决定是：重用现有的音乐系统。 最终行为： 关闭 混淆 天空找到了 Boogie Party 限制 70 几乎快乐的工作 ... 现有的音乐系统将被重用，而不是创建第二个实现。 # 4. 保留布局一致性 相反简单地插入另一个控件，空间成为设计工作的一部分。 一个特定的间距规则被引入，以保持视觉节奏一致： START_SCREEN_SELECTOR_TO_TEXT_GAP = 36 指导性文本被移到下方，以便新音乐选择占据空间而不会使屏幕感到拥挤。 # 5. 规划实施 相反产生一个巨大的代码包，功能被分解为一个结构化的实施计划，包括： * 开始屏幕状态 * 布局计算 * UI 命中测试 * 渲染 * 音乐选择助手 * 开始比赛集成 * 分析事件 * 测试清单 这样就把一个中等大小的UI功能变成可预测的编辑序列。 # 6. 讨论挑战模式 会话然后转向一个更大的想法：挑战URL，玩家可以直接从TikTok或YouTube打开。 初始的这个想法包括： * 录制 * 上传 * 云存储 * 公共领先板 * 管理 * 社交发布 相反立即建造，它本身就被挑战。 # 7. 改变产品策略 在早期TikTok和YouTube表现之后，结论是：这个想法看起来很有希望。 需求 尚未 被证明。 相反，项目应该回答一个问题：玩家是否会点击挑战链接并尝试再玩？ 这样就改变了路线图。 # 8. 定义挑战模式v0.1 相反整个平台，第一个版本变得故意小。 第一个实验将包括： * 一个挑战URL * 一个固定板子 * 单人对机器 * 分数 * 场地 * 胜利/失败结果 * 分析通道Explicitly 不 包括： * 录制 * 上传 * 公共领先板 * 账户 * 管理 * 社交API * 赛事挑战的目的从建造功能转向验证需求。 # 9. 网站打磨 会话也包括更小的产品打磨： * Webflow按钮悬停样式 * YouTube按钮颜色调整 * 未来挑战页面的UI mockup * 关于挑战模式页面布局的讨论 # 阻碍和摩擦 有几个时刻会出现阻碍。 # 音乐UI范围不断变化 该功能不断演进：弹出窗口 ↓ 按钮 ↓ 下拉菜单 ↓ 重用现有音乐菜单 每个版本都简化了前一个版本，但只有经过讨论。 # 准备建造太多 最大的风险是产品范围。 初始的挑战模式想法悄悄扩展成一个整个在线平台，直到有证据表明玩家想要它。 认识到这一点，避免了潜在的巨大偏离。 # 需求与激情 挑战想法足够激动人心，以至于它很诱人立即建造所有内容。 讨论重新定义成功指标，转向玩家行为而不是仅仅计算视频观看次数。 # 做出的决定和权衡 # 决定1 将音乐选择移到游戏开始前。 为什么 开始比赛应该感到立即。 权衡 一点更大的开始屏幕以换取更平滑的游戏体验。 # 决定2 重用现有的音乐基础设施。 为什么 避免维护两个独立的音乐系统。 权衡 现在要做更多的整合工作，以便以后更少的维护。 # 决定3 先建造挑战模式v0.1。 为什么 验证需求之前建造昂贵的基础设施。 权衡 一开始就没有上传或领先板，但风险大大降低。 # 决定4 测量参与度而不是观看次数。 重要的指标变成了： * 挑战开始 * 挑战完成 * 重试 * 评论 * 链接点击 * 分数分享而不是仅仅计算视频观看次数。 # 创新/教训 Day 12 的最大认识是： 在建造基础设施之前验证行为。 会话开始时，想法包括录制系统、云存储、管理工具和公共领先板。 结束时，它变成了一个更小的目标：玩家是否会点击一个挑战链接并尝试再玩？ 这个见解大大降低了风险，同时保留了核心产品实验。 # 值得分享的产物 # 产品原则 “不要建造完整的自动录制 + 上传 + 领先板系统。先建造一个更小的挑战URL测试。” # 范围定义 Challenge Mode v0.1故意排除了： * 录制 * 上传 * 公共领先板 * 账户 * 管理 * 自动社交发布，专注于验证玩家参与度。 # 最终状态 Day 12 的结束： * 音乐系统有一个清晰的UX方向，集中在开始屏幕上而不是中断游戏。 * 音乐选择器被重新设计为重用现有的下拉式架构。 * 开始屏幕布局被仔细规划而不是临时修复。 * 挑战模式被缩小为一个专注于验证需求的实验。 * 成功指标从虚荣指标（观看次数）转向有意义的玩家行为（开始、完成、重试和参与度）。 * 路线图变得更加严格，优先考虑证据而不是功能数量。 感谢阅读，下次见！