从空间问题出发
前两期，我们聊过园区和室内。空间搭起来以后，一个更有意思的问题出现了：人进去之后，能做什么？
这次，我们借 Emm Tee（@builtbysketch）的 PaperRoute 案例，把问题往前推一步。他做的是一款受经典送报玩法启发的浏览器游戏：玩家骑车穿过街区，投递报纸，面对障碍，完成路线。本篇根据作者公开帖子及长文整理，加入我们的流程解读；并非我们亲自完成游戏开发的实测记录。
两篇帖子，是同一个项目的两个阶段
9月6日的展示帖强调了早期画面和浏览器运行效果。作者当时就说，模型、渲染和整体观感花了不少时间调整。随后，他在回复中补充了角色链路、雨天、破窗、周一到周日流程和上线信息。
9月12日的复盘长文把过程展开：从需求、玩法、美术，到角色、渲染检查与细节。它最有用的地方，是把第一次生成之后的工作也写出来了。
先做一个能完成的玩法循环
作者先描述了送报机制，并提供视角参考。开发初期主要关心骑行、投掷轨迹、邮箱计分和路线终点，随后才深入美术。
我们可以把这种顺序理解为：先让输入、行动、反馈和目标连起来。拿园区来说，只有建筑和道路，用户可能逛一圈就离开；加入配送任务后，同一条道路就有了目的地、路线选择和完成反馈。这是我们从案例延伸出的设计思路，不是作者已经为园区实现的功能。
可以先问自己：玩家三十秒内会做什么？做对之后，怎么知道自己做对了？失败之后，能否理解原因并重新尝试？
玩法和美术，各自有检查标准
作者先通过 ChatGPT 制作概念图和风格参考，再让 Astra 编写 Python，由 Blender 在后台执行，生成房屋、树、围栏和邮箱等资产，导出 GLB 放入浏览器场景。他明确提到这条 Blender 链路并非通过 MCP 操作界面。
文章对“同一线程”和“分开对话”的表述有所交错，但反复强调了玩法与美术任务应当分开检查。可借鉴的原则是：每一轮有明确目标。改房屋轮廓时检查轮廓和风格；改投掷时检查轨迹与计分。不要用一次笼统的“整体优化”掩盖具体问题。
人物卡住时，换一条制作链路
作者发现，脚本搭房屋相对可行，人物尤其是脸部却很难让他满意。他转而使用 ChatGPT 制作角色概念图，再用 Meshy 生成三维网格，交给 Astra 和 Blender 继续减面、修正、绑定与适配自行车。
我们的理解是，工具分工比坚持一个工具包办更有用。概念图负责外观方向，网格生成负责初始形体，后续脚本和人工判断负责让它适合游戏。获得一个三维文件，只是角色进入游戏的起点。
修改的依据，是你能指出来的问题
作者设置了渲染检查流程：查看前、侧、后等角度，也检查转向、投掷、冲刺和摔倒姿势。文章记录了对袖子、手臂、裤脚、头发、车把与脚踏接触的反复修正。
这一步也很适合前两期的空间制作。把“这个房间不对劲”换成“椅子挡住了门的开启范围”，把“园区不好逛”换成“走到岔路口看不到目标建筑”，修改才有可验证的终点。这些空间例子是我们的讲解，不是对 PaperRoute 的功能描述。
好玩的细节，需要留时间
作者还加入人物、雨天、破窗、路线结尾的训练区域等变化，并把部分实验放在独立分支里验证后整合。他认为，作品的选择和取舍仍然需要创作者参与。
统计也要按原文口径理解：作者记录了39小时覆盖时间，其中25.2小时计为有人在场、13.8小时为代理独立运行；15.6亿token里有15.3亿是缓存读取；2,175美元是API价值估算，作者明确说不是自己的账单。统计包含7月早期尝试与9月开发，不能把它压缩成“四天自动做完”。作者也说明，手机持续60帧尚未得到充分验证。
我们从这个案例带走的，不是一句万能提示词，而是一种推进方式：写清目标，先跑通循环，分开检查玩法和美术，用多角度结果找问题，最后把时间留给变化和细节。
如果把你熟悉的地方做成可玩的空间，你会选哪里？可以先写下“地点＋玩法＋原因”：校园找猫、老街送报，或者在客厅寻找线索。具体的想法，比一句“AI真厉害”更能推动下一次实验。
资料范围
本文依据作者公开展示帖、复盘长文及可见补充整理，没有独立完成全流程开发或手机性能实测。作者原文中的模型名称有不同写法，本文统一简称 Astra，不据此判断官方型号。作者提供的游戏站与开发日志作为延伸阅读，未作为独立实测证据。
关键要点
- 先连接输入、行动、反馈和目标，再扩大玩法。
- 玩法与美术分别验收，多角度和动作测试帮助定位问题。
- 2,175美元是作者的API价值估算，不是实际账单。