HairTeam——Beta阶段项目展示
本模块主要分为6个部分，前5个部分仅做概括性介绍，具体内容放在后续部分详细介绍，最后，本模块会展示本项目的演示视频。
一. 成员与分工简介
成员简介
- 我们项目团队由ZZX，YYH，ZSK，WCF，QY和组长LCY组成；
- 转会期我们的转会组员没有找到合适的团队，通过回收通道回归我们团队，团队成员相对alpha阶段无变化；
| 头像 | 名字 | 成员介绍 | PM | 开发 | 测试 | 美工 | 鼓励师 |
|---|---|---|---|---|---|---|---|
 |
zixfy | 菜到只会c，勇敢的工具人，搞过一点Vue.js/jQuery/Android，希望可以在软工课中成长为合格的工程师，志愿在团队中担任测试或者开发岗位的工作 |
⭐️ | ⭐️ | ⭐️ | ||
 |
yyh | 21岁，是学生。c c++ java html啥的都会一点但是都不精通，比较吃苦耐劳，但是学累了会直接睡觉，一般不会拖ddl。 |
⭐️ | ⭐️ | ⭐️ | ⭐️ | |
 |
zsk | 吃饭睡觉第一名的打工人，努力成为一位合格的代码搬运工 | ⭐️ | ⭐️ | ⭐️ | ⭐️ | |
 |
wcf | 掌握C C++ Java Python的基本语法，曾用C和C++实现了简易版的带优化编译器,使用Java及JDBC完成过火车售票网站的后端，使用Python绘制过数据处理和分析的图表还有爬虫。希望和团队成员一起在本课程中共同努力，有所收获。 |
⭐️ | ⭐️ | ⭐️ | ⭐️ | |
 |
qy | 菜鸡一枚，但是愿意肝；没有太多项目开发经验，希望能从团队项目中学到东西；没有什么特别爱好，就打游戏摸鱼，生活规律比较正常，但非常时期可能阴间作息。 | ⭐️ | ⭐️ | ⭐️ | ||
 |
lcy | 社会主义工具人，写过c51单片机，经历过C/C++ Java的打磨，也感受过Python(with Django, PyTorch, Scrapy)的快乐，体验过纯HTML+JS的凛冽，也享受过JQuery+Vue的极致体验。因此，喜欢新事物，希望在团队任务中同大家一起做好玩的东西。 |
⭐️ | ⭐️ | ⭐️ |
分工简介
我们沿用alpha阶段的小组分工模式，即组间分工+组内分工结合的模式；
-
组间分工：6人团队中按照服务范围和任务性质分为几个小组，但做了细微调整；
alpha阶段：每个小组的任务由组长统一计划，分配到人，除非特殊原因，个人一般按组长分配执行任务；
beta阶段：小组的任务由组内内自主分配，但是需要与组长进行汇报，最终按小组单位交付；
alpha阶段管理模式 
beta阶段管理模式 
改进：组内自主分工使得我们在人员安排上更加具有自由度，同时两日一开的组会又保证了组长对于项目管理和分工的宏观调控和对于项目进度的把控。
-
组内分工：在上述组间分工的基础上，我们进行了小组内自主分工，这里只展示概要，具体每个小组的任务条目请参考后面的项目与团队总结部分。
任务重分配：由于组内工作的高度相似性和成员空闲时间的不确定性，我们组内的工作存在许多重分配的部分，并不是严格按照上图进行划分进行工作，这也是团队分工容错的体现。
改进：我们吸取了alpha阶段不同组别任务工作量和难度不对等的教训，采用了自愿选择和组长安排相结合的方式，组长发放问卷收集组员的分工意向，遇到分工冲突在协商后由组长安排；我们权衡了不同组之间和组内不同成员之间工作量和任务难度的差别，并据此在验收阶段的文档写作中进行工作量的调整，尽可能保证组内成员平摊任务负担。
项目管理简介
在项目管理方面，我们基本沿用了alpha阶段的方式，即：
版本控制：采用了Plastic SCM+git两种工具进行管理，每个人创建自己的分支，在交互阶段先组内合并，再进行小组间的合并并解决冲突；
进度追踪：采用gitlab的issue+pingcode的形式进行追踪，pingcode主要方便绘制项目燃尽图；
|
|
|
|
|
|
二. 典型用户场景
-
典型用户
在需求分析阶段，我们主要列举了小学生，中学生，大学生，游戏行业主播这四类典型用户，具体内容见我们团队博客的典型用户场景分析。
这些典型用户场景集中体现如下两点需求：
1. 轻量级和短时性 从快乐自由的小学生到题海书山的高中党，再到游戏为业的主播，他们都有自己的主流生活节奏，都希望有一个丰富有趣的能填充生活空隙的娱乐方式，但绝不希望这个方式挤占他们的主流时间。 这正好对标我们产品的核心理念：轻量级；在保持趣味性和可玩性的前提下，我们还能让用户得到短时间的游戏体验，而不是又肝又氪，费力不讨好。
2. 联机和交友 这些用户群体中大多都体现出社交方面的需求：小学生公园五连坐，大学室友宿舍背靠背，主播与粉丝连麦互动；这也为我们的产品提出了联机对战的需求。我们会在前期实现局域网联机的功能，并在后期推广到广域网，为用户提供一起游玩的游戏体验。
-
实际情况
基本完成，并取得了较好的评价。
三. 特色功能介绍
-
自选卡组+随机化
相较于alpha阶段完善并丰富了卡牌系统，目前拥有水火草冰四种属性的牌组，每种属性又有三种职业，在对战中，不同职业的角色能打出不同的配合，不同属性间也有着克制关系。
新增了卡牌随机发放的机制，在玩家选择进行卡牌刷新时会随机从备选卡池为玩家选出部分卡牌，以此来强化游戏的随机性与趣味性。
-
轻量级
对游戏软件进行了优化，目前游戏apk安装完后仅570MB，内存占用小，并且对配置的要求较低
-
短时性
从软件运行到游戏加载，对战，各个流程和操作十分便捷，一局游戏平均时长6min左右节奏快，能让用户在空隙时间内自己或者和朋友们进行对战，享受完美的游戏体验。
游戏操作流程展示：
-
3D对战效果
相较于炉石传说这类竞品平面卡牌对战游戏最大的优势，采用3D化即时战斗画面，增强了游戏表现力。
-
联机对战
在多人联机方面，本游戏简化了传统游戏复杂的联机/匹配机制，玩家主要通过房主-玩家的模式进行共同游玩，在多人联机的启动界面，用户可以选择创建指定ID的房间成为房主，或输入已创建的房间的ID以普通玩家的身份加入房间，双方进入后房主即可主持游戏的开始。双方中任一方退出游戏场景时，双方都将回到对战房间，而房主退出时另一玩家将成为房主以保持住房间资源。
-
游戏教程
根据老师和助教们对我们alpha阶段项目的评价，以及我们收集到的一些用户意见，我们新增了教程部分板块。当用户第一次安装游戏并完成注册登陆后，会进入我们预设好的引导界面，玩家可以根据引导教程来熟悉软件的使用，也可以选择直接跳过。同时为了方便玩家随时了解游戏玩法与机制，我们也加入了游戏教程来方便玩家随时随地的查阅相关资料信息。
四. 产品推广与用户反馈
-
项目推广
在Beta阶段，我们依旧使用「游戏网站主页」+「发布博客」的方式推广产品，并将这些网站通过聊天群、朋友圈的方式发布出去。
我们的游戏网站主页：
我们的游戏发布和用户反馈博客：
-
用户信息及反馈
产品发布后的一周内，我们统计了后台用户注册的信息数据：
我们在后端统计了用户使用联机功能在上线中的占比：
同时我们在微信跟进用户反馈：
我们对各渠道的反馈结果进行了一些统计，部分反馈将是我们beta阶段改进的方向：
意见 数目 联机对战延迟存在问题 19 角色在地图中显示大小 21 希望更多的卡牌组合 13 对战中可以加入聊天/好友功能 25
五. 软件工程质量
首先，我们采用ISO/IEC 25010:2011国际软件工程产品质量标准来对我们Beta阶段的软件项目 —— Ghost Tactics 进行评估。
| 对应要求完成情况 | 对应的星级 |
|---|---|
| 完成程度高且独具特色 | ⭐⭐⭐⭐ |
| 完成程度较高 | ⭐⭐⭐ |
| 有对应实现，但没测试全覆盖 | ⭐⭐ |
| 没有实现 | ⭐ |
1. 功能适用性(Functional Suitability)
-
功能完整性(Functional completeness)：功能涵盖所有指定任务和用户目标 ⭐⭐⭐⭐
-
功能正确性(Functional correctness)：产品能提供正确的功能使用结果 ⭐⭐⭐
-
功能适当性(Functional appropriateness)：功能促进特定任务和目标的完成 ⭐⭐⭐⭐
2. 性能效率(Performance efficiency)
- 时间表现(Time behaviour)：产品在执行其功能时的响应与处理时间以及吞吐率达到要求 ⭐⭐⭐
- 资源利用率(Resource Utilization)：产品或系统在执行其功能时所用的资源和类型满足要求 ⭐⭐
- 容量(Capacity)：产品参数的最大限制达到要求 ⭐⭐⭐
3. 兼容性(Compatibility)
- 共存(Co-existence)：产品使用时，同时与其他的产品共享公共环境和资源 ⭐⭐
- 互操作性(Interoperability)：两个或多个产品可以交换并使用信息 ⭐
4. 易用性(Usability)
- 可识别性(Appropriateness recognizability)：用户可以识别产品是否满足其需求 ⭐⭐⭐
- 可学习型(Learnability)：特定用户能通过学习达到有效、高效、无风险地使用产品 ⭐⭐⭐⭐
- 可操作性(Operability)：产品具有易于操作和控制的属性 ⭐⭐⭐
- 用户错误规避(User error protection)：系统保护用户避免错误 ⭐⭐⭐⭐
- 用户界面美感(User interface aesthetics)：用户界面的丰富交互 ⭐⭐⭐⭐
- 可访问性(Accessibility)：满足广泛用户群体进行产品的使用 ⭐⭐⭐
5. 可靠性(Reliability)
- 成熟度(Maturity)：系统正常使用下满足可靠性 ⭐⭐⭐
- 可用性(Availability)：系统在需要时可操作和可访问 ⭐⭐⭐⭐
- 容错性(Fault tolerance)：系统出现软硬件故障时按预期运行 ⭐⭐
- 可恢复性(Recoverability)：发生中断或故障时，系统恢复受损数据和重建状态 ⭐⭐
6. 安全性(Security)
- 机密性(Confidentiality)：产品确保只有授权后才能访问数据 ⭐⭐⭐
- 完整性(Integrity)：产品防止未经授权访问、修改程序和数据 ⭐⭐⭐
- 不可抵赖性(Non-repudiation)：可以证明发生某种动作或事件 ⭐⭐⭐
- 问责性(Accountability)：可将实体的行为与唯一的实体相对应 ⭐⭐
- 真实性(Authenticity)：可以证明主体或资源的身份与所称身份一致 ⭐⭐⭐
7. 可维护性(Maintainability)
- 模块化(Modularity)：系统减少耦合与代码结构化 ⭐⭐⭐⭐
- 可重用性(Reusability)：同一资源可用于多个系统 ⭐⭐⭐
- 可分析性(Analysability)：评估部件变化对系统的影响，诊断缺陷、故障原因 ⭐⭐
- 可修改性(Modifiability)：可对产品有效且高效的修改 ⭐⭐⭐⭐
- 可测试性(Testability)：可为产品建立测试标准，并进行测试以确定是否满足标准 ⭐⭐⭐
8. 便携性(Portability)
- 适应性(Adaptability)：产品能有效和高效的适应不同硬件、操作系统 ⭐⭐⭐
- 可安装性(Installability)：产品在特定环境中能成功安装与卸载 ⭐⭐⭐⭐
- 可替代性(Replaceability)：在同一环境下，产品可替代另一个相同用途的产品 ⭐⭐⭐
其次，我们对基于Django框架开发的后端系统进行了详尽的单元测试，覆盖率达到98%。
六. 项目演示视频
如下是我们项目的demo演示视频：
项目与团队总结
本模块为上一个模块提供数据支撑。
一. 项目管理
-
成员简介
我们项目团队由ZZX，YYH，ZSK，WCF，QY和组长LCY组成，由于在转会期我们的转会组员没有找到合适的团队，因此通过回收通道回归我们的团队，团队成员相对alpha阶段无变化，成员简介如下，个人博客地址请点击成员名字：
| 头像 | 名字 | 成员介绍 | PM | 开发 | 测试 | 美工 | 鼓励师 |
|---|---|---|---|---|---|---|---|
|
zixfy | 菜到只会c，勇敢的工具人，搞过一点Vue.js/jQuery/Android，希望可以在软工课中成长为合格的工程师，志愿在团队中担任测试或者开发岗位的工作 |
⭐️ | ⭐️ | ⭐️ | ||
|
yyh | 21岁，是学生。c c++ java html啥的都会一点但是都不精通，比较吃苦耐劳，但是学累了会直接睡觉，一般不会拖ddl。 |
⭐️ | ⭐️ | ⭐️ | ⭐️ | |
|
zsk | 吃饭睡觉第一名的打工人，努力成为一位合格的代码搬运工 | ⭐️ | ⭐️ | ⭐️ | ⭐️ | |
|
wcf | 掌握C C++ Java Python的基本语法，曾用C和C++实现了简易版的带优化编译器,使用Java及JDBC完成过火车售票网站的后端，使用Python绘制过数据处理和分析的图表还有爬虫。希望和团队成员一起在本课程中共同努力，有所收获。 |
⭐️ | ⭐️ | ⭐️ | ⭐️ | |
|
qy | 菜鸡一枚，但是愿意肝；没有太多项目开发经验，希望能从团队项目中学到东西；没有什么特别爱好，就打游戏摸鱼，生活规律比较正常，但非常时期可能阴间作息。 | ⭐️ | ⭐️ | ⭐️ | ||
|
lcy | 社会主义工具人，写过c51单片机，经历过C/C++ Java的打磨，也感受过Python(with Django, PyTorch, Scrapy)的快乐，体验过纯HTML+JS的凛冽，也享受过JQuery+Vue的极致体验。因此，喜欢新事物，希望在团队任务中同大家一起做好玩的东西。 |
⭐️ | ⭐️ | ⭐️ |
-
项目管理与改进
在项目管理方面，我们基本沿用了alpha阶段的方式，即：
版本控制：采用了Plastic SCM+git的形式进行管理，每个人创建自己的分支，组内合并再组间合并；
进度追踪：采用gitlab的issue+pingcode的形式进行追踪，pingcode主要方便绘制项目燃尽图；
-
分工协作与改进
组间分工
我们沿用了alpha阶段的小组分工模式，即6人团队中按照服务范围和任务性质分为几个小组，在组长的统一调配以及组内人员的对接交流下，分工与合作高效并行；
但是我们在这个基础上，我们对任务的分配模式做了一些细微的调整，Alpha阶段每个小组的任务都是由组长统一计划，分配到人的，除非因为特殊原因，个人一般都按组长分配的任务执行；但是在beta阶段，小组的任务由组内内自主分配，但是需要与组长进行汇报；这样的安排下，我们在人员安排上更加具有自由度，同时两日一开的组会又保证了组长对于项目管理和分工的宏观调控和对于项目进度的把控。
alpha阶段管理模式
beta阶段管理模式
至于如何组间分工，我们是根据alpha阶段的用户反馈，验收答辩阶段专家，老师和助教的建议，决定我们在beta阶段新增两三个主要功能模块：联机对战模式，游戏教程，新增卡牌角色类型；我们也将团队相应地分为三组：联机组，教程组，卡牌组；具体分工如下：
| 小组 | 分工 | 成员 |
|---|---|---|
| 联机组 | 利用Photon组件将单机游戏扩展位联机/单机游戏 | LCY，QY，WCF |
| 教程组 | 增加游戏教程，具体包括游戏内和游戏外的操作教程 | YYH，ZZX |
| 卡牌组 | 新增卡牌和角色类型，提高游戏玩法的丰富性和趣味性 | ZSK |
组内分工
在上述组间分工的基础上，小组内自主分工结果如下（这里的任务不仅仅包括上面三大模块，还包括对alpha阶段的优化），这也与我们gitlab上的issue以及燃尽图的任务项目相对应：
| 成员 | 具体任务 | 花费时长（h） | 预期结束时间 |
|---|---|---|---|
| 李辰洋 | 房间创建、加入UI | 6h | 5月28日 |
| Photon服务器连接 房间创建加入逻辑 | 6h | 5月30日 | |
| 网络部分逻辑代码 | 16h | 6月1日 | |
| 用户登陆、注册部分后端优化 | 4h | 6月3日 | |
| 房间测试与验收 | 1h | 6月5日 | |
| 战斗网络同步验收 | 1h | 6月7日 | |
| 后端优化测试与验收 | 1h | 6月9日 | |
| 严宇皓 | 新增教程：主界面UI和卡牌管理介绍教程 | 12h | 6月1日 |
| 优化用户体验（游戏外操作界面） | 2h | 6月5日 | |
| 游戏外教程测试与验收 | 1h | 6月7日 | |
| 卡牌测试与验收 | 1h | 6月8日 | |
| 游戏打包测试与发布 | 2h | 6月9日 | |
| 张书恺 | 新增教程：游戏中规则静态介绍教程 | 8h | 5月31日 |
| 新增卡牌UI | 8h | 6月5日 | |
| 教程测试与验收 | 1h | 6月7日 | |
| 卡牌测试与验收 | 1h | 6月8日 | |
| 测试和优化卡牌生成逻辑 | 3h | 6月9日 | |
| 赵子轩 | 新增教程 | 8h | 5月31日 |
| 新增卡牌：在战斗中的实例化 | 8h | 6月5日 | |
| 新增卡牌：在战斗中对其他角色的影响 | 8h | 6月5日 | |
| 新增卡牌：在战斗中的生效时间 | 8h | 6月5日 | |
| 教程测试与验收 | 1h | 6月7日 | |
| 卡牌测试与验收 | 1h | 6月9日 | |
| 吴承沣 | 网络部分逻辑代码 | 16h | 5月31日 |
| 复刻联机场景至所有地图 | 1h | 6月1日 | |
| 同步游戏流程阶段 | 4h | 6月7日 | |
| 玩家间数据同步测试 | 2h | 6月8日 | |
| 战斗网络同步验收 | 2h | 6月9日 | |
| 仇越 | 联机游戏流程逻辑框架 | 8h | 5月31日 |
| 主/从玩家交互逻辑框架 | 4h | 6月4日 | |
| 游戏场景素材整合，内存压缩 | 1h | 6月6日 | |
| 游戏内UI界面优化 | 8h | 6月7日 | |
| 战斗网络同步验收 | 4h | 6月9日 | |
由于组内工作的高度相似性和成员空闲时间的不确定性，我们组内的工作存在许多重分配的部分，所以并不是严格按照上图进行划分进行工作，这也是团队分工容错的体现。
我们吸取了alpha阶段不同组别任务工作量和难度不对等的教训，采用了自愿选择和组长安排相结合的方式，组长发放问卷收集组员的分工意向，遇到分工冲突在协商后由组长安排；我们权衡了不同组之间和组内不同成员之间工作量和任务难度的差别，并据此在验收阶段的文档写作中进行工作量的调整，尽可能保证组内成员平摊任务负担。
-
沟通和对接
由于beta阶段我们小组间的分工是互不相干的不同功能模块，只需要在验收阶段进行简单的合并和测试即可；对于小组内的沟通与对接，在代码注释的基础上，我们主要采用线上/线下交流的方式。
在alpha阶段，我们在代码编写的基础上，增加了比较详细的注释，尤其是在给队友提供调用接口的部分；而对于beta阶段，我们不仅仅以注释的方式书面沟通，还增加了口头沟通的比重，尤其是网络联机对战这一模块，因为其难度较大，且我们对于相关技术栈不熟，我们小组内经常进行线下面对面开发，若不方便进行线下面对面开发，我们会微信进行沟通；此外两日一开的会议也是我们沟通对接的渠道。
代码注释 线上交流 组会讨论 
对于代码注释规范，我们主要采用XML注释方式，这是C#代码常见的注释方法和规范：
| 标签名称 | 说明 | 语法 | 参数 |
|---|---|---|---|
| <summary> | <summary> 标记应当用于描述类型或类型成员。使用 <remarks> 添加针对某个类型说明的补充信息。<summary> 标记的文本是唯一有关IntelliSense 中的类型的信息源，它也显示在 对象浏览器 中。 | <summary>Description</summary> | description:对象的摘要。 |
| <remarks> | 使用 <remarks>标记添加有关类型的信息，以此补充用 <summary> 指定的信息。此信息显示在对象浏览器中。 | <remarks>Description</remarks> | description:成员的说明。 |
| <param> | <param> 标记应当用于方法声明的注释中，以描述方法的一个参数。有关 <param> 标记的文本将显示在IntelliSense、对象浏览器和代码注释Web 报表中。 | <paramname='name'>description</param> | name:方法参数名。将此名称用双引号括起来 (" ")。description:参数说明。 |
| <returns> | <returns> 标记应当用于方法声明的注释，以描述返回值。 | <returns>Description</returns> | description:返回值的说明。 |
| ...... | ...... | ...... | ...... |
但对于函数内部比较复杂的逻辑，我们采用传统的“//”进行注释，并且没有严格加以规范。
-
平衡时间/质量/资源完成任务
首先我们在人力资源分配上做了平衡，由于联机模块开发难度大，且存在知识盲区，我们分配了3人进行开发，组长也在这个小组进行开发，并让其他小组自行分配组内任务。
其次，为了尽可能快的完成任务，我们一开始会忽略其中的一些细节，尽可能开发出一个勉强可以交付的大致框架，然后根据当前的进度和时间，继续完善和补充细节，扩展功能；这有点类似于产品开发模型的迭代模型；其实我们软工的课程安排就是一个迭代模型，只不过由于时间关系，只有alpha和beta两个迭代阶段；当我们发现时间紧急，就可能会在质量和时间之间取一个平衡，舍弃一些不必要的功能，优先完成必要功能。
-
项目进展
在项目进度管理上，我们与alpha阶段一样，利用pingCode对每个子任务进行管理，与gitlab上的issue一一对应，同步进行管理，因此能比较真实地反映我们项目在各个时段的状态；这样虽然会使得工作变得繁琐，但pingCode能帮助我们绘制项目燃尽图，更加直观地体现我们项目的进度推进。
由上图可知，我们在项目的推进过程中是存在一些拖延和赶工现象的，由于beta阶段临近期末，大家都处在比较忙的状态，并不是每天都能完成充足的工时，但是整体上，我们能够按时完工。
-
贡献得分
名字 角色 团队贡献分 具体的, 可衡量的, 可验证的贡献 lcy PM&Dev&Test 51 房间创建、加入UI；
Photon服务器连接 房间创建加入逻辑；
网络部分逻辑代码；
用户登陆、注册部分后端优化；
房间测试与验收；
战斗网络同步验收；
后端优化测试与验收yyh Dev&Test 49 新增教程：主界面UI和卡牌管理介绍教程；
优化用户体验（游戏外操作界面）；
游戏外教程测试与验收；
卡牌测试与验收；
游戏打包测试与发布；zsk Dev&Test 49 新增教程：游戏中规则静态介绍教程；
新增卡牌UI；
教程测试与验收；
卡牌测试与验收；
测试和优化卡牌生成逻辑zzx Dev&Test 49 新增教程；
新增卡牌：在战斗中的实例化；
新增卡牌：在战斗中对其他角色的影响；
新增卡牌：在战斗中的生效时间；
教程测试与验收；
卡牌测试与验收；wcf Dev&Test 50 网络部分逻辑代码；
复刻联机场景至所有地图；
同步游戏流程阶段；
玩家间数据同步测试；
战斗网络同步验收；qy Dev&Test 52 联机游戏流程逻辑框架；
主/从玩家交互逻辑框架；
游戏场景素材整合，内存压缩；
游戏内UI界面优化；
战斗网络同步验收；
二. 用户场景
预期的典型用户场景
我们希望开发出一款轻量级手游，供不同年龄层次的人利用碎片化时间进行游玩，起到放松身心、调节生活的作用。它应当具有以下性质：
1. 轻量级和短时性 从快乐自由的小学生到题海书山的高中党，再到游戏为业的主播，他们都有自己的主流生活节奏，都希望有一个丰富有趣的能填充生活空隙的娱乐方式，但绝不希望这个方式挤占他们的主流时间。 这正好对标我们产品的核心理念：轻量级；在保持趣味性和可玩性的前提下，我们还能让用户得到短时间的游戏体验，而不是又肝又氪，费力不讨好。
2. 联机和交友 这些用户群体中大多都体现出社交方面的需求：小学生公园五连坐，大学室友宿舍背靠背，主播与粉丝连麦互动；这也为我们的产品提出了联机对战的需求。 我们会在前期实现局域网联机的功能，并在后期推广到广域网，为用户提供一起游玩的游戏体验。
以下列举四类典型用户，并给出典型的用户场景：
用户类型1：
| 属性 | 描述 |
|---|---|
| 姓名 | 小汪同学 |
| 身份 | 小学五年级学生 |
| 年龄 | 12岁 |
| 潜在量占比 | 20% |
| 使用习惯 | 小学课业压力相对较小，娱乐时间相对充足；平时放学后，周末做完作业后有零零散散的时间；放寒暑假以及各种节日会有较长的时间 |
| 产品期望 | 希望游戏规则简单易上手；希望能和同学一起游玩；对游戏画面特效没有太高期望 |
| 支付情况 | 经济高度不自由，零花钱十分有限，压岁钱被父母管控，基本很少“氪金” |
| 典型场景 | 1.放学后和同学蹲公园打游戏，因为要回家吃饭时间比较仓促； 2.周末或假期在家打游戏，有较为充足的时间。 |
用户类型2：
| 属性 | 描述 |
|---|---|
| 姓名 | 张某 |
| 身份 | 高二学生 |
| 年龄 | 17岁 |
| 潜在量占比 | 15% |
| 使用习惯 | 课业压力相当大，平时基本不会有时间，在非考试复习的周末可能会有0.5-1h的时间；假期在作业，补习和自习时间的间隙会有比较零散但相对非假期充足的时间 |
| 产品期望 | 可以接受逻辑规则比较复杂，需要一定技术门槛的游戏；不希望游戏会花费太多时间(游戏结果更取决于技术和临时决策，而非长期游玩的资本积累) |
| 支付情况 | 经济上有一部分的自主权，可以接受一些低价格短时体验的支付项目(角色试玩卡等，因为也不会有太长的游玩时间) |
| 典型场景 | 1.周末父母较忙，作业写完，可以玩上30min到1h的时间 2.假期在家写作业，自习，放松的时候听听歌，来上5-10min的一场对局 |
用户类型3：
| 属性 | 描述 |
|---|---|
| 姓名 | 李同学 |
| 身份 | 大三学生 |
| 年龄 | 21岁 |
| 潜在量占比 | 40% |
| 使用习惯 | 在放假，或者学期前期时间相当充裕，每天都有3-5的时间；在学期中后期，各类科目大作业和考期复习到来，或者有考研，公司实习，实验室项目的压力时，基本只有茶余饭有零碎的时间 |
| 产品期望 | 期望游戏能有一定的思维策略性，而不是无脑乱点；对游戏的建模特效有一定的要求；对游戏的社交功能有期望，希望能和认识的人一起玩游戏，也希望借助游戏交到志同道合的好友 |
| 支付情况 | 经济不完全独立，但有相当大的自主权，可以接受长期受益的支付(月卡，年卡等)；遇到自己心动的，但价格较高的支付项目(限定皮肤等)可能会购买，但会犹豫。 |
| 典型场景 | 1.时间充裕的时期，闲得无聊，和室友开黑打游戏，一打就是一下午，一晚上； 2.肝大作业，考期复习，经常摸鱼打游戏，但在压力下大概率能在10-15min后及时收手 |
用户类型4：
| 属性 | 描述 |
|---|---|
| 姓名 | 卢某 |
| 身份 | 游戏区主播 |
| 年龄 | 28岁 |
| 潜在量占比 | 25% |
| 使用习惯 | 专业游戏玩家，工作就是直播打游戏，每天都花费8-10h在电脑前直播打游戏，私下还会花费一些时间钻研游戏 |
| 产品期望 | 出于直播效果会对游戏的可玩性，画面，特效和建模要求较高；希望游戏有一定技术上限，能展示自己的水平和游戏理解 |
| 支付情况 | 会在游戏中花费高于普通玩家的资金，游戏消费可能有平台和官方的赞助 |
| 典型场景 | 1.有自己主玩的游戏，但在排位等待或者休闲娱乐的时候会考虑玩一些轻松有趣的游戏消遣； 2.在粉丝互动环节，会选择这种轻量级，门槛低的游戏，让大家都能玩得开心 |
预期功能：用户能够在市场主流的安卓系统手机上成功注册、登录、选择场景并运行游戏。对于注册功能，系统应当自动检查用户名和密码的合法性并给予用户实时反馈，帮助用户纠正错误。登录时应当核对用户名和密码能否准确匹配，不匹配时能够拒绝用户的登录，匹配能够成功跳转到游戏开始界面。选择场景时要求用户选择的难度、地图、卡牌能够正确地在后续游戏中呈现，游戏运行时要求卡牌的选择和拖拽应当灵敏，人物的走动必须在地图的边界内，不应当有不符合逻辑的异常现象。对于联机交互，要求从进入房间、加载场景、游戏交互、退出联机等一系列操作都能保持同步，并且在两端时延同步可容忍的情况下，必须保证操作的同步是按序完成的。
项目发布的功能
以下内容为本产品的发布文档：
实际满足情况
能够满足大部分典型场景。
对于第一类用户（以小汪同学为代表的小学生），当仅使用一个卡牌以及简单地图时，游戏的规则简单，耗时短。用户只需无脑购买骑士并在合适的时机将骑士投入战斗即可享受到游玩的乐趣。同时，对于简单模式，游戏耗时较短，十分钟以内即可分出胜负。
对于第二类、第三类用户（以张某、李某为代表的高中生、大学生），当使用多种卡牌时，需要考虑排兵布阵的多种组合和可能，同时由于对手的排兵布阵也是机动可变的，因此这实际上成为了一个博弈问题，具有一定的技术门槛，可以让高中生享受到游戏的乐趣。
对于第四类用户（以卢某为代表的游戏主播），我们虽然满足了游戏的轻量级、门槛低等条件，由于暂时没有开通支付渠道，同时对于高级卡牌的设计还不够完备，卡牌和场景数量不够多，因此无法完全满足主播这类高技术人群对游戏的需求。
用户使用产品的过程和评价
| 姓名 | 年龄 | 过程 | 评价 |
|---|---|---|---|
| 吴为x | 10 | 用户选择进入单人模式的是Map1的简单难度，用了1个骑士卡片 | 好玩的，当然很好玩！蓝鞋子战士很牛X，而且杀他们杀得很爽！ |
| 卢x言 | 15 | 用户选择进入单人模式的是Map2的困难难度，使用了2个骑士卡片 | 我觉得动画效果还挺好的，不过关卡太难了点，每次都被团灭，也许多玩几次会好一点，当然也可能是因为我太菜了... |
| 陈xx | 19 | 用户选择进入单人模式的是Map4的正常难度，使用了4个骑士卡片 | 我觉得可玩性挺强的，我打了三把每把都用的是不同的阵，我觉得巫师配合骑士的效果最好，不过如果遇到对面特别莽的也容易被团灭，还得提前预判...我觉得这比较适合在公交车上或者地铁上打，在休息的时候爽两把也是极好的。 |
| 凯x丹 | 21 | 进入多人游戏模式，开始联机游戏 | 游戏挺好玩，双人联机这个功能很赞，之前只能和电脑战斗的方式很快就没意思了，现在能够联机战斗，让这款游戏的可玩程度大大提高了，先让我找我的好基友玩一局。 |
| 马x浩 | 25 | 首次打开app | 第一次玩该类游戏，曾经听说过自走棋这种形式的游戏，平时还是玩fps多。进入游戏即有教程引导，感觉不会让我那么陌生和慌乱，进入游戏也有游戏玩法介绍，还是可以的。 |
三、用户日活
同展示部分
四、特色功能
-
项目的杀手级功能：相比于传统的自走棋游戏，我们的游戏注重的是局内轻量化的玩家策略与对战机制，玩家在不进行联网时也能快速地加载游戏，进行人机对战。同时3D化即时战斗画面也增强了游戏表现力，联机支持直接通过通过加入同一游戏房间进行游玩。总的来说，我们的优势在于创新的玩法和的游戏形式
-
相关竞品比对：《云顶之弈》手游随机性过强，玩家不能自由组卡，我们引入卡牌系统增强了玩家决策的自由度。而《炉石传说》中战斗为回合制，所以没有实现非必要的3D效果，而我们的游戏中战斗均为即时画面，所以使用3D化的场景，并加入了战斗特效、音效等元素增强了游戏的表现力。
在多人联机方面，本游戏简化了相关网友中复杂的联机/匹配机制，玩家通过房主-玩家的模式进行共同游玩，在多人联机的启动界面，用户可以选择创建指定ID的房间成为房主，或输入已创建的房间的ID以普通玩家的身份加入房间。房主可主持游戏的开始，双方中任一方退出游戏场景时，双方都将回到对战房间，而房主退出时另一玩家将成为房主以保持住房间资源。
-
团队成员对这些功能的自我评价如何，是否达到了预期目标，为什么？
UI开发组：有一定的3D战斗效果，不过可以考虑加入更多的特殊卡牌
网络编程开发组：希望可以持续改善联机功能的用户体验，以及对游戏性能进一步优化
五、软件工程质量
同展示部分
