XFLAG Tech Note Vol.01 - Speaker Deck

Slide 1

Slide 1 text

No content

Slide 3

Slide 3 text

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

Slide 5

Slide 5 text

⽬次まえがき 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

Slide 12

Slide 12 text

第 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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

第 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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 21

Slide 21 text

第 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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

第 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

Slide 24

Slide 24 text

第 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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

第 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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

第 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

Slide 34

Slide 34 text

第 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

Slide 36

Slide 36 text

第 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

Slide 38

Slide 38 text

第 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 _entities; public CharacterRepository(ILoader loader){ _entities = loader.Load(); } public CharacterEntity GetById(int id) { return _entities.FirstOrDefault(c => c.id == id); } public void AddCharacter(CharacterEntity newCharacter) { _entities.Add(newCharacter); } } 例では Entity ⼀覧を保持し、取得したり追加したりしてます。また、キャッシュの役割も担って 32

Slide 39

Slide 39 text

第 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

Slide 42

Slide 42 text

第 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

Slide 45

Slide 45 text

第 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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

第 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

Slide 54

Slide 54 text

第 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

Slide 55

Slide 55 text

第 4 章 git challenge を⽀える技術 4.2 問題の例 $ git show 85afeb1 commit 85afeb146104cc0d3f539ce34e3ec1ab6f8dcf99 (HEAD -> task-1, origin/task-1) Author: Kuniwak 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

Slide 57

Slide 57 text

第 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

Slide 58

Slide 58 text

第 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

Slide 61

Slide 61 text

第 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

Slide 62

Slide 62 text

第 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

Slide 63

Slide 63 text

第 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

Slide 64

Slide 64 text

第 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

Slide 66

Slide 66 text

第 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

Slide 73

Slide 73 text

第 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

Slide 74

Slide 74 text

第 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

Slide 76

Slide 76 text

第 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

Slide 79

Slide 79 text

第 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

Slide 80

Slide 80 text

第 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

Slide 82

Slide 82 text

第 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

Slide 99

Slide 99 text

著者紹介⾓⿓徳 (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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text