XFLAG Tech Note Vol.01

XFLAG Tech Note 株式会社ミクシィ XFLAG スタジオ著 2018-10-08 版株式会社ミクシィ発⾏

まえがき本書「XFLAG Tech Note」は、XFLAG™ スタジオに所属する有志達によって執筆・制作された初の技術書です。実際にスマホアプリ「モンスターストライク（以下モンスト）」などのプロダクト開発の現場で実践されている今すぐ試してみたい実⽤的な内容から、個⼈的に研究・実装してみた事など、各⾃が思い思いに執筆いたしました。そのため、各章それぞれで完結している内容になっていますので、好きな章から好きな順番でお楽しみください。
また、本書は、XFLAG スタジオにある技術的知⾒やアイデアを積極的に共有・公開していくことで、よりワクワクドキドキするようなプロダクトが世の中にもっともっと溢れだすことを願って刊⾏されています。掲載されている情報は、執筆者⾃⾝の環境で検証し執筆されたものですので、ご参考にされる際は、ご⾃⾝の責任で判断しご活⽤ください。ディベロッパーリレーションズチーム⼀同 ◆本書に関するお問い合わせ先 https://twitter.com/xflag_engineers ◆ XFLAG スタジオについて https://career.xflag.com/ ※ʠモンスターストライクʡ 、 ʠモンストʡ 、 ʠXFLAGʡ 、 ʠXFLAG ロゴʡ は、株式会社ミクシィの商標または登録商標です。また、各社の会社名、サービス及び製品の名称は、それぞれの所有する商標または登録商標です。 i

⽬次まえがき i 第 1 章本当にあった、モンスターストライクのギミック実装事例 1 1.1 始めに
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 友情コンボ「エナジーハート」 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 SS「パンドラボックス・クライシス」 . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 SS「フェイト・オブ・ザ・ゴッズ」 . . . . . . . . . . . . . . . . . . . . . . . . . 11 第 2 章明⽇から使える品質向上 Tips 集 15 2.1 始めに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 コミュニケーションについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 テストについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4 QA チームについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5 品質について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.6 終わりに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 第 3 章とある Unity 開発事例 25 3.1 始めに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2 MV(R)P アーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3 設計の⼀例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.4 Unity 開発におけるテストの導⼊ . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.5 最後に . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 第 4 章 git challenge を⽀える技術 47 4.1 git challenge とは何か . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2 問題の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.3 インフラの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4 スコアボード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.5 今後とまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 65 5.1 始めに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.2 今回作成したデモ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 iii

⽬次 5.3 オイラー⾓とクォータニオンとマトリックス . . . . . . .
. . . . . . . . . . . . . . 66 5.4 板野サーカスを⽬指す . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 第 6 章⾮同期処理の速度問題と解決の試案 79 6.1 問題の内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.2 解決試案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.3 検証環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.4 検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 著者紹介 93 iv

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.1 始めに本章は、モンストのギミックを実際に実装しているクライアントエンジニアの⾓⿓徳（かくたつのり） *1が、担当した案件の発⽣から実装完了までを⼤まかに紹介する章である。読もうとしていただ
けるのはありがたい限り！……なのだが、読み終わってから後悔することが少なくなるように、先にある程度の留意事項を記載しておこうと思う。 • モンストについて、ある程度プレイしたことある知識や経験が前提となる • 実装を担当したクライアントエンジニアの⽬線のみの話しかない • いろいろな都合で省略されているところがあり、期待している部分がないかもしれない • フランクな⽂章 • これはフィクションではないギミックはほとんどがゲーム性と密接に関わるので、ゲームそのものを知らないと理解が難しいかもしれない。無料で DL できるので実際に遊んでみるか、すでに遊んでいる友⼈に読ませて内容を伝えてもらうか、動画検索をして閲覧すると良いだろう。もっと詳しく話を聞きたいな、とか、気になったので質問してみたい、とかがあれば、おそらく巻末に載っているであろう SNS のアカウント宛てに聞いてほしい。 *1 ⽇本⼈ 1

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.2 友情コンボ「エナジーハート」 1.2 友情コンボ「エナジーハート」図 1.1:
オリーブ発端エナジーハートを実装しようと案件が来た時のことは⽐較的鮮明に覚えている。企画の⽅から「オリーブ*2を実装するから友情コンボに使うエナジーハートも実装したい」とギミック担当のクライアントチームに話が来たのだ。「オリーブってどんなキャラでしたっけ？」「どんな感じの挙動になるんです？」など雑談交じりに軽く確認していくと、要点は以下の 2 点だった。 • 基本は、すでに実装されているエナジーサークル*3に準拠する • 軌道が円環状ではなく、ハート型エナジーサークルについてはゲーム中に⾒たことあるぐらいの認識しかなかったが、オリーブの⾒た⽬が中々かわいかった*4ので、気付いた時には実装担当に⽴候補していた。 *2 3DS 版モンストに登場するキャラクタ *3 発動者を中⼼としたリング状にエネルギーを発⽣させ、敵にダメージを与える友情コンボ *4 それまでに実装したものは⼥の⼦に実装されなかった！ 2

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.2 友情コンボ「エナジーハート」図 1.2: エナジーサークル要件解析
エナジーハートはエナジーサークルの挙動に基本的に準拠するので、まずはエナジーサークルの仕様を知る必要がある。実際の挙動を眺めたり、コードを解析したり、周囲の⼈達から話を聞いたりして、以下のような挙動が分かってきた。 • 衝突判定⽤の円が、リングの形状を描くように移動している*5。 • 移動する衝突判定⽤の円は 2 つある。12 時から 6 時、6 時から 12 時にそれぞれ反時計周り。 *6 • 移動は毎フレーム更新されているリングの形状は三⾓関数を利⽤して算出されている。 x = r * cos θ y = r * sin θ これをハートの形状を描く関数に変えてやればいけそうだ。そんな関数があるのかと思うかもしれないが、数学は偉⼤なもので、調べてみると結構ある。 *5 敵も円形の衝突判定を持っていて、重なるとダメージを与える *6 移動開始付近の敵と移動終了付近の敵でダメージ発⽣のタイミングがズレてしまうので、その差を半分に抑える為 3

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.2 友情コンボ「エナジーハート」ハート⽅程式図 1.3: さまざまなハートの⽅程式*7
これらの関数を利⽤するだけでもそれらしいハートを形作ってくれる。これで問題解決といけば良いのだが、そうはいかない。実際のゲーム画⾯で表⽰されるハートはこれらの関数通りではなく、 VFX*8の⽅が⽤意するエフェクトに合わせないといけない。その為にはハートの軌跡を変更できるパラメータが必要になる。お察しの通り、そう簡単に関数ができあがるものではない。試⾏錯誤を繰り返している間に、 VFX から表⽰想定の共有があった。 *7 出典元 http://mathworld.wolfram.com/HeartCurve.html *8 平たく⾔うと、⾒た⽬の演出や表現を作る役職 4

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.2 友情コンボ「エナジーハート」図 1.4: VFX からの演出想定
これで形や⼤きさが分かった。もちろん、この想定とまったく同じにしないといけない、というわけではない。関数の作成に思った以上に⼿間どってちょっと焦っていたこともあって、演出に合わせるのが難しければ相談する、と前もって確認もしておいた。幸い別件がなかったので、ハート関数の作成に注⼒した。結果的に 3 ⽇ほどかかってしまったが、⼤きさや形をパラメータで制御できるハート関数を⽤意できた。図 1.5: ハート関数*9 A = ⼤きさ (調整可) B = ⾼さ係数 (調整可) P = 丸み係数 (調整可) θ = 底の⾓度 (調整可) T_MIN = 最低位相⾓ T_MAX = 最⼤位相⾓ t = 位相⾓ *9 出典元 http://www.geocities.jp/nyjp07/index_heart2.html 5

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.2 友情コンボ「エナジーハート」 i) [-π /2 !=
t かつ 3 π /2 != t] r = a * SQRT( (5 - 3 * SIN(t)) * (1 + SIN(t)) ) z = a * ASIN( a * (1-SIN(t)) * COS(t) / r) ※ [-π /2 ≦ z ≦ π /2] ii) [t = -π /2] r = 0; z = π /2; iii) [t = 3 π /2] r = 0; z = -π /2; f = -θ * z / PI() + PI()/2 x = r * COS(f) y = b * r * SIN(f) + p * ABS(x) 以上のコードは、実際に僕がコード内に残しているコメントで、この通りに実装がされている（はずだ）。単純なハート関数に⽐べて調整可能な値が多い為、VFX から共有された形に合わせることが⽐較的簡単だ。この処理を利⽤して、エナジーサークルをハート型に変えていこう。実装ハートの軌跡を描ければもう⼼配するものはない。早く実機で確認できる様に実装を急ぐ。表⽰できるようになったら VFX や企画の⽅に確認してもらう。ここで修正や調整が⼊ることも少なくないので、早めに⾒せておきたいところだ。今回の案件に関しては特に問題なかったが、普段は⾒た⽬の確認を優先する為に多少強引に書いたコードがあったり、パフォーマンスを無駄に落とす様な処理があったりするので、それらを直す。作成したハートの関数は、パラメータで制御しやすい反⾯、負荷は低くない。この負荷が実機でのプレイでも問題ないかどうかは、QA チーム*10に申し送りしておく。実装が完了したら、QA チェックに通して問題がないか確認が⾏われる。期待通りに機能するかどうかはもちろん、ゲームプレイ中の状況によっても不具合が浮き彫りになることも多い。モンストは⻑期に渡るプロダクトになっているので、思わぬケースで不都合が出て修正することも少なくない。いろいろ不具合が直ったら実装完了だ。リリースの時を待とう。リリース後リリースした後は数多くのユーザーの⼿によって実際に使⽤されることになり、実装担当者にとって喜ばしい瞬間を迎えることができる。SNS が当たり前のように使われる今⽇では感想をダイレクトに知る機会も多く、褒められた内容ならうれしくなってしまうのはしかたのないことだ。が、それだけではない。リリース後にも不具合が発⾒されることもある。不具合の内容、原因の究明、修正にかかる時間など、いろいろな要素から企画と相談して対応を決める。実装したのが⾃ *10 QA は品質保証を意味する「Quality Assurance」の略。今回の場合、エナジーハートが実際のプレイで発⽣するさまざまなケース、パターンでも問題なく使⽤できるかチェックする。些細なバグも露わにされるぞ！ありがとう！ 6

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.3 SS「パンドラボックス・クライシス」分だったかどうか忘れるくらい数ヵ⽉経ったころに⾒つかる不具合もあるぞ。そのころの⾃分がどんな思想でコードを組んだのかさっぱり忘れているので、どのような経緯があったのかしっかりコメントを残しておくと、未来の⾃分や他の誰かの⼤きな助けになる。修正を⼿早く終わらせて、みんながあっと驚く様なギミックの実装に時間を注ぎたいのは僕だけじゃないはずだ。
1.3 SS「パンドラボックス・クライシス」 *11 図 1.6: パンドラ（進化）発端これも企画から来た案件だ。仕様は以下の通りとなる。 • ショット⽅向の敵全員にそれぞれパンドラの箱を投げる • 箱は放物線を描いて着弾し、ダメージを与える • ダメージを与えた敵は複数の状態異常になる放物線は敵の位置で軌道が変わるのでコード側で処理する必要がありそうだが、すでにあるものを参考にすれば良い。状態異常の処理もすでにあるので、実装は然程難しくなさそうだ。既存の処理を参考にしたり合わせたりすることは⼤切で、同じことを実現するのに違う処理になっていると保守がたいへんになってしまうからだ。ちなみにこの時は、というよりたいていの場合はキャラ絵の作成も同時進⾏であることが多く、どのような容姿のキャラが使⽤するか分かっていない。オリーブの時のようにあらかじめ容姿が決まっていることの⽅が珍しいのだ。同じ気持ちを味わってもらおうと最後の⽅にキャラの絵を載せ *11 「SS」は「ストライクショット」の略語。僕はそのまま「えすえす」と呼称している。 7

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.3 SS「パンドラボックス・クライシス」ようと思ったが、僕だったら先に⾒てしまうので⼿間にならないよう先に載せておいた。せっかくなので実際に投げるパンドラの箱も載せておこう。図 1.7:
パンドラの箱放物線仕様から実装は難しくないと踏んでいたので⼼持ちラクだったが、既存の放物線の処理を確認している時にさっそく気になる部分を⾒つけてしまった。それは放物線軌道がフレーム単位で移動していたことだ。フレーム単位だと処理落ちが発⽣した時に軌道が違うものになってしまう。最終的な着弾位置は指定されているので⼤丈夫だが、ダメージの発⽣タイミングがズレてしまう。性能の違うさまざまな端末でプレイされるので、処理落ちは発⽣するものとして考慮しなければならない。修正⽅法は秒単位にすることだ。特別な解決⽅法ではなく、広く⼀般的に取られる⼿段だと思う。結局新しく作らないといけなくなった。放物線の軌道を描く処理を作ることになったので、どうすれば実現できるかを考える。放物線と聞いて思い浮かべたのは⼆次関数だったのでそれを使っている。ただ放物線を描くだけでは⽬標の場所に着弾しないので、考えた⽅法はまず敵の⽅向へ⼀直線に向かう移動量と、放物線の Y 座標成分を加算するものだった。さっそくできあがったコードを⾒てみよう。 // Y 座標に⼆次関数の変異を加算する // (-1, 0) と (1, 0) を通り、頂点が (0, H)、下に開いた関数を使う // 導出すると以下の通り。 // y = -H*x^2 + H // H は最⼤の⾼さになる。 // なお、定数から時間と距離が決まるので、速度も⼀意に決まる const f32 H = 290.0f; // ⾼さの最⼤ f32 dx = 2*t -1; // x の変異 [-1 ≦ x ≦ 1] f32 offsetY = -H * dx*dx + H; _pos._y += offsetY; *12 これも実際に僕がソースコードの中に記述したものを抜粋した。何秒後に着弾するか、最⼤の⾼さはどれくらいか、を指定できる。定数は、VFX の⽅を交じえて実際に⾒ながら良さそうな値に調 *12 f32 は ﬂoat 型のエイリアス 8

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.3 SS「パンドラボックス・クライシス」整していくのだ。着弾までの時間が遅ければ秒数を減らすだけで済むし、⾼さが低ければ値を増やすだけで反映できる。この放物線の処理は 1
つの⼿段に過ぎない。時間と⾼さが指定できる⽅が都合が良かったので今回の場合はこうなっただけだ。ガタガタ揺らす放物線挙動を実装して何度も試している内に、1 つ思いついたことがあった。パンドラの箱なら、ガタガタ揺れている⽅がそれっぽくなるのではないだろうか。具体的には回転⾓を± 30 度ぐらいで往復させるイメージだ。VFX の⽅に提案して OK をもらったのでさっそく組んでみることにする。この時の僕は短絡的に正弦波とか余弦波を使えば良いと思っていた。往復させる処理によく使われるものだが、箱を揺らす処理としては不適切であることに実装してから気付いた。往復する際に速度が落ちてしまうので、ガタガタというよりゆらゆらと揺れている印象が強くなってしまったのだ。これなら実装しない⽅が良いぐらいだ。動画でお⾒せしたいところだがそうもいかない。図 1.8: 正弦波、余弦波*13 サインやコサインはなだらかに変化するので、ギザギザに変化するものがあれば解決すると考えた。それが三⾓波だ。 *13 出典元 https://en.wikipedia.org/wiki/Sine_wave 9

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.3 SS「パンドラボックス・クライシス」図 1.9: 三⾓波*14 三⾓波の値を算出してくれる機能はないので作ることになる。作り⽅としては、まずノコギリ波
を作ってから、その半分を折り返すことで三⾓波を実現する。図 1.10: ノコギリ波*15 // 三⾓波を利⽤して回転させ、ガタガタ揺れているように⾒せる const f32 AMPLITUDE = 15.0f; // 波⻑。⾓度に⽐例する。⼤きいほど傾く。 const f32 FREQUENCY = 3.0f; // 周波数。振動数に⽐例する。⼤きいほど早く振動する f32 tri = _time * FREQUENCY - sn_floorf(_time * FREQUENCY); //< 0.0f ~ 1.0f (のこぎり波) // 0.5f 以上を折り返して三⾓波にする if (0.5f < tri) { tri = 1.0f - tri; } tri *= 2.0f; //< 0.0f ~ 1.0f tri -= 0.5f; //< -0.5 ~ 0.5 tri *= 2.0f; //< -1.0f ~ 1.0f f32 deg = tri * AMPLITUDE; *14 出典元 https://en.wikipedia.org/wiki/Triangle_wave *15 出典元 https://en.wikipedia.org/wiki/Sawtooth_wave 10

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.4 SS「フェイト・オブ・ザ・ゴッズ」 _sprite.setRotation(deg); これも実際に実装してあるコードの抜粋だ。調整可能な値として波⻑と周波数があるが、要は揺れる⾓度とその速さのこと。放物線軌道を描いているのであまりにゆっくりだと気付かれないし、かといって激しくして⾃⼰主張を強めても良くない。最終的な良き値は、VFX
の⽅と画⾯を⾒ながら少しずつ調整して決めていく。リリース後パンドラは⽐較的⼈気の⾼いキャラ*16で、ストライクショットも僕が想像していた以上に強いものだった。ユーザーの⼿元で⾒れる様になってから発⾒される不具合もあって悲しい思いもしたが、ストライクショットを使う度に「放物線、うまく実装できてるわ」とか「ガタガタ揺らすやつ提案して良かったな」とかうれしくも思っている。もしこのストライクショットを⾒る機会があれば、ダメージとか状態異常の結果のほかにも、ぜひ放物線やガタガタ揺れる動きを堪能してほしい。 1.4 SS「フェイト・オブ・ザ・ゴッズ」図 1.11: ラグナロク（神化）発端エナジーハートやパンドラボックスの様に、これも企画から作ってほしいとやってきた案件…… ではない！僕が同僚とモンストをプレイしながら興じる他愛のない話の中の⼀つが実装されたもの *16 出典元 https://www.monster-strike.com/news/20171018_1.html 11

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.4 SS「フェイト・オブ・ザ・ゴッズ」なのだ。そう、クライアントエンジニア側から提案したギミックが採⽤され、リリースされた事例の⼀つである。友⼈とゲームをプレイしている時の会話が、たいていの場合はくだらないが中々おもしろいものであることに⾝に覚えがある⽅も多いと思う。このギミックが発想された時の会話はこんなものだ。
•「ゲームで良く、⽳に落ちたら上から降ってくるのあるじゃないですか」 •「ありますね」 •「あれみたく、この（モンストの）壁を突き抜けて反対側に出てくるのってどうよ」 •「動きは楽しそうですけど使い勝⼿悪そう」 •「楽しいならええやろ！」こんなどうでもよい会話はほかにもたくさんある。ほとんどの場合は思い出になるだけだが、ギミック担当のクライアントエンジニアをしていると⾃分だけのリソースで「とりあえず組んで⾒て動きを⾒せる」ということが可能だ。⽇々の業務中に思いついたギミックの構想をメモしておきながら、⼿の空いた時間を狙って実装するのだ。当然、どのキャラが持つかなんて分からないので「壁貫通ループショット」という汎⽤的な技名を名付けておいた。後に、ラグナロクがこのストライクショットを使⽤するとは、この時の僕はまだ知らない。実装コーディングをする前に、仕様を決める必要がある。企画から上がってくる案件と違って仕様は⾃分で決めないといけないし、良くも悪くも期限がない*17。デタラメな仕様はもちろんダメなのだが、今回の場合はとってもシンプルだ。 • 壁にあたったら、反対側の壁から出てくる以上だ。これだけなので、実を⾔うとソースコードを掲載するほどの処理は記載していない。モンストは四⽅を壁に囲まれているので、上の壁に当たったら下の壁から出てくる、右の壁に当たったら左の壁から出てくる、逆も然り。それだけの処理なのだ。なので、もう少し細かく実装までのフローを紹介する。クライアントエンジニアは⾃分で実装できるがゆえに、サッと作って企画の⽅へ「こんなの作って⾒たんですけどどうでしょう」と実際に⾒せることができる。OK なら現在開発中のバージョンや、その次のバージョンで本格的に実装することになる。NG の場合は意⾒をもらいつつ、ああした⽅がいいんじゃないか、こうした⽅がいいんじゃないか、と試⾏錯誤を繰り返す。 OK でも NG でも考えるべき問題は残っていて、ほかのギミックやパターン、ケースとの兼ね合いである。壁にダメージウォール*18があったらどうなるか、反対側の壁にワープ*19があったらどうなるか、などを考慮して、現状の挙動を確認する。ほかのギミック案件でもそうだが、企画と相談 *17 ⼈間は守るモノがあると強くなれる。〆切とか。 *18 触れるとダメージを受けてしまう壁 *19 触れると吸い込まれて、別のワープのある位置に移動させられる 12

第 1 章本当にあった、モンスターストライクのギミック実装事例 1.4 SS「フェイト・オブ・ザ・ゴッズ」してどの挙動を仕様とするかを決めていく。ただ位置が変わるだけだと何が起きたのかプレイ中のユーザーに分かりづらいので、エフェクトを⼊れることになる。エフェクトといえば VFX
チームだ。VFX の⽅が作ったエフェクトを、位置が変わる前と後の場所に表⽰させるだけで済む。と思っていたが、キャラが⾼速に壁から壁を移動し続けるパターンがあり、エフェクトが出すぎてしまう問題があった。エフェクトが出すぎると処理落ちが酷くなるので、リングバッファを使って⼀定数以上表⽰する場合は古いものを消す処理が⼊っている。⼀定数というのは実際に使って⾒て感覚的に不⾃然さを感じづらい値にしている。すでに使ったことのある⽅はお気付きになられただろうか。 QA チェックももちろん⾏った。リリース後かくして、この「壁貫通ループショット」は実装された。しかし実装されたからといってすぐに使われるわけではない。事実、このストライクショットが使われたのは数ヵ⽉後で、⾃分も実装したことを忘れているころだった。新キャラとしてラグナロクが登場し、ストライクショットが「壁貫通ループショット」だったことを知った時はうれしいものだった。何せ初めて⾃分が発案し、⾃ら実装したストライクショットが世に出るのだから。余談だが、こんな経緯があるので、このストライクショットやそれを使っているラグナロクには思い⼊れが強い。 13

第 2 章明⽇から使える品質向上 Tips 集 2.1 始めにモンストの QA*1は、⽐較的スリムな体制で⾏われています*2。なぜ⼩さい規模で収まっているの
か考えてみたところ、QA チームと開発チームが良好な関係を築けているという点が⼤きいと思います。「良い関係性」という⼟台のおかげで、テストプロセスの改善が進み、テストが効率化されていき、短い QA スケジュールでも⼗分な品質を保ってプロダクトを世に出すことができています*3。私の章では、QA として、開発チームと良い関係性を構築し、品質の良いプロダクトを世に届けるために⼼がけていることを、つらつらと書いていきます。私⾃⾝プログラマーの経験もあるので、なるべくは、QA にもプログラマーにも有意義な内容になるように⼼がけました。難しい内容は何もなく、その気になれば、明⽇から試せるものばかりです。 Let’s Try！ 2.2 コミュニケーションについてミーティングをしよう開発チームと QA チームの間でテストについて、品質について、話し合う機会を設けていますか？極端なことを⾔うと、開発チームと QA チームで対話の機会がなくてもテストは可能です。ビルドを作り、QA チームに渡し、不具合管理システムを通してやりとりを⾏うことで、バグは取り除かれていくでしょう。しかし、質の良いテストをし、サービスの品質を向上させるためには、開発チームと QA チームで定期的にミーティングを⾏う必要があります。実は QA チームからは、開発チームに伝えたいことがたくさんあります。ツールの要望、セルフチェックを徹底してほしい*4、修正コメントの書き⽅、などなど。それらを⼀個⼀個解消していくこ *1 Quality Assurance の略。品質保証と訳されることが多い。⼤雑把に表現すると、開発前のプロダクトからバグを取り除くことと、そもそもバグを作りこませないことがお仕事です (個⼈の感想です。会社によって QA の役割には差があるように⾒受けられます) *2 他社の QA の⽅からも「思ったよりも少ない⼈数ですね」と⾔われることが多いです *3 また、ゲーム業界につきものの開発の佳境時期を、お互い笑顔で乗り切ることができるという副産物もあります *4 ⽴ち上げたら無条件でクラッシュする、などの発⾒が容易な不具合を減らすだけで、QA プロセスの効率はだいぶ変わります 15

第 2 章明⽇から使える品質向上 Tips 集 2.2 コミュニケーションについてとで、少ない時間で効率よくテストができるようになっていきます。そして、当然開発チームからも
QA チームに対して、⾔いたいことの 1 つや 2 つ、あるでしょう。バグ報告書の内容をもう少しちゃんとしてほしい、とか、なぜこんなにテスト期間が必要なのか、とか。こういった意⾒をお互いに伝えあうことで、効率の良いテストプロセスができあがっていきます。改善案もテキストでやりとりすればよいじゃないか、と思われるかもしれません。しかし、テキストベースのやりとりは誤解がつきもので、それがきっかけで関係性がこじれることも珍しくないので、他部署に対する意⾒を伝えるときは⼝頭が良いと思います。開発も QA も、ミーティング嫌いな⼈が多い職種ですので、まずは、⽉に 1 回、QA リーダーとメインプログラマーの 2 ⼈でミーティングを設定してみてはいかがでしょうか。それがうまく⾏ったら、もっと⼈を増やして⾏くと良いでしょう。ちなみに、モンスト開発チームでは、週に⼀回、メインプログラマー、メインプランナー、QA リーダーで、ミーティングを⾏っています。加えて、QA リーダーはメインプログラマーやメインプランナーと定期的に 1on1 も実施し、意⾒交換しています。顔を覚えよう (相⼿に直接会っておこう) 開発組織と QA 組織が違うオフィス (違う会社) にある、ということは珍しくありません。QA 担当者の名前は知っているけど顔は知らない、という状況で仕事をしたことがある⼈もいらっしゃるのではないでしょうか。チャットツールやクラウドツールの発達のおかげで、直接顔を合わせずとも業務ができる環境が整っています。ですが、そんな状況でも、開発と QA は、お互いがお互いの顔を知っていることがとても重要だと感じています。 QA からのコミュニケーションは、不具合報告と作業依頼*5が⼤部分を締めています。加えて割り込みだったりするので、開発者にとって QA からの連絡というのは、基本的には、あまり好ましくなかったりするのが実際のところでしょう。また、開発者に関しても、⼝下⼿な⽅が少なくないので、QA チームは開発者に対して過度に萎縮してしまうケースがあります。そのような状況ですので、「誰から⾔われているのか」ということは、結構、無視できない要素です。顔を知らない⼈間から、不具合報告とタスク依頼を受け続けたらイライラが募るでしょうし、顔を知らない⼈間から、素っ気ないコミュニケーションをされたら、萎縮するか腹が⽴つでしょう。私の事例としては、テレビ会議でお互いの⾃⼰紹介をしただけで、関係性が改善したこともあります。テスト部隊が外部の会社である場合も、⼀度、外部会社を訪れて 1 時間ほど懇親会をしただけで、その後の仕事が⾏い易くなった、ということがありました。お互いの顔をしっているだけで、⾔葉から受け取るネガティブな印象は、だいぶ緩和されます。ぜひとも、顔を覚えましょう。 *5 サーバを再起動してほしい、とか、指定のキャラクタを付与してほしい、とか 16

第 2 章明⽇から使える品質向上 Tips 集 2.2 コミュニケーションについて NO MORE
「全体的にテストして」たまにあるのが、「全体的に問題ないか⾒てほしい」という依頼です。この依頼が来たとき、QA チームには間違いなく、緊張感が⾛ります。全体を⾒て、さらに、問題がないことを保証する、というのは、事実上無理です*6。そのため、「全体的に⾒てほしい」という依頼の「全体」とはどこを指しているのか、その全体の中でも特に重要なことは何か、といったことをすり合わせる必要があり、それなりのコミュニケーションコストが掛かってしまいます*7。ただ本当に、全体を⾒る必要がある場合もあります。たとえば、OS や SDK をバージョンアップしたり、メモリ管理などの根幹部分を改修したときなどです。そのような場合は「全体を⾒てね」というのではなく、「1 名で 2 時間くらいユーザーが良く触れるところを触ってみて、挙動が重いとかレイアウトがおかしいとか、そのような違和感を感じたら報告してほしい」というように、なるべく具体的に依頼を出しましょう。可能であれば、テストの範囲をある程度指定する前項からの続きになりますが、たとえば、あなたが外来を受け持つ医者だったとして、以下の 2 つの患者のどちらが時間をかけずに正確な診断をくだせるでしょうか。 • 具合が悪いから診てほしい • お腹の調⼦が悪いから診てほしいおそらく後者になると思います。テストする範囲が抽象的であるほど、効率的・効果的なテストが難しくなるのも、これと同様です。テスト範囲の指定は、できる限り、具体的にしましょう。テキストのコミュニケーションは丁寧にやりましょうチャット中⼼の会社につとめて、10 年近く経ちますが、QA と開発者間のチャット上の揉め事を多く⾒てきました。そして、その原因の⼤半が、「⾔葉⾜らず」に起因しています。たとえば、たまに⾒かける開発者からの「◦◦の機能って、テストしたんですか？」という⼀⾔です。ここでちょっと考えてほしいのですが、上記のメッセージを受けた QA 組織は、どのような⾏動を取るでしょうか。 QA の⽴ち位置が開発よりも弱い場合*8、それなりの⾼確率で、「開発者が怒っている。もしかしたら、該当の機能で不具合が出ているのかもしれない。とりあえず不具合が出ているかどうかを確認して、⾃分たちに否がないかどうかを確かめよう」という⾏動に出ると予想します。 *6 無限の予算と時間があれば、もしかしたらできるかもしれませんが *7 そして、この⼿の依頼を出してくる⼈は、QA という仕事の性質を知らないことが多いので、タフなコミュニケーションになることも少なくありません *8 よくあるのが、QA 組織の多くが業務委託で構成されている場合などです 17

第 2 章明⽇から使える品質向上 Tips 集 2.3 テストについて⼀⽅、開発者は、ただ気軽に、「テストした？
機能を改修したいから、もしテストを開始していないのであれば、改修が終わるまで待ってほしい」と⾔いたかったのかもしれません。この場合、QA の取った⾏動は、まるごと無駄になります*9。無駄なコストをなくすためには、チャット上では、過不⾜のない情報を書くように⼼がけましょう。開発者と QA チームの環境の差異を意識しよう「⾃分の環境ではバグっていない」という開発者の⾔葉は、ときに QA チーム vs 開発チームのゴングになることがあります。仮に QA チームから共有された再現⼿順の通りに操作しても、不具合が再現しないときは、⾃分⾃⾝の確認環境を QA チームに伝えるようにしましょう。ビルドのバージョン、確認した OS の種類、サーバ環境（開発⽤とか staging とか）あたりを、QA に伝えることを忘れないようにしてください*10。 2.3 テストについて QA 担当者を早めにジョインさせる早くから QA 担当者を⼊れておくメリットは、プロダクトに「テスト容易性」という観点が追加されることです。テスト容易性とは、ゲーム開発の世界でいうなら、デバッグコマンドが充実していること、となるでしょうか。デバッグコマンドがあることで、テストは劇的に効率化されますが*11開発の終盤だとプログラムの構造が複雑になる事もあって、QA チームが望むようなデバッグコマンドを実装することが、難しくなるケースが少なくありません。ですので、開発フェーズの早い段階からテスト担当者を参加させ、プログラムに柔軟性が残っているタイミングでデバッグコマンドの要望をもらうと良いでしょう。ビルドの丸投げはやめましょう QA にとって⼼の折れる代表的な瞬間は何かというと、出社して最新のビルドをインストールして、さぁ、テストをするぞ！とやる気満々で起動した瞬間に、クラッシュしたときです。まったくテストを進めることができません。他には、不具合の修正対応がされたはずのビルドを確認したところ、まるで治っていなかったりだとか、A 機能を実装したのでテストしてくださいと連絡が来たのに、その A 機能が⼊っていなかったりとかする場合です。 *9 ⼤げさな例のように思われるかもしれませんが、ありがちな光景です *10 よくあるパターンは、QA は端末で確認し、開発者は PC のエミュレータ等で確認してた、とか。お互い確認しているサーバの環境が違う、とか *11 テスト費⽤も少なく抑えられる、ということでもあります 18

第 2 章明⽇から使える品質向上 Tips 集 2.3 テストについてこの⼿のことは、QA の時間を無駄にしてますし、開発関係者にとっても⼆度⼿間です。QA
にビルドを渡す際は、必ず⼀度は⾃分⾃⾝の⼿で問題ないかどうかを確認したうえで*12、渡すようにしましょう。直しやすいところからではなく重要度の⾼いところから治すゲームプログラマーをやってたころは、開発が佳境になり、不具合修正のタスクが増えてくると、とりあえず⽬に⾒えるタスクの数を減らすために、直しやすい不具合を優先して対応しがちでした。しかし、QA の⽴場になり、対応すべき不具合にも優先度がある、ということが⾒えてきました。まず、再現頻度の⾼いクラッシュバグは最優先で直しましょう。クラッシュすることでいろんな業務が⽌まるため、開発進捗に影響を及ぼします。また、ゲームの根幹を担う部分も早めに対応に取り掛かりましょう。たとえば、メモリ管理、描画、通信などです。これは、修正したときの影響範囲が広いため、修正後の再テストに時間がかかるためです。不具合を修正したあと QA チームに修正確認依頼を出す際は、何をどう直して影響範囲がどこまで及ぶのかを、伝えるようにしましょう。そうすることで、QA チームは修正された箇所だけでなく、関連するところもテストでき、「バグ修正をしたことによって新たに⽣まれるバグ」を防ぐことができます。また、不具合の原因と修正内容の詳細を書いておくことは、開発者⾃⾝のためにもなりますし、未来に類似の不具合が出たときの対応のヒントになることもあります。「修正しました」の⼀⾔だけで、QA チームに戻すのはもったいないと思います（急いでるときはしょうがないですが）。ツールを作ってあげましょうテストが効率的に進むようなツールを提供してあげましょう。ツールが充実しているチームは、そうでないチームと⽐べて、⽣産性は何倍も変わります。たとえば、ゲームのログインボーナスのテストをしているときは、サーバ時間を何度も書き換える必要があります。このとき、毎回 QA チームがサーバ側に依頼してサーバ時間を書き換えるのと、 QA チームがツールを⽤いて任意にサーバ時間を書き換えられるのとでは、QA チームにとっても開発者にとっても、効率は違うはずです。サポート系のツールを作ることは、なかなかモチベーションが上がりにくいかもしれませんが、地 *12 とりあえず動くかどうか軽くチェックすることを、ソフトウェアテストの世界では「スモークテスト」と呼んだりします。ハードウェアの世界から流れてきた⾔葉のようで、「スイッチ⼊れてみて、発⽕したり煙がでたりしないかどうかを確認する」といった意味合いです。スモークテストは、品質を上げ、QA コストを下げるのに、⾮常に効果があります 19

第 2 章明⽇から使える品質向上 Tips 集 2.3 テストについて道に確実に、品質とテスト効率を向上させます*13*14。ちなみに、私が最も感動したツールは、テストユーザー⼀⼈⼀⼈が、それぞれサーバ時間を設定で
きる、という機能です。同⼀環境で A というユーザーは 8 ⽉ 10 ⽇の AM10 時、B というユーザーは 9 ⽉ 30 ⽇の PM6 時みたいに設定できます。たいていは、サーバ時間はすべてのユーザーに影響するものですので、誰かがログインボーナスのテストをしているときは、期間限定のガチャのテストはできなかったりします。しかし、この機能のおかげで、時間が関係する機能のテストが並⾏にできるようになり、かなりの効率化が進みました。どれだけ些細な不具合でも、それを QA チームが⾒つけると、それなりのコストが掛かるたとえば誤字脱字のような、サクッと修正できる不具合であったとしても、テストフェーズで⾒つかった場合は、 1. QA チームが⾒つける 2. 不具合を起票する 3. 開発者が修正する 4. 修正版のビルドを作る 5. QA チームが修正確認するというプロセスを踏むことになり、トータルで 30 分くらい対応の時間が取られることになります*15。これが、テストプロセスの前であれば、 1. 該当箇所をセルフチェックする 2. 不具合を⾒つける 3. コードを修正するという、5 分程度の作業時間で済むかもしれません。些細な不具合も、積もり積もれば⼤きな⼯数となります。QA ⽤のビルドを QA チームに回す前に、今⼀度、⾃分の担当領域に不具合がないかどうかを確認する習慣をつけましょう*16。ある程度のバグは許容するとテストのコストは⼤幅にさがるかなり⼤雑把な感覚値ですが、バグを 80% 取り除くのに要した労⼒を 100 とすると、そこから 90% に持っていくまでの労⼒は 500 くらいになります。そして、99% を⽬指す場合は、労⼒は 1000 くらいになるでしょうか。 *13 テストツール開発者を、QA は陰で神として崇めています *14 最近は、QA エンジニアという、テスト環境を整備する職種も⽿にしますが、まだマイナーな印象 *15 どんな軽微な不具合でも最低 30 分の修正コストがかかる、ということです *16 「ビルドの丸投げはやめましょう」の項⽬も参照ください 20

第 2 章明⽇から使える品質向上 Tips 集 2.4 QA チームについて後半になるにつれて、発想が降りてくる時間が必要になるため、コストが急激に増⼤していきま
す。バグゼロを⽬指すあまりに、QA コストをかけすぎないように、注意が必要です。バグを⾒つけられるかどうかは、時間にほぼ⽐例する。たとえば将棋だと、1 分で考えた⼿と 1 時間で考えた⼿は、後者の⽅が有効である可能性が⾼いと思います。このとき⼤事なポイントは 2 つあって、時間をかけた⽅が有効である可能性が⾼いということと、かといって、必ずしも時間をかけた⽅が有効であるとは限らない、ということです。あくまで、統計的に時間をかけたほうが優れている傾向にある、というくらいにしか過ぎません。ソフトウェアテストにも同じことが⾔えます。時間をかければ、たいていの不具合を洗い出すことはできますが、しかし、時間を賭けたからと⾔って、⾒逃される不具合がゼロになるわけではありません。⾒逃された不具合というのは、再現に複雑な条件が必要になるものが多く、テストでそれを⾒つけるためには、論理的な思考というよりは、発想⼒が必要となる作業です。そして、発想が降りてくるかどうかは、与えられた時間に⽐例しますが仮に時間を無限にもらえたとしても、100% 発想が降りてくるわけではないことに注意が必要です。まとめると、テストで得られる品質は、時間を変数とした値ですので、テストの時間はなるべくたくさん確保しましょう。ただし、時間が⼗分にあったからといって、すべての不具合が⾒つかるとは限らないので、不具合が流出しても「あんなに時間があったのに、なにやってんだ？」と QA チームを責めるのではなく、なぜその条件が⾒つからなかったのかを、冷静に振り返りましょう。 2.4 QA チームについて QA チームが⼀番詳しい？スマートフォンゲームもリッチになり、複雑になってきています。そんな状況ですので、開発チーム内でゲーム全体の仕様を詳細に把握しているのは、もはや QA チームだけかもしれません。暗黙の仕様にも詳しかったりするので、ゲームの仕様に関して、何かわからないことがあれば、 QA チームに聞いて⾒ると良いでしょう。また、障害が起きやすいコンポーネントについても詳しかったりするので*17、機能改修のリスクを事前に知りたい場合も、QA チームから良い意⾒が聞けるかもしれません。 *17 「この機能に改修が⼊ったら要注意リスト」みたいのを、QA チームで持ってたりする 21

第 2 章明⽇から使える品質向上 Tips 集 2.4 QA チームについてゲーム内パラメータを公開しましょう
QA チームにゲーム内のパラメータを公開することをお勧めします。可能であれば、編集もできるようにしておいたほうが良いでしょう*18。テスターは、プログラムは書けなくても、パラメータの因果関係を理解することはできます。パラメータを理解することで⾼度なテストができますし、不具合の原因を⾒つけてくれることもあります。ちなみにモンストでは、テスターがほぼすべてのパラメータを操作することが許されています。そのおかげで、創造性のあるテストをすばやく⾏えるようになっています。そして、「思いついた⼿順をすばやく試せる」という環境が、テスターのモチベーション維持にも影響していると感じています。 QA チームとは問題を⾒つける部署ではなく、問題がない事を確認する部署であるこの意識の差はとても⼤きいです。恥ずかしながら、私⾃⾝、ゲームプログラマーをやってたころ、「バグは QA チームが⾒つけてくれるっしょ」という意識で仕事してました。その結果、⾃分担当の不具合チケットが 100 を超えたことがあり、ある⽇、QA リーダー、プロデューサー、メインプログラマー（つまり上司）に会議室に呼び出され、全員からいかに⾃分が品質の妨げになっているかを、⼩⼀時間説教されたことがあります。プログラマーやプランナーが、QA チームのことを「ミスを⾒つけてくれる組織」というふうに考えていると、品質は上がっていきません。凡ミスが原因の不具合チケットが⽬⽴つようであれば、 QA の役割を勘違いしている⼈がいる可能性が⾼いでしょう。 *19 QA チームの役割を定義するテストを始める前に、QA チームとミーティングを開き、QA チームに求める役割をすり合わせておきましょう。開発側とテスト側で、QA チームの役割の認識に相違があるシーンを結構⾒かけますし、それが原因でトラブルになることもあります。たとえば、 • テストケースをどこのチームが作るのか • テストにかかる予算を誰が決めるのか • バグさえ出してればよいのか、それとも、開発プロセスにも意⾒を求められているのか *18 編集が容易になるツールも提供できると、なお良しです *19 これは QA チームの課題でもあります。QA チームの役割を普通は知らなくて当たり前ですので、積極的に開発者やプランナーとコミュニケーションを取るべきでしょう。 22

第 2 章明⽇から使える品質向上 Tips 集 2.5 品質についてといったようなことは、事前に認識を合わせておかないとお互いに不幸な結果となります。認識の相違がどこから起こるのかというと、会社によって
QA チームの役割が異なるため、「以前、⾃分が所属した会社ではこうだった」という思い込みからきていることが多いようです。 2.5 品質について品質を定義しよう品質とはとても抽象的な⾔葉です。そのため、「良い品質を⽬指す」と⼀⼝に⾔っても、⼈それぞれ思い描いているものがバラバラだったりします。たとえば、挙動が軽いこと、ゲームとしておもしろいこと、不具合が少ないこと、いずれも「良い品質」として定義できます。ですので、議論の際に「品質を⾼めたい」という⾔葉が出てきたら、「それってつまりどういうこと？」と、ちゃんと確認するようにしましょう。「良い品質」というのは、「性格の良い⼈」と同じくらい、ふんわりした⾔葉ですので、使うときは注意が必要です。品質は何で決まるのか品質とは、何で決まるのでしょうか。f(X) = Quality とするなら、変数 X は何なのか。 QA という職種は、いろんなチームを⾒ることができます。良い品質を提供するチームも、そうでないチームも、たくさん⾒ます。おそらく、プログラマーやプランナーの何倍も、チームを⾒てきているでしょう*20。私個⼈の考えとしては、X は「開発に関わっているすべての⼈（の品質に対する意識）」と思っています。ツールや採⽤技術や開発フローとかも当然⼤事なのですが、それは枝葉で、結局は「⼈」なんじゃないかなと。品質を上げるために、レビューのプロセスを強化したり、⾼価な UI ⾃動テストツールや静的解析ツールを導⼊することがあるかもしれません。しかし、何のためにそれらを導⼊しているのかを開発メンバーが理解していないと、いずれ形骸化し、品質は思ったように上がっていきません。品質を⾼めるためには、品質への意識が⾼い⼈を採⽤するか、開発に関わるメンバーの品質への意識を⾼めるしか⽅法はない気がしています。品質向上の取り組みをやるのなら、このことを軸に添えていないと、何をやったとしても「仏像作って魂込めず」という状況になりがちです。⼩医は病を癒し、中医は⼈を癒し、⼤医は国を癒す中国のことわざだそうです。QA にも同じことが⾔えると思います。バグを⾒つけるのが仕事の中⼼であるうちは、まだスタートライン。バグを作り込ませないよう *20 私も 30〜40 チームくらいは⾒てきたでしょうか 23

第 2 章明⽇から使える品質向上 Tips 集 2.6 終わりにな働きかけができて、道半ば。関係者全員が品質に対して正しい考え⽅を持つことができれば、ようやくゴール。
どうすれば⼤医になれるのか、いつも考えています。もし⼤医の領域までたどり着けたのであれば、もはや、その組織には QA チームは必要ないかもしれません*21。バグを憎んで⼈を憎まず開発スケジュールの後期に深刻なバグが出たときや、サービスリリース後に不具合が流出してしまったときは、プロセスの改善やチームメンバーの品質への意識を⾼める材料として扱いましょう。なぜそれが作り込まれたのか、今後、同種のバグが作り込まれないためにはどうしたらよいのか。なぜそれがテストフェーズで⾒つけきれなかったのか、⾒つけるためにはどうしたらよかったのか。チームの問題を振り返る良いきっかけになります。このとき、特定のプログラマーや QA スタッフを個⼈攻撃するのは効果的ではありません。不具合の理由は、たいてい、複数の理由が組み合わさっているので、特定の誰かを⼀⽅的に責めて改善するものではありません*22。個⼈の課題ではなく、チームの課題として、取り組むべき内容です。反省することは⼤切ですが、犯⼈探しに熱中しないようにしましょう。 2.6 終わりに読んでいただき、ありがとうございました。QA の⽴場から、開発やプランナーやプロデューサーに知っておいてほしいな、という内容を書いたつもりです。品質を⾼めるには、関係者全員が品質に関⼼を持ち、QA チームを正しく効果的に使うことが⼤切です。その第⼀歩を、明⽇から踏み出してみませんか？ *21 もしかするとクビになるかもしれませんが、ほかの会社が⾼待遇で雇ってくれるはずなので⼼配しなくてよいでしょう *22 不具合が⾒つけきれなかったことを理由に、QA チームを過剰に攻め⽴てると、QA チームはどんどん保守的になっていきます。⾔い訳がましくなり、「品質を上げる」というよりは、怒られないことに時間を使い始めます 24

第 3 章とある Unity 開発事例 3.1 始めに昨今の Unity
開発では MVP や MVVM、または MV(R)P などのソフトウェアアーキテクチャを導⼊することが増えてきました。ここに上げたアーキテクチャは最低限のルールを提⽰していますが細かい役割の切り出し⽅はチームに委ねるため、どう設計していくか頭を抱えることも多いでしょう。筆者も悩み、Web 上で具体的な事例を探しましたが中々⾒つけることができませんでした。本章では、筆者が実際に業務で MV(R)P を導⼊した事例、またテストを含んだ開発事例を紹介します。 3.2 MV(R)P アーキテクチャアーキテクチャがなぜ必要か複数⼈での開発、運⽤にはつらくならない設計が必要です。ここで⾔うつらい設計とはどういうものでしょう。たとえば筆者は次のように考えます。 • ⼀つのクラスの責務が⼤きい • どこに何が置かれるべきか定まっていないこれらは複数⼈で開発していくと⼤きな問題となり開発速度を著しく下げる危険性があります。前者は UI とロジックなどが密結合だったりと関⼼の分離ができていないことから発⽣する問題です。後者はきちんとルールを明⽰しないことによる問題です。ルールがないと⼈々は⾃分の持っているノウハウから⾏動しがちで、さらにちぐはぐなプロダクトになってしまいます。実際の開発でそこまで凄惨なことにはならないと思います。どのプロダクトもまずは基本的に開発ルールと全体設計を決めるでしょう。それがソフトウェアアーキテクチャです。各プロダクトごとに特化したアーキテクチャを設計していると思います。たとえば STG では弾幕を出すために⼤量のデータをさばく必要があるので、パフォーマンスを重視したデータ指向設計なアーキテクチャを⽬指したりなど。また、MVC や MVP など、先⼈たちが築き上げたアーキテクチャを採⽤するのも良いでしょう。 25

第 3 章とある Unity 開発事例 3.2 MV(R)P アーキテクチャアーキテクチャを導⼊するにあたって重視すべきはなんでしょうか。筆者は次の
2 点だと考えています。 • 作りたいアプリケーションに向いているか • 学習しやすいかまずは作りたいものの内容とマッチしているかは最重要だと考えます。こうなってくるとその都度特化したアーキテクチャを設計するのが正解のように思えてきますが、それらはかなりのコストがかかります。また、チームメンバーが学びやすいかという点も重要です。社内ドキュメントを充実させれば可能ではありますがこれもまた⼤きなコストです。世に存在する既存のアーキテクチャを採⽤した場合、調べれば理論や考察記事などが公開されているのでいくぶんか楽です。とはいえ、アプリケーションの性質を理解しないまま「流⾏っているから」と採⽤するとまったく良いことはないので、しっかりと時間かけた選定を⾏うことをお勧めします。特にゲームは要件によって求められることがあまりにも違うのでうまく適合できない可能性は⾼いです。 MVP アーキテクチャについて本章で説明するプロダクトでは MV(R)P アーキテクチャを採⽤しています。MV(R)P の説明を⾏うまえに、その前⾝となる MVP アーキテクチャについて説明します。 MVP アーキテクチャは各コードの責務を Model-View-Presenter に切り分ける設計です。図 3.1: MVP アーキテクチャそれぞれのレイヤは以下の役割を持ちます。 Model Model 層はいわゆるビジネスロジックを内包します。ビジネスロジックはデータを取ってきたり何かの計算をしたりなど多岐に渡るため、Model という名前だけで分別することは難しいです。実際導⼊する場合は Model 層の中でさらに役割で名前を切ることが多いです。たとえばデータを取ってきたり更新したりするインタフェースを Repository と名付けたり、実際のデータの保存先である API やローカルストレージなどに具体的なアクセスを⾏うクラスを DataSource と名付けたりとさ 26

第 3 章とある Unity 開発事例 3.2 MV(R)P アーキテクチャまざまな実装⽅法があります。
Model は View と Presenter の存在を知りません。 View ユーザーに表⽰する画⾯や⼊⼒を受け付ける処理がここに該当します。ユーザーのインプットを受け付け、何らかの処理が⾛って画⾯に表⽰する、というのが基本的な動きになります。Model に依存してはいますが、直接 Model 層にアクセスすることはなく、後述の Presenter に処理を委譲しています。 Presenter Model と View の間を取り持つ層です。View のイベントを受け取り Model を操作する、または Model の変更を受け取り View に変更を通知します。View と Model の橋渡しとしての存在ですので、Presenter にビジネスロジックはあまり含みません。Model のメソッドを呼ぶ、View のメソッドを呼ぶ、くらいにとどめておくのが望ましいです。 Unity における MVP たとえば、アイテムの表⽰と、クリックしたらアイテムを⼀つ消費する、といった機能を実装するとき MVP で分割して書くと以下のようになります。 public interface IItemView { void ShowItem(Item item); } public class ItemView : MonoBehavior, IItemView, IPointerClickHandler { public int itemId; private ItemPresenter _presenter; public Text _itemName, _itemCount; void Start() { _presenter = new ItemPresenter(this); _presenter.FetchItem(itemId); } public void ShowItem(Item item) { _itemName.Text = item.Name; _itemCount.Text = item.Count.ToString(); } public void OnPointerClick(PointerEventData eventData) { _presenter.UseItem(1); } } 27

第 3 章とある Unity 開発事例 3.2 MV(R)P アーキテクチャ public
class ItemPresenter { private IItemView _view; private Item _model; public ItemPresenter(IItemView view) { _view = view; } public void FetchItem(int itemId) { _model = Item.GetById(itemId); _view.ShowItem(_model); } public void UseItem(int useCount) { var callback = item => _view.ShowItem(item); ItemApi.Request(_model, useCount, callback); } } アイテムを表⽰、⼊⼒を受け付ける部分を ItemView に任せ、アイテムのデータ取得、更新は ItemPresenter に委譲しています。ItemPresenter は具体的なロジックを持たず、ItemModel から取得して結果を ItemView に渡したり、ItemApi を使ったサーバとの通信の結果を View に返しています。 Presenter は具体的な View を知らずに IItemView というインタフェースに依存しています。つまり Presenter は View を知ってはいるが、MonoBehavior は知りません。このやり⽅の良いところは Presenter の EditModeTest が書けるという点です。EditModeTest では MonoBehavior を扱うことができませんが、IItemView を実装したモッククラスを⽤意することで Presenter の挙動をテストできます。 Unity において MVP アーキテクチャを採⽤する場合、MonoBehavior がどのレイヤに相当するのかというところを考える必要があります。View はユーザーに表⽰する役割を持つため MonoBehavior を継承して問題はないでしょう。Model は⼊⼒の受け付けや表⽰とは遠い世界にいるので継承する必要はないでしょう。Presenter が継承しているかどうかはケースバイケースです。今回の⼀例では PureClass として定義することでテスタブルになるメリットがありましたが、 Text ⼀つを操作したり画像を 1 枚表⽰するだけでも必ず View のインタフェースと実体の実装が必要であったりと、若⼲⼿軽さを失うデメリットもあります。ですので Presenter が MonoBehavior を継承することで Button や Text などの View を直接参照する⽅法も有効です。こちらの場合は Presenter のテストが⾏いづらくなるのでどちらが良いかは作りたいものに合わせて判断すると良いでしょう。 MV(R)P アーキテクチャこの MVP から派⽣して @neuecc さんが提唱したのが Model-View-(Reactive)Presenter、 MV(R)P アーキテクチャです。 28

第 3 章とある Unity 開発事例 3.2 MV(R)P アーキテクチャ図
3.2: MV(R)P アーキテクチャ基本の考え⽅は MVP と同様ですが、Presenter が View と Model を取り持つ⽅法が変わります。 UniRx を⽤いて View の変更と Model の変更を Observable で購読できるようにしています。先ほどのアイテムの例だと次のように表せます。 public class ItemView : MonoBehavior { public Text _itemName, _itemCount; public void ShowItem(Item item) { _itemName.Text = item.Name; _itemCount.Text = item.Count.ToString(); } } public class ItemPresenter : MonoBehavior { public int itemId; private ItemView _view; private ReactiveProperty<Item> _model = new ReactiveProperty<Item>(); void Start() { 29

第 3 章とある Unity 開発事例 3.3 設計の⼀例 // View
のイベントを購読してモデルを更新する _view.OnClickAsObservavle() .SelectMany(_ => ItemApi.Request(_model, 1)) .Subscribe(newModel => _model = newModel); // モデルのイベントを購読して View を更新する _model.Subscribe(view.ShowItem); _model.value = Item.GetById(itemId); } } View は Presenter を知らず、イベントを流すだけの存在です。Presenter は Model と View のデータのやりとりを Reactive につなぐだけです。 3.3 設計の⼀例現在進⾏中のゲームタイトルの開発では MV(R)P を採⽤しています。 View View は MV(R)P の思想と同じで、毎回必ず作るのではなく必要であれば View クラスを作る、くらいの塩梅で定義しています。具体的に⾔うと画像を１枚表⽰する、テキストを１つ表⽰する、くらいの規模であれば View クラスは定義せず、Presenter が Text や Image を直接参照するようにしています。ですので、画⾯数に対して View はそこまで数が増えていない状況です。独⾃ View を定義するときは、Text や Image など個々の要素は外部に公開せず、必ず各イベント通知を IObservable にして公開しています。 Presenter Presenter も MV(R)P の思想をそのまま適⽤しています。基本的には View の IObservable を購読して Model を操作し、Model の IObservable を購読して View を操作するという役割のみですが、ストリームが複雑化しないような注意は必要です。たとえば View から送られてくるデータが Model を操作するのに適切でないので Select で変換したくなったり、特定の条件だけ欲しくて Where でフィルタリングしたくなったりという状況はありがちですが、それらをすべてオペレータに直書きしてしまうと可読性が下がる懸念があります。1 ⾏ラムダ式が追加される分にはまだそこまで気になりませんが、もしオペレータが膨れ上がりそうな兆候を感じたら、変換処理を別の Model に切り出したり⼊⼒を検証する Validation クラスを⽤意したりなど、各責務を逃してあげた⽅が将来的に幸せになります。もともと Presenter は肥⼤化しがちなのでここはコードレビューで補っていくのが良いでしょう。 30

第 3 章とある Unity 開発事例 3.3 設計の⼀例 Model Model
層以下は最低限の分割を⾏っています。 • Entity • Repository • UseCase • Factory Entity Entity の定義はさまざまですが、プロダクトでの Entity の定義は「ロジックを持たないデータを保持する役割のクラス」としています。たとえば通信のレスポンスを格納するクラス、マスタデータの値を保持するクラスなどです。Entity はあくまでデータと構造を保持するだけですので、そこにコンテキストは含まれていません。たとえば⼀般的な RPG のキャラクタのデータを保持する Entity は以下のようになります。 public class CharacterEntity { public int id; // キャラクタ ID public string name; // 名前 public int level; // レベル public int hp; // ヒットポイント public int mp; // 必殺技ポイント的な public int attack; // 攻撃⼒ public int defence; // 防御⼒ public int exp; // 経験値 } これらはキャラクタの詳細を⾒る画⾯ではすべて必要不可⽋なパラメータです。しかし、所有キャラ⼀覧を⾒るような画⾯などではここまで詳細な情報は不要かもしれません。プロダクトでの Entity はただのデータを保持するだけに過ぎず、それをどう使うのかというコンテキストは含めません。コンテキストを含めたクラスは次のコードのようにそれぞれ定義します。 // キャラクタ詳細を持つモデル public class CharacterDetail { private CharacterEntity _entity; public string name => _entity.name public int level => _entity.level public int hp => _entity.hp public int mp => _entity.mp 31

第 3 章とある Unity 開発事例 3.3 設計の⼀例 public int
attack => _entity.attack public int defence => _entity.defence public int exp => _entity.exp public int nextLevelUpExp => /* _entity.exp で計算したやつ */ } // キャラクタ⼀覧の要素を持つモデル public class CharacterListContent { private CharacterEntity _entity; public string name => _entity.name public int level => _entity.level } Presenter、View の世界に Entity が漏れ出すことはありません。Model 層の外には上記のようにどのような使われ⽅をするかというコンテキストを持ったクラスを返します。例で上げたコードだけ⾒ると、CharacterDetail は CharacterListContent が持つ要素をすべて内包しているのでわざわざ分けるのは無駄なのでは、と⾒えるかもしれません。しかしこれらはドメインが異なるのでコードの修正理由が⼤きく変わってきます。たとえばキャラ⼀覧画⾯では、詳細画⾯では使うことのない⼩さいキャラアイコンを使いたくなるかもしれません。その際にクラスが同じでは詳細画⾯まで影響を受けてしまう恐れがあります。クラスの共通化は変更理由を考えた上で⾏うべきです。 Repository Repository は、Entity の保持、操作を⽬的としたクラスです。次のコードは CharacterEntity を保持する Repository です。 public interface ICharacterRepository { CharacterEntity GetById(int id); void AddCharacter(CharacterEntity newCharacter); } public class CharacterRepository { private List<CharacterEntity> _entities; public CharacterRepository(ILoader loader){ _entities = loader.Load<CharacterEntity>(); } public CharacterEntity GetById(int id) { return _entities.FirstOrDefault(c => c.id == id); } public void AddCharacter(CharacterEntity newCharacter) { _entities.Add(newCharacter); } } 例では Entity ⼀覧を保持し、取得したり追加したりしてます。また、キャッシュの役割も担って 32

第 3 章とある Unity 開発事例 3.3 設計の⼀例います。⼀般的に定義されている Repository
は次のようなものです。 • どこにデータが永続化されているか知っている • Repository の利⽤者側にはデータの永続化先を教えないたとえばこの CharacterEntity のデータがローカルに保存されているとしたらこの Repository はローカルストレージにアクセスする処理が書かれるし、外部に保存されているとしたら API サーバと通信を⾏うでしょう。そして Repository を呼び出す側は保存先を知ることなく追加したり取得したりできます。しかし、本プロダクトでの Repository は外部保存先を知らず、オンメモリ上での保存・更新のみを役割としています。API 設計との兼ね合いが理由です。⾮ゲームでない通常の Web アプリケーションやスマートフォンアプリでは RESTful な設計がスタンダードです。ゲームで⾔うところの Character というリソースを単体で CRUD 可能な設計です。ですのでリソース単位での Repository 分割は API の設計と同じであり、⾮常に相性が良いと⾔えるでしょう。しかし、スマートフォンゲームではやや事情が異なり、ゲーム中での通信回数を極⼒減らす⽂化が⾒られます。キャラクタ⼀覧画⾯に⾏くたびに 100 体のキャラクタ情報を API から取ってきたり、クエスト画⾯に⾏くたびに数百を超えるクエスト情報の通信が発⽣すると快適さを損なうからです。できれば最初にすべて保持してそれらを使いまわしたくなります。それでも、クエストをクリアしたときや、キャラクタを強化したなどゲーム中に通信が⾏われるのは避けられません。たとえばクエストをクリアしたときという例で考えてみます。クエストをクリアしたときの仕様は次の通りです。 • クエスト報酬アイテムがもらえる • 次のクエスト情報が出てくる QuestRepository から次のクエスト情報を Get して、そのあとクエスト報酬アイテムも Item- Repository から Get するということは可能ですが、それでは通信が⼆回⾛ってしまいます。通信回数を減らしたいのであれば、クエストクリア時の API のレスポンスに報酬アイテムと次のクエスト情報を含めたりするのが無難です。そうなってきた場合、Repository と API のリソースが 1 対 1 の関係性を保つことが難しくなってきます。しかしここで親の Repository を作って QuestRepository と ItemRepository を操作させるのは組み合わせが凄まじいことになり複雑化してしまいます。それぞれの Entity を保持する存在は必要だが、リソースを保持する側の都合をあまり考慮したくなかったという背景から、プロダクトでの Repository はオンメモリ上での保持や更新の役割に抑えて、通信の事情は後述の UseCase に任せるという⽅針になっています。 UseCase UseCase はビジネスロジックを内包したクラスです。かなり具体的なドメインを含んでいるのが特徴です。たとえば次のコードはキャラクタの名前変更を⾏う UseCase です。 33

第 3 章とある Unity 開発事例 3.3 設計の⼀例 public class
ChangeCharacterNameUseCase { private IApiClient _apiClient; private ICharacterRepository _repository; public ChangeUserNameUseCase(IApiClient client, ICharacterRepository repository) { _apiClient = client; _repository = repository; } public async Task<bool> Run(int characterId, string newName) { var entity = _repository.GetById(characterId); var response = await _apiClient.ChangeNameRequest(_entity, newName); if(response.IsSuccess) { _repository.UpdateCharacterName(_entity, newName); return true; } else { return false; } } } public class CharacterNamePresenter : MonoBehavior { private Text _characterName; private InputField _newNameField; public int characterId; public void Initialize(IApiClient client, ICharacterRepository repository) { _newNameField.OnEndEditAsObservable() .Subscribe(async newName => { var useCase = new ChangeCharacterNameUseCase(client, repository); if(useCase.Run(characterId, newName)) { _characterName.Text = newName; } else { // 失敗ダイアログなど } }); } } UseCase は名前変更のためにリソース取得、通信、リソースの更新など必要な処理をすべて内包しており、Presenter は Run(newName) を呼ぶだけですべて解決するようなインタフェースになっています。Presenter が Model 層にアクセスするときは、直接 Repository や Entity を参照させず、すべて UseCase を通してアクセスするようにしています。ですので UseCase は Facade パターンに近い役割とも⾔えるでしょう。 34

第 3 章とある Unity 開発事例 3.3 設計の⼀例図 3.3:
Presenter から UseCase を処理するフローの⼀例プロダクトにおける UseCase は以下の⽅針で実装されています。 • 使いまわさない • 処理は１つのみ Presenter の受け⼝となるため、UseCase はキャラ詳細を表⽰する画⾯、名前を変更する画⾯、クエストを選択する画⾯など、「何をしたいのか」という情報が多分に含まれます。なので⼀つの UseCase を再利⽤するということは、まったく同じコンテキストが複数ヵ所に存在するということです。現実的には場所が違えばコンテキストは微妙に異なるし、もしまったく同じならそれは Prefab 単位で共通化されるでしょう。すなわち UseCase は常に同じ Presenter から呼ばれること 35

第 3 章とある Unity 開発事例 3.3 設計の⼀例を想定すべきです。そのような理由から、UseCase は絶対に使いまわさない⽅針で実装しています。
もしロジックが同じであればそれは UseCase よりも下の階層でクラスを共通化します。また、コンテキストが常に同じということは具体的に役割が決まっているので処理は１つのみとしています。ChracterUseCase.ChangeName というようにスコープを広げることはしません。クラス名からできることがすべて伝わるのと、単⼀処理ですので依存関係が最低限で済み、テストコードを書きやすいのがメリットです。ただし、ファイル数がかなり膨れ上がってしまうのがデメリットです。 Zenject の併⽤私の開発チームでは Zenject*1を利⽤した DI*2を⾏っています。 DI についてはあまり特殊なことはしていませんが、数点やったことだけ説明します。 Model 層では Zenject を臭わせないフィールドインジェクション、メソッドインジェクションはたいへん便利ですが、Inject 属性を付けるとそれは Zenject に依存することになってしまいます。Zenject を使っているのでおかしいことではありませんが、private なメンバー変数にフィールドインジェクションを使っているため⼿でインスタンスを作ることができないという状況は好ましくありません。Model 層はすべて PureClass なのでコンストラクタを呼ぶことができます。よほど特別な理由がなければコンストラクタで渡すべきでしょう。 public class BadPureClass { [Inject] private Foo _foo; // Zenject が無いと Foo を渡せない！ } public class GoodPureClass { private Foo _foo; public GoodPureClass(Foo foo) { _foo = foo; } } 同様に、DiContanier を PureClass に渡すのも極⼒避けるべきです。Resolve できて便利ではありますがそれはサービスロケータパターンとなり、Conainer そのものへの依存が発⽣します。メソッドインジェクションや Container を渡すのは MonoBehavior を継承している Presenter、View の層までに抑えておくのが無難でしょう。ただし、後述の Zenject Factory を使っているので完全に Zenject が存在しないわけではありません。これは Model そのものが依存しているわけではないので許容範囲と考えています。 *1 Unity で DI を⾏うためのライブラリです。https://github.com/svermeulen/Zenject *2 Dependency injection(依存性の注⼊) の略で、外部から依存するオブジェクトを注⼊するデザインパターンです。 36

第 3 章とある Unity 開発事例 3.3 設計の⼀例 Repository の
Bind Repository は性質上どこの画⾯でも利⽤される可能性があったので、シーンだけにバインドするということができませんでした。この問題は、現状は ProjectContext の Container に Bind することで対応しています。 public class MasterRepositoryInstaller : Installer<MasterRepositoryInstaller> { public override InstallBinding() { Container.Bind<IMasterDataLoader>().To<MasterDataLoader>().AsCached(); Container.Bind<IMasterFooRepository>().To<MasterFooRepository>().AsCached(); Container.Bind<IMasterBarRepository>().To<MasterBarRepository>().AsCached(); } public void UnInstall() { Container.SafeUnBind<IMasterFooRepository>(); Container.SafeUnBind<IMasterBarRepository>(); } } 任意のタイミングで上記の MasterRepositoryInstaller を ProjectContext の Container に Install しています。Installer として切り出しているのでテストを書いたり、インストール先を切り替えたりできます。どこでもアクセスできるので利便性は⾼い反⾯、グローバルに展開しているので保守性の⾯で不安が残ります。現状問題は起きていませんが規模が⼤きくなった時の対応が必要そうです。ちなみに、 UnBind メソッドはバインドされていなかった場合例外を出すので、 HasBinding<T>() で確認する必要があります。ですので、拡張メソッドを定義しておくと少し楽になるのでお勧めです。 public static class ZenjectExtensions { /// <summary> /// Bind されているかチェックして UnBind する。Bind されてない場合は何もしない /// </summary> /// <typeparam name="T"></typeparam> /// <param name="self"></param> /// <returns></returns> public static bool SafeUnbind<T>(this DiContainer self) { if (self.HasBinding<T>()) { return self.Unbind<T>(); } return true; } } 37

第 3 章とある Unity 開発事例 3.3 設計の⼀例 UseCase は
Zenject Factory で⽣成する動的に⽣成したインスタンス、GameObject に Inject したい場合は Zenject Factory を使います。次のコードでは、名前変更する UseCase を Factory で⽣成しています。 public class ChangeCharacterNameUseCase { private IApiClient _apiClient; private ICharacterRepository _repository; public ChangeUserNameUseCase(IApiClient client, ICharacterRepository repository) { _apiClient = client; _repository = repository; } public async Task<bool> Run(int characterId, string newName) { var entity = _repository.GetById(characterId); var response = await _apiClient.ChangeNameRequest(_entity, newName); if(response.IsSuccess) { _repository.UpdateCharacterName(_entity, newName); return true; } else { return false; } } class Factory : PlaceholderFacotry<ChangeCharacterNameUseCase> { } } public class CharacterNamePresenter : MonoBehavior { private Text _characterName; private InputField _newNameField; public int characterId; public void Initialize(ChangeCharacterNameUseCase.Factory useCaseFactory) { _newNameField.OnEndEditAsObservable() .Subscribe(async newName => { var useCase = useCaseFactory.Create(); if(useCase.Run(characterId, newName)) { _characterName.Text = newName; } else { // 失敗ダイアログなど } }); } } public class FooSceneInstaller : MonoInsaller<FooSceneInstaller> { public override InstallBinding() { Container.BindFactory<ChangeCharacterNameUseCase, ChangeCharacterNameUseCase.Factory>(); } 38

第 3 章とある Unity 開発事例 3.4 Unity 開発におけるテストの導⼊ }
Factory 経由でインスタンスを作るので、Presenter は UseCase が依存しているオブジェクトをほとんど知る必要がありません。ですので UseCase を⽣成するために依存オブジェクトを持つということはなくなります。仮に内部実装に変更があっても Presenter が影響を受けにくくなります。また、Installer にはこのシーンで⾏われるすべての UseCase が Bind されることになるので、 Installer を⾒ればこのシーンで⾏われる処理がすべてわかります。これは地味にうれしいです。プロダクトでは Instantiate などもできる限り Factory で⾏うような⽅針です。コンストラクタを呼ぶ、もしくは⾃前の Initialize メソッドを呼ぶということは⽣成したオブジェクトの依存関係を理解する必要があるため、依存関係解決のためのオブジェクトを⼿で引っ張りまわすことになります。それらはすべて Container に任せてしまい、各クラスは⾃分の責務のコードだけを書くようにしていければ複雑性を減らせるのではないかと考えています。また、Zenject Factory に対応していれば今後パフォーマンスチューニングが必要になった段階で Zenject MemoryPool への移⾏が簡単にできるというのもメリットです。 3.4 Unity 開発におけるテストの導⼊私の開発チームではユニットテスト、UI テストを書くようにしています。なぜテストコードを導⼊するのか往々にしてプロダクトの要件は常に変化します。⼀ヵ⽉前の仕様が変わることも珍しいことではありません。仕様が変わればコードの修正は必要です。つまり、コードは必ず変化するという前提で書く必要があります。コードが変化すると、その周辺のコードに少なからず影響を与えます。場合によっては全然関係ないと思っていたところに⾶び⽕することもあります。それらをあらかじめ⼈間がすべて把握するのは経験則からくる職⼈技に近いものですので、⾮常に難易度が⾼いです。テストコードを書くと、変更を加えた際に起きる影響をある程度可視化してくれます。プロダクトの規模が⼤きくなるほど開発速度は落ちていきますが、テストコードはその減速率を下げるのに役⽴ちます。テストコードを書くメリットは以下の２点です品質を把握するテストそのものが品質を上げてくれるわけではありません。テストコードは現状のプロダクトの品質がどんなものなのかを可視化してくれます。この部分が適切に動いているのか、この部分に変更を加えるとどうなるのか、など。品質の可視化は機能追加、リファクタリングの判断材料となり、すばやい意思決定が⾏えます。 39

第 3 章とある Unity 開発事例 3.4 Unity 開発におけるテストの導⼊テストがないコードは品質が悪いのではなく品質がわからないので、どこを直すべきか、どこの
処理を⼿厚くすべきかという判断が難しくなり、結果的に開発効率が落ちてしまいます。精神的障壁の排除影響範囲の⾒えないコードの修正はメンタル的によろしくないです。根本原因を解決すべきとわかっていても、影響範囲が⾒えない場合、リスクを減らし最⼩⼯数で抑えるためにいったん場当たり的な対応を取りがちです。これはもちろん有効に働く場合もありますが、上記のネガティブな理由から選択すると、未来で同じ問題にぶつかってしまいます。テストコードにより影響範囲が可視化されていると、根本原因の解決はどのくらいの影響を与えるのかというのがある程度⾒えることで「よくわからないがたいへんそう・・」という精神的障壁を超えた上で判断ができます。ユニットテストのよかったところ Model 層以下は基本的にユニットテストを書くようにしています。ロジックが含まれない Entity は省いていますが、UseCase、Repository やそのほかの Model は基本的に書きます。当初はアウトゲームのみの想定でしたが、インゲームも MV(R)P アーキテクチャを導⼊したのでユニットテストできるところは極⼒テストを書いています。テストを書き始めて⼤きくメリットを感じた点は次の３つです。トライアンドエラーの速度が上がったエディタ上ですぐに再⽣して確認できるのは、実際にプレイする場合と⽐較してかなり早いです。特にインゲームはアウトゲームと⽐較してさまざまな計算ロジックが⼊りがちです。クリア時の点数計算だったりダメージ計算だったりなどがそうでしょう。これらのロジックを修正してその都度ゲームをプレイするのはかなり⼿間がかかる上に⾒間違えたりなど凡ミスも起こります。 EditModeTest ですぐに調べられるのはそれだけでエンジニアのストレス軽減になっています。また、テストしたいので Presenter からロジックを積極的に剥がしていくようなことも時折⾒られました。コードレビューの負担が減ったコードレビューではもちろん実装を⾒るのですが、これが本当に動くのか、正しいのかというのをコードのみで判別するのは中々たいへんです。テストコードが⼀緒に出されていると、少なくとも「正常に動作するか」という判断はしなくてよくなります。レビュアーは実装⽅法など本質的な部分に集中できるようになったので開発効率が上がりました。また、どのように使うかという例がテストコードで書かれているので特別にドキュメントが必要ということもありません。 40

第 3 章とある Unity 開発事例 3.4 Unity 開発におけるテストの導⼊リファクタリングのきっかけを作った
テストを書いていると、すぐにテストコードが書けるクラスと⾮常に書きづらいクラスがあることに気付きます。なぜこんなにも差が付くのでしょうか。理由はいろいろありますが、よくあるものとしては下準備が多いテストは書きづらいです。下準備とは、そのクラスのメソッドを実⾏するために必要な依存関係が多いため、事前に⽣成するインスタンスが多いということです。依存するインスタンスを作るためにまたそのインスタンスの依存しているインスタンスを⽣成したりと膨れ上がっていきます。Zenject を使えばある程度解決はできますが、それでも Bind する数が多いことには変わりません。プロダクトで実際に発⽣したのは UserData という、あらゆるユーザーデータを保持する神のようなクラスが原因でした。 public class UserData { public UserFoo Foo { get; } public UserBar Bar { get; } public UserData(UserFoo foo, UserBar bar) { } } 例では２つですが実際はもっとありました。この UserData は⽣成時に⼤量の引数を要求するのでテスト時に⼤量の依存関係を解決しないといけません。UserData の１メソッドをテストするために関係ないけど依存しているインスタンスを⽤意しないといけなかったのです。また、UserData に依存しているオブジェクトのテストを⾏うときも同様に UserData を⽣成する必要がありユニットテストの課題となっていました。このクラスの問題点は誰もが気付いていましたが、プロダクトを動かすうえでは必ず存在しているシングルトンインスタンスとして振る舞っていたのでそこまで⼤きな問題と認識するのが難しかったのです。テストを書いていく上でこのクラスの問題提起が⾏われ、ついにリファクタリングが⾏われたのでした。今は各データは Repository に分割され、UserData は本当に最低限の情報だけを持つクラスに変わりました。このように、設計上問題があるクラスはテストの段階で違和感に気付くことができるので、実際にリファクタリングを⾏うかは別にしてどうやっていくかの判断ができるようになったのは⾮常に⼤きなメリットです。通信を含むユニットテストをどう書くかユニットテストの問題として、通信が挟まるパターンを書けないという点があります。たとえばログインに成功したら何かをする、失敗したら何かをするという UseCase があったとして、テストを⾛らせるたびに本当に通信をするわけにはいきません。通信するテストは書かないという判断もありですが、それではあまりテストの恩恵を受けられないので、通信を良い感じに誤魔化す⽅法を考えなければなりません。 Unity 標準では通信部分を誤魔化す機能はないので、モックができる API クライアントを作るこ 41

第 3 章とある Unity 開発事例 3.4 Unity 開発におけるテストの導⼊とにしました。
Client の流れを分解するもともと作っていた API Client は次のような使い⽅でした。 var client = new ApiClient(); client.StartRequest(new FooRequest()); // => Result<FooResponse> APIClient に RequestBase を継承したリクエストを投げると通信してくれるようなしくみです。これをインタフェースとして考えると次の図のようになります。 42

第 3 章とある Unity 開発事例 3.4 Unity 開発におけるテストの導⼊⼀番理想的なのは
IHTTPClient 部分を差し替えられることです。最も適切なモックだと思います。しかし内部実装的に少し⼿間がかかり過ぎるので、今回は IApiClient と IRequest 間を誤魔化す⽅法を選択しました。 ApiClientMock を作成 C#ではテストでモックをするときは Moq というライブラリが使えます。Moq は Zenject の Option として同梱されているのでそれを使ってクライアントを作りました。 var mock = new ApiClientMock(); var mockResponse = new TResponse(); mock.Mock<TRequest, TResponse>().Success(mockResponse); mock.StartRequest(new TRequest()); // => Result<TResponse> 通信が成功したことにする場合は Success に任意のレスポンスを渡します。 var mock = new ApiClientMock(); var response = new FooResponse(); mock.Mock<FooRequest, FooResponse>().Success(response); var result = mock.StartRequest(new FooRequest()); result.Response.Content; // => FooResponse サーバエラーとして返すなら ErrorResponse を渡します。 43

第 3 章とある Unity 開発事例 3.4 Unity 開発におけるテストの導⼊ var
mock = new ApiClientMock(); ErrorResponse error = new ErrorResponse(); mock.Mock<FooRequest, FooResponse>().Failure(error); var result = mock.StartRequest(new FooRequest()); result.Response.ErrorResponse; // => ErrorResponse ネットワークにつながらなかったなど、サーバに届く前のエラーを起こす場合は Error を呼ぶだけです。 var mock = new ApiClientMock(); mock.Mock<FooRequest, FooResponse>().Error(Error.Network); var result = mock.StartRequest(new FooRequest()); result.ErrorCause; // => Error.Network 例として、次のコードのテストを書いてみます。 public class FooUseCase { private IApiClient client; public FooUseCase(IApiClient client) { this.client = client; } public string Run() { var result = client.StartRequest(new FooRequset()); if(result.IsSuccess) { return result.Response.Content.Foo; } else { return "NG"; } } } この UseCase は通信結果を返すのでそのままではテストできません、ApiClientMock を使えばこのようなテストを書くことができます。 public class FooUseCaseTest { private IApiClient client; [Test] public void Run_Success() { client = new ApiClientMock(); var response = new FooResponse { Foo = "OK" }; client.Mock<FooRequest, FooReponse>() .Success(response); 44

第 3 章とある Unity 開発事例 3.5 最後に var useCase
= new FooUseCase(client); Assert.AreEqual("OK", useCase.Run()); } } これで必ず通信に成功した扱いにできます。また、モックしたリクエストと違うリクエストが⾶んできたりモックしたが呼ばれなかったなどの場合は⾃らテストを落とすようにしています。常に本番と同じ状態を⽤意するというのは⾮常にたいへんですので、テストを書くときは何をテストしたいかというスコープをしっかりと絞る必要があります。その際にスコープ外の処理は正常である、という前提を担保するためにモックライブラリを作るのは⾮常に有効ですので多少⼿間でも作ることをお勧めします。しかし、本来テストしないといけない部分をモックしてしまっては本末転倒ですので、使うときはなぜモックしないといけないのかをしっかり考えるようにしましょう。 3.5 最後に⽉並みですが、開発に絶対の正解はありません。チームに合わせた⼿法や設計を採⽤するのがベターでしょう。とはいえ Unity 開発でそれらの事例が出てくることはあまりありません。各所の開発者たちが同じ失敗をしてしまうのは⾮効率だと思うので、少しでもノウハウが公開され Unity 開発の集合知がたまっていくことを願っています。 45

第 4 章 git challenge を⽀える技術弊社で催している、学⽣向け競技型イベント git challenge の裏側についての紹介・解説をしま
す。しかし git challenge で実際に使われているコードのほとんどはプライベートリポジトリとなっています。そのため現⾏のコードを使うのではなく、現⾏のコードを参考にしつつスクラッチに⾃作したものを⽤いて紹介・解説を⾏います。 4.1 git challenge とは何か git challenge とは、弊社が催している学⽣向け競技型イベントで、ひとことで⾔ってしまえば git で回答するプログラミングコンテストのようなものです。参加する学⽣は git コマンドを駆使して、コンフリクトの起きるブランチどうしをマージしたり、コミットの順番を並び替えたりして、こちらが要求するコミットを作ります。図 4.1: 記念すべき第 10 回を 2018 年 12 ⽉ 1 ⽇に開催予定です！基本ルール次のようなルールでポイントを集め競い合う競技となっています。 • 学⽣らはふたり⼀組のチームとなり、各チームには GitHub の組織アカウントを割り当てら 47

第 4 章 git challenge を⽀える技術 4.2 問題の例れる •
それらのアカウントには問題⽤のリポジトリが 20 個弱ほど⽤意されており、リポジトリに回答として指定通りのコミットができれば正解となる • 正解することでポイントを得ることができ、時間内により多くのポイントを得たかどうかで順位を競う • 問題には難易度があり、難しいほどポイントが⾼いしくみになっているイベントはいつも弊社オフィスで、休⽇を丸⼀⽇使ってやっています。ただし競技時間そのものは 3 時間ほどです。ちなみに、難易度は 1~6 までありますが、難易度 5,6 を解けた学⽣は今のところ現れていません。 4.2 問題の例問題はチュートリアルも含めて 3 つだけ mixi-git-challenge*1 という GitHub 組織アカウントで公開しています。ここではそれらの問題を簡単に紹介したいと思います。 tutorial チュートリアルです。この問題は実際の git challenge でもチュートリアルとして使われています。git-challenge-tutorial と⾔うリポジトリ名で、ブランチは全部で readme・master・ task-1・task-2 の 4 つです*2。このリポジトリに限らず問題のリポジトリには readme と呼ばれるブランチがあり、問題設定や正答条件が README.md に書いてあります。基本的には master ブランチに適切なコミットらをプッシュできれば正解です。どの問題にも users.csv と⾔うファイルがあります。中⾝は次のようになっています。 103,419e0896-52f1-4913-a43c-ec3ae62b66b6, 渡辺⼼愛,[email protected],... 48,f6fc18cb-b7d3-4e6c-b4f2-2c9422933b9b, ⽥中美⽻,[email protected],... 6,64157d6b-d84d-417f-b44d-31775d6a134f, 斎藤蓮,[email protected],... ... 名前っぽいものやメールアドレスっぽいものが書いてありますが、正直⼤して重要ではありません。重要なのは、それらのユーザー情報っぽいものが各⾏で固有だと⾔うことと、最初の列の数字です。最初の数字はそのユーザーが持っているチップの数です。ユーザーはユーザーへチップを渡したりもらったりでき、users.csv ではそれらの情報を管理している、と⾔う設定です。たとえば⼀つのコミットを⾒てみましょう。 *1 https://github.com/mixi-git-challenge *2 https://github.com/mixi-git-challenge/git-challenge-tutorial 48

第 4 章 git challenge を⽀える技術 4.2 問題の例 $ git
show 85afeb1 commit 85afeb146104cc0d3f539ce34e3ec1ab6f8dcf99 (HEAD -> task-1, origin/task-1) Author: Kuniwak <[email protected]> Date: Fri Oct 9 19:24:20 2015 +0900 A さんの変更 diff --git a/users.csv b/users.csv index 9d6ba74..2320034 100644 --- a/users.csv +++ b/users.csv @@ -1,5 +1,5 @@ -103,419e0896-52f1-4913-a43c-ec3ae62b66b6, 渡辺⼼愛,[email protected],... -48,f6fc18cb-b7d3-4e6c-b4f2-2c9422933b9b, ⽥中美⽻,[email protected],... +113,419e0896-52f1-4913-a43c-ec3ae62b66b6, 渡辺⼼愛,[email protected],... +38,f6fc18cb-b7d3-4e6c-b4f2-2c9422933b9b, ⽥中美⽻,[email protected],... 6,64157d6b-d84d-417f-b44d-31775d6a134f, 斎藤蓮,[email protected],... 134,4048db0f-2454-477a-870b-a007ea21df2b, 松本⼼愛,[email protected],... 275,9f2fe7d1-a5b0-41b7-802c-8a7ed93baf48, 斎藤結愛,[email protected],... このコミットでは「⽥中さん」から「渡辺さん」にチップを 10 枚渡しています。さて、チュートリアルの正答条件ですが、それは master に task-1 と task-2 をマージすることです。察しの良い⼈はすでにお気付きだと思いますが、このようなデータの扱いをしていた場合、かなりの頻度でコンフリクトがおきます。もちろんチュートリアルでもおきます。なのでコンフリクト解決し、正しくマージしたものをコミットしてくださいと⾔うのがこのチュートリアル問題の趣旨です。 is order an adding ここからはさらっと紹介します。この問題は git-challenge-is-order-an-adding と⾔うリポジトリ名です*3。問題はとてもシンプルで、users4.csv をプッシュしたいが、なぜかできないのでとにかくプッシュしてくださいというものです。users4.csv そのものは Gist に上がっています。 minesweeper この問題は git-challenge-minesweeper と⾔うリポジトリ名です*4。問題は master にテストに落ちるコミットが含まれているので、それらのコミットをすべて直してください、というものです。数コミット程度なら⼀つ⼀つチェックアウトして確かめても良いでしょうが、全部で 44 コミットあります。さぁどうすれば簡単に問題のコミットを調べることができますかね？ちなみに、特定のコミットだけ落ちるテストというのは Perl のスクリプトとして書かれており、README にリンクがある DropBox からダウンロードできます。 *3 https://github.com/mixi-git-challenge/git-challenge-is-order-an-adding *4 https://github.com/mixi-git-challenge/git-challenge-minesweeper 49

第 4 章 git challenge を⽀える技術 4.3 インフラの構成 4.3 インフラの構成
さて、ここから「⽀える技術」っぽい話をします。しかし、前述した通り現⾏のコードはプライベートです。ですので、筆者がスクラッチで⾃作したものを紹介します*5。現⾏の構成実は現⾏の構成についてはすでに mixi engineer blog で紹介されています*6。しくみは簡単で、 AWS 上に⽴てた Jenkins が GitHub からの Webhook を受け取り採点スクリプトを⾛らせる、といった感じです。詳しくは mixi engineer blog の記事を⾒てみてください。新しい構成次に⾃作した新しい構成を紹介します。新しい⽅では Jenkins の代わりに Drone という OSS の CI ツールを使いました。構成は次のようになります。図 4.2: 新しいインフラの構成 *5 つまり、まだ「git challenge を⽀える技術」ではないですが、いずれ移し替えるかもしれません。 *6 http://alpha.mixi.co.jp/entry/2017/08/03/113000 50

第 4 章 git challenge を⽀える技術 4.3 インフラの構成問題のリポジトリには問題のためのブランチや回答のブランチ、採点スクリプトが含まれるブランチなどが存在します。実は現⾏では、問題のリポジトリと回答のリポジトリは別の上、採点スク
リプトは Jenkins が持っていました。新しい構成では、すべて問題のリポジトリに集約させています。Haskell 製のデプロイツールを使って、この問題のリポジトリから回答のブランチや採点スクリプトのブランチなどを除いたブランチを複製し、新しいリポジトリをチームごとに作成します。採点のフローは次のようになっています。 1. 各チームがチームのリポジトリに回答をプッシュ 2. すると Haskell 製の⾃作 App サーバに Webhook され 3. App サーバは問題のリポジトリの採点スクリプトのブランチに空コミットし 4. そのコミットが Drone によって Webhook され 5. 採点スクリプトが⾛る採点スクリプトは、各チームのリポジトリをクローンしスクリプトを⾛らせます。なんでこんな⾯倒くさいフローにしているのかと⾔うと。。。 • なぜチームリポジトリから Drone に Webhook しないのか？ : 採点スクリプトをチームリポジトリに置きたくない • なぜ App サーバから直接 Drone を⾛らせないのか？ : Drone はブランチベースなので厳しい • なぜ App サーバで直接採点スクリプトを⾛らせないのか？ : 結果を保持したりが⾯倒くさい要するに Drone や問題リポジトリに状態の管理を任せることで、App サーバの開発をサボったのでした。また、スコアボードも App サーバから返しています。スコアボードのための情報、採点結果などは Drone に App サーバから Drone の API を叩いて取得し、必要なデータにして返しています。ちなみに、まだやっていませんが、この App サーバは Docker イメージ化しているので Kubernetes とかで良い感じに分散したいですね。 Drone Drone は OSS の CI ツールで、Go ⾔語によって書かれています*7。コンテナネイティブで、 Docker との親和性が⾼いです。⼿元で起動する場合も docker-compose up というコマンドだけで⽴ち上げることができます。 Haskell 以降では⾃作したデプロイツールと App サーバについて紹介します。しかし、その前にデプロイツールと App サーバを記述した Haskell というプログラミング⾔語について紹介 *7 https://drone.io/ 51

第 4 章 git challenge を⽀える技術 4.3 インフラの構成しましょう*8。ちなみに、Haskell 製の⾃作したデプロイツールと
App サーバのコードは matsubara0507/git-plantation と⾔うリポジトリにあります*9。執筆時点でのバージョンを保持するために teckbookfest5 というタグを付けたのでそちらを参照してください。 Haskell とは？ Haskell は純粋関数型プログラミング⾔語で、プログラミングに関する研究のための⾔語として 1990 年ごろに多くの研究者の協⼒によって作成されました。近年では Facebook*10 や GitHub*11 が Haskell を⼀部で採⽤するなど実⽤としても注⽬を集めています。 Haskell の特徴は強⼒な型システムにあります。最近では多くのプログラミング⾔語で静的型検査が注⽬を集めていますが*12、Haskell のそれはそのどれよりも⽐べ物にならないぐらい強⼒です。たとえば Haskell では RESTful API のインタフェースを型として表現したりもできます（これについては後述します）。関数定義わざわざここで説明する必要はないのですが、以降でちょくちょく書くので念のため説明しておきます。たとえば階乗を求める関数は次のように記述できます。 factorial :: Int -> Int factorial n = foldl (*) 1 [1..n] Haskell は Python と同じようなオフサイドルールです。⼀⾏⽬には関数の型を記述し、⼆⾏⽬には実装を記述しています。Haskell は強⼒な型推論を持っているので、実は⼀⾏⽬の型定義を記述する必要は基本的にないのですが、可読性のために記述するのがデファクトスタンダードとなっています。Int -> Int が型です。Int 型の引数を受け取り、Int 型を返すという意味の型です。 foldl はいわゆる畳み込みの関数で、次のような型を持ちます（厳密には違いますが）。 foldl :: (b -> a -> b) -> b -> [a] -> b a や b と⾔うのはジェネリックスな型で任意の型を受け取れます。もちろん factorial の場合はどちらも Int 型にしていますが。また、[a] は型 a を要素にもつリスト型です。つまり foldl は b -> a -> b と⾔う型の 2 引数関数と b 型の初期値、a 型のリストを受け取って畳み込んだ結 *8 さぁここがメインパートですよっ！ *9 https://github.com/matsubara0507/git-plantation *10 https://github.com/facebook/Haxl *11 https://www.theregister.co.uk/2018/08/16/github_rails_microsoft/ *12 Python には型ヒントと⾔うのが導⼊され、Ruby では 3 系で何らかの型検査の導⼊が検討されています。また最近流⾏りの Go や Rust は静的型付き⾔語ですね。 52

第 4 章 git challenge を⽀える技術 4.3 インフラの構成果を返します。型を記述する
Haskell で型を記述するには次のように書きます。 data Maybe a = Just a | Nothing = の左側の Maybe a が定義した型の名前になり、その要素が Just a か Nothing になります。 Maybe a や Just a の a は関数のときと同じようにジェネリックスな型です。Maybe Int と記述することで取りうる値は Just 10 や Nothing となるのです。ちなみに、この Maybe a 型は組込みで存在する型で、いわゆるオプショナル型です。また、次のように記述することで別名の型を定義できます。 type UserId = Int 特殊な型の記述以降ではときおり次のように型を記述します。 type User = Record ’[ "id" >: UserId , "name" >: Text , "active" >: Bool ] これは Haskell の⼀般的な型の記法ではありません。拡張可能レコードと⾔われるものです。これを⽤いると user^.#name のようにオブジェクト指向プログラミング⾔語のようにフィールドにアクセスできるなど、いろいろと便利なので重宝しています。詳しくは「Haskell 拡張可能レコード」などで調べてみてください。 Stack Haskell プログラムをビルドする場合は Stack*13 と呼ばれるツールを使うのが簡単です。Stack は 2015 年ごろにリリースされた割と最近に出てきたビルドツールです。パッケージマネージャーも *13 https://docs.haskellstack.org/ 53

第 4 章 git challenge を⽀える技術 4.3 インフラの構成付随しており、Stackage*14 として管理しています。パッケージそのものは
Hackage*15 と⾔うまったく別のサービス上に保存されていますが、Stackage は各パッケージのバージョンの組み合わせがビルドできるリゾルバーを提供してくれます。デプロイツール今のところデプロイツールには設定ファイルを読み込んで問題のリポジトリからチームのリポジトリを⽣成する機能しかありません。他にも便利機能があると良いのですが、それはおいおい追加していきます。チームリポジトリを⽣成するコマンドは次のように使います。 $ GH_TOKEN=XXX stack yaml -- \ git-plantation-tool -c .git-pantation.yaml --work .temp new_repo team_name -c .git-pantation.yaml で設定ファイルを指定しています。設定ファイルは次のようになっています。 problems: - problem_name: tutorial repo_name: matsubara0507/git-challenge-tutorial difficulty: 1 challenge_branches: - readme - master - task-1 - task-2 ci_branch: ci teams: - name: sample github: sample-hige member: - matsubara0507 基本的に今のところは問題の設定とチームの設定を記述しています。ちなみに、次のような Haskell の型を定義し、yaml パッケージの decodeFile などを使うだけで定義した型にマッピングしてくれます。すばらしいですよね。 type Config = Record ’[ "problems" >: [Problem] *14 https://www.stackage.org/ *15 https://hackage.haskell.org/ 54

第 4 章 git challenge を⽀える技術 4.3 インフラの構成 , "teams"
>: [Team] ] type Problem = Record ’[ "problem_name" >: Text , "repo_name" >: Text , "difficulty" >: Int , "challenge_branches" >: [Branch] , "ci_branch" >: Branch ] type Team = Record ’[ "name" >: Text , "github" >: Text , "member" >: [User] ] git-plantation-tool new_repo コマンドでは次のようなフローで新しいチームリポジトリを⽣成しています。 1. GitHub API でチームリポジトリを作成 2. 作成したチームリポジトリをクローン（この時点では空リポジトリ） 3. 問題リポジトリをリモートに追加してフェッチ 4. challenge_branches のブランチのみを問題のリポジトリからチームのリポジトリにコピー 5. それらのブランチをプッシュチームリポジトリの作成⾃体はこれで完成ですが、採点スクリプトを実⾏するために問題リポジトリの CI ブランチから新しくブランチを切っておきます。 1. 問題リポジトリをクローン 2. ci_branch のブランチからチーム名でブランチを作成 3. チームリポジトリの名前を書き込んだ REPOSITORY と⾔うファイルを作成 4. そのファイルをチームブランチにコミットし問題リポジトリにプッシュ採点スクリプトはこの作成したチームブランチで実⾏されます。ちなみに、これらの作業をするディレクトリを --work .temp で指定しています。また、GH_TOKEN 環境変数には GitHub トークンを指定し、GitHub API をたたくときや、問題リポジトリやチームリポジトリにプッシュするのに使います。 App サーバ次に⾃作した Haskell 製 App サーバについて紹介します。現状の App サーバは次のようなルーティングを持っています。 55

第 4 章 git challenge を⽀える技術 4.3 インフラの構成 [GET] /
# index.html を返す [GET] /static # 画像や JS などの静的ファイル [POST] /hook # GitHub Webhook の Ping と Push Event を拾える [GET] /api/teams # Team 型のリストを JSON 形式で返す [GET] /api/problems # Problem 型のリストを JSON 形式で返す [GET] /api/scores # 全てのチームのスコアを JSON 形式で返すさて、これを Haskell でどう実現しているのかというと、Haskell の Web フレームワークはいくつかありますが、僕は Servant と呼ばれるものを愛⽤しています。彼の有名な Ruby on Rails のようなオールインな Web フレームワークというよりは、Sinatra のような RESTful API のためのコンパクトな DSL といった感じです。 Servant Sevant の特徴は RESTful API の定義を型として書けてしまう点です。たとえば今回の App サーバの API 定義の型は次のようになっています。 type API = Get ’[HTML] H.Html :<|> "static" :> Raw :<|> "hook" :> WebhookAPI :<|> "api" :> CRUD type WebhookAPI = GitHubEvent ’[ ’WebhookPingEvent ] :> GitHubSignedReqBody ’[JSON] PublicEvent :> Post ’[JSON] () :<|> GitHubEvent ’[ ’WebhookPushEvent ] :> GitHubSignedReqBody ’[JSON] PushEvent :> Post ’[JSON] () type CRUD = "teams" :> Get ’[JSON] [Team] :<|> "problems" :> Get ’[JSON] [Problem] :<|> "scores" :> Get ’[JSON] [Score] 驚くことに Haskell では GHC 拡張と⾔われる機能を駆使することで "static" のような「値」 (この場合は⽂字列) を型の中で扱うことができるのです*16。この型に対して、HTTP リクエストを受け取ったときの振る舞いを関数で定義します。 -- Plant のところは気にしないで *16 このように「値」を記述できる型を「依存型」と⾔います。興味のある⼈は調べてみてください。 56

第 4 章 git challenge を⽀える技術 4.3 インフラの構成 server ::
ServerT API Plant server = indexHtml :<|> serveDirectoryFileServer "static" :<|> webhook :<|> crud indexHtml :: Plant H.Html indexHtml = ... webhook :: ServerT WebhookAPI Plant webhook = pingWebhook :<|> pushWebhook pingWebhook :: RepoWebhookEvent -> ((), PublicEvent) -> Plant () pingWebhook _ (_, ev) = ... pushWebhook :: RepoWebhookEvent -> ((), PushEvent) -> Plant () pushWebhook _ (_, ev) = ... crud :: ServerT CRUD Plant crud = getTeams :<|> getProblems :<|> getScores getTeams :: Plant [Team] getTeams = ... getProblems :: Plant [Problem] getProblems = ... getScores :: Plant [Score] getScores = ... Plant の部分は基本的に気にしないでください。これは関数の中で IO などの好きな副作⽤を利⽤するためのコンテナ型です。それぞれの API に対応する関数、たとえばチームのリストを返す /api/teams の関数では [Team] 型を返していますね。もしここで、違う型の値を返す実装を getTeams 関数でした場合は静的型検査でエラーとなります。もちろん、getTeams 関数の型そのものが [Team] 型を返すようになっていなければ、それもエラーとなります。このように Servant は定義したルーティングに対して正しく実装できているかを型検査して、実際に試す前に確認してくれるのです*17。 Webhook 後の振る舞い残りの App サーバの節では Webhook を受け取ったあとの振る舞いを紹介します。前述した通り /hook API は GitHub Webhook の ping イベントとプッシュイベントを拾えます。ping イベントは GitHub Webhook を設定したときにテストで⾶ばされるイベントで、今のところログの出⼒しかしていません。なので実際に利⽤するのはプッシュイベントだけです。プッシュイベント後の動作は次のようになっています。 *17 すばらしい！！ 57

第 4 章 git challenge を⽀える技術 4.4 スコアボード 1. プッシュイベントを受け取る
2. プッシュイベントの payload からチームと問題を検索する 3. 問題のリポジトリをクローン 4. 採点⽤のチームブランチにチェックアウト 5. 空コミットをしてプッシュ採点⽤のブランチはデプロイツールで作ったものです。単純に問題のリポジトリに空コミットをプッシュしているだけですね。この空コミットによって Drone による採点スクリプトが実⾏されます。Drone で動作するスクリプト⾃体は問題リポジトリの ci ブランチの .drone.yml ファイルに書いてあります。 workspace: base: /root pipeline: clone_target_repo: image: buildpack-deps:16.04-scm environment: - GH_TOKEN=$$GH_TOKEN commands: - pwd - export PATH=$${PATH}:‘pwd‘/bin - (ls | grep --silent target) || \ git clone https://[email protected]/‘cat REPOSITORY‘.git target - cd target && ../verify.bash when: branches: exclude: [ ci ] Drone 側はデプロイツールで作成した REPOSITORY ファイルの中⾝を⾒て採点スクリプトを回すべきリポジトリをクローンします。採点スクリプトそのものは verify.bash というスクリプトです。たとえばチュートリアルの採点スクリプトは matsubara0507/git-challenge-tutorial の ci ブランチに置いてあります。ここでは説明を割愛しますが、興味のある⽅は覗いて⾒てください。 4.4 スコアボード次にスコアボードの話をします。もちろん、これも現⾏とは全然違います。現⾏のスコアボード現⾏のスコアボードは TypeScript によって記述されており、さらに Isomorphic TypeScript と呼ばれるデザインパターンを利⽤しています。これは、サーバ・クライアントの双⽅を TypeScript で実装することで、⼀部の実装を共有するデザインパターンのことを指すようです。筆者は TypeScript について詳しくないのでこれ以上の説明はしませんが、サーバとクライアントでデータ型や API を 58

第 4 章 git challenge を⽀える技術 4.4 スコアボード共有化できるというの魅⼒的ですよね。新しいスコアボード
新しいスコアボードも基本は同じような⾒た⽬にしていますが、Elm*18 というプログラミング⾔語で記述しました。実は Haskell を弊社で利⽤している例はありませんが、Elm であればいくつかの社内ツールに利⽤されている実績があります*19。図 4.3: 新しいスコアボード Elm Elm は純粋関数型プログラミング⾔語で、JavaScript にコンパイルされる、いわゆる Alt. JS です。お察しの通り、Haskell から強い影響を受けていますが、Haskell に⽐べてかなり機能を削ぎ落としています。たとえばアドホック多相を表現するための「型クラス」がありません*20。Elm は汎⽤プログラミング⾔語と⾔うよりは、The Elm Architecture というフレームワークのためのドメイン特化⾔語と⾔えるでしょう*21。 Elm の構⽂⾃体は、Haskell によく似ています。たとえば、Elm で階乗を求める関数を定義すると次のようになります。Haskell のときのものとすごく似ていますね。 factorial : Int -> Int factorial n = List.foldl (*) 1 (List.range 1 n) *18 公式サイト http://elm-lang.org/ *19 Elixir を採⽤しているプロダクトの社内ツールです。https://career.xﬂag.com/interview/engineer/xﬂag-career- blog27/ *20 もちろん、Haskell の⽬⽟機能であるモナドもありません。 *21 このあたりの話は @arrow さんの Qiita 記事「Elm はどんな⼈にオススメできないか」が参考になります。 59

第 4 章 git challenge を⽀える技術 4.4 スコアボード Elm のソースコードはリポジトリの
elm-src/Main.elm です。このプログラムでは、2018 年の 8 ⽉にリリースされたばかりの Elm 0.19 を使っています。Elm 0.19 ではかなり破壊的な変更をされたので、インターネットを検索して得られるサンプルコードがうまく動かないと思います。Elm 0.19 の変更点については elm/compiler リポジトリの upgrade-docs/0.19.md に詳しく書いてあります*22。⽇本語であれば @jinjor ⽒の記事「Elm 0.19 の主な変更点」が参考になるでしょう*23。本書では Elm の設計思想や細かい構⽂についての説明は省きます。興味のある⽅は Elm 公式のドキュメント guide.elm-lang.org がかなりよくまとまっていてお勧めだそうなので読んで⾒てください*24。 Elm と Haskell さて、ここからが Elm を採⽤したキモになります。現⾏のスコアボードは Isomorphic TypeScript というデザインパターンにより、サーバとクラインアントで実装を共有していました。実は新しいスコアボードでも Haskell の実装から Elm の実装を⾃動⽣成することで、同様に実装の共有をしています。Haskell から Elm の実装を⽣成するには elm-export*25 と⾔うパッケージを使います*26。これを使うことで、Haskell の型から Elm の型を⽣成できます。たとえば、Team という型を Elm で⽣成して⾒ます。 type Team = Record ’[ "name" >: Text , "github" >: Text , "member" >: [User] ] instance ElmType Team where toElmType = toElmRecordType "Team" Elm のコードを⽣成したい型を ElmType という型クラス*27のインスタンスにすることで⽣成できます。ただし、toElmRecordType 関数は筆者が⾃作したものです。実装は src/Language/Elm.hs にありますが、ここでは割愛します。そして、次のような main 関数を書きます。 spec :: Spec spec = Spec ["Generated", "API"] $ concat *22 https://github.com/elm/compiler/blob/master/upgrade-docs/0.19.md *23 http://jinjor-labo.hatenablog.com/entry/2018/08/23/142026 *24 ちなみに、これの⽇本語版も絶賛 Elm-jp というコミュニティで翻訳中です。https://guide.elm-lang.jp/ *25 http://hackage.haskell.org/package/elm-export *26 残念なことに少なくとも執筆当初は Elm 0.19 に対応していなかったので、筆者が⾃分で直したものを使っています。 https://github.com/matsubara0507/elm-export/tree/elm-0.19 *27 型クラスがわからない⼈は、後付けできる Java のインタフェースという認識で⼗分です。 60

第 4 章 git challenge を⽀える技術 4.4 スコアボード [ [defElmImports]
, toElmTypeAll (Proxy @ Team) ] toElmTypeAll :: ElmType a => Proxy a -> [Text] toElmTypeAll proxy = [ toElmTypeSource proxy , toElmDecoderSource proxy , toElmEncoderSource proxy ] main :: IO () main = specsToDir [spec] "elm-src" 細かいところは気にしなくて良いです。spec のような設定を書き、specsToDir 関数を呼び出すだけで次のような elm-src/Genarated/API.elm を⽣成してくれる。 module Generated.API exposing (..) import Http import Json.Decode exposing (..) import Json.Decode.Pipeline exposing (..) import Json.Encode import String type alias Team = { name : String , github : String , member : List String } decodeTeam : Decoder Team decodeTeam = Json.Decode.succeed Team |> required "name" string |> required "github" string |> required "member" (list string) encodeTeam : Team -> Json.Encode.Value encodeTeam x = Json.Encode.object [ ( "name", Json.Encode.string x.name ) , ( "github", Json.Encode.string x.github ) , ( "member", Json.Encode.list Json.Encode.string x.member ) ] 61

第 4 章 git challenge を⽀える技術 4.4 スコアボードさらに、servant-elm*28 を使うことで
Servant で書かれた API の型から、HTTP リクエストを⾏う Elm の関数を⽣成してくれます。前述した spec 関数へ次のように generateElmForAPI 関数を書き加えます。 spec :: Spec spec = Spec ["Generated", "API"] $ concat [ [defElmImports] , toElmTypeAll (Proxy @ Team) , generateElmForAPI (Proxy @ ("api" :> CRUD)) ] CRUD という型は Servant に関する節で定義したものです。これを同じように実⾏すると Team 型のほかに次のような Elm の関数も⽣成してくれます。⻑くなるので /api/teams に対応する関数しか書きませんが、 /api/problems と /api/scores に対応する関数も⽣成されます。 getApiTeams : Http.Request (List Team) getApiTeams = Http.request { method = "GET" , headers = [] , url = String.join "/" [ "" , "api" , "teams" ] , body = Http.emptyBody , expect = Http.expectJson (list decodeTeam) , timeout = Nothing , withCredentials = False } これらによって現⾏の TypeScript によるスコアボード同様、サーバとクラインアントの実装を共通化でき、また API の整合性を保証することもできました*29。 *28 http://hackage.haskell.org/package/servant-elm *29 すばらしいっ。 62

第 4 章 git challenge を⽀える技術 4.5 今後とまとめ 4.5 今後とまとめ
今回は git challenge をより多くの⼈に知ってもらうことを⽬的として、新しい git challenge のシステムを開発し、それについて執筆しました。このシステムは Drone や Haskell、Elm といった⽐較的利⽤されていないツール・⾔語を使って開発しています。Haskell・Elm を採⽤したことにより強⼒な型システムに守られた安全なシステムを容易に作ることができます。Drone を利⽤したのは最終⽬標でもある Kubernetes 化を⾒据えてです*30。最終⽬標と述べたように、執筆時点にできているシステムは現⾏のシステムに⽐べるとまだまだで、とても置き換えることはできません。今後はデプロイツールに機能を追加したり、エラーハンドリングをちゃんとしたり、現⾏からの置き換えを⽬標に開発を続けていきます。 *30 参加者は限られているので、わざわざ Kubernetes で分散する意味があるかどうかは置いといて。 63

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.1 始めに板野サーカスという⾔葉をご存じでしょうか？
アニメのマクロスなど板野⼀郎⽒が⼿がけるミサイルの弾幕シーンの総称です。⼤量の誘導ミサイルが襲いかかり、ヴァルキリー (ロボット) が華麗にかいくぐって撃破していくシーンです。男⼦プログラマーたるもの板野サーカスにあこがれます。さらに Unity を使っているなら作りたくなるでしょう。その欲求のまま板野サーカスを作り上げたときには、クォータニオンを使いこなしているでしょう。想定読者 • 誘導ミサイルにロマンを感じている⼈ • Unity でゲームをなんとなく作れる⼈ • クォータニオンがよくわからない⼈読者が得られる知⾒ • それっぽい物を作るまでの過程 • オブジェクトの回転制御 • オイラー⾓とクォータニオンの⽐較 • Unity でクォータニオンを使⽤した回転制御 • Unity で RigidBody を "使⽤しない" 当たり判定 65

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.2 今回作成したデモ読者が得られない知⾒ •
クォータニオンについての数学的な知識理解を深めたい⽅は「Quaternion による 3 次元の回転変換」(https://qiita.com/ kenjihiranabe/items/945232fbde58fab45681) を参照してください。丁寧に解説してありました。 5.2 今回作成したデモ敵と⾃分がいます。ミサイルを撃ち合います。図 5.1: スクリーンショット • 動画はこちらにあります。 https://www.YouTube.com/watch?v=V40_mCYeqZ4 • Unity の Project を公開しています。 https://github.com/toymany/missile 5.3 オイラー⾓とクォータニオンとマトリックス回転の表現⽅法は「オイラー⾓」と「クォータニオン」と「マトリックス」の 3 種類あります。それぞれ得⼿不得⼿があります。ざっくり結論を先に書きます。 1. 計算はクォータニオン 2. ⼈間が触わるところはオイラー⾓ 3. クォータニオンでもオイラー⾓でもできないときはマトリックス 66

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.3 オイラー⾓とクォータニオンとマトリックスオイラー⾓ (x,y,z)
のように書きます。x 軸,y 軸,z 軸それぞれの軸で x 度 y 度 z 度回転するというように表現します。やっかいなことにオイラー⾓は (x,y,z) が同じ値であっても、回転させる軸の順番によって結果が異なります。xyz,zyx,yxz... というようにさまざまなパターンがあります。クォータニオン (x,y,z,w) のように書きます。クォータニオンは複素数を拡張したものです。それぞれの値はオイラー⾓のように簡単ではありません。ざっくりいうと、x,y,z は回転軸であり、w はその周りの回転量です。値の感覚をつかむために Quaternion.AngleAxis を使⽤して、数字の変化を確認します。Quater- nion.AngleAxis は、回転軸とその軸周りの回転⾓度を指定してクォータニオンを⽣成する関数です。リスト 5.1: TestAngleAxis() for (var f = 0; f <= 360; f += 90) { var q = Quaternion.AngleAxis(f, new Vector3(1, 0, 0)); Debug.LogFormat("{0} {1}", f, q); } リスト 5.2: TestAngleAxis の結果 0 (0.0, 0.0, 0.0, 1.0) 90 (0.7, 0.0, 0.0, 0.7) 180 (1.0, 0.0, 0.0, 0.0) 270 (0.7, 0.0, 0.0,-0.7) 360 (0.0, 0.0, 0.0,-1.0) 出⼒結果を⾒ると、このクォータニオンは x と w が変化してます。回転⾓度が 0 のとき、 (0.0, 0.0, 0.0, 1.0) です。これは回転がない「単位クォータニオン」です。回転⾓度が 0 以外のときは、x 軸周りの回転なので x に値が⼊っており y と z は 0 です。この x は、θ =回転⾓度とすると sin(θ /2) です。w は cos(θ /2) です。クォータニオンの数値から回転を想像できればデバッグに役⽴ちます。マトリックス 3DCG では 4 ⾏ 4 列 16 要素のマトリックスを使⽤します。回転と位置とスケールをまとめて表現します。回転のみであれば 3 ⾏ 3 列で表現できます。アプリケーションが回転の計算にオイラー 67

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.3 オイラー⾓とクォータニオンとマトリックス⾓やクォータニオンを使っても、Unity などのシステムは最終的にマトリックスに変換して描画し
ます。オイラー⾓とクォータニオンを⽐較する表 5.1: オイラー⾓とクォータニオンの⽐較項⽬オイラークォータニオン難易度簡単難しいジンバルロックあるない球⾯補間できないできる 180 度以上の回転できるできない難易度クォータニオンは、オイラー⾓に⽐べて回転の結果をイメージするのが難しく計算も複雑です。とはいえ、使うだけなら Unity が⽤意している関数を使⽤するだけです。Unity では、 Transform.rotation がクォータニオンですが、インスペクタで表⽰されている⾓度はオイラー⾓です。このように⼈間が理解しやすいのはオイラー⾓ですので、回転量を指定するときなど⼈間が触れる部分はオイラー⾓を使⽤します。ジンバルロック⾶⾏機やミサイルの制御をオイラー⾓を使ってやろうとすると、どうにもならない事態に遭遇します。9 割の状況で⼤丈夫だとしても、ひねって、宙返りなど、x 軸,y 軸,z 軸それぞれの回転が絡み合った時に「ジンバルロック」は発⽣します。ジンバルロックがおきると意図した⽅向に回らなくなります。x 軸で回しても z 軸で回しても同じ⽅向に回ってしまいます。しかし、計算をクォータニオンで⾏えばジンバルロックは発⽣しません。球⾯補間ある回転からある回転に補間したいというのはよくあります。オイラー⾓を使って単純に (x1,y1,z1) と (x2,y2,z2) をそれぞれの軸で線形補間すると、ぐにゃぐにゃと遠回りするような回転になります。クォータニオンには球⾯補間があります。これを使⽤すると普通に期待する最短の回転で補間ができます。Unity の Quaternion.Slerp です。 180 度以上の回転オイラー⾓で (720 度,0 度,0 度) とすれば、x 軸で 2 回転することが簡単に表現できます。しかし、クォータニオンは 180 度を超える回転は表現できません。w = cos(θ /2) というように三⾓関 68

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.4 板野サーカスを⽬指す数を通るためです。0 度も
360 度も 720 度も同じ値になります。回転速度を扱う時はクォータニオンではなく、回転軸 (x,y,z) と回転速度 (degree) と分けて管理してそこからクォータニオンを⽣成します。 5.4 板野サーカスを⽬指すクォータニオンとオイラー⾓をざっくりと理解したところで、板野サーカスを⽬指します。テスト環境を作るアルゴリズムに取り組む前にテスト環境を整えます。テストを作ると同時にクラスの設計もざっくり⾏います。アルゴリズムをいろいろ試⾏錯誤するのでテスト環境がないと始まりません。テストがしやすいプログラムは、機能が分離されて役割がはっきりしているので良い設計です。オブジェクトの配置オブジェクトを配置します。地⾯、ミサイル、ランチャー、ターゲット、カメラです。括弧内は (クラス名) です。 • 地⾯ (Ground) : 移動している距離感がほしいのでまずは平⾯を地⾯として追加します。 • ミサイル (Missile) : 今回の主役のミサイルです。 • ランチャー (Launcher) : ミサイルを発射するものです。 • ターゲット (Target) : ミサイルが当たりにいく攻撃⽬標です。図 5.2: テスト環境クラスの追加先に配置したオブジェクトにつけるクラスを追加します。空っぽのまま、実装はまだ始めません。クラスに⼊れるべき機能は単独では決まらず、ほかのクラスとの関係性で決まります。 69

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.4 板野サーカスを⽬指す実装の前にクラスとクラスの関係を眺めて、プログラム全体をスケッチする感覚で進めます。オブジェクトごとに⼀通り追加したら、クラス設計の沼にはまらないうちに引き上げましょう。
最低限の動きをつけるミサイルを前進させるミサイルを単純に等速で前進させます。頭の中にあるすばらしい誘導アルゴリズムの実装に着⼿したい、そんな気持ちをぐっとおさえます。前進させた先にターゲットを置いて必ず重なるようにします。この段階ではただすり抜けます。リスト 5.3: Move1() void Update() { var step = Vector3.forward * this.speed * Time.deltaTime; transform.position = transform.position + step; } ターゲットにあたったら爆発させるミサイルがターゲットをすり抜けるのを⾒ていると、爆発してほしくなります。その欲求に従って当たり判定を作りましょう。いつもは RigidBody を使⽤して OnCollisionEnter で衝突を検知させます。しかし、物理挙動を⼊れると誘導が難しくなります。今回は単純に座標を transform.position に代⼊して動かしたいので、RigidBody は使⽤せずに Physics.BoxCast を使⽤して判定します。リスト 5.4: CheckHit1() // RigidBody を使わないで CheckBox を使って当たり判定をする。 void CheckHit1() { var t = transform; var isHit = Physics.CheckBox(t.position, t.localScale, t.rotation); if (isHit) { Explosion(t.position); } } この CheckHit1 では 2 つ問題が発⽣しました。 1 つ⽬の問題は、ミサイルがすり抜けました。移動速度が上がって 1 フレームに移動する距離が、 70

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.4 板野サーカスを⽬指すターゲットの⼤きさを超えるとすり抜けてしまいます。Physics.CheckBox はチェックした瞬間に
重なっていないと当たりません。そこで、すり抜け防⽌に Physics.BoxCast を使⽤します。Physics.BoxCast は始点と⽅向と⻑さを指定してチェックします。これにより 1 フレームの移動距離を⻑さにすることで、速度が上がっても必ず当たります。 2 つ⽬の問題は、爆発の発⽣がずれました。爆発は当たった時のミサイルの位置にでます。そこは、ターゲットから少し離れた位置です。当てた快感が物⾜りません。そこで、爆発をターゲットに密着させるため RaycastHit hitInfo を返す Physics.BoxCast を使⽤します。hitInfo.collider が当たったコライダです。コライダとミサイルの最近点に爆発を発⽣させます。それらを修正したコードが CheckHit3 です。リスト 5.5: CheckHit3() // 爆発が真ん中に来るように最近点を計算 void CheckHit3() { var t = transform; RaycastHit hitInfo; var direction = t.position - lastPosition; var length = direction.magnitude; var isHit = Physics.BoxCast( lastPosition, transform.localScale, direction, out hitInfo, t.rotation, length); Debug.DrawRay(lastPosition, direction, this.color, 1.0f); if (isHit) { var point = hitInfo.collider.ClosestPoint(lastPosition); Explosion(point); } } 当たった相⼿側のコライダの最近点に爆発を出すことでやってやった感が出ます。 71

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.4 板野サーカスを⽬指す図 5.3:
スクリーンショットミサイルを誘導させるターゲットの位置をずらすミサイルがターゲットにあたらないようにします。ミサイルがまっすぐターゲットの横を⾶んで⾏く様を⾒ていると、ぐいっと曲げて誘導させたい気持ちがふつふつと湧き上がってきます。ミサイルをターゲットに即時に向かせるまずは補間せずにターゲットの⽅向に即時に反映させます。リスト 5.6: CreateVector() // ターゲットと⾃分のポジションを引き算して⽅向ベクトルを作ります。 var v1 = targetPosition - myPosition; // その⽅向を向くクォータニオンを⽣成します。 var to = Quaternion.LookRotation(v1, Vector3.up); LookRotation はほとんどの場合はうまくいくのですが、特定の⽅向で安定しないのでやめました。特定の⽅向とは、v1 が Vector3.up に近付くときです。そこで、 FromToRotation を使⽤します。リスト 5.8: FromToRotation() var to = Quaternion.FromToRotation(Vector3.forward, v1); 72

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.4 板野サーカスを⽬指すミサイルをターゲットに徐々に向かせる今のミサイルの回転を
from, ⽬的の回転を to として、補間します。迷わず球⾯補間 (Quater- nion.Slerp) を使⽤します。線形補間 (Quaternion.Lerp) ではありません。球⾯補間のために Quaternion を使うと⾏っても過⾔ではありません。リスト 5.8: FromToRotation() transform.rotation = Quaternion.Slerp(transform.rotation, to, 0.05f); これでミサイルの⽅向が 1 フレームに 5% ずつ補間されます。このときに Z 軸周りの回転も⼊ります。ミサイルは問題ないのですが、キャラだと困ることがあります。⽅向の変化を割合ではなく⾓度で指定する 5% ずつ回転するということは、ミサイルの前⽅向とターゲットへの⽅向との差によって回転量が変化するということです。1 フレームに 90 度ずれているときは 4.5 度回転し、30 度ずれているときは 1.5 度回転します。これはバネで引っ張られるように回転します。そういう動きを⽬指すならそれで良いのですが、今回は⼀定の誘導性能をもたせます。ミサイルの誘導性能を x 度/秒で指定をします。つまり、「Slerp に指定する割合 = 誘導性能 / ミサイルの前⽅とターゲット⽅向のなす⾓」です。ミサイルの前⽅とターゲット⽅向のなす⾓を求めるのにちょうど良い、 Quaternion.Angle(from, to); という関数がありました。コードにしたのが CalcRotateRatio1() です。リスト 5.9: CalcRotateRatio1() // ⽬標⾓度と現在⾓度と回転能⼒から回転する割合を計算する。 static float CalcRotateRatio1(Quaternion from, Quaternion to, float degreeSpeed) { var r1 = degreeSpeed * Time.deltaTime; var r2 = Quaternion.Angle(from, to); var ratio = 0.0f; // ゼロ除算、微⼩な値での割り算を避ける if (r2 < Mathf.Epsilon || r2 <= r1) { ratio = 1.0f; } else { ratio = r1 / r2; } return ratio; } 73

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.4 板野サーカスを⽬指すこれを作っているとき、Quaternion.Angle 関数でハマりました。まったく誘導できませんでし
た。分かってしまえば原因は単純で、Quaternion.Angle の戻り値が Radian だと思いこんでいたのですが、Degree でした。Unity の Quaternion.Angle のドキュメントには ‘2 つの回転 a と b 間の⾓度を返します。‘ とあります。しかし、ドキュメントを英語に切り替えると "Returns the angle in degrees between two rotations a and b." と、はっきり degree と書いてあります。当たり前かもしれませんが、⾓度の単位は 2 種類あります。 1. Degree 1 周が 360 度という⼩学校で習う馴染み深い単位 2. Radian 1 周が 2 πという⾼校の数学 2B で習う、Sin,Cos の引数に渡す単位ミサイルっぽくするために加速させる物理的な条件を真⾯⽬に考えてみます。 1. 発射のときの速度は 0 です。 2. 推⼒により加速します。 3. 速度に⽐例して空気抵抗が強くなります。 4. 空気抵抗により加速度が落ちます。 5. 空気抵抗と推⼒が釣り合うところまで加速したら速度が⼀定になります。以上を真⾯⽬に計算する場合もありますが、制御しやすくするためと計算量を抑えるためにアルゴリズムはできるだけ簡略化します。今回は下記のように簡略化しました。 1. 発射のときの速度は 0 です。 2. 指定速度まで加速します。 3. 指定速度に達したら⼀定にします。ミサイルが遅いときに回転すると不⾃然加速機能を⼊れたことで新たな問題がでてきました。そこで CalcRotateRatio1 を修正します。 CalcRotateRatio1 の結果の回転速度に、その時の移動速度の最⼤速度に対する割合を乗算します。これで移動開始時は回転せず、加速とともに誘導性能が上がります。リスト 5.10: CalcRotateRatio2() static float CalcRotateRatio2(Quaternion from, Quaternion to, float degreeSpeed, float speed, float maxSpeed) { 74

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.4 板野サーカスを⽬指す var r1
= degreeSpeed * Time.deltaTime; var r2 = Quaternion.Angle(from, to); var ratio = 0.0f; if (r2 < Mathf.Epsilon || r2 <= r1) { ratio = 1.0f; } else { ratio = r1 / r2; } var adjusted = ratio * (speed / maxSpeed); return adjusted; } 板野サーカスを⽬指していろいろ動かすこの記事のメインである誘導ミサイルが動きました。ここからはこの誘導ミサイルを⼤量に放ち、敵も味⽅も動き回り、カメラがそれらを画⾯に納めるように動かします。設計の変更ここまでターゲットとランチャーを別々に使っていましたが、敵も味⽅も撃ちまくるのでプレイヤーとして統合しました。ミサイルが狙うターゲットはいろいろ存在できるように、ITarget としてインタフェースに切りだしました。このインタフェースを実装すれば誘導ミサイルが狙えます。リスト 5.11: ITarget public interface ITarget { Vector3 Position { get; } Vector3 Velocity { get; } } Velocity は今回使⽤していません。将来ミサイルを賢くするときに先読みさるために使います。ミサイルの⼤量発射ミサイルの発射に緩急が欲しくなったので、「連射する状態」「待機状態」を繰り返します。 75

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.4 板野サーカスを⽬指すカメラの移動プレイヤーから少し遅れてついていくように移動させます。位置関係をみて加速や減速の制御は
奥深いのですが、 Vector3.SmoothDamp を使えばだいたいよい感じに動きます。リスト 5.12: CameraContoller.Update() void Update() { var t = transform; // ターゲットの位置を少し遅れてついていくように注視点を動かす。 { var now = targetPosition; var to = this.target.position; targetPosition = Vector3.SmoothDamp( now, to, ref this.targetVelocity, this.targetPower); } // プレイヤーの位置とターゲットの位置からカメラの位置を決める { var now = t.position; var target_p = targetPosition; var player_p = this.player.position; var to_target = target_p - player_p; var q1 = Quaternion.LookRotation(to_target, Vector3.up); var to_p = player_p + q1 * positionOffset; t.position = to_p; } // 位置を決めてからターゲットを向かせる t.LookAt(targetPosition); } 最後に今回作成したデモは、板野サーカスっぽい雰囲気は出せたと⾃負しています。昔から何回か挑戦しては挫折していたことが、簡単にできてしまって驚きました。Unity が複雑な計算を実装してくれているので、活⽤⽅法さえ理解さえすれば、難しい数学の知識がなくてもよい感じに作れます。昔ベーマガというプログラム投稿雑誌に、「なんかわからないけど Sin を使うと曲線が書けるんだよね」って書いてありました。同様に「クォータニオンもよくわからないけどよい感じで回転ができるよね」と思ってもらえれば、この記事の⽬的は達成されます。現状の誘導ミサイルは単純です。必要であればもっとリアリティを⾼められます。⾓度から速度を直接計算するのではなく、重⼒や空気抵抗や推⼒から加速度を計算して速度を間接的に計算しま 76

第 5 章 Unity で板野サーカス -誘導ミサイルでクォータニオン⼊⾨- 5.4 板野サーカスを⽬指すす。そうすると、ミサイルの向きとは違う⽅向に移動したり、リアルな揺れが発⽣します。もちろん誘導する難易度はどんどん上がります。
繰り返しになりますが、Unity の Project を公開しています。 https://github.com/toymany/ missile 興味のある⽅はぜひ触ってみてください。ヤマヤタケシ/@toyman_jp 77

第 6 章⾮同期処理の速度問題と解決の試案本章では、Ruby プログラムの⾮同期処理の速度問題とその解決案を紹介します。 6.1 問題の内容ゲームの開発現場でよくありがちな課題の⼀つに⾮同期処理の速度改善があります。たとえば、同時接続ユーザー数と処理対象によっては⾮同期処理のキューが詰まるというようなケースです。
6.2 解決試案アプリケーション側の対処⽅法として以下の案を考えました。 • Resque を Sidekiq に変更する • Sidekiq クライアントは Ruby 版の Sidekiq を使⽤し、Sidekiq サーバは Crystal 版を使⽤する理由として第⼀に Crystal の強⼒な処理性能が挙げられます。プログラムの仕様によってパフォーマンスに幅がありますが、最⼤で 20 倍もの⾼速化を実現することも可能です。それによりキューの処理を⾼速化が期待できるからです。そして Crystal ⽤の Sidekiq や O/R マッパなどの使いやすいライブラリが豊富であることも理由として挙げられます。 6.3 検証環境実際に検証するにあたって以下の環境を構築します。 • Ruby on Rails 5 • Sidekiq(Ruby) • Sidekiq(Crystal) • MySQL 5.7 79

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証また本稿での Ruby、および Crystal のバージョンは以下の通りです。
• Ruby 2.5 • Crystal 0.26.0 6.4 検証サンプルのコードとして、ゲームアプリのミッションとその達成状況の判定を⾮同期で⾏うものを作成します。実際のコードはもっと条件が複雑ですが、今回はベンチマークが⽬的なので簡略化しています。 Rails アプリケーションの作成以下のテーブル構成で Rails のアプリケーションを作成します。テーブル名:users ユーザー ID 以外にも、ニックネームの情報がありますが今回は ID とランクのみ残して除外します。カラム名型説明 id serial ID rank integer ユーザーランクテーブル名:characters キャラクタの情報です。カラム名型説明 id serial ID name text キャラクタ名 element integer 属性（5 ⾊の⾊） rarity integer レアリティテーブル名:user_characters ユーザー保有のキャラクタの情報です。カラム名型説明 id serial ID user_id integer ユーザー ID character_id ingeter キャラクタ ID level integer キャラクタレベル luck integer 運 80

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証テーブル名:stages クエストのステージ情報です。カラム名型
説明 id serial ID diﬃculty integer ステージ難易度 (1~6) テーブル名:user_stages ユーザーがクリアしたステージの情報です。カラム名型説明 id serial ID user_id serial ユーザー ID stage_id serial ステージ ID cleared_at timestamp クリアした時間テーブル名:user_achievements ミッションの達成状況です。カラム名型説明 id serial ID user_id serial ユーザー ID achievement_id serial ミッション ID 達成すべきミッションとして以下を想定します。 • character_id 10 を運極達成 (Luck が 99) • character_id 20 をレベル最⼤にする • stage_id 4 のクエストをクリアしている • stage_id 7 のクエストをクリアしている • stage_id 9 のクエストをクリアしている • 超絶ステージ以上の難易度を 5 回以上クリアしている (stages の diﬃculty が 5 以上) 各々のミッション達成判定の発⽕条件は、キャラクタ関連ならキャラクタ合成時、クエストの達成はクエストクリア時に⾏われますが、今回は⼀律で⾏います。 Rails アプリケーションの作成以下⼿順で検証⽤のアプリケーションを作成します。 rails new td5demo -d mysql --skip-bundle bundle install --path vendor/bundle 81

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証各種テーブルを作成していきます。 bundle exec rails
g migration CreateUser rank:integer bundle exec rails g migration CreateCharacter name:text element:integer rarity:integer bundle exec rails g migration CreateUserCharacter user:references character:references \ level:integer luck:integer bundle exec rails g migration CreateStage difficulty:integer bundle exec rails g migration CreateUserStage user:references stage:references \ cleared_at:timestamp bundle exec rails g migration CreateUserAchievement user:references \ achievement_id:integer 作成後に実⾏します。 bundle exec rails db:create db:migrate Sidekiq を追加します。またバルクインポート⽤のツールも追加します。 gem ’sidekiq’ gem ’activerecord-import’ インストールします。 bundle install コンフィグを以下設定します。 conﬁg/initializers/sidekiq.rb Sidekiq.configure_server do |config| config.redis = { url: ’redis://127.0.0.1:6379’ } end Sidekiq.configure_client do |config| config.redis = { url: ’redis://127.0.0.1:6379’ } end ワーカのひな型を作成します。 82

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証 bundle exec rails g
sidekiq:worker Reviewer また⾃動ロードするパスの⼀覧にワーカを加えます。 conﬁg/application.rb config.autoload_paths += %W(#{config.root}/app/workers) 検証⽤のデータを投⼊します。検証のデータは以下の通りです。 • ユーザー数 : 1000 • キャラクタ数 : 200 • ユーザーが持つキャラクタ : 200 • ステージ : 10 • ユーザーがクリアしたステージ : 10 db/seeds.rb ActiveRecord::Base.transaction do # user 1000 ⼈分作成 (1..1000).each do User.create!(rank: [*90..99].sample) end # character200 種作成 (1..200).each do Character.create!(name: %w(char1 char2 char3 char4).sample, \ element: [*1..5].sample, rarity: [*1..5].sample) end # stage10 種 (1..10).each do Stage.create!(difficulty: [*4..6].sample) end user_ids = User.all.map { |user| user.id }.sort character_ids = Character.all.map { |char| char.id }.sort stage_ids = Stage.all.map { |stage| stage.id }.sort User.all.each do |user| # キャラクタ 200 種持つ (1..200).each do user.user_characters.create!(character_id: character_ids.sample, \ level: [*95..99].sample, luck: [*95..99].sample) end # ステージ 10 種クリアしている (1..10).each do 83

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証 user.user_stages.create!(stage_id: stage_ids.sample, cleared_at: Time.current)
end end end 達成判定を⾏います。 app/workers/reviewer_worker.rb class ReviewerWorker include Sidekiq::Worker def perform(id) id = id.to_i user = User.includes([user_characters: :character, user_stages: :stage]).find(id) logger.info "user_id: #{user.id} review start at: #{Time.current}" review(user) logger.info "user_id: #{user.id} review finish at: #{Time.current}" end def review(user) # キャラクタの判定 user_achievements = [] user.user_characters.each do |user_character| # character_id 10 を運極達成 (Luck が 99) if user_character.character.id == 10 && user_character.luck == 99 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 1) end # character_id 20 をレベル最⼤にする if user_character.character.id == 20 && user_character.level == 99 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 2) end end # ステージのクリア判定 clear_count = 0 user.user_stages.each do |user_stage| # stage_id 4 のクエストをクリアしている if user_stage.stage.id == 4 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 3) end # stage_id 7 のクエストをクリアしている if user_stage.stage.id == 7 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 4) end # stage_id 9 のクエストをクリアしている if user_stage.stage.id == 9 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 5) end # 超絶ステージ以上の難易度を 5 回以上クリアしている (stages の difficulty が 5 以上) if user_stage.stage.difficulty >= 5 clear_count += 1 84

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証 end end if clear_count
>= 5 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 6) end UserAchievement.import(user_achievements) end end Sidekiq(Ruby) でのパフォーマンスコンソールを⽴ち上げ以下のコードを実⾏します。 ids = User.all.map {|user| user.id} ; ids.each { |id| ReviewerWorker.perform_async(id) } Ruby の Sidekiq を起動します。コンカレンシーを 25 として設定します。 bundle exec sidekiq -c 25 -L log/sidekiq.log ログの⼀番最初と最後は以下の通りです。 2018-08-19T06:29:17.564Z 93963 TID-oum8sv0of ReviewerWorker \ JID-f31af8215084975af303aeb3 INFO: user_id: 22 review \ start at: 2018-08-19 06:29:17 UTC （中略） 2018-08-19T06:30:03.221Z 93963 TID-oum8kqpff ReviewerWorker \ JID-35f78a22ed0a47c7fd29a568 INFO: user_id: 993 review \ finish at: 2018-08-19 06:30:03 UTC 差分を取ると、45 秒程です。 Crystal による Sidekiq サーバの構築 Crystal による Sidekiq サーバを構築します。 85

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証 crystal init app td5democr
shard.yml に以下の内容を追記します。 shard.yml dependencies: sidekiq: github: mperham/sidekiq.cr version: 0.7.0 granite: github: amberframework/granite version: 0.13.0 mysql: github: crystal-lang/crystal-mysql 記載後に以下実⾏します。 shards install AmberFramework とその OR/M Crystal の O/R マッパは Granite を使⽤します。AmberFramework プロジェクトの成果物として⽇々更新されています。 AmberFramework*1とは Rails ライクな Crystal の Web フレームワークです。現時点で最新のバージョンは 0.9.0（2018 年 8 ⽉ 31 ⽇時点）となっています。 AmberFramework で主に使⽤可能な OR/M は以下の 3 種類があります。 • Granite – https://docs.amberframework.org/granite/ • Crecto – https://www.crecto.com • Jennifer – https://github.com/imdrasil/jennifer.cr Granite は Amber のプロジェクトの派⽣物です。Crecto は Elixir の Web フレームワーク「Phoenix」で使⽤される OR/M「Ecto」に影響されて作られた OR/M です。 *1 https://amberframework.org 86

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証 Jennifer はあまり詳しく⾒ていませんが、Migration で DSL
を使⽤できたりなど、Granite よりやや Rails 寄りになっているように思えます。本稿では公式プロジェクト派⽣の Granite を使⽤していきます。モデル層の作成モデル層のファイルを以下⼿動で作成します。 src/td5democr/models/character.cr class Character < Granite::Base adapter mysql has_many :user_characters field name : String field element : Int32 field rarity : Int32 end src/td5democr/models/stage.cr class Stage < Granite::Base adapter mysql has_many :user_stages field difficulty : Int32 end src/td5democr/models/user.cr class User < Granite::Base adapter mysql has_many :user_characters has_many :user_stages has_many :user_achievements field rank : Int32 timestamps end src/td5democr/models/user_achievement.cr class UserAchievement < Granite::Base adapter mysql belongs_to :user field achievement_id : Int32 timestamps end 87

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証 src/td5democr/models/user_character.cr class UserCharacter <
Granite::Base adapter mysql belongs_to :user belongs_to :character field level : Int32 field luck : Int32 timestamps end src/td5democr/models/user_stage.cr class UserStage < Granite::Base adapter mysql belongs_to :user belongs_to :stage field cleared_at : Time timestamps end Crystal ⽤の Sidekiq サーバを作成します。 src/td5democr.cr require "sidekiq/cli" require "sidekiq/api" require "granite/adapter/mysql" Granite::Adapters << Granite::Adapter::Mysql.new({name: "mysql", url: "#{ENV[DB_URL]}"}) require "./td5democr/worker/*" require "./td5democr/models/*" class SomeClientMiddleware < Sidekiq::Middleware::ClientEntry def call(job, ctx) ctx.logger.info "Pushing job #{job.jid}" yield end end class SomeServerMiddleware < Sidekiq::Middleware::ServerEntry def call(job, ctx) ctx.logger.info "Executing job #{job.jid}" yield end end 88

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証 cli = Sidekiq::CLI.new server
= cli.configure do |config| config.server_middleware.add SomeServerMiddleware.new config.client_middleware.add SomeClientMiddleware.new end cli.run(server) Ruby 同様に Sidekiq ワーカを作成します。感覚的に、ほぼ Ruby と同様であることがわかります。 src/td5democr/workers/reviewer_worker.cr class ReviewerWorker include Sidekiq::Worker def perform(id : Int32) user = User.find(id) if user logger.info "user_id: #{user.id} review start at: #{Time.now}" review(user) logger.info "user_id: #{user.id} review finish at: #{Time.now}" end end def review(user : User) user_characters = UserCharacter.all("where user_id = ?", ["#{user.id}"]) user_stages = UserStage.all("where user_id = ?", ["#{user.id}"]) characters = Character.all stages = Stage.all user_achievements = [] of UserAchievement # キャラクタの判定 user_characters.each do |user_character| character = characters.find {|c| c.id == user_character.character_id} if character # character_id 10 を運極達成 (luck が 99) if character.id == 10 && user_character.luck == 99 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 1) end # character_id 20 をレベル最⼤にする if character.id == 20 && user_character.level == 99 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 2) end end end # ステージのクリア判定 clear_count = 0 user_stages.each do |user_stage| stage = stages.find {|s| s.id == user_stage.stage_id} 89

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証 if stage # stage_id
4 のクエストをクリアしている if stage.id == 4 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 3) end # stage_id 7 のクエストをクリアしている if stage.id == 7 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 4) end # stage_id 9 のクエストをクリアしている if stage.id == 9 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 5) end # 超絶ステージ以上の難易度を 5 回以上クリアしている (stages の difficulty が 5 以上) if difficulty = stage.difficulty if difficulty >= 5 clear_count += 1 end end end end if clear_count >= 5 user_achievements << UserAchievement.new(user_id: user.id, achievement_id: 6) end UserAchievement.import(user_achievements) end end Sidekiq(Crystal) のパフォーマンス今度は Ruby の Sidekiq を停⽌した状態で Crystal の Sidekiq を実⾏し、以下のタスクを実⾏します。 crystal build src/td5democr.cr ./td5democr -c 25 >> sidekiq.log 2018-08-18T17:30:01.393Z 92025 TID-236ow3k JID=33ae9aedb6dda73fcab949b1 \ INFO: user_id: 1 review start at: 2018-08-19 02:30:01 +09:00 （中略） 2018-08-18T17:30:24.586Z 92025 TID-236oum8 JID=a80e4816f47b174fbc0da85f \ INFO: user_id: 998 review finish at: 2018-08-19 02:30:24 +09:00 90

第 6 章⾮同期処理の速度問題と解決の試案 6.4 検証 23 秒程で全件完了しました。Ruby に⽐べるとおよそ 2
倍ほどの速度になります。まとめたしかに⾼速化が達成できていることは確認できました。Crystal 側では DB チューニング（コネクションプールなど）をほぼデフォルトのまま⾏ったのでこのあたりのチューニング次第ではさらに性能が出せるかと思いますが、プログラムの実⾏速度差でいうと期待していたほど（最⼤の 20 倍）ではありませんでした。また実⾏環境がローカルだったのでアプリケーションと DB との通信は UNIX ソケットで⾏われていましたが、ネットワーク環境ではさらに遅延が⽣じ、実⾏速度差はもっと縮まるのではないかと予測されます。 91

著者紹介⾓⿓徳 (1 章担当, GitHub: Blasthal, Twitter: @Blasthal) 魂をゲームに捧げているゲームエンジニア。モンストでは主にストライクショットや友情コ
ンボなどの実装を担当している。エンジニアリングだけでなく、企画、イラスト、モデル、アニメーション、サウンドなどなど、ゲーム制作に関係すること全般に頭から⾶び込んでいく。⽬下の⽬標は、Blender でキャラを⾃作しゲームリソースとして完成させること。誰かが作り⽅教えてくれたらなー。教えてくれればなー。安⾥⼤志 (2 章担当) 良い QA チームを作ることをお仕事にしています。格ゲー部の部⻑もやってます。井本⼤登 (3 章担当, GitHub: adarapata, Twitter: @adarapata) ⾮ゲームのサーバサイド、Android アプリを開発してたけど趣味が⾼じて最近 Unity のクライアントエンジニアになりました。設計とかチームビルディングとかガルパンが好きです。松原信忠 (4 章担当, GitHub: matsubara0507) 所属はモンストサーバチームで Ruby を書いてる。プログラミングが好きで、普段は推し⾔語の Haskell で遊んだり、新しいプログラミング⾔語を勉強したりしている。Haskell-jp や Elm-jp でちょこちょこ活動もしている。ヤマヤタケシ (5 章担当, GitHub: toymany, Twitter: @toyman_jp) 早いものでゲーム業界に⼊って 17 年経ちました。近年はスマホ⽤のゲーム開発プロジェクトに参加しています。趣味でアナログカードゲームを作ったりゲームアプリを作ったりしています。内⽥将之 (6 章担当, GitHub: msky026, Twitter: @msky026) モンストのサーバとか⾒てる⼈。Crystal-JP の中の⼈でもある。最近は Unity に強い関⼼がある。 93

付録著者紹介⼟屋雅 (表紙・デザイン全般, note：miyabt, Twitter：@miyabt_) 普段は web
やアプリを作っているデザイナーです。UI や UX を考えるのがとっても好きです。個⼈的な趣味で同⼈誌を作っているので今回デザインを担当させていただきました杉⽥絵美 (プロジェクト推進・制作進⾏等の庶務, GitHub: esugita, Twitter: @semiemi7) 元エンジニアで、ミクシィでは、Perl を触ったり、アプリを触ったり、新規事業の PM をしたりして、今は、DevRel チームで各種イベントを企画・運営したり、技術的な知⾒のアウトプット活動をサポートしたりしています。喜多功次 (制作アシスト, Twitter: @kojikita) DevRel チームで勉強会やイベントの運営などをしています。元エンジニアで以前は web フロント側のサービス開発やアドテクなどを担当していました。JavaScript が好きで、最近は PWA に注⽬しています。 94

XFLAG Tech Note 2018 年 10 ⽉ 8 ⽇初版第 1
刷発⾏著者株式会社ミクシィ XFLAG スタジオ発⾏所株式会社ミクシィ印刷所⽇光企画 (C) XFLAG

XFLAG Tech Note Vol.01

XFLAG Tech Note Vol.01

More Decks by MIXI ENGINEERS

Other Decks in Technology

Featured

Transcript