【簡報】《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 + 優化團隊及開發團隊的所有人,謝謝。

廣告內容