j2me游戏引擎的基本构成--场景管理器 |
| 作者:点轻烟 来源:j2medev 发布时间:2005-11-3 14:04:25 |
|
前言 上一章我们用通俗易懂的电影拍摄过程大致的了解了一下游戏引擎,希望大家可以了解一个引擎都有哪些部分。恰恰就在帖子贴出的第二天一个朋友问我:“游戏框架和游戏引擎有什么区别?”。当时我就蒙了一下,转眼我又想到了汽车与引擎的关系,于是回答“框架就相当于汽车,引擎就相当于汽车的引擎”。不知道大家看明白没有,框架决定了引擎的作用,比如一个j2me的游戏框架是不可能运行一个PC的游戏引擎,就像小汽车的引擎和客车的引擎不可能通用一样。还有朋友问我,你讲的里面那些东西每一个都是单独的类吗?请大家注意,抽象构成和现实组织有着不可分割的联系,但同样有着巨大的差距,就像钻天猴与“神州5号”飞船的差别一样。原理是一样的,可是他们差别同样巨大。一定要活学活用啊。 第一节 场景管理器(world) 在PC中我们有着海量可以使用的资源,包括各种各样的资源 ,要说有限制也是机器本身的限制。甚至里面一个小小的文件都有可能比我们的j2me游戏本身都大。于是乎在做PC游戏的时候更多考虑的是游戏的效果如何,运行速度如何,而我们也可以天马行空的使用着各种我们可以使用的特效。于是渲染器成了引擎中的重头戏,呵呵,谁不喜欢看自己的游戏能玩出好多特别Cool的效果来,反正我想。唉,虽然为PC的游戏兴奋了半天可我们毕竟不是做PC游戏的,我们做的是比PC游戏更牛X的j2me游戏。为什么说更牛X呢,敢问那个PC游戏可以在仅仅使用100k heap的情况下可以把《古墓丽影》《细胞分裂》这样的游戏做的炉火纯青,玩家爱不释手?100k heap,这是什么概念?都学过计算机理论,知道那是多大。 在这种情况下我们引出第一次从天堂的堕落:场景管理器。我们仍然拿拍电影来做分析。第一章那个小片段中的场景是一个狭窄的街道,中间要放好多道具,“导演”不停的要求“剧务”放这放那,那么如果“剧务”足够聪明的话他肯定要采取一种比较省时省力的办法,而不是一趟一趟的往库房跑。但是本身剧务可以放置道具的地方并不多,于是一次取多少道具以及道具的使用率就决定了“剧务”的劳动量。同理,我们可以把“剧务”可以控制的空间比作heap,“剧务”去库房拿“道具”比作I/O操作。既要最大程度满足“导演”的需求,又要保证“时间”不过多地浪费在去“库房”的路上又不能超出当前所能控制的空间....其实这个真的很难!就像自己的女人要求天天跟她在一起,而自己又因为要挣钱奔波一样^_^。问题出来了,至于怎么样最省力我们仍然需要不断的探索。一个好办法就是“剧务”首先掌握“库房”中“道具”存放位置,等需要的时候一步到位拿出来即可,省去找寻的时间。至于怎么满足“导演”的需要那是另一码事,咱们解决这个问题。我相信大家在学习过程中看代码是最直接,最有效的方式,为了证明我的想法我找了一个S40版的《细胞分裂》来学习研究一下。(如果大家已经看过我的msn 空间了,下面可以略过)第一步从我们的分析中就可以看出应该是“掌握道具在库房中的位置”,这个嘛和我们打的文件包是有一定关系的,需要在文件中加入一些附属的信息,下面是gameloft细胞分裂部分文件操作代码,代码中有详细说明。在我的感觉中gameloft一定采用了什么方法。我曾经大概猜测了一下,无非就是将文件的一些信息扔到一个包里然后在包里记录一些文件的数据信息,比如便移量什么的。我的包就是那么作的,但是缺点很明显,必须要一次载入所有的资源,也不是必须,如果不那样就每次根据需要 首先来看gameloft的第一段代码:(反编译后的) //这里取了两个byte的数据,并组合成了一个整数,仔细想想的话不难发现这是这个包中资源的个数 //这段话又是什么意思呢?又+又*的,晕死了。到最后我再告诉大家这是做什么用的,主要得根据数据结构来说 //难点终于来了 这段代码中并没有反应出系统载入了一个包,而是一些乱七八糟的东西,这段代码也是一直困扰我的地方,明明是载入东西,可是却载入了一股子整数。没办法,接着看吧,也许整合起来就知道做什么用的了。 private static final byte[] addRecord(int i1) |
| [] [返回上一页] [打 印] |
|
文章评论 |
