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.

短期間+大規模ゲーム開発でも破綻しないHTML・SCSS

34 929 vues

Publié le

http://www.zusaar.com/event/412004

Publié dans : Technologie

短期間+大規模ゲーム開発でも破綻しないHTML・SCSS

  1. 1. 短期間+大規模ゲーム開発でも破綻しない HTML・SCSS 株式会社 Aiming 岩野 尚吾
  2. 2. 自己紹介• @shiwano • HTML版ロードオブナイツのプロジェ クトには、6月中旬からアサイン• ゲーム開発への本格的な参加は、今回 が初めて• それまでは普通の Web 製作で、マー クアップとかやってた
  3. 3. 本筋を進める前にHTML版ロードオブナイツ について軽く説明
  4. 4. もともとは Unity 製のスマートフォン・ネイティブアプリ! (最近 Android 版も出た)
  5. 5. それを HTML5 に移植したのが HTML版ロードオブナイツ
  6. 6. 開発時に伝えられていた 要件は―
  7. 7. マルチデバイス対応!• PC版とモバイル版を同時リリース  → Mobage と Yahoo! Mobage で• モバイル版はもちろん Android にも対 応(2.2から)
  8. 8. IE8 対応! やはり 20% 超のユーザーベースはふつう切れない
  9. 9. デザイン一新!• PC版もモバイル版も新規デザインに• モバイル版は縦持ち用• ネイティブアプリをそのままコピーす ればいいというわけではない  → UI 作り直し!!!
  10. 10. Unity版 HTML・モバイル版
  11. 11. Unity版 HTML・PC版
  12. 12. そして、なにより…
  13. 13. スケジュール最優先!• なにより期日優先!!!!• タイトなスケジュール  → 自分がアサインされてから、    リリース予定日まで 2ヶ月しかない…• 社内で優先度が一番高いプロジェクトに
  14. 14. ということで、開発はすごく大変でした
  15. 15. 今日のテーマ• そういう厳しい開発の中で、プロダク トを完成させるために、何を諦めて、 何を諦めなかったか• 主にマークアップ方面を担当した者の 視点から
  16. 16. ゲーム開発で大切なことって何だろう?
  17. 17. 期日を守ることです(今回のプロジェクトでは)
  18. 18. 人は何かの犠牲なしに何も得ることは出来ない
  19. 19. 限られた工数の中で 期日を守るためにまず、何を犠牲にしたのか?
  20. 20. 諦めたもの・その1セマンティック・ウェブ
  21. 21. セマンティック・ウェブとは• Webサイトの各記述の意味を適切に捉 え、正しいタグやメタデータを付与し ていきましょうという考え方• HTML5 では特に重視されている
  22. 22. セマンティック・ウェブとは• 付与したメタデータをもとにコン ピュータが情報を収集・解釈できた り、ハンディを持つ人たちが情報にア クセスしやすくなる
  23. 23. 具体的にどうしたの?• ワイルドマークアップ • ID やクラスの命名規則は、ほとんど決 めてない• タグは基本 div(たまに ul, li)  → a タグも使ってない  → HTML5 新規のタグは機能的に    必要なもの以外は使わない  → アウトライン?    セクショニング・コンテンツ? なにそれ
  24. 24. で、どうだった?• まあ、問題ない  → もともと、アプリの性質上、それほど    アクセシビリティに気を配る必要ない  → 基本、DOM さえあればいい(えっ  → 後ろめたい気持ちはある• もっとゲームに特化した意味付けをで きるスキーマがあってもいいのでは?
  25. 25. 諦めたもの・その2一般的な段組レイアウト
  26. 26. 一般的な Web サイトでは• HTML の要素順 + スタイルシート の float プロパティを使った段組レイアウ トが一般的• 最近だとそれに加えて、「レスポンシ ブ・ウェブ・デザイン常識だよね」と いう感じ
  27. 27. しかし、ゲームの UI って複雑
  28. 28. 複雑な UI の一例
  29. 29. 縦横無尽にクリックできる!
  30. 30. Web サイトと同じように レイアウトを組むのは 難しい
  31. 31. 具体的にどうしたの?• position: absolute; 多用  → どこもかしこもこれで要素の    位置を指定している• z-index も多用  → マップタイルの重なり制御など    かなり複雑化している
  32. 32. で、どうだった?• ぜんぜんレスポンシブじゃない  → でもゲームってそんなものかも• 工数削減にはなった  → ただし、メンテナンス性は微妙…• エディタで CSS を編集して、ゲームの UI を作るのは筋が悪いのでは?  → GUI ツールの必要性をちょっと感じた
  33. 33. 諦めたもの・その3画像アセット管理
  34. 34. 画像組み込みのフローPSDで 画像 マーク元素材 コミット スライス アップ 作成
  35. 35. 画像組み込みのフローPSDで 画像 マーク元素材 コミット スライス アップ 作成 この部分を自動化しないとつらい!
  36. 36. アセット管理の重要性• オンラインゲームの開発は初回リリー スで終わりではない• 継続的に行われるアップデートで、ど のアセットが必要となるか、管理する ことがとても大切!  → 普通の Web サイトでも大切だが、    ゲームだと特に重みを増す• テクニカル・アーティストの職域
  37. 37. 具体的にどうしたの?• マンパワーでなんとかする!!! 
  38. 38. で、どうだった?• やっぱり事故る!!! 
  39. 39. 諦めたもの・その4 IE8 対応
  40. 40. 当初は、タスクとして見積 もっていたが…• スケジュールの都合で、モバイル版のデ ザインをそのまま、PC版に持ってくる ことに• CSS も IE8 対応にするために、余分な 工程をたくさん踏まねばならなかった  → Retina 対応と IE8 対応の矛盾• そもそも JS が動かない
  41. 41. ということで、IE8 は 対応しないことに
  42. 42. で、どうだった?• 開発的にはすごくハッピー!!! • 運営的にはやはり潜在的な顧客が減る ので微妙…• スケジュールのために、一度でも IE8 対応をスコープから外すと、もう二度 と復活しない
  43. 43. 諦めたもの一覧 • セマンティック・ウェブ • 一般的な段組レイアウト • 画像アセット管理 • IE8 対応
  44. 44. じゃあ、それらを諦めて、 代わりに何やったの?
  45. 45. 大切なのは、期日
  46. 46. つまり、重視すべきは
  47. 47. 開発効率!
  48. 48. メンテナンス性:開発効率 ↓ 1:3
  49. 49. こんなことをやりました• 開発環境でのマークアップ管理• 画像最適化• SCSS + Compass の導入• PC版・モバイル版の出し分け準備• 実装の把握
  50. 50. やったこと・その1開発環境でのマークアップ管理
  51. 51. 何が問題だったの? デザイン確認用のマーク アップは、Rails の public ディレクトリで管 理していて煩雑だった
  52. 52. 何が問題だったの? この部分が 必要なだけなのに DRY に書けない
  53. 53. どう対応したの?• デザイン確認用のマークアップに、専 用のルーティングを用意して、Rails で 表示できるようにした• http://localhost:3000/pc/map/
  54. 54. 何がよかった?• 開発環境はひとつだけというのが明確 になった  → デザイン用に環境を分けるのは、    よくないと思う• DRYレイアウトファイルに共通部分を書ける  → に書ける  → Rails のヘルパーメソッドが使える• 実装するときも組み込みやすい  → PC版の開発速度が上がった
  55. 55. やったこと・その2画像最適化
  56. 56. 画像の最適化大事• 特にモバイル版 • 3G 回線経由だと、画像のファイルサイ ズがボトルネックになりうる• また、高解像度ディスプレイで綺麗に 見えるよう画像も高解像度のものを使 わなければならない• 両立は大変! 
  57. 57. 高解像度ディスプレイ対応 横 720px 用にデザインされた画像を 縮小して配置している
  58. 58. どう対応したの? • モバイル版重視 • Chrome の開発者ツール で読み込んでいる画像サ イズを確認しながら、丁 寧に最適化を行った
  59. 59. 何がよかった?• モバイル版の画像サイズを抑制できた  → 同等の機能で実質解像度的にも    大した差はない中で• モバイル版の総画像サイズ  → 5.3 MB• PC版の総画像サイズ  → 6.6 MB
  60. 60. 最適化ツールなど• ImageOptim (画像ファイルサイズ最適化)  → http://imageoptim.com/• ImageAlpha (透過を保ちつつPNG高圧縮)  → http://pngmini.com/• CSSスプライト  → 類似の画像をまとめるなど    必要な部分だけ
  61. 61. やったこと・その3SCSS + Compass の導入
  62. 62. +やっぱり便利!
  63. 63. 簡単に説明すると―
  64. 64. SCSS とは • CSS の拡張メタ言語 → CSS のスーパーセット • 便利な機能がたくさん → 変数 → 演算式 → Mixin → Function
  65. 65. Compass とは • SCSS のフレームワーク • CSS3 の記述を簡潔にする Mixin が多数用意 • Web 制作に便利な再利用可 能パターンを多数用意 → CSS スプライトの   自動生成など
  66. 66. 最近は、紹介記事も増えて 業務で使う人も多い?(デファクトスタンダードになってほしい)
  67. 67. 具体的にどんな感じで 書いてるのか
  68. 68. たとえば、アイコン • data 属性の値 で、アイコンが 差し替わる
  69. 69. このような SCSS を使用
  70. 70. モバイル版のマップ • マップタイルのサイズ は 42px!
  71. 71. PC版のマップ • マップタイルのサイズ に 64px! • モバイル版よりちょっ と大きい
  72. 72. このような SCSS を使用 変数の値を調整するだけ
  73. 73. SCSS ファイルのトータルのコード行数は 16685
  74. 74. 展開される CSS ファイルの トータルのコード行数は 32712(expanded style, line_comments OFF)
  75. 75. 何がよかった?• 開発速度アップ!  → コード行数の大幅削減  → PC版の開発をしているときに    マップ部分のデザインが一瞬で終わった• DRY に書けた  → PC版・モバイル版のコードを共通化  → Compass の Mixin 便利!
  76. 76. やったこと・その4PC版・モバイル版の 出し分け準備
  77. 77. PC版・モバイル版のデザインを 効率的に管理したい!
  78. 78. 要件について整理• HTML版ロードオブナイツは Single Page Application  → HTMLファイルはたった一つ  → CSSファイルは少なければ少ないほどよい• 現在は、PC版・モバイル版だけだが、将 来的に新しいバージョンが追加されるこ とがありうる  → 適切なディレクトリ分けが必要
  79. 79. よって、SCSS は このような形に
  80. 80. SCSS のディレクトリ構成• modules  → 共通で使う mixin や 変数などを    まとめたディレクトリ• partials  → プラットフォームごとに使う    SCSS ファイルをまとめたディレクトリ
  81. 81. SCSS の中身 このように import して最終的に1ファイルに出力!
  82. 82. View(HTML) は このような形に
  83. 83. View のディレクトリ構成• app/views 以下に、pc と mobile と いうディレクトリを作成  → View ファイルはすべて ERB 形式で記述
  84. 84. View の中身の例 ゲームで使う HTML は独自ヘルパーメソッドを使って テンプレート化
  85. 85. テンプレートの例テンプレート化された HTML は、 このように Mustache 化も されていたりする
  86. 86. そして最終的には全 2766 行数の単一のHTML ファイルとして出力
  87. 87. 何がよかった?• この規模のゲームを Single Page Application として運用したこと  → モバイル版でも、特にパフォーマンス    に問題はなかった• PC版とモバイル版のデザインを適切に 出し分けることができた• 新しいバージョンを追加する作業が容 易になった
  88. 88. やったこと・その5実装の把握
  89. 89. 何が問題だったの?• 基本、DOM 依存が激しいゲーム  → それ関連のバグが山ほどある• JS 側のバグか HTML・CSS 側のバグ か、判別もけっこう大変
  90. 90. 例えば、こんなバグチケット!
  91. 91. どう対応したの?• ペアプロする!• JS のコードはなるべく読む  → 特に View 側  → Github 見やすくて便利• 自分でマークアップして、自分で実装 のパターンも
  92. 92. 何がよかった?• 結果的に工数削減!  → コミュニケーションコストが減るため• デザイン側のバグ、JS 側のバグの対 応・判別が容易• 自分の関われる範囲が増えるのは、や はり嬉しい!
  93. 93. 結果、期日はどうなったの?• プロジェクト初期に、想定されていた7 月中旬に出すというのは守れなかった• 8月3日に Mobage 審査に出すという 約束は守れた  → 途中審査落ちるなど色々ありつつも、    8月中に何とかリリースできた
  94. 94. ということで、まとめ!
  95. 95. まとめ• プロジェクトの性質によって、何が大 切かよく変わるので、みんなしっかり 考えよう• Web 制作のセオリーをそのまま無批判 にゲーム開発に持ってくるとつらい• アセット管理大事• SCSS + Compass みんな使おう
  96. 96. あと、何より―
  97. 97. ゲーム開発って、面白い!
  98. 98. ご清聴ありがとうございました
  99. 99. 最後に、このプロジェクトの 管理手法について• 弊社開発者ブログに記事があるので、 ご覧になってない方は是非• JS 大規模プロジェクトの管理手法 ‒ ロードオブナイツの実例紹介  → http://goo.gl/JFrlt

×