客户端架构与引擎体系

Category

client 树总览。覆盖：技术栈与引擎（01）、前后端边界（02）、资源系统（03）、脚本与 ECS（04）、AI 场景（05），交互与输入横向节点，以及 web 子树（web/01–06）与 engines 子树（engines/01–03）。

Definition

很多团队在服务端问题上容易进入“系统工程”视角，到了客户端却退回成“把 UI、角色和特效塞进引擎里”。这是一个很常见的误判。客户端并不是单纯的表现层，它本身就是一个长期运行的复杂系统，要同时承担输入、渲染、资源调度、脚本运行、网络交互、平台接入、性能适配、包体控制和版本演进。

客户端一旦复杂起来，很多线上问题都不再能简单归因为“美术资源太大”或“引擎不行”。真正暴露出来的通常是更硬的工程问题：

• 引擎能力和项目层架构到底怎么分工
• 哪些逻辑该放客户端，哪些必须交回服务端裁决
• 资源、代码、脚本和配置怎样一起组成可演进的运行时
• 性能、包体、热更和多端适配为什么经常互相拉扯
• AI 和自动化工具进入客户端链路后，边界和责任如何定义

这一章不是按引擎产品功能表来写，而是把客户端当成一套独立运行时系统来讨论。重点不在于某种技术是否“先进”，而在于它会把复杂度放到哪里，会如何影响版本节奏、团队协作和线上故障形态。

Related

关系链：责任划分（01）→ 前后端边界（02）→ 资源供应链（03）→ 脚本与 ECS（04）→ AI 场景（05）；Web 侧接 web 子树，选型的商业与团队维度接 engines 子树。下游：server 树（边界与同步的另一半）、production 树（构建与发布）。

Reference

节点清单见下节；教程侧同题对照见第 03 讲《前端引擎与客户端》。

本章文章

• 客户端技术栈与引擎：先讨论引擎到底解决什么问题，项目层框架又该承担什么，避免把所有复杂度都推给引擎或插件。
• 前后端边界与网络层：梳理客户端与服务端之间真正难的边界问题，包括裁决权、预测、回滚、断线和状态恢复。
• 资源系统与工具链：把包体、分包、热更、资源依赖、构建流程和内容生产效率放回同一条工程链里讨论。
• 脚本语言与 ECS：讨论脚本层和数据驱动架构为什么会出现在客户端，以及它们分别适合解决什么问题。
• AI 在客户端与游戏系统中的应用场景：把 AI 放回真实工程语境里看，讨论它适合提升什么效率，不适合替代什么边界。
• 交互与输入：把设备事件归一化成可复算的意图，输入映射是数据不是代码，手感的一半诞生在输入管线的延迟账里。