插曲:你的独立游戏生涯

希望你在阅读本文的时候,已经完成了,起码阅读完所有初级教程了。因为在本篇后,如果你选择继续使用Love,那么你将进入中级教程。当然,未来还将有一个案例教程,是跟其他教程没有阅读顺序的独立教程。同样,在开始中级教程前,我仍然希望你要了解未来你将面对的love与独立游戏道路。

独立游戏与你

如果你阅读了初级教程的内容,并且做了案例和作业,那么恭喜你,你基本可以完全独立的写大多数你想实现的东西了,而且有了一个对于库自学的基本能力(自己阅读库代码并会使用和改善)。而你将面对的道路就十分宽广了。因为可能你之前并不太了解游戏为何物(对于程序而言而非玩家视角),而如今,你已经对游戏中很多基本的行为可以用代码来实现了。实际上,我们初级教程所介绍的是引擎通用的,对于其他引擎而言,也需要用到之前讲过的代码,有的可能是包装好的,有的也需要你自己写。所以,学了初级教程,选择权仍然在你手上,继续使用love还是弃坑。

与其他引擎的对比

从目前你接触到的程序的角度,我们做一下对比。

游戏循环封装

游戏循环封装实际上也就是对于游戏最底层的窗体及绘图循环的控制。很少有游戏引擎允许你对游戏底层进行控制,而love是其中一个(我还知道一个monogame,最近我才接触的。),因为底层控制意味着改变很多上层建筑的基本行为,因此,如果你使用的是较高级(相对于底层)的游戏引擎,那么游戏循环将是被定制的。控制循环意味着你将拥有极大的自由度,用与不用任何资源全在你的掌控(只要不加入循环即可),但是有一个问题就是,如果你的语言是解释型(比如lua)而非编译的,它将影响效率。

虚拟层封装

虚拟层封装是高级引擎的基础,它对一般游戏可能出现的基本行为,全部封装,纳入到游戏引擎中。在你使用的时候,仅需实例化使用即可。他的好处是在于,强制代码规范,强制解决方案,提高代码一致性。这样对于团队来讲绝对是个好事,你不用阅读别人底层的代码就可以了解一个游戏,代码规范好看,大家都学一个解决方法,不必产生额外的学习成本。它的缺点在于,如果你不喜欢那个方案的代码风格,你想定制一些额外的东西,那么对不起,这种方案要么不动,要么就得动全身,而且还不一定是这个引擎所支持的。而love因为没有底层封装,你可以用一两行来表现别的引擎可能一整个类要表现的事,而且想改就改,但是如果你有团队,而且比较松散的话,这是个灾难。

游戏素材

有的引擎在编译之前,并不会真正的导入资源到内存,而是在编译的时候,通过编译方法来形成内部使用的数据,这样就使得它具有检验功能。就是不被使用的素材或者代码,是不会进入游戏资源的。love是手动导入到游戏中来建立绘图对象的。而文件的控制也是手动的,所以它不会检查你的素材是否被使用。这点需要注意。当然,你也可以使用自己的工具来实现上面检验和导入功能。

代码规范

就像上面说的虚拟层封装一样,对于没有虚拟层的love引擎,代码在游戏相关编程就已经是十分自由的了,而且love使用的是lua这种十分灵活的语言,使得你代码规模一旦很大,而你对代码架构的控制功力不够,那么你的项目在代码上就是摇摇欲坠了。所以,即使是独狼做游戏(程序就你一个人),也可能因为你对代码控制能力不足而导致混乱。对于养成一个好的代码习惯,可能你需要下更大的基本功,因为lua不会检查你的代码框架,你使用一个局域变量或者全局或者数据类型错误,往往它并不报错。

第三方库

高级引擎的宗旨是不用第三方的东西,至少尽量少用,这样来增加代码的规范性和一致性。类似unity插件,则是按照其插件的使用规范来。 而love则不同,它的上层功能几乎都是用第三方库(或者你自己写的)来实现的,这样也会带来各种各样的代码习惯的不兼容,代码架构的混乱,而且一般的,在网上的库实际上也是用户在自己的项目使用后,把它分享给大家,而不需要一个一致性的接口。而你引入到自己的项目中,就需要你有一定的代码能力来消化这些来自外部的库,通过修改或者自己改写,让它成为自己代码中比较和谐的一部分。

编译

love没有针对各平台的统一编译工具,前面已经说了。实际上现有的第三方工具可以一键编译win平台和android平台,对于mac和ios系列还是需要苹果机的。关于love商业化时,代码加密之类的事,我后面开专题讨论,这里只有一句话:把你的注意力放在写游戏上,而非杞人忧天;有一天你的游戏被仿了,被破了,你已经成功了,那时相信你的能力就不仅仅是加密一个代码这么简单的事了。

love的人群

上面的情形实际上描述了那些使用love的人的特征。
geek向,作为硬核的你,当然希望什么东西都自己把控,别人盖的楼房,你不拆开看看里面,怎么能放心住进去呢,人家不让拆,那就自己盖楼房吧,反正你喜欢这样,同时还有这个能力。
独狼向,你喜欢我行我素,我的代码我做主,反正我的代码一般也就给自己看。代码能让自己看懂就ok了,当然必要的注释也得有,不然隔两天自己都忘了自己写的是什么了。
独立向,没有商家会用love作为商业引擎,所以就是独立游戏人在用咯。那么,你使用love的话,基本也意味着你就是独立游戏人啦。独立游戏下文会再次讲到。
程序向,做游戏的,或者说游戏中的“程序”有两种,一种是做架构的架构程序员,一种是做组件的脚本程序员。实际上,使用love的需要两种技能,而很多人并不喜欢写什么架构和库。
兴趣向,之前说了,love是不能被用作商业工具的,因此,你做的一切都出于兴趣,整个love的圈子,也都是对游戏制作的纯热爱来的,他们有网络工程师,也有游戏程序员,或者是业余爱好者,都是喜欢而作,而非作为工作负担。
你与上面的特征有多大的契合度?就决定了你的去留。当然你想背着自己的兴趣硬啃骨头,也是可以的,也许你啃着啃着就喜欢了呢?

独立游戏

说love引擎,就不得不说独立游戏了,因为love的产出方向只有独立游戏。

什么是独立游戏

这个不是硬性的解释,从字面释义,它就是非公司行为的个人游戏。当然,我们说独立游戏有更多的隐含特征。比如游戏性很高;画面要么特别朴实,要么特别唯美;创新性很好,往往可以产生那些无法被分类的游戏,甚至创新型高于游戏性(很奇特但不一定好玩);有一些是非盈利性的(不一定);不随市场潮流,往往烂大街的东西都不屑于做。
个人认为,独立游戏人还是回归本源,就是只要你不是公司行为,就是独立游戏,并不代表你的非商业化,或者内容有什么倾向。

国内独立游戏现状

也许我本人并不是独立游戏圈子的一员,算是在边缘的人,多少对国内圈子有一点点了解。我不想过多的去用文字描述圈子的现状和人们的想法。这个你自己进入到圈子中就可以体会了。而是给大伙点建议。并不是所谓高大上的游戏才能叫独立游戏,独立游戏的概念本来是从老外那里来的,而如果你经常逛一些老外的独立网站看,他们的游戏并不是很“好看”,也许仅仅是一个游戏形式幽默的玩笑或者一些人的恶趣味,他们的目的也不都是为了让很多的人去关注他们,就像写一个博客一样,我发表一个文章也不需要绑架很多人来看。这是一种态度,而国内的人大多都缺乏这种态度。这时,不要跟我说国内的生活压力现状。如果你有太大压力,你也不太可能使用Love这种高自由的慢功夫引擎。可能在国内,你写了个小游戏,比较简陋,你会被圈子的人嘲笑,即使他们连任何东西都写不出来,但是你自己要知道你所走的路,注定跟大多数人不同。

独立、商业与闭源

我从来都不反对游戏商业化,人也要吃饭,或者有的人也需要通过购买量来对游戏的价值进行肯定。一想到商业化,很多人就想到要加密,防破解,防外挂,支付api等等。然后,需要把这些比较遥远的话题放在写游戏之前。但是,问题是,你连一个游戏都做不出来,你的程序能力可能还没有达到能够防一个比你高出几个数量级的人来抠你的游戏数据的地步,甚至人家都不屑于去看一眼。等你程序能力,以及设计能力提高的时候,你可能有更多的手段来达到相同的目的了。换个说法,如果你的游戏都值得被人破解了,那他就具有商业化的能力了,你完全可以花钱找人帮你加密。Love论坛的大佬们,也经常面对这种如何闭源的问题,他们的回答都很简单,对于代码,你只需要不被人简单的打开并修改导致破坏游戏本身结构和游戏性就足够了,剩下的问题交给版权。如果版权都不能保护的,也不是你能防的住的。

中级教程内容

如果你读了上面的内容,还想继续使用Love以及在独立圈子里混,我们就可以开始中级教程了。对于初级教程,我们实现了一些物体的构建,基本移动,碰撞,以及基本的输入和输出。这些都是游戏概念中的基础,而我们中级教程主要讨论的是“让游戏更有意思”的话题。比如画面更加漂亮,比如AI更加聪明等等。

在中级教程中,我们将接触:用户界面;高级绘图mesh及变形、裁剪模式、canvas、shader;人物状态机;tiled地图;光影;人物状态机;寻路;基本AI、基于规则算法及遗传算法;数据序列化,文件读写及存档制作;基本的背包、对话、任务系统;网络编程初步,项目内部工具调试及外部工具调试等等。

实际上,中级教程也是终极教程了,因为越往后学,游戏共性的东西就越来越少了,我能够展现给各位的也越来越少了。后面还会有一个案例教程,我将使用几个典型的游戏类型,以制作案例的形式来讲解一些思路问题和架构问题。

如何自我提升

之所以我给大家讲的都是基础原理,就是希望能够提供大家自学的空间,因为实现一种效果的方法很多,往往并没有排名先后。而你需要的就是不断的尝试。
我相信,在不断对中级教程的展开过程中,你完全可以对任何2d游戏游戏中,所涉及的技术范畴有一个归类了,比如你面对超级马里奥,你就知道里面可能设计的元素:人物类,碰撞盒,场景切换,计时器等等。比较复杂的,比如地狱边缘,可能涉及的技术问题有人物类,物理引擎或者多边形碰撞,场景切换,对话类,道具类,任务类,光影,骨骼动画,粒子效果,3d初步等等。通过对游戏的技术拆解,你来构思他们如何你自己来实现,发现差距,有针对性的技术搜索,学习,实践。
不要被各种特效晃瞎了你的双眼-。-学习了shader的同学很喜欢在shadertoy各种闲逛,然后发现“哇,这个好帅”,“哇,这个好神奇”之类,然而去读shader代码基本处于不懂的状态。即使能够调节些数值,也不太理解背后的理论。因为计算机图形学,或者单单的shader编程,就不是一般人能够完全掌握的,你需要过硬的数学基础和程序基础,以及大量的代码经验。所以,好的做法是,当你项目中用到了这个技术,就去搜相关的技术文档和git,而不是横向的浏览各种文档。
记住,素材是载体,玩法是核心,不要为了素材而游戏。而是先想好玩法。如果你的玩法真的很棒,素材完全可以单独购买。
当你的理论基础比较好的时候,你的伙伴往往就从百度谷歌转到git上了,而且不要局限语言,因为背后的本质是一样的。别看看就了事,要动手成为自己的东西,甚至写出标准成为公共库。
最后,还是那句话:no more talking, just coding.

Alexar @成都
2016-12-05