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管理器、角色管理器等。搞成邏輯則是直接處理網絡消息，玩法相關的邏輯，比如工會系統、主界面邏輯等。
　　恩，目前也正在考慮中。