1.2 游戏类型、平台与商业形态

这一节学习如何按技术特征对游戏分类，不同类型的技术挑战差异巨大。

为什么需要分类？

很多开发者会犯一个错误：用同一套技术方案套所有游戏。

错误案例：

// 开发者A：我做了3年卡牌游戏，现在要做FPS
// → 直接复用卡牌游戏的WebSocket长连接架构
// → 结果：FPS延迟300ms，玩家全部流失

// 问题：卡牌游戏能容忍500ms延迟，FPS只能容忍100ms
// → 技术选型完全不同！

正确的做法：

1. 先识别游戏类型
2. 确定技术约束（延迟、并发、一致性）
3. 选择合适的技术方案

游戏分类的三个维度

我们按技术特征而不是玩法来分类游戏：

维度1：实时性（Real-time）

实时性决定了网络架构和同步模型。

技术决策树：

延迟要求 > 500ms?
├─ 是 → HTTP轮询，WebSocket长连接
└─ 否 → 延迟要求 > 100ms?
    ├─ 是 → WebSocket，状态同步
    └─ 否 → UDP/KCP，帧同步

案例对比：

炉石传说（卡牌）：

• 网络协议：HTTPS（HTTP/1.1）
• 同步模型：请求-响应
• 延迟容忍：500ms+
• 架构：无状态REST API

英雄联盟（MOBA）：

• 网络协议：自定义UDP协议
• 同步模型：状态同步+客户端预测
• 延迟容忍：<100ms
• 架构：房间服务器，权威判定

街霸（格斗）：

• 网络协议：本地对战，或Rollback Netcode
• 同步模型：Lockstep帧同步
• 延迟容忍：<50ms
• 架构：确定性计算，帧数据

维度2：在线模式（Online Mode）

在线模式决定了服务器架构和数据持久化策略。

技术决策差异：

单机游戏（如《原神》单机模式）：

// 无服务器架构
type SinglePlayerGame struct {
    localDB *SQLiteDB  // 本地数据库
    saveMgr *SaveManager  // 本地存档
}

// 技术挑战：本地存档防篡改

弱联网游戏（如《皇室战争》）：

// 服务器只存储：玩家账号、卡组、段位
type BackendServer struct {
    accountDB  *Database  // 账号数据
    matchmaking *MatchmakingSystem  // 匹配
    leaderboard *Leaderboard  // 排行榜
}

// 游戏逻辑在客户端，服务器只校验结果

房间制游戏（如《王者荣耀》）：

// Lobby架构
type LobbyArchitecture struct {
    lobbyServer    *LobbyServer     // 匹配、房间管理
    gameServers    []*GameServer    // 游戏房间（无状态）
}

// 技术挑战：
// 1. 房间服务器调度（负载均衡）
// 2. 跨房间通信（世界频道、好友）
// 3. 房间状态迁移（服务器维护）

强联网游戏（如《魔兽世界》）：

// 分布式世界架构
type MMOWorld struct {
    loginServer    *LoginServer     // 登录服
    worldServers   []*WorldServer   // 游戏世界（分片）
    dbCluster      *DatabaseCluster // 数据库集群
    crossServerMgr *CrossServerMgr  // 跨服管理
}

// 技术挑战：
// 1. 分布式事务（跨服交易）
// 2. 数据一致性（副本进度、世界BOSS）
// 3. 服务器扩容（动态分片）

维度3：经济系统（Economy System）

经济系统的复杂度决定了安全要求和数据持久化策略。

技术决策差异：

无经济游戏（如《英雄联盟》）：

// 无复杂经济系统
type EconomySystem struct {
    // 只有皮肤购买，无玩家间交易
    skinStore *SkinStore  // 商城
}

// 技术挑战：支付安全

复杂经济游戏（如《梦幻西游》）：

// 复杂的经济系统
type ComplexEconomy struct {
    currencies  map[string]*Currency  // 多货币（金币、银币、元宝）
    market      *PlayerMarket        // 玩家交易市场
    auction     *AuctionSystem       // 拍卖行
    economyLog  *EconomyMonitor      // 经济监控
}

// 技术挑战：
// 1. 刷单检测（异常交易识别）
// 2. 经济平衡（通货膨胀控制）
// 3. 反外挂（脚本挂机）

平台差异

平台1：手游（Mobile）

技术约束：

• 电池消耗：CPU/GPU使用受限
• 网络不稳定：4G/5G/WiFi切换
• 内存限制：2-4GB（相比PC的16GB+）
• 存储限制：游戏包体<100MB，首更<500MB

架构影响：

// 手游优化策略
type MobileOptimization struct {
    // 1. 资源压缩
    assetCompression string  // Texture ASTC，Mesh压缩

    // 2. 网络优化
    networkOpt string  // 断线重连、状态缓存

    // 3. 性能优化
    perfOpt string  // LOD、对象池、GPU Instancing

    // 4. 省电优化
    powerSave string  // 降低帧率、减少特效
}

// 手游特有挑战：
// 1. 弱网优化（第3.7节）
// 2. 省电优化（第5.4节）
// 3. 包体优化（第10.3节）

案例：《王者荣耀》手游优化

• 网络协议：自定义UDP协议，弱网优化
• 图形优化：动态分辨率、LOD
• 省电模式：降低特效、降低帧率
• 包体优化：资源分包、热更新

平台2：端游（PC）

技术优势：

• 性能强：CPU/GPU无限制
• 内存大：16GB+可用
• 存储大：无包体限制
• 网络稳定：有线网络

架构影响：

// 端游优化策略
type PCOptimization struct {
    // 1. 高画质
    highQuality bool  // 4K分辨率、高画质

    // 2. 复杂特性
    complexFeatures bool  // 更复杂的AI、物理

    // 3. 模组支持
    modSupport bool  // 社区内容
}

// 端游特有挑战：
// 1. 反外挂（第20章）
// 2. 模组系统（第10章）
// 3. 多平台兼容（Windows/Mac）

平台3：主机游戏（Console）

技术约束：

• 认证严格：Sony/Microsoft/Nintendo审核
• 更新困难：补丁需要审核
• 性能固定：硬件统一，优化目标明确
• 手柄优化：必须支持手柄操作

架构影响：

// 主机特有考虑
type ConsoleConsiderations struct {
    // 1. 手柄支持
    controllerSupport bool  // 必须支持

    // 2. 离线模式
    offlineMode bool  // 不强制联网

    // 3. 存档管理
    saveCloud bool  // 云存档

    // 4. 审核合规
    compliance bool  // 平台规则
}

// 主机特有挑战：
// 1. 平台审核（第20.3节）
// 2. 手柄操作适配
// 3. 离线模式支持

平台4：小游戏（Mini Game）

技术约束：

• 包体限制：<4MB（微信小游戏）
• 内存限制：<200MB
• 加载时间：<3秒
• API限制：受限的Web API

架构影响：

// 小游戏优化策略
type MiniGameOptimization struct {
    // 1. 极致包体优化
    ultraCompression bool  // 所有资源压缩

    // 2. 代码分割
    codeSplitting bool  // 按需加载

    // 3. 远程资源
    remoteAssets bool  // CDN加载资源

    // 4. 降级方案
    fallback bool  // 低端机降级
}

// 小游戏特有挑战：
// 1. 包体极限优化（第10.3节）
// 2. 加载速度优化
// 3. API限制绕过

案例：《跳一跳》（微信小游戏）

• 包体：1.5MB
• 加载时间：1.5秒
• 优化：纯Canvas渲染，无3D引擎
• 网络架构：极简HTTP API

商业模式差异

模式1：买断制（Paid Games）

特点：一次性购买，无后续付费

技术影响：

// 买断制游戏架构
type PaidGameArchitecture struct {
    // 1. 无需复杂的防刷单
    antiFraud string  // 简单校验即可

    // 2. 可以支持离线模式
    offlineMode bool  // 单机可玩

    // 3. 无需复杂的商业化系统
    monetization string  // 简单DLC
}

// 案例：《Minecraft》
// - 支持离线模式
// - 无复杂经济系统
// - 社区Mod支持

模式2：免费+内购（F2P - Free to Play）

特点：免费下载，内购付费

技术影响：

// F2P游戏架构
type F2PArchitecture struct {
    // 1. 复杂的付费系统
    paymentSystem *PaymentSystem  // 多渠道支付

    // 2. 经济平衡系统
    economyBalance *EconomyBalancer  // 防通货膨胀

    // 3. 留存分析
    analytics *AnalyticsSystem  // 埋点、BI

    // 4. 防刷单
    antiFraud *FraudDetection  // 异常交易检测
}

// 案例：《原神》
// - 复杂的抽卡系统
// - 多货币经济（原石、创世结晶、摩拉）
// - 留存分析（第16章）
// - 防刷单系统（第20章）

模式3：订阅制（Subscription）

特点：月费/年费，持续付费

技术影响：

// 订阅制游戏架构
type SubscriptionArchitecture struct {
    // 1. 订阅管理
    subscriptionMgr *SubscriptionManager  // 续费、过期

    // 2. 权限系统
    permissionSystem *PermissionSystem  // VIP功能

    // 3. 计费系统
    billingSystem *BillingSystem  // 账单管理
}

// 案例：《魔兽世界》
// - 月费订阅
// - 游戏时间计算
// - 订阅状态管理
// - 账单系统

模式4：广告变现（Ad-based）

特点：免费+广告

技术影响：

// 广告变现游戏架构
type AdBasedArchitecture struct {
    // 1. 广告SDK集成
    adSDK *AdSDK  // 多平台广告SDK

    // 2. 广告频率控制
    adFrequency *FrequencyController  // 防打扰

    // 3. 数据分析
    analytics *AnalyticsSystem  // 广告转化率
}

// 案例：《消灭星星》
// - 激励视频广告
// - 插屏广告
// - Banner广告
// - 广告收益分析

组合分析

案例1：《王者荣耀》

分类：

• 实时性：强实时（<100ms）
• 在线模式：房间制
• 经济系统：单一货币+点券
• 平台：手游
• 商业模式：F2P+皮肤

技术栈决策：

// 架构决策
type HonorOfKings struct {
    // 1. 网络：UDP + 自定义协议（第3章）
    network string  // 低延迟优先

    // 2. 同步：状态同步 + 客户端预测（第4章）
    sync string  // 权威服务器 + 预测

    // 3. 架构：Lobby + 房间服务器（第9章）
    architecture string  // 匹配服 + 游戏服

    // 4. 经济：简单皮肤购买（第15章）
    economy string  // 无玩家交易，简单

    // 5. 平台优化：弱网优化 + 省电（第3.7节）
    platform string  // 手游特有优化
}

案例2：《梦幻西游》手游

分类：

• 实时性：弱实时（<500ms）
• 在线模式：强联网（MMORPG）
• 经济系统：复杂经济+玩家交易
• 平台：手游
• 商业模式：F2P+多货币

技术栈决策：

// 架构决策
type FantasyWestwardJourney struct {
    // 1. 网络：TCP长连接（第3章）
    network string  // 可靠性优先

    // 2. 同步：状态同步（第4章）
    sync string  // 服务器权威

    // 3. 架构：分布式世界（第6章）
    architecture string  // 多服务器架构

    // 4. 经济：复杂交易系统（第15章）
    economy string  // 拍卖行、摆摊

    // 5. 数据：分库分表（第13章）
    database string  // 海量数据存储
}

案例3：《原神》

分类：

• 实时性：弱实时（单机）+ 强实时（多人）
• 在线模式：弱联网（单机）+ 房间制（多人）
• 经济系统：复杂经济+抽卡
• 平台：全平台（PC+主机+手游）
• 商业模式：F2P+抽卡

技术栈决策：

// 架构决策
type GenshinImpact struct {
    // 1. 网络：HTTP（单机）+ UDP（多人）（第3章）
    network string  // 混合架构

    // 2. 同步：无同步（单机）+ 状态同步（多人）（第4章）
    sync string  // 混合同步

    // 3. 架构：云存档 + 多人副本（第9章）
    architecture string  // 混合架构

    // 4. 经济：抽卡系统（第15章）
    economy string  // gacha系统

    // 5. 平台：跨平台适配（第10章）
    platform string  // 多平台优化
}

分类决策树

下面是一个完整的分类决策树，帮助你识别游戏类型：

graph TD
    A[开始：你的游戏是什么？] --> B{实时性要求}
    B -->|回合制| C[回合制游戏]
    B -->|延迟<500ms| D[弱实时游戏]
    B -->|延迟<100ms| E[强实时游戏]
    B -->|延迟<50ms| F[超实时游戏]

    C --> G{在线模式}
    D --> G
    E --> G
    F --> G

    G -->|单机| H[单机游戏]
    G -->|弱联网| I[弱联网游戏]
    G -->|房间制| J[房间制游戏]
    G -->|持久化世界| K[MMO游戏]

    H --> L{经济系统}
    I --> L
    J --> L
    K --> L

    L -->|无经济| M[无经济游戏]
    L -->|单一货币| N[简单经济游戏]
    L -->|多货币+交易| O[复杂经济游戏]

    M --> P{平台}
    N --> P
    O --> P

    P -->|手游| Q[手游]
    P -->|端游| R[端游]
    P -->|主机| S[主机]
    P -->|小游戏| T[小游戏]

    Q --> U{商业模式}
    R --> U
    S --> U
    T --> U

    U -->|买断| V[买断制]
    U -->|F2P+内购| W[F2P游戏]
    U -->|订阅| X[订阅制]
    U -->|广告| Y[广告变现]

小结

这一节我们学习了：

1. 三个分类维度：实时性、在线模式、经济系统
2. 平台差异：手游、端游、主机、小游戏的约束
3. 商业模式：买断、F2P、订阅、广告的技术影响

关键要点：

• 游戏类型决定了技术选型
• 不能用同一套技术方案套所有游戏
• 先识别类型，再选择技术方案

实战建议： 在开始任何游戏项目前，先回答这三个问题：

1. 我的游戏实时性要求是什么？
2. 我的游戏是在线模式是什么？
3. 我的游戏经济系统有多复杂？

下一节（1.3）我们将学习：从玩法到架构的分析方法，这是最核心的方法论。