Aiming study#6pdf

大規模 JavaScript
その設計と実装と現実

株式会社Aiming
ソフトウェアエンジニア
竹馬光太郎

2012/10/24@AimingStudy#6
12年10月24日水曜日

@mizchi / Koutaro Chikuba

2012/3/1- Aiming/Software Engineer

* github https://github.com/mizchi
* blog http://d.hatena.ne.jp/mizchi


Lord of Knights


Strategy & Card Game


Lord of Knights for iOS

* Strategy Simulation
* implemented by Unity3D


2012/5 中頃 ....

これをさー
移植したいんだよねー


Lord of Knights for
Mobage and Yahoo! Mobage
* refine UI for PC and SmartPhone
* implemented by HTML5
* share same resource for pc and mobile

新企画

状況
MobageとYahoo! Mobageに
同時リリースできないか？
* 既存のコードをUnity版書き出せないか？
*そもそもiPhone以外に書き出すことを想定していない
* HTML5でやろう
* 開発チーム: Webとネイティブが半々
* リリース目標は8月頭(2ヶ月半)


Lok-html版開発チーム
Aiming:
JS:7~8 マークアップ:3 デザイナ:2
サーバーは既にあるものを利用

* Rubyの人(Web) or C#の人(Unity) が多い
* JavaScript経験者少数


自分
* Web側のメンバーとして参加
* 入社前はWebSocketのMMOとか(mizchi/ws-netgame)
* Nodeの経験で色々言ってたら、好き勝手やらせてもら
えた


8月中頃…


できた


Unity3D
内政
HTML5


Unity3D
デッキ
HTML5


Unity3D
マップ
HTML5


その苦労と
楽しさについて


今日のテーマ

1章普通のWeb技術でリッチなゲームを
2章開発チームと環境
3章 JavaScriptと設計
4章 HTML5の実際


「普通」のWeb技術で
リッチなゲームを


「普通」である理由

普通のWeb技術とは何か？
* 最も知られている、ウェブサイトを組み立てる技術
* HTMLは「最も普及したGUIライブラリ」

「普通でない」もの
* 用途に特化したゲームエンジン
* Flashから出力する系とか
* HTML5の特定技術にロックインしすぎてる系


「普通」である理由

* 普通の知識はググれば見つかる
* 普通の知識はキャッチアップが簡単
* 普通の知識だから人員追加に耐えられ
る！！！


普通のライブラリを使う


今回使用したライブラリ

* CoffeeScript
* jQuery
* Backbone.js
* undrscore.js
* Mustache
* iScroll


とくに効果があったもの

CoffeeScript
気持ちがいいシンタックス + OOP

Backbone.js
MVCパターンとイディオムの提供

underscore.js
関数型言語が好きなメンバが多かったので


「もう最初からCoffeeScriptでいい
んじゃないかなー」

* チームにJS経験者がすくない(Rubyist, C#er)
* オブジェクト指向(っぽい)
* 「BadPartsでない」JavaScriptを出力する


The Little Book on CoffeeScript を読もう！

http://arcturo.github.com/library/
coffeescript/
(日本語版もある)

coffeescriptはシンタックスの拡張な
ので既存技術と重ならない


JavaScript の現況
JSはウェブ上の学習資料が豊富
ただし…

* 2005年までのJSサンプルは基本的に参考にならない
* AJAXによるパラダイムの変化
* JITによる高速化
* 行儀が悪いサンプルを見抜く力が必要


真っ当なプログラマなら

JavaScript: The Good Parts で大体は察するはず…


JavaScript: The GoodParts
JavaScriptの良いパーツだけを使おうという本

大事なのは、
付録A「ひどいパーツ」
付録B「悪いパーツ」

* JavaScript自体の言語仕様は小さい
* なぜCoffeeScriptはそのコードを出力するか？という視点で読む


結果
良かった点

* オブジェクト指向に慣れてる人は自然にCoffeeScript覚えた
* JavaScriptの理解はCoffeeScriptが出力するものをみてれば
* JSとCoffeeScriptに詳しい人が一人がいると便利

*チームで CoffeeScript は面白い言語と評判
* 面白いってのはモチベーション的に大事


1章まとめ

1. HTMLは普通の技術だから使いやすい

2. できるだけ新しい記事を参考にしよう

3. ダメなサンプル避ける為にJS GoodPartsを読もう

4. OOPやってたプログラマとCoffeeScriptは相性がいい


2章
開発チームと環境


最初にやったこと
VMware Imageの配布
* 非WebエンジニアはLinux環境が苦手
→ Rails/Node 環境を整えたVMイメージを配布

* 環境構築手順を解説したスクリプトを公開
→ わかる人は勝手に同等の環境を組んでいい


JavaScriptのテスト


JSerはテストを書く文化が希薄
どうする？

↓

無理矢理お膳立てして
とにかくテストが書きやすい環境を用意しよう


Nodeによるテスト環境

* Mocha + jsdom + sinon + should by npm/node.js
* ブラウザレスで動く
* 単体テストが簡単
example:
https://github.com/mizchi/sample-node-client-test


Demo


結果

* モデル層に近いピュアJSなコードが充実
* ゲームはそこが大事
* DOM強依存コードはやはりテストできず
HTMLは頻繁に変更される
高度に発達したHTMLはデザインと分離しにくい


Github & Code Review


OSSでは標準的なPull Requestフロー
全員が中央リポジトリをフォーク -> PR
詳細は http://scottchacon.com/2011/08/31/github-flow.html


Githubでのルール


自分で出したPullRequestは
自分以外がマージする


自分で出したPullRequestは
自分以外がマージする

* 誰かが目を通してマージする必要がある
* 誰でも目を通せる
→マージされたコードは全員の責任


結果

* 他人のコードを読む機会が多い
=>キャッチアップが早い

* 間違ったやり方がすぐ訂正される
=> 誤ったコードが再生産されるのを防ぐ


Githubとペアプロ

一行でツッコミ終わるものは解決するが
複雑になりそうなそのまま隣にいってペアプロ


パッチベースのレビューの欠点
メソッドの使い方、細かいミス等は指摘できるが
設計の失敗についてはレビューできない(しづらい)

→ 定期的に設計会議を開いた


効果的に行うために
個々人ごとに知識にバラつき

* ゲーム仕様
* 既存コードの理解
* 開発環境や開発言語の知識

足りない知識を埋め合わせるようにペアプロを組む


結果

* コードに対してチームの共通認識ができた
* 設計の失敗は定期的に議論すること修正
* 変なコードを通したくない
=> 徹底的にレビュー


2章まとめ

1. JavaScriptでもテストを書こう

2. ペアプロはスキルの共有が効果的に広まるように

3. githubを使うことでコードがチーム全体の責任になる

4. Diffベースのレビューは設計の失敗を指摘できない


JavaScriptの設計


コンパイラとしてのRails

Railsを使った理由
* Assets Pipeline
* coffee-script, scss, erbの動的コンパイル

* Ruby資産によるアセット管理やデプロイ
* コンパイル手順をrakeのtask化
* Capistranoによるデプロイ


開発環境

APIプロキシ
開発環境 Rails PHP
.coﬀee
動的コンパイル
.scss + キャッシュ


本番環境
静的ファイルの生成
Rails
開発環境

デプロイ

本番 PHP

* 本番にRailsはいない
* 静的ファイルのみ

Output
Railsが最終的に生成する静的ファイル
* index.html
* all_pc.js, all_mobile.js
* all_pc.css, all_mobile.css


結果

* 開発時のストレス低減
* Ruby資産を有用に使い回せた
* 開発ツールの追加が簡単
* 最終的に依存が切れてスッキリ！


ディレクトリと
名前空間


ディレクトリと名前空間

* ディレクトリ設計は重要に
名前空間は実装をインスパイアする

* 適切な名前空間は正しいアフォーダンスを生む
* 大規模JavaScriptは前例が少なかったので慎重にやった


sprocketsによる依存管理(Rails)
* //= require hogehoge で、ファイルが連結される
* 擬似インポートのように使う
* 素のJSはインポート機能がない
* 相対requireは禁止
* デプロイ担当から
「#ifdef ほしい」との声も…


Directories::
app/assets/javascripts/lib
* views/
Backbone.Viewを継承するクラス

* models/
Backbone.Modelを〃

* namespace.js
名前空間の初期化


名前空間
namepspace.js で定義

名前空間を事前に予約
※ Rubyのmoduleの真似したかった

グローバル汚染は
最小限にかつ明示的に


結果

* JSの依存管理ができた
* 意図不明なファイルがなくなった
* MVC的な構成が整った


JavaScript MVC with


Backbone/MVC

ref. https://hacks.mozilla.org/2012/10/the-web-developer-toolbox-backbone/


Backbone MVC

* Backbone.Viewはコントローラ
* MVCのVに相当するのはHTMLそのもの
* Backbone.ViewはBackbone.Modelを監視し、HTML
を書き換える


MVCに従った結果

同じJavaScriptを使用!


MVCに従った結果

セレクタをえるだけで
同じJavaScriptでMobile版とPC版を実装


今日のテーマ

1. 普通のWeb技術でゲームを
2.開発チームと環境
3.設計とディレクトリ
4. HTML5の実際


4章 HTML5の実際


HTML5が
得意なこと
苦手なこと


HTML5が得意なこと
* ユーザーインターフェース
* 複雑なUIを組むのが得意
* 柔軟なフォーマットの切り替え
* 便利
* 手早いデザイン変更
* 手軽
* 既存資産の再利用
* 無限にウェブにリソースがある


HTML5で出来ないこと
* 3D表現
* 無理にやる必要はない
* WebGLを実投入できる時期は早くて3~4年
* 細かいパフォーマンスチューニング
* 頑張ればパフォーマンス(たとえば60FPSの
アニメーション)は出せるがプラットフォ (趣味でいじってた
mmd.js)
ーム依存になりがち


例えば


マップ実装の話


マップ実装の話

* 選択タイルの点滅したかった
* 周辺に描画が走って激重
* やむなく白の透明タイルに
* モバイルでのドラッグが…
* iScrollの対応が半端で動いたり動かなったり
* 諦めてページャーで対応
* 初期化が重い…
* 大量のdivを生成するがゆえに重い


改善
工夫
* 一度生成したDOMを使いまわす
画面遷移 2.5s -> 0.1s

* クオータービュー(斜め見下ろし)
回転行列が固定(π/4)
手計算で解いた近似値をハードコード

* 端末ごとにDOM生成数を調整
Mobile: 10 × 15^2 = 2250 (div) PC: 10 × 25^2 = 6250

パフォーマンスに
影響を及ぼす二つ

* CSSのGPU負荷
* DOMツリー構築コストとそのタイミング


CSSのGPU負荷
再配置や再描画を抑制
描画がかかるタイミング/領域をできるだけ減らす

example:
ダイアログの場合
隠す -> 背面で要素書換 -> 表示


DOMツリーの構築コスト

$(‘body’).html(“<div>big .... text ... insertion</div>”)

* テキスト挿入後、バックグラウンドでDOMを再構築

* 大きな文字列をDOMに突っ込むと遅い

* 構築済みDOMに再配置が走らないよう挿入すると速い


ブラウザ互換の現実


ブラウザ互換の現実(PC)

Chromeが快適なのでChromeで開発してしまう
→ 大抵他で動かない
* 動かない箇所から逐一潰す
* ChromeからのIE9とFirefox対応、体感同じぐらいのコ
スト
* IE8対応は同じものもう半分作るぐらいの覚悟


ブラウザ互換の現実(Mobile)

iOS Safari
対応策が出回ってるので対処しやすい

Android Webkit Browser
機種ごとに全く新しいバグが出る
* Galaxy系バグるが同じ対応で全部直る
* Xperia系新しいやつほど変な挙動
* テレビと同じブランド基本的にヤバイ本当にヤバイ


教訓

* 早くする方法はあるが面倒くさい
* 現実的にどこまでやれるか決める
* マルチプラットフォーム対応はプロジェクトの3割以
上を見込んでおく
* Androidは一部を切り捨てることが前提
* HTMLはUIを作るのに最適


全体のまとめ
* JavaScriptもテストは書こう
* コードレビューしよう
* ちゃんと設計しよう
* JSのMVCはサーバーのMVCと違う
* HTMLはUIを作るのに最適
* パフォーマンスはトレードオフ


楽しかったこと
* 超実験的なプロジェクト
既存コード一切無し
ライブラリ選定が自由
* 新卒なのに色々やらせてくれた
一部やりすぎた感はある
* カリカリパフォーマンスチューニングするの楽しい
* ゲーム作るの面白い


最後にaltjsの話


altjs とは
JavaScriptにコンパイルされる言語一般のこと

List of languages that compile to JS · jashkenas/coffee-script
Wiki
https://github.com/jashkenas/coffee-script/wiki/List-of-
languages-that-compile-to-JS


次のJSプロジェクトがあるなら

CoffeeScript
* なんだかんだで使いやすい
HaXe
* 真っ当なOOP
* 速度改善が見込める
TypeScript
* 型 + インターフェースで使ってて面白い
* JS の悪い点引きずりすぎ


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


Aiming study#6pdf

Aiming study#6pdf

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(8)

Similar to Aiming study#6pdf

Similar to Aiming study#6pdf(20)

Aiming study#6pdf