游戏与建模的领域对象分析

游戏和建模（CAD/绘图/场景）的领域对象分析和一般软件是两条不同的线：一般软件的对象来自「用户要完成什么业务流程」，游戏/建模的对象来自「这个世界里有什么东西、什么规则」。分析游戏，就是在分析一个允许玩家行动的世界的结构；分析建模，就是在分析一个要被描述的场景的结构。

一、从一般软件到游戏：对象来源变了

一般软件问：

1 2	「用户要通过这个软件完成什么任务？」 → 对象：图片、订单、进程、项目

游戏问的是完全不同的问题：

1 2	「这个世界里有什么东西？它们遵循什么规则？」 → 对象：玩家、敌人、道具、地形、关卡

以闯关游戏为例，领域对象不是从「用户任务」来的，而是从世界结构来的：

Game
├── Player       玩家（可控制的实体）
├── Scene        场景
│    ├── Background 背景
│    ├── Terrain    地形
│    ├── Obstacle   障碍
│    └── Object     物体
├── Enemy        敌人
├── Item         道具
├── Camera       摄像机
├── UI
└── GameManager  游戏流程控制

这就是游戏领域对象分析的第一步：列出这个世界的实体。

二、世界实体 → 属性、状态、关系

和一般软件一样，每个对象要补属性、状态、关系，但内容完全是世界性的：

Player（玩家）
 ├── 属性：位置、速度、动画、生命值
 ├── 关系：与障碍物碰撞、拾取道具、被敌人攻击
 └── 状态：Idle → Run → Jump → Dead

Enemy（敌人）
 ├── 属性：位置、巡逻范围、攻击力、AI 状态
 ├── 关系：追踪玩家、触发事件
 └── 状态：Patrol → Chase → Attack → Dead

Item（道具）
 ├── 属性：类型、效果、位置
 └── 关系：被玩家拾取 → 触发效果

关卡也是对象：

1
2
3

Level（关卡）
 ├── 属性：难度、目标、敌人配置、道具配置
 └── 状态：Locked → Available → Completed

三、游戏对象分析的独特之处：规则驱动

一般软件的对象由「业务规则」驱动，游戏的对象由「世界规则 + 玩家行动」驱动：

一般软件：订单有状态机（待支付→已支付→发货）
  规则来自业务约定

游戏：敌人有 AI 状态机（巡逻→追击→攻击）
  规则来自设计者定义的「世界如何运转」

游戏分析还有一个一般软件没有的维度——玩家：

1
2
3

一般软件：用户是软件的使用者，不在软件内部
游戏：玩家是世界的参与者，玩家本身是领域对象
  → Player 对象：位置、状态、能力、与世界的交互

四、建模：和游戏同一条线

建模（CAD、绘图、场景设计）和游戏是同一条线——都在分析「一个要被描述的世界/场景的结构」：

人物建模：
  领域对象：头、躯干、四肢、服装、表情
  → 每个对象有几何、比例、位置、姿态
  → 对象之间有空间关系（头在躯干上方，手臂接肩膀）

场景建模：
  领域对象：地面、建筑、树木、天空、光源、摄像机
  → 对象有几何、材质、光照属性
  → 对象之间有空间布局关系

AI 绘图领域模型：
  领域对象：人物、树木、建筑
  → 实体 → 属性 → 空间关系 → 几何 → 像素

共同点：

游戏和建模都是「分析一个世界的结构」
  → 对象 = 世界里的实体
  → 属性 = 实体的特征（几何/状态/能力）
  → 关系 = 实体之间的空间/逻辑连接

五、游戏对象 → 数据结构/组件的落地

游戏对象分析出来后，落地方式有两派（详见游戏系统论的 ECS 部分）：

传统 OOP：对象 = 类
  Player 类：位置、速度、动画、碰撞 全包在一个类里

ECS：对象 = ID，属性拆成组件
  Entity: 玩家
  Position / Velocity / Sprite / Health 是独立组件
  System 负责处理特定组件组合

但无论怎么落地，领域对象分析是第一步：

领域对象分析（本线）
  玩家、敌人、道具、地形 ← 世界结构
      ↓
落地选择
  OOP：对象→类
  ECS：对象→Entity + Component + System
      ↓
数据结构（Domain 层）
  PlayerData / EnemyData / 关卡数据

六、和一般软件线的分界总结

维度	一般软件	游戏 / 建模
分析起点	用户要完成什么任务	世界有什么、规则是什么
对象	业务实体（图片/订单/进程）	世界实体（玩家/敌人/建筑）
玩家/用户	使用者，在系统外	参与者，在系统内（Player 是对象）
规则来源	业务约定	设计者定义的世界规则
落地	类/struct + Service	OOP 类或 ECS 组件系统

七、和其他线的关系

游戏/建模对象分析 → 领域模型
  先挖出世界实体，再建完整领域模型（属性+关系+规则+状态）

游戏/建模对象分析 → 游戏系统论
  游戏系统论讲游戏从零演化 + 世界建模
  本线讲「世界建模」里对象怎么分析出来

游戏/建模对象分析 → 数据结构
  世界实体 → Domain 数据（PlayerData/EnemyData/关卡配置）

游戏/建模对象分析 → 认知与语言主题（09，01 认知语言智能）
  语言 → 领域模型（人物/场景/几何/风格）→ 绘制器
  建模对象分析就是这条链「领域模型」的构建方法

收束

游戏/建模的对象来自世界结构，不是用户任务
  世界实体：玩家、敌人、道具、地形、关卡
  每个对象：属性 + 状态 + 关系

游戏独有的维度：玩家是世界的一部分（Player 是领域对象）
规则来自设计者定义的「世界如何运转」

建模与游戏同一条线：都在分析世界的结构
  人物：头/躯干/四肢/服装 + 几何比例 + 空间关系
  场景：地面/建筑/树木/光源 + 布局

落地：OOP（对象→类）或 ECS（对象→Entity+Component+System）
  无论哪种，领域对象分析都是第一步

先分析世界，再落地成程序。 游戏和建模的对象分析，起点永远是「这个世界里有什么，它如何运转」。