73
社区成员




项目 | 内容 |
---|---|
这个作业属于哪个课程 | 2024年北航敏捷软件工程 |
这个作业的要求在哪里 | [T.17] 团队项目:Beta 阶段项目展示-CSDN社区 |
我们在这个课程的目标是 | 学习敏捷开发的思想,合作开发出一款优秀有趣的软件 |
这个作业在哪个具体方面帮助我们实现目标 | 对 Beta 阶段的工作进行总结与展示 |
成员 | 分工 |
---|---|
洪陈天一 | 游戏设计、数值策划、团队管理、文档撰写、宣发、功能测试、美术设计与审核 |
石睿知 | 背包界面美化,教程设计、开发 |
黄泓亮 | 图鉴设计、美术、开发,节点图功能迭代 |
赵彦豪 | 战斗界面、防御塔、组装件、敌人美术调研应用,战斗美术表现优化 |
朱宇 | 战前预览功能开发,敌人生成与索敌功能优化,若干问题修复 |
丁梓星 | 完善战斗界面信息显示,部分音效素材填充,buff 系统开发 |
钟彦童 | 事件、商店系统开发,音乐音效选取与系统开发,主界面设计,界面美术设计 |
线上与线下相结合。
使用 Github 进行代码管理
例会报告使用 Notion 进行管理
重要信息使用 Github Issue 进行管理
使用 Github Issues 进行任务管理。
Collapsar 是一款融合了组装功能与肉鸽要素的塔防游戏。
在 Beta 阶段,我们:
组装件玩法
组装件是我们在游戏中设计的一种具有代表性的特殊资源,其可以装配在防御塔上,为防御塔提供攻击模式与数值提升。
我们的核心玩法便是围绕组装件与防御塔展开。组装件主要分为以下三种:
攻击型:能够发动攻击(或是其他即时效果),是最重要的组装件,若未装配则防御塔无法进行攻击。
加成型:能够提升攻击型组装件的效果,对攻击型组装件的不同数值进行修改。
持续型:能够为防御塔带来持续性的提升。
攻击型与加成型组装件在防御塔内循环触发,依次发动效果,发起攻击或对后续组装件产生影响;持续型组装件不主动触发,直接对防御塔进行加成。在组装件强化防御塔的同时,也会影响防御塔的费用,使其变得“笨重”。防御塔为组装件的容器,不同的防御塔会对组装件的最终伤害效果有不同的加成。因此,玩家需要合理搭配不同的防御塔与组装件,得到最佳的配合,才能轻松通关。
在游戏流程中,玩家会有大量机会获取效果不同的防御塔和组装件,并组装强化防御塔,加强自身的战斗力。
我们的 assets 代码统计结果如下:
language | files | code | comment | blank | total |
---|---|---|---|---|---|
C# | 100 | 9,184 | 1,110 | 1,335 | 11,629 |
UnityShader | 18 | 2,439 | 82 | 662 | 3,183 |
JSON | 6 | 1,445 | 0 | 4 | 1,449 |
我们的项目可维护性指数为 78,同时所有的类可维护性均达到绿色评级,代码可维护性良好。
参考了 Unity Code Style Guide 代码规范文档,规范了以下规则
this
使用规则var
使用规则我们参考了 roife 在 2022 级北航软件工程的团队开发中编写的规范以及课程组提供的相关规范进行执行。
配置了 .NET Checkstyle 的 ci 脚本,对每次 pr 的代码风格进行检测,并给出修改建议。
请看实操
团队成员的简介和个人博客地址。
它会蜷缩身体,并以迅疾的速度旋转移动。
可以利用能力制作黄油。
兄弟,你好香。
它装出一副威风凛凛的样子,其实胆小软弱。
如果被它看不起,
某种意义上可谓奇耻大辱。
也不知为何总是被当成宠物。
但可爱就是正义。
它只要走在坡道上就肯定会跌倒并滚动起来。
而且还会因为眼冒金星而无法动弹,
非常容易被当做是猎物,是食物链的底层。
兄弟,你怎么是2D的
天哪,我是第一次这么近距离跟羊接触!手感好好!
具有会为伙伴加油的习性。
给伙伴加油的时候,会通过让体内发出的电流短路,从全身发出电火花并噼里啪啦地发光。
如果伙伴输了,就会放声大哭。
它眼神凶恶,朋友也很少,
但其实心地很善良。
团队是如何进行项目管理的?相比于Alpha阶段有什么改进?
项目管理见上。
团队的成员如何分工协作的?有什么经验教训?相比于Alpha阶段有什么改进?
根据个人意愿与Alpha阶段负责内容进行分工。执行效果较好,但美术方面可能还是安排对美术更有感觉的人会更好(不过由于人员限制目前已经很不错)。
团队成员如何沟通和对接的?有什么记录留存?
主要通过线上wx讨论和线下集中开发沟通。
团队如何平衡 时间/质量/资源 争取如期完成任务的?
合理规划任务目标,提前了解成员时间安排,并根据工作进度随时调整。
团队项目的实际进展如何(拷贝那些 scrum 过程中的燃尽图即可)?在项目管理中,scrum的燃尽图是如何真实反映项目的状态的?或者燃尽图美化了状态?
我们的进度由于计网实验与计网理论考试有不同程度的延误,可以在scrum图上比较明显地看出来。
既然同学们选择上这个软件工程课,那么就希望大家能够认真的参与到软件工程实践中来。当然,同学们的投入程度会有所不同,所以我们就把大家做了哪些工作亮相给大伙看看,把这些情况量化出来,摆在大家面前。 酱油在哪里,大腿在哪里就一目了然。这样我们的团队贡献分就很好决定了。所以,请各团队列出成员在 Beta 阶段的角色和具体贡献(课程组将据此核算团队各成员得分是否合理):(待完善)
名字 | 角色 | 团队贡献分 | 具体的, 可衡量的, 可验证的贡献 |
---|---|---|---|
洪陈天一 | PM & Test | 50 | 27 commits,551++,776-- ,进行了游戏的总体设计与数值设计,撰写了大部分全部文档,与成员共同完成其余文档。 |
钟彦童 | Dev & Test | 54 | 95 commits,3783 ++,1221--,共同完成了节点图,完成了事件、debug与音乐音效系统。 |
石睿知 | Dev & Test | 52 | 62 commits,5596 ++,968--,完成了背包部分与教程系统。 |
朱宇 | Dev & Test | 51 | 61 commits,3977++,2300--,完成了敌人部分与诸多调整。 |
黄泓亮 | Dev & Test | 50 | 90 commits,3306++,775--,共同完成了节点图,完成了图鉴系统。 |
丁梓星 | Dev & Test | 47 | 61 commits,3122++,1027--,完成了战斗场景与buff部分。 |
赵彦豪 | Dev & Test | 46 | 32 commits,1607 ++,695--,完成了防御塔部分,同时完成了美术素材搜索应用。 |
项目开发前的目标,预期的典型用户场景,预期的功能描述。
Beta目标:教程、商店、遗物、图鉴系统,音乐与美术内容。
用户场景:新人玩家使用教程、高手玩家分析图鉴,所有场景均有音乐与美术等。
项目发布的功能(拷贝发布文档),在哪里发布了软件。
项目发布后是否满足了全部典型场景?剩下的为何没有满足?
满足了典型场景的绝大部分内容,但游戏背景故事相关由于工作量较大与文案的缺失并没有完全满足。
项目发布后真正符合用户需求了吗?列出目标用户使用产品的过程和评价。
符合PM作为一个玩家想要玩到的内容()但可玩内容需要一定提升,这是需要大量工作量与设计的内容,在软工课内我们没有大量填充。
项目发布时团队做了哪些努力来推广项目?
如上,我们在年级群与若干其他校内校外群进行了宣传。值得一提的是,PM本人还在某二次元塔防游戏交流群进行了宣传。
软件的日活跃用户量是否达到了预先定义的数量?如果没有达到,你们觉得可能是什么样的原因导致的?你们认为还有什么指标可以佐证你们的软件对用户“有用”?
我们无法精准统计用户量,但根据常见独立游戏用户群玩家数量与总玩家数量估算,我们应当接近预期用户量。用户量不足主要由于缺少前期积累,宣发不足,上线较晚。我们可以根据玩家反馈来判断游戏的可玩性。
是否有用户在功能改进上有所反馈?可以提供用户反馈的截屏。
是的。我们在收到用户反馈后加紧开发了若干功能。
是否有用户在Bug上有所反馈?有什么样的bug?这是预料之中的还是没想到的?
有。存在许多预料到与没遇到到的bug,包括:
项目的杀手级功能,与竞品相比最特色的功能展现。
见上
思考一下竞品出于什么原因并没有囊括该特色功能,团队凭借什么样的优势实现了它?
独立游戏的杀手功能往往是玩法的创新,因此竞品可能并没有想到这一杀手功能,团队凭借PM玩一大堆游戏激发的灵感对塔防游戏的思考与延伸实现了这一新的玩法。
团队成员对这些功能的自我评价如何,是否达到了预期目标,为什么?
很不错,基本达到了预期目标。
用户对这些功能的评价如何,是否认为这些功能富有特色,为什么?
认为我们的杀手玩法是很有趣的。
项目有完善的文档吗,是否有约定代码规范?
有约定代码规范,但文档可能不够完整。
项目是否有出现代码混乱,没有注释,没有详细文档的问题?明年的同学继续开发这个项目,会不会出现以上抱怨?如果一个新学生在一台新机器上想编译并运行你的项目, 请问能顺利完成么?有什么样的文档能指导新学生?
代码可维护性高,注释详细,拥有相关信息文档。同时,由于 Unity 对各平台支持的很好,新学生应当有较高概率能够顺利完成。
项目是否有单元测试,测试用例数目,代码覆盖率等。
无
项目是否采用了CI/CD等软件工程工具,并说明理由。
使用 CI 进行代码风格检查,没有使用其他相关工具,因为我们开发游戏决定了我们并不需要。
学到的经验和教训:整个团队在Beta阶段学到了什么,对软件工程有什么样的经验教训?
感觉学到了很多吧。
代码质量:部分命名约定并未被严格执行,同时有些代码可维护性很差,需要提升代码编写与code review要求。我们的自动化CI脚本推出后解决了不少。
测试:我们进行的测试局限于部分环境,因此在一些性能不佳的设备上运行出现了未能预料的问题,需要全面的在不同环境进行测试。同时也可以考虑测试阶段即向小部分用户公开,通过用户游玩发现真实情境下出现的多种bug。