グリーにおけるスマホアプリ開発～HTML5編

グリーにおけるスマホアプリ開発
〜～HTML5編

15-C-2
#devsumiC 反田光洋

Copyright © GREE, Inc. All Rights Reserved.

⾃自⼰己紹介

•  開発本部 Japan Studio第5統括部
•  2011年年1⽉月⼊入社
•  携帯ブラウザ開発の会社からGREEへ
•  釣り★スタ → 聖戦ケルベロス → 現プロジェクト
•  Twitter: @mtanda


アジェンダ

•  開発スタイルの変化
•  チーム構成の変化とその課題
•  フロントエンド実装
•  サウンド組み込み
•  LWFを使った開発事例例
•  機能紹介
•  組み込み例例
•  注意した点など
•  その他の取り組み
•  バックエンド
•  フロントエンド
•  アプリ


開発スタイルの変化
どんなゲーム？

•  ネイティブゲームみたいなUI
•  リッチな演出
•  BGM/SEによる⾳音声演出


チーム構成

•  ディレクター
•  企画⽴立立案、画⾯面遷移図を作成
•  UIデザイン
•  企画、画⾯面遷移図をベースにワイヤフレームを作成
•  演出
•  企画をベースに演出画⾯面をHTML5などで作成
•  サウンド
•  演出画⾯面などに合わせてBGM/SEを作成、組み込み
•  フロントエンド
•  ワイヤフレームから対応する画⾯面をマークアップ
•  バックエンド
•  バックエンドの実装、マークアップされた画⾯面/演出を組み込み


開発環境

フロントエンド
バックエンド
•  LWF
•  Underscore.js
•  その他いろいろ
•  PHP 5.3
•  Ethna 2.6
•  Smarty 3
アプリ

•  GREE SDK


既存プロダクトの開発スタイル

メリット: 仕様のぶれが少ない
デメリット: 負荷が集中
企画

デザイン演出

兼務
もしくは数名

フロントバック
アプリ
エンドエンド


開発の⼤大規模化

•  よりリッチなUIの実現
•  バックエンドエンジニアが兼務するのは難しい
•  フロントエンドの専⾨門チームとの分業体制
•  演出、サウンド、アプリなどの連携
•  サウンドは専⾨門チームでなければ対応不不可
•  演出やアプリなど、多数のチームが関わることに


新プロダクトの開発スタイル

メリット: 負荷が分散、専⾨門化
デメリット: 仕様のぶれ、⼿手戻り発⽣生
企画

デザイン演出サウンド

分担して
対応

アプリ
エンドエンド


⼤大規模化によって発⽣生する課題

•  チーム/メンバー間のコミュニケーションコスト増加
•  タスクが依存することにより開発効率率率が低下
•  仕様/インターフェースの不不整合による不不具合発⽣生
•  仕様/実装変更更による影響範囲⼤大、⼿手戻りの発⽣生


課題解決のために

•  タスク間の依存度度を下げる
•  モジュール間の結合度度も下げる
•  仕様の不不整合を早く解消する
•  各チームで課題解決できる体制作り


フロントエンド実装の課題

•  テンプレート化を考慮しない実装
•  CSS/JavaScriptにハードコーディングされたパラメーター
•  例例: ステージごとに切切り替わる背景画像
•  テンプレート化作業のブロッキング、⼿手戻り
•  HTMLが完成するまで、テンプレート化できない
•  デザインの変更更=>HTMLの変更更で、再度度埋め込みが必要
•  テンプレートタグの組み込み漏漏れ
•  マークアップの意図を理理解しないと、置き換えが必要か気づけない
•  例例1: HPゲージを表⽰示する箇所でstyle=“width: 80%”
•  例例2: カード属性に応じてclass=“rare”

デザイン
エンドエンド


マークアップ時のガイドライン策定

•  テンプレートによる置き換えを想定して実装する
•  パラメーターで置き換わる画像はCSSで指定しない
•  JavaScriptで参照するパラメーターはHTML側にdata属性で埋め込み


テンプレートの共有化①

•  Smarty互換のJavaScript テンプレートエンジン「jSmart」を導⼊入
•  http://code.google.com/p/jsmart/
•  HTMLではなくテンプレートを直接マークアップ
•  クライアント/サーバ間でテンプレートを共有化
•  フロントエンド開発時は、モックデータを使って動作確認

<script type="text/javascript" src="smart.js"></script>
<script type="text/javascript">
var tAppData = {
'app': {
’foo': ‘bar’
}
};
</script>
<script type="text/x-jsmart-tmpl">
<p>{$app.foo}</p>
</script>


テンプレートの共有化②

Client Server

dummy View
JSON data PHP

template
jSmart Smarty

HTML


フロントエンド実装の改善

•  バックエンドの開発が並⾏行行に進められるようになった
•  デザイン変更更などフロントエンド実装の変更更に影響されなくなった
•  再度度テンプレート化といった⼿手戻りがなくなった
•  結合部のインターフェースが明確になった
•  バックエンド側で⽤用意すべきデータが明確になった
•  テンプレートタグの組み込み漏漏れがなくなった
•  テンプレート化することで、より効率率率的に実装できるようになった
•  共通部はincludeで対応
•  画像URLはSmartyプラグインで⽣生成

デザイン
エンドエンド


サウンド組み込みの課題

•  前提
•  <audio>タグにより同時再⽣生可能な⾳音源数に制限がある
•  複数のSEを組み合わせて再⽣生できない
•  BGMとSEを同時に再⽣生することができない
•  アプリ側で実装することで回避
•  アプリ側のサウンド再⽣生機能をWebViewから呼び出す
•  ⾳音声ファイルは、アプリ組み込み
•  課題
•  アプリがないとサウンドの検証ができない

アプリサウンド演出


互換インターフェースの提供

•  ⾳音声再⽣生のラッパーAPIを提供
•  <audio>タグにアプリ側API固有のパラメーターをdata属性として設定
•  <audio data-src=“foo.mp3” data-type=“BGM” …>
•  アプリでもPCブラウザでも⾳音声再⽣生をサポート


サウンド組み込みの改善

•  アプリなしでサウンドの調整が可能に
•  ⾳音の差し替え、ボリューム調整がすぐにできる
•  演出チームとサウンドチーム間で制作が可能に
•  アプリ実装担当の負担減
•  密にコミュニケーションをとることで、細かい調整が可能に

演出サウンドアプリ


LWFを使った開発事例例
LWFの機能紹介①

•  GREE内製アニメーションエンジン
•  SWFをHTML5のCSS/Canvasアニメーションに変換し、再⽣生する
•  (Lightweight SWFの略略)
•  OSSで公開されています
•  詳細は、こちら
•  https://github.com/gree/lwf
•  http://gree.github.com/lwf/


LWFの機能紹介②

•  ゲームの演出作成に必要な機能がそろっている
•  演出に必要なパラメーターを渡すインターフェース
•  カード画像など、ユーザー状態に合わせた画像の置き換え
•  端末解像度度に応じた画像の切切り替え
•  ボタンイベントを処理理する仕組み
•  fscommandにより、独⾃自イベントの定義
•  などなど


LWFの機能紹介③

•  端末に応じて適切切な描画⽅方法を選択できる
•  Canvas/CSS
•  例例: Android 4.xの⾼高解像度度端末で、Canvasを使うと2FPS！？
•  描画部分がボトルネック
•  パフォーマンスは、解像度度に反⽐比例例
•  CSSに切切り替えることで、パフォーマンスが改善


レンダラ選択の基準


LWFの機能紹介④

•  テクスチャシート対応
•  画像は外部リソースとして別途ダウンロード
•  キャッシュを有効に使うことで、転送量量/待ち時間が減る
•  ⾼高解像度度の画像を⼤大量量に使⽤用する場合に、特に重要
•  LWFのBase64エンコードで、Same-origin policyを回避
•  Webサーバと別のサーバからの配信が可能


全体の流流れ

privateData
演出パラメーター
(プレイヤーのHP
などの数値)

Event handler
各種イベント発⽣生時
のcallback
(演出終了了時の
ページ遷移など)

imageMap
演出内での画像置換
(カードやアイテム
画像など)


パラメーターの渡し⽅方

cache.loadLWF({
lwf: “foo.lwf”, // 再⽣生するLWF
stage: stage, // 描画先となるdiv/canvas
onload: onloadFunction, // LWF読み込み完了了時に呼び出される再⽣生処理理
privateData: privateData, // 演出パラメーター
prefix: “”, // LWF読み込み先のprefix
imageMap: imageMap, // 画像の置き換えマップ
imagePrefix: “”, // 画像読み込み先のprefix
imageSuffix: “@2x”, // 画像ファイル名のsuffix
});


パラメーターによる置き換え

privateData
{
“p1”: {
“AT”: 17638
},
“p2”: {
“AT”: 9710
} imageMap
}
{
“p1_1.jpg”:
“/img/card/8.jpg”
“p1_2.jpg”:
event handler “/img/card/7.jpg”
lwf.setButtonEventHandler(”ok”, }
{
press: function(button) {
document.location.href = …
}
});


新プロダクトでの組み込み例例

•  再⽣生処理理、エラー処理理を共通化
•  ページ読み込み時に⾃自動で再⽣生
•  HTMLのdata属性でパラメーターを設定
•  (smartyプラグインでより簡単に設定できるように)
•  SE再⽣生は、fscommandのイベントハンドラ内で処理理

<div class=‘lwf’ data-lwf-name=‘foo.lwf’
data-lwf-private_data=‘{ “p1”: { “AT”: 17638, …}}’
data-lwf-image_map=‘{ “p1_1.jpg”: “/img/card/8.jpg”, …}}’
…>
</div>


LWFSについて

•  LWFSとは
•  LWFへの変換/再⽣生を⾏行行うアプリ
•  http://labs.gree.jp/blog/2012/11/6422/
•  複雑なセットアップをせずに、LWFが制作できるようになる
•  エンジニアのサポートが不不要
•  演出の確認、改善というイテレーションを回しやすい


LWFSを導⼊入した制作フロー

実環境
モックの
private
private
Data
Data
など
演出の確認や改善

SWF LWF
LWFS サーバ

サウンド実データで
組み込み


注意した点

•  画像の読み込みに⼀一つでも失敗すると、LWFは再⽣生されない
•  適切切にエラー処理理をして、エラーページなどに遷移させる必要がある
•  演出パラメーターは、オブジェクトとして渡される
•  サーバで演出パラメーターを出⼒力力する際に、余分なパラメーターを含めない
•  サーバ側でのみ使⽤用するマスターデータなどの流流出を防ぐ
•  LWFのバージョンに気をつける
•  再⽣生確認に使⽤用するLWFSのLWFとバージョンが合っていることを確認する
•  制作時には、単独で動くようにする
•  ページ遷移などの処理理をLWF内に直接埋め込まない


その他の取り組み
バックエンドのユニットテスト

•  バックエンドモジュールを機能ごとにパッケージ化
•  User、Point、Item、…
•  フロントエンド側実装と並⾏行行して実装
•  Jenkinsでユニットテストを定期的に実⾏行行
•  機能追加などでのデグレ防⽌止


JavaScript/CSSのビルド環境

•  GruntJSを導⼊入
•  http://gruntjs.com/
•  ビルド作業を定型化
•  開発⽤用、リリース⽤用などのタスクを定義
•  デバッグ⽤用のJavaScriptを開発⽤用に組み込み
•  グローバルオブジェクトが⽣生成されないか定期チェック
•  console.logの出⼒力力内容をログサーバにも送信
•  https://github.com/imaya/birdwatcher.js/


クライアント側のエラー検知

•  JavaScriptのエラーは、サーバ側では検知できない
•  エラーにより操作不不可となっている状況がありうる
•  適切切なエラーハンドリングをすると共に、原因箇所の情報をサーバに
通知

window.onerror = function (message, file, line) {
try {
var report = JSON.stringify({
'message': message,
'file': file,
'line': line
});
new Image().src = '/?action=report_error&src=' + uri + '&report=' + report;
} catch (e) {
// do nothing
}
};


アプリ内キャッシュ

•  過去のプロダクトに⽐比べ、リソースサイズが増加
•  カード画像は⼤大きいもので、100KB超
•  画像は数100MBのオーダー
•  アプリ内に画像などのリソースをキャッシュ
•  同じリソースの繰り返しロードをさける
•  キャッシュ容量量の上限を設ける
•  使わないものからLRUで削除
•  事前にロードすることで、読み込み時間短縮が可能に


まとめ

•  開発スタイルの変化
•  依存をなくすことで、各チームがイテレーションを回せるようにする
•  仕様の不不整合がないように、早い段階で調整を
•  LWFを使った開発事例例
•  LWFにより、効率率率的にゲーム内演出が作成できる
•  LWFSを使うことで、より効率率率的に演出の改善が可能に
•  その他の取り組み
•  エラー検知、キャッシュが重要
•  JenkinsやGruntJSなどで、より効率率率的に開発を


グリーにおけるスマホアプリ開発～HTML5編

More Related Content

グリーにおけるスマホアプリ開発～HTML5編