Flex 和 Ogre

最近和賴爺聊了聊，於是決定看看網頁遊戲方面的資料。在賴爺的強烈推薦下，開始了我的Flash之旅。不過這其中的過程倒不是太順利。因為我向來沒有接觸過網頁遊戲的開發領域，一開始僅僅會安裝apache，放一個index頁面上去，寫一個“Hello World！”的頁面。這已經讓我狂喜不已。實際上這實在是有點可悲的，雖然早有研究一下的興趣，可惜卻只停留在高中階段的認識。

 

記得那時會用FrontPage編輯靜態網頁，並和同學一起放到了免費的個人空間上面（好像是163的）。我已經不記得檔案具體是如何上傳的了，可能那段操作也是參考著資料而卻完全不瞭解具體的含義。那個時候的天空總是很藍，人也如此單純……跑題了。

 

聽了賴爺的“忽悠”，於是便答應他去幫他做一些介面封裝上的事情。雖然我對此一無所知，但是我相信這是正確的事情。

 

Flex

 

我實在沒有能力解釋清楚Flex、Flash、AS之間的關係，因為我學東西一直都是先瞭解我最關心的內容開始的。不過一開始走了一些彎路，如果能夠早些聽賴爺的勸告或許能更快一些找到方向。最後我還是找了一本關於Flex3的電子書來看：《ActionScript3 CookBook 中文版》。憑著直覺很快就瞭解到想要瞭解的東西：一、如何顯示一張圖片；二、如何建立網路連接。

 

顯示一張圖片是所有圖形庫的最基礎的功能，任何2D遊戲引擎最基礎的問題就是如何把圖片顯示出來（我說的圖片一般都是Bitmap的位元影像檔案，而不是指Flash中的向量圖形）。Flex提供的方式是使用一個Sprite類來讓使用者控制。使用者可以任意設定Sprite的圖片、位置等視覺上的屬性，同時也可以繼承Sprite類，來給它加入遊戲的邏輯：比如跑、跳。

 

關於建立網路連接，倒是讓我感歎了一下。非常簡潔的代碼：socket.connect(ip, port)，絲毫沒有拖泥帶水的感覺，就如同我寫了非常久的C++代碼之後，第一眼看到Python的“class ClassName(): def func(): print 'Hello World!'”的那時候的震撼感覺。但是，Python的很多模組都保留了C++時候的介面設計，特別是一些有曆史淵源的擴充模組，可能為了移植方便或者保持習慣等方面的原因。比如Python的預設的socket的介面和C++幾乎一樣。

 

我認為指令碼語言的趨勢應該是讓使用者寫最少的代碼、隱藏更多的細節，同時充分的考慮到了擴充性。這樣對於一個剛剛入門的人來說，可以盡量降低他們的門檻，並且能更好的實現項目的快速原型開發。就好比C#，一切都是託管的。

 

目前我暫時還沒有去實踐Flex，但我覺得Flex是個不錯的適合快速開發的語言，最好能不局限於Web開發。

 

關於網頁遊戲市場

 

早一兩年前非常流行策略類遊戲，而題材大多集中在武俠、三國上面。特別是在熱血三國成功後，一夜之間出來無數的三國web遊戲，然後大家一起死翹翹……呵呵，實際上他們其中一些比較有特色的產品，活的還是挺滋潤的。這類策略類的遊戲有個天生的弊病：老的伺服器在遊戲的分化的過程中會導致其中某一群玩家（可能是一個公會或者聯盟）的勢力變的無比強大，壓制了其他玩家群體的發展，然後導致玩家的流失。而在這一群玩家稱霸了伺服器之後，因為沒有了“綠葉”所以也開始流失。

 

還有一類比較受歡迎的類型，這類比較類似互連網發展初期的MUD。這是一種含有比較多的RPG遊戲元素的玩法，也是符合長期發展的一個模式。玩家可以像RPG一樣練功升級、體驗遊戲世界觀、養成遊戲角色。而且它又不需要像RPG那樣一直操作，僅需要點滑鼠。比較適合沒有太多精力去練級，又喜歡體驗和探索的玩家。

 

最近炒的比較火熱的是SNS平台的應用開發。一般都是由互連網SNS網站提供使用者資料介面，開發人員個人或者小團隊開發Flash遊戲整合入SNS平台。國內比較火熱的有人人網、校內網（也屬於人人網）、開心網（開心001，不是人人網的開心網）、51社區，QQ社區也屬於這類SNS，但是目前不提供開放平台。目前成功的案例就是開心農場，在多個平台上都有模仿並半成功的作品。這也是我比較看好的一個方向。

 

Ogre

 

我在讀大學的時候就已經聽說過這個開源引擎，不過當時並沒有仔細研究。工作後，慢慢通過學習和實踐有了自己的一些想法，瞭解了3D引擎的一些設計思想，並且自己做了一些嘗試。可惜那個時候沒有更多的瞭解Ogre，直到真正去瞭解的時候才發現原來Ogre的很多設計理念和我的想法不謀而合。（雖然我並不是很喜歡完全的OO風格代碼，因為完全C++的OO風格讓人覺得比較繁瑣並且不易修改）

 

關於Ogre，請訪問http://www.ogre3d.cn擷取中文資料。網上的教程也很多，不過比較詳細的是一份《PRO OGRE 3D PROGRAMMING》的中文版資料。裡面講述了Ogre引擎的許多方面，也有教程和範例程式碼。如果你想要真正用來開發項目，那還需要一份Ogre API手冊，這個在官方網站上可以下載的到。我現在用的是Python-Ogre，用指令碼來寫Ogre程式，感覺網上有足夠的教程，擷取起來也非常方便。（有機會我會專門介紹下這個環境的搭建）

 

Ogre有一個設計思想是：總是同時提供了“自動擋”和“手動擋”供使用者選擇。所謂的“自動擋”指的是，當你不像去涉及到具體的編碼細節的時候，你可以用一些Ogre預設的方式。比如Ogre提供了預設的顯示配置對話方塊，當你的程式啟動並執行時候，可以通過一個函數開啟這個對話方塊，它會自動的記錄配置到一個cfg檔案，並且設定好硬體和視窗的初始狀態。而如果你希望用手動擋的時候，你也可以通過介面來設定設定檔中的一些屬性之後再啟動硬體和視窗的初始化。這種同時具備多層次介面的方式，提高了原型開發的速度，也提高了新手學習的難度。

 

Ogre的材質系統讓我印象非常深刻，它實現了一套類似DirectX的effect的機制，甚至功能更強！它提供了一種比較清爽乾淨的模式（不是衛生巾）：模型不用同時附帶貼圖資訊和渲染方式資訊，而只需要帶材質資訊；材質可以由專門的材質編輯器去編輯和管理，（可惜Ogre並未提供材質編輯器）。這點非常類似於現代的遊戲機遊戲上的方式：情境中有大量的材質，所有材質由材質編輯器編輯和管理，並提供給模型編輯器和情境編輯器去使用。而放到團隊工作中則更具好處，大部分程式員不用太關心貼圖和effect檔案的管理細節，這些事情都交給了美術人員和專門編寫著色器程式的一個程式員用材質編輯器搞定了。

 

MMO用戶端構架

 

 

一開始我很糾結於遊戲的整體架構，之前在公司的內部交流中有人介紹了一種叫做MVC的開源架構。這種模式提出把程式主模組拆分為“資料-邏輯-介面”，我本來希望這個架構能夠應用在遊戲的開發中，但是在經過和主講人的討論之後，我放棄了這個想法。原因是遊戲情境模組和遊戲介面模組有很大的不同，對於某些遊戲邏輯來說，可能會和遊戲情境模組非常頻繁的互動，導致這兩部分的模組相關性太大，以至於不適合做拆分。而MVC模式適合應用於一般應用軟體的其中一個重要的原因是介面和邏輯模組相關度並不大，甚至大部分的情況下，和資料模組的相關性也不大，所有的重新整理介面的操作都可以用有限的幾個或者幾十個訊息定義出來。不過，我並沒有說過不適合用在遊戲介面上。在之後的交流中主講人也比較同意我的這個說法。

 

於是我在考慮：

 

1 遊戲情境模組是否應該屬於一個給上層邏輯提供圖形支援的模組，而並非是核心模組之一，雖然代碼量可能很大。

2 遊戲的核心互動模組為“遊戲高層邏輯-遊戲資料庫-介面”，而把他們結合在一起的則是MVC模式。

3 遊戲邏輯可以分成底層邏輯和高層邏輯，底層邏輯是各種管理器，比如NPC管理器、角色管理器等。搞成邏輯則是直接處理網路訊息，玩法相關的邏輯，比如工會系統、主介面邏輯等。

 

恩，目前也正在考慮中。