我的游戏开发与软件工程

或许是小光 2022-07-14 10:47:44

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

初识恶鬼

作为一名热爱游戏开发的学生,我已在探索相关技术和开发方法的路途上矢志不渝地行走了七年,从高中时的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

...全文
45 回复 打赏 收藏 举报
写回复
回复
切换为时间正序
请发表友善的回复…
发表回复
发帖
代码中的软件工程

395

社区成员

软件工程教学新范式,强化专项技能训练+基于项目的学习PBL。Git仓库:https://gitee.com/mengning997/se
软件工程 高校
社区管理员
  • 码农孟宁
加入社区
帖子事件
创建了帖子
2022-07-14 10:47