每个人都好吗？ TL;DR, 摘要和全面的技术分解在下面。 背景： 最近我发了一篇关于Day 1 的一项副业项目ShuffleBall Arena（它是一个免费的浏览器游戏，结合了打字机得分和像bumper pool, pinball 和Frogger这样的其他游戏的疯狂性）。这个项目是使用AI（主要是GPT / Cursor / Fable）帮助建立的。我试图找到时间来发表相当一致的内容。 我想发表关于这项项目的第1到14天，并希望尝试添加一些价值。 为了试图加快追赶，我正在使用一个结构化提示来回溯我的GPT会话并提取有用的信息。 希望这个提示可以帮助那些试图跟踪或从过去的AI项目会话中提取价值的人。 说到 Day 13 的更新。 Day 13将分为两篇。 今天有7个会话要处理（4个保存的文件版本）超过5个小时的建造。 这里是Day 13.1的第一部分： =========================================================== # TL;DR Day 13.1专注于 玩家身份没有玩家帐户。 不要建立： * 用户帐户 * 认证 * 云配置文件 * 在线身份管理 我建立了： * 一个可选的本地玩家配置文件 * 浏览器存储 * 个人化的挑战模式标签 * 隐私友好的分析 * 可重用的系统可以扩展到主游戏后 =========================================================== Day 13.1摘要： 第13天的第一部分是使游戏更具个人化感而不使其更复杂。挑战模式已经工作了，但每个玩家都只是“你”。我的第一直觉是思考账户、在线配置文件和排行榜。 但随着我探索这个路径，我越来越意识到我实际上是在试图解决一个我根本没有的问题。 相反，我建立了一个轻量级的本地玩家配置文件，它完全存储在浏览器中。 玩家可以选择一个名字，看到它在挑战模式中反映出来，并感受到他们的分数属于他们而不必创建账户或共享任何个人信息。 配置文件永远不会离开设备，分析只记录匿名状态而不是玩家名字。 这也为整个游戏奠定了基础。 同样的本地配置文件可以在普通比赛、未来统计和其他功能中重复使用，而不必引入不必要的基础设施。 本次建造的最大收获是玩家不一定需要云账户才能感到投入。 有时仅仅看到自己的名字在体验中就足够了。 =========================================================== Day 13.1全面的技术摘要（结构化提示输出）： # 部分1：技术分析与回顾 # 开始点 在本次会话开始时，挑战模式已经存在并且正常工作。 玩家可以启动挑战、完成它并收到结果。 但是，体验仍然感到匿名。 每个玩家的体验都被称为“You”，这使得挑战感觉像是一种可抛弃的体验而不是一种个人化的体验。 显而易见的解决方案将是添加用户账户和云配置文件，但这将大大增加复杂性，并且对于仍在早期阶段的浏览器游戏来说，这是一个不必要的负担。 目标变成找到一个更轻的解决方案。 # 会话目标 给玩家一种身份感而不引入认证、账户、数据库、密码或后端配置文件管理。 解决方案还需要： * 完全可选 * 完全在localStorage中工作 * 保护玩家隐私 * 在标准游戏中可重用 * 避免在游戏的第一版中创建技术债务 # 我们实际上做了什么 # 1.定义实际的产品问题 不要问： “我们如何建立账户？” 我们重新定义了问题为： “如何让玩家感觉这项挑战属于他们？” 这改变了整个功能的方向。 # 2.拒绝一个完整的账户系统 我们讨论了建立： * 云账户 * 用户名 * 认证 * 排行榜 * 在线配置文件 你故意 不 建立任何东西，因为复杂性在当前项目阶段并不是必要的。 # 3.设计一个轻量级的本地玩家配置文件 不要账户，我们设计了一个小的本地配置文件，仅在玩家浏览器中存储。 配置文件存储： * 玩家手柄 * 创建/更新时间戳 * 只在本地存储的数据 没有后端。 没有登录。 没有个人信息。 # 4.计划如何在挑战模式中显示身份 相反，不要显示通用的标签，如： “你的分数” ，界面可以显示个人化的版本而不改变游戏本身的工作方式。这使得挑战感觉更加个人化，而保持实现极为简单。 # 5.设计可重用的玩家名称模态 不要让挑战模式特殊，我们计划命名系统，使其可以在正常游戏中重复使用。 同样的本地配置文件可以在将来： * 普通比赛 * 挑战模式 * 未来统计 * 未来玩家卡片而无需重写功能。 # 6.保护玩家隐私 设计决策之一是确保分析从不收集玩家名字。 分析可以安全地记录玩家是否创建了本地手柄，但从不传输实际手柄本身。 身份永远不会离开浏览器。 # 7.为未来的架构做准备 配置文件系统故意设计成，如果在线账户在将来被引入，局部身份系统可以自然演变而不是被抛弃。 # 阻碍和摩擦 最大的障碍是抵制过度建设。 一开始，添加玩家身份自然会让人想到： * 认证 * 云同步 * 帐户恢复 * 用户名 * 排行榜 但每个这些都会大大增加开发时间和维护时间。 任务是识别最小的功能，即仍然创造情感投入。 # 做出的决定和权衡 # 选项A 建立一个完整的账户系统。 优点： * 未来可用 * 在线配置文件 * 云同步 * 全球排行榜 缺点： * 极大地增加复杂性 * 认证 * 安全性 * 后端维护 * 新玩家对新玩家造成的阻碍 # 选项B（选择） 建立一个可选的本地身份系统。 优点： * 无需注册 * 立即个人化 * 隐私友好 * 几乎无维护 * 可重用后期 缺点： * 配置文件只存在于该设备上 * 不同步到其他设备 的决定优先考虑： 玩家体验 过基础设施 # 创新 / 学习 本次会话的最大收获是： 在这个阶段，玩家并不一定需要账户才能感到所有权。 只要看到自己的名字附着在分数、挑战和统计中，就可以创造出同样的情感联系，而避免了在游戏的第一版中引入的几乎所有复杂性。 有时90%的情感影响可以来自10%的实现。 # 值得分享的艺术原则 # 产品规则 每个功能都应该证明其复杂性。 # 架构规则 将玩家身份存储在本地。 从不将玩家名字通过分析发送。 只记录匿名状态（例如，是否存在本地手柄）。 # 最终状态 本次会话结束时： * 挑战模式有明确的身份策略。 * 设计了一个轻量级的本地配置文件系统。 * 玩家名字在UI中可重用。 * 分析保持完全隐私安全。 * 解决方案可以在未来的游戏中扩展而无需重写。 * 项目避免了几个月的不必要的基础设施，同时仍使游戏感到更加个人化。 这就是今天的第一部分，感谢您的阅读！