团队项目——Alpha阶段计划
团队项目——计划
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021学年春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 团队项目-计划 |
| 在这个课程的目标是 | 锻炼在大规模开发中的团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过在实践中分析一款软件产品，来切实体会软件工程在实际工作与生活中的应用 |
功能规格说明书
典型用户及场景
典型用户分析
- 由于这些用户之间交集较小，基本可以认为一类用户对应一个典型场景集合，所以将场景嵌入到用户描述中；
- 因为调查圈子有限，用户描述只有一小部分取材于问卷调查，大部分来源于查阅和借鉴其他资料，数据；
- 我们在每一类用户中只列举了典型场景，对于场景的分析和与我们产品的联系则放在下一部分。
用户类型1：
| 属性 | 描述 |
|---|---|
| 姓名 | 小汪同学 |
| 身份 | 小学五年级学生 |
| 年龄 | 12岁 |
| 潜在量占比 | 20% |
| 使用习惯 | 小学课业压力相对较小，娱乐时间相对充足；平时放学后，周末做完作业后有零零散散的时间；放寒暑假以及各种节日会有较长的时间 |
| 产品期望 | 希望游戏规则简单易上手；希望能和同学一起游玩；对游戏画面特效没有太高期望 |
| 支付情况 | 经济高度不自由，零花钱十分有限，压岁钱被父母管控，基本很少“氪金” |
| 典型场景 | 1.放学后和同学蹲公园打游戏，因为要回家吃饭时间比较仓促； 2.周末或假期在家打游戏，有较为充足的时间。 |
用户类型2：
| 属性 | 描述 |
|---|---|
| 姓名 | 张某 |
| 身份 | 高二学生 |
| 年龄 | 17岁 |
| 潜在量占比 | 15% |
| 使用习惯 | 课业压力相当大，平时基本不会有时间，在非考试复习的周末可能会有0.5-1h的时间；假期在作业，补习和自习时间的间隙会有比较零散但相对非假期充足的时间 |
| 产品期望 | 可以接受逻辑规则比较复杂，需要一定技术门槛的游戏；不希望游戏会花费太多时间(游戏结果更取决于技术和临时决策，而非长期游玩的资本积累) |
| 支付情况 | 经济上有一部分的自主权，可以接受一些低价格短时体验的支付项目(角色试玩卡等，因为也不会有太长的游玩时间) |
| 典型场景 | 1.周末父母较忙，作业写完，可以玩上30min到1h的时间 2.假期在家写作业，自习，放松的时候听听歌，来上5-10min的一场对局 |
用户类型3：
| 属性 | 描述 |
|---|---|
| 姓名 | 李同学 |
| 身份 | 大三学生 |
| 年龄 | 21岁 |
| 潜在量占比 | 40% |
| 使用习惯 | 在放假，或者学期前期时间相当充裕，每天都有3-5h的时间；在学期中后期，各类科目大作业和考期复习到来，或者有考研，公司实习，实验室项目的压力时，基本只有茶余饭后有零碎的时间 |
| 产品期望 | 期望游戏能有一定的思维策略性，而不是无脑乱点；对游戏的建模特效有一定的要求；对游戏的社交功能有期望，希望能和认识的人一起玩游戏，也希望借助游戏交到志同道合的好友 |
| 支付情况 | 经济不完全独立，但有相当大的自主权，可以接受长期受益的支付(月卡，年卡等)；遇到自己心动的，但价格较高的支付项目(限定皮肤等)可能会购买，但会犹豫。 |
| 典型场景 | 1.时间充裕的时期，闲得无聊，和室友开黑打游戏，一打就是一下午，一晚上； 2.肝大作业，考期复习，经常摸鱼打游戏，但在压力下大概率能在10-15min后及时收手 |
用户类型4：
| 属性 | 描述 |
|---|---|
| 姓名 | 卢某 |
| 身份 | 游戏区主播 |
| 年龄 | 28岁 |
| 潜在量占比 | 25% |
| 使用习惯 | 专业游戏玩家，工作就是直播打游戏，每天都花费8-10h在电脑前直播打游戏，私下还会花费一些时间钻研游戏 |
| 产品期望 | 出于直播效果会对游戏的可玩性，画面，特效和建模要求较高；希望游戏有一定技术上限，能展示自己的水平和游戏理解 |
| 支付情况 | 会在游戏中花费高于普通玩家的资金，游戏消费可能有平台和官方的赞助 |
| 典型场景 | 1.有自己主玩的游戏，但在排位等待或者休闲娱乐的时候会考虑玩一些轻松有趣的游戏消遣； 2.在粉丝互动环节，会选择这种轻量级，门槛低的游戏，让大家都能玩得开心 |
典型场景分析
在我们的分析中，虽然每一类场景集合只包含一类用户，但这并不意味着用户之间的关联性不明显，这些场景中他们体现出的游戏习惯和产品期望都有如下两点共性：
1. 轻量级和短时性
从快乐自由的小学生到题海书山的高中党，再到游戏为业的主播，他们都有自己的主流生活节奏，都希望有一个丰富有趣的能填充生活空隙的娱乐方式，但绝不希望这个方式挤占他们的主流时间。
这正好对标我们产品的核心理念：轻量级；在保持趣味性和可玩性的前提下，我们还能让用户得到短时间的游戏体验，而不是又肝又氪，费力不讨好。
2. 联机和交友
这些用户群体中大多都体现出社交方面的需求：小学生公园五连坐，大学室友宿舍背靠背，主播与粉丝连麦互动；这也为我们的产品提出了联机对战的需求。
我们会在前期实现局域网联机的功能，并在后期推广到广域网，为用户提供一起游玩的游戏体验。
规格书术语说明
- 卡牌/角色/棋子(游戏内)
描述：游戏运行机制内的基本单位，游戏场景中玩家的召唤物，拥有自治的生命周期与控制逻辑，在玩家的放置阶段在游戏场景被实例化，在战斗阶段进行自动的寻路与攻击，并在被击败后进行绑定对象的销毁
- 状态转移
描述：软件系统整体的状态机，游戏运行时根据用户输入或当前状态进行状态的变更，并进行相应UI与游戏中脚本绑定对象的更新、游戏场景的跳转、暂停、恢复、创建、销毁
游戏可能存在的问题、副作用以及解决方案
-
如何解决游戏发布初期缺少人气与曝光度的问题？
由于每个游戏都有较为固定的玩家群体，因此我们计划在游戏上架安卓平台后：
-
在NGA、掌盟、TapTap等游戏论坛的自走棋、卡牌桌游等相关板块发布游戏信息，与宣传视频，下载链接。通过我们前期需求分析的问卷调查结果能够显示，游玩过自走棋或卡牌游戏的玩家，对我们开发的游戏的期待值远高于没有游玩过这两种类型游戏的玩家。因此我们有理由相信，凭借大量的自走棋与卡牌游戏玩家基数，在各大游戏论坛的对应板块发布新游戏信息/广告，能极为高效且直接地吸引大量潜在用户。
-
在Bilibili、抖音设立专门的官方账号，投稿游戏宣传视频。
随着弹幕影片分享网站与短视频的风行，B站与抖音占据了当代青年网民大部分的网上冲浪时间。根据调查数据显示，2020年B站月活跃用户突破2亿，日活跃用户达到5300万，日均用户视频播放量突破13亿次；而抖音日均视频搜索次数达到4亿次，日活跃用户突破6亿。因此，想要快速提升游戏的曝光度，借助各视频平台高流量的特性是刚需。
-
在炉石传说、三国杀、云顶、Dota自走棋等游戏QQ群里发布宣传视频与游戏信息，并建立我们游戏的玩家交流群。
首先，根据笔者自身的体会，游戏QQ群中成员申请入群的原因主要在于 “一人游玩过于孤单，希望找到有共同兴趣的团体，交流游戏心得体会”，所以可以将游戏QQ群看作微缩版的游戏论坛，并且更为精炼，成员间交流更为直接、方便。因此在这里进行宣传能更好地利用玩家间的相互作用，从而二次构成特定用户生态。
其次，决定一个游戏能否长期保持充足的用户活跃度的很大的一个因素是：“是否形成了较为稳定且活跃的玩家圈”，即只有当有玩家愿意去与他人讨论、研究游戏机制、战术，并向官方反馈游戏存在的问题，才能使玩家与玩家，玩家与游戏制作者之间形成连通的交流闭环。因此我们会建立专门的玩家交流群，供玩家们商讨战术玩法，以及提供直接向官方反馈意见的渠道。这样不仅能拉近玩家间的距离，同时还打破了裁剪玩家与软件开发者之间的隔阂，让大家能共同努力，维护一个良好的游戏生态圈。
-
-
你们的游戏与其他竞品相比有什么优势？从名字上看更像是云顶与炉石两款游戏的杂交体，是否考虑过鱼和熊掌不可兼得的道理？
与其说我们是炉石传说与云顶之弈的杂交体，不如说我们将云顶之弈等自走棋游戏的“3D对战"“随机索敌”元素 与 炉石传说等卡牌游戏的“卡牌培养””卡组搭配“等游戏元素相结合，同时加入我们自身对游戏市场需求的理解，形成了我们独一无二的产品。
根据我们需求分析阶段的市场调研，超过半数的卡牌游戏玩家认为”在卡牌游戏中加入3D对战动画能够提升游戏的表现力与感染力“，而80%以上的自走棋游戏玩家认为”如何更好的利用碎片化时间“”如何增强游戏的社交性(参考王者荣耀)“是如今PC端自走棋游戏需要突破的地方。
因此，我们将目前市面上的两类游戏取其精华去其糟粕，在兼顾自走棋游戏3D动画表现力与卡牌游戏战术多样化的同时，尽可能地简化去除繁琐无用的游戏功能(如战歌竞技场中的工会、宠物系统等)，让用户能随时随地，高效快捷地与朋友开启一把趣味对决(类比微信跳一跳)。
综上，我们游戏的核心竞争力在于： ”轻度“ 与 ”精致“二词，即其设计理念在于，吸引玩家更为频繁登录游戏，在每次较为短暂的游玩时长里享受精致的游戏画面，精巧的游戏设计，以及与好友对战的喜悦，而非重度沉迷于传统游戏中的氪金强化系统，或者浪费本身就极为宝贵的休闲时间在没有意义的系统加载、繁琐重复的每日任务中。
界面原型设计的axure截图
系统功能描述及验收验证标准
Alpha阶段
各个界面的状态转移如下：(进入游戏时位于主界面)
| 当前 | 事件 | 下一状态 |
|---|---|---|
| 主界面 | 点击开始游戏 | 模式选择界面 |
| 主界面 | 点击退出游戏 | 游戏退出 |
| 模式选择界面 | 点击快速开始 | 难度选择界面 |
| 模式选择界面 | 点击挑战 | 挑战关卡选择界面 |
| 模式选择界面 | 点击返回 | 主界面 |
| 模式选择界面 | 点击卡组管理 | 卡组管理界面 |
| 卡组管理界面 | 点击返回 | 模式选择界面 |
| 难度选择界面 | 选择难度后点击开始游戏 | 游戏界面(即正式进入游戏) |
| 难度选择界面 | 点击返回 | 模式选择界面 |
| 挑战关卡选择界面 | 选择相应关卡后点击开始游戏 | 游戏界面(即正式进入游戏) |
| 挑战关卡选择界面 | 点击返回 | 模式选择界面 |
| 游戏界面 | 点击菜单按钮 | 游戏内菜单界面 |
| 游戏内菜单界面 | 点击退出游戏 | 主界面 |
| 游戏内菜单界面 | 点击返回 | 游戏界面 |
| 游戏内菜单界面 | 点击重新开始 | 游戏界面 |
其中验收标准需满足所有转移均可正常进行，因此如无特殊情况不再赘述。其他验收标准如下：
| 视图 | 操作 | 验收标准 |
|---|---|---|
| - | 进入游戏 | 正常显示主界面 |
| 难度选择界面 | 选择难度后点击开始游戏 | 1.以所选难度正常开始游戏 2.游戏加载时间位于可接受范围内 |
| 挑战关卡选择界面 | 选择相应关卡后点击开始游戏 | 1.正常开始与所选关卡对应的游戏 2.游戏加载时间位于可接受范围内 |
| 难度选择界面 | 已经进行过一次难度选择后，再次进入难度选择界面 | 难度默认显示为用户上次进行游玩时所选择的难度 |
| 卡组管理界面 | 管理卡组 | 1.用户选择使用的卡牌数量必须限定在一定范围内 2.选定卡组后，战斗时用户随机到的卡牌只可能在选择的范围内 |
| 游戏内菜单界面 | 游戏中点击菜单按钮 | 暂停游戏，用户点击返回后则恢复游戏运行 |
| 游戏中的放置阶段 | - | 1.正常显示游戏画面，包括正常显示我方HP、敌方HP、卡牌等 2.放置阶段用户点击卡牌时，若金币足够则相应角色出现在战场上并扣除相应金币，否则操作无效 3.放置阶段用户拖拽改变棋子站位时，拖拽过程中正常显示可放置方格，用户将棋子放置在不可放置的地方时棋子自动回到原位 4.限制时间归零时强制开始进入战斗阶段，此时用户仍在拖拽的棋子将回到原位 5.每次放置阶段开始时能自动增加相应金币，并随机获取一组新的卡牌 6.用户使用金币进行刷新时，金币足够则扣除金币并重新获取一组新的卡牌，不够时不进行任何操作 |
| 游戏中的战斗阶段 | - | 1.双方棋子都能够自动找到敌方棋子并进行攻击，不能出现棋子完全不攻击对方的情况 2.双方棋子能按照自身属性给予相应的伤害(或是治疗、属性加成等) 3.HP归零的棋子立即消失，其他棋子不会以HP归零的棋子为目标 4.战斗结束后按照相应的方法给予某一方HP伤害 5.如果己方有三个或以上相同角色，则这三个角色将变为一个更强力的角色 |
| 游戏中 | - | 1.我方HP最小值为0，我方HP归0时游戏结束，显示相应失败画面 2.敌方HP最小值为0，敌方HP归0时游戏结束，显示相应胜利画面 3.无论失败还是胜利画面，均提供重新开始选项，即以相同的设置再来一局 4.无论失败还是胜利画面，均提供返回模式选择界面选项，用来返回模式选择界面 |
- 用户目标：在TapTap或应用市场等平台上架，估计下载量100人左右
- 日活跃用户：Alpha阶段为单机demo，故难以统计日活跃用户，但目标可以设为10人
- 对于Alpha阶段，主要收集数据为用户反馈(通过社区评论、问卷调查等方式)以及下载量的统计
Beta阶段
此阶段新增功能暂定为：
- 主界面中新增“本地联机”和“线上游戏”选项。选择“本地联机”后可以正常进行局域网联机游戏，选择“线上游戏”后则可以正常进行网上对战
- 新增特殊效果卡牌，使用后可以触发特殊效果
- 增加更多的属性
- 增加更多的趣味挑战关卡
验收标准除满足Alpha阶段要求外，要能正常实现以上功能。
- 用户目标：估计下载量300人左右
- 日活跃用户：目标为20人，鉴于用户量可能比较少，本阶段虽然可以联网进行玩家对战，但不一定能匹配到玩家，因此统计方式可能会采用在线签到礼包
- 数据收集渠道除Alpha阶段所提及的方式外，还可能在游戏内设置线上渠道，使得反馈更为快捷
技术规格说明书
技术栈
- 前端
- 开发环境系统：Windows 10
- 游戏设计语言和框架：
Unity，版本：2020.3.3f1c1 LTS
C#
* 应用端运行环境：Android 10或更高版本
* 应用端适配开发工具包：
Java JDK
Android SDK
前端主要利用Unity引擎开发游戏界面，并且利用C#编写游戏中角色活动机制。选择Unity3D进行游戏开发，正是由于其编程周期短、模块丰富的优点，较为适合本次软件工程的开发规模和速度。其次，Unity可移植性很高，可以较为容易的在多平台进行打包发布，便于本项目未来可能对iOS平台的延伸部署。C#是Unity主要是用的脚本编程设计语言，它的语法同C/C++及其相似，但又充斥着现代面向对象设计的思想，较为适合新手快速上手，使得本项目能够在简单学习后快速上手进行开发。
- 后端
- 系统：Ubuntu，发行版版本：20.04.1
- 编程设计语言：Python，版本：3.8.5
- 框架：Django，版本：3.2
后端采用基于Python语言的Django这一Web应用框架，Django具有低耦合、开发快捷、部署方便等优秀的特性，相较于Tomcat，Django无需过多配置即可快速建立一个可部署的开发环境，易于本项目敏捷开发的特性。同时，Django具有强大的数据库管理功能，将数据库底层管理封装起来，让技术人员对数据库的增删改查更为便捷。最后，Django提倡优雅的URL设计模式，这种设计模式使得API更加清晰易懂，方便了前后端人员对API接口的设计、使用。
- 数据库
MySQL，版本：8.0.23
本项目数据库管理系统将使用MySQL，作为一个老牌关系型数据库管理系统，它从稳定性、兼容性、易用性等多个方面都较为出色，并且，Django框架能够很好的适配MySQL，为我们的后端开发提供了许多便捷。
总体架构
本项目总体包括前端Unity、后端Django、MySQL数据库等几个子系统，前后端利用预先定义好的API进行交互，而前端主要采用MCV的设计模式，Model存储各类对象的数据和信息，Controller接受用户交互，根据用户数据和控制逻辑修改Model内容，View利用不同的Model和数据，为用户提供不同的视图进行交互。具体结构如下：
前端子系统主要有如下几个模块：
- 游戏玩家
游戏玩家主要分为：用户本人、电脑AI、以及联机玩家，我们设计统一的「对战者」接口以方便后期的扩展，这种设计方式也便于其他模块对于玩家模块的使用。
- 竞技场景
竞技场景分为单机模式和联机模式，单机模式中玩家可以对AI进行不同难度、不同关卡的选择来开始游戏，联机模式中玩家与在线其他玩家连线对战。同时，竞技场集也负责展示玩家放置卡牌的战斗交互场景。
- 个人展示
个人展示主要包括玩家的个人信息，如昵称、头像、角色等级等。
- 卡牌场景
卡牌场景主要展示个人拥有卡牌，在抽卡环节的特效展示，以及游戏中玩家发卡部分的UI展示。
- 场景管理
场景管理负责上述场景的转换逻辑和切换效果。
- 用户信息管理
该部分负责联机中对联机双方的信息管理。
- 卡牌管理
集中管理用户牌组的增删改查。
- 网络模块
建立一个与后端交互的逻辑封装模块，使得网络部分的引入不会改变项目整体的耦合性。
后端子系统主要利用URL进行服务分层，SQL子系统仅负责数据表的管理，行为较为简单，内部模块无需过多介绍，详见数据库与API接口设计章节。
功能详细设计
数据库与API接口设计
数据库设计
用户数据表：
| 字段 | 类型 | 含义 |
|---|---|---|
| username | CharField(128) | 用户昵称 |
| password | CharField(256) | 用户密码 |
| EmailField | 用户邮箱 | |
| sexual | CharField(32) | 用户性别 |
| c_time | DateTimeField | 用户账号创建时间 |
卡牌数据表：
| 字段 | 类型 | 含义 |
|---|---|---|
| player | ForeignKey | 卡牌所属用户 |
| type | IntegerField | 卡牌类型 |
| level | IntegerField | 卡牌等级 |
API设计
| URL | 请求方法 | 含义 |
|---|---|---|
| /user_manage/card/get_cards/int:user_id | GET | 获得用户所有卡牌信息 |
| /user_manage/card/set_card/int:card_id | POST | 新增/修改卡牌信息 |
| /user_manage/user/token-auth | POST | 用户登陆API |
| /user_manage/user/register | POST | 用户注册API |
系统的开发目标
1. 代码编写
1. 游戏服务端
1. 服务器数据库设计与建表
2. 使用实体数据类对数据库操作进行封装
3. 负责信息传输的接口实现，在联机功能实现时利用**Socket**等完成实时通信
4. 质量工程，保证在beta加入联机时可以增量开发
5. 必要的注释（如核心代码）
2. 游戏客户端
1. 客户端整体界面、卡牌UI、模型特效的编写
2. UI交互逻辑，不同关卡游戏场景的创建、跳转
3. 游戏内角色（玩家召唤物）的生命周期与交互行为逻辑控制
4. 游戏内对局整体流程的逻辑控制
5. 游戏内战术意义上的AI（玩家的召唤物自动寻路与攻击），不同层级AI的难度区分
6. 游戏内战略意义上的AI（作为电脑AI的布局、经济策略），不同层级AI的难度区分
7. 游戏内UI与游戏场景/对象的交互对接
8. 质量工程，考虑如何实现进行多样化的技能，通过模块化解耦避免特殊的技能与核心机制的冲突
9. 负责信息传输的接口调用，在联机功能实现时利用**Socket**等完成实时通信
10. 必要的注释（如核心代码）
- 单元测试
- 就游戏客户端而言，使用NUnit, UnityTestTool等测试框架完成抽离于场景的游戏运行逻辑的模块化测试，包括游戏中的单个卡牌（棋子）对象、对局交互逻辑
- 就游戏的服务端而言，使用pytest,unittest等三方测试库进行针对数据库的单元测试
- 系统压力测试与指标
- 在游戏场景中玩家的召唤物到达上限，并启用对应动画特效时，测试其在中高低端机型上的表现，监控游戏的帧数、资源占用量，评估是否有掉帧或卡顿的现象
- 联机部分(beta)进行玩家操作时延(ping)的监控，通常即时游戏中ping达到150~200ms将被认为是不可忍受的，测试指标为玩家操作时延普遍达到150ms前可连接的玩家总数
- 真实测试
- 开发组吃狗食，保证在开发过程中持续使用软件，快速反馈自身的用户体验，同时找出客户端UI展示相关的bug
- 于不同移动设备进行游戏的性能测试，主要体现在不同设备游戏运行时所占用内存、游戏平均帧率
- 发布阶段展开用户测试，用户试玩后及时给出反馈的界面或链接
- 系统文档
- 游戏客户端与游戏服务端的交互接口设计，详细到数据结构，url，以及所属模块
- 游戏核心机制说明书，以形式化的语言表述
- 游戏客户端中前端UI与后端逻辑的交互，详细到方法与参数的实际意义
Alpha阶段初始任务分配
详见石墨文档
gitlab截图：
团队贡献分——分配方案
分配概要
矩不正，不可为方；规不正，不可为圆。
首先，在团队中，需要为大家定下一个准则基调，不论是例行开会还是工作开发，我们每个人需要有一致的前进方向，“合作共赢”，这个词正代表了协作中每个人最重要的任务和共同目标，因此，希望大家遵循如下的基本要求：
- 按时完成分配的工作，保证基本质量
- 暗示参加例行会议，并如实汇报当前工作进度
- 戮力同心，有建议、问题或困难，及时反馈。
团队贡献的评定，既是对每个人工作的肯定，也是团队对个人工作进度和质量的监督。同时，绩效考核作为一个评价个人工作完成质量和效果的重要指标，也将引入团队贡献分的计算，该考核将从多个角度进行考量，以此更全面的展示任务的完成质量。最后，将引入互评机制，团队内每个人将对该任务的完成情况进行评价打分，从团队中其他合作者的角度更好的建立我们的评价体系。
综上所述，我们的团队贡献分将分为如下三个部分：
- 基础分（Base）：80%
- 绩效分（Performance）：10%
- 互评分（Mutual Evaluation）：10%
分配细则
基础分（Base）
基础分数为任务基本完成情况的评价分数，共40分，只要正常完成，即可拿到所有分数。
绩效分（Performance）
- 任务交付时间
| **** | 完成时间 | 得分 |
|---|---|---|
| 按时完成 | +5 | |
| 延迟1天 | +4 | |
| 延迟2天 | +2 | |
| 延迟3天及以上，耽误项目进度 | +0 |
- 任务交付质量
| **** | 测试代码覆盖率 | 得分 |
|---|---|---|
| 80%及以上 | +5 | |
| 60%及以上 | +4 | |
| 可正常运行 | +2 | |
| 无法正常运行 | +0 |
互评分（Mutual Evaluation）
组内成员互评，0分没有任何贡献，10分为贡献突出，取所有人评价均分，获得该贡献分数。
