KLab JS+CSS ワークショプ
- Flash LiteアニメをJS+CSSでスマフォ向けに -
KLab株式会社 開発制作本部 / 中澤 慧(@muo_jp)

自己紹介
なかざわ けい (中澤 慧 / twitter: @muo_jp)
所属: KLab株式会社 開発制作本部
Android好き
Google公式ドキュメントの日本語訳とかやってました
プログラミング言語はC#好き
興味範囲広め、結構プロトタイプ作ったりします
実は、専門は経営学です
blog: http://muo.jp/

セッションの流れ
Flash Liteファイルをスマフォ対応する手段の紹介(15分)
変換にあたって考えること・やること・気をつけるこ
と(15分)
休憩・質疑応答(5分)
実際に書いてみる(45分)
まとめ(5分)
質疑応答(5分)

大前提
フィーチャーフォン向けにFlash Liteで作られてきたものをリ
ライトする
30/60fpsを目指さない
諸々の実装バグが解消してきたらこのあたりを目指せる
ようになる
CPUをブン回してどうにかなる範囲(6/12fpsあたり)を目指す
元版を大幅に超えたリッチな表現を目指さない
ベクター画像にこだわり過ぎない

こんなのが出来ます(要時間)
ターン制ロボット格闘ゲーム
構成要素
体力ゲージ
画像のクリップ域に対する半透明
マスク
(赤みがかった処理)
導入部分のスライドイン、
スライドアウト
ビリビリエフェクト
全画面エフェクト

Flash Liteファイルを
スマフォ対応する手段の紹介

系統
JavaScriptで実装されたFlashLite(swf)エンジンで直接実行
したり、前処理した独自ファイルを自前のエンジンに
食わせて実行したりするもの
=> 変換実行系
JavaScript + CSS/canvasへの手動変換

自動変換系

自動変換系 / ExGame
Flash Lite 1.1をターゲットに据えたもの(2.0非対応)
多くのフィーチャーフォン向け演出Flashは1.1であった
ので、実際十分なケースが多い
元ブロードテイル社のプロダクト( http://dena.jp/press/
2011/06/dena-21.php )
mobageに提供されているゲームで結構使われている
中の人による紹介スライド( http://www.slideshare.net/
sousk/exgame )
mobage以外での利用は認められていない

自動変換系 / Shumway
MozillaによるOSS
割と期待株
社内で試してみた人曰く「結構ちゃんと動くので多少
手を入れれば良さそう」

自動変換系 / Google Swiffy
https://www.google.com/doubleclick/studio/swiffy/
日本語(MS932)の取り扱いに難がある
変換部分自体は非公開であるため、問題があっても手
を入れるのが非常に面倒

自動変換系 / FlashJS
http://accelart.jp/products/flashjs.html
株式会社アクセラートジャパンのプロダクト
未評価

自動変換系 / SWF
Decompiler(HTML5 Exporter)
http://www.sothink.com/
swfファイル解析、素材抜き出しを行うツールのオマケ
機能
ごっそりと構造をJSONにダンプして、それを自前のプ
レイヤーで再生する形
重すぎる上にシェイプが正しく描画されない箇所が多
く、完成度低い

手動変換

基本構造
画面表示の管理、ゲームロジック、アニメーション管
理は全てJavaScriptで行う
画面描画には主に2つの方法がある
CSSを利用する / canvasを利用する
描画要素管理 描画要素管理
タイミング管理 タイミング管理
データ処理 データ処理
ネットワーク 画面 ネットワーク 画面
通信 描画 通信 描画
JavaScript CSS JavaScript canvas

canvas vs CSS
CSS: 画面上に要素を配置し、キーフレーム指定等を行なってア
ニメーションさせる
canvas: 画面上にフリー描画エリアを作り、その上に任意の要素
を描画する(アニメーションは自前管理)
IE系ではCSSアニメーションのGPUアクセラレーションが推奨
されている
iOS5以降、canvasでの描画にGPUアクセラレーションが効くよ
うになっている
幅広い端末で30/60fps出すのは厳しい。が、12fpsならなんとか

CSSってこんなの出来るんでしょ?
出典: http://rei.idv.tw/sample/mio.html

ソース見てみなよ
CSS(抜粋)
skew(-39deg,-39deg); -o-transform: skew(-39deg,-39deg); -
webkit-transform: skew(-39deg,-39deg); border-radius:
15px 0 0 / 15px 0 0; width: 220px; height: 500px; left:
34px; top: 404px; -webkit-animation-name: hb1; -ms-
animation-name: hb1; -moz-animation-name: hb1; -o-
animation-name: hb1; }
div#hear_back div.hb2! { -ms-transform: rotate(-57deg); -
moz-transform: rotate(-57deg); -o-transform:
rotate(-57deg); -webkit-transform: rotate(-57deg); width:
200px; height: 65px; left: 50px; top: 392px; }
div#hear_back div.hb3! { width: 35px; height: 120px;
left: 137px; top: 245px; }
div#hear_back div.hb4! { -ms-transform: rotate(50deg); -
moz-transform: rotate(50deg); -o-transform:
rotate(50deg); -webkit-transform: rotate(50deg); width:
14px; height: 50px; left: 143px; top: 280px; }

CSSでのシェイプ描画の実際
作れるのは四角、円、楕円(枠指定によっては卵型のよう
な非対称の楕円も)
任意の多角形とか無い
じゃあどうやってるのか
borderで頑張る(凸だけでなく透明背景で凹も表現可能)
before、afterで頑張る(同じ場所に最大3つのシェイプを
重ねてひとくくりにすることが出来る)
ある種の芸。例: six-point-star ( http://css3shapes.com/ )

CSSでのシェイプ描画例
このへんとか見ればより分かりやすい
http://www.russellheimlich.com/blog/pure-css-shapes-
triangles-delicious-logo-and-hearts/
(軽くChrome開発ツールでデモ)
これは辛い

これは辛い。

Flashでよくあるシェイプ

やめてください死んでしまいます

ということで、こうする
ベクターのシェイプは、適宜ラスタライズして扱う
特定のシェイプへのマスク処理は、mask-imageを使う
Android 4.0以上(4.0, 4.1)の標準ブラウザで、mask-image
とtransformを併用するとマスクが効かないというまさか
のエンバグ(ChromeはOK)
→マスク利用部分については、
自前でアニメーション制御
参考: http://jsdo.it/mattari_panda/qePP

目指すバランス
コーディング量
=> JS比率かなり高め、CSS比率かなり低め
アニメーション定義
=> なるべくCSSのクラスとして事前定義
(前述のAndroidでの問題があるため、今のところ
マスクと組み合わせるなどの乱用は禁物)
実行時間
=> JS比率低め、CSSベースのアニメーション比率高め
(なるべくネイティブの高速なライブラリへ処理を
任せられるようにしてトータルの性能を上げる)

手動変換の利点
出来合いの自動変換ツールでうまく変換出来ないもの
でも動かせる
表現をリッチ化/簡略化出来る
独自の最適化を加えることが出来る
ロジックを自由に記載出来る

手動変換の欠点
既存のオーサリングツールを利用出来る余地が少ない
プログラマがゴリゴリ書かなきゃいけない
何か変更を加える際にも、当然プログラマの手(少な
くとも協力)が必要になる
レガシーなものと付き合っていく上で必要なコスト
とも言えるけど、結構しんどい

補足: CSSアニメーションとcanvasア
ニメーションの今後
JS実行コストとアニメーション描画コスト、どちらが支配的か
従来は描画コスト>JSでのフレーム制御コスト
描画アクセラレーションが十分に効いてくるとJS制御部分がネックになる
CSSアニメーションを利用すると、JSでの制御頻度をだいぶ減らせる
FlashでActionScriptベースのアニメーションよりもプリセットアニメーショ
ンのほうが高速なのと同じ
一定のところまではどちらを使っても良い 。限界性能はキーフレームア
ニメーションの利用と最適化次第
描画にDOM操作が不要な分、canvasのほうが高速となる可能性は十分ある

補足: 手動変換支援ツール /
Adobe Edge Animate
http://labs.adobe.com/technologies/edge/
HTML5なアニメーションのオーサリングツール
最近Preview 7がリリースされた
Flash(オーサリングツール)に近い完成度まで到達するこ
とが出来れば、と期待高まる
時間があれば後ほどもう少し詳しく紹介

変換にあたって
考えること・やること・気をつけること
ターゲットユーザの読みを立てる
どんなレイヤー構造になってるのか、というのをじっくり見て調べる
必要なエフェクトを洗い出す
元々シェイプとして作られているものを、どこまでCSSで描き何をPNGで書き
だすのか、を決める
HD版的なものを用意するかどうか検討する
画面タップへの対応をどのように処理するか考える
素材を一通り切り出す
素材のスプライトが可能か検討する
JS+CSSでひたすらリライトする

ターゲットユーザの読みを立てる
Androidのバージョン、iOSのバージョン、どういった端
末で動作検証すれば効果的に多くのユーザをカバー出
来るか
アクセスログの解析などをもとにする
今後の端末開発・発売動向と、想定ユーザの動向を一
定は予測しておく(外れても泣かない程度の依存度に)
当然、スマートフォン向けの表現を強化することで
ユーザ動向が変わることも想像はしておく

どんなレイヤー構造になってるの
か、というのをじっくり見て調べる
ここ大事。後で漏れに気づくと追加対応が大変な場合
もそこそこある。
後から変更される場合もあるだろうから、一定は仕方
ないんだけど それでもここに力入れとくのがいい

必要なエフェクトを洗い出す(例)
前景へのベタ塗りエフェクト(アルファ付き)
要素の斜め方向へのスライドアウト
要素の横方向へのスライドイン
背景のアルファを変化させつつ拡大
複数の要素をまとめてアニメーション
指定画像の前に同画像をマスクとして指定色(アルファあり)ベタ塗り
事前定義のアニメーション要素をコピー生成し指定位置で再生
任意のテキストを表示(自動折り返し、余分省略等)

元々シェイプとして作られているものを、どこま
でCSSで描き何をPNGで書き出すのか、を決める
先に紹介したように、単純なシェイプ以外はCSSのみで
描くのには向かない
全体の容量と見栄えのバランスで、簡略化可能なもの
は簡略化を
ベクターにこだわり過ぎない
ベクターデータを持つとしても、サーバ側で数パ
ターン生成すれば良い場合が大半
ブラウザでの描画時ギリギリまでベクターで持つ必

HD版的なものを用意するかどうか
検討する
高解像度版の素材を入手出来るか?
高解像度化することによる速度低下(ロード/描画)と、
見栄えとの兼ね合いで判断

画面タップへの対応をどのように
処理するか考える
フィーチャーフォン向けのものをスマフォ対応する場
合、↑↓キーやセンターキーを利用していた部分を画面
中段あたりに仮想キーとして用意するのが無難
スワイプとか使ってみたくなっても、安易な変更は使
いづらさを生む。パッと見で分かるUIを維持するのは
重要
描画エリアの一部に細かくタップエリアを張るより
は、画面の大部分を押すとセンターキー動作と同様と
するのが分かりやすいケースも

素材を一通り切り出す
どうしても手に入らないものは、目コピやトレースで
作り直す(大体はswfさえあればなんとかなるかと)
画像を8bit PNGなどに書き出してみてトータルサイズを
検討する
静的要素についてはアプリケーションキャッシュの利
用を検討する(フィーチャーフォン向けFlashLiteだと、通
常アニメーションロジックも含めて大半がキャッシュ
可能で、一部のメッセージや画像のみを実行時に差し
替えれば済むのでは)

素材のスプライト(1枚の画像への
集約)が可能か検討する
スプライト化することで、画像自体が8bitに収まらなくなる可能
性など、デメリットも考えつつ
元々画面全体が8bitしか使ってない、などであればそこそこスプ
ライト効果あるはず
大半をアプリケーションキャッシュに乗せられるのであれば
HTTPリクエスト頻度自体を低減出来る。この場合、JSからの指
定時に面倒が増えるデメリットが速度メリットを上回る可能性が
高いためスプライトしない
ただし、ブラウザの最適化によってはスプライトされたものを利
用したほうがOpenGL描画時にテクスチャの差し替えが不要とな
り、画面構築に必要なドローコール回数を減らせる可能性もある

JS+CSSでひたすらリライトする
ベンダープリフィックスを補完するユーティリティを用
意しておく
ベンダーごとの先行実装は当然
-webkit, -moz, -o, -ms
これらを一気に指定出来るようなユーティリティを
持っておくと多少楽

前半終了(5分休憩)
ハンズオン用の素材をダウンロードしておいてください
http://bit.ly/RVxHve

実際に作ってみる

前に軽くアンケート
プログラマな方 Illustratorを扱える方
デザイナな方 jQueryを扱える方
HTMLを書ける方 Coffee Script好きな方
CSSでレイアウト出来る方 PHPを書ける方
CSSでアニメーション出来 Javaを書ける方
る方
C#が好きな方
Photoshopを扱える方
Haskell好きな方

JS+CSSで書き始めるまで
FlashをMac上で再生する→QuickTime Playerで録画
avconv -i input.mov ‘out_%04d.png’でフレームにバラす
QuickTime Playerでコマ送り、早送り/スロー再生を繰り
返して演出の構造とレイヤ構造を掴み、リスト化する
もしもソースが手に入らなければswftoolsに含まれる
swfextractを使い内部リソース(PNG類)を抜き出しておく
swfmillの出力をざっと眺めてステージ情報等を把握する

今回フォーカスするポイント
JavaScriptからCSSを制御し、いくつかの表現を実装
なので、それ以外の部分については事前に用意
ディレクトリ構成をざっくり説明

ハンズオン...

まとめ

様々な技術を実際に試して良
し悪しを判断

JS+CSSでゴリゴリと書いていくのは、自由
度大きいけれどやっぱり大変な部分も多い。
うまく作業担当を切り分けるのが肝心。

他に、enchant.jsなどのJS+CSS用ゲームエンジンを
利用する方法も(アニメーションなどのユーティリティが一通
り っていて、ある程度広い端末での動作も確認されている)

書きやすいシンタックスで高速な実行環境、
というのがメンテ上は望ましいので、実装言
語にJSXを利用するというのもアリかも

その他
SVGの使い所
Android4.0、iOS5.x以上なら一定は使い物になるかも
(私見)アニメーション(画面タップ含め)丸ごとSVGでやるよりは、
ベクター保持したいグラフィックのラスタライズに使われるか
バイナリにパックされた複雑なシェイプをネイティブライブラリ
にて指定サイズでラスタライズ(JSでやるより十分高速になりうる)
参考
http://blog.webcreativepark.net/android/ AndroidでCSS3やる際の問題が
丁寧にまとめてあって凄い

長時間お付き合い頂き
ありがとうございました