Java学习笔记之SWING -- 基本SWING程序（地图的层的分布以及图形资源的储存）

前言：最近烦人的事情比较多，其实也无暇顾忌这里的MapsEditor了，而且没有实现的功能是那么的多，市面上又有了那么多的现成的，比较完善的地图编辑器，自己对Java又还没有达到融汇贯通的境界，那些有用的类库又都是一知半解的，所以最近的路走了比较艰苦，有个人能一起走，也许就轻松多了。程序员是需要交流想法的……

      最近CSDN的Blog终于OK了，至少我的Blog算是恢复正常了，能编辑能显示能聚合……感谢这里辛劳的管理人员们的付出……近段事件自己的事情也比较多，妈妈要住院开刀，又频频发病，自己只能笑颜相对，但是自己的苦大仇深却无人能倾诉……觉得GF也不好和她多说什么，人家现在自己还泥菩萨过江，是正需要我安慰和开导的时候，如果反过来照顾我，那自己也太窝囊了点，至少得表现出我现在什么都能应付了过来的样子。由于顾这顾那的，这里也就没怎么照顾了，也好久没有新的文章发表了。觉得写的文字就是我Blog里面流动的血液，长时间的停滞，会使血液流经处的组织坏死……也没有硬性规定一分钟心跳一定要多少，但是至少要保证机能的健全。慢慢流也是流啊……

      回到MapsEditor，这里不得不注意的问题有两个：1、地图的层次显示。2、地图资源的格式与储存。 

      地图的层次显示是尤为重要的，暂且抛开以后的可编辑可优化可复用的调子不说，单单从显示效果上来讲就是必须的，要是再说到以后的复用便利性等等就更加显得位尊权重了。首先，抛开直接程序绘图（不再本次地图编辑器载入资源范围），你要显示的地图当然是外部的图片文件了，那么透明的图片顺理成章成为了必须的资源。打个比方，这里有两张图片：和。如果我们要在一片绿油油的草地上放上一个木篱笆，那么显示结果应该是篱笆的后景是绿色的草地，所以，前面的木篱笆本身就要求是透明的图片，然后放到草地上的层中，并且把这层也设置成可以透明显示，那么就能把一个木篱笆放到草地的地形上，而不是像上面显示的那样，篱笆区域的背景是蓝灰色的，如果是这样，那么在草地上放置篱笆不是变得非常的怪异？！篱笆只有下端是插在草里的呀（现实世界）。所以，我们要定义许多层（其实在前面关于层的文章中就应该提到，这里只是说清楚而已，实在是最近没什么新文章好写啊，炒炒冷饭也好，能品出味道来也罢了……），最底层的图层是放置那些基本地形用的，如草地，普通山脉，雪地，泥地等等，它们不需要透明（如果一个层中所有的对象都是非透明的，那么这个层也就没有设置透明属性的必要了，当然，这是针对我这里放入图片资源来说）。而上层的，是需要透明的。除了篱笆放在草地上之外，比如树立的石碑啊，沙漠中的骨头啊之类的。如果对于每个对象在不同后景（如雪地和草地）都要画针对的后景色的画，那简直是一种资源的冗余，空间的浪费！做成透明的往上一放，因为透明效果自动显示出后景色不是更好，其实这个一般来讲，大家都能想到的。（注：从游戏的角度来讲，角色必须独立一层，他们是在地形上移动的，也必须露出背景色；而菜单又是最顶层的，因为菜单调出必然要遮盖住所有游戏画面。当然，这些层并不在地图编辑器的讨论范围内，因为单单是地图并不保存这些。不过也可以像魔兽3一样，把事件编辑加地图编辑还有任务安排统统都做在一起，这样就使得游戏的任务编写变得非常独立，一个任务就是一个文件，包括地图、人物、任务、文字说明等等，这样会使得玩家能自己发挥想象，编写出自己的游戏剧本来并且实现它，当然，这些资源都是被事先定死的。）其实地图文件中不仅仅只保存地形，而且还可以保存整个地图的可移动标志矩阵（自己临时起的名字，也就是一个和地图同样大小的2维Boolean矩阵，表示对应的该点地形上可否移动）。当然，也许这个更加适合RPG游戏，而纹章类游戏不同的职业的可移动地形是不同的。比如骑士只能在非山脉陆地上移动，而龙骑就可以在地图任意位置移动（相对于野外来说）。所以单单一个只有true和false的二维数组是不能胜任的，现在的想法就是给不同的地形以不同的移动损耗，只有当职业的移动力大于移动损耗时才能一定移动到此地形上，不过对于飞龙来说就比较特殊了，因为它们比较无视地形，任何地形（相对于野外）对他们来说都之消耗1点的移动力。地形应该存储自己的移动力损耗值，可以记录到一个静态的数组里面，对应地形的移动力损耗，而编辑器输出地图文件时也输出一个字符串来记录地形上的损耗值（通过地形的index查询对应的移动力损耗值数组得到）。其实这个地图上的损耗值是可以单单读入一些地图符号后转换搜索在程序中算出相对应的地形的移动力损耗的二维数组来，但是考虑到这个计算量所耗费的时间可能高出I/O的读取的时间，况且又是在手机上（虽然我相信ARM的性能），但是总是不能比PC机的处理速度，至少现在是这样。而且测试之类的都是在PC机上进行的，也许你的电脑觉得这么点时钟损耗根本犹如鸿毛，但是也许你的手机并不这么想……（注：对于这些移动力损耗的字符串并不是给地图编辑器用的，当然，也可以用作显示移动力需求，来测试一个关卡任务的平衡性和难度。在地图文件中，因为都是用UNICODE或者ASCII编码的，所以都是一些字符，要区分地图标记和诸如地图大小，移动力损耗值之类的数据，必须分开对待，比较推荐的一种做法是用地图文件的标记，保留关键字！虽然像编程语言用的手法，但是确实太管用了，谁也没说保留字只能用在Java、C＋＋、Delphi这些里面啊～当然，这样地图文件的读取时就要做相应的过滤了，这个不在本文的讨乱范围内。）

      上面说到了资源利用的问题，不能太浪费是吧，现在就要讨论第二个问题。想到了服务器程序的一些东西。以前在做网络编程的时候，一个服务器响应程序做了自认为满不错，把一切都做到服务端，访问端只要发几个控制信号，服务端就会发回大串的数据，比如以前做的那什么星座算命（当然，数据都是老师给的，我还没到那么能掰的境界），所有的星座的信息之类的都在服务器端，而Client只要发出生日期到Server，服务端就在本地调出并查询对应生日的信息，并向Client发送对应的描述字符串，而Client受到后做的也简单，直接在Console显示这些字符串就完成了。虽然时很小的程序，但是仔细扣扣还是能扣出很多问题来的。开始编好程序后还觉得满不错，还像模像样的，你发个出生日期过去就马上返回一些介绍啊，意见啊之类的回来，但是只要你很多人一起（比方500个Client）同时发起查询（当然，做了Thread，不然一个一个等还不真的搞笑），那速度就慢很多了。后来又考虑到远距离的问题，比如把这个Server发给美国的朋友，当他们开起来后，我一个Client去访问，速度还要慢～为什么？一、一个一个访问对于现在的的时钟频率的PC来说，简直不值一提，一个flash就完成服务返回信息了，但是当多人同时发起服务请求时，自然有处理上限，超过了负荷，负荷外的请求自然就被搁置了。二、这个网络的程序还要考虑到网络的拥塞状况，说实在的，美国和中国的传输速度真TMD不怎么样，返回比较大的文件时，自然速度慢了要死（人家还给你切片，分路由传递……到了目的端还要重组……美国～有你等等的）。对于第一种情况，这个还真的是看你机器的能力了～而就第二种情况来讲，路上出的问题，我怎么能保证，又不是ATM，谁叫它是Internet呢？人家秉承了中华民族的光荣传统：无论做不做了到，接了再说，面子重要，我尽力而为就是了。但是归根结底，这两个问题都能放到一个地方来解决～第一个问题关键是一旦服务器负荷满了，工作就得不到迅速解决了，那么我把重的任务放到本地Client来做（当然，对于这个星座算命的程序显得不切实际，查询要是放到本地，我还要你Server做什么）。而第二个问题是发送全部数据文件过大，受到不稳定速度的影响，要是服务器发送几个控制信息给Client，然后由Client根据Server发来的控制信息来做显示（数据本地化）的话，小数据受到外界不稳定因素造成的延时大大小于大数据（很明显，造高楼大厦一样，一道工序延时，比方运送施工材料，会延迟整个大厦的竣工时间），你给他出错的机会少了，它给你出错的几率自然降低了。现在很多的3D网络游戏就是这样做的，如果屏幕上所有的数据都是服务器发出，那么估计之间也要用骨干光纤连接才能保证游戏顺畅了……放到地图资源上来讲，虽然问题不是同一个，但是解决的思路是差不多的。地图资源是图片，载入外部文件总会因为这样那样的原因导致抛出异常，这样在basic上就出了问题，资源都没有，谈何显示啊！比方以前的一些文章中，我的地图文件是单个的16×16的png图片，要是其中一个出了点岔子，那我整个程序就糟了殃了，结果无非运行不能，运行报错，如果逻辑么有问题那也会导致显示不能……那么多地形，如果都做成16×16，那只要每个外部文件有1％的概率载入不能出现，10张地形还好，要是100个地形，那我不是得被考验100次1％哪怕前面99次都没问题，第一百次时碰到这个1％我还不哭死，而前面的10个地形我就早通过了，但是还是要考验1％10次啊！再者说了，每种文件的都是有自己的数据格式的，也就是说，文件里面包含了数据部分和标记部分。数据部分自然不用说了，标记部分就是记录了文件的格式，文件的大小等等等等有关的信息。给个小学毕业就能算的题目：假使，一个png图片，用1KB的大小（当然不会那么多，打个比方，为了计算方便而已）来用作标记，如果256×256大小的png图片暂且算他257K（纯粹为了计算方便），那么也就是说其中256K用来记录图片数据。如果把它分为16×16大小的文件，那么一共可以分256个16×16的小图片，每个文件的体积为256÷256＋1 ＝2KB，那么总共的文件大小就变成2×256 ＝ 512KB大小了，和原来的257KB相比，体态魁梧不少～当然实际中的标记信息不可能到达1KB，但是，如果你把文件分了越小，那么标记信息占整个文件的比例也越来越大，分到相当于图片数据和标记数据同样大小时，就会出现如上的计算结果了（大两倍）。所以，无论你怎样，只要分开了图片，就会有数据冗余。当然，冗余并不一定是不好的，只不过这里来看，没必要造成这种冗余，但是怎样控制就看个人和项目的需要而定了。如果没有了冗余反而造成了使用和控制上的困难，那么适度的冗余就是可行的。回到正题，正如以上的两个问题：出错概率和数据冗余，使得把这些地图资源全都做成一个图形文件中去显得非常必要！读入一个文件，只要担心一次1％就可以了，而且标记信息也只有一份，把冗余降至了最低限度。两个问题一个解决方法～呵呵。但是手机的运行内存容量和存储容量又是两个概念了，这就像是PC机器上的内存和硬盘一样，而现在的手机存储空间大家都习惯叫成手机内存，无论是运行的空间大小还是存储程序的空间大小统统叫做内存……（不知道是不是这样，我只是自管自这样想的而已，难说真的都是内存也说不定，难说运行空间和存储程序空间是公用的也说不定……汗！）图形其实到了机器里面，有用的，在内存中放的也就是些图形的点阵数据而已（也是个人想想……汗！），标记数据没什么大用，也许创建图形数据的数组时能用规定下大小等。而所有地形全载入，可用运行空间就少了，当前地图中没有用到（显示）的地形在内存中就造成了浪费等等。关于做成一个文件后的性能问题先撇开不谈，这个是程序优化阶段要解决的问题了，当前要解决的问题就是怎样把读入的一个文件给分割开，取我们所需要的部分！其实这就是大部分平面2D游戏中常用的手段，既能减少I/O读取出错概率又能有效减少数据的冗余。接下来的关键问题就是怎样去把这个一块的图形切割开来。由于前面提到了许多说这个地图编辑器是在PC上运行的，所以，其实按照现在的PC的海量存储以及系统安全角度来讲，做成单独的资源文件也没什么大的影响，但是考虑到这个游戏我还没有开始主要程序阶段的制作，而是从地图编辑器开始着手，所以也是为了可以让以后的主程序用上这里所用到的方法（复用，其实是懒惰），所以还是这里就开始做掉得了，虽然游戏和地图编辑器采用两套不同的资源系统是完全可行的，本来就不是要所见即所得么，Mobile Phone有不是PC是吧。

       呵呵，有点累了，终于把最近的思路给梳理了一下，还算整齐得放到了这里。这个有点虎头蛇尾，因为最关键的分割问题没有解决。是的，因为我现在只是一个想法一个思路，并没有付诸实际，而且具体的分割技术还没有看过，只是知道有这么个方法，所以，这里也只能写到这儿了，不过决定下篇文章就关键解决这个内存中的图形分割，嘿嘿，要开始看起来了啊～最近也快开学了，忙里忙外的，有兴趣的朋友或者有这方面技术又愿意探讨下或者指点我下的人加QQ群：8882320呵呵，不是JAVA的也无所谓，觉得还是思路最重要了，至于实现的语言是个工具的问题。工具是可以掌握的，而思路和想法是与生俱来的。望大家不吝啬赐教。^_^