产出食物、废品、搭屋材料和任务物品；玩家决定吃、卖、保留或归还。
DESIGN RETROSPECTIVE · EARLY PERSONAL PROTOTYPE
拾荒人生
一款儿童视角的叙事探索项目。主线是通过寻找任务物品、结识小镇人物、开放功能地点和新区域，逐步查明主角的真实身份。拾荒、生存与秘密基地构成日常行动和成长反馈，为人物任务提供自然入口。
01 / EXPECTED EXPERIENCE
从“先活过今天”，走向“我是谁”
出门有目的想找到食物和可用物品
轻度生存需求推动玩家出门，但不以越来越严厉的惩罚维持紧张。
拾得有惊喜旧物连接小镇里的人
废品可能换钱，材料可带回基地，特殊物件引出人物任务。
成长看得见小镇认识我，我也有了家
结识 NPC 后出现新服务与线索；秘密基地记录玩家留下的物品。
主线目标是确认主角的真实身份。生存和搭屋控制在轻量范围内：它们让任务从日常行动中出现，也让每次回到基地有温暖的反馈。
02 / CORE LOOP
日循环提供发现，区域循环推进身世主线
日循环
找食物与废品 → 管理饱食、健康和背包 → 兑换或使用物品 → 回基地整理、休息 → 为下一次探索选择目标。
区域与长期循环
发现任务品 → 调查失主并结识 NPC → 解锁服务与新的身世线索 → 完成当前区域全部人物任务后过桥 → 继续寻找身份。
03 / SYSTEM CONNECTIONS
六个系统各有职责，输出又成为别人的输入
饱食提出日常补给需求；健康让高风险搜集和恢复时机产生取舍。
结识废品站 NPC 后把废品换钱；食品、药品、衣物和修理服务各有店主与用途。
发现与核对线索、交还或修复任务物，结识 NPC 后改变服务和故事状态。
当前区域的 NPC 都已结识，桥的关口才开放；新区域引入下一阶段线索。
材料沉淀为布置、储藏和休息条件，是成长反馈与日循环的返回点。
例如：拾荒得到废品和失物 → 归还失物结识废品站老板 → 废品兑换为钱 → 用钱处理补给或付费修复下一件任务品 → 新任务带来人物与区域进度。部分店铺在结识老板后还有着装要求，服装店同时提供自主装扮和满足准入条件的衣物。
04 / HEALTH & PLAYER CHOICES
健康值要改变行动计划，而不是只多一个药品按钮
什么会改变健康
翻找有风险的搜集点、食用带副作用的食物会降低健康；休息和解锁后的补给服务提供恢复途径。饱食与健康会交叉：免费的食物可能解决眼前需求，却让下一次探索更谨慎。
玩家因此怎么选
有重要线索时可以继续探索并接受风险；也可以先走更稳妥的路线换钱，前往已解锁的店铺补给，或回基地休息。药品店的结识任务因此获得具体动机。
规则边界：目前没有确认“低健康降低移速”“固定扣收益”等数值惩罚。正式规则需用原型比较：健康变化是否真的让玩家换路线、改物品用途或主动解锁服务，同时不使主线被生存系统拖慢。
05 / TOWN & PROGRESSION
人物解锁让功能地点与区域推进连起来
初期地图只开放一部分。玩家在寻找生活物资时发现任务品，完成任务结识废品站、食品店等 NPC，然后获得兑换和购买能力。某些店铺还设有着装条件；后续区域的木匠、铁匠和修理店可付费处理损坏的任务品。
区域所有 NPC 解锁后，桥的关口开放，下一片地图继续提供人物和身世线索。任务设计需要清楚提示剩余 NPC，并保证商店开放前仍有基本补给，需要衣物和修理费时也有可达的获取路径。
06 / PROTOTYPE
把文档压缩成一个能回答问题的灰盒
原型的目标不是证明“我能把所有系统做出来”。 我更需要知道：寻找物品与路线探索是否足够清楚？任务能否自然连接生活需求与人物？支撑完整区域解锁链需要多少内容。
07 / DESIGN VALIDATION
把“任务如何推进”拆成可检查的依赖
任务结构
发现特殊物品 → 观察与核对线索 → 找到人物或修复去处 → 完成交付 → 人物及功能状态改变。不同任务组合观察、搜集、修复和排除线索。
服务与资源
废品站把拾荒收获转成货币，商店提供生活用品，后续修理店消耗货币处理任务品。每条必经任务要检查物品、服务与费用是否可达。
进度状态
任务完成、NPC 结识、商店准入、服务开放与桥梁通行是不同状态；区别记录，才能清楚呈现玩家为何暂时无法使用某个地点。
物品表按来源、类型、价值、用途与任务标签组织。新增字段前先问它是否影响一次具体选择；目前 Unity 原型完成了地图灰盒、拾取、搭屋和兑换等基础行为；NPC 与店铺门槛、区域推进以及健康决策链仍是策划方案，未宣称完成测试。
08 / SCOPE REVIEW
真正让我停止项目的，不是技术实现，而是内容规模
完成地图原型，并做出拾取、房屋搭建、物品兑换等简单玩法后，我重新评估了整个项目。基础功能本身可以继续实现，但地图探索要长期成立，就需要持续生产区域内容、任务、剧情、NPC、物品和环境变化。
这些系统之间的耦合又让地图与剧情解锁设计消耗了大量前期时间。对个人独立开发而言，完整工期会远超我希望承担的范围。
因此我主动停止继续开发。
这次原型让我形成了一个之后一直保留的判断：“能实现”不等于“适合做成独立项目”。
这次原型让我形成了一个之后一直保留的判断：“能实现”不等于“适合做成独立项目”。
在 RealityStudio 等后续项目中，我开始更早把内容量、状态变体、资产成本和验证周期一起纳入玩法设计，而不是等系统全部实现以后才讨论 Scope。
09 / WHAT I TOOK AWAY
从灰盒到系统策划，我学到如何控制依赖与范围
Experience First
围绕身份主线分配任务、生存和筑家的职责，避免系统喧宾夺主。
World as System
把地图、NPC、店铺服务和区域门槛组织成可检查的进度关系。
Scope Control
用灰盒和最小玩法闭环重新估算内容生产成本，并在不合适时停止投入。