开发日志 #1 — 围绕「被需要」设计猫咪陪伴互动
platform: 个人站 DevLog lang: zh-CN topic_id: HW-20260904-01 title: “开发日志 #1 — 围绕「被需要」设计猫咪陪伴互动” status: 已关闭 (B4 交付 · 2026-09-04) compliance: C1 §5.2 十二维核查通过 (无 🔴)
这是一系列笔记的第一篇，聊我作为单人开发者怎么构思这款治愈宠物陪伴游戏的猫咪互动系统。暂时没有玩法爆料——先分享设计思路，因为这恰恰是我最希望更多开发者愿意公开的部分。
一直绕不开的问题
早期原型「精致但空虚」。猫的动画没问题，玩具系统也跑得通，可测试者反应平平。当我深挖反馈，得到的永远是某种变体的：「挺可爱，但我觉得它并不在乎我。」
这句话，重塑了我对整个系统的理解。
假设：被需要的连续性
玩家要的不是系统更多的宠物模拟，而是一个会注意到自己的生命。于是我停下了「堆内容」，开始设计记忆。
具体来说，猫的情绪是一个小型状态机，由一张轻量的「互动账本」驱动——它是一段近期玩家行为的环形缓冲，而不是一张巨大的属性表。每个行为（喂食 / 梳毛 / 玩耍 / 漏了一天）都会写入一条记录。反应是对这张账本做模式匹配得出的，而不是对单一数值的阈值判断。
为什么用账本而不是「亲密度条」？因为进度条在告诉玩家「把我填满」；而账本能让猫出其不意：「你三天没梳毛了，所以我坐在梳子旁边。」这种意外，才是产品本身。
三个抓手（以及它们如何落到代码）
- 互动记忆 → 账本 + 模式匹配反应。构建成本低，可读性强。
- 可培养的陪伴关系 → 慢速、非线性的情绪状态机。「怯生」到「你的」是一段曲线，不是一条填充条。
- 日常仪式感 → 循环的奖励是「出现」本身，因此仪式被调校成「重复也舒服」，而不是「可以被优化跳过」。
我在盯的风险
风险不在体量，在信任。如果猫的反应让玩家事后无法解释，记忆就会显得随机，魔法瞬间破灭。所以每个反应都附带一个可见的成因。可读性优先于聪明。
下一篇：账本如何在长时间闲置（「你一周后才回来」的情况）下依然高效且存档安全。
封面：暖色调低饱和陪伴概念图（见 HW-20260904-01_cover.png）。