Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

12.09.08 明星和楽2012 KLabハンズオンセッション

2 699 vues

Publié le

Flash LiteのアニメーションをJS+CSSに書き換えてみるハンズオンです。変換技術の紹介もいくつかしています。

  • Soyez le premier à commenter

12.09.08 明星和楽2012 KLabハンズオンセッション

  1. 1. KLab JS+CSS ワークショプ- Flash LiteアニメをJS+CSSでスマフォ向けに - KLab株式会社 開発制作本部 / 中澤 慧(@muo_jp)
  2. 2. 自己紹介なかざわ けい (中澤 慧 / twitter: @muo_jp)所属: KLab株式会社 開発制作本部Android好き Google公式ドキュメントの日本語訳とかやってましたプログラミング言語はC#好き興味範囲広め、結構プロトタイプ作ったりします実は、専門は経営学ですblog: http://muo.jp/
  3. 3. セッションの流れFlash Liteファイルをスマフォ対応する手段の紹介(15分)変換にあたって考えること・やること・気をつけること(15分)休憩・質疑応答(5分)実際に書いてみる(45分)まとめ(5分)質疑応答(5分)
  4. 4. 大前提フィーチャーフォン向けにFlash Liteで作られてきたものをリライトする30/60fpsを目指さない 諸々の実装バグが解消してきたらこのあたりを目指せる ようになるCPUをブン回してどうにかなる範囲(6/12fpsあたり)を目指す元版を大幅に超えたリッチな表現を目指さないベクター画像にこだわり過ぎない
  5. 5. こんなのが出来ます(要時間)ターン制ロボット格闘ゲーム構成要素 体力ゲージ 画像のクリップ域に対する半透明 マスク (赤みがかった処理) 導入部分のスライドイン、 スライドアウト ビリビリエフェクト 全画面エフェクト
  6. 6. Flash Liteファイルをスマフォ対応する手段の紹介
  7. 7. 系統JavaScriptで実装されたFlashLite(swf)エンジンで直接実行したり、前処理した独自ファイルを自前のエンジンに食わせて実行したりするもの=> 変換実行系JavaScript + CSS/canvasへの手動変換
  8. 8. 自動変換系
  9. 9. 自動変換系 / ExGameFlash 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以外での利用は認められていない
  10. 10. 自動変換系 / ShumwayMozillaによるOSS割と期待株社内で試してみた人曰く「結構ちゃんと動くので多少手を入れれば良さそう」
  11. 11. 自動変換系 / Google Swiffyhttps://www.google.com/doubleclick/studio/swiffy/日本語(MS932)の取り扱いに難がある変換部分自体は非公開であるため、問題があっても手を入れるのが非常に面倒
  12. 12. 自動変換系 / FlashJShttp://accelart.jp/products/flashjs.html株式会社アクセラートジャパンのプロダクト未評価
  13. 13. 自動変換系 / SWF Decompiler(HTML5 Exporter)http://www.sothink.com/swfファイル解析、素材抜き出しを行うツールのオマケ機能ごっそりと構造をJSONにダンプして、それを自前のプレイヤーで再生する形重すぎる上にシェイプが正しく描画されない箇所が多く、完成度低い
  14. 14. 手動変換
  15. 15. 基本構造画面表示の管理、ゲームロジック、アニメーション管理は全てJavaScriptで行う画面描画には主に2つの方法がある CSSを利用する / canvasを利用する 描画要素管理 描画要素管理 タイミング管理 タイミング管理データ処理 データ処理ネットワーク 画面 ネットワーク 画面 通信 描画 通信 描画 JavaScript CSS JavaScript canvas
  16. 16. canvas vs CSSCSS: 画面上に要素を配置し、キーフレーム指定等を行なってアニメーションさせるcanvas: 画面上にフリー描画エリアを作り、その上に任意の要素を描画する(アニメーションは自前管理)IE系ではCSSアニメーションのGPUアクセラレーションが推奨されているiOS5以降、canvasでの描画にGPUアクセラレーションが効くようになっている幅広い端末で30/60fps出すのは厳しい。が、12fpsならなんとか
  17. 17. CSSってこんなの出来るんでしょ? 出典: http://rei.idv.tw/sample/mio.html
  18. 18. ソース見てみなよ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; }
  19. 19. CSSでのシェイプ描画の実際作れるのは四角、円、楕円(枠指定によっては卵型のような非対称の楕円も)任意の多角形とか無いじゃあどうやってるのか borderで頑張る(凸だけでなく透明背景で凹も表現可能) before、afterで頑張る(同じ場所に最大3つのシェイプを 重ねてひとくくりにすることが出来る)ある種の芸。例: six-point-star ( http://css3shapes.com/ )
  20. 20. CSSでのシェイプ描画例このへんとか見ればより分かりやすいhttp://www.russellheimlich.com/blog/pure-css-shapes-triangles-delicious-logo-and-hearts/(軽くChrome開発ツールでデモ)これは辛い
  21. 21. これは辛い。
  22. 22. Flashでよくあるシェイプ
  23. 23. やめてください死んでしまいます
  24. 24. ということで、こうするベクターのシェイプは、適宜ラスタライズして扱う特定のシェイプへのマスク処理は、mask-imageを使うAndroid 4.0以上(4.0, 4.1)の標準ブラウザで、mask-imageとtransformを併用するとマスクが効かないというまさかのエンバグ(ChromeはOK)→マスク利用部分については、自前でアニメーション制御参考: http://jsdo.it/mattari_panda/qePP
  25. 25. 目指すバランスコーディング量=> JS比率かなり高め、CSS比率かなり低めアニメーション定義=> なるべくCSSのクラスとして事前定義(前述のAndroidでの問題があるため、今のところマスクと組み合わせるなどの乱用は禁物)実行時間=> JS比率低め、CSSベースのアニメーション比率高め(なるべくネイティブの高速なライブラリへ処理を任せられるようにしてトータルの性能を上げる)
  26. 26. 手動変換の利点出来合いの自動変換ツールでうまく変換出来ないものでも動かせる表現をリッチ化/簡略化出来る独自の最適化を加えることが出来るロジックを自由に記載出来る
  27. 27. 手動変換の欠点既存のオーサリングツールを利用出来る余地が少ないプログラマがゴリゴリ書かなきゃいけない何か変更を加える際にも、当然プログラマの手(少なくとも協力)が必要になるレガシーなものと付き合っていく上で必要なコストとも言えるけど、結構しんどい
  28. 28. 補足: CSSアニメーションとcanvasア ニメーションの今後JS実行コストとアニメーション描画コスト、どちらが支配的か従来は描画コスト>JSでのフレーム制御コスト描画アクセラレーションが十分に効いてくるとJS制御部分がネックになるCSSアニメーションを利用すると、JSでの制御頻度をだいぶ減らせるFlashでActionScriptベースのアニメーションよりもプリセットアニメーションのほうが高速なのと同じ一定のところまではどちらを使っても良い 。限界性能はキーフレームアニメーションの利用と最適化次第描画にDOM操作が不要な分、canvasのほうが高速となる可能性は十分ある
  29. 29. 補足: 手動変換支援ツール / Adobe Edge Animatehttp://labs.adobe.com/technologies/edge/HTML5なアニメーションのオーサリングツール最近Preview 7がリリースされたFlash(オーサリングツール)に近い完成度まで到達することが出来れば、と期待高まる時間があれば後ほどもう少し詳しく紹介
  30. 30. 変換にあたって考えること・やること・気をつけることターゲットユーザの読みを立てるどんなレイヤー構造になってるのか、というのをじっくり見て調べる必要なエフェクトを洗い出す元々シェイプとして作られているものを、どこまでCSSで描き何をPNGで書きだすのか、を決めるHD版的なものを用意するかどうか検討する画面タップへの対応をどのように処理するか考える素材を一通り切り出す素材のスプライトが可能か検討するJS+CSSでひたすらリライトする
  31. 31. ターゲットユーザの読みを立てるAndroidのバージョン、iOSのバージョン、どういった端末で動作検証すれば効果的に多くのユーザをカバー出来るかアクセスログの解析などをもとにする今後の端末開発・発売動向と、想定ユーザの動向を一定は予測しておく(外れても泣かない程度の依存度に)当然、スマートフォン向けの表現を強化することでユーザ動向が変わることも想像はしておく
  32. 32. どんなレイヤー構造になってるのか、というのをじっくり見て調べるここ大事。後で漏れに気づくと追加対応が大変な場合もそこそこある。後から変更される場合もあるだろうから、一定は仕方ないんだけど それでもここに力入れとくのがいい
  33. 33. 必要なエフェクトを洗い出す(例)前景へのベタ塗りエフェクト(アルファ付き)要素の斜め方向へのスライドアウト要素の横方向へのスライドイン背景のアルファを変化させつつ拡大複数の要素をまとめてアニメーション指定画像の前に同画像をマスクとして指定色(アルファあり)ベタ塗り事前定義のアニメーション要素をコピー生成し指定位置で再生任意のテキストを表示(自動折り返し、余分省略等)
  34. 34. 元々シェイプとして作られているものを、どこまでCSSで描き何をPNGで書き出すのか、を決める先に紹介したように、単純なシェイプ以外はCSSのみで描くのには向かない全体の容量と見栄えのバランスで、簡略化可能なものは簡略化をベクターにこだわり過ぎない ベクターデータを持つとしても、サーバ側で数パ ターン生成すれば良い場合が大半 ブラウザでの描画時ギリギリまでベクターで持つ必
  35. 35. HD版的なものを用意するかどうか 検討する高解像度版の素材を入手出来るか?高解像度化することによる速度低下(ロード/描画)と、見栄えとの兼ね合いで判断
  36. 36. 画面タップへの対応をどのように 処理するか考えるフィーチャーフォン向けのものをスマフォ対応する場合、↑↓キーやセンターキーを利用していた部分を画面中段あたりに仮想キーとして用意するのが無難スワイプとか使ってみたくなっても、安易な変更は使いづらさを生む。パッと見で分かるUIを維持するのは重要描画エリアの一部に細かくタップエリアを張るよりは、画面の大部分を押すとセンターキー動作と同様とするのが分かりやすいケースも
  37. 37. 素材を一通り切り出すどうしても手に入らないものは、目コピやトレースで作り直す(大体はswfさえあればなんとかなるかと)画像を8bit PNGなどに書き出してみてトータルサイズを検討する静的要素についてはアプリケーションキャッシュの利用を検討する(フィーチャーフォン向けFlashLiteだと、通常アニメーションロジックも含めて大半がキャッシュ可能で、一部のメッセージや画像のみを実行時に差し替えれば済むのでは)
  38. 38. 素材のスプライト(1枚の画像への 集約)が可能か検討するスプライト化することで、画像自体が8bitに収まらなくなる可能性など、デメリットも考えつつ元々画面全体が8bitしか使ってない、などであればそこそこスプライト効果あるはず大半をアプリケーションキャッシュに乗せられるのであればHTTPリクエスト頻度自体を低減出来る。この場合、JSからの指定時に面倒が増えるデメリットが速度メリットを上回る可能性が高いためスプライトしないただし、ブラウザの最適化によってはスプライトされたものを利用したほうがOpenGL描画時にテクスチャの差し替えが不要となり、画面構築に必要なドローコール回数を減らせる可能性もある
  39. 39. JS+CSSでひたすらリライトするベンダープリフィックスを補完するユーティリティを用意しておく ベンダーごとの先行実装は当然 -webkit, -moz, -o, -ms これらを一気に指定出来るようなユーティリティを 持っておくと多少楽
  40. 40. 前半終了(5分休憩)ハンズオン用の素材をダウンロードしておいてください http://bit.ly/RVxHve
  41. 41. 実際に作ってみる
  42. 42. 前に軽くアンケートプログラマな方 Illustratorを扱える方デザイナな方 jQueryを扱える方HTMLを書ける方 Coffee Script好きな方CSSでレイアウト出来る方 PHPを書ける方CSSでアニメーション出来 Javaを書ける方る方 C#が好きな方Photoshopを扱える方 Haskell好きな方
  43. 43. JS+CSSで書き始めるまでFlashをMac上で再生する→QuickTime Playerで録画avconv -i input.mov ‘out_%04d.png’でフレームにバラすQuickTime Playerでコマ送り、早送り/スロー再生を繰り返して演出の構造とレイヤ構造を掴み、リスト化するもしもソースが手に入らなければswftoolsに含まれるswfextractを使い内部リソース(PNG類)を抜き出しておくswfmillの出力をざっと眺めてステージ情報等を把握する
  44. 44. 今回フォーカスするポイントJavaScriptからCSSを制御し、いくつかの表現を実装なので、それ以外の部分については事前に用意ディレクトリ構成をざっくり説明
  45. 45. ハンズオン...
  46. 46. まとめ
  47. 47. 様々な技術を実際に試して良 し悪しを判断
  48. 48. JS+CSSでゴリゴリと書いていくのは、自由度大きいけれどやっぱり大変な部分も多い。 うまく作業担当を切り分けるのが肝心。
  49. 49. 他に、enchant.jsなどのJS+CSS用ゲームエンジンを利用する方法も(アニメーションなどのユーティリティが一通り っていて、ある程度広い端末での動作も確認されている)
  50. 50. 書きやすいシンタックスで高速な実行環境、というのがメンテ上は望ましいので、実装言 語にJSXを利用するというのもアリかも
  51. 51. その他SVGの使い所 Android4.0、iOS5.x以上なら一定は使い物になるかも (私見)アニメーション(画面タップ含め)丸ごとSVGでやるよりは、 ベクター保持したいグラフィックのラスタライズに使われるか バイナリにパックされた複雑なシェイプをネイティブライブラリ にて指定サイズでラスタライズ(JSでやるより十分高速になりうる)参考 http://blog.webcreativepark.net/android/ AndroidでCSS3やる際の問題が 丁寧にまとめてあって凄い
  52. 52. 長時間お付き合い頂きありがとうございました

×