项目立项：这个游戏为什么长这样

1.1 我最初想做的那个版本，被我自己砍掉了

我最初写在备忘录里的 Skyline Courier 是个城市物流经营游戏：玩家有一支无人机车队，接单、造仓库、升级运输能力、跟竞争对手抢单子，配一套轻度的经济循环。这个想法听上去挺完整，做起来是个坑。

第一个月我做了个灰盒原型，只有俯视网格、点击格子生成无人机、无人机飞到目标点。跑起来才发现，玩家能做的决策只有一个：点哪里。别的全是数值变化，而数值变化在没有真实反馈的前提下，玩家感觉不到自己在玩什么。

于是我把范围砍了。砍的过程不优雅，我先列个单子，后面表格里那份清单是最终版本：

砍到最后剩下的是一个纯粹的技巧小游戏：一架无人机，一份订单，一片有障碍和风区的城市，一趟送快递。这个东西的好处是，一个关卡就是一个问题，玩家试三次就知道自己在想什么。

我现在的判断是，一个人做项目的第一版，最该砍的不是美术，是系统数量。系统会互相扯皮，加一个就要给另外三个补适配。

1.2 为什么是 2D 俯视角，不是 3D 也不是横版

决定用俯视角那一晚，我其实在试 3D。因为俯视意味着玩家能一眼看清整个关卡的障碍分布，这对"规划路线"这个玩法核心是刚需。横版做不到，你能看到的只有身前那一小块，玩家会变成瞎猜，那核心循环里最有意思的一环直接没了。

3D 我试了大概一周就放弃了，理由很实际：微信小游戏的主包限制是 4 MB，主包加所有分包加起来不超过 30 M。3D 的骨骼、材质、模型资源往里一塞，光引擎运行时代码加一张默认材质和一张环境贴图就吃掉大半预算，留给内容的空间被压到几千 KB。而且 3D 做这种俯视角，美术得搭楼体、摆模型、调光照，一个人做一栋楼的时间够我做完一整张俯视场景图了。

俯视角还有个隐形成本低的特点：地面用一张平铺图加几个立面贴片就够了。我不是美术出身，我的做法是用纯色块加描边先拼出所有场景，程序能跑通之后再找外包或者素材站补细节。3D 做不到这一点，缺一个模型场景就是缺一块。

物理上我选了 RigidBody2D。2D 物理在这类游戏里足够表达碰撞和风力推力，而且 Box2D 的行为是可预期的，调试时我心里能算出碰撞后的位置。3D 物理我调不明白。

1.3 为什么主平台是微信小游戏

先说结论：微信小游戏是主平台，Web 是副平台，我用 Web 来快速验证玩法，用微信小游戏来验证性能和变现。顺序不能反。

选微信小游戏是因为启动成本。玩家扫个码就进来了，不需要装 App。对一个没有 IP、没有买量预算的独立项目来说，"下载这一步"能筛掉一半人。开发者工具能直接连真机调试，手机上装一个 Cocos Creator 扩展就能看日志，这个链路比原生 App 短得多。

代价也很实在，我列个表，主要是提醒自己别掉进这些坑：

Web 有一个真实优势：调试快。F12 里能看到网络请求、断点、打包后的 bundle 体积，我前期做 bundle 瘦身时几乎天天靠 Web 版本看数据。微信小游戏版本的调试要开开发者工具、连真机、看 Console，慢半拍。所以我的做法是：玩法逻辑和资源加载先在 Web 上跑到顺，微信小游戏只做适配层的工作。

有一条是我踩过才知道的：小游戏里没有 DOM，别在 Web 上能跑就以为小游戏也能跑。后面第 4 章会专门写这个。

1.4 核心循环必须能用一句话说完

我给自己定的规矩是：核心循环如果需要两句话解释，说明还没想清楚。

Skyline Courier 的一句话是：送得越快越远，赚得越多，但路上的障碍和风区会越来越难躲。

拆开是五步，也就是玩法循环：

1. 接单。玩家在 ScrollView 订单列表里挑一单，看清目的地、时限、报酬。
2. 规划路线。地图在眼前，玩家判断哪条路障碍少、哪段有风区、绕远还是硬闯。
3. 躲避障碍。实际操作无人机穿过楼宇间隙和风区。
4. 送达。撞了会掉耐久或者丢件，超时扣钱。
5. 结算。给钱，进入下一单，难度递进。

我一开始写的循环是"接单 → 规划 → 飞行 → 结算"，四步，少了"躲避"和"送达"这两个反馈点，结果玩起来像模拟器，屏幕在动但玩家没有决策压力。补上之后难度曲线立刻有了抓手。

一个循环要立得住，得满足几个条件：

• 每个环节都有玩家能读懂的信息，不需要猜规则。风区要有明显的视觉提示和方向箭头，伤害要有数字飘字。
• 每个环节都有一次成功或失败的反馈。送达要有落地动画和结算音，撞墙要有屏幕抖动。
• 每一圈时长在 60 秒到 90 秒。太短没有决策空间，太长玩家注意力散掉。
• 数值要少。一局里玩家需要同时盯的变量不超过三个：剩余时间、剩余耐久、当前报酬。

我给这三个变量的初始值是：时限 45 秒、耐久 3 格、报酬按距离算 10 到 60。三个数在小屏上一眼能看完。

1.5 美术规格和性能预算怎么定

这一节的东西看起来像配置，实际上是约束。定不下来后面每加一张图都要吵一次。

设计分辨率我定的是 720×1280，竖屏。理由是玩家单手操作竖持手机最稳，而且订单列表放顶部、视野放下方，俯视角的关卡区域正好铺满剩下的横向空间。720 宽这个数是因为它在 2 倍图上整数缩放不会糊，也刚好卡在主流手机屏幕的逻辑宽度附近。

图集和资源规格：

性能预算我按中低端安卓机定，也就是大概 2019 年前后的千元机，微信小游戏环境里：

我给自己定的规矩是，每加一个美术资源，先问它能不能塞进某个 bundle，bundle 能不能塞进 4 MB。塞不进就先别加。这条规矩救了我一次：早期把所有场景放一个 bundle，构建完发现主包 3.6 MB，加两个场景就爆了。拆成 gameplay、level、ui 三个 bundle 之后，主包降到 1.1 MB。

预算的意义在于提前砍。等包体超了再回头找资源，那是几小时的工作量；定预算的时候砍掉一张图，只要 30 秒。

1.6 相关阅读

• Cocos Creator 3.8 用户手册
• 微信小游戏框架参考文档
• libGDX v1.10 Documentation