【簡報】《Final Fantasy Record Keeper》開發實務暨產品架構經驗分享


吹著魔笛的浮士德不專業翻譯
擔任《Final Fantasy Record Keeper(FFRK)》主要研發人員的新井英資先生,於「第二屆 DeNA 遊戲開發交流會」中分享了該團隊的開發經驗。

新井先生的簡報分為三個部份,分別是《FFRK》的遊戲開發方法,遊戲的整體架構,以及各種技術性問題的解決方法。

他也大方分享了遊戲初期所發生的各種問題(效能極差,極度耗電),並說明他們是如何在一個月內徹底改造架構,優化效能的。

我本身不是程式人員,所以對於簡報內的專有名詞有如鴨子聽雷,邊讀邊撥電話請公司的研發同事告訴我哪些詞是什麼意思,最後決定全部照英文(外來語)打出來。
吹著魔笛的浮士德不專業翻譯
教學以相長,歡迎各位嚴厲的指正內文,同時也讓我有學習的機會。

簡報原始檔連結:
http://www.slideshare.net/dena_study/20141111-seminar-eisuke/21



Page 1 - 《Final Fantasy Record Keeper》的開發方法


吹著魔笛的浮士德不專業翻譯


譯:DeNA 新井英資分享
吹著

魔笛的浮士德不專業翻譯
Page 2 - 自我介紹



◎自我介紹。新井英資,FFRK 團隊的 Lead Engineer,2011 年入社(第四年)。
◎以前在打工的時候曾開發過 iOS APP,負責 Infra 與 Middleware 及團隊對外的溝通與協調
◎化不可能為可能。
吹著魔笛

的浮士德不專業翻譯
Page 3 - 今天要談的事



◎FFRK 的開發經驗分享
◎FFRK 的架構
◎FFRK 應用相關經驗

著魔笛的浮士德不專業翻譯
Page 4 - FFRK 的開發經驗分享




Page 5 - 關於 FFRK
吹著魔笛的
浮士德不專業翻譯
吹著魔笛的浮士德不專業翻譯
◎ iOS/Android 版本於 2014 年 9 月 25 日推出
◎ 與 SEX 社共同開發的作品
◎ 以點陣圖的方式重現 FF 全系列作品的戰鬥
◎ 既懷舊又嶄新的 Final Fantasy
◎ 由 DeNA 負責系統開發
◎ 感謝玩家支持,反應十分的好


Page 6 - 影片展示(應該是在會場上撥放)


吹著魔笛的浮士德不專
業翻譯

Page 7 - 開發之初的要件



◎ 想開發 Application(可以放豐富的動畫)
◎ 想控制內容的更新(釋出不用更新版本的事件)
◎ 想利用既有的資源如 Kickmotor(D.O.T、三國志 Royale)以及網頁遊戲的內製 Framework
吹著魔笛的浮士德不專業翻譯

Page 8 - Hybrid Applicaion



◎ WebView Layer 與 OpenGL Layer 兩層架構(表現方面透過 OpenGL 來做)
◎ WebViewBridge(WebView 由 JS 執行 Native 的函數)
吹著魔笛

的浮士德不專業翻譯
Page 9 - 這邊是 WebView



Page 10 - 這邊是 OpenGL吹著魔笛的
浮士德不專業翻譯


Page 11 - 實裝 WebView 的 JS吹著魔笛
的浮士德不專業翻譯


◎ 導入 MVC Framework(也將 Front 構造化實裝)
◎ Backbone.js + RequireJS(考慮到利用實績)
◎ Underscore template( 將 JST Compile 後使用)



Page 12 - 戰鬥系統實裝



◎ 重現 FF 的 ATB  戰鬥系統(待機、詠唱、攻擊等狀態的控制)
◎ 利用 JS 實裝 State Machine(Native 動畫描繪與戰鬥邏輯分離)
◎ 動畫部份是 Deferred Chain(Native 的描繪 Callback)
◎ 製作頭目的 State Map(控制豐富的頭目行為)


Page 13 - FFRK 做好了!準備上架了!

Page 14 - 上架前一個月發生了這些事



◎ CB 測試的結果是 Loading 太重,而且太燙了
◎ 戰鬥畫面只有 10 FPS
◎ 物品欄無法捲動
◎ 電力耗損的速度比充電還快


Page 15 - (死)



Page 16 - 優化祭典 WebView 篇



◎ 透過 Chrome Profiling(徹底清除多餘的處理並從 Layout 架構開始重作)
◎ 與 Naitve 同等 Level


Page 17 - 從這樣變成...



Page 18 - 變成這樣



Page 19 - 從這樣變成




Page 20 - 變這樣



Page 21 - 優化祭典之 Native 篇


◎ 檢查所有用到 OpenGL 的外部呼叫功能
◎ 減少無用的外部功能(頂點數 0 的描繪與無用的廣域描繪領域)
◎ 統整參照相同 Texture 的描繪
◎ Android 2.X 版本也能跑足 30 FPS(Draw Call 削減至 4 分之 1)


Page 22 - 如此一來從這樣...



Page 23 - 變成這樣
吹著魔
笛的浮士德不專業翻譯


Page 24 - Hybrid 的優點


◎ 可以實現事件驅動(不會受到客戶端申請期間的影響,變更 JS 便可以做出完全不同的遊戲)
◎ 利用 Chrome 或 Safari 就可以除錯


Page 25 - 儘管如此



◎ 難以做出動作性高的要素
◎ WebViewBridge 的延遲
◎ HTML Template 會在讀取途中終止
◎ 悄悄地放在「重新讀取」鍵
◎ 依作業系統版本的不同而會有差異(主要是 Android)


Page 26 - FFRK 的架構



Page 27 - 長這樣


由左至右,由上至下:OpenGL / WebView / html, json / Game Server / WebView . NativeBridge / Native Cache / js, css, AnimeData / Database


Page 28 - Client 架構


由上而下,由左而右:Game / WebView / Native Cache / WebView . NativeBridge / Native Animation / cocos2d-x / 其他 SDK / iOS / Android
吹著魔

笛的浮士德不專業翻譯
Page 29 - Native Animation


◎ Animation Player - 內製工具作成動畫檔後利用 Cocos2d-x 撥放
◎ 細微的動畫控制 / 資料控制 / Master 控制 / JS 控制


Page 30 - 圖解 Native Cache


◎只向伺服器要缺少的 Asset



Page 31 - Native Cache




◎ WebView & Native 的 Access(Sunny Lee & 虞敬業指正)

◎ 使用 Mongoose 建立 APP 內部 Proxy Server
◎ 沒有 Cache 的話再從 Server 撈
◎ 放進 Cache 的東西什麼都有什麼都不奇怪
◎ CSS 的處理上多了些手續(保存時將圖片的 URL 重新指向 Cache Server)


Page 32 - FFRK 的其他情報分享



Page 33 - 高負載的對策



◎ 上架後馬上投入電視廣告宣傳(用戶急速增加,當時已有 300 萬人, Web 伺服器陷入混亂)
◎ 迅速展開負載應對(Shard DB 追加 / Web 伺服器依次投入)
◎ 終於不再當機


Page 34 - Master 管理



◎ 透過 Google Spreadsheer 統一管理
◎ Google Apps Script(Master 值的 Mapping / 輸出 CSV)
◎ Master 生成 Flow(開發環境 Load / Master 的測試 / github:E 經由 Jenkins Pull-Request)


Page 35 - ChatOps
吹著魔笛的浮士
德不專業翻譯


◎ IRC + Jenkins +Hubot(Jenkins 失敗時全員暴怒)
◎ Hubot 的管理(Jenkins 的 Build 狀況 / 驗證環境的狀態 / 其他多餘的功能)


Page 36 - 總結

吹著魔笛的浮士德不專業翻譯
◎ FFRK 是 Hybrid Applicaion(WebView 與 Native 兩種 Layer 的最佳化)
◎ FFRK 的特徵結構(動畫撥放器 / Native Cache)
◎ FFRK 無止盡的改善之路(高負載對應 / Master 管理 / ChatOps)


Page 37 - 致謝語


吹著魔笛的浮士德不專業翻譯
◎感謝 Infra Team + Middleware Team + 優化團隊及開發團隊的所有人,謝謝。

0 意見:

 
吹著魔笛的浮士德 © 2010 | Designed by Trucks, in collaboration with MW3, Broadway Tickets, and Distubed Tour