从零开发一款像素风生存建造手游：Caveman完整立项、数值、优化与上线复盘

我最近一直盯着"caveman"这个词发呆。这两年在游戏社区里，"穴居人生存"题材好像又热了一轮，从《孤岛惊魂》里的原始杀戮到各类Steam上的石器时代沙盒，大家都想体验一把"开局一双手、装备全靠打"的原始生活。但市面上大多数同类产品要么太重、要么太黑，真正能让人在通勤路上掏手机玩两把的并不多。于是我自己从零开始做了个小游戏，项目代号就叫"Caveman"：一款竖屏、单指操作、像素风格的石器时代生存建造游戏。这篇文章是我完整立项、开发、优化、上线的全过程复盘，不写虚的，只聊真实的取舍、数值、代码和踩坑，适合正在做独立小游戏、或者打算用业余时间跑通一个完整产品闭环的朋友。

1. 立项复盘：从"caveman"这个词到我这个游戏的缘分

1.1 一句话说清楚《Caveman》是什么

《Caveman》是一个竖屏手机上的单指操作生存建造游戏。玩家扮演一个穴居人，白天收集木头、石头、草、果实，晚上躲进山洞点火取暖防野兽。目标是在有限天数内建立自己的部落营地，并解锁更高级的工具和建筑。整个游戏一局大概是十五到二十分钟，没有强制广告，没有养成抽卡，就是一个纯粹的、可随时拿起放下的沙盒小循环。

你可能觉得这个描述很普通，但正是"普通"两个字把我自己骗进去开发了八个月。因为越简单的玩法，越考验底层设计的扎实程度：资源循环顺不顺、AI行为可不可预测、手感重不重，每个点都能直接决定玩家是留着还是卸载。

1.2 同类型竞品调研：抄什么、不抄什么

在动手前我把当时能玩到的同类游戏全过了一遍。横向对比下来，它们主要分成两派：

我的判断是：在手机上做重度自由建造是死路，因为操作精度和屏幕尺寸根本撑不起复杂建造；做竞技又拼不过头部大厂。所以《Caveman》的差异化就落在"轻度、单局完整、单指操作"这三个关键词上。我要的是一个玩家在地铁上等车的十几分钟里，能完成"白天采资源、晚上扛过野兽袭击、顺手盖出一个小营地"的完整体验。

1.3 引擎选型：Unity、Godot还是纯前端

这个决定直接影响后面八个月的开发体验，所以我认真做过对比。Godot 4对2D很友好、启动快、导出APK体积小，但当时我对它的移动端性能调优体系还不熟；纯前端用H5的话，性能和包体是个坎，而且我想做的本地存档、粒子特效、音频池这些能力要自己造不少轮子。最后选了Unity 2021 LTS，原因是移动端生态最成熟、Profiler工具链完整，搜问题也容易。说实话这个选择谈不上惊艳，但在业余时间开发的场景下，"团队踩坑经验密度"和"搜索能搜到答案"这两点比引擎本身先进多少更重要。

2. 生存循环的底层设计：饥饿、寒冷与恐惧三个维度的数据模型

2.1 为什么是三个维度，而不是十个

很多生存游戏一上来就给玩家一堆数值：饱食度、血量、水分、心情、体温、耐力……看起来真实，实际体验是玩家必须一边看教程一边盯面板，玩半小时还记不住哪个数值对应哪个颜色。《Caveman》只做了三个维度：饥饿（Stomach）、体温（Warmth）、恐惧（Fear）。

三者的关系我用一句话概括：白天吃不够，晚上就会冷；夜里火不够，恐惧就会涨；恐惧满了，角色就会失控乱跑，直接冲向野兽。这个循环的妙处在于它天然形成了一个"白天决策影响夜晚结果"的闭环，玩家不需要看任何说明就能通过失败理解规则。第一次被狼咬死的玩家，下一次一定会多带两根柴火回家，这就是设计目标。

2.2 资源数值的推导过程

资源数值是我最早用Excel反复推演的部分。下面是初始版本的参数表，我后面所有玩法都基于这张表扩展：

这里最核心的推导逻辑是"夜晚时长决定资源下限"。我设定游戏内夜晚是90秒，相当于真实时间的1.5分钟，这个长度刚好是玩家等待的火堆不至于无聊、但也不至于从容到随便浪的时长。晚上每分钟烧1单位木头，玩家就必须在白天存下至少2~3单位木头才能安稳过夜，再加上烤肉也要木柴，所以白天至少采集5单位木材。这组数值是从"夜晚时长"反推出来的，而不是拍脑袋定的。

2.3 数值平衡的第一次重大调整

初版测试后发现一个问题：只要有5单位木头，玩家就能蹲在山洞里挂机熬过夜，完全没有动力去猎杀野兽。这导致"打猎"这个核心乐趣完全被浪费。我的调整方案是引入"饥饿阈值"：当饱食度低于30时，角色睡眠质量下降，体温流失速度提升50%，即使坐在火堆旁也会逐渐冻伤。这意味着玩家不能只是囤木头，还必须持续出门找食物。这一刀砍下去，游戏节奏立刻紧了起来，也逼着玩家去接触长矛、弓箭这套工具链。

这个经验对我后面所有系统都有启发：生存游戏的压力不来自数值本身，而来自数值之间的耦合关系。单看任何一个资源都很充裕，但叠加维度之后玩家才会感到"什么都缺一点"的紧迫感。

3. 程序实现：一个有点像状态机的原始人

3.1 玩家状态机的设计

角色控制这块，我没有用复杂的动画控制器直接裸调，而是先写了一个基于枚举的状态机。状态机不光是代码风格问题，它解决的是"防止操作冲突"的核心痛点：采集时不能被攻击打断，被打时不能继续建造，这些规则如果用散落的if/else写，改三四轮之后必然乱套。

public enum CavemanState { Idle, Walk, Gather, Attack, Build, Sleep, Panic, // 恐惧值满时的失控状态 Dead }

核心思路是定义一张"状态切换权限表"：允许从哪些状态进入哪些状态，禁止的路径直接return。比如Gather状态下禁止触发Attack，除非先打断；Panic状态只能由Idle和Walk进入，之后玩家必须等到恐惧值降下来才能恢复控制。这样一套表下来，异常状态交叉少了很多，Debug成本明显下降。

3.2 物品与配方数据的可配置思路

《Caveman》有二十多种物品、十几种配方，如果全写死在代码里，后期调平衡就是在烧时间。我用了Unity的ScriptableObject做了一套数据驱动体系，每个配方就是一份资产文件：

[ { "id": "stone_axe", "name": "石斧", "ingredients": [ { "item": "wood", "count": 2 }, { "item": "stone", "count": 3 } ], "craftTime": 4.0, "unlockDay": 2 } ]

配方里的unlockDay字段是后期加上的，用来做"天数解锁"。它比科技树方案轻得多，也更符合穴居人朴素的题材。调平衡时只需要改JSON，策划数据可视化、QA回归都方便。这个习惯我是从一个做卡牌的前辈那儿学来的：凡是超过五种的同构数据，一律别写死在代码里。

3.3 建造系统的网格与放置规则

建造系统我纠结了两个星期。方案A是自由放置，方案B是网格对齐。自由放置观感好，但移动设备上很难避免误触和重叠；网格对齐处理简单，但看起来像"卡通农场"。最终我做了个折中：半网格吸附，即建筑本体用格点固定（方便碰撞和交互），但装饰物可以自由偏移，视觉上显得自然一些。

放置的合法性检测核心就两条：是否在营地范围内、是否与已有建筑重叠。实现时我用了一个简化版的格子碰撞：

bool CanPlace(BuildingData data, Vector2Int cell) { foreach (var occupied in _occupiedCells) { if (occupied.Overlaps(cell, data.Size)) return false; } return true; }

这里有个我踩过的坑：Unity的RectInt和BoundsInt在判断重叠时，对"边界算不算占用"的默认策略不一致。第一次实现时我把建筑边缘圆角当成了装饰，结果一个栅栏转角的位置会被判定成两个房子同时占用，导致存档读档后建筑莫名其妙缺一块。我后来统一封装了一个GridRect结构，所有判断都走同一份边界逻辑，问题才彻底消失。

4. 像素美术与表现力：24x24的框子里谈手感

4.1 为什么坚持24x24像素

一开始美术同事建议用32x32，这样细节多、动作好画。但放到手机竖屏之后，32x32的角色在屏幕上占据的有效像素其实很细微，远看就是一团色块，导致玩家经常找不到自己控制的人物在哪里。我最终选了24x24，分辨率低一点，但每个像素的对比度更大，轮廓在复杂场景里反而更跳。

同时24x24意味着动画帧数必须精打细算。我曾想给"走路"画8帧循环，看着很流畅，但一做攻击动作就得妥协，因为总帧预算摆在那。后来我把走路砍到4帧、攻击砍到2帧，但每帧都做像素级的前后对比调整，最终效果甚至比8帧更干净，因为少了大量中间过渡的抖动感。

4.2 人物动画状态机：从"能跑"到"有手感"

美术动画和程序状态机的结合是个老问题。代码里我分成两层：逻辑层只关心CavemanState，表现层有一个独立的动画状态机做过渡。逻辑层从Walk切到Attack，表现层不一定立刻播放攻击动画，而是先做一个短暂的"准备"过渡帧，这个延迟让挥击有了蓄力感。

具体帧配置我列一下，给想做像素动作的朋友参考：

4.3 打击感的三个隐藏细节

我一直认为"打击感"不是一次攻击动画做得好，而是多个反馈同时叠加。第一是击退位移：受击怪物往攻击方向后退2~3像素，不需要真实物理，手动插值就能假造出受力感；第二是顿帧：攻击命中的那一帧，游戏逻辑暂停0.05秒，视觉上有一种"砸实了"的卡顿；第三是粒子残影：挥动路径上留下2帧淡出的白色虚线像素，弥补24x24下动作幅度不够大的问题。

这三个细节加起来成本极低，但玩家反馈"手感不错"。这是独立小游戏性价比最高的投入：先把反馈密度做足，再谈动作设计的华丽度。

5. 性能与兼容：我把自己当成了中低端安卓用户

5.1 性能目标与实测基准

《Caveman》虽然是个小游戏，但我很早就定下目标：在红米9A这种中低端设备上，也要能稳跑30帧，发热控制在温热而非烫手的程度。为此我买了一台二手安卓测试机专门压测，而不是只在模拟器上跑。很多独立开发者吃亏就吃亏在测试机太好，真机一跑就掉帧。

首轮Profiler数据非常难看：角色动画重绘、Tilemap全量刷新、粒子系统在夜晚火堆场景满屏幕跑，直接导致电量十分钟掉8%。我给自己定了一条调试基准：任何系统在100ms的帧预算里，都不得超过15ms的占用。

5.2 三项核心优化：对象池、Tilemap分区、粒子封顶

优化动作里最立竿见影的，是给掉落物、伤害数字、野兽尸体这些高频生成销毁对象做了对象池。Unity的Instantiate/Destroy在手机端真的很贵，尤其当一晚上要刷二十只狼的情况下。对象池实现不复杂，但要注意池子的初始容量、最大容量、回收策略，否则内存会像气球一样涨。

第二项是Tilemap的分区加载。早期版本我先生成整张地图的Tilemap再让玩家跑，实际场景一大，AWS的加载时间就会多出一大截。后来改成网格分区，玩家周围活跃9个区块，更远的直接休眠，地图表现上没有任何差别，但初始化时间下降了接近一半。

第三项是粒子数量的硬性封顶。夜晚火堆我原来想做连续粒子喷发，效果是真的好，但中低端机直接被拖垮。最终策略是根据设备等级动态调整粒子上限：高端机120个、中端机60个、低端机30个，同时降低粒子发射频率。这个策略牺牲了部分高端机用户可能获得的观感，但保住了一个"所有设备都能玩"的下限。

5.3 优化前后的实测对比

我这里放一组同一台红米9A上的实测数据，给大家做一个直观参考：

5.4 关于"轻量"的两个认知修正

做完这轮优化，我修正了两个自己的认知偏差。第一个偏差是"2D游戏不需要性能优化"，实际上像素游戏的性能瓶颈一点都不少，尤其是Tilemap和粒子，还有大量的Sprite渲染；第二个偏差是"优化会损害美术表现"，实际上通过对象池、LOD、分帧加载这些技术手段，把原本卡顿掉帧的部分变成稳定流畅的场景之后，玩家对美术质量的感知反而提升了。帧率稳定本身就是一种"高级感"。

6. 测试与上线：真实世界比任何模拟器都残酷

6.1 招募测试玩家时我吃的哑巴亏

游戏开发到第七个月，我信心满满地拉了二十个朋友做封闭测试。第一天就翻车了：所有人的游戏安装包都装不上。原因是我用开发签名打包发给了测试群，测试人一多、手机型号一杂，各种兼容问题全部冒出来了。后来我赶紧切到正式签名，并且自己用三台不同品牌、不同安卓版本的机器全部重装一遍，才把问题压下去。

这个教训非常直接：测试包和正式包必须用同一套签名流程，不然你根本不知道玩家装的是不是你打算发的那个版本。还有一个小细节，测试包要提前打开"允许未知来源安装"的设置，否则很多玩家根本不会去设置页面找你。

6.2 关于"免费+广告"模式的最终决策

《Caveman》从开发初期就在"买断制"和"免费+激励广告"之间摇摆。试过接入广告SDK，结果字节跳动的SDK包体增重快20MB，审核和隐私合规也一堆事情，还要面对各种回调坑。最终我选择了免费下载+少量激励广告（复活、双倍资源），不插屏、不横幅。这个决定不是因为我道德高尚，而是我算过一笔账：插屏广告在二十分钟短平快流程里只会打断节奏，玩家卸载率带来的损失远大于广告收益。

6.3 商店页文案与截图转化率的简单复盘

商店页是我花了整整一周打磨的部分。第一版截图我放的是"创建角色""砍树""夜晚点火堆"三张流程图，点击率非常平庸。后来我改成一张"角色坐在篝火旁、身后是野兽剪影"的情绪图，配上一句"今晚，你能活到明天吗？"，点击率提升了将近40%。这让我意识到：在TapTap这类商店里，文字情绪共鸣比功能演示更能拉新，玩家想看的不是游戏机制，而是"这款游戏会带给我什么情绪体验"。

6.4 上线两周的数据复盘

游戏上线两周，安装量三千多，日活跃在两百上下，次日留存率略有上升但整体还属于小体量。数据上最让我惊讶的是：玩家平均单局时长比我在开发时预想的多了近五分钟，很多人都愿意在夜晚阶段多待一会儿、把营地布置得更完整。这导致我原本设计的"十五分钟单局"变成了"二十分钟起步"，策略调整为：适当压缩耐力消耗、让白天采集效率略微提高，保持整体节奏不拖沓。

另一件值得记下来的事情是：安卓平台上"下载-安装-打开"的转化漏斗，比我想象中损耗大得多。原因是很多低端机在安装完点击图标后，首次启动黑屏时间过长，很多用户直接就卸载了。这逼我做了启动画面进度提示，至少让玩家知道"它在加载，不是死了"。

7. 代码之外：那些文档里不会写的运营细节

7.1 管理社区反馈的节奏感

游戏人少但活跃，玩家的每条反馈我基本都会在当天回复。有一个玩家在评论区抱怨"晚上太黑看不见狼在哪里"，我第一次回复是"建议升级火堆提高视野"，第二次又遇到同样的问题，我恍然大悟：可能并不是看不见狼，是屏幕亮度在夜晚场景确实压得太低。我随后把夜晚的全局亮度从0.25调到0.35，同时给狼在低光状态下增加了一双发光的眼睛。这个调整让差评直接少了一半。玩家反馈描述的是感受，不是方案，永远要回到实际体验里去验证真伪。

7.2 独立小游戏"再加一单"的冲动陷阱

开发过程中最大的敌人不是技术，是"我还能再塞一个系统"的冲动。第八个月时我一度想加"驯化宠物系统"，画了草图、写了状态机，做了一个星期的demo，最后我硬生生砍掉了。理由很简单：这会牵扯到新的寻路AI、新的资源消耗、新的引导教程，但它在核心循环"白天采集、夜晚防守"中并不是必要的。砍掉后整个游戏包体小了2MB，流程更紧凑。如果你在做一个独立小项目，请对任何新增系统保持怀疑，默认答案应该是"不做"。

7.3 下一版本计划的务实选择

现在手上的下一版本计划很克制：第一，增加一个"休闲模式"，降低夜晚野兽频率，让生存苦手也能享受建造乐趣；第二，加入云存档，解决玩家换机后进度丢失的吐槽；第三，做一版更适合横屏的外服包，试探一下海外用户的口味。没有第四个系统。我很清楚一个现象级小游戏大概率轮不到我，但把一个已经上线、有真实玩家的产品打磨到平滑舒服，是我这个阶段能做到的最实在的事。

做完《Caveman》整个周期，我个人最大的感受是：小游戏项目的天花板不是引擎、不是美术资源，而是你在每个"要不要做、先做哪个、砍掉什么"的瞬间，有没有足够清晰的逻辑去支撑决策。这套逻辑来自竞品调研、数值推导、真机测试和玩家反馈，每一步都急不来。如果你也想启动类似的项目，我的建议很简单：先把"一局体验"的长度定死，再把资源数值从这个长度反推出来，然后用一台低端测试机把你的所有幻想挨个打碎。你会比我少走很多弯路。