/2020SpringProject

2020年春季学期软工大项目

Primary LanguageC++

弹幕术士!

简介

双击 HelloWorld.exe 进行游戏菜单界面使用鼠标控制,游戏中使用键盘控制

这是一个类似元气骑士,但是更多为弹幕回避要素的游戏:弹幕术士! 专心回避敌人发射的子弹吧! 因为是以弹幕为主,所以自机是具有判定点的,只有当自机的判定点碰到了弹幕才会被认为被弹哦!

通过方向键控制自机的移动方向,使用 shift 显示判定点并让自机移动的更加精确 按下z让自机发射子弹,按下 x 释放强力 bomb 保护自己 游戏过程中按下 esc 进入暂停界面,这时候也请用鼠标选择退出或是继续进行游戏 因为实现方法的问题,所以切换场景的时候有概率导致方向键卡住,这时候最好的方法是重启游戏(反正游戏也没多长对吧

在游戏过程中敌人会掉落各种道具,其中 p点 可以些许增加自机的火力,而每吃满 1.00P 则会大幅度增加自机的火力! 蓝点用于获取分数,如果想要得到高分那就请多收集一些蓝点吧! Bomb 道具用于回复自机持有的 Bomb ,最高不能持有超过8个,面对完全无法回避的弹幕时放心的用吧! LifePiece 道具用于回复自机1点 HpHp 上限为5,当 Hp 降为零时游戏就结束了,所以弹幕回避是非常重要的呢!

在关卡的最后会有一个非常厉害的大妖精,击破这只妖精游戏就结束了! 同时这只妖精也是非常厉害的呢,所以如果还剩有 Bomb 那就尽情的使用吧!

项目信息介绍

项目名

《弹幕术士!》

项目成员及贡献比例

​ 略

项目进度时间线

2020.5.14 项目开始,测试上传

2020.5.27 期间一直在研究 Bullet 类的实现方式,大概研究成型

2020.5.28 研究 直线激光 类和 曲线激光 类和 高光 效果的实现可能以及方式,均以失败告终

2020.5.29 第一个 自定义子弹 类完成

2020.6.04 敌人加载帧动画摸索,但是因为最后发现自定义 sprite 类无法使用提供的方法来创建帧动画而放弃。

2020.6.13 熟悉场景切换功能,探究应划分多个小场景还是大场景小视野,最后选择前者

2020.6.16 自机发弹完成

2020.6.17 物理碰撞大致实装, ui 外表实装

2020.6.18 跨 sceneplayer 大致完成,虽然还有很多缺陷

2020.6.19 item 基类和 Enemy 基类完成, ui 大体成型, p点 火力增加实装

2020.6.20 Bullet 基类的反弹实装,自机被弹效果实装,暂停菜单实装,随机生成地形实装

2020.6.21 boss 类大致完成, item 类完成,随机生成小怪实装,小怪掉落道具实装,项目结束,文档编写。

项目开发文档

游戏整体架构设计与小组分工

这是一个更加强调躲避敌人的弹幕而不是相互射击的平面竖版卷轴射击游戏,弱化了玩家的运气要素(指捡道具)

***制作了敌我双方的攻击方式(即弹幕)设计,参与文档编写、ppt制作

***进行了地形的生成及场景的切换,以及打杂,参与文档编写

***参与了 Enemy 类的制作和素材搜寻、绘制,参与文档编写、ppt制作

实现的功能点与实现思路

开始界面

主要就是菜单的实现。利用 MenuItemLabel 使用文本生成菜单。

键盘控制

方向键控制移动, shift 键进行精确的移动, z 键控制射击, x 键释放强力 Bomb 保护自己。自机射击方向会跟随移动方向,而按住 shift 可以固定这一方向。

因为使用的是通过按键获取键盘代码来控制自机移动的方式,所以当场景切换发生卡顿等情况极其容易导致方向不受正常控制

武器

power 来提升火力,每一个小 p点 增加 0.05 火力,每达到 1.00P 则增加一颗子弹

每次发弹时判断自机火力值,整除以100得到应该发射的子弹数量

自机具有 bomb ,实质是几个大判定自机子弹在自机周围绕圈。

敌人使用弹幕(后述)

敌人

Enemy基类:为具体的 Enemy 搭建框架

继承自 Enemy 基类的各种 Enemy ,每一种类型的敌人对应一个自定义 Enemy

Boss

继承自 Enemy 基类,具有较高的血条和极强的攻击能力(指弹幕

道具

实现了以下道具:

P_Point :增加自机 0.05 点火力和分数

BluePoint:增加最大得点 PointMax 所对应的分数

LifePiece:回血,增加 Player 的1点 HP ,最高不超过5

Bomb:增加 player 的1个Bomb,最高不超过8

关卡

Barriers 类制造地形(地形消弹功能丢失导致难度上升)

Door 类作为关卡间跳转

项目的技术难点与解决方案及解决过程

地形对象批量生成

​ 利用 for 循环在构造函数中实现。(由于 this 指针的特性,只能在每一个构造函数中添加相似的代码而没有模块化)

对经过关卡的状态进行保留

​ 定义全局变量作为是否去过该房间的参数,并进行判断是否刷怪。并在随机产生地形时使用 static 变量来确保为同一地形。(由于没想到办法保留原有的 scene ,走回头路只是创建一个不会刷怪的 new scene

弹幕的设计

这一部分大概是该项目时间投入最长的部分,起码半个月

Bullet 基类:实现最基本的简单子弹

实际上因为 cocos2dx 并未提供移动速度和角度这类接口,所以我们思考决定使用自带的 Move 函数作为子弹运动,将每一个动作按照1帧的时间间隔进行分解并且执行。

具体化了 Bullet 类所有的基本参数和函数接口,让 Bullet 可以不用像 Enemy 那样先继承才能使用,而是能直接作为简单子弹使用,调用非常方便。

继承自 Bullet 的各种自定义子弹类:实现各种需求的弹幕设计(甚至可以用来设计近战弹幕)

而敌人的发弹则是利用 CallFunc 可以自定义动作的特性,将每一种发弹作为一种动作传入。

其他亮点的部分

弹幕很漂亮哦!

项目运行截图

Image

Image

Image

Image

其他

学习过程中的困难

Cocos的学习成本还是比较大的,学习起来比较慢,使用也没有那么方便

“虽然想尽可能地打磨的更精细一些,但是我们还是极大地错估了此事的学习成本,与团队的磨合也花了较多的时间。因此导致了我们的项目相对来说十分粗糙。”

cocos 没个界面用起来真的好难难难难难难难难难难难难难难啊,每次都要找好多教程还是看的一头雾水,基本上写多少报错多少呜呜呜还是我太菜了,但有时候突然发现一个”

cocos2dx 这玩意怎么连个像样的教程都没有,查开发文档半天还查不到想要的功能,甚至一个类扔上去查无此结果。结果就是团队交流的时候差不多什么也得不到,反而还是自己脑洞占比高很多”

编程时的一些问题

其实真正开始干的时间晚很多,早期看这玩意基本是在研究 bullet 类、直线激光 类、曲线激光 类的实现,结果后面两个不还是因为完全不会写而被废除了。

弹幕需要 高光 特效的时候去查开发文档根本没有相应的颜色混合介绍,百度csdn出来的一对东西也是完全不知所云,于是只好放弃这一块。

当初要写地图的时候也在纠结半天要一个大地图还是几个小地图。前者不需要考虑继承 Player 的问题,后者不需要考虑地图不在视野内是什么情况的问题,讨论了几天最终还是决定使用简单的后者。但是这又带来新的问题,即切换场景键盘输入与缓存不一致导致卡键的问题,也是想不到换算法以外的解决方案。

在实装了道具系统之后,经常有完全不知原因的报错,初步分析是 P点 道具照成的。但是在实装 Bomb 消弹功能的过程中又出现了更多的报错,也是完全不知头绪,于是又将 bomb 消弹功能移除。

团队合作的不足

一开始没有明确的分工与计划,组长个人能力比较强承担了大部分工作,团队没有组织起来,导致大家基本是各干各的,然后交流也不到位,组员前进没有方向,前期就这样耽误了很多时间,也没有推进度。然后后期合作交接时因为前期缺乏交流出现了很多不适应的情况。

“就我个人而言,因为对项目不够了解导致我常常不知道该做什么,以及上手时很困难因为我也不清楚队友们做了什么,感觉严重影响了效率。”

“果然不能指望丢给别人教程别人就会认真去看,毕竟教程放在我面前的时候我也基本不会去看。初期因为不太相信其他几位选手的编程能力而没怎么敢下发任务,结果到后期差点变成一个人包揽所有任务。如果真这样我还不如单干去写一个纯种弹幕游戏呢。”

虽然想尽可能地打磨的更精细一些,但是我们还是极大地错估了此事的学习成本,与团队的磨合也花了较多的时间。因此导致了我们的项目相对来说十分粗糙。支撑起其玩法核心的弹幕设计也是基本交由***完成,这给了我们一个很大的教训。

团队分工上也存在较大问题,由于没有从一开始就明确分工、也没有制定具体的推进计划,导致学习和项目进度比预想的落后很多,也因分工的不明确导致一些组员参与度较低,以及后期工作的分担和交接难以顺利过渡,使工作难度增加。

Conclusion!

经过此次大项目的学习与实践,做出以下总结:

  1. 团队项目应该提前分好工,哪怕因为还未上手难以明确分工,也要制定好学习和推进计划,不能再莽下去了。(ddl太痛苦了)
  2. Leader 应该充分发挥领导作用,进行规划和部署,成员也应该积极参与,增进沟通交流,否则会出现各干各的,甚至一些组员参与度较低的情况,而且后期想再磨合费时费力
  3. 没有很好地发挥 c++ 特性,有些地方仍然写的有些简陋或冗余。