2020年12月22日、新たなオンラインセミナーとして、「The Method #0 　～モンストのギミック開発フロー紹介～」を開催しました。“The Method”とは、さまざまなプロダクトにおいて実践されているノウハウやメソッド惜しみなく共有する「参加型のオンラインイベント」です。

さて、第1回となる今回は、『モンスターストライク（以下、モンスト）』のギミックに関する話です。ギミックは、モンストを面白くする上で欠かせない要素の一つ。開発現場では、どのような“ものづくり”をしているのか…本記事では、配信された内容を簡潔にまとめて、紹介していきたいと思います。

登壇者の紹介

まず最初に登壇者の紹介です。今回のイベントで話をしてくれるのは、モンスト事業本部のクライアントエンジニア、角 龍徳（かくたつのり）。現在は、国内版モンスターストライクで、ストライクショットや友情コンボなど主にギミックの実装を担当しています。

角 龍徳（かくたつのり）
複数社のゲームデベロッパーにてゲーム開発を経験したのち、2016年2月ミクシィ入社。国内版モンスターストライクで、ストライクショットや友情コンボなど主にギミックの実装を担当。フロントエンドを横断してUI周りのアウトゲーム側の実装も行う。

▲配信中の様子

その後、司会進行役の「ミクシル」編集長・深町からの質問に、クライアントエンジニア・角龍徳氏（かくたつのり）が答えていく形でイベントは進行していきました。

エンジニアからの提案で採用されたSSや友情コンボも多数

深町　早速ですが、モンストにおけるストライクショット（以下、SS）の開発フローについて教えてください。

角　はい、まずは企画チームが大まかな仕様を決めます。その後、VFXチームや僕らエンジニアチームも合流して、現実的に実装可能な仕様に詰めていきます。エフェクトを作ってもらったり、コーディングをしたり、企画の方に確認をとったり、何度も繰り返して完成へと持っていきます。実装が完了したら、QAチームにバグの確認をしてもらい、都度修正していきます。発見された不具合への対応が終わったら、後はリリースを待つ、という流れになります。

深町　こう見ると一般的なゲーム開発と似た開発フローと捉えてよさそうですね。ちなみに、新しい開発案件は企画チームからのものがほとんど？

角　企画チームからの依頼が中心ではありますが、そうじゃないものもありますね。

深町　エンジニアから提案することもあると？

角　あります。エンジニアから提案して、実装されたものも多くあります。たとえば、「ラグナロク」というキャラが使うSSの挙動は、僕が提案したものです。モンスト上の外壁に当たると跳ね返るものを、跳ね返らず反対側の壁から出てくる、というものです。
もう一つは友情コンボの「チップソー」。敵を切り刻みながら貫通していく時に速度が下がるので、大柄の敵によりダメージを与えやすい、そんな特徴があります。

深町　両方とも新しい演出でしたよね。こういったアイデアはどこから着想を得ているんでしょう。

角　僕の場合は、いろいろなゲームからヒントをもらうことが多いですね。「チップソー」でいうと、もともとはドリルのデザインだったんですよね。でも、モンストに取り入れてみると、ドリルの先端が必ず敵に突き刺さらずに見栄えが悪いケースがあったんです。そこで、丸いチップソーの形にすればどの部分に当たっても見栄えが良いのではないか、と変化した経緯があります。

深町　着想を得るゲームについてですが、これは現在のゲームに限らない？

角　昔のゲームからヒントをもらうこともたくさんあります。実際に自分が遊んだものはもちろん、ゲーム実況動画を見て「ここが面白そう」「モンストで使えるかな」などのメモを残しています。

深町　なるほど。採用されやすい提案とかって共通点があるんでしょうか？

角　今までになかった“モンストの遊び方”が作れていると通りやすい印象がありますね。ユーザーに新しい価値を提供することができますから。あとは、テクニック的なところでいうと、提案時に実際の挙動が見えるものがあると伝わりやすいです。なので、エンジニアは事前にモックを作ることが多いですね。

深町　SSや友情コンボの開発期間はどのぐらいですか？

角　案件にもよります。ライトなものだと1日、重たいものだと1週間ぐらいかかることもあります。

深町　けっこうバラバラなんですね。実際に開発がスタートするときは、どのぐらいまで内容が決まっているんでしょうか？

角　開発の流れで、重要な点やゴールなどの致命的な点を決めますが、細かいところは決めずにスタートすることが多いですね。図にすると、こんな感じ（笑）青い部分が決まっている箇所です。

深町　ガチガチに決めてスタートするわけではないと。

角　ええ、決めきれないというのが本音でしょうか。実際の挙動を見てから良し悪しが判断されて仕様が変わることはありますし、無理に決めても曖昧なのは変わりませんから。

深町　重要なところだけ決めておくというのは、たとえばどういうこと？

角　たとえばキャラの動きの中で「敵に向かって移動する」ということは決めているけど、具体的な動き方についてはSSごとに変わるので後で決めよう、とかそんな感じですかね。

深町　なるほど。こういう案件を1人のエンジニアは、どのぐらい担当しているんでしょう？

角　案件のボリュームにもよりますが、だいたい5件前後かな。案件ごとにスケジュールが少しずつかぶりながら、進んでいくようなイメージです。

ユーザーのワクワクを求めて、技量を超えてチャレンジ

深町　モンストの開発全体像が見えてきたので、続いて、角さんが取り組んできた案件についてお聞きしたいと思います。これまでで、自分にとってチャレンジだったと思われる案件はありましたか？

角　いろいろありますが…中でも思い出深い案件は「エナジーハート」ですね。もともとは「エナジーサークル」と呼ばれるもので、その名の通りサークル（=円形）だったんです。エナジーサークルの円形をハート型にしたい、という話でスタートしたんですが、そもそも「座標ってハート型になるよう計算で出せるの？」という課題にぶつかって。当時の僕はエナジーハートを積むキャラが可愛かったからという理由だけで「やります！」と、見切り発車しました（笑）。

深町　できるか分からない状態でスタートしたってことですよね？どうやって完成できたんでしょう？

角　調べていったら、ハートをつくる関数が世の中にはたくさん存在していました。資料かき集めて、エクセルで計算したり、モンストのコードに落とし込んだり、パラメーター化したり…と、一つずつ「エナジーハート」の完成に近づけていきましたね。

深町　そうだったんですね。もう一つの「ブーメラン」というのは？

角　これも記憶に残っている実装実例です。モンストのブーメランはちょっと特殊な動き方で、発射された後、左回りに曲線を描いて戻ってくるんですが、この動きをプログラムするのはとても大変でした。というのも、あるだろうと思っていた曲線計算の機能がなくて…ないなら作るしかない！とゼロから形にしていきました。

深町　もしクリアできていなかったら、もっとつまらないブーメランだったのかもしれない？

角　それはあります。ブーメランには”ロマン”のようなものがあるようで、開発陣も思い思いのブーメランの動きを語ってました。カッコイイ動きになるだけで夢が広がるし、ワクワクしちゃいますね。なので、きちんと形にできて良かったと充実感は大きかったです。

深町　ユーザーが楽しんでくれることを目指して、チャレンジを続けてきたということなんですね。あとは、具体的なコーディングというところでは、意識してることってありますか？

角　最近だと参考書を読むようにしていますね。特にご紹介する2冊に書いてあることを意識していて、誰にとっても読みやすいコードを目指しています。

深町　そう思われるようなきっかけがあったのでしょうか。

角　昔は、かなり自分本位なコードを書いていたんですよ（笑）。自分のコードの悪い部分に気づくことすらできませんでした。でも、数カ月たって読み返してみると、自分が書いたものなのに良く分からなくなったりして、これは良くないなと。自分だけじゃなく同僚や後輩が読む可能性もありますから、コード解析の時間が削減できたらよいなと思って取り組んでいます。

ゲームエンジニアに大事なのは、ゲームに熱い情熱を注げるか

深町　最後に、角さんがモンストの開発に向き合う上で大事にしていることや、仲間に持っていてもらいたい考え方についてお聞きしたいです。

角　僕自身がモンストの開発に取り組む上で一番大事にしているのは・・・続きはこちら