175 lines
8.2 KiB
Markdown
175 lines
8.2 KiB
Markdown
# 仙侠纯听觉MUD游戏 — 策划案任务拆分
|
||
|
||
> 创建日期：2026-05-21
|
||
> 修订日期：2026-05-21
|
||
> 状态：修订完成（技术架构前置至第一层，补充启动页音频解锁与系统依赖）
|
||
|
||
---
|
||
|
||
## 项目概览
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| 类型 | 纯听觉交互手机游戏（屏幕全黑） |
|
||
| 题材 | 仙侠 |
|
||
| 参考 | 传统 MUD 游戏 |
|
||
| 平台 | 纯 HTML5（浏览器运行） |
|
||
| 操作 | 上滑、下滑、左滑、右滑、单击、双击（共6种手势） |
|
||
| 输出 | 语音播报 + 音效 + 环境氛围音乐（启动页有可访问按钮，游戏内无核心视觉元素） |
|
||
| 战斗 | 回合制 |
|
||
| 联机 | 大型MUD在线世界，支持PvP/PvE/副本，低人数时游历修士NPC填充 |
|
||
| 商业模式 | 纯免费 |
|
||
| 玩法 | 主线剧情 + 自由探索/修炼 |
|
||
| 语音策略 | 预生成 + 按需生成 + 播报时拼装；玩家聊天支持语音输入 ASR |
|
||
|
||
---
|
||
|
||
## 任务拆分
|
||
|
||
策划案共分为 **14 个模块**，按依赖关系分为 4 层。
|
||
|
||
> **关键原则**：技术架构前置。手势识别、音频引擎、WebSocket 协议、资源缓存、服务端权威状态等技术约束会反过来决定玩法能否成立，因此必须与基础设计同层确定。
|
||
|
||
### 第一层：基础框架 + 技术架构（无依赖，必须最先确定）
|
||
|
||
#### 任务 1：游戏概述与核心设计理念
|
||
- 游戏定位、目标用户
|
||
- 核心体验描述（"闭眼修仙"的体验承诺）
|
||
- 与传统MUD的异同对比
|
||
- 纯音频游戏的设计原则与约束
|
||
|
||
#### 任务 2：世界观与背景设定
|
||
- 仙侠世界观框架（天地灵气、修炼体系的宏观设定）
|
||
- 大陆/区域划分
|
||
- 主要势力/门派
|
||
- 时间线与历史大事件
|
||
- 世界运行规则（昼夜、天气、灵气潮汐等）
|
||
|
||
#### 任务 3：交互设计 — 手势映射与UI流转
|
||
- 6 种手势在不同场景下的功能映射表（严格6种，不引入长按等额外手势）
|
||
- 场景上下文切换逻辑（探索态、战斗态、菜单态、对话态等）
|
||
- 导航与寻路的音频交互方案
|
||
- 无障碍设计原则
|
||
- 操作容错与撤销机制
|
||
|
||
#### 任务 4：技术架构概要（从第四层前置）
|
||
- 客户端架构（HTML5 + Web Audio API + WebSocket）
|
||
- 移动浏览器限制调研（后台暂停、音频自动播放策略、内存限制）
|
||
- 启动页设计与音频解锁流程（用户手势激活 AudioContext，避免无声黑屏）
|
||
- 服务端架构（游戏逻辑服务 + 音频资源服务）
|
||
- 通信协议设计
|
||
- 数据存储方案
|
||
- 音频资源缓存策略
|
||
- 服务端权威状态设计（离线收益由服务端结算，不依赖客户端持续运行）
|
||
|
||
### 第二层：核心系统（依赖第一层）
|
||
|
||
#### 任务 5：角色与修炼系统
|
||
- 角色创建流程（纯音频引导）
|
||
- 基础属性体系（根骨、悟性、灵力等）
|
||
- 修炼境界体系（练气→筑基→金丹→元婴→…）
|
||
- 功法/技能树设计
|
||
- 属性成长与突破机制
|
||
|
||
#### 任务 6：地图与导航系统
|
||
- 地图数据结构（房间/节点 + 连接，MUD经典模式）
|
||
- 区域设计（新手村、城镇、野外、秘境、副本入口等）
|
||
- 导航语音播报方案（到达/离开/方位描述）
|
||
- 环境氛围音设计（每个区域的声景特征）
|
||
- 随机事件触发机制
|
||
|
||
#### 任务 7：音频系统设计
|
||
- 音频分层架构（BGM层、氛围层、音效层、语音层）
|
||
- 语音播报规范（播报优先级、队列管理、打断规则）
|
||
- 音效设计清单（按场景/动作分类）
|
||
- BGM设计清单（按区域/情境分类）
|
||
- 语音拼装方案（预生成片段 + 动态拼接规则）
|
||
- 音频资源生产管线（对接本机 TTS/音乐/音效工具链）
|
||
|
||
### 第三层：玩法系统（依赖第二层）
|
||
|
||
#### 任务 8：战斗系统
|
||
- 回合制战斗流程（纯音频版）
|
||
- 技能/功法在战斗中的使用
|
||
- 战斗音频反馈设计（攻击、防御、闪避、暴击等音效）
|
||
- PvE 怪物设计（种类、AI行为）
|
||
- PvP 对战规则
|
||
- 战斗结算与奖励
|
||
|
||
#### 任务 9：副本系统
|
||
- 副本类型（单人、组队、公会）
|
||
- 副本结构设计（线性/分支）
|
||
- Boss 机制设计（纯音频下如何传达Boss技能预警）
|
||
- 副本奖励与难度分级
|
||
- 组队匹配机制
|
||
|
||
#### 任务 10：任务与剧情系统
|
||
- 主线剧情大纲
|
||
- 支线任务类型（日常、悬赏、奇遇、门派）
|
||
- 任务追踪与播报方式
|
||
- 剧情分支与选择机制
|
||
- NPC对话系统（对话树 + 语音播报）
|
||
|
||
#### 任务 11：经济与物品系统
|
||
- 货币体系（灵石、贡献点等）
|
||
- 物品分类（装备、丹药、材料、法宝）
|
||
- 装备系统（穿戴、强化、品质）
|
||
- 交易系统（玩家间交易、NPC商店）
|
||
- 背包管理的音频交互方案
|
||
|
||
### 第四层：社交与运营（依赖第三层）
|
||
|
||
#### 任务 12：多人社交系统
|
||
- 玩家登录与账号系统
|
||
- 好友系统
|
||
- 门派/公会系统
|
||
- 聊天系统（语音输入 ASR → 文本确认 → TTS播报，快捷消息/键盘输入兜底）
|
||
- 玩家间互动（切磋、交易、组队）
|
||
|
||
#### 任务 13：AI游历修士系统（原"机器人"）
|
||
- 游历修士行为模型（巡逻、修炼、社交、战斗）
|
||
- 游历修士人格与对话风格
|
||
- 动态填充策略（根据在线人数调节数量）
|
||
- 游历修士明确标识为NPC，不伪装真人玩家
|
||
- 与真实玩家的交互规则
|
||
|
||
#### 任务 14：内容生产管线与版本规划
|
||
- 音频资源生产流程（TTS → 音效 → BGM → 拼装 → 质检）
|
||
- 对接本机工具链的具体方案
|
||
- MVP版本范围定义
|
||
- 后续版本迭代路线图
|
||
|
||
---
|
||
|
||
## 依赖关系图
|
||
|
||
```
|
||
第一层（并行） 第二层（并行） 第三层（并行） 第四层（并行）
|
||
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
|
||
│ 1.游戏概述 │──┬────────→│ 5.角色修炼 │───┬──→│ 8.战斗系统 │───┬──→│12.社交系统 │
|
||
└──────────┘ │ └──────────┘ │ └──────────┘ │ └────▲─────┘
|
||
┌──────────┐ │ ┌──────────┐ │ ┌──────────┐ │ ┌──────────┐
|
||
│ 2.世界观 │──┼────────→│ 6.地图导航 │───┼──→│ 9.副本系统 │───┼──→│13.AI游历修士│
|
||
└──────────┘ │ └──────────┘ │ └──────────┘ │ └──────────┘
|
||
┌──────────┐ │ ┌──────────┐ │ ┌──────────┐ │ ┌──────────┐
|
||
│ 3.交互设计 │──┼────────→│ 7.音频系统 │───┘──→│10.任务剧情 │───┘──→│14.生产管线 │
|
||
└──────────┘ │ └──────────┘ └──────────┘ └────▲─────┘
|
||
┌──────────┐ │ 5/6 ───────────────→┌──────────┐─────────────┘
|
||
│ 4.技术架构 │──┘ │11.经济物品│
|
||
│ (前置!) │ └────┬─────┘
|
||
└──────────┘ └────────────→ 12.社交交易
|
||
```
|
||
|
||
> **变更说明**：技术架构从第四层提升至第一层。手势识别、音频引擎、WebSocket协议、移动浏览器限制等技术约束会直接决定玩法设计能否落地，必须前置验证。
|
||
|
||
---
|
||
|
||
## 输出标准
|
||
|
||
每个任务模块在策划案中应包含：
|
||
1. **设计目标** — 该模块要解决什么问题
|
||
2. **详细设计** — 具体规则、数值、流程
|
||
3. **音频需求清单** — 该模块需要哪些语音/音效/BGM资源
|
||
4. **交互流程** — 玩家操作手势 → 系统响应音频 的完整流转
|
||
5. **边界条件** — 异常情况处理（网络延迟、操作冲突等）
|