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模塊，就本質而言是一種“特定遊戲類型專用開發包”，它與標準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機制）。
附帶一提，原本SRPG包附帶了第三方的Lua包作爲腳本使用，但後來考慮到一是Lua包較大，一是使用上還是太繁瑣，所以暫時取消了該設置，小弟準備直接重構Command類完善自帶腳本機制。不過，僅憑目前自帶的Command腳本做個R劇之類倒也沒什麼問題，況且也允許用戶自行擴展。
下載地址（內含示例工程、源碼及jar）：http://loon-simple.googlecode.com/files/LGame-0.3.7z
————————————————————
前一陣小弟家有點“雜事”，所以一直沒時間寫文檔（本來想上個月寫，結果失敗），暫時先把0.3版發佈出來，文檔慢慢補好了（剛纔又看了一下代碼量，對文檔開始絕望了……），鬱悶，鬱悶，鬱悶中。