LGame-0 3 Android與JavaSE遊戲引擎正式釋出，新增SRPG製作模組

阿新 • • 發佈：2018-11-12

分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

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機制）。