見出し画像

嗚呼、失敗也ゲーム制作

まえがき

普段clusterでワールド制作をしていますが、火星銭湯や蘇州紫夜、アラビアに神社など雰囲気だけで制作しており、ゲーム制作はあまりしたことがありません。
いままで制作したゲームは、ゲームJAM21年夏に向け制作したUpsidedowntown(現在非公開)というアスレチックゲーム、
ゲームJAM22年冬のMultiplicationDungeonof Mayan(現在非公開)、
22年2月お題企画用のColor Cats in NewYork

のみ。いずれもゲーム要素というよりはやはり雰囲気重視のワールドです。いまきがついたけど、全部英語だ!

なお、ひとつだけ言い訳をすると、21年夏は盆踊り準備と重なり集中できず、22年冬は仕事と被って10時間ほどしか使えず、という状況でした。

ワールドクリエイターは大きく分けると、いまのジャンル分けであるアート(ビジュアル)派、ソーシャル(コミュニティ)派、ゲーム派がいると思ってるのだけど、私はビジュアル派なので、2年弱ワールド制作やっているとはいえゲームのことは基礎の基礎でもわかっていなかったりする。
それでも果敢に挑み、ノーコードでできるCCKのおかげで、ある程度ロジックやギミックができるようになったのは自分をほめたい気持ちもある。

ゲームを創ろう

さて、本題ですがゲームJAM22年秋が発表される前、TGSの話題を見てゲームワールドを創ろうと思い立ちました。乗り物に乗って戦うゲームが前からイメージにあったのと、中学生くらいの時に有線のロボットでエアホッケーみたいなゲームを選択授業でやったのが楽しかったので、それがやりたいな、と思い、マシンに乗って行うサッカーゲームを創ろうと思い立ったのです。

スタジアムやロビーなど場所を創っていくのはお手の物です。テーマをお得意の火星にし、シリーズとしての繋がりもつくりました。火星サッカー、語呂もいいし。なによりモチーフが決まっていると全体像作り上げていくのが楽です。
このゲーム、mobiと名付けた一人乗りの未来感ある乗り物にのってサッカーをします。
まずはmobiをどうするか、boothやassetstoreをしらみつぶしに探し、まあまあイメージに合った乗り物を見つけました。
これの挙動を馬型にするかヘリ型にするか車型にするか悩みましたが、ある程度自由が利かない方が面白そうだと思い、車型にしました。
馬型にしてジャンプさせるのも魅力的でしたが、それを捨て不自由さを選びました。

続いて手掛けたのがUIとタイマー。今回俯瞰型のミニマップが作りたかったので、mobiとボールに付随していくアイコンを付けたミニマップをUI表示させたり、遊び時間も選べるようにしたり、参加人数を選択できるようにしたり。参加人数に合わせてmobiを出したり、全員が搭乗したことを計算して試合を開始させたり、視界ジャック&ボイス付きのオープニング制作したり、3週間程度一進一退する場面もありつつ、完成させました。

UI表示によるタイマーとミニマップ

Unity上で一人で遊んでいるときは、わりと夢中になっていくらでも遊べ、こりゃあみんなでやったら面白くて盛り上がるんじゃなかろうか、とリリースを楽しみにしておりました。

さて、リリース前にデバッグ

Unityと挙動が違う場面があるのと、多人数で遊んだ時の挙動がUnity上でわからないので、ご協力いただける方をちょこっと募ってデバッグしました。
自分のサブ垢をいれてもできるんだけど、この時点ではそこそこ自信もあったし、なにより人と遊んでみたかったので、海底世界飲み会の合間にそこで飲んでいた方々に少しだけ手伝っていただくことにしました。不安があるとすれば1回目のゲームを終えて、2回目始まる際にしっかりリセットされるかくらいが心配な程度でした。

デバッグをはじめて人数のカウントによる参加者締め切りやオープニング、タイマー動作やミニマップ、UIもすべてうまくいった。これはもうリリースできるぞ、大成功だ!旅行中船の上でもやった甲斐があった。ほっと一息。

ところがだ。動かないのだ、肝心のボールが

正確に言うと、私が触れたときにしか動かないのだ。この時点でピンときた。これは、うわさに聞く「オーナー問題」とやらだ、と。
ボールは同期をとるためにMovable Itemになっている。これがないと、それぞれの人から見たときに、ボールの位置が同期せず、バラバラになってしまう。つまり、自分が見えているボールと他の人が見えているボールが別のものになってしまうのである。
他にもゴールしたときのギミック発動などのために、ボールをItemにするのは必須だ。
一方、mobiも乗り物なので当然Itemである。これにより、ボールのオーナー=一番最初に入室した人、mobiのオーナー=搭乗者となるわけだが、ここで何の問題が起きるかというと、オーナーの違うアイテム同士の衝突はうまくいかない、という現在のclusterの制約にひっかかってしまうようなのだ。さらに非オーナーのアイテム(この場合はボール)はRigid bodyのkinematicが自動的にtrueになってしまうようだ。つまり、一番最初に入室した人以外から見たボールは、当たっても動かない岩と同じなのである。これではゲームにならない。
ちなみに、mobiからはビームが発射できる。しかし、ビーム自体も発射した人がオーナーとなるItemなので、同様のことが起きてしまう。

これを改めて読むまで、この基本に全く気が付かなかった。しかもご丁寧に「物理的な衝突に強く依存したゲームデザインは避けてもらうのが無難です。野球のように、投げる人と打つ人がいるような仕組みは不向きと言えます。」とまで書いているではないか!
説明書を読まずにゲームを始める悪い癖発動である。
ボールが動くなんて当たり前だと思っていて、その上に人数カウントやUIやいろいろ苦労を乗せてきたのに、一番下にあって簡単だと思って意識もせず、なおかつゲームの根幹をなすものがうまくいかなかったので、これはもうどうしようもない。
mobiとボールだけを置いた時点でマルチプレイしていればこれに気付くことができ、その後の時間が不要だったのに。ここまで創りこんで初歩の初歩で成り立たないとは。嗚呼、大失敗。

打開策を考えた

最初に思い付いたのはそれぞれがmobiに乗った瞬間にそれぞれがオーナーのボールをItemとしてクリエイトし、これらをなんとか同期できないか、というものだ。ただ、結局同期元がオーナーボールである以上はあまり意味がない。参加選手の数だけボールを創る方法もあるが、それではサッカーではない。(いや、むしろ火星サッカーなら何でもありなのだけど、ただどれが自分のボールかわからなくて混乱する)
次に考えたのは、ItemではないボールとItemのボールをなんとか紐づけられないか、という方法だった。そこでまずは単純にコライダーとRigidbodyをつけたボール(虚のボール)を用意し、Itemボール(実のボール)がそれをConstraintで追従する形を創った。
一人マルチプレイをしたところ、非オーナーでもボールは動いた。ただ、正直最初から分かっていたことだが、実のボールが同期しない虚のボールを追ってしまっているので、途中からプレイヤーによって見えるボール位置が変わってしまった。ワンチャン同期信号だけ送れるかな、と思ったのだけど。
となると、逆はどうだ。実のボールを虚のボールが追う。これも結果を見ずとも失敗である。結局実のボールに非オーナーは影響を与えられないので、意味がない。虚のボールに力を与えたところで、実のボールと位置が変わらないのだから当然である。この状態でConstraintのWeightを0.99にしてみたが、挙動がおかしくなり勝手に舞い上がっていくだけだった。
Constraintではなく、一回り大きい虚のボールの内部に実のボールを入れてみてはどうか。Sphereコライダーだと中に入れられないのではじき出される。それであれば、Meshコライダーではどうか。一見うまくいきそうだったが虚のボールのRigid BodyでMeshコライダーをconvexにするか(これだと結局Sphereコライダーと同じ)、kinematicにしなければならず、これもうまくいかなかった。他にも実のボールにon collideでAdd Instant Forceを付けるなども試したが、非オーナーで動かないか宇宙の果てに飛んでいくか、どちらかであった。

結果的に

ここにきて、逆にmobiのほうを何とかすればいいのではないか、と考えた。mobiに追従するコライダーを用意すれば、それはItemではないのでボールへの影響を与えられるのではないか。
mobiを囲むようにドーナッツ型のコライダーとRigid bodyを付け追従させたのだが、結局ボールがkinematicだからとおもうが、わずかに動いたものの思い通りには動かなかった。
ビームの方もItemではないコライダーを追従させ、こちらもわずかには動いたがうまくはいかなかった。

結果、行き詰ったため本PJは凍結することとした。clusterの開発が進むか、他に画期的な方法が思いつかない限りは解決できそうにない。
ワールドは非公開にしたままにしようと考えたが、ゲームJAMもあるし、ゲームワールドを創りたい人の参考になるかもしれないと考え、失敗例として本記事とセットで公開することとした。

本記事を読み進める際の参考にもなるだろう。だれかが解決方法を見つけてくれるのではないかという淡い期待もある。

これだけ書くとclusterでのゲーム制作は難しいのでは?と思ってしまう人もいるかもしれないが、私のようにさっぱりわからなかった状態からでもCCKを使ってノーコードでそれなりのものが創れるのは表現として魅力的である。根本さえ間違えなければきっと楽しいものが創れる。そして、やはり基礎は大事。私の場合、一番簡単だと思って気にも留めなかったところで躓いたが、これを失敗例として反面教師にしてほしい。そしてゲームJAMに参加してみてほしい。なにより、わからなかったことをひとつずつ理解しながら、脳みそフル回転で手を動かすのが一番の創作であり楽しいのだ。
中の人や先人たちによる公式記事が充実しているのも魅力的なので、まずは小さく試してみることが重要だ。最初から大きなものを創って、根幹でミスることのないように。失敗とはいえいいトレーニングになったし、勉強になった。
ゲームJAMでの健闘を祈る。


この記事が気に入ったらサポートをしてみませんか?