公会/战队系统

概述

公会是玩家社交的"组织层"：把一群玩家绑成一个集体，提供集体目标（领地、任务、活动）与集体荣誉（排行榜）。公会系统的难点在成员与角色权限管理、集体任务进度、以及解散/转移时的数据一致性。本文设计完整的公会系统：创建/加入/退出/解散、领地/任务/活动、权限体系、公会排行榜。

---

一、公会模型

1.1 核心实体

Guild（公会）：
  guildId、名称、徽章、简介
  等级、经验、活跃度
  创建者、当前会长
  人数、上限
  领地/公告/活动进度

GuildMember（成员）：
  guildId + playerId
  role（会长/长老/成员）
  joinTime、贡献、活跃
  PRIMARY KEY(guildId, playerId)

1.2 公会属性

属性	说明
等级	由经验/活跃提升，解锁容量与功能
活跃度	成员贡献汇总，驱动公会活动
人数上限	等级解锁（10-100+）
徽章/名称	创建设定，改名有冷却

公会数据存储：
  公会表 + 成员表（player_id 索引）
  公会数据量小 → 单表即可
  成员列表按需分页

---

二、生命周期

2.1 创建公会

流程：
  1. 玩家创建（校验：等级、付费/道具、无公会）
  2. 生成公会（唯一名称校验）
  3. 创建者成为会长
  4. 设置基本配置（徽章、简介、加入方式）

加入方式：
  自由加入（无需审批）
  审批加入（需管理员同意）
  邀请加入（凭邀请）
  按运营策略配置

2.2 加入与退出

加入：
  校验（无公会、人数未满、未被拉黑）
  审批模式走申请流程
  加入 → 写入成员 → 通知公会频道

退出：
  主动退出 → 移除成员（会长转移或解散）
  被踢出 → 管理员操作
  退出后：个人数据保留，公会贡献清空（按规则）

2.3 解散与会长转移

会长离开/长期离线：
  转移给副手/活跃长老（自动）
  或解散（需确认流程）

解散流程：
  通知全体成员（宽限期）
  成员释放 → 公会数据归档
  公会活动/任务结算处理

防滥用：
  解散有冷却/确认
  解散时公会资产处理明确（领地被回收等）

---

三、权限体系

3.1 角色与权限

角色	权限
会长	全部：解散、踢人、任命、公告、审批
长老	踢人、审批、公告（部分）
成员	发言、参与活动

权限模型：
  角色 → 权限位集合
  操作时校验角色权限
  权限表可配置（运营扩展）

权限实现：
  enum Permission { KICK, APPROVE, NOTICE, APPOINT, DISSOLVE }
  rolePermissions: Map<Role, Set<Permission>>
  校验：hasPermission(member, KICK)

public class GuildAuthService {

    private static final Map<Role, Set<Permission>> ROLE_PERMS = Map.of(
            Role.LEADER, EnumSet.allOf(Permission.class),
            Role.ELDER, EnumSet.of(Permission.KICK, Permission.APPROVE, Permission.NOTICE),
            Role.MEMBER, Set.of()
    );

    public boolean can(long playerId, Guild guild, Permission perm) {
        GuildMember m = guild.member(playerId);
        return m != null && ROLE_PERMS.get(m.getRole()).contains(perm);
    }
}

任命规则：
  任命长老/副手：会长
  逐级降权：高权限者操作
  操作审计：关键操作留日志

---

四、公会领地/任务/活动

4.1 公会领地

领地概念：
  公会专属场景/功能区域（据点、城堡）
  领地产出（每日收益：资源/货币）
  领地升级（消耗公会资源）

简化落地：
  领地 = 公会等级附属的一组"建设项"
  建设进度（木材/金币/时间）→ 解锁功能
  不需要真实场景也可做"虚拟领地"

4.2 公会任务

任务类型：
  个人贡献任务（每日活跃 → 个人贡献）
  集体任务（全公会累计目标：击杀数/捐献）

进度：
  个人任务 → 个人进度
  集体任务 → 公会进度（成员共同推进）

完成奖励：
  个人奖励 + 公会宝库（贡献分配）
  奖励发放要幂等（防重复）

4.3 公会活动

活动形式：
  限时活动（公会战、竞速）
  日常活动（捐献、答题）

实现：
  复用活动系统框架（第 8 周）
  公会维度参与（按 guildId 分组计分）
  结算 → 公会排行 → 发奖

活跃度体系：
  成员操作 → 贡献 + 活跃度
  公会活跃 → 经验 → 升级
  每日/每周活跃目标 → 宝箱

---

五、公会排行榜

5.1 排行维度

榜单	排序依据
公会战力榜	总战力/总评分
公会等级榜	等级/经验
活跃榜	周活跃度
活动榜	当期活动积分

实现（Redis ZSet）：
  上榜键：guild:rank:power
  成员加入/战力变化 → ZADD 更新公会总分
  排行查询：ZREVRANGE
  活动榜：按活动独立键（活动结束归档）

5.2 排行更新时机

更新策略：
  实时更新（成员战力变化即更新公会总分）
  定时汇总（每 5 分钟重算，控制写量）
  事件驱动（结算/升级时更新）

体验与性能平衡：
  榜单展示允许分钟级延迟
  实时性需求低 → 定时重算更稳

发奖：
  周榜结算（定时任务，见第 8 周）
  结算 → 发奖（幂等）→ 清榜/重新计
  榜单防作弊：活跃/贡献校验

---

六、数据一致性

关键一致性场景：
  成员加入/退出与公会统计同步
  解散时所有成员释放
  会长转移原子操作
  活动结算与排行一致

处理：
  成员变更用事务（成员表 + 公会统计）
  解散 = 批量成员移除（分页处理）
  关键操作幂等 + 审计

退出后数据：
  个人贡献记录保留（个人资产）
  公会职位释放（防占位）
  再入会：冷却时间（按规则）

---

七、常见问题

问题	处理
会长跑路	自动转移机制
公会数据不一致	事务 + 幂等
小号刷公会	活跃校验 + 上限
排行刷分	贡献校验 + 反作弊
解散清算	宽限期 + 资产处理

---

八、小结

公会系统是"集体社交"的载体：以 Guild + GuildMember 双实体组织关系，生命周期覆盖创建/加入/退出/解散，会长离线自动转移防止群龙无首；权限体系用"角色 → 权限位"模型约束踢人、任命、公告等操作并全程审计；领地/任务/活动分别承载建设、集体进度与限时玩法，共同驱动活跃度成长；排行榜基于 Redis ZSet 按战力/活跃/活动多维度排名，定时汇总控制写量。公会系统的工程关键是"集体数据的一致性"，成员、统计、排行、活动四处联动，靠事务与幂等守住。