所有一切都好！
TL;DR 下面。
几天前，我发表了一篇关于我一个副业项目的第一天的帖子，名为 Day 1（ShuffleBall Arena 是一个免费的浏览器游戏，结合了shuffleboard得分与其他游戏的疯狂，如bumper pool、pinball和Frogger）。
这个项目是由AI（主要是GPT / Cursor / Fable）帮助完成的。
我正在尝试定期发布更新。因此，我想在这篇文章中发布从第一天到第14天的项目更新，并希望能够添加一些价值。
为了加快更新的速度，我正在使用一个 结构化提示来回顾我的GPT会话并提取有用的信息。希望这个提示可以帮助那些试图跟踪或从过去的AI项目会话中提取价值的人。
说到这里，关于ShuffleBall Arena的第9天的更新。
今天有5次会话（6个保存的文件版本）需要处理，持续了6小时。
这里是那天发生了什么：
TL;DR：版本1正式发布。
这个版本的构建重点是游戏玩法和可发现性：
- 添加了第一个Frogger样式的穿越板
- 建造移动交通道、撞击、虫洞和重力井
- 调整了新模式的设计
- 改进了广播布局混洗
- 开始教导机器人如何处理穿越板
- 重设计了OBS广播覆盖
- 首次在YouTube上直播
- 设置了Google Analytics、Cloudflare安全和启动基础设施
- 准备了Reddit、Facebook、TikTok和YouTube的内容
- 学习到发布游戏只是开始。让人们找到它才是下一个挑战。
更详细的总结和完整的技术总结如下：
===========================================================
第9天总结：
在将ShuffleBall Arena做好准备后，这个版本的构建重点是两个目标：使游戏更令人兴奋的观看和让人们更容易发现。
游戏玩法中最大的添加是新版的穿越板，受Frogger的启发。玩家不再仅仅是瞄准得分环，而是需要在移动的交通道中通过，交通道中有撞击、虫洞和重力井。建造这个模式需要多轮迭代，从匹配原始板设计到重新设计移动障碍物、调节车道可见度、增加射击时间、改进开始菜单和开始教导机器人如何处理新布局。
除了游戏外，我花费了同样多的时间来准备发布。设置了第一个YouTube直播、重设计了OBS广播覆盖、配置了分析、加强了Cloudflare安全、准备了Reddit和TikTok的营销、配置了电子邮件并开始学习如何让一个全新的游戏被发现。第一个流行了一个半小时，没有人观看，但它标志着ShuffleBall Arena正式成为一个活跃的产品，而不是一个局部项目。
===========================================================
第9天完整的技术总结（结构化提示输出）：
部分1：技术分析与回顾
开始点
第9天开始于第8天的发布准备工作后。游戏已经有可玩的版本1、音乐、广播模式、Webflow域名工作、YouTube设置和基本的发布计划。
这个项目从“能否建造游戏”转变为“能否让游戏更有趣、更值得观看和更容易被发现”。
第一个主要的想法是新版的 Frogger样式的穿越板，玩家需要通过移动的交通道，交通道中有撞击、虫洞和重力井。
会话目标
这个会话有三个连接的目标：
- 添加一个基于时间的板样式，让ShuffleBall Arena感觉不那么静止，更加技能依赖。
- 改进广播和发布呈现，使YouTube、OBS、Reddit、TikTok和直播观众能够快速理解游戏。
- 为项目做好公众发现准备，通过分析、安全、社交帖子、直播和反馈请求。
线索很明显：第8天使游戏发布准备好。第9天试图使它更值得观看和更容易被发现。
我们实际上做了什么
1. 设计了Frogger样式的穿越板
讨论的焦点是穿越板中的障碍物组数应该是1、2还是3，圆形撞击是否比椭圆形撞击更好。
最终的设计方向是：
- 交通道应该横跨整个板
撞击、虫洞和重力井应该移动通过那些交通道
障碍物组1和2应该常见
障碍物组3应该少见
椭圆形撞击看起来更像移动障碍物
得分环应该生活在板的另一侧
时间应该与瞄准一样重要
这是一个重大游戏玩法的变化。它保留了拖放射击，但添加了时间压力。
2. 导入了布局设计师JSON
第一个Frogger实现没有匹配设计师的意图。因此，布局设计师的JSON被导入到项目中并用作真实的来源。
这是一个正确的决定，因为问题不是概念性的。它是精确性的问题。设计已经存在，实现需要匹配它。
3. 迭代了穿越板的视觉语言
多次细化之后：
交通道撞击的颜色被改变成和游戏中的撞击颜色一致
虫洞变得更频繁
虫洞组2或3被要求
旧的顶部虫洞道被从Frogger布局中移除
车/半车撞击被改变成椭圆形
射击时间被改变为15秒
粉色车道指示线被保留，但变得更隐蔽
“机器人简单”被从启动区域信息卡中移除，因为它会溢出
这不仅仅是视觉细化。这些改变使新板更容易被读者理解为一个基于时间的板，而不是一个随机障碍板。
4. 重做了板选项的用户体验
启动屏幕板选项变得太拥挤了，因为普通板和穿越板现在生活在一起。
讨论转向将布局分组而不是将它们视为一个平整的列表。
这是第一个迹象，Frogger模式不应该是一个单独的模式按钮。它应该是一个板家族内的ShuffleBall系统。
板的命名也发生了变化。“Frogger”是有用的，但不是一个理想的公众名称。项目开始转向像穿越板/穿越道这样的品牌名称。
5. 调试了OBS侧边栏布局问题
一个大块的会话时间被花在调试OBS侧边栏问题上。
关键的发现是：
来源没有丢失
幻灯片/图片来源本身比预期大
*实际的卡片位于一个更大的灰色/空的来源矩形中
实际的解决方案是：
不要重建整个OBS场景
只裁剪或重建破碎的幻灯片来源
使用Alt-drag裁剪在OBS中
保留1080×1920画布设置
*有意地放置游戏/分发和侧边卡片
这是一个好例子，诊断了实际来源而不是重建整个场景的视觉问题。
6. 计划了Reddit横版资产
因为游戏是垂直/移动优先的，但Reddit更喜欢横版媒体，讨论探讨了是否应该显示两个游戏。
决定是：
不要显示两个全游戏
推荐格式是：
一个活跃的垂直游戏分发
一个旁边的强调板
*清晰的文本快速传达钩子
这是一个可发现性的决定。目标不是显示应用程序的精确形式。目标是让Reddit用户在两秒钟内理解游戏。
7. 改进了广播板混洗
观看广播后，太多的经典板在一起了。纯随机混洗虽然技术上工作，但感觉像是一个问题。
解决方案是：
限制混洗：
经典板和穿越板都可以参与
不要两个经典板在一起
不要两个穿越板在一起
穿越板在早期出现
不要硬性交替模式
*在类别内保留随机性
这是一个重要的产品教训：技术上随机并不是总是好的用户体验。
8. 调查了OBS与浏览器不匹配
OBS和Chrome显示不同的布局，即使使用相同的URL。
最初的假设是缓存不匹配，但在使用相同的缓存打破URL后，真正的解释是OBS和Chrome是两个独立的浏览器实例，运行两个独立的随机模拟。
提出的改进是添加一个可选的 seed URL参数来实现可预测的广播布局顺序。
这将同步OBS和Chrome中的板顺序，用于测试，而不试图同步整个物理。
9. 计划了轻量级机器人穿越板的意识
穿越板进入广播后，机器人需要看起来更有信心。
决定不是建立一个完整的物理预测系统。相反，机器人应该变得轻微地穿越板意识：
检测穿越板
估计一个射击是否穿越移动车道
评估明显的车道风险
避免最差的射击一部分时间
仍然会犯错误
保留正常板行为
这保持了机器人的可信度而不需要过度工程化的AI。
10. 发布并推广了游戏
会话包括多个发布/发现任务：
写了Facebook发布帖子
讨论了Zoho电子邮件/域名设置
工作了TikTok直播/OBS设置
创建了YouTube Shorts缩略图
草拟了一个r/playmygame帖子
创建了一个关于AI辅助开发的冷静Reddit回复
讨论了排除内部流量从GA4
开始了第一个YouTube直播
连接了OBS到YouTube
结束了第一个90分钟的流行，没有观众
计划了下一个YouTube/ Shorts策略
写了TikTok描述
这是一个情感上的转变：游戏不再仅仅是建造。它被放在人们面前。
11. 添加了实用Cloudflare安全
会话还包括安全审查。
由于游戏没有账户、没有付款和很少的玩家数据，因此主要的风险是：
机器人攻击API
表单垃圾邮件
未来的分析滥用
管理员账户被破坏
*开发/调试暴露
推荐的行动包括：
全SSL
最小TLS 1.2
始终使用HTTPS
基本Cloudflare机器人保护
一个广泛的/_api/_速率限制规则
将来在表单中使用Turnstile
*避免静态游戏中的阻力
指导原则变成：
保护API和管理员系统很硬。保持游戏阻力很轻。
阻碍和阻力
主要的阻碍点是：
第一个Frogger实现没有匹配设计师的意图
概念很强，但生成的版本没有与设计师导出的布局匹配。因此，使用实际的JSON而不是更多的口头描述进行了修正。
视觉一致性不断打破
Cursor将交通道撞击变成棕色。虫洞变得太稀疏了。旧的顶部虫洞道仍然存在。车道指示线太大了。每个问题都使新板看起来不属于ShuffleBall Arena的特征，直到修复。
OBS很混乱
侧边栏看起来是可见的，但不在预期的位置。实际问题是来源大小/裁剪，而不是画布尺寸或一个破碎的场景。
随机性看起来像是一个问题
广播混洗是随机的，但长时间的经典板连续使穿越板看起来缺失。这暴露了随机性和观众感知的差异。
YouTube发现是情感上的痛苦
第一个流行了1小时30分钟，没有观众。更大的痛苦不是只有零观众，而是没有印象。这迫使一个策略讨论，围绕着短片、Reddit、标题、缩略图和引入外部流量。
AI批评需要克制
一个Reddit回复关于AI辅助开发可以很容易地变成辩护。选择的方向是冷静透明，而不是因为人们对AI感到威胁而辩护。
做出的决定和权衡
穿越板成为板样式，而不是单独的模式
这保留了主要的游戏结构并避免了模式复杂性的增加。
权衡：不那么戏剧性的品牌名称，但更容易整合。
第一个穿越板优先考虑可读性而不是疯狂
障碍物组1和2是常见的，障碍物组3是少见的。
权衡：不那么极端的疯狂，更多的技能和时间。
穿越板的射击时间被增加到15秒
这减少了因为时间限制而感到沮丧的感觉，因为时间限制需要等待开口。
权衡：更少的压力，但更公平。
广播混洗变成了受控的混洗
纯随机性被纯粹的随机性所取代。
权衡：不那么纯粹的数学随机性，但更好的用户体验。
机器人AI保持轻量级
机器人将变得更加穿越板意识，而不是完美。
权衡：更快的实施、更少的风险，但仍然可信。
OBS布局被修复了
场景没有重建。只裁剪或重建了破碎的来源。
权衡：更快的修复、更少的干扰。
YouTube策略从24/7直播转变为包装内容
结论是，发现性内容比直播小时更重要。
权衡：更少的连续直播小时，但更多的包装内容机会。
公共安全保持了游戏的轻量级，但API的重量级
游戏保持了阻力很轻。
权衡：没有机器人墙在玩家面前，但后端端点得到保护。
突破/教训
最大的教训是：
发布后，工作的变化。
发布前，进展意味着添加功能。
发布后，进展意味着：
使游戏更容易理解
使广播更值得观看
使内容更点击
使分析更可信
使API更安全
使第一次玩家反馈循环成为可能
最强大的技术教训是，观众体验经常需要受控的系统，而不是纯粹的系统。
纯粹的随机板选择是“正确”的，但它使广播看起来像是一个问题。受控的混洗是更好的，因为它尊严地对待观众感知的随机性。
值得分享的艺术品
艺术品1：广播混洗规则
保持广播混洗是随机的，但确保穿越板/蛙人样式的板在健康的频率出现。不要简单地交替每轮普通板和穿越板。它应该仍然感觉是混洗的，但防止长时间的普通板连续。
艺术品2：机器人穿越板意识设计原则
使机器人在穿越板上看起来更可信，而不需要建立一个完整的物理预测系统。
艺术品3：安全原则
保护API和表单很硬，保护静态游戏文件很轻，保护管理员账户很硬。
最终状态
第9天结束时：
第一个穿越板的设计和迭代已经完成
新板样式有更清晰的视觉、更隐蔽的车道、更合适的障碍物和更长的射击时间
板选项的用户体验正在向分组板样式转变
广播混洗被重新设计以更一致地显示穿越板
可选的播种广播布局顺序被计划用于测试
机器人穿越板意识被计划
OBS布局问题被诊断
Reddit/TikTok/Facebook/YouTube发布内容被草拟
第一个YouTube直播发生了
项目有一个更清晰的生长策略在第一个零观众的流行之后
*Cloudflare安全基础设施被部分配置
如果你仍然在这里，感谢阅读，下次见！
评论 (0)