完善多赛道联调与全局产品架构
This commit is contained in:
324
doc/gameplay/APP全局产品架构草案.md
Normal file
324
doc/gameplay/APP全局产品架构草案.md
Normal file
@@ -0,0 +1,324 @@
|
||||
# APP全局产品架构草案
|
||||
> 文档版本：v1.0
|
||||
> 最后更新：2026-04-02 18:10:04
|
||||
|
||||
本文档用于整理当前 APP 级产品逻辑的整体设想，作为后续页面架构、后端对象模型、联调边界和默认流程设计的上层基线。
|
||||
|
||||
---
|
||||
|
||||
## 1. 总体判断
|
||||
|
||||
当前产品不应再简单理解为“地图游戏程序”，更准确的定位应当是：
|
||||
|
||||
**以地图为资源底座、以活动为对外核心、以对局为过程、以用户资产为沉淀的运动游戏系统。**
|
||||
|
||||
这意味着：
|
||||
|
||||
- 地图是场地资产和体验载体
|
||||
- 活动是运营层、展示层、商业层和用户入口
|
||||
- Session 是一次真实对局过程
|
||||
- 历史、成就、奖励、资料等属于用户长期资产
|
||||
|
||||
---
|
||||
|
||||
## 2. 一级模块建议
|
||||
|
||||
建议 APP 长期按 5 个一级模块组织。
|
||||
|
||||
### 2.1 首页 / 发现
|
||||
|
||||
负责：
|
||||
|
||||
- 地区浏览
|
||||
- 地图列表
|
||||
- 推荐活动
|
||||
- 默认体验入口
|
||||
- 宣传入口
|
||||
|
||||
适用对象：
|
||||
|
||||
- 游客
|
||||
- 初次进入的新用户
|
||||
- 以地图体验为目标的训练型用户
|
||||
|
||||
### 2.2 活动 / 赛事
|
||||
|
||||
这是系统核心模块。
|
||||
|
||||
负责：
|
||||
|
||||
- 活动卡片列表
|
||||
- 活动详情
|
||||
- 报名
|
||||
- 签到
|
||||
- 开局
|
||||
- 公告
|
||||
- 排行榜
|
||||
- 社交或分享入口
|
||||
- 多地图活动聚合
|
||||
|
||||
说明：
|
||||
|
||||
- 活动页本质上是系统的对外展示壳和运营壳
|
||||
- 不同客户的活动页、排行榜、宣传页都可能是定制化的
|
||||
- 这里适合长期采用“原生模板 + 原生 DSL + H5 增强”的分层方案
|
||||
|
||||
### 2.3 地图体验
|
||||
|
||||
负责：
|
||||
|
||||
- 地图默认体验活动
|
||||
- 地图自由体验
|
||||
- 训练入口
|
||||
- 正式进入地图游戏过程
|
||||
- 游戏过程中的内容、规则、结算
|
||||
|
||||
说明：
|
||||
|
||||
- 地图体验层是运行层，不是对外运营主入口
|
||||
- 游客主要通过这一层进入体验
|
||||
|
||||
### 2.4 我的
|
||||
|
||||
负责：
|
||||
|
||||
- 历史记录
|
||||
- 成绩详情
|
||||
- 报名信息
|
||||
- 全局头像与昵称
|
||||
- 成就
|
||||
- 奖励展示
|
||||
- 收藏与长期资产
|
||||
|
||||
说明：
|
||||
|
||||
- 历史、成就、奖励不应分散在不同页面里，建议统一收口在用户资产中心
|
||||
|
||||
### 2.5 系统
|
||||
|
||||
负责：
|
||||
|
||||
- 设置
|
||||
- 帮助
|
||||
- 使用说明
|
||||
- 反馈
|
||||
- 关于
|
||||
- 调试入口
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心对象模型
|
||||
|
||||
建议长期围绕 4 个核心对象组织前后端模型。
|
||||
|
||||
### 3.1 Map
|
||||
|
||||
含义：
|
||||
|
||||
- 地图资源
|
||||
- 场地资产
|
||||
- 瓦片与底图
|
||||
- 点位、图层、默认体验挂载位置
|
||||
|
||||
### 3.2 Event
|
||||
|
||||
含义：
|
||||
|
||||
- 活动
|
||||
- 赛事
|
||||
- 运营包装壳
|
||||
- 报名、签到、排行榜、宣传、社交等活动级能力
|
||||
|
||||
说明：
|
||||
|
||||
- 一个 Event 可以挂一个地图，也可以挂多个地图
|
||||
- 一个地图也可以承载多个 Event
|
||||
|
||||
### 3.3 Session
|
||||
|
||||
含义：
|
||||
|
||||
- 一次具体开局记录
|
||||
- 一次真实游戏过程
|
||||
- 与规则、成绩、恢复、结果页直接相关
|
||||
|
||||
### 3.4 User Asset
|
||||
|
||||
含义：
|
||||
|
||||
- 历史记录
|
||||
- 成就
|
||||
- 奖励
|
||||
- 头像昵称
|
||||
- 报名资料快照
|
||||
- 收藏与长期沉淀
|
||||
|
||||
---
|
||||
|
||||
## 4. 用户主流程建议
|
||||
|
||||
### 4.1 游客主流程
|
||||
|
||||
1. 打开程序
|
||||
2. 浏览地区和地图
|
||||
3. 进入地图默认体验活动
|
||||
4. 进行单局游戏
|
||||
5. 结果和历史先本地保存
|
||||
6. 登录后再触发同步或迁移
|
||||
|
||||
设计结论：
|
||||
|
||||
- 游客以地图体验链为主
|
||||
- 游客不应直接进入正式活动能力
|
||||
|
||||
### 4.2 注册用户主流程
|
||||
|
||||
1. 打开程序
|
||||
2. 浏览活动 / 赛事
|
||||
3. 进入活动详情
|
||||
4. 报名 / 签到 / 开局
|
||||
5. 进入正式对局
|
||||
6. 成绩回写历史、排行榜、奖励、成就
|
||||
|
||||
设计结论：
|
||||
|
||||
- 注册用户以活动运营链为主
|
||||
- 活动是主要用户入口
|
||||
|
||||
---
|
||||
|
||||
## 5. 当前设想的逐项落点
|
||||
|
||||
### 5.1 地图列表
|
||||
|
||||
保留，但定位建议明确为：
|
||||
|
||||
- 自由体验入口
|
||||
- 游客入口
|
||||
- 训练入口
|
||||
|
||||
### 5.2 活动卡片列表
|
||||
|
||||
必须升格为核心模块。
|
||||
|
||||
活动系统长期需要支持：
|
||||
|
||||
- 标准模板活动
|
||||
- 默认体验活动
|
||||
- 客户定制活动
|
||||
|
||||
### 5.3 历史记录
|
||||
|
||||
建议归入“我的”模块统一管理，至少分成：
|
||||
|
||||
- 最近活动
|
||||
- 全部记录
|
||||
- 成绩详情
|
||||
|
||||
### 5.4 游客模式
|
||||
|
||||
建议正式规则为：
|
||||
|
||||
- 游客只可进入地图默认体验活动
|
||||
- 游客数据先本地存储
|
||||
- 登录后触发数据迁移或合并
|
||||
|
||||
### 5.5 全局资料与活动内资料
|
||||
|
||||
建议分两层模型：
|
||||
|
||||
- 全局用户资料
|
||||
- 活动报名资料快照
|
||||
|
||||
因为活动内昵称、头像、队伍信息可能与全局资料不同。
|
||||
|
||||
### 5.6 帮助页面
|
||||
|
||||
建议未来拆成：
|
||||
|
||||
- 新手引导
|
||||
- 使用帮助
|
||||
- 常见问题
|
||||
|
||||
### 5.7 反馈功能
|
||||
|
||||
建议反馈最少自动带上：
|
||||
|
||||
- 当前活动
|
||||
- 当前地图
|
||||
- 当前 session
|
||||
- 设备信息
|
||||
- 程序版本
|
||||
|
||||
### 5.8 成就展示
|
||||
|
||||
当前可以先不做奖励系统，但架构上建议预留：
|
||||
|
||||
- 成就
|
||||
- 奖章
|
||||
- 奖励
|
||||
- 收藏品
|
||||
|
||||
---
|
||||
|
||||
## 6. 产品主线建议
|
||||
|
||||
当前最适合正式确定的一条主线是：
|
||||
|
||||
### 游客态
|
||||
|
||||
- 以地图和默认体验为主
|
||||
|
||||
### 登录态
|
||||
|
||||
- 以活动和赛事为主
|
||||
|
||||
这个分流非常重要，因为它会影响：
|
||||
|
||||
- 首页结构
|
||||
- 登录前后导航
|
||||
- 活动和地图的权重关系
|
||||
- 默认入口设计
|
||||
|
||||
---
|
||||
|
||||
## 7. 与当前工程结构的关系
|
||||
|
||||
对照当前代码与文档体系，可以理解为：
|
||||
|
||||
- `MapEngine`、渲染层、传感器层：地图资源与运行骨架
|
||||
- 规则层、Telemetry、Feedback：Session 过程层
|
||||
- 活动页、准备页、结果页、首页聚合：Event 与 User Asset 的上层壳
|
||||
- 配置系统与文档体系：把 Map / Event / Session 的差异转为可配置运行态
|
||||
|
||||
因此，后续开发不应再只围绕“地图页”扩功能，而应正式开始：
|
||||
|
||||
- 活动系统设计
|
||||
- 结果与历史沉淀设计
|
||||
- 游客链与登录链分流
|
||||
|
||||
---
|
||||
|
||||
## 8. 当前阶段建议
|
||||
|
||||
当前建议优先做这三件事：
|
||||
|
||||
1. 正式梳理活动系统页面骨架
|
||||
2. 打磨顺序赛 / 积分赛的默认规则、默认样式、默认流程
|
||||
3. 明确游客模式与登录模式的数据迁移规则
|
||||
|
||||
不建议当前阶段做的事：
|
||||
|
||||
- 过早铺开复杂社交体系
|
||||
- 在奖励系统未定前做大而全的成就结构
|
||||
- 让地图页承担过多对外展示职责
|
||||
|
||||
---
|
||||
|
||||
## 9. 一句话结论
|
||||
|
||||
当前 APP 最合理的全局方案是：
|
||||
|
||||
**地图是资源底座，活动是对外核心，Session 是游戏过程，历史与成就是用户资产。**
|
||||
|
||||
后续页面、后端模型、联调策略和配置体系，都应围绕这四个对象继续收口。
|
||||
Reference in New Issue
Block a user