我的游戏开发与软件工程

[或许是小光]

感谢各位点开这篇博客。本文将从我个人的游戏开发历史的角度，为各位讲解软件工程的存在意义，以及磨砺开发技术的方法。如果你对软件工程这门课程甚至说各门计算机课程有些迷茫，也不妨先看下去，也许能对你的理解有一些帮助。软件开发同样是一门技术，没有一步登天，只有勤学苦练。

初识恶鬼

作为一名热爱游戏开发的学生，我已在探索相关技术和开发方法的路途上矢志不渝地行走了七年，从高中时的PyGame、RPG Maker、Game Maker，到大学时期的Unity、UE，开发工具和语言随着自身知识的增多而演进，与之一起发生变化的，还有项目的规模和复杂度。也是因此，尽管有了功能更加强大的工具，但是开发本身却变得困难重重了，似乎写下的每一行代码都隐藏着陷阱，待到瓜熟蒂落便会化身拦路恶鬼。是代码本身出了问题吗？还是有别的原因？

当时初入软件领域的我心里很快诞生了一个念头：这样下去不行。

宋·朱熹《中庸·或问》卷三：“古语所谓闭门造车，出门合辙，盖言其法之同。”

坚持“面向需求学习”的我，如今遇到了无法逾越的困难。

求道四方

最开始的时候，我们使用RPG Maker这类高层工具，编写少量代码和部分可视化脚本，再填写一些数据库，就可以制作出一款内容丰富的RPG游戏，尽管玩法可能有些单调，但是自成一格浑然一体，倒也均衡；配合一些JS或者Ruby脚本，更是能扩展出无限的玩法（比如早期国产游戏《雨血》、《OZ大乱斗》以及由国人罗伊SD自制的《火焰之纹章》等）。为何转到Unity这类功能丰富，具有无限拓展能力的引擎上，反而连简单的吃豆人都做不出来了呢？

《中庸》 ： "莫见乎隐，莫显乎微，故君子慎其独也。“

我想不是工具本身的问题。

其实答案也很明了了。同样是搭建一个RPG游戏，需要编写和整理的代码越多、需要实现的模块越多，维护起来就越困难。而缺乏准备和计划的开发者，尤其是缺少队友讨论纠错的个人开发者，很容易在不知不觉中陷入泥淖，进而一步步陷入软件开发的深渊。如何为工程做好计划、如何按照计划开发，成为了我的一块心病。

不知道各位可曾编写过脚本。每个脚本基本上只负责一个功能，比如打开窗口、攻击敌人、移动玩家等等，但是很多时候脚本之间也需要互动，保持引用、检查非空……随着脚本数量的增加，脚本之间的关系逐渐织成一张大网，不仅让新的功能无处落脚，更让维护代码和修改代码的我无从下手。

在本科期间学习了计算机网络、操作系统、计算机组成原理后，总觉得颇有些远离实际，有种抽象和模糊感。但是软件工程和数据结构的学习却击中了我的痛点，后者提供了解决问题的工具，而前者则将设计和开发连接在了一起，只可惜本科时的我经验依然不足，还未能将知识融会贯通，只是在开发新的游戏时，会有意识地运用其中的知识。尽管在运用的途中同样犯下了不少错误，但是这些错误也成为了宝贵的历史经验。

不要害怕犯错，因为只有在不断的实践中，才能找到不足、加深理解……再说了，写软件犯错的成本可比其他地方低得多了！放手去干吧！

局部胜利

《设计模式》

在我看到这四个字的时候，我就知道它会是我开发旅程上新的帮手。数据结构过于底层，偏向于效率。从中未能学到的工程知识，相信能在更加偏向于实际开发的设计模式中得到补足。数据结构的知识面对P类问题（即高度抽象、明确定义的问题求解）时帮助甚大，但是面对E类问题（现实的不确定抽象、不稳定且多变的问题和环境）时显然有力无心。在掌握了基础数据结构知识并且累积了代码编写经验的现在，也是时候踏入下一个领域了。

而实际上也确实如此。

观察者模式、工厂模式、单例模式……无不成为现在的我软件开发的得力帮手。何为高内聚？何为低耦合？在学习设计模式的期间逐步形成了感性认识和理性认识的统一，即使放下书本脱离概念的条条框框，我也能分辨出代码中不合理的部分。从追求可运行的代码，到追求整洁的代码，再到追求优美的代码，与代码的关系就如同恋爱一般……这是缺乏开发经验的人无法了解的快乐。

KISS原则，让你的模块自成一体，每行代码都简洁明了，功能划分有致。这就是高内聚。

SOLID原则，让你的模块各成一派，有序相连。这就是低耦合。

什么是KISS原则/SOLID原则……？自行百度请

翦草除根

《架构模式》

架构模式，其实在游戏开发中并不是特别有存在感。游戏引擎实际上已经为你准备好了许多功能，Github等开源社区中同样也有很多框架可供调用。但是这不代表这些知识就没有意义了。而且描述架构模式的方法——UML等，在你的项目设计中也必不可少。

MVC架构，在如今的交互式系统中非常常见，用在游戏服务端和客户端的交互上有何不可？其变体MVVM架构更是打通了Model（数据）和View（视图）的关节，采用ViewModel进行数据的映射和解析，那么用在游戏中，便是利用C#访问器对数据进行追踪和即时反射。

面向需求的学习会让人忽视掉这些知识，但是如今的我已经明白，在计算机的世界中，各种知识都有其优美的内核，而从内核之中能够诞生出另一种表现，以此帮助你掌握别的知识，或是在别的领域一展拳脚。

永无尾声

我很高兴在本科之后还有机会回到教室，重新学习软件工程的知识。不仅仅是温故而知新，在新的课堂、新的老师那里，也能得到新的见解。

在此，也为我认为合理的学习路线做个总结：

首先，了解你最强大的工具：编程语言。语言之间存在特性、适用范围、人气等关系，选择一门专精的语言可能会影响到求职。但是语言之间同样存在着强烈的共通性，精通了一门语言，再学另一门也不会觉得多困难。比如C#从Java那里（抄来的）反射机制、虚拟机，以及从CPP那里继承的IL2CPP技术。再比如C#和CPP的正则表达式，尽管写法稍微有区别，但是都遵循着正则表达式的规范，在规则层面并无区别。还有现在流行的匿名函数、闭包和Lambda表达式，可以在许多语言上见到。我想未来也许Linq表达式同样会被许多语言吸纳成为新的特性吧。

然后，使用你的语言作为工具，来实现你的愿望。做游戏也好、做网站也罢，就算是最简单的命令行图书管理程序也能成为你的经验。也许下一次不用数组，改用列表？也许再下一次试一下观察者模式？也许该学习一种UI的编写？也许是时候自己实现一款具备消息传递功能的自增列表了？自简到繁，但又化繁为简。你的愿望会成为你最大的动力，然后你的努力，将成为你宝贵的经验。

最后，管理好你的工程。一个人的开发范式、敏捷的开发范式，对于庞大的系统可能并不适用。这时候就需要回到书本，学习分工合作、学习统筹规划。现在的你能够解决诸多小型问题，配合书本的知识，就能开始尝试解决更大的问题了。逐步挑战更大规模的项目直到能够独当一面，你也就成为了成熟的软件开发者，甚至，已经能够被成为架构师了。

当然学无止境。知识是没有止境的，经验也是一样。总会有更多开源框架等着你去认识，总会有更好的设计模式等着你去学习。未来的路，我们还要一起见证。

最后，如果对软件工程的深入学习感兴趣，推荐这份参考资料：https://gitee.com/mengning997/se

补充

关于IDE的看法。我习惯了使用VS Studio这种全面的集成开发环境。但是由于Unity的ShaderLab语言并不受到支持，也会在必要时使用VS Code。而面对文件甚少的小型项目，也会直接使用VS Code进行开发。IDE的选择其实也很个人化，有人有钱，乐意用JetBrains那就更好，还有人喜欢Notepad++来编写Shader（比如美国着色器大神Ben Cloward），调教好你的IDE、熟悉它的功能和快捷键，在需要的时候灵活更换……毕竟我们的目标是如何达成事半功倍的效果。

正则表达式。学！为了处理大量的文件但是又懒得编写Bash脚本，内嵌于各类IDE的正则表达式绝对是最佳选择。规则也不难，建议在掌握数据结构知识后抽空学一下。网上也有很多帮助你编写和验证正则表达式的网站。

异步技术。实际上现在很多语言都在支持更多的异步操作写法。流行的Promise和async已经在许多目前还在活跃的语言中得到了实现（比如JavaScript、C#等），学习这类写法是时代的趋势，不可不品尝。计算机是一个演化很快的学科，停止学习很容易就会落后于时代了。

CODE：258