企业官网建设流程全解析

做caveman这个项目的时候，我脑子里其实只有一个模糊的画面：一个光屁股的原始人蹲在篝火旁边，手里攥着石头，外面是漆黑一片的丛林。这个画面最终变成了一款可以玩的生存模拟原型，核心玩法就三件事：采集、保命、活下去。整个项目从零到现在能稳定跑完一局，大概花了两个周末的时间，中间踩了不少坑，也摸索出一些很有价值的设计取舍，整理出来给同样想做生存类原型的开发者参考。

1. 项目由来与核心玩法定位

1.1 为什么选穴居人题材

生存类游戏其实已经被做烂了，现代都市、荒野、太空站、末日废土，每个题材都有成熟框架。但我选caveman这个题材，理由很简单：它把生存要素压缩到了最原始的层面。没有科技树，没有枪械，没有复杂合成系统，你的所有行为都围绕最基础的三件事——找吃的、避免被吃、生火过夜。这种极简设定天然适合做原型验证，因为玩家不需要任何教程就能理解游戏目标，而开发者也省下了大量UI和引导的精力。

另一个好处是，穴居人题材在视觉表达上有天然的辨识度。低多边形风格的岩石、洞穴、篝火、兽骨，玩家一眼就能记住画面调性。相比同体量的现代都市题材，建模成本低得多，但记忆点反而更强。我当时在程序化生成地形上用了一套纯色的低多边形风格，搭配暖色系的光照调调，效果出奇地好。

1.2 核心玩法的三根支柱

我把整个玩法收敛到三条核心循环上，后来所有系统都是围绕这三根支柱搭建的。

第一根支柱是采集。玩家需要从树木、岩石、浆果丛上获取木材、燧石和食物。这些资源分布在场地的特定区块内，并且有刷新周期。第二根支柱是制作。采集到的资源组合成工具或武器，比如石头斧子、木矛、篝火堆。制作配方我设计得很简单，两种资源组合就能成一个物品，玩家不需要背配方，打开制作面板就能看到可合成的物品列表。第三根支柱是生存压力。角色有饥饿度、体力、生命值和体温四个数值，夜晚会降温，饿太久会扣血，被野猪攻击也会扣血。这三根支柱之间互相咬合，形成推进玩家行动的动力闭环：天快黑了，你得赶紧找木头生火；木头找到了，又发现没吃的；跑去采果子，结果被野猪盯上。这种压力循环是整个游戏乐趣的核心。

我个人认为，生存类原型最忌讳系统堆叠。如果你在第一版就同时加上疾病、心情、社交、建造、地图探索，每个系统都会因为缺乏深度打磨而显得粗糙。caveman这个项目里，我刻意砍掉了所有“锦上添花”的系统，只保留最核心的闭环。事实证明这是对的——每个系统都能在有限时间内做到手感流畅、反馈清晰。

2. 技术选型与项目结构

2.1 引擎与语言选择

我用的Unity 2022 LTS，配合URP渲染管线。选择Unity而不是虚幻的原因很简单：原型阶段，Unity的迭代速度更快，C#的编译、运行、调试链路非常顺滑；而且资源商店里能找到大量低多边形资源包，可以快速搭出场景素材库。URP管线在这个项目里有个很好的优势——它支持更精细的光照衰减控制，火焰光照在夜晚场景中的表现力直接决定玩家安全感，这一点上URP比内置管线强很多。

语言层面用C#。Unity开发里，C#的垃圾回收机制是个双刃剑：写起来方便，但高频调用的AI决策、物品拾取等代码里频繁产生临时对象时会引发GC spike。后面我专门做了一轮性能优化，把AI决策里的LINQ查询全部替换成普通for循环，解决了卡顿问题。这个优化思路非常朴素，但是效果立竿见影。

2.2 项目目录与模块划分

原型项目同样需要清晰的模块划分，否则功能一多就开始互相踩脚。我用了很经典的分层结构：

Assets/ |-- Scripts/ | |-- Core/ # 游戏启动、单例管理、事件总线 | |-- Player/ # 玩家控制、属性、状态机 | |-- AI/ # NPC行为树、感知系统、寻路 | |-- World/ # 地形生成、资源点、昼夜循环 | |-- Crafting/ # 配方、道具、制作面板 | |-- UI/ # HUD、交互提示、制作面板 |-- Art/ | |-- Models/ # 低多边形模型资产 | |-- Materials/ # 材质与着色器 |-- Prefabs/ | |-- Interactables/ # 树木、岩石、浆果丛 | |-- Entities/ # 玩家、野猪、篝火

分层原则很简单：Core不依赖任何业务模块，AI不直接操作UI，Player只管自身属性并对外暴露事件。比如饥饿度变化时，Player组件发出OnHungerChanged事件，UI层订阅这个事件来刷新进度条。这样各模块之间都是单向依赖，写起来清爽，调试时也很容易定位问题。

事件总线我用了C#里最轻量的实现——一个静态类加一堆Action委托。不需要引入第三方框架，Unity 2022的UnityEvent虽然可视化友好，但在代码里订阅和注销反而繁琐，静态事件更直接。唯一要注意的是，在对象销毁时一定要注销事件订阅，否则会造成内存泄漏和NullReference异常。我在项目里封装了一个EventBus工具类，并在OnDisable里统一做注销，踩过一次坑之后就养成习惯了。

3. 生存系统实现：饥饿、体力、体温与生命值

3.1 数值设计思路

生存数值是整个游戏的压力调节器，设计得好不好直接决定玩家体验张弛是否合理。caveman里我设定了四个数值：饥饿度、体力、体温、生命值，每个数值的取值范围都是0到100。

饥饿度的衰减速度是每游戏分钟降0.1，意味着从满值到饿到零需要大约16分钟的游戏时间。考虑到一局游戏的时间目标控制在8到12分钟，这个衰减速度刚好能让玩家在一局内感受到“从吃饱到饿到危险”的完整压力曲线。体力值只会在奔跑和挥砍工具时消耗，静止或走路时缓慢恢复。体温是昼夜循环系统联动的重要数值，白天稳定在正常值，夜晚在地图上的避难点之外会快速下降，降到30以下会触发持续扣血。生命值就是角色生存的最终判定，降到零则游戏结束。

这四个数值之间的联动关系是：饥饿度影响体力上限，饥饿度低于20时体力上限减半；体温低于40时饥饿度衰减翻倍；生命值作为最终出口，会被饥饿和低体温间接消耗。这样整个数值网络形成了一个有趣的叠Buff效应，玩家必须同时管理多个维度，而不是只盯着单一数值。

3.2 数值驱动与状态机架构

数值驱动我用了一个简单的StatusSystem组件，每个子项是一个StatusValue对象，包含当前值、衰减速率、最大值和恢复条件。每个StatusValue在Update里自动更新，同时抛出相应的回调事件。例如饥饿度的更新逻辑简化后如下：

public class HungerStatus : StatusValue { public override void Tick(float deltaTime) { if (GameState.Instance.IsDaytime && player.IsResting) { Current = Mathf.Min(Max, Current + RecoverRate * deltaTime); } else { Current = Mathf.Max(0f, Current - DecayRate * deltaTime * TemperatureModifier()); } LastDelta = Current - PreviousValue; if (Mathf.Abs(LastDelta) > 0.01f) { OnChanged?.Invoke(Current, LastDelta); } } private float TemperatureModifier() { // 体温低于40时饥饿加速 return player.Temperature.Current < 40f ? 2.0f : 1.0f; } }

状态机用在玩家行为控制上，状态包括Idle、Walk、Run、Chop、Pick和Eat。每个状态是一个独立的C#类，继承自抽象基类PlayerStateBase，基类定义Enter、Exit、Tick三个虚方法。状态切换由输入条件和系统事件共同触发，比如当玩家接近木材资源并按下采集键时，输入系统发出OnInteractRequested事件，状态机判断当前状态是Idle或Walk，且目标资源可采集，则切换到Chop状态。

这个状态机架构并不复杂，但它的关键在于将状态切换的所有判定逻辑集中在状态机内部，PlayerController只负责转发输入事件，对外暴露当前状态和状态切换回调。这样后续新增状态（比如游泳、攀爬）时，只需在状态机里注册即可，不会污染控制器的核心逻辑。

3.3 状态反馈与手感调整

数值和状态最终都要通过反馈端呈现给玩家。手感这部分我特别花了心思。饥饿度和生命值的变化直接在HUD上用进度条展示，同时配合低血量时的屏幕红晕和心跳音效。体温变化则通过屏幕色调呈现——体温越低，画面四周的冷色渐变越明显，这种间接反馈比单纯的数值警示更有沉浸感。

采集动作的手感核心在于“打击感”。我做了两层反馈：一是动画上的暂停帧，角色挥砍动作在接触树木模型时，将动画速度瞬间降为原来的20%，持续0.08秒后再恢复，这个模拟“击中停顿”的技巧能明显增强打击感；二是资源破碎时的粒子效果加上镜头轻微震动，震动幅度用动画曲线控制，随采集进度逐渐增强。这两层反馈叠加之后，玩家普普通通砍一棵树的体验也跟原本干巴巴的纯数值变化有了质的不同。

4. 原始AI行为系统：懂需求，才会像真的生物

4.1 AI需求层级

caveman里的AI角色分两类：一类是和平的动物（兔子），一类是敌对生物（野猪）。即便是最低限度的AI，我也希望它们的行为符合动物的“需求驱动”逻辑，而不是单纯的巡逻-发现-攻击三连。我参考了模拟类游戏中常用的需求层次模型，为每种AI定义了简单的动机评分系统。

以野猪为例，它的需求权重是这样分配的：饥饿度权重最高，其次是好奇心（对玩家角色的兴趣），再其次是漫游探索需求。每个AI每隔0.5秒做一次行为决策，计算当前各需求的分数，选择分数最高的需求执行对应行为。饥饿度高时，它会朝最近的浆果丛或食物资源点移动；好奇心分数上升时，会试探性地靠近玩家；当玩家进入警惕范围且双方距离持续缩小时，攻击需求覆盖好奇心，触发冲锋攻击。

这套简易的权重决策模型虽然比不上正经GOAP或行为树，但胜在轻量、直观、易调参。我只需要调整各需求的权重系数和距离衰减因子，就能营造出完全不同的动物性格——野猪更凶猛还是更怯懦，完全由参数决定。

4.2 行为实现：感知、决策与移动

AI感知用了一个很简洁的方案：一个圆形触发器挂在AI角色上，检测玩家或食物进入感知范围。感知范围里维护两个列表，一个是“玩家角色”列表，一个是“可交互资源”列表，每个AI帧从这两个列表里获取数据并喂给决策系统。由于是原型，没有用Unity的NavMesh做寻路，而是直接用简单的方向寻路加障碍规避。

障碍规避的实现也很有意思，我用了三射线检测的方式。AI每帧向前投射三条射线，分别探测左、中、右方向，偏向中间有障碍的方向转向。这个方案在平坦地形上足够用，而且性能开销极低。真正在大岩石堆叠处会出现卡死现象，后面我加了8方向随机试探逻辑：如果检测到前方阻挡，且多次尝试方向都失败，就随机选择一个新的角度重新寻路。这个“死磕后会绕路”的参数调起来非常有意思——数值太大会导致AI频繁放弃目标，太小则容易卡死。

回到代码层面，感知和决策的核心逻辑大概是：

public class BoarAI : MonoBehaviour { private float decisionInterval = 0.5f; private float nextDecisionTime = 0f; void Update() { if (Time.time < nextDecisionTime) return; nextDecisionTime = Time.time + decisionInterval; EvaluateNeeds(); ExecuteBestAction(); } private void EvaluateNeeds() { float hunger = GetHungerScore(); float curiosity = GetCuriosityScore(player); float attack = GetAttackScore(player); bestNeed = (hunger > curiosity && hunger > attack) ? NeedType.Food : (curiosity > attack) ? NeedType.Curiosity : NeedType.Attack; } }

这样实现的好处是，AI的行为不会出现“看见玩家就永远追着打”的僵化模式，而是会根据自身状态做出动态选择。你在玩的时候会发现，野猪有时候会忽略你去吃果子，有时候又追着你跑，这一点点“生物感”极大增加了游戏的耐玩性。

4.3 调试技巧：可视化AI状态

AI系统最容易出问题的地方是你看不清它内部在想什么。每帧的感知数据怎么变化？权重分数如何波动？行为切换是否顺畅？如果靠日志打印，决策数据少的时候还行，一旦打出几十条日志就完全失控。我用了一套轻量的调试可视化方案。

在Scene视图中把AI的感知范围画成半透明的圆环，把当前选中的目标用黄色线条连接；在AI角色头顶挂一个TextMeshPro标签，实时显示当前行为状态（比如“搜索食物”“攻击玩家”）。这些可视化数据在Editor下常驻显示，打包时通过宏开关自动关闭。这个方案帮我节省了大量调试时间，很多时候游戏出Bug了，不用看日志，直接盯Scene视图就能发现AI在感知和决策之间哪里出了问题。

比如我第一次调试野猪攻击逻辑时，发现野猪在距离玩家两米的地方会变成一个痴呆状态，既不攻击也不离开。可视化的日志显示，它的攻击需求得分在临界值附近反复震荡，导致行为的切换频率非常快。后来加了一个行为冷却时间（同一行为在切换后至少保持0.8秒），才彻底解决抖动问题。

5. 场景交互与物品系统设计

5.1 可交互资源与工具链

场景里的可交互资源主要分成三类：树木（产出木材）、燧石岩（产出燧石）、浆果丛（产出浆果）。每种资源都有它的专属交互方式，用石头直接敲击树木效率很低，制作出石斧后效率大幅提升。这里其实埋了一条隐性的工具引导线：玩家刚开始徒手采集时会发现太慢，被逼着去打开制作面板合成工具，而制作材料恰好是前期最容易获取的木材和燧石——这样工具链的解锁过程就自然嵌进了生存压力中。

工具链我设计了三层：徒手→石斧/木矛→篝火。石斧提升伐木效率，木矛提升狩猎效率，篝火提供安全过夜区域。篝火的特殊之处在于它不仅仅是制作物品，同时也是一个“安全区域”标记——只要玩家站在篝火的光照范围内，体温就不会下降，野猪AI的攻击欲望也会大幅降低。这让篝火从一件“普通道具”升格为“策略决策点”：篝火放置在哪里，往往决定了玩家后续几分钟的生存策略框架。

资源刷新逻辑用了分块管理。我以25米x25米为一个区块，每个区块维护一个刷新记录表，记录每个资源点的产出次数和重置时间。玩家在一段时间内连续砍同一区块的资源，资源会逐渐耗尽，但区块本身会在闲置约3分钟后启动一次全局刷新。这样设计是为了模拟自然的生态恢复逻辑，又不会让玩家走太远才能找到新资源。

5.2 交互检测与触觉反馈

交互检测我用了一个基于距离和朝向的简易方案。玩家身上挂一个虚拟胶囊体，指向视角前方，检测范围内所有带Interactable接口的对象。交互对象在材质上添加描边高亮，靠近时显示“E键采集”提示，按下后播放对应动画。这个方案没有用物理射线命中检测，主要考虑到移动端的扩展性，以及避免频繁的Physics.Raycast带来的性能波动。

触觉反馈方面，交互手感除了前面提到的采集打击感外，还有一个细节设计：物品拾取时，模型向玩家角色的方向飘移，并带一个短暂放大再缩小的动画，配合音效模拟“拿到手”的感觉。实际上在手感调试时，我发现光是“拾取动画的持续时间”这一个参数就够调一整天的。太短显得突兀，太长又打断操作节奏，最终定在0.25秒，既保留了反馈，又不拖沓。

5.3 配方与合成面板的设计取舍

合成面板让我头疼了挺久。作为原型，我不希望玩家太容易打开UI界面，那样会破坏生存沉浸感，但也不能太隐蔽让玩家找不到。最后我做了个折中方案：合成面板不是传统意义上的“背包+配方”双栏网格，而是用了一个极简的“需求引导式”面板。面板默认显示所有已解锁配方的卡片列表，每张卡片上标注所需材料及当前拥有量，可合成的卡片高亮，不可合成的置灰。

这个设计背后的逻辑是：当玩家在生存压力下打开合成面板时，核心诉求是“我现在能做什么来解决问题”，而不是“我有多少种材料”。配方卡片直接给出答案，减少了认知摩擦。技术实现上，配方数据用ScriptableObject存储，每个配方包含输入材料列表、产出物品、所需工具和制作时长。ScriptableObject的好处是美术或策划可以改数据，不需要动代码，版本管理的diff也很清晰。

6. 避难点、昼夜循环与火焰渲染

6.1 避难点与篝火机制

避难点是整个caveman地图设计的关键空间节点。我在测试地图里设置了三个主要避难点：一个天然山洞、一块大岩壁下的凹窝、一片靠近溪流的开阔地。山洞相对最安全，但距离主要资源刷新区较远；岩壁凹窝位于森林边缘，资源丰富但夜间会有野猪游荡；溪流旁的避难点视野开阔，但需要玩家自己搭建一圈木头围栏来增强安全感——这个围栏是道具系统里的一个变体，也是唯一带“建造”属性的功能。

篝火机制在这三个避难点中扮演着核心角色。篝火有四个状态：熄灭、点燃、燃烧旺盛、即将熄灭。状态切换由火焰燃烧计时和玩家投入木材的行为驱动。投入木材可以延长的燃烧时间与投入量成正比，投入方式也做了简化——拿着木材靠近篝火，按E键自动添加。这套机制给玩家制造了一个经常性的“心头时间压力”：篝火快燃尽时，你甚至没心情去打猎，只能焦躁地四处找柴。实际测试下来，这种焦躁感反而成为游戏核心体验的一部分，玩家记忆点最深的就是“摸黑找柴差点被野猪追”。

6.2 昼夜循环与光照交互

昼夜循环我是用Unity的Directional Light旋转来实现的，配合一个简单的天空盒插值。白昼持续4分钟，黄昏1分钟，夜晚3分钟，然后再进入黎明。一昼夜8分钟，这个循环长度和饥饿值的衰减曲线刚好匹配，玩家在白天能勉强完成一轮采集、制作、狩猎的准备活动，天黑前必须回到避难点。昼夜循环本身不复杂，复杂的是它和各个系统的交互。

夜晚会让体温下降，同时降低玩家的能见度，但AI野猪的感知范围反而提升。在不安全的夜晚留在野外，等于把自己变成了活靶子。为了强化夜晚的压迫感，我做了声音上的辅助：夜晚时环境音量降低，但远处会随机播放野兽吼叫或树枝断裂的声音。声音并不对应真实实体，只是营造氛围，玩家普遍反映“其实没什么东西追我，但就是吓得不敢出去”。

6.3 火焰渲染的调优经历

火焰渲染是画面表现的重头戏。一开始我用Unity内置的ParticleSystem做篝火粒子，简单快捷，但画面效果偏“假”——火焰缺乏从内到外的颜色渐变，也没有温度带来的空气扭曲感。后来我改用URP中的Lightweight Render Pipeline的2D/3D光照探针做辅助光照烘培，并在火焰中心放了一个衰减范围很小的点光源。

真正让火焰看起来有生命力的，是一套“扰动”逻辑：点光源的颜色和强度会在橙黄和橙红之间用噪声函数做微小波动，粒子系统的发射速率也会根据一个正弦曲线抖动。这些扰动叠加起来，篝火的暖光就带上了呼吸感。后来我又给火焰加了阴影投射，黑暗环境中的火光照亮人物和岩石轮廓，那种“光与暗的交界”一下子就出来了。性能方面，火焰粒子数量控制在600个以内，点光源光照半径不超过8米，在低端移动设备上还有优化空间，但PC和主流手机上60帧无压力。

7. 常见问题与排查技巧实录

7.1 行为卡死：AI在障碍物前疯狂转向

这是我在开发过程中遇到的第一个比较严重的Bug。野猪在试图接近玩家的过程中，一旦碰到一块突出地表的石头，三射线障碍规避系统就会失效，野猪在石头前原地高速左右摇摆。排查办法还是靠可视化调试：把感知范围和射线方向画出来后，发现野猪的三条射线里，中间和左边的射线都撞到了石头，它转向左，但因为石头不够宽，左边射线又通过，转向结束它重新直行，再次撞上石头——死循环。

解决方案是加上“卡死检测”：持续追踪AI在0.5秒内的位置变化，如果移动距离小于阈值，则判断为卡死，强制切换到一个较高权重的随机转向行为，再清除卡死标记。实际测试下来，这个方法比用NavMesh的障碍偏移要轻量许多，而且符合AI的“野生感”。

7.2 高频拾取物品导致GC卡顿

早期版本的物品拾取逻辑是在每个物品的OnTriggerStay里检测玩家按键，然后实例化一个拾取提示组件。高密度资源区（比如一片浆果丛）里十几件物品同时处于触发器范围内，每帧都要检测，加上提示组件的实例化销毁，GC频率高得可怕。我用Profiler一看，GC.Alloc的峰值能到几十KB，这在低保真原型中是不该出现的。

优化思路分两层。第一层：拾取提示不再每帧实例化，而是改为对象池管理；没有按键操作时，只维护一个全局提示对象，玩家碰到的第一个资源更新提示文本和位置即可。第二层：OnTriggerStay的检测频率降到0.15秒一次，用一个可变的检测计时器控制，拾取手感几乎没有损失。

7.3 手感太“飘”：碰撞体范围与交互距离的博弈

玩家反馈采集动作“打空气”的情况比较严重——明明看着角色挥刀碰到树木了，却没有任何反馈。这个问题的根源在于模型的碰撞体和交互检测胶囊体没有对齐。树木模型的碰撞体是一个胶囊体，但视觉上的树冠会超出碰撞范围一大截，导致玩家以为碰到了树冠，实际Collider只碰到了树干以下区域。

解决方法是调整树木的碰撞体，让它更像一个盒型结构覆盖树干的中下部分，同时加大交互检测胶囊体的半径。但距离控制必须精细——太大就会变成“隔空采物”，太小则频繁出现碰不到。最终我把交互半径调到2.5米，胶囊体半径1.0米，这个组合在大多数地形和模型尺寸下都表现正常。

7.4 昼夜切换的突然变暗问题

夜幕降临的那一瞬间，整个场景亮度骤降，视觉上非常突兀。我原本以为只要把Directional Light旋转角度做成平滑过渡，亮度就会平滑，结果忽略了天空盒插值的变化。白天的天空盒和夜晚的天空盒颜色差异太大，即使光源平滑移动，天空颜色的突变也会让玩家觉得“唰一下天就黑了”。

修复方法是将天空盒的曝光值和颜色插值也纳入昼夜切换的时间曲线里，同时把光源强度曲线改为S形缓动。这里有个小技巧：曲线中间部分变化快，两端变化慢，模拟自然光在黄昏和黎明时的“急转缓变”特性，整个过渡会自然很多。

8. 从原型到可玩Demo的扩展思路

8.1 增加配方深度，但不破坏极简体验

如果继续做下去，我第一优先级的扩展方向是配方深度。当前版本只有一个配方表，可制作的物品有限。在不破坏极简体验的前提下，可以增加“工具升级链”——石斧可以升级成石锤，石锤可以在岩壁上砸出燧石碎片；或者把木材+浆果组合成“浆果烤串”，让食物恢复量翻倍。配方等级逐层解锁，高等级配方需要的材料来自低等级配方的产出，这样整个流程就形成了一条自然的引导链，玩家始终知道下一步要做什么。

8.2 巢穴与部落实体互动

地图里可以加入一个原始的“洞穴巢穴”，作为玩家的第二个安全点。按一定的天数条件（比如存活到第三夜），会有另一名NPC部落成员出现，帮忙跟随玩家行动并提供战斗支援。但引入NPC就需要处理更复杂的行为协同，目前的简易AI框架在这块的扩展成本较高。更务实的做法是：把NPC做成“跟随采集”型助手，不会主动攻击，但会帮玩家自动采集附近资源。这个模式不需要复杂AI，只要一个简单的跟随状态和采集计时器就能跑起来。

8.3 服务器实时同步与多人联机

虽然原型是纯单机，但很多朋友反馈想和朋友一起玩。单机版要改成联机，最直接的方案是用Unity的Netcode for GameObjects做同步，把玩家属性、资源状态、篝火状态这三个核心系统的同步做出来。资源同步的冲突处理是难点，比如两位玩家同时砍同一棵树，谁获得产出？我的设想是引入简单的“采集所有权”机制：第一位开始采集动作的玩家获得该资源的产出权，其他玩家只能旁观或等待刷新。这个机制的实现复杂度不高，但能避免大量冲突问题。

8.4 让“饥饿”不再是数值，而是情境

数值之外，我想做更多情境化的生存叙事。比如饥饿度高时，玩家视野边缘会出现模糊虚影，模拟低血糖的眩晕感；或者在极度饥饿的状态下，角色会听到错觉的流水声或浆果晃动声。这些非数字的“软反馈”比进度条掉得更快更能让玩家身临其境。把生存从“数值管理”向“情境体验”推进，是这类游戏真正的分水岭。

在一个小而有趣的题材里做原型，最忌讳的是想一口气吞下所有功能。caveman能从一堆灰盒开始走到今天这个状态，靠的是一步步把核心循环夯实，再把每个系统的反馈细节打磨到位。拿到别人跑通的思路，自己在项目里重新踩一遍坑，你会比任何教程都更理解它们的价值。