# **1\. 涉众 (Actors)**

* **玩家 (Player)**：唯一的用户类型。

# **2\. 功能需求 (Use Cases)**

## **2.1. UC-01: 用户账户管理**

* **As a** 玩家, **I want to** 在客户端启动时，可以选择“注册”或“登录”。  
* **Acceptance Criteria:**  
  1. **注册**：需要提供唯一的“用户名”和“密码”。服务器检查用户名是否已存在于数据库。  
  2. **登录**：需要提供“用户名”和“密码”。服务器在数据库中验证。  
  3. **数据持久化**：注册信息必须使用 SQLite 数据库存储。  
  4. **安全**：密码应在数据库中加盐哈希存储（*开发注：如果时间紧张，MVP 阶段可降级为明文存储*）。

## **2.2. UC-02: 游戏大厅 (Lobby)**

* **As a** 玩家, **I want to** 登录成功后进入游戏大厅，以便和其他玩家互动。  
* **Acceptance Criteria:**  
  1. **公共聊天**：玩家可以发送消息，该消息应被广播给所有**当前在大厅中**的其他玩家。  
  2. **接收聊天**：玩家可以实时看到大厅中的所有公共聊天消息。  
  3. **玩家列表**：玩家可以输入特定命令（如 /list），从服务器获取当前所有在线玩家的列表。

## **2.3. UC-03: 战斗邀请与匹配**

* **As a** 玩家, **I want to** 邀请大厅里的其他玩家进行 1v1 对战。  
* **Acceptance Criteria:**  
  1. **发起邀请**：玩家A可以向玩家B（必须在线且不在战斗中）发送对战邀请。  
  2. **接收邀请**：玩家B会收到“玩家A向你发起决斗，是否接受？(y/n)”的提示。  
  3. **响应**：玩家B响应后，结果会通知给玩家A。  
  4. **状态变更**：一旦双方同意，服务器应将两名玩家的状态标记为“战斗中”，他们将不再接收大厅聊天。

## **2.4. UC-04: 回合制战斗 (1v1)**

* **As a** 玩家, **I want to** 在战斗房间中，和对手轮流行动，直到一方 HP 降为 0。  
* **Acceptance Criteria:**  
  1. **战斗逻辑在服务器**：所有战斗计算（伤害、闪避、Buff）**必须**在服务器上进行。  
  2. **角色职业**：至少实现 2 个职业（如 Warrior, Mage），它们具有不同的属性和技能。  
  3. **技能系统**：每个职业至少有 2 个技能（如 Fireball, Heal）。  
  4. **回合制**：服务器根据角色“速度”属性决定行动顺序。轮到某玩家时，服务器通知其客户端“请行动”。  
  5. **行动**：玩家客户端发送行动指令（如 "USE:Fireball:Target\_B"）。  
  6. **战报**：服务器执行行动后，将结果（如 "A对B使用了\[火球\]，造成50伤害"）广播给**战斗中的两名**玩家。  
  7. **胜负**：一方 HP \<= 0 时，战斗结束。服务器宣布胜利者，并将双方T出战斗房间，状态改回“在线”。

# **3\. 非功能需求**

1. **技术栈 (强制)**  
   * **多态**：必须用于实现 ICharacter (角色基类) 和 ISkill (技能基类)。  
   * **STL**：必须深度使用 std::map (管理客户端), std::vector (管理战斗序列), std::thread (并发), std::mutex (线程同步)。  
   * **模板 \+ 链表**：必须**手写一个泛型链表类** HistoryLog\<T\> (模板)，用于存储战斗日志（链表）。  
   * **网络编程**：必须使用**原生 Socket API** (Winsock/POSIX Sockets) 并自行封装。  
   * **数据库**：必须使用 **SQLite3** 库进行数据持久化。  
2. **性能**  
   * 服务器必须能稳定处理至少 10 个并发的客户端连接。  
   * 网络通信延迟在局域网内应无明显卡顿。  
3. **健壮性**  
   * 服务器必须处理客户端的异常断开（如 Ctrl+C），并正确清理其资源（从 map 中移除，释放战斗房间等）。  
   * 客户端必须处理连接服务器失败、或中途与服务器断开连接的异常。