LGame-0.3(Android与JavaSE游戏引擎)正式发布，新增SRPG制作模块

最新推荐文章于 2019-02-09 09:01:58 发布

iteye_702

最新推荐文章于 2019-02-09 09:01:58 发布

阅读量90

点赞数

文章标签：移动开发游戏 java

2011-05-27 留言：

目前svn中有一个0.3的小补丁(LGame-Android-Core-0.3(revise).jar)，修正了在初始化设置Mode.Fill时的自适屏低效问题。另外增加了Max（将游戏View大小设置为手机屏幕极限大小）和FitFill(成比例的全屏游戏画面（未必会填充满整个屏幕），游戏View将随着maxScreen函数设定的初始大小成比例拉伸)两种模式，有需要的话可以去SVN的LGame-Android-0.3文件夹中下载此jar。也不算BUG更新，只是影响运行速度的算法修正，特此一提。

2011-05-24 LGame-0.3.0（含Android版及JavaSE版）：

下载地址（内含示例工程、源码及jar）：http://loon-simple.googlecode.com/files/LGame-0.3.7z

更新内容：

1、新增SRPG模块（独立jar），该模块可以极大简化用户开发SRPG或SLG游戏所需流程，另外也可用于R剧的制作或和其它模块混合使用（比如模仿《武林群侠传》仅将此模块作为战斗模式用）。

2、新增LPixmap类，用以处理象素级图像渲染操作，虽然它所生成的图像不会依赖Bitmap，但缺点是渲染到屏幕上的速度较慢（稍后渲染机制改为OpenGL即可解决），它的API与LGraphics的API基本等价。

3、新增PlaySoundManager类及其关联类PlaySound，作为SoundPool类的封装，可以按资源ID读取APK中的音频文件及进行常规音频操作，Screen中同时添加有调用函数（仅限Android版）。

4、新增部分功能类，同时为超过20个原有类新增了不同的操作函数。

5、修正了所有于较早前版本发现的BUG以及改进了部分过时算法。

6、取消ThreadScreen类，为标准Screen类新增waitFrame与waitTime函数，用以在其它线程中暂停主线程指定的帧数或时间。

7、自0.3版起，为避免触摸屏误操作，AVGScreen以及SRPGScreen中的剧情选择框强制要求双击确定（仅限Android版）。

另外，对应本次更新取消了旧版的SLGTest示例工程，改为新版的SRPGTest示例工程。

最后，LGame正在进行WP7移植，预计11月左右可以完成。

_____________________________________________________________________

新增的SRPG模块结构如下所示：

srpg模块结构

本次新增的SRPG模块，就本质而言是一种“特定游戏类型专用开发包”，它与标准LGame核心库的差异在于，LGame的运行完全不依赖于它，也并非特定游戏的开发就必须使用它。但是，小弟依旧强烈建议您使用这些专用包来开发特定类型的游戏，其原因主要有如下两点：

其一曰、立象以尽意

通常来说，越是复杂的游戏类型，越难以轻易的设计与开发出来，比如很多初学者在掌握了贪食蛇、俄罗斯方块之类简单游戏的制作方法后，便会自认为已初窥游戏开发门径，甚至意气风发的跳出来“指点江山”。可如果你想打击一下此人的锐气，也非常简单，只要让他在不使用RMXP、RMVX、Sim RPG Maker等业余游戏制作工具的前提下（PS：小弟并非歧视这些工具，毕竟有amaranthia(http://www.amaranthia.com)这样收费的RM游戏网站存在，不过即便是amaranthia上出名的游戏，要移植到iPhone或Android等平台实现高盈利，也大多聘请专业程序员移植，而非原作者自行搞定），去独立制作一款水准近似上世纪九十年代早期如《运镖天下》、《炎龙骑士团》、《仙剑奇侠传》“在当时”效果的游戏，甚至让他去再现九十年代后期如《血狮》、《江湖》之类“令人疯狂的神作”，都可能让他信心顿失，原形毕露。

但请注意，小弟这里并不是说《炎龙骑士团》就比贪食蛇复杂了多少，《仙剑奇侠传》又比俄罗斯方块难在了何处，因为无论多么复杂的系统，都是由一个个简单到“1+1”程度的基础部分组合而成的。或者说，难道《炎龙骑士团》中需要碰撞算法，贪食蛇就不需要吗？难道《仙剑奇侠传》中需要事件触发，俄罗斯方块的消除方块步骤就不算事件吗？其实差别只在于，很多人都知道俄罗斯方块该怎么编码，而那些人却未必知道《炎龙骑士团》该怎样编码。

事实上，即便对很多首次尝试制作俄罗斯方块等级游戏的初学者而言，大多也不能一蹴而就的独立完成编程，他们每每会从四处找寻现成的源码“参考”开始，再经过几次编译失败或者论坛请教的“痛苦”过程，最终才“恍然大悟”的设计出那些“完全自主开发”的大作。然而，我们就事论事，其中真正能够“闭门造车，出门合辙”，全凭自悟写出相关算法者，恐怕也只有少数具备天才、鬼才、偏才一类天赋者才能做到。

反向例证，如果小弟能够在一夕之间让所有俄罗斯方块算法全部从网络以及教材中消失，并且让所有了解这种算法的活人全部闭嘴（乃至灭口），试问又会有多少后来人，能够自行参悟出俄罗斯方块的算法呢？凭心而论，恐怕不多吧。又好像说，如果在未来的“第三次世界大战”中毁灭了现存的全部人类科技成果，那么即便人类没有因战争灭绝，我们的子孙后代又能凭空在短时间内重建整个现代人类文明吗？哼哼，恐怕到时能不用石头与棒子进行“第四次世界大战”，就已经是最好的结局了。

所以，假设大家都生活在一个并不存在任何“俄罗斯方块源码或算法”，甚至根本没有存在过“俄罗斯方块”的世界里。这看上去简单已极的俄罗斯方块，又会有几个人能凭空创造出来呢？——凤毛麟角，恐怕都不足以说明其稀少程度。

如果您基本认同上述所言，那么，试问如果一个人压根就没有见过《炎龙骑士团》、《仙剑奇侠传》之类游戏究竟是怎么写成的，您又怎么可能要求在这个天才与白痴都仅占极少数的世界上，占绝大多数的、智商中等的游戏初学者们，能够拥有凭空完成同类游戏的能力呢？

从世俗的眼光来看，游戏开发初学者与游戏开发高手间的差距仿佛在于编程水平，仿佛“高手”就多么大牛，“新手”就多么小白。但归根结底，原来也不过是对于“前人经验”的掌握程度不同罢了。更极端的说，其症结在于贪食蛇、俄罗斯方块之类源码随处可见，而《炎龙骑士团》、《仙剑奇侠传》的源码却远没普及到人手一份……

我们中国人喜用“阳春白雪，下里巴人”来比喻某些曲高和寡的情形。但仔细想想，简单的“下里巴人”是歌曲（其实是两大部分），复杂的“阳春白雪”也不外是歌曲吧（同样两大部分）？歌曲是什么，不就是一种特殊频率的声音嘛；而声音是由什么决定的，大家都知道“高强长色”(音高、音强、音长、音色)这些概念。只要找准节奏，鹩哥、鹦鹉都能学人说话，更何况是人学人。就算“阳春白雪”有千句，“下里巴人”仅一行，也无外是歌词曲调罢了。如果词多，难道不能用笔记吗？如果音高，难道不能用低频唱吗？如果意深，难道不能人云亦云的模仿吗？能学会“下里巴人”，怎么可能就搞不定“阳春白雪”呢？

曹家老二教导我们说“文本同而末异”，孔家老二教导我们说“吾道一以贯之”。此刻，如果将那些简单的游戏类型比作“下里巴人”，那些复杂的游戏类型比作“阳春白雪”的话，就势必可以推论出，“能为下里巴人者，亦能为阳春白雪”这一浅显易懂的道理。说白了，能唱“下里巴人”的人，首先就已经拥有了最基础的歌唱能力，大约也算得智力正常（总不可能楚国上千人齐唱智障歌曲……），当然也能学唱“阳春白雪”，或许唱起来存在“好坏”的分野，却绝对不存在“能否”的问题，这道理非常浅显。

所以，绝大多数在游戏开发领域还唱着“下里巴人”调调的初学者，其真正需要的仅仅是一个会唱“阳春白雪”的人，教他“阳春白雪”到底该怎么唱法，乃至让他听一遍完整的“阳春白雪”演唱流程到底如何而已。这并非什么玄而又玄的大道理，不过是生活常识罢了。而目前中国游戏业，尤其是Java游戏领域的最大症结在于，根本没人教初学者该如何演唱“阳春白雪”，他举目所及又都是“下里巴人”之辈，初学者们当然也只好无限期的充当“下里巴人表演者”了。

古人为什么会说“言不尽意、立象以尽意”？归结其根本，就是怕后人无法理解前人的想法，所以才要“立象”，立个标杆给后人看看，后人才好有个参考，才知道该怎么办，不该怎么办，该怎么搞，不能怎么搞。能举一反三，能达到“得意而忘象”固然是好，如果没有那种天资，至少能够有样学样，也就“虽不中，亦不远，不为谬矣”了。

小弟在这里坦率的讲，只要掌握了适当的源码与算法，对绝大多数智力正常的游戏开发者——哪怕是初学者而言，无论开发任何游戏也至多存在时间问题，而决不会有能力问题。

如今，小弟提供细分的游戏扩展模块，首要目的就是“立象”，立个简单可行的标准给大家使用，借用《西游记》中孙悟空吓唬小和尚的话，我是“打个棍样”出来看看。

PS：话说业余玩家做AVG有krkr可用，做RPG有RMXP、RMVX可用，做动作类有AGM可用，十几岁的孩子都能发布个上百MB的游戏“大作”出来，而咱们正经程序员如果只能拿俄罗斯方块，贪食蛇，超级玛丽之类糊弄事，试问还有天理吗？就是单纯为面子考虑，怎么也该升级了……

其二曰、致一而不乱

三国时精研玄学（特指哲学上的，而不是后来充斥宗教色彩的玄学）的王弼曾说：“夫众不能治众，治众者至寡者也；夫动不能制动，制天下之动者，贞夫一者也。故众之所以得咸存者，主必致一也；动之所以得咸运者，原必无二也。物无妄然，必由其理，统之有宗，会之有元，故繁而不乱，众而不惑。”笼统的说，王弼这段话的精要就在于“以寡驭众，以简解繁，致一而不乱”。

大家都知道，所谓游戏框架或者说引擎，首先是一个大马甲，作者是什么API都敢往上调用，其次就是一个大箩筐，作者是什么模块都敢往里封装。他们为了照顾绝大多数使用者，那些已有的或潜在的需求，图像、音频、视频、陀螺仪感应、地图、精灵、物理引擎等等什么都敢放……还不够用？没问题，还缺什么自己说，能说出来就能做出来。您还别不服气，只要你能说出名，绝大多数引擎作者就真能搞做出个对应模块给你看看。别说做不出，做不了不是显自己没本事吗？那还敢出来混？没这两下子，出门你都不好意思和别人打招呼。

可这样一搞，全倒是真全，广也是真广，但无论是性能上抑或专业性上，就全部打了折扣。为什么？俗话说的好，“贪多嚼不烂”啊，游戏引擎不是大力丸，不能包治百病，一旦想要解决所有问题，就难免会顾此失彼，这个用户说这样方便，那个用户说那样麻烦，你需要这个，他需要那个，真是出门的恨天阴，卖伞的恨天晴。一旦陷入这种因为产生问题而去解决问题的怪圈当中，就肯定会把有限的精力投入到无限的问题处理中去，那就永无出头之日了。为什么经常有所谓精英抨击开源游戏引擎不够专业？其实他们真正看不上眼的，就是这种“万能特性”才对。

用户的需求，当然不能不满足，但也不能为了满足用户需求而无限度的扩展框架造成恶性循环。可这中间的矛盾该怎么解决呢？其实也好办，答案就是王弼所说的“得咸运者，原必无二”。

都说众口难调，但为什么再多人去饭馆吃饭，饭馆他也不怕众口难调啊？您什么时候去饭馆吃饭听说过：“先生，实在是众口难调，因此我们一次就管一个人做饭，队都排满了，您明年请早”的说法？原因很简单，饭馆按菜谱点菜，客人来饭馆不是想吃什么吃什么，而是菜谱有什么才能吃什么。客户的需求是无限的，但需求的种类是有限的，您口味再怪，也无非是“酸甜苦辣咸”这五味自由搭配嘛。连做饭的都懂这个道理，我们这些每天除了“计”就是“算”，除了“算”就是“计”的主怎么可能不懂呢？

当然，比喻是这么比喻，小弟可没打算直接“卖”游戏成品给用户，比较来看的话，其实使用引擎的用户才是“开饭馆”的，你们才负责“卖饭菜”给游戏玩家，而引擎作者不过是个原料供应商，存在的意义仅在给用户节省个种菜养猪的时间。不过，小弟虽然不能“卖”你“成品”，可谁又说小弟连个“半成品”也不能“卖”你呢？

只要不玩穿越，现存的所有javaer恐怕都知道Spring，都知道一个Spring就能搞定几乎所有的Java企业级开发需求（不过某些复杂业务也需要其它组件支持）。可难道你对着Spring的jar大叫“芝麻开门”，它就会自行实现并构建出你所需要的完整代码了吗？肯定不是。难道是所有用户都不停的向Rod Johnson提要求，他就不停地实现用户要求了吗？肯定也不是（各种意义上都不是～）。事实是，Spring也不过是提供了一系列标准化的组件，为近乎所有企业级需求都提供了基础实现模块（或者第三方库的更简易封装），而任凭用户自由选取这些现成模块二次组合罢了。

既然同属javaer，既然有前人的成功经验，即使领域略有差别，小弟却一样可以照葫芦画瓢。我把AVG、SLG、RPG、STG、ACT、PUZ、FTG、RTS这些常见游戏模式各做一个标准封装，怎么着你也能用上一个吧？一切按标准走，这样就你也不乱，我也不乱了。

没错，小弟提供的游戏扩展模块，另一个意义就是充当一个“游戏半成品”或者说是一个“特定游戏类型的开发标准”，只要用户想开发的游戏与该扩展包属同一类型（综合类型混用即可），那么按照扩展包的套路去做，甭管您会不会“做饭”吧，至少也能炒个“菜”出来。它的存在，能够让开发《炎龙骑士团》变得像开发贪食蛇一样简单，让制作《仙剑奇侠传》变得比制作俄罗斯方块还要轻松。

_____________________________________________________________________

一直以来，小弟之所以将LGame版本号上升的很慢，其真正目的，原本就是为了在1.0版发布前完成AVG、SLG（SRPG）、RPG、STG、ACT、PUZ、FTG、RTS 等八大扩展包，以求为用户提供一套完整的2D游戏解决方案，而不是一套单纯的渲染引擎或者工具集合。坦率的讲，LGame本就是为了充当2D游戏领域的Spring而存在的。

以下是一些本次提供的SRPGTest工程中效果，虽然默认样式不够华丽，不过您完全可以放心替换，因为LGame组件全部采用绘制方式构建，所以无论什么效果都是可以制作出来的（而且替换样式也很简单，目前重载即可，稍后小弟会提供更加简便的style机制）。