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機器上的記憶體和硬碟一樣，而現在的手機儲存空間大家都習慣叫成手機記憶體，無論是啟動並執行空間大小還是儲存程式的空間大小統統叫做記憶體……（不知道是不是這樣，我只是自管自這樣想的而已，難說真的都是記憶體也說不定，難說Runspace和儲存程式空間是公用的也說不定……汗！）圖形其實到了機器裡面，有用的，在記憶體中放的也就是些圖形的點陣資料而已（也是個人想想……汗！），標記資料沒什麼大用，也許建立圖形資料的數組時能用規定下大小等。而所有地形全載入，可用Runspace就少了，當前地圖中沒有用到（顯示）的地形在記憶體中就造成了浪費等等。關於做成一個檔案後的效能問題先撇開不談，這個是程式最佳化階段要解決的問題了，當前要解決的問題就是怎樣把讀入的一個檔案給分割開，取我們所需要的部分！其實這就是大部分平面2D遊戲中常用的手段，既能減少I/O讀取出錯機率又能有效減少資料的冗餘。接下來的關鍵問題就是怎樣去把這個一塊的圖形切割開來。由於前面提到了許多說這個地圖編輯器是在PC上啟動並執行，所以，其實按照現在的PC的海量儲存以及系統安全形度來講，做成單獨的資源檔也沒什麼大的影響，但是考慮到這個遊戲我還沒有開始主要程式階段的製作，而是從地圖編輯器開始著手，所以也是為了可以讓以後的主程式用上這裡所用到的方法（複用，其實是懶惰），所以還是這裡就開始做掉得了，雖然遊戲和地圖編輯器採用兩套不同的資源系統是完全可行的，本來就不是要所見即所得 (WYSIWYG)麼，Mobile Phone有不是PC是吧。

       呵呵，有點累了，終於把最近的思路給梳理了一下，還算整齊得放到了這裡。這個有點虎頭蛇尾，因為最關鍵的分割問題沒有解決。是的，因為我現在只是一個想法一個思路，並沒有付諸實際，而且具體的分割技術還沒有看過，只是知道有這麼個方法，所以，這裡也只能寫到這兒了，不過決定下篇文章就關鍵解決這個記憶體中的圖形分割，嘿嘿，要開始看起來了啊～最近也快開學了，忙裡忙外的，有興趣的朋友或者有這方面技術又願意探討下或者指點我下的人加QQ群：8882320呵呵，不是JAVA的也無所謂，覺得還是思路最重要了，至於實現的語言是個工具的問題。工具是可以掌握的，而思路和想法是與生俱來的。望大家不吝嗇賜教。^_^