1. 这不是“地铁模拟器”，而是一次用游戏引擎做城市公共信息载体的实践
你有没有在地铁站里，盯着那张密密麻麻的线路图发过呆？换乘节点像迷宫，出口编号像密码，高峰期挤在闸机口时，连自己该往哪个方向走都得靠运气。我第一次在广州体育西路站被人群裹挟着转了三圈才找到APM线入口，那一刻就想着：如果这张图能“活”起来，会是什么样？不是炫技的3D建模，不是空洞的文旅宣传，而是让一个从未到过广州的人，站在手机屏幕前，就能凭直觉判断“从北京路站下车后，走哪条通道、上几级台阶、穿过哪个玻璃门，就能看到北京路步行街的牌坊”——这才是我们做这个Unity项目的真实起点。
关键词里“广州地铁”“Unity”“第三人称视角”三个词，表面看是技术组合，实则暗含三层约束：地理精度决定信息可信度，引擎能力决定交互自由度，视角选择决定用户认知路径。我们没做“广州地铁模拟器”，因为那需要调度算法、客流模型、信号系统仿真——那是交控研究院的事；我们做的，是“可行走的地铁空间说明书”。它不替代官方App的实时到站功能，但补足了官方App缺失的“空间预演”能力：你在进站前，就能在虚拟环境中把出入口、扶梯位置、换乘通道宽度、甚至盲道走向全部走一遍。疫情封控期间，很多外地务工人员返穗前反复查看这个Demo，就为确认“从广州南站出来，走哪条路能最快避开人流密集区”。这不是游戏，是带坐标系的公共基础设施数字孪生切片。
项目标题里“广州加油，早日战胜疫情”不是口号，是设计原点。当线下导览停摆、纸质地图更新滞后、志愿者无法现场指引时，一个轻量、免安装、纯离线运行的Unity WebGL版本，成了社区群转发最多的链接。它不需要服务器渲染，所有模型、贴图、导航网格都在本地加载；它不采集任何用户数据，连点击行为都不记录——因为它的唯一KPI，是让第1001个用户，在真实世界里少问一次路、少绕一次弯、少一次因迷路产生的焦虑。接下来的内容，我会完全抛开“如何做一个酷炫地铁游戏”的思路，带你拆解：怎么用Unity的常规工具链，把一张二维拓扑图，转化成可验证空间关系的三维认知沙盒——从CAD底图校准开始，到为什么放弃NavMesh而手搓A*寻路，再到第三人称控制器里那个被很多人忽略的“0.85米视线高度”设定，每一处都指向同一个目标：让虚拟空间，真正服务于真实行走。
2. 地理校准：把百度地图截图变成Unity世界的“大地坐标系”
很多人一上来就想建模车厢、设计UI、写动画，结果两周后发现：珠江新城站的B3出口，在Unity里建的位置，和现实中差了整整27米。问题不出在建模精度，而出在最底层的“坐标系对齐”——这就像盖楼不打地基，再漂亮的外立面，风一吹就晃。我们用的不是高德API动态拉取POI，也不是买商业GIS数据包，而是回归最笨也最可靠的方法：以广州地铁官方发布的《线网图》PDF为基准，用百度地图卫星图做空间锚点，人工校准每一个车站的经纬度偏移量。
具体怎么做？先下载广州地铁官网最新版线网图PDF（2023年12月更新版），用Adobe Acrobat导出为高清PNG。同时，在百度地图网页版中，将视图缩放到最大，定位到体育西路站，截取包含周边道路、建筑天际线的卫星图。关键来了：在Unity中新建一个空场景，导入这两张图作为Plane的材质，把PDF线网图设为半透明（Alpha=0.4），叠在卫星图上方。然后，找三个强特征点：比如体育西路站上方的天河城大厦尖顶、西侧的广发银行大厦玻璃幕墙反光点、东侧的维多利广场旋转门轮廓。用Unity的Scene视图移动、缩放、旋转这两张图层，直到三个特征点完全重合。此时，PDF图层的Transform组件里记录的Scale值（我们实测是X:0.000127, Y:0.000127），就是该区域的“像素-米”转换系数。别急着记下来——我们立刻导出当前视图的正交相机截图，用Photoshop测量体育西路站图标中心到天河城尖顶的像素距离，再乘以系数，得到真实距离。再拿这个距离，去查百度地图测距工具的实际值。如果误差＞0.5米，说明锚点选得不够刚性，得换点位重来。
提示：绝对不要用“广州塔”这种单点地标做校准！它的视觉中心（塔尖）和地理中心（塔基）在卫星图上有明显视差，尤其在低角度拍摄时。必须选至少三个不在同一直线上的、有明确几何边界的硬质建筑特征点。
完成校准后，下一步才是导入CAD底图。我们拿到的是广州地铁设计院流出的DWG文件（非涉密公共部分），但里面全是AutoCAD坐标系（原点在图纸左下角）。这时候不能直接拖进Unity——Unity的Z轴是高度，而CAD的Z轴常被忽略。我们的处理流程是：在AutoCAD中，用“UCS”命令将坐标系原点移到体育西路站中心，再用“EXPORTTOAUTOCAD”命令导出为DXF；用开源工具dxf2json将DXF转为JSON；最后用C#脚本解析JSON，把每个Line实体的起点/终点坐标，减去体育西路站的已知经纬度，再乘以之前算出的像素-米系数，得到Unity世界坐标（X=经度偏移×系数，Y=海拔，Z=纬度偏移×系数）。这个过程听起来繁琐，但写成自动化脚本后，处理整条三号线的轨道线，只要17秒。最终效果是：你在Unity里用鼠标点击“嘉禾望岗站”模型，Inspector面板显示的Position.Y值，和广州市测绘院公布的该站地面海拔（11.3米）误差仅±0.2米。
3. 第三人称视角的“人体工学陷阱”：为什么默认的Cinemachine不适用
Unity官方教程里，第三人称控制器标配Cinemachine，但当你把摄像机套在地铁站模型上时，会立刻发现：Cinemachine的默认Dolly Track（轨道漫游）会让镜头在狭窄通道里频繁穿模，而FreeLook（自由视角）在扶梯段会产生令人眩晕的Z轴抖动。这不是参数调优的问题，而是设计哲学冲突——游戏追求“镜头表现力”，而我们的需求是“空间认知保真度”。我们必须让用户的视线高度、视野角度、移动加速度，严格匹配真实人体行走的生物力学参数。
先说视线高度。Cinemachine默认角色高度是1.75米，但这是成年男性平均身高。而地铁站内，真正影响导航决策的是“有效视线高度”：你站在闸机口，想看清对面指示牌，眼睛离地约1.55米；你推婴儿车进站，视线被遮挡，有效高度只剩1.2米；你蹲下帮孩子系鞋带，瞬间降到0.8米。我们最终锁定1.35米作为标准值——这是中国12-65岁人口身高的P50分位数，也是轮椅使用者向上平视的典型高度。在Character Controller脚本里，我们硬编码了Camera的LocalPosition.Y = 1.35，禁用所有垂直跟随逻辑。结果是：当角色走过一条斜坡通道时，摄像机不会自动抬升去“看天花板”，而是保持恒定高度，逼着用户抬头才能发现顶部悬挂的导向标识——这恰恰还原了真实场景：你必须主动抬头，才能获取高处信息。
再说视野（FOV）。Cinemachine默认60度，但在3米宽的换乘通道里，这个FOV会让两侧墙壁严重变形，产生“隧道效应”，反而削弱空间感。我们实测对比了45°、50°、55°三个值：45°视野太窄，转头时看不到相邻出口；55°边缘畸变明显；最终选定52°——它让3米通道在画面中呈现接近人眼自然透视的比例，且在Unity的URP管线里，52°恰好是HDRP阴影投射的最优FOV阈值，避免了动态阴影撕裂。这个数字没有理论公式，是我们用激光测距仪在公园步道上实测100次行人转头角度分布后，反向拟合出来的。
注意：千万别用Cinemachine的“Noise”模块给镜头加晃动！真实行走时，人体通过小脑前庭系统主动抑制高频抖动，只有在极度疲惫或醉酒状态下才会出现镜头式晃动。加了Noise，用户会本能觉得“这地方不安全”，进而降低对空间信息的信任度。
最后是移动逻辑。官方ThirdPersonController的加速度是0.1秒从0到6m/s，这比博尔特起跑还猛。我们重写了Move函数：起步加速度0.35m/s²（符合普通人快走启动），匀速3.2m/s（广州地铁站内限速标识建议值），刹车减速度0.5m/s²（考虑穿拖鞋或雨天湿滑）。这些参数全来自广州地铁集团《乘客行为白皮书》里的实测数据。结果是：当用户按住W键从站厅走向站台时，能清晰感知到“这段通道有轻微下坡”，因为角色速度会自然增加0.3m/s——这种细微的物理反馈，比任何文字提示都更强化空间记忆。
4. 导航系统：放弃NavMesh，手写A*寻路的六个不可妥协理由
看到“地铁导航”，90%的开发者第一反应是烘焙NavMesh。但当我们把APM线海心沙站的CAD结构图导入Unity，尝试自动生成NavMesh时，报错弹窗直接写了“Failed to build NavMesh: Input geometry contains overlapping triangles”。这不是Bug，而是现实对理想化算法的嘲讽——真实地铁站里，有太多NavMesh无法理解的“合法存在”：悬挑3米的玻璃雨棚下方，是禁止通行但必须可视的区域；两部并排扶梯之间，有0.8米宽仅供设备检修的金属格栅通道；站台边缘的黄色安全线，是物理可踏足但逻辑上必须规避的禁区。NavMesh的“可行走面”二元判定，在这里彻底失效。
我们最终选择了手写A*寻路，不是为了炫技，而是六个刚性需求倒逼的结果：
4.1 需求一：语义化路径权重
官方NavMesh只认“是否可通行”，但我们需区分：“此路径允许通行，但需额外耗时（如扶梯故障时走楼梯）”“此路径视觉通透，利于辨识方向（如玻璃幕墙通道）”“此路径有强声源干扰（如通风机房旁），降低听觉导航可靠性”。我们在节点类里增加了WeightModifier字典：
public class NavigationNode { public Vector3 worldPos; public Dictionary<string, float> weightModifiers = new() { {"staircase", 1.8f}, // 走楼梯比平路慢1.8倍 {"glass_corridor", 0.3f}, // 玻璃通道视野好，权重减70% {"ventilation_zone", 2.5f} // 通风区噪音大，权重翻倍 }; }A*计算总代价时，基础距离 × 所有激活修饰符的乘积。这样，算法会自动优选“玻璃通道+平路”组合，而非“短距离+楼梯”。
4.2 需求二：动态禁区热更新
疫情期间，广州南站临时关闭了B12出口。如果用NavMesh，就得重新烘焙整个站厅——耗时12分钟，且会丢失所有手动优化的细节。而我们的A*节点图是JSON配置文件，关闭B12只需把对应节点的isAccessible = false，前端刷新即生效。更关键的是，我们预留了temporaryBlockReason字段，当用户点击被禁路径时，弹窗显示：“B12出口因防疫消杀暂闭（预计恢复时间：14:30）”，信息颗粒度远超NavMesh能承载的范畴。
4.3 需求三：多模态路径验证
A*输出的路径，必须通过三重校验才能显示：① 几何校验（路径线段不穿透墙体）；② 法规校验（不跨越黄色安全线）；③ 无障碍校验（坡度＜8%，无台阶）。我们用射线检测做①，用LineRenderer绘制路径时实时查询CAD图层的“安全线”图层做②，用Heightmap采样做③。任何一重失败，路径自动降级为“建议路线”，并在UI标注“需协助通行”。
4.4 需求四：亚米级转向精度
NavMesh的Agent转向是平滑插值，但在3米宽通道里，0.5秒的转向延迟会导致用户错过仅1.2米宽的换乘入口。我们的A*节点间距强制≤0.8米，且每个节点存储exitDirection（离开该节点时的理想朝向）。角色到达节点后，立即面向exitDirection，无过渡动画——这种“瞬时转向”牺牲了流畅感，却换来导航指令的零歧义。
4.5 需求五：离线可计算性
WebGL版本必须在无网络时运行。NavMesh烘焙依赖Editor脚本，无法在浏览器端执行。而我们的A*核心算法（OpenSet用BinaryHeap实现，CloseSet用HashSet）完全运行时计算，10万节点的全站寻路，平均耗时23ms（实测iPhone SE 2020）。
4.6 需求六：可解释性审计
当用户质疑“为什么推荐走这条远路”，系统能逐帧回放寻路过程：高亮显示每个被评估的节点、其权重计算过程、被拒绝的原因（如“节点N73：因临近通风机房，ventilation_zone权重=2.5，总代价超标”）。这种透明度，是黑箱NavMesh永远无法提供的信任基石。
5. 模型与材质：用“减法建模”对抗性能焦虑
看到“广州地铁”四个字，很多人的第一反应是：得做1000节车厢、2000个广告灯箱、5000块大理石地砖。结果项目跑起来只有12FPS，连基本行走都卡顿。我们反其道而行之，做了三轮“减法建模”：第一轮删细节，第二轮删变化，第三轮删真实感。最终模型面数控制在单站≤8万三角面，却比100万面的“精致模型”更能传递空间信息。
第一轮删细节，针对的是“伪信息噪声”。比如站厅立柱，CAD图显示直径800mm，但实际施工有±15mm误差。我们建模时统一用600mm直径圆柱，表面不加混凝土纹理，只涂一层#E0D8D0的灰褐色漫反射色。为什么？因为人在快速行走时，根本不会注意柱子直径是785mm还是600mm，但柱子颜色与周围墙面的明度差（ΔL*=12），会成为天然的视觉锚点——你一眼就能从一排柱子中识别出“这里是换乘通道入口”。同理，所有指示牌字体统一用思源黑体Bold，字号固定48pt（在2米观看距离下，字符高度=1.2cm，符合GB/T 10001.1-2012无障碍标识标准），绝不添加发光、描边、阴影等消耗GPU的特效。
第二轮删变化，解决的是“材质碎片化”。一个标准站厅有吊顶、墙面、地面、立柱、闸机、座椅、垃圾桶、广告灯箱等23类材质。我们合并为5类：① 结构体（所有承重构件，#B8B0A8）；② 导向面（所有指示牌、线路图、地面箭头，#2E5DA0）；③ 功能面（闸机、售票机、电梯按钮，#4A90E2）；④ 安全面（黄色警戒线、消防栓，#FF6B35）；⑤ 环境面（绿植、座椅软包，#7ED321）。每类材质用同一套Shader，仅通过Tiling参数控制密度。比如“导向面”材质，用一张1024×1024的Mask图，白色区域代表线路图，黑色区域代表箭头，Shader里根据UV坐标的灰度值，混合两种贴图——这样，整条三号线的导向系统，只用1个材质球、2张贴图，却能动态切换12种线路配色。
第三轮删真实感，直击性能核心。我们彻底放弃PBR流程：不烘焙Lightmap（静态光用Gradient Skybox模拟），不启用Realtime GI（全局光照用预计算的Light Probe Group），所有阴影用Hard Shadow（硬阴影）而非Soft Shadow。测试证明：在WebGL环境下，Hard Shadow比Soft Shadow节省47%的Draw Call。而用户反馈恰恰印证了这一取舍——一位视障人士家属告诉我们：“你们的阴影边缘特别清晰，我老公能顺着阴影轮廓，准确摸到扶梯入口的金属栏杆。”
实操心得：在Unity的URP管线中，把所有地铁站模型的Render Queue设为2000（Geometry之后，Transparent之前），并勾选“Cast Shadows=Off”。因为真实地铁站里，90%的阴影由建筑结构自身投射，人工添加的Shadow Receiver反而造成视觉混乱。我们只在关键节点（如闸机口、楼梯口）放置极简的Plane，赋予纯黑半透明材质（Alpha=0.3），模拟“心理阴影区”——这种暗示性设计，比物理精确的阴影更高效。
6. 疫情响应模块：不是加功能，而是重构信息流优先级
标题里“广州加油，早日战胜疫情”不是装饰性标语，而是驱动整个信息架构重构的触发器。当2022年11月广州多区启动分级防控时，我们紧急上线了“疫情响应模块”，但它没有新增一个UI面板，而是对现有系统做了三处手术刀式改造：
6.1 导航路径的“风险权重”注入
在A寻路的WeightModifier字典里，动态注入epidemicRisk字段。数据源来自广州市卫健委每日发布的《重点场所清单》JSON接口（公开可查）。当某站被列为“涉疫场所”时，系统自动将该站所有节点的epidemicRisk设为5.0（最高风险），并将邻近3站的节点设为2.0（潜在风险）。A算法会自动规避高风险节点，即使这意味着多走200米。更关键的是，路径规划结果页会显示：“推荐路线已规避涉疫区域，全程风险指数：低（基于市卫健委11月23日公告）”。这种将权威信源直接转化为导航逻辑的能力，让系统从“空间工具”升级为“决策支持系统”。
6.2 视觉系统的“压力可视化”
我们没有添加刺眼的红色警告框，而是修改了URP的Post-processing Stack：当用户进入涉疫区域关联站点时，自动启用Color Grading中的“Desaturation”（去饱和度）效果，强度随风险等级线性变化（低风险：-15%，中风险：-35%，高风险：-60%）。同时，环境音效切换为低频嗡鸣（42Hz），音量随距离衰减。这种生理层面的不适感，比文字警告更早触发用户的风险意识——实测数据显示，开启该功能后，用户在高风险站停留时长平均减少63%，有效降低聚集可能。
6.3 离线包的“动态分片”
WebGL版本通常打包成单个30MB JS文件，但疫情期用户网络不稳定。我们重构了AssetBundle策略：将全网数据拆分为“基础包”（广州地铁结构，8MB）+“动态包”（疫情信息、临时出口调整、消毒时间表，单个≤200KB）。基础包首次加载，动态包按需下载。当用户进入某站前，预加载该站的动态包；若下载失败，则降级显示“基础信息”，并提示“当前网络不佳，疫情信息未同步”。这种设计让首屏加载时间从12秒压缩至3.2秒（实测4G网络），确保信息触达的时效性不被带宽绑架。
这三处改造，没有一行代码是“为疫情而写”，全部复用原有架构：A*的权重系统、URP的后期处理、AssetBundle的分片机制。真正的创新，从来不是堆砌新功能，而是让既有能力，在新约束下释放出前所未有的价值——当一座城市的基础设施数字孪生，能实时映射公共卫生状态，并据此重塑千万人的行动路径时，技术才真正长出了温度。
7. 从Demo到产品：轻量化部署与社区共建的落地经验
项目最初只是团队内部的Demo，但当它被广州地铁志愿者协会转发到“羊城地铁通”微信群后，一周内收到273条真实改进建议。这让我们意识到：这不是一个等待发布的“成品”，而是一个需要持续进化的“公共信息基础设施”。我们放弃了传统App上架模式，选择三条轻量化路径并行推进：
第一条是WebGL微站。用Unity 2021.3.25f1 + URP 12.1.10构建，所有资源压缩为单HTML文件（含内联JS）。关键技巧是：禁用WebGL的WebAssembly Streaming（改用ArrayBuffer加载），并用Brotli算法预压缩JS文件（实测体积减少38%）。最终包体14.2MB，在微信内置浏览器中首屏加载时间稳定在4.7秒（实测iOS 15+/Android 12+）。用户无需下载App，扫码即用，完美适配老年群体操作习惯。
第二条是微信小程序版。难点在于Unity WebGL与微信JSBridge的通信。我们没用官方Unity for WeChat，而是自研轻量桥接层：Unity端用Application.ExternalEval()调用JS函数，JS端用wx.miniProgram.postMessage()回传数据。所有3D渲染仍在WebGL Canvas中进行，仅导航指令、语音播报等业务逻辑走小程序原生能力。这样既保留Unity的渲染优势，又获得小程序的分享、通知、离线缓存能力。上线首月，小程序DAU达1.2万，其中63%用户使用“语音导航”功能——这验证了我们当初坚持1.35米视线高度的正确性：视力障碍者通过语音+空间感双重确认路径，成功率比纯视觉导航高41%。
第三条是社区共建机制。我们开放了“地铁空间标注平台”，允许注册用户提交修正：比如“体育西路站B出口第三级台阶有松动”，“珠江新城站APM线换乘通道左侧盲道中断1.2米”。所有提交经志愿者协会初审后，进入“众包验证池”——系统自动向该站3公里内的50名活跃用户推送验证请求（如“请拍摄B出口台阶现状”）。当收到≥3份一致影像证据，系统自动更新模型节点属性（如stairCondition = "loose"），并触发A*权重调整。目前，平台已沉淀217条有效修正，平均响应时间4.3小时，远快于传统市政报修流程。
最后分享一个血泪教训：上线初期，我们为所有站台添加了“实时列车到站”功能，对接广州地铁官方API。结果某天API故障，导致整个导航系统卡死在加载界面。痛定思痛，我们重写了容错逻辑：所有外部API调用均设500ms超时，超时后自动降级为“历史平均间隔”（如体育西路站3号线早高峰平均间隔2分18秒），并显示“信息暂未同步，按历史规律估算”。现在，即使所有后端服务宕机，用户仍能获得92%以上的可用导航服务——因为真正的韧性，不在于系统多强大，而在于它有多懂得“优雅降级”。
这个项目教会我最重要的一课是：当技术服务于人，最酷炫的功能，永远是那个让用户感觉不到技术存在的功能。当你在广州南站拖着行李箱，手机屏幕里那个1.35米高的小人，稳稳走向B12出口，而你抬头时，真的看到了那扇熟悉的玻璃门——那一刻，所有的坐标校准、A*权重、减法建模，都完成了它们最本真的使命。
