本来想在之前Uncertainty的基础上拓展出一个类似Ghost Runner的跑酷射击游戏，很显然开始写这个文那肯定是已经Failed嘞，但是也只能说吃一堑长一智吧，希望我已经从愚昧山峰掉到了emo之谷（忘了那个玩意儿叫啥了）

以下简单说明一下为什么最后代码和工程做不下去嘞，就是个自我反省，可能没啥干货

游戏制作前准备工作的重要性

GDD

说实话这次继续拓展这个游戏就只知道我们要做的是个跑酷打枪的游戏，而对于关卡设计，是否具有可玩性，背后的很多设定，美术风格，都是一边做一边决定的

我只能说边做边定这种行为对于小团队小项目来说是完全适用的，尤其是对于一个像我一样的Noob，因为让一个没怎么系统性做过游戏的准Beginner来着手GDD，可能会导致计划的内容过于抽象和脱离实际，唯一能够贡献的也就一个指导意义了，但直接开始做，边做边解决问题，虽然第一次做出来的东西会到处都是不合理的地方，但最重要的是让实践者知道了在实操中可能遇到的困难和已经拥有的技术能力，那么在下次做游戏的时候就可以尝试开始GDD了，然后每次把游戏做大一点点，每次做之前把不合理的地方进行重构重写，就可以做出更加合理的东西了（而不是像是在堆一座屎山

总结就是：做第一个游戏最好别弄什么GDD，放手去做就行，然后也别太有野心，就尽量做直到自己觉得这屎山代码不重构一下真的写不下去的时候，就开第二个游戏的坑。在第二个游戏中任何一行代码之前先敲定GDD，并大概规划一下各个制作环节、制作阶段的周期，计划好了再做事，不然很容易Spaghetti Code

（所以这么来说，虽然说Uncertainty是做的第一个游戏，但是说实话并没有觉得”做不下去了“，而在这个新的拓展中却有这种感觉，说明瓶颈是现在才有的，那就在下一个游戏开始注意这些了嗯

架构

在正式动工之前，要现根据GDD对整体架构进行大概的颅内coding，比如类与类的继承关系，一个继承Monobehaviour的类中的哪些内容可以被抽象出来作为一个更为Generic的类，要准备哪些接口，要如何构建Event System等等。说实话我现在写这个的时候我都还没有太理解到底怎样才能做到一个优秀的架构，等我以后真的会做这些工作了我再发一篇文理一下，但至少多花点时间在着手coding前的设计上，能让你在实际coding中少很多顾虑，并且对自己的code更有底气（我这次就写了很多没底气的code，比如我有些时候觉得“好像这些code不该写进这个类啊…”，但是因为图方便以及确实不太清楚要怎么做才是正确的，导致代码越写越乱，越写越难受，直到完全开摆，类与类之间的关系乱到发指

因为是在Unity引擎基础上做游戏，只需要考虑游戏本身的架构，所以其实已经很表层了，之前的Uncertainty因为结构简单，没有什么复杂的要素，所以做起来其实根本不需要什么架构，一直堆代码就完事了，代码层面上都没怎么用接口继承虚函数之类的东西，结构非常”平面“，逻辑上只有几个按钮几个门来做一些简单的交互，Event的管理上也非常平面，过于简单

但是当我们想要增加一点NPC，一些敌人的时候，就发现需要做的工作还差的很多了，首先在一开始因为Player不需要生命值，所以后来加了一个Entity类来Derive出具有生命值的物体，

OOP基础和语言基础

不得不说OOP对我还说还仍然是一个神奇的东西，给我的感觉就是“我脑子都明白这些关键字、这些操作是什么意思，我也知道他们之间的逻辑关系”，但我有些时候就是不能合理地处理他们在实际运用场景中的关系

语言基础应该也是导致OOP不熟的一个原因，我一开始对于接口、虚函数、重写、event之类的关键的要素了解和应用太少，导致基础不牢固，至于要熟悉这些内容，那最好多做一些工具化的实现，比如背包系统啊，或者实践一些NPC的AI系统啊什么的，但关键都是做完之后要尽可能解耦，并尽力保证抽象出来的系统的通用性

之后的规划

花了一个多月去试着在之前做过的游戏的基础上继续做个游戏但是没有成功，大部分还是自己的问题，至少现在对很多东西的应用场景有更深的理解了，也还是新学了不少内容的implement

现在这个时间点属于是马上就要期末了，所以得滚去复习和赶作业的DDL了

假期尽量做些游戏引擎底层的东西搓个MC（貌似接触底层先搓MC是个比较普遍的HelloWorld），希望能用上这学期（虽然有课但纯靠自）学的OS