第190章 人机交互×人机协同√
回复完伊芙·卡莉的邮件，林灰又陆陆续续回复了一些邮件。
在这之后，林灰又想到了游戏引擎。
游戏引擎虽然很好，应用场景很广阔。
但终究是“工业软件”。
这样的软件是需要长时间的精力去打磨的。
总之，虽然以前很多游戏林灰都可以肆无忌惮的直接搬运。
但像游戏引擎这种需要积年累月时间才能搞定的东西直接拿出来怕是不符合技术发展的逻辑。
在此之前林灰要经过长时间的铺垫。
不过具体怎么入局游戏引擎这个方向呢？
以UNITY这款游戏引擎为例，前世这款游戏引擎的发展由单平台到多平台可以说是一个极其漫长而又曲折的过程。
这条道路显然不适合林灰，林灰的时间太紧迫了。
林灰灵机一动，突然想到了什么。
从插件开始入局游戏引擎似乎是个不错的选择。
游戏引擎也有插件？
没错，一款游戏引擎问世以后虽然很强大，但也不是能像像瑞士军刀一般能解决各种各样的场景。
这个时候一些插件作为游戏引擎的补充就很有必要了。
之前在开发《HILL
CLIMB
RACING》的时候林灰灵机一动想到的Ferr2D
Terrain
Tool其实就是一个插件。
这种插件常常被用来开发2D场景中的地图。
除此之外，还有很多插件。
虽然这个时空游戏引擎不少，但游戏引擎插件可不少。
很多开发者和开发公司都会顺带鼓捣些游戏引擎插件以使游戏引擎效率更高。
在这种情况下，林灰入局游戏引擎的插件也不至于引发什么涟漪。
不过问题来了，在一堆游戏插件的红海中林灰能杀出重围吗？
当然能，毕竟林灰有信息差的优势。
同样是Ferr2D
Terrain
Tool这款游戏的插件。
2021版本的该插件比14年的该插件实用性不知道高到哪去了。
更何况林灰硬盘里一堆现成的插件。
这种情况下，林灰想入局游戏引擎的插件未必不能杀出一条血路。
虽然2021版本的Ferr2D
Terrain
Tool该插件比14年的该插件实用性不知道高到哪去了。
但林灰并不打算截胡，林灰打算由易到难，先从普通的游戏插件入手。
而什么样的插件简单呢？
最基础的应该是涉及到2D游戏碰撞检测的插件。
在2D游戏中，一般存在模拟重力和阻挡物的存在。
而在游戏中的业务对象，例如人物、飞机、宠物、道具物品等，受到用户的操作控制，需要实现业务对象在地面上行走、掉落、不可通过地形的阻挡等移动，或者，需要实现诸如射击类游戏中的子弹等道具物品飞行、命中等动作，经常在游戏中发生碰撞。
因此，在2D游戏中需要进行碰撞检测。
比如利用flash就可以实现简单的碰撞检测。
这种方法在检测两个对象是否碰撞主要看二者是否重叠。
具体地，通过判断两个业务对象(例如人物的显示对象)之间，是否有像素点的重叠。
如果有，则判断这两个业务对象发生碰撞；如果没有，则判断这两个业务对象没有发生碰撞。
除了这种方法还有很多检测碰撞的方法。
很多人对检测碰撞都有不错的思路。
在这种情况下林灰以GRAY
FOREST的身份搞一个检测2D游戏中碰撞的插件也没啥。
林灰在前世那台ThinkPad里翻找了一会。
几乎没怎么费力就找到了一个适用于unity游戏引擎的2D游戏碰撞检测的插件。
这个插件前世存在，这个时空却不存在。
这无疑大概率将成为林灰这个重生者的福利。
而且以林灰的眼光来看这个2D游戏碰撞检测插件还算不错。
这个碰撞检测插件确实要比Unity游戏引擎里面自带的碰撞检测装置好用一丢丢。
但其实两者功能性上的区别其实不是很大。
林灰之所以说这个2D游戏碰撞检测插件“还算不错”不是从“这个插件多么多么好用”这个角度出发的。
而是从插件的设计风格来说的。
这个2D游戏碰撞检测插件几乎不带任何开发者的个人风格，十分简约。
这种情况无疑意味着林灰搬运的可行性。
要知道有的项目虽然技术不复杂。
但由于开发者个人风格极其浓厚，实际上这类项目是很难搬运的。
这类项目贸然搬运的话只会带来一些麻烦。
而具体到现在这个2D游戏碰撞检测插件则没那么多麻烦事。
虽然搬运这个2D游戏碰撞检测插件是可行的。
但名字什么的还是要改动一下的。
林灰是资深起名废。
苦思冥想许久，林灰也没想出比较牛比的名字。
林灰干脆直接将这个插件随便起了一个中规中矩的名字：
——CRASH_2D
这之后，林灰又仔细检查了几遍这个插件所涉及到的底层内容。
还好这只是一个很小的插件，加上林灰工作效率很高思维很活跃。
因此检查起来并不是很费力。
在确定没什么撞车的隐患之后。
林灰就将CRASH_2D这个插件上传到Unity游戏引擎的插件库里。
插件库似乎是这个时空独有的产物。
和前世到处找插件的局面不同，这个时空Unity还有官方的插件库。
这让林灰稍稍有点意外。
前世的插件基本都是散装放养的，而不是像现在这样圈养。
至于为什么Unity搞个这样的插件库？
在性能不够先进的情况下，似乎也只能通过类似于官方社区这种东西培养用户情感。
上传CRASH_2D这个插件的时候，林灰使用的是GRAY
FOREST这个身份而不是再换一个新马甲。
马甲再换多一些，林灰估计他本人都快分不清了。
而且之前微博上无端兴起又莫名结束的风波已经证明了马甲太多并不是好事。
虽然GRAY
FOREST这个马甲一贯是林灰拿来开发游戏的。
但现在开发点游戏引擎也没什么。
之前林灰就已经考虑过这点了。
很多牛比的游戏开发公司在开发游戏时甚至会顺手搞定游戏引擎。
至于说普通的游戏开发者，虽然没有单撸游戏引擎那么离谱。
但一些牛比的游戏开发者在使用游戏引擎开发游戏的时候都顺带着开发一些游戏引擎的插件也不是不可能。
以林灰GRAY
FOREST现在对应的名声，顺手搞定几个游戏引擎插件在外人眼中根本激不起什么水花。
此举不但不会引起外界的质疑，而且很可能为林灰收获新一轮的赞誉。
具体到CRASH_2D本身。
值得一提的是，涉及到unity这款游戏引擎的插件如果非要细分的话。
其实可以细分为两种的，一种是托管插件，另一种是原生插件。
托管插件使用的是
Visual
Studio
等工具创建的托管.NE
程序集。
此类插件仅包含.NE
代码，因此无法访问.NE
库不支持的任何功能。
不过，因为Unity
使用的标准.NE
工具是可以访问托管代码来编译脚本的。
因此，托管插件代码和
Unity
脚本代码之间几乎没有用法差异。
相比于托管插件，原生插件是特定于平台的本机代码库。
插件可访问操作系统调用和第三方代码库等功能。
客观来说托管插件相对于原生插件同Unity的兼容性更好。
林灰搬运的CRASH_2D就是一个托管插件。
这无疑意味着该插件能同Unity有更好的兼容性。
相信这样一款兼容性强的软件尽管技术不是特别领先，应该也会有一定的受众。
因为将CRASH_2D设置为免费的插件的缘故。
几乎没怎么费力，这个插件就通过了审查。
在通过审核之后，只间隔两三分钟就发现在Unity插件库的免费插件里已经可以搜得到CRASH_2D这款插件。
至于为什么要将这款插件设置成免费？
无非就是靠免费走量争用户基础。
虽然现在CRASH_2D这个插件是免费的。
但有了用户基础，今后赚钱只会事半功倍。
而且利用插件赚钱其实是次要的。
重点是借助于插件向外界证明林灰有对游戏引擎进行拓展、升级和改造的实力。
从而慢慢向外界表明林灰有入局游戏引擎这个领域的实力。
而后寻找一个合适的时机直接下场做游戏引擎。
相比于插件小来小去的利润。
涉及到游戏引擎才是真正广阔无边的“钱景”。
当然细究的话，其实插件方面将来还是有机会能给林灰赚个千八百万美元的。
不过人的欲望都是升级的。
现在的林灰可不是千八百万美元就能满足的了。
林灰图谋的是更大的机遇以及更广阔的天地。
即便林灰真的要依托插件什么的挣钱。
也不会依托一个2D游戏碰撞检测装置来赚钱。
尽管这个时空很多地方都短腿吧。
但也没落魄到让林灰随便拿出一个2D游戏碰撞检测的插件也能赚钱。
毕竟像2D游戏检测装置这是很多游戏开发必不可少的一部分。
类似于雷霆战机、贪吃蛇之类的游戏都要涉及到碰撞检测。
这个时空2D碰撞检测已经很成熟了。
林灰之所以要上传一个2D游戏碰撞检测的插件恰恰是因为这东西简单且成熟。
简单意味着方便入局；
成熟意味着即便以此入局也不会引入注目。
有这两点就足够了。
对于现阶段的林灰来说入局远比赚钱更重要。
退一万步讲，即便是林灰真的要利用碰撞检测插件来赚钱的话也只能是3D游戏碰撞检测。
依靠2D游戏碰撞检测这类的插件想赚钱几乎不可能。
想到3D游戏碰撞检测，林灰突然想到了一个能够搞钱的技术。
——3D游戏异常碰撞检测技术。
林灰记得前世上大学的时候为了评奖学金还申请了一个3D游戏异常碰撞检测方面的专利。
尽管当初搞这个东西有跟风的意味吧。
但不管怎么说林灰前世对这个专利也忙前忙后一段时间。
因此尽管重生了。
林灰对3D游戏异常碰撞检测依旧印象深刻。
正是因为这种印象深刻，成了重生之后林灰的一项福利。
说起来3D游戏异常碰撞检测技术这东西在前世来看虽然很鸡肋。
但放到现在妥妥的黑科技啊。
脱离时代背景谈技术先进与否明显不妥当。
放到前世这项技术虽然只是林灰跟风之作罢了。
但现在却稳稳的领先水平。
不止是领先全国，而是领先世界。
前世3D游戏异常碰撞检测技术对应的专利也是林灰前世大三时搞得技术。
而林灰大三大概对应前世的2016年。
此时却刚刚2014年。
也就是说，这样一项前世一般般甚至泯然众人的技术放到现在起码领先世界先进技术一年多。
涉及到纯粹游戏方面的东西：
领先一年多可以说是极具诱惑力了。
游戏技术更迭本来就很快。
一年时间甚至足够有些游戏来四个大版本迭代了。
这种情况下，林灰前世搞得3D游戏异常碰撞检测技术如果拿到今天来其实是很有价值的。
涉及到“3D游戏异常碰撞检测技术”虽然听起来很高大上。
但用途其实蛮直观的——防外挂。
其防外挂的原理跟碰撞游戏的机制有关系。
碰撞游戏是这样的机理：
计算机产生自动游戏对象，从显示界面的一个方向出发按照一定路径行进。
用户控制一个控制游戏对象向与其余游戏对象相对的方向进行，当玩家控制游戏对象或者控制游戏对象使用的道具（比如说游戏里的枪）和其余游戏对象在显示界面上发生碰撞时取得相应的分数；
累积用户在一场碰撞游戏中取得的分数获得游戏积分，通过游戏积分的高低来衡量用户玩碰撞游戏获得的成绩。
比如说飞机射击类游戏、碰撞球游戏等这些都是碰撞类游戏；
而一些枪战类游戏更是属于碰撞类游戏。
除此之外，还有……
总而言之，碰撞类游戏是相当广泛的。
在碰撞游戏如此广泛的情况之下，一些睿智的科技狗就会有想法了。
为了获得较高的游戏积分，通过外挂程序等辅助程序修改碰撞游戏程序，从而使得游戏能够取得更高的游戏成就/积分。
甚至改变游戏里的一些机制，只为了更强的游戏表现。
比如说枪战游戏有时你的子弹明明打中了敌人却没啥反馈。
未必是因为敌人锁血了，可能只是因为对方通过一些手段改变了碰撞机制的评判标准。
这种情况下你射出的子弹被认定为无效碰撞，从而使科技玩家达到一种类似于无敌的效果。
这只是利用碰撞机制进行开挂的一个例子而已。
此外还有“轻功水上漂”之类的外挂也都是碰撞机制上做文章的。
这种利用碰撞机制开发的外挂一般很难彻底杜绝，毕竟涉及到游戏核心机制。
在这之后，林灰又想到了游戏引擎。
游戏引擎虽然很好，应用场景很广阔。
但终究是“工业软件”。
这样的软件是需要长时间的精力去打磨的。
总之，虽然以前很多游戏林灰都可以肆无忌惮的直接搬运。
但像游戏引擎这种需要积年累月时间才能搞定的东西直接拿出来怕是不符合技术发展的逻辑。
在此之前林灰要经过长时间的铺垫。
不过具体怎么入局游戏引擎这个方向呢？
以UNITY这款游戏引擎为例，前世这款游戏引擎的发展由单平台到多平台可以说是一个极其漫长而又曲折的过程。
这条道路显然不适合林灰，林灰的时间太紧迫了。
林灰灵机一动，突然想到了什么。
从插件开始入局游戏引擎似乎是个不错的选择。
游戏引擎也有插件？
没错，一款游戏引擎问世以后虽然很强大，但也不是能像像瑞士军刀一般能解决各种各样的场景。
这个时候一些插件作为游戏引擎的补充就很有必要了。
之前在开发《HILL
CLIMB
RACING》的时候林灰灵机一动想到的Ferr2D
Terrain
Tool其实就是一个插件。
这种插件常常被用来开发2D场景中的地图。
除此之外，还有很多插件。
虽然这个时空游戏引擎不少，但游戏引擎插件可不少。
很多开发者和开发公司都会顺带鼓捣些游戏引擎插件以使游戏引擎效率更高。
在这种情况下，林灰入局游戏引擎的插件也不至于引发什么涟漪。
不过问题来了，在一堆游戏插件的红海中林灰能杀出重围吗？
当然能，毕竟林灰有信息差的优势。
同样是Ferr2D
Terrain
Tool这款游戏的插件。
2021版本的该插件比14年的该插件实用性不知道高到哪去了。
更何况林灰硬盘里一堆现成的插件。
这种情况下，林灰想入局游戏引擎的插件未必不能杀出一条血路。
虽然2021版本的Ferr2D
Terrain
Tool该插件比14年的该插件实用性不知道高到哪去了。
但林灰并不打算截胡，林灰打算由易到难，先从普通的游戏插件入手。
而什么样的插件简单呢？
最基础的应该是涉及到2D游戏碰撞检测的插件。
在2D游戏中，一般存在模拟重力和阻挡物的存在。
而在游戏中的业务对象，例如人物、飞机、宠物、道具物品等，受到用户的操作控制，需要实现业务对象在地面上行走、掉落、不可通过地形的阻挡等移动，或者，需要实现诸如射击类游戏中的子弹等道具物品飞行、命中等动作，经常在游戏中发生碰撞。
因此，在2D游戏中需要进行碰撞检测。
比如利用flash就可以实现简单的碰撞检测。
这种方法在检测两个对象是否碰撞主要看二者是否重叠。
具体地，通过判断两个业务对象(例如人物的显示对象)之间，是否有像素点的重叠。
如果有，则判断这两个业务对象发生碰撞；如果没有，则判断这两个业务对象没有发生碰撞。
除了这种方法还有很多检测碰撞的方法。
很多人对检测碰撞都有不错的思路。
在这种情况下林灰以GRAY
FOREST的身份搞一个检测2D游戏中碰撞的插件也没啥。
林灰在前世那台ThinkPad里翻找了一会。
几乎没怎么费力就找到了一个适用于unity游戏引擎的2D游戏碰撞检测的插件。
这个插件前世存在，这个时空却不存在。
这无疑大概率将成为林灰这个重生者的福利。
而且以林灰的眼光来看这个2D游戏碰撞检测插件还算不错。
这个碰撞检测插件确实要比Unity游戏引擎里面自带的碰撞检测装置好用一丢丢。
但其实两者功能性上的区别其实不是很大。
林灰之所以说这个2D游戏碰撞检测插件“还算不错”不是从“这个插件多么多么好用”这个角度出发的。
而是从插件的设计风格来说的。
这个2D游戏碰撞检测插件几乎不带任何开发者的个人风格，十分简约。
这种情况无疑意味着林灰搬运的可行性。
要知道有的项目虽然技术不复杂。
但由于开发者个人风格极其浓厚，实际上这类项目是很难搬运的。
这类项目贸然搬运的话只会带来一些麻烦。
而具体到现在这个2D游戏碰撞检测插件则没那么多麻烦事。
虽然搬运这个2D游戏碰撞检测插件是可行的。
但名字什么的还是要改动一下的。
林灰是资深起名废。
苦思冥想许久，林灰也没想出比较牛比的名字。
林灰干脆直接将这个插件随便起了一个中规中矩的名字：
——CRASH_2D
这之后，林灰又仔细检查了几遍这个插件所涉及到的底层内容。
还好这只是一个很小的插件，加上林灰工作效率很高思维很活跃。
因此检查起来并不是很费力。
在确定没什么撞车的隐患之后。
林灰就将CRASH_2D这个插件上传到Unity游戏引擎的插件库里。
插件库似乎是这个时空独有的产物。
和前世到处找插件的局面不同，这个时空Unity还有官方的插件库。
这让林灰稍稍有点意外。
前世的插件基本都是散装放养的，而不是像现在这样圈养。
至于为什么Unity搞个这样的插件库？
在性能不够先进的情况下，似乎也只能通过类似于官方社区这种东西培养用户情感。
上传CRASH_2D这个插件的时候，林灰使用的是GRAY
FOREST这个身份而不是再换一个新马甲。
马甲再换多一些，林灰估计他本人都快分不清了。
而且之前微博上无端兴起又莫名结束的风波已经证明了马甲太多并不是好事。
虽然GRAY
FOREST这个马甲一贯是林灰拿来开发游戏的。
但现在开发点游戏引擎也没什么。
之前林灰就已经考虑过这点了。
很多牛比的游戏开发公司在开发游戏时甚至会顺手搞定游戏引擎。
至于说普通的游戏开发者，虽然没有单撸游戏引擎那么离谱。
但一些牛比的游戏开发者在使用游戏引擎开发游戏的时候都顺带着开发一些游戏引擎的插件也不是不可能。
以林灰GRAY
FOREST现在对应的名声，顺手搞定几个游戏引擎插件在外人眼中根本激不起什么水花。
此举不但不会引起外界的质疑，而且很可能为林灰收获新一轮的赞誉。
具体到CRASH_2D本身。
值得一提的是，涉及到unity这款游戏引擎的插件如果非要细分的话。
其实可以细分为两种的，一种是托管插件，另一种是原生插件。
托管插件使用的是
Visual
Studio
等工具创建的托管.NE
程序集。
此类插件仅包含.NE
代码，因此无法访问.NE
库不支持的任何功能。
不过，因为Unity
使用的标准.NE
工具是可以访问托管代码来编译脚本的。
因此，托管插件代码和
Unity
脚本代码之间几乎没有用法差异。
相比于托管插件，原生插件是特定于平台的本机代码库。
插件可访问操作系统调用和第三方代码库等功能。
客观来说托管插件相对于原生插件同Unity的兼容性更好。
林灰搬运的CRASH_2D就是一个托管插件。
这无疑意味着该插件能同Unity有更好的兼容性。
相信这样一款兼容性强的软件尽管技术不是特别领先，应该也会有一定的受众。
因为将CRASH_2D设置为免费的插件的缘故。
几乎没怎么费力，这个插件就通过了审查。
在通过审核之后，只间隔两三分钟就发现在Unity插件库的免费插件里已经可以搜得到CRASH_2D这款插件。
至于为什么要将这款插件设置成免费？
无非就是靠免费走量争用户基础。
虽然现在CRASH_2D这个插件是免费的。
但有了用户基础，今后赚钱只会事半功倍。
而且利用插件赚钱其实是次要的。
重点是借助于插件向外界证明林灰有对游戏引擎进行拓展、升级和改造的实力。
从而慢慢向外界表明林灰有入局游戏引擎这个领域的实力。
而后寻找一个合适的时机直接下场做游戏引擎。
相比于插件小来小去的利润。
涉及到游戏引擎才是真正广阔无边的“钱景”。
当然细究的话，其实插件方面将来还是有机会能给林灰赚个千八百万美元的。
不过人的欲望都是升级的。
现在的林灰可不是千八百万美元就能满足的了。
林灰图谋的是更大的机遇以及更广阔的天地。
即便林灰真的要依托插件什么的挣钱。
也不会依托一个2D游戏碰撞检测装置来赚钱。
尽管这个时空很多地方都短腿吧。
但也没落魄到让林灰随便拿出一个2D游戏碰撞检测的插件也能赚钱。
毕竟像2D游戏检测装置这是很多游戏开发必不可少的一部分。
类似于雷霆战机、贪吃蛇之类的游戏都要涉及到碰撞检测。
这个时空2D碰撞检测已经很成熟了。
林灰之所以要上传一个2D游戏碰撞检测的插件恰恰是因为这东西简单且成熟。
简单意味着方便入局；
成熟意味着即便以此入局也不会引入注目。
有这两点就足够了。
对于现阶段的林灰来说入局远比赚钱更重要。
退一万步讲，即便是林灰真的要利用碰撞检测插件来赚钱的话也只能是3D游戏碰撞检测。
依靠2D游戏碰撞检测这类的插件想赚钱几乎不可能。
想到3D游戏碰撞检测，林灰突然想到了一个能够搞钱的技术。
——3D游戏异常碰撞检测技术。
林灰记得前世上大学的时候为了评奖学金还申请了一个3D游戏异常碰撞检测方面的专利。
尽管当初搞这个东西有跟风的意味吧。
但不管怎么说林灰前世对这个专利也忙前忙后一段时间。
因此尽管重生了。
林灰对3D游戏异常碰撞检测依旧印象深刻。
正是因为这种印象深刻，成了重生之后林灰的一项福利。
说起来3D游戏异常碰撞检测技术这东西在前世来看虽然很鸡肋。
但放到现在妥妥的黑科技啊。
脱离时代背景谈技术先进与否明显不妥当。
放到前世这项技术虽然只是林灰跟风之作罢了。
但现在却稳稳的领先水平。
不止是领先全国，而是领先世界。
前世3D游戏异常碰撞检测技术对应的专利也是林灰前世大三时搞得技术。
而林灰大三大概对应前世的2016年。
此时却刚刚2014年。
也就是说，这样一项前世一般般甚至泯然众人的技术放到现在起码领先世界先进技术一年多。
涉及到纯粹游戏方面的东西：
领先一年多可以说是极具诱惑力了。
游戏技术更迭本来就很快。
一年时间甚至足够有些游戏来四个大版本迭代了。
这种情况下，林灰前世搞得3D游戏异常碰撞检测技术如果拿到今天来其实是很有价值的。
涉及到“3D游戏异常碰撞检测技术”虽然听起来很高大上。
但用途其实蛮直观的——防外挂。
其防外挂的原理跟碰撞游戏的机制有关系。
碰撞游戏是这样的机理：
计算机产生自动游戏对象，从显示界面的一个方向出发按照一定路径行进。
用户控制一个控制游戏对象向与其余游戏对象相对的方向进行，当玩家控制游戏对象或者控制游戏对象使用的道具（比如说游戏里的枪）和其余游戏对象在显示界面上发生碰撞时取得相应的分数；
累积用户在一场碰撞游戏中取得的分数获得游戏积分，通过游戏积分的高低来衡量用户玩碰撞游戏获得的成绩。
比如说飞机射击类游戏、碰撞球游戏等这些都是碰撞类游戏；
而一些枪战类游戏更是属于碰撞类游戏。
除此之外，还有……
总而言之，碰撞类游戏是相当广泛的。
在碰撞游戏如此广泛的情况之下，一些睿智的科技狗就会有想法了。
为了获得较高的游戏积分，通过外挂程序等辅助程序修改碰撞游戏程序，从而使得游戏能够取得更高的游戏成就/积分。
甚至改变游戏里的一些机制，只为了更强的游戏表现。
比如说枪战游戏有时你的子弹明明打中了敌人却没啥反馈。
未必是因为敌人锁血了，可能只是因为对方通过一些手段改变了碰撞机制的评判标准。
这种情况下你射出的子弹被认定为无效碰撞，从而使科技玩家达到一种类似于无敌的效果。
这只是利用碰撞机制进行开挂的一个例子而已。
此外还有“轻功水上漂”之类的外挂也都是碰撞机制上做文章的。
这种利用碰撞机制开发的外挂一般很难彻底杜绝，毕竟涉及到游戏核心机制。
温馨提示：按 回车[Enter]键 返回书目，按 ←键 返回上一页， 按 →键 进入下一页，加入书签方便您下次继续阅读。