XFLAG Tech Note vol.02

XFLAG Tech Note vol.02 株式会社ミクシィ XFLAG スタジオ有志著 2019-04-14 版
株式会社ミクシィ発⾏

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

⽬次まえがき i 第 1 章「ドラクリヤ・バレット」の作成事例 1 1.1 「ドラクリヤ・バレット」の名を知るのは実装完了後
. . . . . . . . . . . 1 1.2 コードを書くだけが、実装じゃない . . . . . . . . . . . . . . . . . . . . . 2 1.3 ライフルってカッコイイよね . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 ガトリングもカッコイイよね . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5 読了ありがとうございました . . . . . . . . . . . . . . . . . . . . . . . . 14 第 2 章 XFLAG Academy アプリ 15 2.1 始めに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 今回使⽤した環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3 アプリの設計と開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 運⽤と改善 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5 総括 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 第 3 章ファイトリーグにおける Unity のシーンアセット最適化 24 3.1 始めに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2 想定読者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3 読者が得られる知⾒ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4 Lightmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.5 Mesh 結合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.6 ポリゴンのソート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.7 Index のソート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.8 他にやれること . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 第 4 章ファイトリーグ環境を OpenAI Gym で構築した話 47 4.1 始めに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 ii

⽬次 4.3 ファイトリーグのバトルシステム . . . . . . .
. . . . . . . . . . . . . . . 48 4.4 Gym インタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.5 実装前の準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.6 実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.7 実装後に起きた問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.8 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 61 5.1 はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.2 使⽤する⾔語やアプリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3 MML を鳴らす . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.4 MML から wav を⽣成する . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.5 Elixir から MML を⽣成する . . . . . . . . . . . . . . . . . . . . . . . . 65 5.6 関数⾔語で⾳楽を表現する . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.7 ハマったこと . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.8 感想とまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.9 成果物の場所 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 著者紹介 72 iii

第 1 章「ドラクリヤ・バレット」の作成事例本章では、モンストに登場するストライクショット「ドラクリヤ・バレット」の実装事例を紹介する。実装を担当したクライアントエンジニアである⾓⿓徳（かくたつのり）が紹介するのだが、読み終わってから後悔することが少なくなるように、先にいくつかの留意点を記載しておく。 • モンストについて、ある程度プレイしたことのある知識や経験が前提となる
• 実装を担当したクライアントエンジニアの⽬線のみの話しかない • いろいろな都合で省略されているところがあり、期待している部分がないかもしれない • フランクな⽂章である • これはフィクションではないストライクショットはいわゆる必殺技のようなもので、その仕様は当然ゲーム性と密接に関わる。そのため、ゲームそのものを知らないと理解が難しいかもしれない。無料で DL できるので実際に遊んでみても良いし、すでに遊んでいる友⼈に読ませても良いし、動画検索をして閲覧しても良いだろう。もっと詳しく話を聞きたいな、とか、気になったので質問してみたい、とかがあれば、おそらく巻末に載っているであろう SNS のアカウント宛てに聞いてほしい。 1.1 「ドラクリヤ・バレット」の名を知るのは実装完了後ユウナが使うストライクショット今回紹介するストライクショットは「ヴァンパイアの少⼥ユウナ」が使⽤する「ドラクリヤ・バレット」だ。ユウナは、劇場版第２弾であるソラノカナタに登場した名称通りヴァンパイアの少⼥で、銃に変形する棺桶を担いでいる。 1

第 1 章「ドラクリヤ・バレット」の作成事例 1.2 コードを書くだけが、実装じゃない図 1.1: ヴァンパイアの少⼥ユウナ
劇中でも幾度か変形して撃つシーンがあり、「ドラクリヤ・バレット」の仕様もこれを参考にしている。この変形だが、おもしろいことにガトリング形態とライフル形態の２種類がある。当初の案件ではこのどちらかだったのだが、制作途中のシーンを⾒たり設定資料集を確認したり、開発陣営内で仕様を揉んでいる間に「両⽅使えたら良いんじゃね？」ということになった。普段なら１キャラ１ストライクショットだが、今回の仕様ではストライクショットを２つ作って１キャラが使⽤するため、単純に物量が２倍に増えている。そのぶん実装にかかる⼯数も増えてしまうのだが、棺桶が２種類の銃形態に変形して撃つというロマンの前には些細な問題だ。 1.2 コードを書くだけが、実装じゃないストライクショット作成の⼤まかな流れは以下の通りで、今回のドラクリヤ・バレットも例にもれない。こまかな違いはあれど、ゲームのメカニクスを実装する際はモンストに限らず似たようなフローをたどるだろう。 • 企画要件、仕様の確認 • モックアップの作成 • 開発実装 • QA チェック 2

第 1 章「ドラクリヤ・バレット」の作成事例 1.2 コードを書くだけが、実装じゃない • 最終確認企画要件、仕様の確認仕様は企画の⽅からある程度決められたものが挙がってくる。VFX
チームも含めて、実装できるのかどうか、どう実装するのか、などを話し合い、期間内に実装できるよう落とし所を探っていく。本件のストライクショットの仕様を⼀部列挙すると以下の通りだ。 • 速度と攻撃⼒が上がって動き回る • 停⽌時に最初に触れた敵の位置に攻撃 • ガトリングとライフルの振り分けは対象の⽅向で決定 • 対象の敵の HP が 0 になっても同じ位置に撃ち続ける • 弾は貫通する • 属性はキャラに依存する今回の案件の基本的な挙動はガトリングとライフルに分かれることを覚えておこう。モックアップの作成たとえば、ガトリングといえば連続で弾丸を撃ちまくる挙動を思い浮かべるが、この想像がゲーム内に実装された時に企画側との想定と正しいかどうかの共有をする為にも、ある程度の出来で画⾯上に表⽰するのが先決だ。想定通りで何も仕様に変更がなければそれで良いが、違えば仕様の変更も⼗分にある。しっかりと実装するには時間がかかるもので、その後で仕様が変わると実装のほとんどが無駄になってしまうことも少なくない。「本当にこれで良いのか？」と不安な状態で実装を続けるのも精神的につらいものがあるので、早い段階で動くものを共有できることは重要だ。この為にまずは「モックアップ」と呼ばれるものを作る。現場ではよく「モック」と略称されるもので、コードや素材はテキトーでかまわないのでとりあえず動くものを⾒れる状態まで作り上げる。いざコーディングをしてみるとその時になって気付くことも多いので、エンジニア側としても設計がしやすくなる。問題なければテキトーに書いたコードを消してから書き直したり、そのまま整えて調整したりする。実装の途中でも気になったことはどんどん詰めていくべきだ。想定はしていたが記載されていなかった仕様や、まったく想定されていなかった仕様は訊かないと分からないので、分からないなら確認しておくと経験上良いことにつながりやすい。決まったことはほかの⼈が触れられる範囲に書きとどめておくことを強く勧める。⼝頭で話した内容は忘れてしまうもので、数⽇経過してから挙動を⾒直すと「どうしてこんな仕 3

第 1 章「ドラクリヤ・バレット」の作成事例 1.2 コードを書くだけが、実装じゃない様になったんだっけ？」とまったく思い出せず、余計な時間を割くことになるからだ。そればかりか数ヵ⽉経過すると実装したのが⾃分かどうかすらも怪しくなってくる。円滑な QA のためにも、不具合の修正を⾏うことになった⾃分以外の⼈のためにも、未来の⾃分の
ためにも残しておこう。開発実装ここまで読んでいる⼈にとって⼀番気になっていると思われるこの項だが、後の節で少し詳細に話す。モックアップも開発実装の範囲ではあるが明確な線引きがあるわけでもないので、そのまま本実装に雪崩れ込むことが多い。 QA チェック QA とは「Quality Assurance」の略で直訳すると「品質保証」となる。リリースされたことを想定して、実装した「ドラクリヤ・バレット」が正しく動くかどうかの確認はもちろんのこと、モンストをプレイ中に発⽣するさまざまなケースを組み合わせても問題ないかも確認する。ゲームが進⾏不能や強制終了にならなければ良いということはなく、特定のマップでは演出が⾒づらいが良いのかどうか、⾒た⽬は既存の挙動と同じように⾒えるがダメージの発⽣タイミングが 1 フレーム違うのは良いのかどうか、という細かな指摘もしてくれる。これら QA を専⾨に⾏う QA チームの存在は⾮常に⼤切だ。開発中に決まった仕様や挙動は申し送り事項として伝えると、QA が円滑に進むので忘れずにメモしておこう。最終確認⾒事 QA チェックを通過したら、企画や VFX に最終確認をしてもらい、実装完了となる。実際にユーザーの⼿元で操作されるリリースの⽇を待つだけだ。不具合が出ないことを祈ろう。 4

第 1 章「ドラクリヤ・バレット」の作成事例 1.3 ライフルってカッコイイよね 1.3 ライフルってカッコイイよね図 1.2:
ライフル形態ライフル形態になる条件ガトリング形態になるか、ライフル形態になるか、これは対象の⽅向で決定するという仕様だった。どの⽅向へ向いた時、どの形態になるのだろうか。敵との距離が近ければガトリングになり、遠ければライフルになる？⾃分の残り HP？敵にあたった回数？判定に使おうと思えば使える数値はいくつもあるが、好き勝⼿に決めるわけにはいかない。企画との仕様確認が必要だ。確認の結果「敵の位置が⾃分より画⾯右側だとライフル、画⾯左側だとガトリングになる」に決定した。これは、⾃分から⾒て敵への⽅向ベクトルを求めた後に X 成分を⽐較すれば判定できる。リスト 1.8: ライフル形態かガトリング形態かの判定をする 1: // myPosition : ⾃分の位置 5

第 1 章「ドラクリヤ・バレット」の作成事例 1.3 ライフルってカッコイイよね 2: // enemyPosition :
敵の位置 3: // toEnemy : 敵⽅向へのベクトル 4: Vector2 toEnemy = enemyPosition - myPosition; 5: if (0.0f <= toEnemy.x) 6: { 7: // ライフル形態！ 8: } 9: else 10: { 11: // ガトリング形態！ 12: } 上記は擬似コードだが、イメージは伝わっただろうか。シンプルな仕様のおかげで処理もシンプルにできた。後はそれぞれの弾の挙動を実装していこう。もしかすると中には「距離が近ければガトリング、遠ければライフルの⽅が良かったのでは？」と思う⼈もいるかもしれない。僕もそう考えていた内の⼀⼈だったので、実際に距離基準の判定を実装して試してみたのだが、どの距離からガトリングになるのかライフルになるのか納得感がなかったので却下している。結果だけ⾒れば時間としては無駄だったが、実際に試して⽐較するというのは判断がしやすく、当初の案件より良くなる可能性もあるのでどんどん試していこう。とはいえ、なんでもかんでも試せるほどの余裕はないので、試すのは「こうした⽅がもっとおもしろくなるのではっ」と情熱に突き動かされた時にしておこう。ライフルの弾道挙動今回ライフルで放たれる弾は、⾼速で貫通する弾が１発だけだ。弾のコリジョンと敵のコリジョンが接触するとダメージが発⽣するのは既存処理に任せられるので、コリジョンの置き⽅さえ気を付ければ良い。ライフルの先端から画⾯の外に出るまでカンマ数秒しかないので、物理的に速度を持たせて直線運動させず、弾道上にカプセル型のコリジョンを瞬間的に置くようにした。始端がライフルの先端になるので、キャラからは敵⽅向に向かって少しズラす必要がある。終端は敵⽅向に向かってズラす量を多くするだけだ。リスト 1.8: コリジョンの配置を求める 1: // myPosition : ⾃分の位置 2: // enemyPosition : 敵の位置 3: // startPosition : コリジョン始端の位置 4: // endPosition : コリジョン終端の位置 5: Vector2 toEnemy = enemyPosition - myPosition; 6

第 1 章「ドラクリヤ・バレット」の作成事例 1.3 ライフルってカッコイイよね 6: Vector2 toEnemyDir =
toEnemy.Normalize(); 7: 8: const float START_DISTANCE = 50.0f; 9: const float COLLISION_LENGTH = 600.0f; 10: Vector2 startPosition = toEnemyDir * START_DISTANCE + myPosition; 11: Vector2 endPosition = toEnemyDir * COLLISION_LENGTH + startPosition; 始端がどれくらいズレるかはライフルのエフェクト次第となるので、パラメータのように const 化している。VFX チーム*1と顔を付き合わせながら調整する際は数値調整で済ませられるようにしておくと、お互い費やす時間を抑えられて効率が上がる。弾道と⾔う割には運動挙動がまったくないが、単純な処理で仕様が実現できるなら単純な処理で済ませた⽅が分かりやすくて不具合も出にくい。ユーザーはコードを⾒ながらゲームをするわけではないので、コードがいかにキレイだったとしても表⽰が変わらないのであればゲームの質は上がっていないのだ。余談だが、僕も保守性を⾼く保とうとキレイなコードを求めるあまりに、キレイなコードを書くことそのものが⽬的になってしまう時がある。適切なコードは仕様によってまったく違うものになるので、そんな時はいったん⼿をとめて、落ち着いて⾒直して⾒ると気付けることが多い。ライフルの表⽰画⾯に表⽰するための素材は VFX チームが同時並⾏して作成している。想定している表⽰演出を実現するためには、どの部分を VFX 側が担当し、どの部分をコード側が担当するのか相談する必要がある。敵の位置によって向きが変わるものに、VFX 側で 360 度分パターンを⽤意してもらうのは効率が悪すぎる。正位置に向けた銃⼝をコード側で回転させてやれば、1 つのパターンで済ませることができ、⼩数点未満の微妙な⾓度にも対応できる。ライフルはまさしくこのケースだ。演出想定はこうだ。 • 初期の棺桶状態は正位置で表⽰する • ライフル状態になった時に敵の⽅向に向ける正位置から瞬間的に敵の⽅に向けてしまうと違和感が拭えないので、敵の⽅向に向けるための回転を補間することにした。補間機能は昨今のエンジンやライブラリになら標準で⽤意されていると思う。もしなければ「Easing」や「Tween」などの単語で検索して、実績 *1 ビジュアルエフェクトを専⾨に作るチーム 7

第 1 章「ドラクリヤ・バレット」の作成事例 1.3 ライフルってカッコイイよねあるライブラリの導⼊を検討したり、オープンソースを参考に移植をするなりしよう。敵への⽅向は 2D ベクトルで求められるので、その値から⾓度を算出しよう。算出する
には逆正接関数「atan2(y,x)」 *2を使う。atan2(y,x) は、点 (0,0) から点 (x,y) までの半直線と、正の x 軸の間の平⾯上での⾓度を求めてくれる。返ってくる値はラジアン単位なので注意しよう。リスト 1.8: 対象の敵への⾓度を求める 1: // myPosition : ⾃分の位置 2: // enemyPosition : 敵の位置 3: Vector2 toEnemy = enemyPosition - myPosition; 4: Vector2 toEnemyDir = toEnemy.Normalize(); 5: 6: float toEnemyRotation = atan2(toEnemyDir.x, toEnemyDir.y); atan2(y,x) の第⼀引数に x 座標を渡して第⼆引数に y 座標を渡しているのは間違ったわけではない。x と y を逆にすると、点 (0,0) から点 (x,y) までの半直線と、正の y 軸の間の平⾯上での⾓度を求めてくれる。また、反時計回りが正⽅向だったのに対し、時計回りが正⽅向になる。これは 12 時⽅向が正位置の時計回りと⼀致するので、エフェクトの回転値とも⼀致し、計算がしやすくなる。敵に向ける⾓度が分かったら、0 度から補間した値をライフルに適⽤していく事で滑らかに敵⽅向に向けてくれる。何秒で向けるか、向ける速さはどれくらいか、などをエフェクトと⾒⽐べたり VFX チームと⼀緒に調整したりすれば完了だ。 *2 環境によっては atan2(x,y) の場合もあるらしい 8

第 1 章「ドラクリヤ・バレット」の作成事例 1.4 ガトリングもカッコイイよね 1.4 ガトリングもカッコイイよね図 1.3:
ガトリング形態ガトリング形態になる条件必ずどちらかに変形することになるので、ライフル形態にならないならガトリング形態になる。判定処理は「ライフル形態になる条件」の項で説明したのでここでは割愛させてもらいたい。⾮常にまれなケースだが、キャラと敵の位置関係がちょうどピッタリ真上や真下などの場合、x 座標が 0 になるので右側なのか左側なのか判断が付かない。仕様としては、ルールが決まっていればライフルでもガトリングでもどちらでもかまわないとのことだったので、判定を「<」から「<=」にするだけのライフル形態になるようにした。万が⼀、ライフルもガトリングも撃たずに何もせず進⾏不能になる⽅が恐ろしいので、不明なケースは必ず確認しておこう。 9

第 1 章「ドラクリヤ・バレット」の作成事例 1.4 ガトリングもカッコイイよねガトリングの弾道挙動モンストには弾を連続で発射する挙動がすでに存在する。プレイしたことのある⼈なら、バラージショットガン、ソリッドバレット、オールレンジバレットなどを思い出してもらえれば想像しやすいと思う。既存の処理があるならそれに倣う⽅が良い。
図 1.4: オールレンジバレットガトリングもライフルと同じように砲⾝のぶんだけ射出位置をズラす必要がある。算出⽅法も「ライフルの弾道挙動」の項と同じということで、気になる⽅はそちらを⾒直してほしい。発射された弾の⼀つ⼀つは、発射時の⾓度そのままに直線運動で移動していき、敵を貫通していく。ガトリングの弾はライフルの弾と違って⽬で追えるほどの速さで動くので、毎フレーム位置に移動量を⾜し込んで更新していく必要がある。リスト 1.8: 弾の運動 1: // Vector2 bulletOldPosition : 弾の前回位置 2: // Vector2 bulletPosition : 弾の現在位置 10

第 1 章「ドラクリヤ・バレット」の作成事例 1.4 ガトリングもカッコイイよね 3: // Vector2 bulletVelocity
: 弾の速さ 4: // float deltaTime : 経過時間 5: bulletOldPosition = bulletPosition; 6: bulletPosition += bulletVelocity * deltaTime; deltaTime の乗算を忘れないようにしよう。忘れてしまうと携帯端末のフレーム更新に依存してしまうので、低スペック端末と⾼スペック端末とで挙動が変わってしまうからだ。位置に速さを⾜し続けるという素直な⽅法だが、等速で弾が⾶び続ける仕様のためシンプルに収まっている。もし徐々に加速させたければ等加速度直線運動の公式に当てはめるだけで実現できる。等加速度直線運動の公式は覚えているだろうか。覚えていなくても調べればすぐに分かるので問題ない。僕は⾃分の記憶に⾃信がないので毎回調べている。リスト 1.8: 等加速度直線運動の公式の⼀つ 1: // v : 速度 2: // v0 : 初速度 3: // a : 加速度 4: // t : 経過時間 5: v = v0 + a * t 算出された速度 v に正規化した⽅向ベクトルを乗算し、位置に⾜し込めば移動させることができる。時間経過によって速度が変わらない場合は加速度 a が 0 になるので、今回のガトリングの弾と同じく等速になる。専⽤のヒットエフェクトを表⽰するガトリングの弾が敵にヒットした時に、劇中と同じようなヒットエフェクトを表⽰しよう。エフェクトそのものは VFX チームが作成してくれるので、ヒットした箇所でエフェクトを再⽣するだけで済む。しかし、ヒットした箇所に同じエフェクトを何度も出すと単調に⾒えてしまう。そこで、エフェクトの表⽰する位置を、ヒットした箇所を中⼼とした⼀定範囲の円内から決めるのはどうか、と提案してみた。⼩数の乱数を⽣成する機能はライブラリやエンジンに標準機能としてあることが多いが、円形の範囲から求めてくれるものは多くない。モンストの環境では⼩数の乱数を求める機能しかないため、⾃作することになった。当時の僕は、特定の半径の円内から乱数を⽣成する⽅法を知らなかった。ぼんやりと考えていたのは「円だから極座標を使ったらすぐ求められるんじゃないか」ということだけだ。極座標は覚えているだろうか。単語さえ聞き覚えがあるなら検索できるので⼤丈夫だ。 11

第 1 章「ドラクリヤ・バレット」の作成事例 1.4 ガトリングもカッコイイよねリスト 1.8: 極座標から直交直線座標への変換 1:
// r : 動径 2: // θ : ⾓度 3: x = r * cos(θ ) 4: y = r * sin(θ ) この式から円内の点を取得できるので、動径 r と⾓度θにそれぞれ成分となる乱数を⽣成すればいけるだろうと考えた。リスト 1.8: 円内から乱数を⽣成する（NG 版） 1: // R : 範囲円の半径 2: // PI : 円周率 3: // r : 動径 4: // theta : ⾓度 5: // rand() : 乱数⽣成関数 [0.0f ~ 1.0f] 6: // hitPosition : ヒットした位置 7: float r = rand() * R; 8: float theta = rand() * (2 * PI); 9: 10: float x = r * cos(theta); 11: float y = r * sin(theta); 12: Vector2 effectPosition = Vector2(x, y) + hitPosition; よーしできたできた。弾が敵にヒットしたら上記の式から位置を算出し、エフェクトを再⽣すれば良い。だが、これでは不⼗分だった。何度もヒットエフェクトを⾒ている内にだんだんと違和感を持ち始めていたのだが、どうも円の中⼼付近に表⽰されやすい気がしていた。実際に上記の式で数千回プロットしてみると、中⼼付近に点が集中することが⾒て分かる。半径 4 の円で試した結果が次の図だ。 12

第 1 章「ドラクリヤ・バレット」の作成事例 1.4 ガトリングもカッコイイよね図 1.5: 中央に集中してしまっているどうすれば良いだろうか。結果を先に伝えると、動径
r には円の半径を 2 乗して平⽅根を取ったものにすれば良い。リスト 1.8: ヤコビアンを加味する 1: // sqrt() : 平⽅根を求める関数 2: float r = sqrt( rand() * R * R ); 図 1.6: ⼀様に分布するようになったなぜそうなるかの説明には⼤学数学のヤコビアン周りが絡んでくるので、気になる⽅は調べてほしい。正直なところ付け焼き刃の僕の知識では誤解を与える可能性が⾮常に⾼い。より詳細により分かりやすく説明してくれる⼈がいるインターネットの情報を閲覧した⽅はるかに信憑性が⾼いだろう。 13

第 1 章「ドラクリヤ・バレット」の作成事例 1.5 読了ありがとうございましたなお、根号計算が速度的に気になったので、精度を若⼲落としつつも⾼速な根号計算に交換することも考えていた。実際に試したところ処理負荷は問題なさそうだったので根号計算はそのままに、低スペック端末でも問題ないか QA
の申し送り事項として⾒てもらうことになった。実装完了、QA へ仕様は満たし、表⽰演出関連の実装も済んだなら、最後に企画側に確認を取って問題ないか確かめよう。問題なければ QA をしてもらい、不具合がないかチェックしてもらう。何事もないと良いのだが、悲しいかなたいていの場合は何かが起こる。起こったことは共有し、修正対応の⽅向性を相談しておくと、今後似たような不具合を解決するまでの時間を短くできるので、⾃分を含め未来の誰かを助けることにつながる。⼀度実装した後、余程のことがない限りコードの変更は⾏わなくなるので、変な処理やコードがないか整理しておくと安⼼だ。⼤規模、⻑期間のモンストでは特に響きやすいのでより意識しておきたいことでもある。 QA がすべて通ったなら、後はリリースされるのを待つだけだ。不思議な事に、リリースしてユーザーの⼿元で動くようになって初めて顕現する不具合もあるので油断ならない。 1.5 読了ありがとうございました今回は開発実装時の内容を厚めにしてみたが、いかがだっただろうか。同じコードでも仕様によって良い悪いが変わるのでしっかり確認しないといけないし、仕様を実現するために未知の問題に直⾯することも数多い。⽴ち向かっているときは⾮常につらいものだが、それらを乗り越えて作り上げられたものは振り返ってみても「よくやった」と当時の⾃分を褒めたくなる。次にユウナのストライクショットを⾒る際は、以前と違って少し⾒⽅が変わっているかもしれない。ちなみに、ほかにもいろいろと試⾏錯誤してクオリティを上げようとした事例はあるのだが、そう⻑々と書けないので以下に⼀部を列挙するだけにとどめることを許してほしい。 • 銃⼝の内側に⼩さい敵がいた場合、現実では当たらないがゲーム上では使いやすさを優先し当たるように処理した • ヒットエフェクトは出しすぎると負荷が⾼くなってしまうので、⼀定数以上は出ないように間引いている • ガトリング中は銃⾝部分が回転しているように⾒せたいと提案し、⽤意してもらった • 銃⾝部分がスピンアップしてから弾が出る⽅がよりガトリングらしいので、何度か調整した 14

第 2 章 XFLAG Academy アプリ 2.1 始めに XFLAG では
CSR 活動 (社会貢献活動) の⼀環として、中⾼⽣の企業訪問 (職業研究) を受け付けています。学⽣は⽇本全国から訪れます。特に東京から離れた地域の学校は修学旅⾏のカリキュラムの⼀環としてミクシィを訪れています。企業訪問イベント開始当初は座学のみで⾏われ、会社や職業の紹介が主体でした。せっかくの修学旅⾏で訪れた企業訪問が座学だけでは楽しくないだろうと考え、学⽣の良い想い出に残してもらえるようなコンテンツを作ろうと考えました。さらに、コンテンツの中で制作の仕事を少しでも体験してもらい、将来「IT、ゲーム関連の仕事がしたい！」と思ってもらえるようにしました。その結果⽣み出したコンテンツがモンスト IP をベースとしたゲーム制作が体験できるスマートフォンアプリ「XFLAG Academy アプリ」です。ここではアプリの実装内容を紹介しようと思います。図: アカデミーアプリ 15

第 2 章 XFLAG Academy アプリ 2.2 今回使⽤した環境想定読者 •
社会貢献活動に関⼼のある⽅ • 教育関連事業に関⼼のある⽅ 2.2 今回使⽤した環境 Unity(C#) を利⽤してコンテンツを制作しました。 Unity モンストは Cocos2dx で制作されています。Unity を⽤いた理由としては、Cocos2dx よりも Unity の⽅が実現したい内容に向いていたためです。詳細は後述します。 2.3 アプリの設計と開発アプリの要求定義アプリを設計するにあたり、以下の条件から内容を考えました。1. 体験を通して将来 IT 業界で働きたいと思ってもらえるものにする。2. モンストが好きで XFLAG を訪問先に選んでいるのでモンストの IP を利⽤する。3. ただモンストと同じ内容を実現しただけでは遊びに来ただけになってしまうので、勉強要素を取り⼊れる。4. 企業訪問イベントは時間が限られており、アプリを触れるために与えられた時間は約 20 分。5. 本業務との合間に制作をする必要があり時間が多く取れない。6. すぐに作れて⼿軽にメンテナンスできるものにする。考察〜私が受けてきた学校教育から感じる課題〜勉強要素で何を取り⼊れようか考えた時、⽬を付けたのは「数学」です。国語や英語は将来どう役に⽴つのかは⾔わずもがなです。⼀⽅数学は簡単な計算は社会⼈になっても必要なのは誰の⽬から⾒ても明らかですが、たとえば「座標・⾓度・三⾓関数などが将来どう役に⽴つのか？」は特に中学１・２年の学⽣には伝わっていないのではないかという疑問があります。私も中学⽣になったときは、座標・三⾓関数などが将来何に役⽴つかは教師から 16

第 2 章 XFLAG Academy アプリ 2.3 アプリの設計と開発説明のないまま、ただ教科書に従ってやっていただけでした。私が将来数学が重要だと気付くようになったのは⾃分でアプリやゲームを作り始めるようになった中学３年⽣くらい
のときです。⾃⾝で気付けたのは幸いでしたが、なぜ学校の先⽣は実⽤的に教えてくれなかったのだろうかという疑問が残りました。そして今、エンジニアの⽴場として学⽣を迎えるにあたり、アプリやゲームには数学が多⽤されていることを伝え、授業でやっていることの意味を伝えられたらと考えました。学校での授業はけっして無駄なものではない。と。設計数学を盛り込みモンストの IP を活⽤したアプリを作る上で、実現しようと思ったものは、モンストの⼀部を制作して遊べるアプリです。いわゆるツクールソフトであれば、ゲーム制作を疑似体験でき、モンストのレーザーやホーミングミサイルなどの攻撃を⾃分で作れれば数学要素を⼊れることができます。企業訪問イベントは約 20 分と限られた時間であることから、Stratch のような擬似プログラミングまでは実現できないため、数式を埋めて攻撃を作ることとしました。また、本業務の合間で簡単に実現するため、レベルデザインツールがもともと備わっている Unity を選択しました。ステージ、エフェクト、サウンド、キャラクタイラストなどのリソースはモンストのものを Unity で扱いやすいように加⼯して利⽤することにしました。⼿軽にレベルデザインができる Unity で Try&Error を早く回し、⼿軽なモンストツクールを実現し、学⽣さんに早く提供をする。これをテーマに制作を開始しました。開発まずはステージ・プレイヤー・敵を選択して指で好きな位置に置き、各種パラメータを設定できる制作モードを実現しました。これと同時に配置や設定を⾏った状態から、⾃分で作ったゲームを引っ張ってあそべるプレイモードを実現しました。ここまではモンストツクールに相当する機能です。 17

第 2 章 XFLAG Academy アプリ 2.3 アプリの設計と開発図: 制作モードとプレイモード
ここからが⼤事な勉強要素の実現です。中学⽣が学校でならう数学の範囲でアプリに活かしやすいものは「座標・⾓度」です。これをモンストの攻撃でわかりやすく教えるとしたら拡散弾がふさわしい内容だと考えました。拡散弾は指定した⾓度毎に弾を散らして発射します。学⽣には⾓度や弾数を⾃由に決めてオリジナルの拡散弾が作れる機能を作りました。モンスト本編にはない特別な拡散弾ですので、⼈気キャラのオラゴンを使ってオラ様拡散弾と命名しました。 18

第 2 章 XFLAG Academy アプリ 2.3 アプリの設計と開発図: オラ様拡散弾
次に⾼校⽣です。⾼校⽣くらいになると、数学で「三⾓関数」が登場します。これをモンストの攻撃でわかりやすく教えるとしたらエナジーサークルがふさわしい内容だと考えました。エナジーサークルはキャラクタの周囲で円の形を作るレーザー砲です。学⽣にはどの三⾓関数を使えば円状のレーザーが作れるのか選ぶ機能を作りました。こちらもモンスト本編にはない特別なエナジーサークルですので、⼈気キャラのぜつぼうくんを使ってぜつぼうエナサーと命名しました。 19

第 2 章 XFLAG Academy アプリ 2.3 アプリの設計と開発図: ぜつぼうエナサー
早く学⽣に届けたいと考えたため、⼀部特殊な作り⽅をしています。Cocos2dx(C++) の攻撃プログラムの⼀部を Unity ⽤に C#移植をしているという点です。攻撃のグラフィック素材 (Eﬀect)・サウンド素材 (SE)・スクリプトは１つの Prefab に⼊れ、Instantiate で⽣成したものが発動されています。これをコントロールする外側のスクリプトは C#でゼロから書いていますが、攻撃内のスクリプトは Cocos2dx で書かれたソースに⼿を⼊れて利⽤しています。たとえば円を描くエナジーサークルのプログラムであれば以下のような感じです。C++ ベースなので C#っぽい書き⽅ではないですね。 C++ から C#への移植例 private GameObject _fromCharacterObject; private float _speed; private float _radius; private float _time; 20

第 2 章 XFLAG Academy アプリ 2.4 運⽤と改善 void Update
() { float x = Mathf.Cos(_time * _speed) * _radius; float y = Mathf.Sin(_time * _speed) * _radius; x += _fromCharacterObject.transform.position.x; y += _fromCharacterObject.transform.position.y; this.transform.position = new Vector3(x, y, 0.0f); } ⼀部このような作り⽅をしたことで制作時間は⼤幅に短縮でき、構想から実現まで短期間で⾏うことができました。 2.4 運⽤と改善運⽤ XFLAG Academy アプリは学⽣に好評なコンテンツとなりました。企業訪問イベントの最後にアンケートをお願いしているのですが、定量的な評価としてほぼ満点の評価をいただきました。定性的な評価としては「数学の授業がんばります」「将来ゲーム製作者になりたい」「IT 企業ではたらきたい」といううれしいフィードバックを多くいただくことができました。⼀⽅、課題も⾒えてきました。数学に紐づいたコンテンツとしたため、エンジニア以外を志望している学⽣にはわかりづらいという声です。改善エンジニア向け数学要素だけではなく、デザイン要素を追加することにしました。やはり 20 分という時間制限があるため、ゼロからキャラクタデザインを興す訳にもいきません。そこで追加したものはボスのペイント機能です。ベースとなる⾊はこちらから提供し、⾊の組み合わせを⾃由に⾏ってデザイン感を出すようにしました。 21

第 2 章 XFLAG Academy アプリ 2.5 総括図: ボスデザイン機能
2.5 総括企業訪問イベントの今後 XFLAG Academy アプリが登場して約２年の運⽤がなされてきました。年間数百の学⽣に体験を提供でき、今後に活かせる何かを持って帰ってもらえたことはうれしい限りです。また、学⽣に職業紹介やアプリの使い⽅や数学を教えることで、⾃⾝の学びにもなりました。特に参考になったのは UI 設計です。私⾃⾝、仕事でゲームを作っていますし、プライベートでも数本ゲームやアプリの配信を⾏っています。エンドユーザーの操作に関する疑問や改善提案はたいへん貴重なものでした。今後の XFLAG Academy での取り組みについては、活動⽅法などの⾒直しが⼊ること 22

第 2 章 XFLAG Academy アプリ 2.5 総括になりました。CSR アプリとしては⼀定の評価をいただけたアプリですので、今後何らか
の形でソースの公開や学⽣のフィードバックを公開できたら良いなと考えています。 23

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.1 始めに Unity
上ではたくさんの GameObject を配置できますが、多ければ多いほど処理負荷につながります。背景などは、ほとんど動かない GameObject が⼤量に配置されており、 CPU リソースを消費させるには、もったいない時も多くあります。ほかにも、アセットデータには、デザイナーさんには、コントロールの難しい問題が多く潜んでいます。それらをエンジニアリングで解決することは、佳境のプロジェクトにとって、急務となることがあります。本章では、弊社タイトルファイトリーグのケースをもとに、事前処理でのアセットの問題解決法を共有します。 3.2 想定読者アセットの問題を技術的に解決したい⼈ 3.3 読者が得られる知⾒ • Mesh 結合アルゴリズム • シーン Mesh の操作時のハマりポイント • 静的なデータへのアプローチ 24

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.4 Lightmap 3.4 Lightmap
Lightmap とはライトをテクスチャに焼き込むことで、ランタイムのライト計算を減らすテクニックです。ファイトリーグでは、Unity 内に搭載されている Lightmap を使⽤しています。Unity 公式に使⽤⽅法をまとめられているため、詳しくは割愛します。 3.5 Mesh 結合 Mesh 結合の必要性 Unity には Static Batching というレンダリングシステムが搭載されています。Static Batching を設定することにより、複数の Mesh を 1 ドローで描画できます。しかし、 Static Batching は、Mesh を⼀つにまとめますが、GameObject はバラバラのまま⽣きています。 GameObject 毎、結合したうえで、Static Batch すれば、GameObject 量に由来するコストが削減できます。⼿法選択 Mesh の結合といえば、Unity には Mesh.CombineMeshes という関数が⽤意されています。しかし、この関数には⽋点があります。SubMesh を複数持つ Mesh を結合する際、⼀度 SubMesh ごとに分解しなければなりません。その際、SubMesh 間で共有されている頂点が複製され、トータルの頂点数が増えてしまいます。ファイトリーグでは Mesh 結合を⾃作し、Material を元に SubMesh の振り分けに対応しています。対象の選定まずは、今回結合したいシーンを⾒てみましょう。これはファイトリーグで実際に使⽤しているアセットです。 25

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合図
3.1: 結合したいシーン結合するにあたり、どういったメッシュを結合対象とするか決めなければなりません。タグ付け等の⼿段であれば⾃由度があります。ファイトリーグでは作業⼿順の増加を防ぐために、下記のルールにのっとって⾃動収集します。 • MeshRenderer を持つ • Component の参照を受けない • Component の参照を受ける GameObject/Component の⼦でない • Animation の参照を受けない • Animation の参照を受ける GameObject の⼦でない • 除外リストに含まれないレンダラの収集 // シーン内のレンダラを収集する var targetRenderers = new List<MeshRenderer>(); ComponentUtils.GetComponentsInScenes(targetRenderers); // 結合しないレンダラを対象外にする targetRenderers.RemoveAll(excludeRenderers.Contains); 26

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 //
どこかから参照されているオブジェクトを対象外にする this.RemoveReferencedComponents(targetRenderers); // @brief リスト内から、どこかから参照されているコンポーネントを削除する // @tparam T コンポーネント型 // @param components コンポーネント private void RemoveReferencedComponents<T>(List<T> components) where T : Component { var referencedObjects = new List<GameObject>(); GameObjectUtils.FindPropertyReferencedObjectsInScenes(referencedObjects); GameObjectUtils.FindAnimationReferencedObjectsInScenes(referencedObjects); components.RemoveAll((component) => GameObjectUtils.IsChildOf(component.gameObject, referencedObjects)); } GameObjectUtils.cs // @class GameObjectUtils // @brief ゲームオブジェクトのユーティリティ public static class GameObjectUtils { // @brief シリアライズプロパティから参照されているオブジェクトを探す // @param result シリアライズプロパティから参照されているオブジェクト public static void FindPropertyReferencedObjectsInScenes( List<GameObject> result) { if (result == null) return; var components = new List<Component>(); ComponentUtils.GetComponentsInScenes(components); foreach (var component in components) { SerializedObject serializedObject = new SerializedObject(component); SerializedProperty property = serializedObject.GetIterator(); while (property.Next(property.name != "m_Children")) { if (property.propertyType != SerializedPropertyType.ObjectReference || property.name == "m_GameObject" || property.name == "m_Father" || property.name == "m_Children") continue; // オブジェクト参照プロパティを取得 var propertyObject = property.objectReferenceValue; // コンポーネント参照を取得 var referencedComponent = propertyObject as Component; 27

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 if
(referencedComponent != null && !result.Contains(referencedComponent.gameObject)) { result.Add(referencedComponent.gameObject); continue; } // ゲームオブジェクト直参照の可能性もあるので取得 var gameObject = propertyObject as GameObject; if (gameObject != null && !result.Contains(gameObject)) { result.Add(gameObject); continue; } } } } // @brief アニメーションから参照されているオブジェクトを探す // @param result アニメーションから参照されているオブジェクト public static void FindAnimationReferencedObjectsInScenes( List<GameObject> result) { if (result == null) return; // Animator コンポーネントの参照 var allAnimators = new List<Animator>(); ComponentUtils.GetComponentsInScenes(allAnimators); foreach (var animator in allAnimators) { if (animator == null) continue; var runtimeAnimatorController = animator.runtimeAnimatorController; if (runtimeAnimatorController == null) continue; var clips = runtimeAnimatorController.animationClips; if (clips == null) continue; foreach (var clip in clips) { FindAnimationClipReferencedObjects(clip, animator.transform, result); } } // Animation コンポーネントの参照 var allAnimations = new List<Animation>(); ComponentUtils.GetComponentsInScenes(allAnimations); foreach (var animation in allAnimations) { if (animation == null) continue; 28

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 foreach
(AnimationState animationState in animation) { if (animationState == null) continue; FindAnimationClipReferencedObjects( animationState.clip, animation.transform, result); } } } // @brief アニメーションクリップから参照されているオブジェクトを取得 // @param clip アニメーションクリップ // @param rootTransform ルートのトランスフォーム // @param result 結果 public static void FindAnimationClipReferencedObjects( AnimationClip clip, Transform rootTransform, List<GameObject> result) { if (clip == null || result == null) return; var curveBindings = AnimationUtility.GetCurveBindings(clip); foreach (var curveBinding in curveBindings) { var transform = rootTransform.Find(curveBinding.path); if (transform == null || result.Contains(transform.gameObject)) continue result.Add(transform.gameObject); } } } ComponentUtils.cs // @class ComponentUtils // @brief コンポーネントのユーティリティ public static class ComponentUtils { // @brief 複数のシーン内のコンポーネントを取得する // @tparam T コンポーネント型 // @param result コンポーネント⼀覧 // @param includeInactive アクティブなオブジェクトを含むか public static void GetComponentsInScenes<T>( List<T> result, bool includeInactive = false) { for (int i = 0; i < SceneManager.sceneCount; ++i) { var scene = SceneManager.GetSceneAt(i); GetComponentsInScene(scene, result, includeInactive); } 29

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 }
// @brief シーン内のコンポーネントを取得する // @tparam T コンポーネント型 // @param scene シーン // @param result コンポーネント⼀覧 // @param includeInactive アクティブなオブジェクトを含むか public static void GetComponentsInScene<T>( Scene scene, List<T> result, bool includeInactive = false) { var rootGameObjects = scene.GetRootGameObjects(); foreach (GameObject rootGameObject in rootGameObjects) { if (rootGameObject == null) continue; var children = rootGameObject.GetComponentsInChildren<T>(includeInactive); result.AddRange(children); } } } 結合単位をまとめるいざ、結合をしてみようとすると、「MeshRenderer の Property の異なるものどうし」「Static フラグ、Layer の異なるものどうし」など結合できない GameObject があることがわかります。GameObject、MeshRenderer 毎に設定されパラメータは複数の持つことができない為、1 つの GameObject にできません。そこで、GameObject と MeshRenderer のパラメータをもとに結合単位を決めます。結合単位の基準にするのは下記パラメータです。 • MeshRenderer.sortingOrder • MeshRenderer.sortingLayerID • MeshRenderer.sortingLayerName • MeshRenderer.reﬂectionProbeUsage • MeshRenderer.probeAnchor • MeshRenderer.lightProbeProxyVolumeOverride • MeshRenderer.lightProbeUsage • MeshRenderer.LightmapIndex • MeshRenderer.receiveShadows • MeshRenderer.shadowCastingMode 30

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 •
GameObject.layer • GameObject の Static フラグ (GameObjectUtility.GetStaticEditorFlags によって取得) ファイトリーグでは、これらのパラメータをキーに、MeshRenderer の List を Value にし、Dictionary 形式で管理することで、簡単に結合単位を分けることができます。 Dictionary のキー // @struct MeshRendererParameter // @brief メッシュレンダラのパラメータ private struct MeshRendererParameter : IEquatable<MeshRendererParameter> { private int sortingOrder; //!< ソート順 private int sortingLayerID; //!< ソートレイヤー ID private string sortingLayerName; //!< ソートレイヤー名 private ReflectionProbeUsage reflectionProbeUsage; //!< ReflectionProbe 使⽤オプション private Transform probeAnchor; //!< Probe ⽤アンカーポジションオブジェクト private GameObject lightProbeProxyVolumeOverride; //!< LightProbe のボリューム値上書き⽤オブジェクト private LightProbeUsage lightProbeUsage; //!< LightProbe 使⽤オプション private int lightmapIndex; //!< LightMap のインデックス private bool receiveShadows; //!< 影を受けるか private ShadowCastingMode shadowCastingMode; //!< 影を落とすためのモード private StaticEditorFlags staticMask; //!< StaticFlag のマスク private int layer; //!< レイヤー // @brief ⽐較 // @param obj ⽐較対象 // @return 結果 public int CompareTo(object obj) { return this.ToString().CompareTo(obj.ToString()); } // @brief ⽂字列変換 // @return ⽂字列 public override string ToString() { return "sortingOrder:" + this.sortingOrder + ", sortingLayerID:" + this.sortingLayerID + ", sortingLayerName:" + this.sortingLayerName + ", reflectionProbeUsage:" + this.reflectionProbeUsage + ", probeAnchor:" + this.probeAnchor + ", lightProbeProxyVolumeOverride:" + this.lightProbeProxyVolumeOverride + ", lightProbeUsage:" + this.lightProbeUsage + ", lightmapIndex:" + this.lightmapIndex + ", receiveShadows:" + this.receiveShadows + ", shadowCastingMode:" + this.shadowCastingMode + ", staticMask:" + this.staticMask + 31

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 ",
layer:" + this.layer; } // @brief 対象にコピーする // @param renderer レンダラ public void CopyTo(MeshRenderer renderer) { renderer.sortingOrder = this.sortingOrder; renderer.sortingLayerID = this.sortingLayerID; renderer.sortingLayerName = this.sortingLayerName; renderer.reflectionProbeUsage = this.reflectionProbeUsage; renderer.probeAnchor = this.probeAnchor; renderer.lightProbeProxyVolumeOverride = this.lightProbeProxyVolumeOverride; renderer.lightProbeUsage = this.lightProbeUsage; renderer.lightmapIndex = this.lightmapIndex; renderer.receiveShadows = this.receiveShadows; renderer.shadowCastingMode = this.shadowCastingMode; GameObjectUtility.SetStaticEditorFlags( renderer.gameObject, this.staticMask); renderer.gameObject.layer = this.layer; } // @brief 対象からコピーする // @param renderer レンダラ public void CopyFrom(MeshRenderer renderer) { this.sortingOrder = renderer.sortingOrder; this.sortingLayerID = renderer.sortingLayerID; this.sortingLayerName = renderer.sortingLayerName; this.reflectionProbeUsage = renderer.reflectionProbeUsage; this.probeAnchor = renderer.probeAnchor; this.lightProbeProxyVolumeOverride = renderer.lightProbeProxyVolumeOverride; this.lightProbeUsage = renderer.lightProbeUsage; this.lightmapIndex = renderer.lightmapIndex; this.receiveShadows = renderer.receiveShadows; this.shadowCastingMode = renderer.shadowCastingMode; this.staticMask = GameObjectUtility.GetStaticEditorFlags( renderer.gameObject); this.layer = renderer.gameObject.layer; } // @brief ハッシュコードの取得 // @return ハッシュコード public override int GetHashCode() { return this.ToString().GetHashCode(); } // @brief ⽐較 // @param other ⽐較オブジェクト // @retval true ⼀致 // @retval false 不⼀致 32

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 public
bool Equals(MeshRendererParameter other) { return this.ToString() == other.ToString(); } } Dictionary のバリュー // @class CombineUnitList // @brief 結合単位⼀覧 private class CombineUnitList { //! 結合レンダラ⼀覧 public List<CombineUnit> CombineUnits { get { return this.combineUnits; } } //! 結合レンダラ⼀覧 private List<CombineUnit> combineUnits = new List<CombineUnit>(); // @brief レンダラの追加 // @param renderer レンダラ // @retval true 追加成功 // @retval false 追加失敗 public bool Add(MeshRenderer renderer) { foreach (CombineUnit combineUnit in this.combineUnits) { if (combineUnit.Add(renderer)) return true; } var newUnit = new CombineUnit(); if (!newUnit.Add(renderer)) return false; this.combineUnits.Add(newUnit); return true; } } // @class CombineUnit // @brief 結合単位 private class CombineUnit { //! 結合レンダラ⼀覧 public List<MeshRenderer> Renderers { get { return this.renderers; } } //! 頂点数 private int totalVertexCount = 0; //! 結合レンダラ⼀覧 private List<MeshRenderer> renderers = new List<MeshRenderer>(); 33

@brief レンダラの追加 // @param renderer レンダラ // @return true = 追加成功 public bool Add(MeshRenderer renderer) { if (renderer == null) return false; var filter = renderer.GetComponent<MeshFilter>(); if (filter == null) return false; var mesh = filter.sharedMesh; if (mesh == null) return false; // note: 32bit インデックス未対応 if (ushort.MaxValue - this.totalVertexCount < mesh.vertexCount)return false; // 追加 this.totalVertexCount += mesh.vertexCount; this.renderers.Add(renderer); return true; } } 結合してみる結合の準備が整いました。順番にメッシュを結合していきます。結合時に操作するパラメータは下記です。それぞれ操作時の注意点があります。 • Mesh.vertices – Transform.MultiplyPoint を⾏い、位置を動かします。 • Mesh.normals • Mesh.tangents • Mesh.uv • Mesh.uv3 • Mesh.uv4 • Mesh.colors – 先頭から順に結合していきます。ただし、もともと値がない場合に結合をすると、エラーになります。「vertices と同じ⻑さ」or「⻑さなし」でしか作ることはできません。 • Mesh.uv2 – Lightmap ⽤の UV となっています。Lightmap の UV の Scale と Oﬀset は 34

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 MeshRenderer
によって異なります。結合前に正規化を⾏う必要があります。 MeshRenderer.LightmapScaleOﬀset の x, y が Scale 値、z, w が Oﬀset 値です。uv2 を x,y で Scale し、z,w を⾜すことで、正規化できます。 • Mesh.triangles – ポリゴンの Index 配列です。Mesh.triangles は SubMesh 毎にあるため、 Mesh.GetTriangles を⽤いて SubMesh ごとに取得します。結合時は「Index は結合するごとにずれる」という点に注意する必要があります。すべて配列ですので、List に変換し、AddRange するだけで結合できます。triangles、 vertices、uv2 は例外です。結合処理 // @brief メッシュ結合 // @param combineUnit 結合単位 // @param combinedMesh 結合済みメッシュ // @param combinedMaterials 結合済みマテリアル private void CombineMeshes( CombineUnit combineUnit, out Mesh combinedMesh, out Material[] combinedMaterials) { // 各種パラメータの作成 var vertices = new List<Vector3>(); var normals = new List<Vector3>(); var tangents = new List<Vector4>(); var uv = new List<Vector2>(); var uv2 = new List<Vector2>(); var uv3 = new List<Vector2>(); var uv4 = new List<Vector2>(); var colors = new List<Color>(); var triangles = new List<List<int>>(); // マテリアルを取得し、サブメッシュ作成準備 List<MeshRenderer> renderers = combineUnit.Renderers; var newMaterials = new List<Material>(); var materialToSubMeshIndex = new Dictionary<Material, int>(); foreach (MeshRenderer renderer in renderers) { if (renderer == null) continue; Material[] materials = renderer.sharedMaterials; foreach (Material material in materials) { if (material == null || materialToSubMeshIndex.ContainsKey(material)) continue; triangles.Add(new List<int>()); newMaterials.Add(material); materialToSubMeshIndex.Add(material, materialToSubMeshIndex.Count); 35

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 }
} // メッシュの結合を開始 foreach (MeshRenderer renderer in renderers) { if (renderer == null) continue; var filter = renderer.GetComponent<MeshFilter>(); if (filter == null) continue; int indexOffset = vertices.Count; Mesh mesh = filter.sharedMesh; if (mesh == null) continue; var scale = renderer.transform.lossyScale; bool isReverse = scale.x * scale.y * scale.z < 0; Matrix4x4 transform = renderer.transform.localToWorldMatrix; // 頂点の結合 var baseVertices = mesh.vertices; foreach (var baseVertex in baseVertices) { vertices.Add(transform.MultiplyPoint(baseVertex)); } // ライトマップ⽤の UV 作成 var lightmapScaleOffset = renderer.lightmapScaleOffset; var lightmapScale = new Vector2(lightmapScaleOffset.x, lightmapScaleOffset.y); var lightmapOffset = new Vector2(lightmapScaleOffset.z, lightmapScaleOffset.w); var lightmapUvs = mesh.uv2; for (int i = 0; i < lightmapUvs.Length; ++i) { lightmapUvs[i].Scale(lightmapScale); lightmapUvs[i] += lightmapOffset; } // 頂点サイズに依存するパラメータの結合 this.AddRangeOfSize( normals, mesh.normals, vertices.Count, Vector3.zero); this.AddRangeOfSize( tangents, mesh.tangents, vertices.Count, Vector3.zero); this.AddRangeOfSize(uv, mesh.uv, vertices.Count, Vector2.zero); this.AddRangeOfSize(uv2, lightmapUvs, vertices.Count, Vector2.zero); this.AddRangeOfSize(uv3, mesh.uv3, vertices.Count, Vector2.zero); this.AddRangeOfSize(uv4, mesh.uv4, vertices.Count, Vector2.zero); this.AddRangeOfSize(colors, mesh.colors, vertices.Count, Color.black); // ポリゴンの結合 Material[] materials = renderer.sharedMaterials; 36

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 for
(int subMeshIndex = 0; subMeshIndex < mesh.subMeshCount; ++subMeshIndex) { Material material = materials[subMeshIndex]; if (material == null) continue; int newSubMeshIndex = materialToSubMeshIndex[material]; var baseTriangles = mesh.GetTriangles(subMeshIndex); for (int triangleIndex = 0; triangleIndex < baseTriangles.Length; ++triangleIndex) { int trueTriangleIndex = isReverse ? baseTriangles.Length - 1 - triangleIndex : triangleIndex; var baseTriangle = baseTriangles[trueTriangleIndex]; triangles[newSubMeshIndex].Add(baseTriangle + indexOffset); } } } // マテリアル完成 combinedMaterials = newMaterials.ToArray(); // メッシュへ各種パラメータを設定 combinedMesh = new Mesh(); combinedMesh.SetVertices(vertices); combinedMesh.SetNormals(normals); combinedMesh.SetTangents(tangents); combinedMesh.SetUVs(0, uv); combinedMesh.SetUVs(1, uv2); combinedMesh.SetUVs(2, uv3); combinedMesh.SetUVs(3, uv4); combinedMesh.SetColors(colors); combinedMesh.subMeshCount = combinedMaterials.Length; for (int subMeshIndex = 0; subMeshIndex < combinedMesh.subMeshCount; ++subMeshIndex) { combinedMesh.SetTriangles(triangles[subMeshIndex], subMeshIndex); } // Bounds を再計算 combinedMesh.RecalculateBounds(); // メッシュ最適化 MeshUtility.Optimize(combinedMesh); } // @brief リストに指定サイズまで要素を追加 // @tparam T リストの要素型 // @param list リスト // @param addValue 追加する値 // @param maxSize 最⼤サイズ 37

@param defaultValue デフォルト値 private void AddRangeOfSize<T>( List<T> list, T[] addValue, int maxSize, T defaultValue) { // 元々空で、かつ、追加する分がなければ空のまま。 int totalCount = list.Count + addValue.Length; if (totalCount <= 0) return; int diff = maxSize - totalCount; if (diff > 0) { for (int i = 0; i < diff; ++i) { list.Add(defaultValue); } } list.AddRange(addValue); } ここで、実際に結合したメッシュを⾒てみます。図 3.2: 結合したシーンライティングが⼤きく変わっています、これは、Lightmap の設定が剥がれてしまっているためです。そこで、Lightmap を使えるよう、代替機能を作る必要がありますマテリアルの Lightmap 対応 Lightmap は、Lightmapping.lightingDataAsset から参照されます。中には古い Mesh の参照が残っている為、使うべきではありません。そのため、Lightmap- 38

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 ping.lightingDataAsset
には null を⼊れておきます。ファイトリーグでは、lighting- DataAsset の代理として、「LightmapMaterialAdapter」2 種類の⽅法で実装しました。パターン A:LightmapData に直接代⼊するテクスチャ等の参照をランタイムで取り戻せるよう実装してみます。結合時に、「LightmapSettings.lightmaps」および「Lightmap の対象となる Renderer」から下記のパラメータを取得します。 • LightmapData.lightmapColor • LightmapData.lightmapDir • LightmapData.shadowMask • Renderer.lightmapIndex • Renderer.lightmapScaleOﬀset これらを、SerializeField に保持しておき、Start のタイミングで、元のオブジェクトに返します。これで、Lightmapping.lightingDataAsset の機能を代理できますが、実⾏時に以下の警告が出てしまいます。 The renderer xxxx is a part of a static batch. Setting the lightmap scale and offset will not affect the rendering. The scale and offset is already burnt into the lightmapping UVs in the static batch. パターン B:MaterialPropertyBlock でライトマップ⽤パラメータを上書きするこの⼿法では MaterialPropertyBlock を使⽤します。結合時に、「LightmapSet- tings.lightmaps」および「Lightmap の対象となる Renderer」から下記のパラメータを取得します。 • LightmapData.lightmapColor • LightmapData.lightmapDir • Renderer.lightmapIndex • Renderer.lightmapScaleOﬀset Renderer.lightmapIndex は、LightmapSettings.lightmaps のインデックスです。 Start() 内で MaterialPropertyBlock を⽤い、lightmapIndex の⽰す、Lightmap- Data.lightmapColor、LightmapData.lightmapDir を設定します。 39

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.5 Mesh 結合 Property
名パラメータの取得元 unity_Lightmap LightmapData.lightmapColor unity_LightmapInd LightmapData.lightmapDir unity_LightmapST Renderer.lightmapScaleOﬀset この場合、シェーダーキーワード「LIGHTPROBE_SH」が強制的に設定されてしまいます。対策として、「#pragma skip_variants LIGHTPROBE_SH」を記述済みのシェーダーを設定してください。結合結果図 3.3: Lightmap 対応したシーン⼨分違わず、しかも、同じ⾒た⽬が再現できています。結合済みアセット参照解除結合しても、もともと使⽤していた結合済みアセットの接続が残っている場合、結合前の Mesh がメモリ上に乗ってしまいます。結合に使⽤した Mesh のアセットのみを対象に、参照を解除しなければなりません。まずは、結合対象にならなかった Mesh を確認します。結合済み Mesh と同様のアセットを参照している場合、これらを Instantiate で複製することで参照が解除されます。 Animator には avatar が参照されています。そして、avatar は FBX 内に参照を持っている場合があります。結合済みメッシュと同様の FBX が参照されている場合、avatar も Instantiate で複製し、参照解除を⾏います。次に、SimpleAnimation に FBX 内の AnimationClip が接続されている場合があります。AnimationClip の参照も Instantiate で複製し、解除できます。 40

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.6 ポリゴンのソート参照しているアセットが Prefab
であれば、Prefab の参照解除も⾏います。Prefab の参照は、PrefabUtility.DisconnectPrefabInstance で解除できます。⼀通りの処理を⾏った後、シーンにアセットバンドル名を指定し、AssetBundleBrowser で⾒てみます。参照の解除が確認できます。 3.6 ポリゴンのソートポリゴンソートの必要性ゲーム画⾯のモデルは、描画順序によって処理効率が変動します。たとえば、「スカイスフィア→地形」の順で描画するとします。すると、⼀度画⾯をスカイスフィアで塗りつぶしたあと、「⼀度塗った場所にもう⼀度」地形を描くことになります。画⾯に絵を描くコストを最⼩にする場合、近くにあるものから描くと安く収まります。（半透明のモデルであれば、遠くから描画する必要があります。） Unity では GameObject 毎のソートは⾏ってくれますが、ポリゴンのソートは発⽣しません。そこで、アセットにする時点で事前にポリゴンをソートしてしまいます。これはファイトリーグのような、「カメラの座標が⼀定範囲から逸脱しないゲーム」において、有効です。カメラ位置の指定ソートの基準となるカメラ位置を指定します。カメラ位置はポリゴンとの距離を測るのに使⽤します。ポリゴンをソートするファイトリーグでは三⾓形の重⼼を計算し、ポリゴンの座標としています。他にも、ポリゴンのカメラとの近傍、中⼼、傍⼼等、選択の余地があります。ここは、ゲームに合わせて最適な物を選びましょう。中⼼点が決まってしまえばあとは、距離を測りソートするだけです。ポリゴンのソート // @brief メッシュのポリゴン並び順をソート // @param indices インデックス // @param vertices 頂点⼀覧 // @param center ソートの基準点 41

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.6 ポリゴンのソート // @param
vertexCountInPolygon 1 ポリゴンあたりの頂点数 // @param isAscending 昇順 private void SortPolygon( int[] indices, Vector3[] vertices, Vector3 center, int vertexCountInPolygon, bool isAscending) { // ポリゴン単位にまとめる var polygons = new int[indices.Length / vertexCountInPolygon][]; for (int i = 0; i < polygons.Length; ++i) { int offset = i * vertexCountInPolygon; var polygon = new int[vertexCountInPolygon]; for (int j = 0; j < polygon.Length; ++j) { polygon[j] = indices[offset + j]; } polygons[i] = polygon; } // ソート：優先度（中⼼に近いもの順） var sortedPolygons = new SortedList<float, List<int[]>>(); foreach (var polygon in polygons) { Vector3 sum = Vector3.zero; foreach (var index in polygon) { sum += vertices[index]; } Vector3 g = sum / vertexCountInPolygon; Vector3 centerVec = g - center; var key = centerVec.sqrMagnitude; key = isAscending ? key : -key; List<int[]> tmpList; if (!sortedPolygons.TryGetValue(key, out tmpList)) { tmpList = new List<int[]>(); sortedPolygons.Add(key, tmpList); } tmpList.Add(polygon); } int count = 0; foreach (var pair in sortedPolygons) { foreach (var polygon in pair.Value) { int offset = count * vertexCountInPolygon; for (int i = 0; i < polygon.Length; ++i) 42

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.7 Index のソート {
indices[offset + i] = polygon[i]; } ++count; } } } 3.7 Index のソート Index をソートする必要性 CPU、GPU ともに連続したデータを処理するほうが効率が良いように設計されています。プロセッサにはキャッシュが設定されており、優先的に連続したメモリを乗せるようになっています。メモリ上において、頂点は Mesh.vertices の順に並んでいます。しかし、 GPU 上では Mesh.triangles の順に頂点シェーダーを実⾏します。つまり、Mesh.triangles 内で隣どうしの値が離れている場合、キャッシュの書き換えが⾛ってしまいます。多くの場合、FBX などのモデルアセットの triangles は、Unity インポート時に最適化されます。しかし、先述の Mesh 結合においては、最適化の対象となりません。これは、事前処理だからこそ必要になるテクニックです。⼿法選択最も簡単なのは、MeshUtility.Optimize を使うことです。キャッシュ効率の優れた Mesh.triangles にソートしてくれます。しかし、Mesh.triangles の中⾝⾃体がソートされています。先述の「ポリゴンをソートする」が実⾏されている場合、せっかくソートした順序が崩れてしまいます。ファイトリーグでは Mesh.triangles の順序に合わせて、 Mesh.vertices や Mesh.uv をソートしました。⾃⼒でソートしてみる⾃⼒と⾔ってもあまり⼤したことはしません。たとえば、Mesh.triangles の先頭の数字が「5」だったとします。下記すべての「0 番⽬」と「5 番⽬」の要素を Swap します。 • Mesh.vertices 43

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.7 Index のソート •
Mesh.normals • Mesh.tangents • Mesh.uv • Mesh.uv2 • Mesh.uv3 • Mesh.uv4 • Mesh.colors Mesh.triangles を全検索し、すべての「0」を「5」に、すべての「5」を「0」に Replace します。⼊れ替える数字（先程の「0 番⽬」）をインクリメントします。これを繰り返すだけです。ポリゴンの順序はそのままに、最適化された Mesh.vertices を扱えます。 Index のソート var triangles = mesh.GetTriangles(subMeshIndex); for (int i = 0; i < triangles.Length; ++i) { int index = triangles[i]; if (index < tail) continue; // 頂点をスワップ vertices.Swap(index, tail); normals.Swap(index, tail); tangents.Swap(index, tail); uv.Swap(index, tail); uv2.Swap(index, tail); uv3.Swap(index, tail); uv4.Swap(index, tail); colors.Swap(index, tail); this.BothReplaceIndexBuffer(mesh, index, tail); triangles = mesh.GetTriangles(subMeshIndex); ++tail; } mesh.SetTriangles(triangles, subMeshIndex); // @brief インデックスバッファの双⽅リプレース // @param mesh メッシュ // @param left 左辺 // @param right 右辺 private void BothReplaceIndexBuffer(Mesh mesh, int left, int right) { for (int subMeshIndex = 0; subMeshIndex < mesh.subMeshCount; ++subMeshIndex) { var triangles = mesh.GetTriangles(subMeshIndex); for (int i = 0; i < triangles.Length; ++i) { 44

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.7 Index のソート if
(triangles[i] == left) { triangles[i] = right; } else if (triangles[i] == right) { triangles[i] = left; } } mesh.SetTriangles(triangles, subMeshIndex); } } ソート結果それでは、ソート結果を確認してみましょう。今回、チェック⽤としてインデックス順に頂点カラーを設定してみました。先頭に近いほど、明るい⾊が設定されます。図 3.4: ソート結果の確認⽅法中⼼ほど明るい⾊になっているのがおわかりでしょうか？これで、カメラに近い位置から順番に描画されるようになり、描画効率が良くなります。 45

第 3 章ファイトリーグにおける Unity のシーンアセット最適化 3.8 他にやれること 3.8 他にやれること
FBX,Obj 等で出⼒⽣成した Mesh インスタンスは Read/Write Enabled であるため、⼆倍のメモリを消費します。Wavefront Obj 等のフォーマットで出⼒し、ReadOnly にすることで⼤幅に消費メモリを削減できます。事前カリングファイトリーグでは、カメラの座標が⼤きく変動しないため、画⾯に映らないポリゴンが眠っています。これらのポリゴンに対し、カリングすれば事前に Mesh のリダクションを⾏うことができます。 46

第 4 章ファイトリーグ環境を OpenAI Gym で構築した話 4.1 始めに
ファイトリーグでは、機械学習アプローチを⽤いた盤⾯における配置予測 AI の開発を⾏っています。すでに教師あり学習では既存のルールベース AI より精度が⾼くなっていることが確認されており、現在は強化学習アプローチの検証に取り組んでいます。本章ではその取り組みの⼀環として⾏った、ファイトリーグにおける強化学習の実験環境を構築した話を紹介します。 4.2 背景機械学習⼿法の⼀つである強化学習の研究は、最近の AI 研究の中でもトレンドとなっています。そのため、⾮常に速いペースで SOTA*1の性能を持ったアルゴリズムが⽣まれています。またそのようなアルゴリズムを⼿軽に試せるように、Ray RLlib*2や Coach*3といった OSS の強化学習フレームワークの開発も活発に⾏われるようになってきました。そしてこうした強化学習フレームワークの多くは、強化学習⽤のツールキットを提供している OpenAI Gym*4の共通インタフェースに対応しています。このインタフェースに沿って環境を構築することで、フレームワークが提供しているさまざまなアルゴリズムを使うことができ、また分散学習も容易です。私達のプロジェクトでも、強化学習フレームワークが使えるよう、Gym インタフェースに即した形のファイトリーグ環境を構築することとしました。 *1 State-of-the-art の略。現時点において最⾼の精度であることを指します。 *2 https://ray.readthedocs.io/en/latest/index.html *3 https://nervanasystems.github.io/coach/ *4 https://gym.openai.com/ 47

第 4 章ファイトリーグ環境を OpenAI Gym で構築した話 4.3 ファイトリーグのバトルシステム 4.3
ファイトリーグのバトルシステム今回の強化学習環境となるファイトリーグのバトルシステムについて紹介します。バトルシステムは図 4.1 のようになっています。中央の枠が 12 マスのバトルフィールドとなっており、プレイヤーは空いているマスにファイターを配置できます。そしてその下の枠には⼿札が表⽰されています。プレイヤーは先⼿番、後⼿番の 2 回⾏動ができ、先⼿番では左の２枚から１枚、後⼿番では右の２枚から１枚ファイターを配置できます。さらにその下の枠には FB(ファイティングバースト) という条件を満たした際に発動できるリーダースキルのボタンがあり、このスキルは⼿番を消費せずに発動できます。強化学習下でのファイトリーグ環境では、環境が「各キャラがどのように配置されているか等の盤⾯情報や⼿札等の周辺情報」を状態空間として持っており、エージェントが「フィールドのマス × ⼿札 + FB) × 選択スキル*5分の状態」を action の状態空間として持ってます。そして報酬は、勝利の場合 1、敗北の場合-1 としています。また置けない場所への action が指定された時も、その試合は終了して-1 が返ります。図 4.1: ファイトリーグのバトルシステム図 *5 フィールドにいるファイターを選択して発動するスキル 48

第 4 章ファイトリーグ環境を OpenAI Gym で構築した話 4.4 Gym インタフェース
4.4 Gym インタフェース Gym のインタフェースは、環境がエージェントと円滑にやりとりするためにいくつかのメソッドを定義しています。 • env.reset(self) – このメソッドを呼び出すと環境を初期状態にリセットします。そして、初期状態の observation を返します。 • env.step(self, action) – 引数に渡された action を⾏い、その結果得られた、次状態の observation、報酬値の reward、状態が終了状態であるかの done、追加情報の info の 4 つを返します。 • env.render(self, mode=’human’, close=False) – 現在の状態をレンダリングします。 • env.close(self) – 環境の持つ状態を破棄して終了します。 • env.seed(self, seed=None) – ランダムシードの設定を⾏います。ファイトリーグ環境では、2 つの必須メソッドとレンダリングのための env.render() の合計 3 つを定義することで Gym インタフェースベースの環境を構築しています。しかし、このインタフェースには⼀つの問題があります。それは、Gym のインタフェースが「action によって次状態が決定できる前提で設計されている」という問題です。ファイトリーグは⼆⼈零和不完全情報ゲーム*6であるため、エージェントは⾃分と相⼿の２体いるのですが、この２体をそのまま同じアルゴリズムで動かそうとすると、env.step() メソッドの戻り値である observation が⾃分の action だけでは決まらない問題に直⾯します。たとえば⾃分が後⼿番であるとすると、ファイターを配置した後はダメージ計算後相⼿のターンに移⾏するので、相⼿のターンが終わらないと次の⾃分の状態が定まりません。 env.step() メソッドの設計はこのような環境の想定がされていないのです。この問題に対して現状のファイトリーグ環境では、⽚⽅のエージェントをルールベース AI とし学習はカリキュラム学習*7とすることによって対応しています。ルールベース AI はゲームサーバ側のコードに定義されているので、env.step() メソッドを使⽤したらサーバ側にレスポンスを投げて次の状態が返ってくるまでルールベース AI に action を⾏わせ、返ってきた *6 プレイヤーの数が⼆⼈であり、利害が対⽴しており (⼀⽅が勝てば⼀⽅が負ける)、情報が不完全 (相⼿の⼿札が⾒えない等) であることを指します。 *7 本来のタスクより難易度の低いタスクを設定し、徐々に本来のタスクに近付けていく学習⼿法 49

第 4 章ファイトリーグ環境を OpenAI Gym で構築した話 4.5 実装前の準備タイミングで
observation を返す設計にしています。またカリキュラム学習を⽤いるため、ルールベース AI の強さを変えていくことで強化学習 AI の強さを上げていくような運⽤をしています。なお、この Gym の設計の問題は issue でも同様の議題が上がっており*8、いずれこの問題に対応したインタフェースが出てくるかもしれません。 4.5 実装前の準備ファイトリーグの学習環境を構築する前に、下準備を⾏います。なおこれから先のコードは以下のディレクトリ構成を想定しています。ファイトリーグ環境のディレクトリ構成 gym-fightleague/ README.md setup.py gym_fightleague/ __init__.py envs/ __init__.py fightleague_env.py まず、今回のファイトリーグ環境に必要なパッケージを定義します。 gym-fightleague/に setup.py を作成します。 gym-ﬁghtleague/setup.py 1: from setuptools import setup 2: 3: setup(name=’gym_fightleague’, 4: version=’0.0.1’, 5: install_requires=[’gym’, 6: ’numpy’]) 次に gym.env にファイトリーグ環境を登録します。 gym.envs.registration.register を使って⾃作環境を登録すると、 gym.make(’ENV_NAME’) を実⾏することで指定した環境のコンストラクタが実⾏され、環境の初期状態が渡されます。Gym ではこの gym.make() を書き換えることにより、学習環境を⾃由に変更できる仕様となっています。gym-fightleague/gim_fightleague に __init__.py を作成します。 *8 https://github.com/openai/gym/issues/934 50

第 4 章ファイトリーグ環境を OpenAI Gym で構築した話 4.6 実装 gym_fightleague/__init__.py
1: from gym.envs.registration import register 2: 3: register( 4: id=’fightleague-v0’, 5: entry_point=’gym_fightleague.envs:FightleagueEnv’, 6: kwargs={}, 7: ) また、このままではファイトリーグ環境を import する際に名前空間が⻑くなってしまうため、gym-fightleague/gym_fightleague/envs/__init__.py に以下の記述をしておきます。 gym-fightleague/gym_fightleague/envs/__init__.py 1: from gym_fightleague.envs.fightleague_env import FightleagueEnv 4.6 実装それでは、Gym インタフェースでファイトリーグ環境を構築していきます。環境はすべて fightleague_env.py の fightleagueEnv クラスで実装されています。まず、クラスと gym.make() で呼び出されるコンストラクタを実装します。 gym-fightleague/gym_fightleague/envs/fightleague_env.py 1: import os, sys, io 2: import numpy as np 3: import json, urllib.request 4: import gym 5: from gym import error, spaces, utils 6: 7: ACTION_NUM = 49 8: TARGET_NUM = 13 9: CPU_TYPE = 6 # random 10: ENDPOINT = ’localhost:4000’ 11: 12: class fightleagueEnv(gym.Env): 13: metadata = {’render.modes’: [’human’]} 14: 15: def __init__(self): 16: self.action_space = gym.spaces.Discrete(TARGET_NUM * ACTION_NUM) 17: self.observation_space = gym.spaces.Dict({ 51

第 4 章ファイトリーグ環境を OpenAI Gym で構築した話 4.6 実装 18:
’character_id’: \ 19: spaces.Box( 20: low=0, high=10000, shape=(16,), dtype=np.int32 21: ), 22: ’section_data’: \ 23: spaces.Box( 24: low=0., high=100., shape=(79,), dtype=np.float32 25: ), 26: ’field_condition’: \ 27: spaces.Box( 28: low=0., high=100., shape=(4, 3, 24), dtype=np.float32 29: ), 30: ’enable_actions’: \ 31: spaces.Box( 32: low=0, high=1, 33: shape=(ACTION_NUM * TARGET_NUM,), dtype=np.int32 34: ), 35: }) 36: self.reward_range = [-1., 1.] 37: self.game_id = None 38: self.observation = None 39: self.reward = 0.0 40: self.terminal = False 41: self.enable_actions = [] 42: 43: self.reset() 44: ) 1~5 ⾏⽬で必要なライブラリの import を⾏っています。json や urlib.request を import している理由は、reset や step メソッドで observation を取得する際、ゲームロジックの実装があるサーバ側とやりとりするためです。7~10 ⾏⽬で定数を定義しています。 7、 8 ⾏⽬は action の状態空間を定義しています。9 ⾏⽬の CPU_TYPE は、環境としてみなす相⼿側のルールベース AI のタイプを指定しています。最初からルールベース AI を強くしてしまうと報酬がもらえず学習が進まなくなってしまうため、まずランダムな⼿を打つ 6 番を指定します。エージェントが強くなってきたらこの CPU_TYPE を変えることで徐々に学習ができるようにしています。12 ⾏⽬~クラスの定義をしています。この際、 gym.Env を継承する必要があります。16 ⾏⽬の gym.space.Discrete(TARGET_NUM * ACTION_NUM) は action の状態空間の総数を指定しています。17 ⾏⽬~22 ⾏⽬は observation の状態空間を指定しています。character_id がファイターの情報、section_data が⼿札等の周辺情報、field_condition が盤⾯情報を指しています。enable_actions は、action に対して enable_action でフィルタリングしたりする際に利⽤したいため渡しています。30 ⾏⽬で reset メソッドを呼んでいます。これは、gym.make() された際に環境を初期化して初期状態を渡すためです。次にこの reset メソッドを実装します。 gym-fightleague/gym_fightleague/envs/fightleague_env.py 52

︙ 2: def reset(self): 3: self.observation = None 4: self.reward = 0.0 5: self.terminal = False 6: 7: response = self._api("reset", {’type’: CPU_TYPE}) 8: self.game_id = response[’game_id’] 9: self.enable_actions = response[’enable_actions’] 10: self.observation = {’character_id’: \ 11: response[’character_id’], 12: ’section_data’: \ 13: response[’section_data’], 14: ’field_condition’: \ 15: response[’field_condition’], 16: ’enable_actions’: \ 17: np.sum( 18: np.identity( 19: ACTION_NUM * TARGET_NUM 20: )[self.enable_actions], 21: 0 22: ), 23: } 24: return self.observation 25: ) reset メソッドでは、初期状態での observation を返すための実装がされています。 7 ⾏⽬で_api メソッドを呼んでいます。このメソッドにʠreset"とパラメータとして CPU_TYPE を指定してあげることで、バトルで使⽤するルールベース AI がセットされます。そして、ゲームロジック側ではエージェント側の状態が返ってくるまで CPU が配置を⾏っています。そのため、エージェントが先攻であればリーダーのみのフィールドの observation が、後攻であれば指定した CPU_TYPE に沿った⼿を打った後の observation が返ってきます。下記が_api メソッドの実装となります。 gym-fightleague/gym_fightleague/envs/fightleague_env.py 1: ︙ 2: def _api(self, function, request_json): 3: url = "http://{}/api/debug/agent_game/{}?_r=json".format( 4: ENDPOINT, function 5: ) 6: json_data = json.dumps(request_json).encode("utf-8") 7: request = urllib.request.Request( 8: url, data=json_data, 9: headers={"Content-Type": "application/json"}, 10: method="POST" 53

) 12: response = urllib.request.urlopen(request) 13: response_body = response.read().decode("utf-8") 14: result_objs = json.loads(response_body.split(’\n’)[0]) 15: return result_objs[’data’] この_api メソッドは、同じくゲームロジックとやりとりする必要がある step メソッドでも使⽤します。次はこの step メソッドの実装をします。 gym-fightleague/gym_fightleague/envs/fightleague_env.py 1: ︙ 2: def step(self, action): 3: response = self._api( 4: "step", {’game_id’: self.game_id, ’action’: int(action)} 5: ) 6: self.enable_actions = response[’enable_actions’] 7: self.observation = {’character_id’: 8: response[’character_id’], 9: ’section_data’: 10: response[’section_data’], 11: ’field_condition’: 12: response[’field_condition’], 13: ’enable_actions’: 14: np.sum( 15: np.identity( 16: ACTION_NUM * TARGET_NUM 17: )[self.enable_actions], 18: 0 19: ), 20: } 21: self.reward = response[’reward’] 22: self.terminal = response[’terminal’] 23: return ( 24: self.observation, self.reward, 25: self.terminal, {’foul’: response[’foul’]} 26: ) reset メソッドと同じく、_api メソッドを呼び、返ってきた変数 response の中⾝をそれぞれの変数に渡しています。step メソッドでは、_api メソッドを呼ぶ際、"step"とパラメータとして’game_id’、’action’ を指定しています。ゲームロジック側では渡された action を⾏い、同じように機械学習エージェント側の状態が返るまで CPU が配置を⾏っています。最後に、結果が標準出⼒で確認できるように render メソッドと render_cell メソッドを実装します。 gym-fightleague/gym_fightleague/envs/fightleague_env.py 54

︙ 2: def render(self, mode=’human’, close=False): 3: turn_count = int(self.observation[’section_data’][0] * 10) 4: hands = self.observation[’character_id’][0:4] 5: fields = self.observation[’character_id’][4:16] 6: field_cond = self.observation[’field_condition’] 7: 8: outfile = io.StringIO() if mode == ’ansi’ else sys.stdout 9: outfile.write(’\n’ 10: + "terminal: {}, reward: {}, turn_count: {}".format( 11: self.terminal, self.reward, turn_count 12: ) + ’\n’ 13: + "hands: {}".format(hands) + ’\n’ 14: + "field:" + ’\n’ 15: + "+-----+-----+-----+" + ’\n’ 16: + "+{}+{}+{}+".format( 17: self._render_cell( 18: fields[0], field_cond[0][0][19] 19: ), 20: self._render_cell( 21: fields[1], field_cond[0][1][19] 22: ), 23: self._render_cell( 24: fields[2], field_cond[0][2][19] 25: )) + ’\n’ 26: + "+-----+-----+-----+" + ’\n’ 27: + "+{}+{}+{}+".format( 28: self._render_cell( 29: fields[3], field_cond[1][0][19] 30: ), 31: self._render_cell( 32: fields[4], field_cond[1][1][19] 33: ), 34: self._render_cell( 35: fields[5], field_cond[1][2][19] 36: )) + ’\n’ 37: + "+-----+-----+-----+" + ’\n’ 38: + "+{}+{}+{}+".format( 39: self._render_cell( 40: fields[6], field_cond[2][0][19] 41: ), 42: self._render_cell( 43: fields[7], field_cond[2][1][19] 44: ), 45: self._render_cell( 46: fields[8], field_cond[2][2][19] 47: )) + ’\n’ 48: + "+-----+-----+-----+" + ’\n’ 49: + "+{}+{}+{}+".format( 50: self._render_cell( 51: fields[9], field_cond[3][0][19] 55

), 53: self._render_cell( 54: fields[10], field_cond[3][1][19] 55: ), 56: self._render_cell( 57: fields[11], field_cond[3][2][19] 58: )) + ’\n’ 59: + "+-----+-----+-----+" + ’\n’ 60: 61: ) 62: return outfile 63: def _render_cell(self, char_id, is_opponent): 64: if char_id == 0: 65: cell = " " 66: else: 67: if int(is_opponent) == 1: 68: cell = "x{:>4}".format(char_id) 69: else: 70: cell = " {:>4}".format(char_id) 71: return cell 必要な情報を observation から取って表⽰しています。なお、field_cond[0][0][19] には敵か味⽅かの値が⼊っており、_render_cell メソッドで、敵だった場合 x がつきます。以上が Gym インタフェースにそったファイトリーグの環境です。試しに、ランダム⾏動を⾏う random.py を実⾏してみます。random.py は以下のコードです。 gym-ﬁghtleague/random.py 1: import gym 2: import gym_fightleague 3: 4: NUM_EPISODE = 30 5: 6: # initialize game 7: env = gym.make(’fightleague-v0’) 8: # play game 9: for i in range(NUM_EPISODE): 10: print( 11: "====================EPISODE{}====================".format(i+1) 12: ) 13: observation_space = env.reset() 14: done = False 15: env.render() 16: while not done: 17: action = env.action_space.sample() 18: observation, reward, done, option = env.step(action) 19: env.render() 56

実⾏結果は以下となります。 ====================EPISODE1==================== terminal: False, reward: 0.0, turn_count: 1 hands: [340, 59, 178, 173] field: +-----+-----+-----+ + +x 89+ + +-----+-----+-----+ + + + + +-----+-----+-----+ + + + + +-----+-----+-----+ + + 179+ + +-----+-----+-----+ terminal: True, reward: -1.0, turn_count: 1 hands: [340, 59, 178, 173] field: +-----+-----+-----+ + +x 89+ + +-----+-----+-----+ + + + + +-----+-----+-----+ + + + + +-----+-----+-----+ + + 179+ + +-----+-----+-----+ ====================EPISODE2==================== terminal: False, reward: 0.0, turn_count: 2 hands: [340, 173, 178, 34] field: +-----+-----+-----+ + +x 89+ + +-----+-----+-----+ + + + + +-----+-----+-----+ + + + + +-----+-----+-----+ + + 179+x 68+ +-----+-----+-----+ 57

第 4 章ファイトリーグ環境を OpenAI Gym で構築した話 4.7 実装後に起きた問題 terminal:
True, reward: -1.0, turn_count: 2 hands: [340, 173, 178, 34] field: +-----+-----+-----+ + +x 89+ + +-----+-----+-----+ + + + + +-----+-----+-----+ + + + + +-----+-----+-----+ + + 179+x 68+ +-----+-----+-----+ ︙ 4.7 実装後に起きた問題 FightleagueEnv の実装により、gym ベースでエージェントと環境がやりとりできるようになりました。しかし実⾏結果をみるとわかる通り、このままでは-1 が返ってきてしまってすぐに試合が終わってしまっています。これは、エージェント側がランダムな⼿を打っていることと、打つことができない⼿を打ったら-1 の報酬で終了という実装なのが原因です。実際はランダムではなくアルゴリズムに従って打つから問題ないのでは？と感じられるかもしれませんが、強化学習ではルールは教えずもらった報酬によって学習するので、ランダムに⾏動して報酬がもらえないと学習が進みません。実際この実装で強化学習のアルゴリズムを回してみると、やはりなかなかプラスの報酬がもらえず、マイナスの報酬しかもらえない問題が発⽣します。強化学習では、このような環境のことを報酬がスパースな環境と呼びます。このような問題を解決するため、リーダーにダメージを与えることに対しての報酬を定義することにしました。step メソッドの self.reward を以下のような計算式に変更しています。 gym-fightleague/gym_fightleague/envs/fightleague_env.py 1: def step(self, action): 2: ︙ 3: if self.leader_reward: 4: enemy_leader_hp_rate = \ 5: (response[’enemy_leader_hp’] - self.enemy_leader_hp) \ 6: * self.enemy_leader_hp_rate / 10000.0 7: my_leader_hp_rate= \ 8: (response[’my_leader_hp’] - self.my_leader_hp) \ 9: * self.my_leader_hp_rate / 10000.0 58

第 4 章ファイトリーグ環境を OpenAI Gym で構築した話 4.7 実装後に起きた問題 10:
11: self.reward = \ 12: response[’reward’] - enemy_leader_hp_rate + my_leader_hp_rate 13: else: 14: self.reward = response[’reward’] 15: この実装は leader_reward が True の際、現在の HP と⼀つ前の状態の HP の差を取って、引数で指定した rate / 10000 の報酬を計算しています。それを敵味⽅両⽅に⾏い、self.reward に合計しています。これにより、リーダーダメージに対しての sub reward の定義を⾏いました。なお、CPU_TYPE 含めこのようなパラメータは fightleague_env.py のコンストラクタに引数で定義するようにしました。 gym-fightleague/gym_fightleague/envs/fightleague_env.py 1: class fightleagueEnv(gym.Env): 2: metadata = {’render.modes’: [’human’]} 3: 4: def __init__( 5: self, leader_reward=False, my_leader_hp_rate=1.0, 6: enemy_leader_hp_rate=1.0, cpu_type=CPU_TYPE 7: ): 8: ︙ また、gym-fightleague/gim_fightleague/__init__.py に以下を追加しています。 gym-fightleague/gym_fightleague/envs/fightleague_env.py 1: ︙ 2: register( 3: id=’fightleague-v1’, 4: entry_point=’gym_fightleague.envs:FightleagueEnv’, 5: kwargs={ 6: "leader_reward": True, 7: "my_leader_hp_rate": 0.5, "enemy_leader_hp_rate": 1.0 8: }, 9: ) このようにしておくことで、gym.make(’fightleague-v1’) を呼び出せば引数で指定したパラメータでの環境を新たに定義できます。また、スパースな報酬を軽減しています。しかしこのままでもまだスパースであるため、実際は enable_actions を使った action_space のフィルタリング等の⼯夫を⾏っています。 59

第 4 章ファイトリーグ環境を OpenAI Gym で構築した話 4.8 まとめ 4.8
まとめ以上、ファイトリーグにおける強化学習環境実装の紹介でした。今回の執筆では、ゲームサーバ側のロジック等、都合上触れていない点や端折ってしまった部分も多々あります。疑問点がありましたら、ぜひ私のメールアドレス*9にご連絡いただければ幸いです。 *9 [email protected] 60

第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 5.1 はじめに
「プログラムで何かを⽣成したい！」では、何を⽣成しよう？と考えていたときに、「MUCOM88 Windows」と出会いました。ざっくり⾔うと、このアプリは⽂字列を⼊⼒すると⾳楽ファイルを作ってくれます。⼩学⽣のころ PC-9801DX の BASIC で MML を⼊⼒しては、FM ⾳源を鳴らしていました。30 年の時を経て再びやってみます。⾳楽とプログラムの類似性はよく指摘されますが、実際に⾳楽をプログラムで表現するとどんな感じなのか？を試してみます。想定読者 • プログラムで⾳楽を作りたい⼈ • 8Bit サウンド、16Bit サウンド、FM/PSG ⾳源にときめく⼈ • プロシージャルでジェネレーティブなミニマリスト読者が得られる知⾒ • MUCOM88 で wav を⽣成する⽅法 • 構造的に⾳楽を作る⽅法 • MML の⼊⾨ • Elixir の⼊⾨ 61

第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 5.2 使⽤する⾔語やアプリ 5.2
使⽤する⾔語やアプリ Elixir で MML を⽣成し、MUCOM88 Windows で MML から wav を⽣成します。 Elixir Elixir は関数型⾔語です。C#と⽐較すると圧倒的に関数に関わる機能があります。⼿続き型よりは関数型の⽅が構造からデータを⽣成する⽅法を考えやすいだろうということで選びました。 MML MML は⾳楽を表現するため⾔語です。今⾵に⾔えばドメイン固有⾔語 (DSL) です。 MML はミニマムに⾳楽を表現します。昔のパソコンには必ず標準で BASIC という⾔語が⼊っていました。その BASIC には⾳楽を鳴らすために PLAY 関数があり、その引数にわたすのが MML です。メモリ容量の少ない時代の⾔語ですので、必然的にミニマムです。 MUCOM88 MUCOM88 は有名なゲーム⾳楽の作曲家である古代祐三⽒が使⽤していた「⾃作ツール」です。PC-8801 のアセンブラで書かれています。無料公開されています。 MUCOM88 Windows MUCOM88 を Windows で動作させるアプリが MUCOM88 Windows です。PC-8801 の CPU である Z80 と FM/PSG ⾳源のエミュレータが内蔵されています。このアプリのウィンドウに MML を書くと FM/PSG ⾳源が鳴ります。また、wav で保存できます。 5.3 MML を鳴らすさっそく、MML の練習のため、MUCOM88 Windows で⾳を鳴らしてみましょう。 62

第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 5.4 MML から
wav を⽣成する MUCOM88 Windows をインストール 1. 公式ページ https://onitama.tv/mucom88/ から "mucom88win190205.zip(最新 β版 ) (1,473,420bytes) (2019/02/05 13:00 update)" をダウンロードします。 2. mucom88win.exe を起動します。 MUCOM88 Windows で MML を鳴らすカエルの歌を MUCOM88 Windows で鳴らすための MML は次のように書きます。この MML をエディタ画⾯に⼊⼒し、F5 キーを押すと⾳楽が鳴ります。リスト 5.1: kaeru ‘A C192 T120 @78 v9 l4 cdefedc2 l4 efgagfe2 l2 cccc l8 ccddeeff l4 edc2‘ 上記 MML を順番に説明します。 • "A"は A チャンネルという意味です。A から K までチャンネルがあります。 • "C192"はクロック分解数です。4 とか 8 とかで割り切れる数にします。 • "T120"はテンポです。1 分間の 4 分⾳符の数です。 • "@78"は⾳⾊番号です。MUCOM88 Windows はデフォルトでたくさんの⾳⾊が登録されています。 • "l4"はデフォルトの⾳の⻑さを四分⾳符にします。 • "cdefedc"はドレミファミレドです。 • "c2"はドの⼆分⾳符と、個別に⻑さを指定しています。 5.4 MML から wav を⽣成する Elixir を絡めたいのでコマンドラインで wav を⽣成します。ちなみに、MUCOM88 Windows の Menu->Tool->「wav ファイルとして保存」でも wav ファイルを⽣成できます。 63

第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 5.4 MML から
wav を⽣成する必要なファイルを作業ディレクトリにコピーコマンドラインで wav を⽣成するには次のファイルが必要です。 • mucom88.exe CUI ⽤の本体です。 • mucompcm.bin K チャンネルのリズムの⾳源です。PCM データです。 • voice.dat FM ⾳源の⾳⾊パラメータです。 • 2608_bd.wav G チャンネルのバスドラの⾳です。 • 2608_hh.wav G チャンネルのハイハットの⾳です。 • 2608_rim.wav G チャンネルのリムシンバルの⾳です。 • 2608_sd.wav G チャンネルのスネアドラムの⾳です。 • 2608_tom.wav G チャンネルのタムの⾳です。 • 2608_top.wav G チャンネルのバスドラの⾳です。リズム⾳源の wav を取得 MUCOM88 Windows の G チャンネルを鳴らすには 2608_*.wav が必要です。しかし、それらの wav ファイルは MUCOM88 Windows に同梱されていません。別の場所から⼊⼿する必要があります。package の readme.txt に詳細がありますのでそれに従って⽤意してください。readme.txt は GitHub からもアクセスできます。https://git.io/fjvlT MML を作成下記の kaeru.muc を作成します。muc は MUCOM88 ⽤の MML ファイルの拡張⼦です。リスト 5.2: kaeru.muc A C192 T120 @78 v9 l4cdefedc2 l4efgagfe2 l2cccc l8ccddeeff l4edc コンパイルして wav を⽣成するリスト 5.3: mub を⽣成して、wav を⽣成する 64

第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 5.5 Elixir から
MML を⽣成する MUCOM88 -c kaeru.muc -o kaeru.mub MUCOM88 -x kaeru.mub -w kaeru.wav ⽣成された kaeru.wav は⾳楽再⽣アプリで再⽣できます。 5.5 Elixir から MML を⽣成する Elixir のインストール Chocolatey を使⽤すると簡単に Elixir をインストールできます。Chocolatey は Win- dows ⽤のパッケージ管理ソフトです。Mac でいうところの Homebrew です。リスト 5.4: Elixir のインストールコマンド choco install elixir Elixir から MML を⽣成するまずは、単純に出⼒します。リスト 5.5: kaeru-01.exs "A C192 T120 @78 v9 l4cdefedc2 l4efgagfe2 l2cccc l8ccddeeff l4edc" |> IO.puts リスト 5.6: kaeru-01.exs を実⾏して kaeru.muc に保存するコマンド elixir kaeru.exs > kaeru.muc 65

第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 5.6 関数⾔語で⾳楽を表現する makefile
で作業効率アップ筆者はエディタとして Emacs を使⽤しています。ctrl-c, c で make -k を実⾏したいので、wav ファイルが⽣成されるように makefile を書きました。リスト 5.7: makefile に kaeru.wav を⽣成するコマンドを追加 kaeru: -elixir kaeru.exs > kaeru.muc -mucom88 -c kaeru.muc -o kaeru.mub -mucom88 -x kaeru.mub -w kaeru.wav makefile の凝った機能は使⽤していません。シェルコマンドを実⾏するだけです。ただ、mucom88.exe がエラー以外に 0 以外を返します。そのため、コマンドの前に"-"を付けて、戻り値が 0 以外の場合も次のコマンドを実⾏するようにしました。 5.6 関数⾔語で⾳楽を表現する⾳楽には縦の構造と横の構造があります。縦の構造は⾳の重なりであり、横の構造は時間です。まさに楽譜のイメージですが、縦軸で楽器のパートや和⾳が表現し、横軸でリズムや曲の展開を表現します。⾳楽の横軸横軸をもう少し分解します。⾳楽をよく聞くと、だいたい 8 拍でまとまっており、その 8 拍が 4 個でまとまりを作っています。8 拍やその集合を表現するちょうどよい⾔葉が⾒つからなかったので、⽤語を定義します。 • フレーズは 8 拍 • ブロックはフレーズの集合 • 曲はブロックの集合定義した⽤語を⽤いて、ある曲を分析したところ、ブロック構成はイントロ,A メロ,B メロ, サビ,A メロ,B メロ, サビ, 間奏,c メロ, サビ, アウトロでした。イントロは 2 フレーズ、そのほかのブロックは 4 フレーズでした。A メロが複数回かありますが、同じメロディーではあるものの、伴奏の楽器構成が違いました。 66

第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 5.6 関数⾔語で⾳楽を表現する⾳楽の縦軸
⾳楽は⾳が重なっています。複数の楽器パートで構成されます。たとえば、ドラム、ベース、ギター、ピアノ、ボーカルという構成です。それぞれのパートは単⾳のときもあれば同時に複数の⾳が重なっていることもあります。ドラムならキック、スネア、タム、ハイハット、クラッシュシンバルで構成されています。ピアノとギターはドミソなどの和⾳、複数の⾳を同時に鳴らします。ブロック単位でそれぞれが⼤胆に変化します。たとえば、ギターは最初の A メロはコードをそのまま鳴らしていても、2 回⽬の A メロはアルペジオになったりします。また、ドラムはあるブロックではハイハットだけになるなど、登場する楽器が変化します。コーディングのための定義関数として表現するためにあらためて⽤語を定義します。 • ⾳楽はブロックの集合 • ブロックはパートの集合 • パートはフレーズの集合 • フレーズは 8 拍分の MML • フレーズは 2 個のユニット • ユニットは 4 拍分の MML フレーズをコードで表現ここまでの考察をコードに落とし込みます。抽象的な話もコードに落とすと具体的になります。構造を関数で表現し、MML を⽣成します。リスト 5.8: kosei.exs defmodule Kosei do def gen_phrase(:bass_11) do gen_units([:bass_1_1, :bass_1_1]) end def gen_units(units) do units |> Enum.map( fn unit -> gen_unit(unit) end) end def gen_unit(:bass_1_1) do "K0l16[gc>dg<]4 " end def gen_unit(:bass_1_2) do "K7l16[gc>dg<]4 " end 67

第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 5.6 関数⾔語で⾳楽を表現する end
Kosei.gen_phrase(:bass_11) |> IO.puts リスト 5.9: elixir kosei.exs の実⾏結果 K0l16[gc>dg<]4 K0l16[gc>dg<]4 曲の構造をコードで表現ダンス⾳楽にありがちな、ベースを抜いたり、ドラムだけ変えたりなどを繰り返しながら曲をふくらませることは簡単にできるようにします。イントロ、A メロ、B メロを atom のリスト表現します。曲の構成を、イントロ,a,b,a,b、イントロ,a,a,b,b としてみました。ブロック単位で順番を⼊れ替えることで、新鮮さを維持したまま曲を膨らませられます。リスト 5.10: gen_music def gen_music() do [:header, :intro, :amelo, :bmelo, :amelo2, :bmelo2, :intro, :amelo, :amelo2, :bmelo2, :bmelo2, :outro] |> gen_blocks() |> to_mml() end 曲が完成パートを増やしたり、構成を修正したりして、なんとか曲を作ることができました。部分と全体がつながっていて、少しいじるだけで、曲全体が⼀気に変わるのはとても気持ちがよく、気楽にフレーズの変更などを⾏えました。 MUCOM88 Windows のウィンドウで実験したり修正し、コードに書き戻すというのは、まさに REPL(Read-Eval-Print Loop) です。本来なら⼯程が分かれるであろう、試⾏錯誤と全体の製作が同時に⾏えます。 68

第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 5.7 ハマったこと 5.7
ハマったことやってみていくつかハマったことがあります。 wav が⽣成されないコマンドラインの MUCOM88 で wav を⽣成するのに苦労しました。リスト 5.11: ⽣成できなかったコマンド mucom88 -x kaeru.muc -w kaeru.wav 上記のコマンドで直接変換できると思いこんでいました。しかし⽣成されません。しばらく悩んだあげく公開されているソースコードを読みました。ソースコードは GitHub https://github.com/onitama/MUCOM88 にあります。 muc からを mub に変換したあとに、mub->wav にする仕様でした。リスト 5.12: ⽣成できたコマンド mucom88 -c kaeru.muc -o kaeru.mub mucom88 -x kaeru.mub -w kaeru.wav 上記のコマンドで無事 wav が⽣成できました。⽣成された wav が無⾳やっと、サンプルの曲から wav ファイルが⽣成できた思ったら無⾳です。何も鳴っていません。原因は、mucom88.exe の場所にパスを通して実⾏していましたが、⾳⾊データ読み込めていませんでした。mucom88.exe は voice.dat ファイルをカレントディレクトリから読み込みます。-v で voice.dat を明⽰的に指定する⽅法があります。とはいえ、作業ディレクトリにコピーすることにしました。 69

第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 5.8 感想とまとめリズムが鳴らない
1 ⽣成された wav ファイルの、K チャンネルが鳴っていませんでした。原因は、前述と同様ですが、リズムの⾳声データが読み込めていませんでした。作業ディレクトリに mucompcm.bin をコピーすることで解決しました。リズムが鳴らない 2 ⽣成された wav ファイルの、G チャンネルが鳴っていませんでした。リズムの⾳声データが読み込めていませんでした。2608_bd.wav などの wav ファイルも必要でした。これは MUCOM88 Windows に同梱されていないため、そもそも存在していませんでした。別のサイトからダウンロードするなりして⽤意するものでした。 5.8 感想とまとめワークフロー⾳楽を構造で扱うことができました。⼊れ替えたり、繰り返したりすることがとても楽にできます。⾳楽は繰り返しが多く、ただ、繰り返しすだけではなく、少しずつ変化します。部分の変更が全体に影響します。このあたりはプログラミングと同様ですので、重複した部分をまとめることで直交性を獲得して変更に対して柔軟に対応できます。 MML は柔らかい MML は構造がないため、簡単ですのですが、たとえばどこかで 8 分⾳符分ずれたりすると、どこでずれたのかを探すのに時間がかかります。また、同じフレーズをまとめて修正するのも⼿間がかかります。 Elixir は奥深い結局、コードには、重複した表現があります。もっとうまくまとめられそうです。ただ、まとめすぎると柔軟性がなくなります。データドリブンに寄せたほうがよいのか、アルゴリズムで⽣成させるほうに寄せたほうがよいのか、迷いながらの実装でした。結局、単純にデータを返す⼩さい関数をたくさん作成しました。Elixir はコードを⾒直すたびに、重 70

第 5 章 Elixir と MUCOM88 で構造的な作曲に挑戦 5.9 成果物の場所複パターンをまとめられてとてもコンパクトになります。
作曲は奥深い正直、作曲能⼒はまだまだですが、今回の執筆のために⾳楽の構造についていろいろ分析し、調査したので少しは成⻑しました。今まで適当に⾳を鳴らすだけだったので、始めから終わりまでを作りきるのはよい経験でした。 5.9 成果物の場所今回作成した成果物を下記に公開しました。 • makeﬁle https://git.io/fjvCX • techno2.exs https://git.io/fjvcT • techno2.muc https://git.io/fjvcO • techno2.wav https://soundcloud.com/yamayatakeshi/techno2 71

著者紹介⾓⿓徳 (第 1 章担当, GitHub: Blasthal, Twitter: @Blasthal)
ゲームを作っていないと発狂する男。モンストでは主にストライクショットや友情コンボなどの実装を担当している。エンジニアリングだけでなく、企画、イラスト、モデル、アニメーション、サウンドなどなど、ゲーム制作に関係すること全般に⾸を突っ込む。柳澤貴宏 (第 2 章担当, GitHub: TakahiroYanagisawa) ミクシィには中途⼊社。以前はコンシューマ機のゲーム開発を主にやっていました。最近はスマホとコンシューマ機で対戦ができるリアルタイムマルチの仕組みを作っています。プライベートではスマホアプリを数本リリースしています。村上克弥 (第 3 章担当, GitHub: Katsuya100) 普段はゲーム作りとツール作りと最適化っぽいことをしています。第 3 章の執筆にあたり、⼀番⼤変だったのは、ページ数の削減です。渡辺莉央 (第 4 章担当, GitHub: simasan0118) ミクシィ 18 新卒で、今は、ファイトリーグの機械学習部分を担当しています。最近は強化学習を⽤いた配置予測モデルの検証を⾏っています。ヤマヤタケシ (第 5 章担当, GitHub: toymany, Twitter: @toyman_jp) 近年はスマホ⽤のゲーム開発プロジェクトに参加しています。趣味でアナログカードゲームを作ったり、ゲームアプリを作ったりしています。 72

付録著者紹介宮原⾹奈⼦（表紙デザイン担当）普段は web 広告やイベントの KV・ロゴ、紙周りのデザインをやってます。飽きっぽいですが最近はトランプのデザインを研究中。
杉⽥絵美 (プロジェクト推進・制作進⾏等の庶務, GitHub: esugita, Twitter: @semiemi7) 元エンジニアで、ミクシィでは、Perl を触ったり、アプリを触ったり、新規事業の PM をしたりして、今は、DevRel チームで各種イベントを企画・運営したり、技術的な知⾒のアウトプット活動をサポートしたりしています。喜多功次 (制作アシスト, GitHub: kojikita, Twitter: @kojikita) DevRel チームで勉強会やイベントの運営などをしています。元エンジニアで以前は web フロント側のサービス開発やアドテクなどを担当していました。JavaScript が好きで、最近は PWA に注⽬しています。 73

XFLAG Tech Note vol.02

XFLAG Tech Note vol.02

More Decks by MIXI ENGINEERS

Other Decks in Technology

Featured

Transcript