Mech Battler Crisis開発録【紹介編】＃０３
Created: 2026/09/13
初めに
時は来た！
変形ロボットの時代到来！
プレイヤーが自分でロボットのAIをカスタマイズ！
拡張入力！UIカスタマイズ！モバイル対応！
すべてはプレイヤーの思うがままに！
Mech Battler Crisis開発録【紹介編】＃０３
開幕！！
前回記事の後、大学の実習や課題が重なり開発が停滞し、一年近くほとんど進捗を上げられないまま時間だけが過ぎていきましたが、今年の夏休みでとうとう自分の時間のほぼすべてをゲーム開発に注ぎ込む期間を設けることに成功し、進捗記事を書くことができました。
今回のテーマは「変形ロボット」です。
特に初期のほうはいきなり説明しても信じてもらえないし、自分自身できるかどうかわからなかったので言ってはこなかったのですが、私はかなり早い時期からMBCの開発目標の目安として「変形ロボットを作れるかどうか」という指針を考えていました。変形ロボットを作れるくらいの自由度があれば大体何でも作れるよね、じゃあそこまでやろうという考えで開発を行ってきました。
まだMBCがスペースロボクラという仮称で制作していた時から一貫してきた「物理演算・シミュレーションの簡略化」という方針も最終的には変形ロボットを誰でも自由に作れるゲームにしたかったという思惑があります。
（ちなみにもう一つは人型ロボットからたくさん飛び出してくる小型無人攻撃機が実装できるようにすることだったり。そちらの実装もすでに目途がついていてあとはタイミングと制作期間の問題）
長かった……本当に長かった。
今回はそんな超進化したMBCの進捗について紹介していきます。
概要
汎用入力基盤
技術的な話はいつか別記事にまとめようと思っているのですが、名前解決という方法を導入することでロボットの入力基盤を完全に汎用化しました。
どういうことかというと、今までのクラスと変数として固定化された静的な入力基盤では今後の拡張に限界があり、またロボットが最初から持っている標準入力データとプレイヤーが新しく定義する拡張入力データで扱いを変えなければならない二重管理の手間などが問題となったため、思い切って全部のデータを文字列とデータのセットにしてしまいました。
要するに今まで開発者が直接コードを書き換えないと修正できなかった入力データが、これからは文字列キーを追加するだけでいくらでも増やせるようになり、さらにプレイヤー自身がそれを制御することができるようになりました。
基本的にはいままでの入力基盤のような静的データへのアクセスを動的データのアクセスに切り替えると処理速度が悪化するのが普通で、特に今回のような文字列キーを使ったアクセスは、毎フレーム文字列を使うような処理にしてしまうとFPSが低下する可能性もあるわけですが、ここで名前解決を使います。
文字列キーを使って一回だけ高速で配列データにアクセスできるインデックスを辞書型から取得する、ロボットが動いているときは入力データを扱うすべてのシステムがインデックスで入力データにアクセスする、この方法によって辞書型の使用回数を最初に一回だけにしてしまい、実行時はほぼ最速のアクセスを実現しています。
あと、この名前解決の副産物として、普通はコードを直接書き直さないと定義を変えられないenumを実行時に拡張可能にする動的enumも実装可能になりました。
現在ロボットの入力はBool、Int、Float、Vector2、Vector3、そして動的enumの六つの型を扱うことができ、この六つでロボットの入力データは大体全部表現できます。もちろんこれで困ったら将来的にはまた別の型を追加することもできます。
この汎用入力基盤がMBC開発においてものすごい転換点で、ここから先紹介する追加要素は大体全部この入力基盤がないと実現困難だったシステムになります。
関節バインド設定
変形ロボットを作りたい。
人型形態と戦闘機形態を自由自在に切り替えるめちゃくちゃかっこいいロボットが作りたい！
しかし変形ロボットを作るには「このボタンを押したときこの関節がこの回転角度で回転する」というところまでプレイヤーが詳細に設定できなければいけません。
ところが、いままでのMBCはFK・IK関節こそありましたが、プレイヤーが内部のパラメータを編集するシステムがなかったので、開発側が足関節用・腕用など用途ごとに用意した関節を使ってロボットを動かすのが限界でした。
そして内部パラメータを編集できるようになったとしても、前述のとおりその時代のMBCはまだ入力データがクラスで固定化されていたので、開発側が「MoveInputはこの方式で入力を処理して、LookInputなら……」という風に各入力に対して一つ一つ手作業でFKJointの入力処理を記述しなければならない問題もありました。
しかし、入力基盤が汎用化された結果ここら辺の問題が全部片付いたので、とうとうプレイヤーが関節のパラメータを自由に編集できるシステムが実用化されました。
編集システムで関節ブロックを選択すると内部パラメータを編集できるエディターが開き、ここで回転角度や入力バインドを設定することができます。入力バインドは現状文字列キーを使って「この文字列キーの値が○○になったときこの回転角度に回転してほしい」という形式で設定を行う形をとっています。さすがに毎回文字列を手打ちするのは使い勝手が悪いので将来的には調整したいですが、現状でも関節編集システムは最低限の能力を実装しています。
UIカスタマイズ
これで関節側は入力に応じて自由自在に変形することが可能になりましたが……プレイヤーが入力を送るボタンのほうが準備できていませんね？
そういうわけでUI側も自由にプレイヤーがカスタマイズ可能な拡張UIシステムを実装しました。
現時点では拡張UIシステムはボタンとジョイスティックに対応していて、変形ボタンみたいな普通の拡張入力はもちろん、モバイル向けUIとしての機能もまるごと全部網羅するシステムになっています。
当然こんなシステムの使い道がロボットの入力だけというのはもったいないので編集カメラにも同じ基盤を流用してプレイヤーがカスタマイズ可能な形で編集カメラのモバイル入力システムをリメイクしました。
現段階ではさすがに全部を全部流用という形にはできなかったのですが、これからどんどんロボットUIシステムと編集カメラモバイル入力システムの共通部分をまとめていこうと思っています。
変形ロボットの実現
前述のシステムによってとうとう変形ロボットが製作可能になったので、その実証もかねて作ったのが冒頭に見せたこちらのロボットです。
このロボットの制作がそこそこ難航しまして……。
今更ではあるんですけど、自分はあくまでプログラマー志望の大学生であって、ロボットデザイナーでも何でもないので、いざ実際に変形ロボットを考えよう、そのための変形機構を考えようとなるとアイデアが思いつかなくて大変でした……（汗）それに、造形上の問題も考えると複雑な変形機構を実現するのは難しい。
そういうわけで、実際に腕を取り外した状態で分かりやすく変形機構を見えるようにしたのが以下の画像になるのですが、実はこれ足と翼以外ほとんど動いてないです（）
著作権に引っ掛かりそうなどこかで見たことのある変形機構は採用したくない。
複雑すぎる変形機構も採用したくない。
そんな制約の中で私が考案したのがS字変形機構というもので、上記画像のロボットの脚部を見てもらうとわかるんですが、本来線対称として配置されている脚部を前方に突き出してロール回転させ、下側になった片足を１８０度回転で後方に流すことで点対称（S字）に再配置する機構になります。
これによって脚部パーツだけで比較的自然に戦闘機形態における「機首パーツ」を表現することが可能になりました。なかなかの自信作ですね。
ノーコードAIロジック
この変形ロボット、AIに動かしてほしくないですか？
そのロジックを自由自在にカスタマイズしたくないですか？
「敵から離れているときは変形形態で急速接近」「接近したら通常形態に移行して攻撃」そんな変形機体の特性を活かしたアグレッシブな戦術で敵機体と戦ってほしくないですか？
できます。
そう、MechBattlerCrisisならね。
こんな感じのUI画面でプレイヤーがAIのロジックを自由自在にカスタマイズ可能です。
このAI編集システムは、方式としては毎フレーム判定用の条件式と処理を記述する簡単なビジュアルスクリプティングシステムとなっていて、上記画像で条件ブロックを組んで、判定に合わせてプレイヤーが作成できる関数を呼び出して処理を実行する形式をとっています。
この編集システムは自分のこれまでのMBC開発で培った独自の知見を組み込んだものとなっています。
一般的なノードベース型のビジュアルスクリプティングと異なり手続き型を採用、さらに条件は条件だけ、処理は処理だけを分離する方式をとっています。さらにAIロジックをステート単位にパッケージ化し、実行時には状況に応じてステート遷移で処理を切り替える仕組みも実装しています。
処理ブロックは条件と処理それぞれに用意された配列に保存されていて、条件分岐を横方向インデックスと勝手に呼んでいる仕組みで表現しているので、内部に命令を格納するリストがあったり、再帰処理を使っていたりするということはありません。完全に一本の配列として保存しています。
これらの仕様はノードベース型VSで問題となったコード肥大化と可読性の低下に対して最初から全力で対処しようとした結果です。ノードベース型VSにすることも考えたのですが、ノードとして構築したプログラムをセーブ・ロードする処理の実装が恐ろしく大変になることは容易に予想できたので、今回は手続き型を採用することにしました。
（そもそもノードベース型ができて手続き型だとできないことってn）
WebGL版ビルド
思えば大学一年生の春から開発を始めたMBCの開発は、もうすぐ三年目になろうとしています。
しかし、長期休暇を最大限利用して可能な限り頑張ったものの、もともとの構想がやはり巨大だったこと、そして開発中に自分の趣味が暴走してどんどん工数が増えていったことから、製品版のリリースは大学卒業までには到底間に合いそうもないことがわかってきました。
しかし私も現在進行形で就活中の大学生なので、ポートフォリオとして実際に動く形でこのゲームを卒業までに公開したいわけです。
そこでいままで想定していなかったWebGL版、つまりブラウザゲームとしてMBCをビルドできるかどうかを今回テストしました。
もともとプラットフォーム依存のシステムは全くと言っていいほど組み込んでいなかったので、理論上WebGL版ビルドは不可能ではないことはわかっていて、唯一負荷だけがネックだったのですが、実際にビルドを動かしてみたところほぼ全部の処理が普通に動いてしまうことが判明しました。
というわけで、WebGL版は普通に動きます。さすがにブラウザ上での実行なのでちゃんと動くハードは限られてくるとは思いますが、基本的機能はほぼ全部問題なく動くことが判明しました。
今後は目標をWebGLデモ版のリリースに切り替え、開発を続けていこうと思います。
おまけ
宣伝用にXアカウントを作成しました。
なかなか記事にまとめられないリアルタイムの開発進捗を投稿しています！
もしこの記事を見てくれた方がいればいいね・フォローをぜひよろしくお願いします！