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

1. 短期間＋大規模ゲーム開発でも破綻
しない HTML・SCSS
株式会社 Aiming
岩野 尚吾

2. 自己紹介
• @shiwano
• HTML版ロードオブナイツのプロジェ
クトには、6月中旬からアサイン
• ゲーム開発への本格的な参加は、今回
が初めて
• それまでは普通の Web 製作で、マー
クアップとかやってた

3. 本筋を進める前に
HTML版ロードオブナイツ
について軽く説明

6. もともとは Unity 製の
スマートフォン・ネイティブアプリ！
（最近 Android 版も出た）

7. それを HTML5 に移植したのが
HTML版ロードオブナイツ

8. 開発時に伝えられていた
要件は―

9. マルチデバイス対応！
• PC版とモバイル版を同時リリース
→ Mobage と Yahoo! Mobage で
• モバイル版はもちろん Android にも対
応（2.2から）

10. IE8 対応！
やはり 20% 超の
ユーザーベースはふつう切れない

11. デザイン一新！
• PC版もモバイル版も新規デザインに
• モバイル版は縦持ち用
• ネイティブアプリをそのままコピーす
ればいいというわけではない
→ UI 作り直し！！！

12. Unity版
HTML・モバイル版

13. Unity版
HTML・PC版

14. そして、なにより…

15. スケジュール最優先！
• なにより期日優先！！！！
• タイトなスケジュール
→ 自分がアサインされてから、
リリース予定日まで 2ヶ月しかない…
• 社内で優先度が一番高いプロジェクトに

16. ということで、
開発はすごく大変でした

17. 今日のテーマ
• そういう厳しい開発の中で、プロダク
トを完成させるために、何を諦めて、
何を諦めなかったか
• 主にマークアップ方面を担当した者の
視点から

18. ゲーム開発で大切なことって何だろう？

19. 期日を守ることです
（今回のプロジェクトでは）

20. 人は何かの犠牲なしに
何も得ることは出来ない

21. 限られた工数の中で
期日を守るために
まず、何を犠牲にしたのか？

22. 諦めたもの・その1
セマンティック・ウェブ

23. セマンティック・ウェブとは
• Webサイトの各記述の意味を適切に捉
え、正しいタグやメタデータを付与し
ていきましょうという考え方
• HTML5 では特に重視されている

24. セマンティック・ウェブとは
• 付与したメタデータをもとにコン
ピュータが情報を収集・解釈できた
り、ハンディを持つ人たちが情報にア
クセスしやすくなる

25. 具体的にどうしたの？
• ワイルドマークアップ
• ID やクラスの命名規則は、ほとんど決
めてない
• タグは基本 div（たまに ul, li）
→ a タグも使ってない
→ HTML5 新規のタグは機能的に
必要なもの以外は使わない
→ アウトライン？
セクショニング・コンテンツ？ なにそれ

26. で、どうだった？
• まあ、問題ない
→ もともと、アプリの性質上、それほど
アクセシビリティに気を配る必要ない
→ 基本、DOM さえあればいい（えっ
→ 後ろめたい気持ちはある
• もっとゲームに特化した意味付けをで
きるスキーマがあってもいいのでは？

27. 諦めたもの・その2
一般的な段組レイアウト

28. 一般的な Web サイトでは
• HTML の要素順 ＋ スタイルシート の
float プロパティを使った段組レイアウ
トが一般的
• 最近だとそれに加えて、「レスポンシ
ブ・ウェブ・デザイン常識だよね」と
いう感じ

29. しかし、ゲームの UI って複雑

30. 複雑な UI の一例

31. 縦横無尽にクリックできる！

32. Web サイトと同じように
レイアウトを組むのは
難しい

33. 具体的にどうしたの？
• position: absolute; 多用
→ どこもかしこもこれで要素の
位置を指定している
• z-index も多用
→ マップタイルの重なり制御など
かなり複雑化している

34. で、どうだった？
• ぜんぜんレスポンシブじゃない
→ でもゲームってそんなものかも
• 工数削減にはなった
→ ただし、メンテナンス性は微妙…
• エディタで CSS を編集して、ゲームの
UI を作るのは筋が悪いのでは？
→ GUI ツールの必要性をちょっと感じた

35. 諦めたもの・その3
画像アセット管理

36. 画像組み込みのフロー
PSDで
画像 マーク
元素材 コミット
スライス アップ
作成

37. 画像組み込みのフロー
PSDで
画像 マーク
元素材 コミット
スライス アップ
作成
この部分を自動化しないとつらい！

38. アセット管理の重要性
• オンラインゲームの開発は初回リリー
スで終わりではない
• 継続的に行われるアップデートで、ど
のアセットが必要となるか、管理する
ことがとても大切！
→ 普通の Web サイトでも大切だが、
ゲームだと特に重みを増す
• テクニカル・アーティストの職域

39. 具体的にどうしたの？
• マンパワーでなんとかする！！！

40. で、どうだった？
• やっぱり事故る！！！

41. 諦めたもの・その4
IE８ 対応

42. 当初は、タスクとして見積
もっていたが…
• スケジュールの都合で、モバイル版のデ
ザインをそのまま、PC版に持ってくる
ことに
• CSS も IE8 対応にするために、余分な
工程をたくさん踏まねばならなかった
→ Retina 対応と IE8 対応の矛盾
• そもそも JS が動かない

43. ということで、IE8 は
対応しないことに

44. で、どうだった？
• 開発的にはすごくハッピー！！！
• 運営的にはやはり潜在的な顧客が減る
ので微妙…
• スケジュールのために、一度でも IE8
対応をスコープから外すと、もう二度
と復活しない

45. 諦めたもの一覧
• セマンティック・ウェブ
• 一般的な段組レイアウト
• 画像アセット管理
• IE8 対応

46. じゃあ、それらを諦めて、
代わりに何やったの？

47. 大切なのは、期日

48. つまり、重視すべきは

49. 開発効率！

50. メンテナンス性：開発効率
↓
１：３

51. こんなことをやりました
• 開発環境でのマークアップ管理
• 画像最適化
• SCSS + Compass の導入
• PC版・モバイル版の出し分け準備
• 実装の把握

52. やったこと・その1
開発環境でのマークアップ管理

53. 何が問題だったの？
デザイン確認用のマーク
アップは、Rails の
public ディレクトリで管
理していて煩雑だった

54. 何が問題だったの？
この部分が
必要なだけなのに
DRY に書けない

55. どう対応したの？
• デザイン確認用のマークアップに、専
用のルーティングを用意して、Rails で
表示できるようにした
• http://localhost:3000/pc/map/

56. 何がよかった？
• 開発環境はひとつだけというのが明確
になった
→ デザイン用に環境を分けるのは、
よくないと思う
• DRYレイアウトファイルに共通部分を書ける
→
に書ける
→ Rails のヘルパーメソッドが使える
• 実装するときも組み込みやすい
→ PC版の開発速度が上がった

57. やったこと・その2
画像最適化

58. 画像の最適化大事
• 特にモバイル版
• 3G 回線経由だと、画像のファイルサイ
ズがボトルネックになりうる
• また、高解像度ディスプレイで綺麗に
見えるよう画像も高解像度のものを使
わなければならない
• 両立は大変！

59. 高解像度ディスプレイ対応
横 720px 用にデザインされた画像を
縮小して配置している

60. どう対応したの？
• モバイル版重視
• Chrome の開発者ツール
で読み込んでいる画像サ
イズを確認しながら、丁
寧に最適化を行った

61. 何がよかった？
• モバイル版の画像サイズを抑制できた
→ 同等の機能で実質解像度的にも
大した差はない中で
• モバイル版の総画像サイズ
→ 5.3 MB
• PC版の総画像サイズ
→ 6.6 MB

62. 最適化ツールなど
• ImageOptim (画像ファイルサイズ最適化)
→ http://imageoptim.com/
• ImageAlpha (透過を保ちつつPNG高圧縮)
→ http://pngmini.com/
• CSSスプライト
→ 類似の画像をまとめるなど
必要な部分だけ

63. やったこと・その3
SCSS + Compass の導入

64. ＋
やっぱり便利！

65. 簡単に説明すると―

66. SCSS とは
• CSS の拡張メタ言語
→ CSS のスーパーセット
• 便利な機能がたくさん
→ 変数
→ 演算式
→ Mixin
→ Function

67. Compass とは
• SCSS のフレームワーク
• CSS3 の記述を簡潔にする
Mixin が多数用意
• Web 制作に便利な再利用可
能パターンを多数用意
→ CSS スプライトの
自動生成など

68. 最近は、紹介記事も増えて
業務で使う人も多い？
（デファクトスタンダードになってほしい）

69. 具体的にどんな感じで
書いてるのか

70. たとえば、アイコン
• data 属性の値
で、アイコンが
差し替わる

71. このような SCSS を使用

72. モバイル版のマップ
• マップタイルのサイズ
は 42px！

73. PC版のマップ
• マップタイルのサイズ
に 64px！
• モバイル版よりちょっ
と大きい

74. このような SCSS を使用
変数の値を調整するだけ

75. SCSS ファイルの
トータルのコード行数は
16685

76. 展開される CSS ファイルの
トータルのコード行数は
32712
(expanded style, line_comments OFF)

77. 何がよかった？
• 開発速度アップ！
→ コード行数の大幅削減
→ PC版の開発をしているときに
マップ部分のデザインが一瞬で終わった
• DRY に書けた
→ PC版・モバイル版のコードを共通化
→ Compass の Mixin 便利！

78. やったこと・その4
PC版・モバイル版の
出し分け準備

79. PC版・モバイル版のデザインを
効率的に管理したい！

80. 要件について整理
• HTML版ロードオブナイツは
Single Page Application
→ HTMLファイルはたった一つ
→ CSSファイルは少なければ少ないほどよい
• 現在は、PC版・モバイル版だけだが、将
来的に新しいバージョンが追加されるこ
とがありうる
→ 適切なディレクトリ分けが必要

81. よって、SCSS は
このような形に

82. SCSS のディレクトリ構成
• modules
→ 共通で使う mixin や 変数などを
まとめたディレクトリ
• partials
→ プラットフォームごとに使う
SCSS ファイルをまとめたディレクトリ

83. SCSS の中身
このように import して
最終的に1ファイルに出力！

84. View（HTML） は
このような形に

85. View のディレクトリ構成
• app/views 以下に、pc と mobile と
いうディレクトリを作成
→ View ファイルはすべて ERB 形式で記述

86. View の中身の例
ゲームで使う HTML は
独自ヘルパーメソッドを使って
テンプレート化

87. テンプレートの例
テンプレート化された HTML は、
このように Mustache 化も
されていたりする

88. そして最終的には
全 2766 行数の単一のHTML
ファイルとして出力

89. 何がよかった？
• この規模のゲームを Single Page
Application として運用したこと
→ モバイル版でも、特にパフォーマンス
に問題はなかった
• PC版とモバイル版のデザインを適切に
出し分けることができた
• 新しいバージョンを追加する作業が容
易になった

90. やったこと・その5
実装の把握

91. 何が問題だったの？
• 基本、DOM 依存が激しいゲーム
→ それ関連のバグが山ほどある
• JS 側のバグか HTML・CSS 側のバグ
か、判別もけっこう大変

92. 例えば、こんなバグチケット！

93. どう対応したの？
• ペアプロする！
• JS のコードはなるべく読む
→ 特に View 側
→ Github 見やすくて便利
• 自分でマークアップして、自分で実装
のパターンも

94. 何がよかった？
• 結果的に工数削減！
→ コミュニケーションコストが減るため
• デザイン側のバグ、JS 側のバグの対
応・判別が容易
• 自分の関われる範囲が増えるのは、や
はり嬉しい！

95. 結果、期日はどうなったの？
• プロジェクト初期に、想定されていた7
月中旬に出すというのは守れなかった
• 8月3日に Mobage 審査に出すという
約束は守れた
→ 途中審査落ちるなど色々ありつつも、
8月中に何とかリリースできた

96. ということで、まとめ！

97. まとめ
• プロジェクトの性質によって、何が大
切かよく変わるので、みんなしっかり
考えよう
• Web 制作のセオリーをそのまま無批判
にゲーム開発に持ってくるとつらい
• アセット管理大事
• SCSS + Compass みんな使おう

98. あと、何より―

99. ゲーム開発って、面白い！

100. ご清聴ありがとうございました

101. 最後に、このプロジェクトの
管理手法について
• 弊社開発者ブログに記事があるので、
ご覧になってない方は是非
• JS 大規模プロジェクトの管理手法 ‒
ロードオブナイツの実例紹介
→ http://goo.gl/JFrlt