【Unity】Domina-Game总结与反思
2018/6/15
我总算是把物理课作业--Domina-Game给赶完了，这也算是我用Unity做的第一个游戏吧（不得不说我的脚本写的超烂的）。。。纪念意义挺大的，这次作业也算是一波三折了，游戏改了三个版本，最后总算将游戏定性为密室逃脱类型的游戏，把我脑内的设想从多人竞技类型的游戏改成密室逃脱类游戏也是够了（笑）。
感慨到此为止，下面给出我在这次制作过程的总结还有自我反思，然后明确一下下一步要接着往哪走~~~~
该游戏GitHub仓库：https://github.com/swordjoinmagic/Domino-Game
总结
总结一下我在这次制作中学习到了什么知识~
1.简单状态机AI的制作
这次用了很简单的Switch...case来做状态机，怎么说呢，感觉这样子把状态迁移和状态进行时发生的事件全部写在一个case里面是真的不好维护，很难改，但是如果用状态模式来写的话，就要写超级多的类（包括状态类，状态迁移类，状态机类，感觉对于我这个超级小的游戏来说应该没必要把？），这是我第一次学做游戏AI（非常弱智的程度。。），感觉还是挺有意思的，用在了追逐主角的守卫身上，接下来想要学习更深一点，比如行为树，分层有限状态机什么的
2.Unity基本组件的运用
在这次制作过程中，我遇到了一个很微妙的Bug，就是，有这么一个场景，主角可以对一个门进行推开操作（通过一些按键），但是，主角不能直接这样子移动过去就算是把门给推开了，在这里我的主角是有Rigdbody和Collider两个组件的（因为在其他场景有主角的碰撞事件要处理），而门因为我要对它施加力的作用(要做一个门向后倒下的动作)，他也得有Rigdbody组件，又因为我不能让主角穿过它，所以我也给他加了一个Collider组件，但是！！！问题就是，这样子的话，如果主角直接这样跑过去，会直接推开门（不改门的mass的情况下），由于某些原因，我不能修改门的mass，但是我又不能让主角这样直接推开它~~
我想了一个解决方法（不知道符不符合做游戏的规范，有点惶恐，不知道有没有触犯什么禁忌之类的（没有游戏上的前辈来告诉我啊。。沮丧））：
创建一个空对象，设置它的layer和门的layer不产生碰撞，然后，为空对象增加collider，用一个脚本设置这个空对象的Transform时时刻刻都跟门的Transform一样，这样的话，主角就无法通过rigdbody的相互作用推开那扇门了，然后，就可以在门前面放一个触发器（collider），然后弄一个提示，比如说按Q键推开门，然后再写按下Q键之后的事件~~这是我想的一个笨方法。。不知道还有什么比较巧妙的方法可以解决这个问题
3.协程的运用
在这个游戏里面倒是用了不少协程，但是不知道有没有用对。在一些关卡中，因为要等待玩家做决策，就用了协程，放弃了在Update里面写游戏流程，就是在等待玩家时new WaitForSeconds(2f)
4.UI(ugui)的MVC模式
我用的是Unity比较推崇的ugui，里面用了一下以前在学java web时的mvc模式，但是感觉自己写错了~~总而言之，稍微实现了一点模型与界面显示分离，然后大致的做出了这个游戏的UI，其实我就是一直弄不清Unity里面MVC的话，Controller要怎么写呢？View的话，我想的是对应一个UGUI组件，比如Canvas（不知道对不对），然后Model的话，我也是尽量模仿Java的写法，也就是写一个类似JavaBean的东西来充当模型，比如我的UI里面要显示物品的名字和他的说明，我的Model就是新建一个Model类（继承MonBeahvior，方便直接在Unity编辑器里面调数据），然后建立几个属性，就好了，但是Controller就让我犯难了。。不知道怎么写，java web里面controller负责的是分发请求的任务，并且将model数据传输到view那里，最后显示视图，在这里的话，我想Controller应该担任的是何时显示UI的任务吧？
5.旧版Animations系统的学习
现在Unity的主流应该是使用mecanim动画系统了，但是我觉得旧版这个也挺值得学习的~~就是学习了一下，在Unity里面制作Animation，感觉还挺方便的，跟Flash一样，插入关键帧，然后改变组件的某个属性，Unity里面的动画系统就会像Flash一样直接自动过渡过去~
反思
反思是我写这篇文章的主要目的，Unity总体来说还是比较易上手的~但是让我无法容忍的是我写了超多超垃圾的代码（无法维护，可重用性极低，Bug频出）。。就是那种一坨一坨的代码，很反感，（让人绝望的是，我还暂时没找到如何改正的方法）下面主要检讨一下我在这次制作过程做的最蠢的几件事。
1.滥用MonoBehaviour脚本和协程
在游戏里面，我超级大量的滥用了MonoBehaviour脚本，比如说，有一道门，我要检测它是否倒下，我就写了一个MonoBehaviour脚本，然后在Update函数里面不停的检测它的欧拉角是否到了90度之类的，到了之后做什么事之类的
2.脚本复用性极低
我觉得这应该是我的最主要的问题了！我写的脚本复用性极低，唯一算的上是复用程度高的只有我写的那个残疾的MVC脚本，我基本上就是，如果要按xxx按键，就直接写一个xxx按键的脚本，要拿起一个物品，就写一个拿物品的脚本，要开门，就写一个开门的脚本，实际上，它们之中是有一些重合性的，而我，极少考虑复用性，所以在项目的后期，感觉写的极其痛苦，感觉自己就是一个不停地在写业务逻辑的码农，这就是因为我的*太少的原因！所以，我的改正方法就是，以后写东西，多多考虑全面性，复用性，力争每次写的项目，里面的东西都能变成我下一个项目的一个小*，就这样一步步积累我自己的*~~
3.写的脚本可维护性很低
感觉我写的脚本，考虑的东西太少了，bug频出，然后，又很难维护，就是里面都是随性写函数，要把就是一坨坨的代码写在Update里面，丑的不行！！这方面感觉主要就是我的设计模式没学好吧~~我的解决方案是，接下来努力学习、接触一下常用的设计模式，观察者模式、单例模式等等，力争写出可以看的代码~
下一步
下一个游戏打算做一个MOBA风格的游戏，感觉做着各个英雄的特技挺好玩的样子（虽然我并不是很喜欢玩MOBA游戏~~），感觉做游戏还是比玩游戏好玩多啊23333