開發過程中5件對的事情
1、選擇Flash11作為解決方案
主要因為Stage3D使開發web平臺上基於硬體渲染的3D遊戲成為可能。在2011年專案調研期，我們還在猶豫開發2D遊戲還是3D遊戲，雖然2D頁遊技術門檻低，風險小，但由於我們初涉頁遊領域，經驗不足，在成熟的2D市場上難有競爭力，玩法也很難創新。相反3D雖然技術難度大，風險高，但是一種技術創新，熟悉傳統3D開發的我們也有明顯優勢，而且我個人從技術人員角度更想開發3D遊戲，在無外掛3D頁遊方向，我甚至還為此研究過webGL，不過那時也還剛起步，現在都還沒成熟（html5)。適逢stage3D第一版本molehill在那時推出，得知此訊息後我們立即開始調研， 經過初步分析，有較大風險，但我們主要看中flash的普及率和瀏覽器整合 以及adobe公司的技術實力，最終還是選擇用flash11來開發頁遊，選用一個還在孵化階段的技術用於正式商業專案，在當時的確是一個很大膽的做法。不過隨著專案基本成型後，並且Adobe有條不紊的跟進和更新最後release，這個風險也基本消除了，驗證了我們當初技術選型的正確性，主要抓住了“無外掛3D頁遊“這一先機。
2、 中期拋棄效率不甚理想的Away3D引擎，重寫渲染核心，大幅優化效率
初期調研期間，為了快速開發原型已驗證可行性，我選用了開源的Away3D作為渲染模組，包含在我們自己新命名的引擎DelatX當中。開源引擎是當時的最優選擇，因為flash3D都是大家都是剛剛起跑，都是在嘗試，問題也很多，能跟蹤原始碼自己修改問題比使用一個不穩定的黑箱要安心很多。當時只推出了alpha版，bug很多，後來因為改動較大，我們也不再合併away3d更新。本來打算在它基礎上繼續開發，越來越發現效率實在跟不上，主要是渲染部分，很多基礎演算法就不是優化演算法（比如骨骼動畫、材質系統、shader整合），它想做大而全的圖形開發包，但架構偏複雜，中間層過多，相對於我們端遊的引擎的架構過於笨重過於緩慢。於是我們幾乎拋棄了所有away3d的程式碼，只保留了一些純粹的輔助包，基於簡潔、高效的原則將整個渲染模組重寫，摒棄不需要的，只留需要的程式碼，最後效能有大幅度提升。整塊優化和重構工作（包括下面提到的另外3件正確的事情）主要是由我們的CTO柯達招操刀，我協助完成。
3、 採用Stage3D實現介面系統
專案初期，介面系統我是直接採用當時開源的aswing介面庫，然後做一定擴充套件以相容我們的介面系統（從端遊移植而來）。初衷是想減少開發成本，但aswing也是相當龐大和複雜的，這個相容過程也耗費了相當大的人力。後來由於目前stage3D的內容不能繪製在2D的flash元件之上，導致有些需求基於2D的介面無法實現，比如需要在介面上繪製3D模型和特效，後來考慮再三，決定除了主畫面，介面也用stage3D來實現繪製，和3D的繪製統一起來，在專案中後期實施這個改動也是一大手術，整個過程持續接近一個月，但結果證明是正確的，不僅實現了需求，由於繪製轉移到了GPU，CPU大幅下降，並且記憶體也降低了不少。
4、使用自定義ds格式shader直譯器，提高shader開發效率
這個其實也屬於渲染引擎重構和優化的一部分。因為我們發現書寫AGAL的shader效率很低，除錯也困難，而當時嘗試過的pixelBender3D也有很多bug，幾乎不能使用。彙編的書寫主要麻煩在與暫存器的分配，比如mov vt0,v1; mov vt1, v2; 假如去掉了v1屬性，那麼需要修改所有v2為v1，臨時暫存器的修改更是會影響到整段shader程式碼的調整。能否讓我們不關心那些暫存器編號，只關注我們需要的變數和操作呢？比如mov temp, pos; mov anotherTemp, color; 基於這個原則，我們開發了一個輕量的直譯器，輸入剛才那段有具名變數的偽shader，指令集完全沿用AGAL，輸出的則是原生的AGAL程式碼，暫存器全部由直譯器分配好，無需人工干預。這大大簡化了shader的開發，寫shader不比高階語言麻煩多少，而且直接面對底層指令，反而更容易發現問題，對於複雜的計算，只要旁邊附上高階語言的註釋就可以了。目前這個直譯器已支援基本替換變數、語義繫結以及函式（巨集），以後還想新增的特性比如檔案的include、暫存器按分量更精確分配等。
5、特效系統核心移植到GPU用shader實現
ActionScript3雖然在指令碼語言中效率不算低，但終究還是指令碼語言，效能難以和C/C++匹敵，尤其是CPU密集型計算更是差別巨大，導致原本我們在端遊的特效系統移植到flash後有很大的效能瓶頸，所以做了很多製作上的限制。在專案後期，外界測試反饋的效率問題比較嚴重的情況下，我們不得不進行特效系統的優化，主要方案是把效能瓶頸的特效更新程式碼移植到GPU用shader去實現，as端只傳輸基本的資料和引數，不做多餘的計算。這部分優化也讓特效的限制基本解除，效率和效果都有顯著提升。
開發過程中的5個問題
1、效能需要進一步優化
雖然我們一直強調效能，並且勝於畫面（首先要讓玩家能玩），也投入了很多時間在優化上，但似乎已經到了一個瓶頸，受限於flash虛擬機器本身，所以還沒有完全達到預期的結果。另外我們有一個比較隱晦的記憶體洩露也還在排查當中，目前並沒有發現太好的記憶體分析的工具，包括能分析flash內部物件如BitmapData、String等物件記憶體。Monocle是一個很好的效能分析工具，據說新版本會新增記憶體分析功能，值得一試。
2、邏輯程式碼的質量稽核需要加強
《封神無雙》在畫面上做出了一定水準，效率也不錯，但這只是遊戲的基礎，遊戲的主體功能目前還存在不少bug，影響到使用者體驗，也會導致玩家流失。我們團隊規模較小，很多流程也不太正規，開發節奏比較快，導致程式碼質量的把關上出現了脫節，這也是日後需要重點改善的地方，我們需要的是更高質量的產品。
3、加強團隊內部的培訓
這其實和上一條有關聯，在新人培訓上我們還停留在傳幫帶和放在一邊自己啃的層次，很多東西包括專案的系統講解、常規開發事項等都應該在前期開始就貫徹執行，降低開發期間的重複工作，提高開發效率。
4、儘可能帶動解決flash11的相容性問題
flash11雖然帶來了技術的變革，把3D搬到了網頁，但變革的路都是曲折的。比如低端顯示卡相容性、舊驅動的相容性，右鍵開放後和瀏覽器自帶手勢的衝突問題，chrome瀏覽器安裝多個版本flash外掛的衝突，這個bug甚至會引起stage3D回退到軟體渲染，還有其他一些影響玩家進入的問題。畢竟我們是第一個吃螃蟹的，從使用者那裡得到了很多關於flash外掛的問題，也積極反饋給adobe以求解決，但這是一個漫長的過程，隨著這些問題的逐個解決，我們才能真正說flash3D頁遊普及到90%的PC端以上。
5、處理使用者反饋的速度
這方面我們還遠遠不夠，這需要在各方面下功夫，人力問題、個人解決問題能力提升、遊戲更新方式的優化等，比如做通過後臺入口做遊戲的線上修改，迅速地處理問題，這是玩家和運營商都喜聞樂見的。
技術與效率
選擇Adobe技術理由是跨平臺，開發效率高，容易學習。作為網頁遊戲的主打平臺flash的開發商，沒有理由不去選擇。
目前在使用Adobe的解決方案有：
i. Flash Player 11.4, Stage3D
ii. Flash Builder 4.5
iii. Monocle
如何實施Adobe解決方案
遊戲的實施和傳統網路遊戲開發沒有區別，策劃定好世界觀，做系統的設計，提出明確的需求交給美術和程式去實施。美術部分主要是用3dsmax、Photoshop/Coraldraw/painter等傳統藝術工具進行基本素材編輯，然後匯入自研的美術工具集加工處理成支援我們遊戲引擎的資源格式，最後由程式呼叫並呈現在遊戲當中。遊戲區別於其他頁遊主要還是在基於flash硬體加速的3D遊戲這一技術創新點上。
Adobe解決方案（AIR, Flash, Stage 3D等）本身的獨特優勢
Stage3D 高效能的跨平臺3D圖形API 極大的提升異於傳統頁遊的表現力，接近客戶端遊戲效果，藉助flash本身的高佔有率，這一優勢會讓其他跨平臺3D技術短期很難超越，flash平臺也被Unity、Unreal等遊戲引擎商看中，flash匯出也成一趨勢，因為潛在的使用者是非常可觀的。
Adobe解決方案帶來的專案收益
開發效率相對傳統端遊C++開發有大幅提升，主要體現在編譯時間的大幅降低，以及語言和平臺本身的易用性。Monocle的使用也大大減少查效率問題的時間，因為它能非常快並準確的定位到效率瓶頸之處。
分享該遊戲的製作經驗
由於初次接觸頁遊開發，遇到許多flash傳統開發的常見問題，也適逢flash11的各種變革，一方面我們要虛心向傳統flash開發人請教學習開發心得，一方面在要積極跟進adobe，及時反饋，及時採用新的方案和工具（比如monocle），減少彎路。
效能永遠優於畫面。頁遊使用者對畫面要求並不如端遊高，所以對畫面的追求要有個度，玩家的體驗主要還是看效能和流暢度。第一是下載效率和載入效率， 最快的讓玩家進入遊戲，資源量和資源大小的控制要達到極致才行，我們已經做過很多努力，貼圖的jpegXR壓縮，檔案的swf壓縮，並行的下載佇列等等。第二是遊戲執行效率，包括渲染效率和操作流暢度，因為CPU方面是瓶頸，GPU方面效能並不是優化重頭，提高as程式碼執行效率，降低CPU佔用是關鍵，藉助效能分析工具也能達到一定高度。
要明確區分頁遊和端遊的開發。要認清他們的本質區別，而不僅僅是把端遊或者主機遊戲移植到網頁端，除了減少下載外並無太多意義。頁遊注重休閒和零碎時間的利用，注重使用者體驗，並儘可能的降低使用者操作，所以如果你是要移植已有的端遊，在遊戲系統得做大量調整，UI/UE也要做很多優化。
團隊目前進行的工作以及未來的專案
目前我們著眼於效能的進一步提升，以及遊戲玩法的豐富和遊戲bug的修復。另外公司正著手進行基於ActionScript3和C++結合的遊戲微端開發，基於avm2開源虛擬機器和底層C++ DirectX圖形引擎，以充分利用ActionScript的高開發效率以及C++的執行效率。未來可能會嘗試移動平臺的遊戲研發。