总论与方法论

Category

industry / methodology 子树总览。覆盖：知识地图（01）、三输入（02）、五步分析法（03）、核心取舍（04）、四条边界（05）、生命周期（06）、经验沉淀（07）。

Definition

游戏开发里的大多数技术分歧，表面上在争论引擎、语言、数据库、同步方案，实质上是在争论项目到底是什么问题。只要问题模型判断错了，后面的技术细节做得越精致，返工成本反而越高。

这一章不讲某个框架怎么用，而是先建立一套分析顺序：先看玩家在游戏里反复做什么，再看哪些状态必须共享、必须实时、必须长期保存，然后再看这些约束会把系统推向什么样的架构。只有顺序对了，后面的网络、战斗、服务拆分、数据和运维章节才有稳定前提。

这一章主要解决六类常见失误：

• 立项时先谈技术栈，最后才发现玩法根本不需要那套复杂系统。
• 把不同类型游戏混成一种问题，照搬别的项目架构。
• 只看单机开发效率，不看上线后的版本、运营、风控和恢复成本。
• 客户端、服务端、平台和运营边界划分不清，导致责任无法落地。
• 用互联网后端经验直接套游戏项目，忽略局内实时性和版本窗口。
• 团队复盘只记住结论，不沉淀触发条件、代价和适用边界。

如果读完本章只能记住一句话，那就是：游戏架构不是从中间件开始设计的，而是从玩法循环、状态归属和生命周期约束一路推出来的。

Related

关系链：地图（01）→ 三输入（02）→ 分析法（03）→ 取舍（04）→ 边界（05）→ 生命周期（06）→ 沉淀（07）。下游：models 子树（类型问题模型化）、树根 industry 总览。

Reference

节点清单见下节。

本章文章

• 游戏开发知识地图：先把游戏项目里真正会反复出现的问题域拆开，避免一开始就陷入名词堆。
• 游戏类型、平台与商业形态：说明玩法类型、发布平台和商业模式怎样共同塑造系统约束。
• 从玩法到架构的分析方法：给出一条从核心玩法推到技术方案的分析路径。
• 游戏后端设计的核心取舍：集中讨论权威性、实时性、复杂度、成本之间的基本矛盾。
• 客户端、服务端、平台与运营的边界：把责任划分讲清楚，减少长期扯皮和系统漂移。
• 游戏项目生命周期与团队协作：解释同一个项目在不同阶段为什么需要不同工程重点。
• 如何系统化积累游戏开发经验：把经验从“个人印象”变成可复用的团队资产。