Unity完全自制游戏《纸箱战争》项目记录（完结）

最近半年时间通过培训机构接触到了Unity游戏制作引擎，通过半年的时间，临近毕业的时候需要制作一个大项目来验证学习结果，因此就确立了这个项目的诞生。（点此回顾前半部分项目记录）

日期：20180711

今天实现了NPC主动寻找可使用的载具和NPC的驾驶。

效果如下图：


不是Gif图看不出效果，其实图上的飞机和坦克都是由NPC驾驶控制的。


在游戏进行过程中，每隔一秒会在范围内搜寻可用的载具，必要条件为同阵营载具，并且载具中并没有人使用。

检测方法和NPC的射击模式类似，通过射线和球形范围检测来控制条件。

如果蓝色射线照射到的目标和检测到的目标载具不同，NPC就会以寻路状态前往目标载具，直到距离小于设定距离之后才认为“NPC登上了该载具”。

在坦克的控制脚本中加入了AI使用的一个bool选项，用来给其他AI判断该载具是否被使用，也可以用于控制坦克AI的功能。

AI驾驶的坦克同样用到了Unity自带的寻路系统，和士兵的个体AI相同，坦克的AI首先会在游戏中寻获控制管理AI，随后从控制管理AI取到应该进攻的目标点的信息从而对目标发起进攻。

因为坦克和士兵不同，坦克的底座和炮塔并不是所有时候都在一个水平线上，有可能坦克的目标在东面，而需要瞄准的单位在北面。

因此坦克的AI并不能使用到之前封装好的士兵AI方法，坦克所能进行的行为树也不多，所以就又单独写了一条AI，能够让坦克捕获目标，并且向着目标开火，会移动向占领目标点就OK了。


之后又把红色阵营的载具按照蓝色载具处理了一下，更改了阵营识别的数字，这样战场就出具规模了。

游戏运行之后，能看到己方NPC朝着载具蜂拥而去，驾驶载具之后朝着目标点进攻，士兵在奔跑的过程中被子弹击中，倒地身亡。


其实中间还抽空完善了一些细节，就像是NPC手中拿的东西，不再单一的是AK47了。


就像是这个死掉的红色士兵，手里拿了个医疗包。

当然了，他们拿的东西也不是随机的，看当时他想干什么，可能这个死掉的NPC当时正想要加血，然后被打死了……


另外还做了个日出日落系统，本来想实现白天过得慢一点，夜晚过的快一点，现在还没有找到好的判断白天黑夜的办法，如果时间充裕的话可以研究一下。

最后贴上一段坦克AI的代码：









日期：20180712

今天写了一个挂在玩家身上的控制脚本，脚本主要实现了对玩家控制角色的集中控制。


首先得让玩家有别于NPC，不然仅凭挂载在玩家身上的Camp脚本，如果玩家死亡后，玩家就会和个体AI死亡后一样进入复活流程。

玩家虽然在游戏中扮演的是一个普通士兵的角色，但肯定是会比AI智商更高一筹的，选择重生点的位置就可以交给玩家自己来选择。

譬如有的时候玩家需要切换自己的兵种或者是迅速改变自己的位置，可能会直接选择重生，这些细枝末节的操作都是要考虑在内的，不然玩家的游戏体验就会像是感觉自己是披着一张皮的傀儡。

另外对玩家的武器切换，武器的使用也写了响应的方法，方便直接的调用。

在之前玩过的《守望先锋》游戏中，玩家控制的各色英雄的武器使用方式都各不相同， 像士兵76、麦克雷这些被称为及时弹道英雄，意指在点击开火的时候，子弹就已经命中了敌人，不需要子弹在空中飞行的时间。

而狂鼠、法老之鹰这些延时命中英雄的武器在发射过子弹后，会经过一段的子弹飞行时间才能命中发射的目标点。

及时命中的话，可以直接用射线检测来代替，方便快捷，而且减少了很多的代码量，也节省了资源。

可榴弹枪和RPG同样也使用简单的射线检测的话效果就会大打折扣，虽说用碰撞检测的话也同样能够实现，但在场景中已经存在太多的碰撞体，又打消了这个想法。

随后我想到，可以在玩家点击发射按钮之后，首先实例化出一枚炮弹，给炮弹传递一个位置信息，让炮弹自行接近目标点，在检测到距离目标点的距离足够近的时候产生爆炸效果，并且销毁自己。

明天的任务量相当重，需要提交一份能够简单游玩的游戏版本。

总结一下，现在我的游戏距离基本游戏功能还有很多没有实现的地方。


以上，五点内容需要在明天实现，看来需要争分夺秒了。

日期：20180713

今天的工作几乎让人崩溃。各种奇怪的BUG层出不穷，本来项目时间就已经很紧张了，现在还需要花费大量的时间调整BUG。

首先出现的第一个BUG，在游戏中，蓝色阵营的寻路系统失效。

这个问题出现的非常莫名其妙，明明是同一个脚本，但是红色阵营就是正常的，而蓝色阵营寻路系统就会不起任何作用。

把蓝色已经生成的士兵阵营数值更改成红色后马上就又恢复了行动，似乎是陷入了某个逻辑缺陷中。

但如果是逻辑错误，那就不会仅仅发生在蓝色阵营身上，毕竟写出来的是通用脚本。

请教了老师也摸不着任何头绪。

最后只能一点点的排查。

发现只有蓝色阵营的寻路目标为目标点的时候，寻路系统就失效了，虽说是失效，但指向目标确实是寻路目标点。

给寻路目标附加一个新数值后，寻路系统随即就恢复了。

直到现在还没有找到问题所在，不过发现把场景中的树木隐去动态障碍物组件后蓝色就回复了正常，难道是因为动态障碍物过多的缘故？


第二个BUG产生为榴弹武器发射的时候，炮弹射向的位置总是会和准星指向目标发生偏移，检查代码后发现炮弹的射向位置被定义为了受到射线触发后物体的位置信息。

用射线碰撞点可以解决，但新的问题来了，射线碰撞点的信息始终不能传递给炮弹，总是提醒引用为空，想了很多办法都未能实现。

最后发现是因为声明的位置变量没有附初始值，这点实在是意料之外，没想到使用公开位置变量还需要先赋值的。

效果实现是把射线碰撞点的信息以V3向量传递给了炸弹，这才实现了炸弹看向目标移动最后爆炸的效果。

除此之外，今天模拟出了一个UI框架，给以后向内填充做好了准备。

利用两个摄像机做出了小地图的效果。


在点击“M”键之后，小地图会产生迅速放大的效果。


考虑到在俯视摄像机中拍摄到的物体实在太小，于是在单位身上添加了一个没有任何碰撞的面片，定义好层级之后，在主摄像机中选择剔除。

图上两个坑洞上的斑马线条纹是测试用的桥梁，用来模拟类似树木分支的效果，产生更为合理的感觉。

日期：20180716

项目的最后完工节点被定在了周六，周六将会举行产品发布会，这么说留给我的时间只有到周五就截止了，而且明天还有别的事情需要耽搁一天，满打满算还剩下三天的项目时间。

在这三天中要实现各项的优化，和组件的拼接工作，事态非常严峻。

今天还发现了一个特别严重的事情，关乎到了游戏效果的成败，到目前为止，我的游戏还没有任何声音。

在FPS中，声音一项占到了重要的一环，而我的项目居然没有声音，这跟我的设计思路不符合，按照设想，项目从模型制作、动画的调整、代码的编写都是一个人完成，我却疏忽了声音这一点，自己想办法配的话肯定是来不及的，难道就必须得在网上找资源了么？

今天需要给老师提交一个预览版的游戏包，做了个简易的UI界面。


数一数，项目到现在为止已经迭代了八个版本，每个版本都更新了不少功能。


主界面浏览图，借鉴了《守望先锋》的设计风格，把模型人物放在主界面上进行展示。

在场景的异步加载界面本来想用一个loading条演一下，一想，既然UI界面都向着网游倾斜了，那干脆就把Loading条演一下好了，就弄了个假装排位的倒计时。


在读取完毕之后，会跳转到游戏场景，在游戏场景中是预留了很多接口的，以便日后可以统一的管理游戏进程。

在进入游戏后，能看到寻常的FPS界面、准星、血条、小地图、目标点占领状态。


当玩家在游戏中时，如果处于死亡状态，系统则会循环判断当前重生点的可用情况，如上图的B点被蓝色完全占领，那么可重生的坐标点就只有B点。

在选择了重生点和重生后的兵种后，玩家就会以该兵种在重生点重生。


受到攻击血条减少。

这里还设计了比较有意思的点。

还记得以前玩到的一些游戏，玩家在死亡后有一段的死亡回放，会以敌人的视角让你看一遍自己是怎么被杀死的，也在一定程度上监督了外挂。

在制作游戏前的构思中，我就想要实现到死亡回放的功能，当时就想到了死亡回放应该是记录下了游戏运行时候的状态，再模拟重演出来一次，如果是录制视频的话对系统内存的消耗就太大了。

查阅了一些资料，有关于《守望先锋》死亡回放系统的讲解，里面采用的就是记录数据后重演的做法。

思索了一下，对我目前的实力来说比较困难，当然了，也不是不可能实现，只要记录下游戏中人物的位置变化，每隔一段时间对数据进行更新覆盖，在死亡之后切换视角验算一次。

可时间严重不足，没有时间给我再做实验，只能作罢。

于是我就换了一种死亡视角，在玩家死亡之后，播放玩家的死亡动画，随后运行其另一台摄像机，使这台摄像机会看着杀死玩家的单位方向并且追踪，这样既不影响游戏进度，而且还简单易用。


如图红圈中就是被打死后死亡视角摄像机观察的目标（准星设置的太大，导致盖住了人体，仔细看还有能再右下看到一个轮廓的）。

在FPS中，一般玩家都看不到自己的身体，能看到的只有两个手臂，为了更简单，在游戏中玩家的身体被省略掉了，实例化出来的敌人才会有真正的身体。

而我的动画模型和手臂完全连接成了一个整体，没有更多的时间给我切割模型，所以在我的游戏中，玩家都是带有身体的。

前两天还想到设计一个彩蛋，如果玩家低头往自己脚上打的话会掉血的设定，仔细想想，估计也不会有人闲着无聊去观察这种设定，也就给舍弃了。

既然是有身体，那岂不就可以让玩家切身实地的感受到自己的死亡？


就这样，在玩家死亡之后，身体会产生跌倒的动画，而摄像机也会跟随玩家一同跌倒在地面上，仿佛真的是中弹身亡一般。

最后，今天又丰富了三个脚本：

• UIControl：负责总体控制UI系统。
• PlayerControl：负责对玩家进行总体控制。
• GameControl：负责对游戏进行总体控制。
  

在接下来的几天，将会把之前预留的功能全部接驳在GameControl中，能节省大半的功夫。

日期：20180718

今天完成了大量的工作，首先把一些需要修正的BUG调整完毕。

在他人试玩过程中收到了建议，应当在占领点附近弄一个可见的区域，这样玩家才知道自己是在占领据点。

所以我就制作了这样的一个圆环，在游戏中是可以旋转的，并且还有三个颜色，根据占领点的状态不同发生变化。


在原先的游戏中，载具的生命值耗尽之后会直接销毁，就给玩家一种biu的就消失的感觉，游戏体验感不好，既然地形都是可破坏的，那么载具理所应当也得是可破坏的，索性在3Dmax中重新修改了模型，制作出了一套战损状态的载具模型。



如图分别是坦克飞机爆炸后的效果，朝着周围飞溅开来，显得很有气势，如果条件允许的话，之后还会添加进入火焰效果？

除此之外，还给玩家的武器添加上了子弹发射效果，让玩家感觉自己的子弹真的打了出去，而不是看不到的空气子弹。


以及坦克上的炸弹和飞机上的导弹。



另外还调整了飞机上两个摄像机的视角，这样一来就可以让玩家看到导弹发射出去的轨迹。

对AI驾驶载具添加了武器效果，现在AI也会发射炮弹了。


如图蓝色飞机打红色坦克。


红色坦克打爆了蓝色飞机。

距离项目时间截止还剩下两天的时间，是时候争分夺秒了。

日期：20180722

截止到昨天上午，《纸箱战争》的项目就结束了，总体消耗时间大约为三周左右，代码总量大致是7000行，游戏最终还是从完全原创变成了百分之八十原创。

因为周六的下午要召开产品发布会，而周五晚上我的项目还没有任何声音。

对于战争游戏来说，声音固然重要，不然就不会产生那种身临其境的感觉，让玩家有想要游玩的冲动。

最终在周六上午我妥协了，从资源网站上找了几段不知道来源的声效给加了进去，不得不说，效果确实好了很多，但也很遗憾，原创计划最终还是破产了。

事后分析，导致这一原因的本质有两点：本人的能力不足；时间太短。

在游戏还未着手开发的阶段我构思了很多有趣的想法，最终都因为时间的原因没能加入到游戏中来，这是一件相当遗憾的事情。

via：游戏扶持by腾讯游戏学院