結論
今Unityのネットワークマルチゲーム作るならMLAPIよりMirrorの方がいいかも
以前はUnityに完全に騙されてMLAPIを推しちゃってたけど、今はもうそれほど推してない。
騙したUnityが全部悪い。これだけはハッキリと真実を伝えたかった。
前置き
以前、Unityのネットワークマルチの現状について記事を書きました。
この記事は、ありがたい事に結構多くの方に読まれているようです。
しかし、この記事はUnityが書いた「自分のゲームに適したネットコードを選ぼう」という、Unityで使える色々なネットワークライブラリの比較記事の内容を鵜呑みにして書いたものです。
その後、UnityがMLAPIを買収した事で、件のブログ記事がMLAPIアゲしたいがための提灯記事だった疑惑が極めて濃厚になりました。
つまり、インチキ記事だったかもしれないという事です。
とは言え、この時点では疑惑は疑惑に過ぎなかったわけですが、その後、MirrorのDiscordを眺めてるとこのような書き込みを発見しました。
な…なんということでしょう。
このLukeさんという方は、Unityで働いていて、MLAPIのディスコにもよく出現するので、MLAPIチームの人だと思われます。
彼が、Mirrorのディスコで
・我々は別にMLAPIを安定した製品に使用可能なライブラリにするつもりとか無いねん
・今後もMLAPIで色々実験しておもちゃにして遊ぶぜ
・安定したライブラリが要るならMirrorの方がいいよ
ほとんどこういう意味の爆弾発言を投下しました!
う…ウソだろ…?だってUnityは公式ブログで、
”安定してサポートされたネットワークをMLAPIで提供する!”って言ってたじゃねえかよ!
Unity嘘だよな?
あまりに過激な書き込みだったので、ひょっとしてこのLukeさんは本物じゃなくてなりすましなんじゃないかと疑う人もいました。
やっぱり本物らしいです。
ちなみにLukeさんはこんな書き込みもしています。
件の、私が鵜呑みにしてしまったUnityブログのMLAPIアゲ、Mirrorサゲな比較表の内容を修正したコラ画像です。
一体何が起きてるんでしょうか?ふざけているのか?
私は正直言ってLukeさんの書き込みを見て最初怒りを覚えました。
「真面目に仕事しろよ!こっちは真剣にゲーム作ってんだよ!!」
UnityがMLAPIを安定したネットワークライブラリに仕上げる気が無くて、実験して遊びたいだけなら、そんなもん誰だって使いたいわけないですよね。
Unityは今までにUNETの開発をしくじり、DOTS Netcodeの開発もしくじりつつあり、信頼は地の底へと落ちつつあったところに、この追い打ちです。
いい加減にしてくれよ…そう思いますよね。
さらにLukeさんは「こんな書き込みしてるのがバレたらUnityをクビになっちゃうかもな~(爆笑」みたいな投稿もしてます。
これも、最初は世の中ナメとんのか?と思いましたが、冷静に考えてみると、もしかしたらLukeさんは自分のクビを賭けてまで、何か大事な事を我々に内部告発しようとしてくれてるのかもしれません。
何か、Unityの中で非常に良くない状況が発生しているのかもしれない…そんな事を勘ぐってしまう書き込みでした。
さて、つまるところ、これらのLukeさんの告発が本物だった場合、これまであくまで疑惑に過ぎなかった”UnityブログMLAPI提灯記事事件”はクロだと確定したと言えるでしょう。
つまり、Unityの記事のMLAPIの過剰な高評価はウソであり、Mirrorの方が優れている可能性が高い…という事です。
Mirrorについて
Mirrorってなんなの?というと、かいつまんで言うと、有志が開発しているUNETの後継ネットワークライブラリです。
Mirrorの作者のvis2kさんがMirrorの歴史について記事を書いてくれてるので、それを読めば経緯が分かるでしょう。
https://mirror-networking.gitbook.io/docs/trivia/a-history-of-mirror
かなり興味深い事実が色々と書かれてます。
vis2kさんは、昔はUNETの登場に心を躍らせてMMOゲーム開発に夢中になってました。
試しにそのMMOシステムをuMMORPGというゲームテンプレートアセットとして売ってみたら大人気になったそうです。
しかし、ボトルネックになったのはUNETの大量のバグです。
vis2kさん達は、必死でUnityにバグレポートを出したのに、Unityは「仕様です」と返答するだけで、全然修正してくれなかったそうです。(当時はクローズドソースだったのでユーザーは自分でバグを修正できず、途方に暮れるしか無かった)
実はその裏で、UNETのコアメンバーは沈みつつある船から脱出するかのごとく、次々とチームを去っていたのです!当然、修正したくてもできないですね。
そしてとうとう、UNETは放棄されました。
しかし、UNETのHLAPIは突如オープンソース化されたので、vis2kさんはこのHLAPIのバグを自力で修正しまくり始めました。
これが後のMirrorになったと。そういう経緯だったそうです。
「どうしてUNETチームは自分たちでUNETを作れるくらい凄い人達なのに、バグが修正できずにチームから逃げ出すハメになったんだろう?」という事についてもvis2kさんは述べています。
HLAPIのソースを掘っていくと判明した事ですが、実はUNETはNetworkView(UNET以前にUnityに搭載されていたレガシーのネットワーク機能)の上に乗っかって作られていたようです。
NetworkViewはRaknetというサードパーティのライブラリをラップしたものでした。
つまり、Raknetの上にNetworkViewを増築して、さらに3階にUNETを建て増しした…そういうカオスな状態になってしまっていて、恐らくもはや誰にも解読不能なコードだらけになっていただろう事は容易に想像が付きます。
まあそんなわけで、忌まわしいUNETのHLAPIを改造しまくって、やがてLLAPI(トランスポート層)も自作の物にすげ替えて完全に置き換えられた物がMirrorというわけです。
ちなみに、vis2kさんは現在Mirrorの開発に週80~100時間を費やしてるそうです。要するに毎日ずっとMirrorを開発してるって事ですね。
Mirrorの長所(MLAPIと比べて)
採用実績
Mirrorには、実際に発売されてるゲームで採用されているという実績があります。
https://mirror-networking.com/showcase/
これが何を意味するのかと言うと、これらのMirror採用ゲームの開発、および運用において、色々とMirrorで起きたバグは報告、修正されているはずという事です。
つまり、Mirrorがそれなりに安定している事は約束されている事を意味します。
ショーケースの中では、Population:ONEが有名ですね。
VRゲームでなおかつバトロワ、さらにQuest対応となると、要求されるネットワーク品質のハードルはかなり高いものになると思われますが、それにMirrorが使われてるというのはMirrorのポテンシャルの高さを表してると言えるかもしれません。
一方、MLAPIには事実上、採用事例はありません。
アセットがある
ネットワークライブラリがいくら高機能でも、アセットストアにゲームテンプレートアセットが無いと、ゲームを作り始めるのは面倒です。
現在、Unityアセットストアにあるネットワークマルチができるゲームテンプレートは、殆どPhoton Cloud(PUN)対応の物ばかりです。
https://assetstore.unity.com/packages/templates/packs/mfps-2-0-multiplayer-fps-101171
https://assetstore.unity.com/packages/templates/systems/ufe-bundle-24884
PUNはたしかに手軽に他人とネットワークマルチが試せて便利なのですが、秒間メッセージ数の制限があるため、マルチプレイ人数は4~8人で頭打ちになるので、それ以上の人数のバトロワとか作ろうとしても困難です。
とは言え、PUNからPhotonServerに移行すれば秒間メッセージ数の制限は無くなります。しかし、PhotonServerは”サーバを設置する権利”にお金を払うハメになります。これはサーバ代とは別にかかります。MirrorやMLAPIのヘッドレスサーバならそんなコストはかかりません。
PUN以外だと、たま~にMirrorに対応してるアセットもあります。
https://assetstore.unity.com/packages/templates/systems/pirates-of-voxel-play-189096
https://assetstore.unity.com/packages/templates/systems/ummorpg-remastered-159401
https://assetstore.unity.com/packages/templates/systems/ummorpg-2d-remastered-102632
https://assetstore.unity.com/packages/templates/systems/usurvival-95015
https://assetstore.unity.com/packages/templates/systems/umoba-62542
uSurvivalとかuMobaとか、uなんちゃらという名前のアセットがいくつかありますが、これらはMirror作者のvis2kさんが全部開発しています。
まあ、時系列的にはuMMORPGを作っていたvis2kさんがMirrorの開発も始めたって流れですが。
ともあれ、ネットワークライブラリの作者自らがバキバキに最適化してくれているネットワークマルチのゲームテンプレートという事で、相当パフォーマンスが高いようです。
uSurvivalのマニュアルによると、コミュニティのメンバー達の協力で負荷テストを行ったところ、122人の同時参加に成功したそうです。(結構強力なサーバーを借りてサーバにヘッドレスビルドを置いた場合)
さらに、uMMORPGでは480人参加をテストした事があるそうで、その時の動画が上がってます。
uMMORPGやuSurvivalは、個人的にはアセットストアにあるマルチプレイヤーゲームテンプレートで一番実用的なものなんじゃないかと思ってます。
unityで100人以上が接続できるアセットってvis2kさんのもの以外では見つかりません。100人繋がるならuSurvivalをちょっと弄ればバトロワが作れそうですよね。
とはいえ、これらのアセットを実際のゲームで使われた例はあるのか?というと、一応こちらのページにuMMORPGのショーケースがあります。
あんまり聞いたことないタイトルばかりですね…まあ、実はもっと有名なタイトルでも使われてたとしても、ゲーム開発者が「テンプレート使ってゲーム作りました。」なんてあんまり自分から言わないってだけかもしれません。
Mirrorはゲームテンプレート以外のアセットでもちょくちょく対応してるアセットがあります。
例えば、Easy Build Systemというゲームで建築機能が実装できるアセットは、UNETもMirrorもPUNも全部対応しています。さらに、uSurvival、uRPG、uMMORPGへの統合も用意されてます。(uSurvivalにもデフォルトで建築機能はありますが、それより高機能です)
https://assetstore.unity.com/packages/templates/systems/easy-build-system-v5-2-5-45394
他にも、Enviroという昼夜、天候制御アセットはUNETとMirrorをサポートしてます。
https://assetstore.unity.com/packages/tools/particles-effects/enviro-sky-and-weather-33963
さて、ではMLAPIは?というと、今のところMLAPIをサポートしているアセットやゲームテンプレートは存在しません。
まぁ…MLAPIは急にUnity公式になって、いきなり出てきた感があるので、もしかすると今後じわじわサポートするアセットが増えるのかもしれませんが、今のところは何もありません。
ですが、4月にUnityはMLAPIの「Boss Room」サンプルを発表しました。
https://blogs.unity3d.com/jp/2021/04/08/enter-the-boss-room-our-new-multiplayer-sample-game/
今まで散々「MLAPIにはロクなサンプルがねえ!なんか用意しろ!」と言われ続けたのに応えた形ですね。結構凝った作りです。MLAPIでゲームを作るならとりあえずこれを叩き台にすればいいのではないでしょうか。
さらに、「Boss Room」と同時期に、MLAPI用のPhotonトランスポートも用意されました。
トランスポートって何?というと、MirrorやMLAPIでは低レベル層のトランスポートレイヤーが何種類も用意されており、例えばudp通信を使うトランスポートやtcpを使うトランスポートなどを容易に差し替える事が出来ます。
PhotonCloudを利用して通信するトランスポートが用意されたという事は、MLAPIでもPUNと同様に無料で簡単にインターネット越しのマルチプレイを試すことができるという事です。
MirrorやMLAPIは、LAN内で簡単に接続できるのが便利でしたが、ネット越しのマルチプレイをしたいと思ったら、今までは素朴なP2Pで繋ぐか、専用サーバを用意するかで手軽ではありませんでした。Photonトランスポートはそこを補ってくれます。
ちなみにPUNの方はネット越しのマルチプレイは簡単にできるものの、逆にLAN内で接続したくても絶対Photonのリレーサーバを経由しないといけないので、インターネットに繋げない環境だとマルチできないという弱点がありました。
という事は、MLAPIはPhotonトランスポートが用意された分だけ、Mirrorより有利じゃないの?と思うかもしれませんが、一応、MirrorにもNobleConnectという便利なものがあります。
NobleConnectの話
NobleConnectってなんじゃ?というと、これです。
https://assetstore.unity.com/packages/tools/network/noble-connect-free-141599
つまり、UNETとMirrorにNATパンチスルーとリレーサーバの機能を追加してくれるソリューションです。これにより、MirrorでもPUNのように無料で簡単にネット越しのマルチプレイが試せます。
先ほども書きましたが、Mirrorでは、専用サーバを使わない場合、インターネット越しにマルチプレイするには、素のP2P接続しか使えません。つまり、ホストがポート開放したりする必要があるという事です。
NATパンチスルーによって、ポート開放みたいな面倒な事をしなくても、ネット越しに接続する事が出来ます。NATパンチスルーでも接続に失敗する場合は、リレーサーバを経由して通信する事で、確実な接続を保証してくれます。
PUNだと絶対にリレーサーバを経由してしまうので、通信が遠回りになってしまいますが、NobleConnectならなるべくP2Pで繋ぐので、遅延が小さくなるというメリットがあります。(ちなみにMirrorはサーバークライアント型なので、クライアント同士は直接接続しませんが、PUNはP2Pネットワーク型なのでクライアントから他のクライアントに直接RPCが打てたりします)
NobleConnectは無料で使用する事ができ、8人まで同時接続できますので、開発中に簡単にマルチプレイを試せます。
気を付けないといけないのは、無料版のNobleConnectにはマッチメイク機能が付いてません。ポート開放は不要なものの、ゲストはホストのIPを直接打ち込んで接続する必要があります。
PUNのように自動でマッチメイクして繋いでほしい時は、15ドルで別売りされてるMatch Upアセットが必要になります。
https://assetstore.unity.com/packages/tools/network/match-up-104411
ちなみに、88ドルで売っているNobleConnect有料版を買うと、Match Upアセットも付属しています。そして、100人まで同接できるようになります。(5年間)
https://assetstore.unity.com/packages/tools/network/noble-connect-140535
もし、同接人数が100人以上必要な場合は、NobleConnectの公式サイトから月額プランを契約する事になります。大体、価格の相場はPUNの半額くらいです。例えば1000人だと月160ドルです。何故PUNより安いか?というと、PUNが必ずリレーサーバを経由するのに対して、NobleConnectは大抵の場合はP2Pで接続されるので、たまにリレーサーバを経由する時以外はサーバに負荷がかからないからです。つまり、リレーサーバを経由しないでP2Pで繋いだ接続も同接制限にカウントされちゃうという事でもあります。
さて、こうしてみると、MLAPIはPhotonトランスポートによって、MirrorはNobleConnectによって、ネット越しにP2Pで繋ぐのが容易になりました。
という事は、専用サーバ構成やLAN内通信ができる分だけ、MLAPIもMirrorもPUNの上位互換と化していると言えるかもしれませんね。
ただし、Photonトランスポートは恐らくPUNの秒間メッセージ制限を引き継いでると思うので、厳密にはMirrorが優勢かもしれません。
MLAPIの行方
MLAPIの作者はTwoTenさんです。
TwoTenさんは現在20歳です。MLAPIを作り始めた時は16歳の高校生の頃だったとどこかで読んだ気がします。そんな若さでネットワークライブラリを開発してしまうって天才なんでしょうか。
TwoTenさんは2019年にMirrorをボコボコに批判したブログ記事を書いて、その後消してます。
MirrorはいまだにUNETの悪い所を引き継いでしまってるのが良くないそうです。MLAPIは完全にゼロベースで書かれてるそうです。
まあ、TwoTenさんのMirror叩きが妥当なのかはさておき、少なくともMirrorにはアセットがあり、コミュニティがあり、確かな採用事例があります。それに対してMLAPIはUnityから買収されるまでほとんど誰も使ってなかったようです。私から確認できる事実はそういう事です。
私はMLAPIがUnity公式のネットワークソリューションに採用された時、「これでUnityに安心して使えるネットワークソリューションができた!」と大喜びして記事まで書いてしまいましたが、その後にLukeさんのディスコ投稿やvis2kさんによるMirrorの歴史を知ってしまった今、まったく手放しでは喜べません。
Unityのネットワークの歴史を振り返ってみてください。
最初のNetworkViewはRaknetをラップしたもので、これはいい感じに動いていました。
それから新しくUNETを作るぞ!とUnityは張り切ってましたが、結局これは、中身はNetworkViewを魔改造したコードで、色んな人が代わる代わるコードを引き継いでいる内に、誰にも手が付けられない違法建築コードが爆誕して、まったくバグ修正もままならない状態になり、コアメンバーが全員泥船から逃げ出して、挙句の果てに放棄された。それが実情だったと判明しました。
お次にUnityはDOTSこそがUnityの未来だ!とか言い出して、DOTSベースのNetcodeをゼロから開発し始めました。UnityはDOTS Netcodeが2021年のQ2に製品品質でリリースされます!と主張していました。
https://blogs.unity3d.com/jp/2019/06/13/navigating-unitys-multiplayer-netcode-transition/
今現在、すでに2021年Q2に突入していますが、DOTS Netcodeがリリースされる気配は全くありません。それどころか、ECSはパッケージマネージャから非表示にされて、隠されてしまいました。
一部では、ECSは完全にポシャりつつあるという見方が有力であるとも言われています。
Unityは大嘘こいてたって事になりますね。まあ、開発が想定していたより順調に行かないのは仕方ない事ですが、Unityを信じて製品品質のネットコードを待ち侘びてた開発者の気持ちはどうなるのでしょうか。
Unityは最初のNetworkViewはRaknetのラッパーだし、UNETは弄りまわしてグチャグチャにしちゃった挙句放棄。DOTS Netcodeはあれほど宣伝してたのに結局うまく行かなくて盛大にポシャりつつある疑惑…
お気づきの通り、ハッキリ言ってUnityは自力でちゃんとネットワークライブラリを最後まで完成させたことはありません!
というか、Unityのやってる事全部メチャクチャだよ!これが上場企業の仕事なのか!?
DOTS Netcodeが約束の期限に全然間に合わない事に気付いたUnityは、慌ててTwoTenさんのMLAPIを買収してUnity公式のネットワークソリューションとしてでっち上げました。
そんな事したってまだ当分MLAPIは実験段階だし、結局2021年Q2に製品に使えるネットワークが提供されてない事実は変わらないんだよなあ…
UnityはどうしてMirrorじゃなくMLAPIを買収したのか?という話がありますが、もしかするとUnityの中でUNET放棄事件がよっぽどトラウマになっていて、まだUNETの負の遺産が残ってるMirrorより、ゼロベースで書き直されてるMLAPIの方が魅力的に見えたのかもしれません。
しかし、いくらTwoTenさんが天才だとは言え、所詮は高校生の趣味のプロジェクトだったMLAPIをいきなり公式ソリューションに祀り上げるとは…よっぽどUnityは切羽詰まってたんでしょうか。自力でネットワークライブラリ開発する能力ありませんって白状してるようなものでは…。
Unityは現在、買収したMLAPIをベースに色々と足りない機能を実装しまくっているようです。
この先、MLAPIはどんどん良くなっていくのでしょうか?以前は私もそのように楽観視してましたが、これまでのUnityの所業を振り返ると、これまでと同様に弄くり回して遊んでダメにしちゃってポイ…なんてことになる可能性も低くないのでは…。
Lukeさんのディスコ投稿の「MLAPIをおもちゃにして実験して遊ぶぞ~」的な発言も不安を煽られます。
かなりUnityの事を悪しざまに言ってしまいましたが、Unityはこれまでの失敗の反省を生かして、MLAPIの開発にRFCプロセスという手法を取り入れたりしてます。
https://github.com/Unity-Technologies/com.unity.multiplayer.rfcs
これは、民主的なプロセスを通して開発を進めていく仕組みです。
MLAPIに新機能が欲しい人は、まず仕様書を書いてコミットします。それからその仕様書について、Discord上であーだこーだ議論します。議論した結果、採用だとジャッジされたら初めてその仕様を実装するという流れです。
このような仕組みを取り入れる事で、UNETの時のような開発の完全崩壊を防ごうという意図だと思います。
結局MirrorとMLAPIどっちがいいの?
さて、色々とMirrorとMLAPIの事情を深堀りしてましたが、「で?結局どっちがいいの?」と言われると、どうなんでしょうね。
「エンジニアだったらくだらねーことウダウダ言ってるヒマあったら実際に負荷テストしてパフォーマンス比較とかしてみりゃいいじゃねえか!」と思う人もいるかもしれませんが、すいませんが正直そこまでやるのは気乗りしないんですよね…。
何故なら、私が今推してるのは、MirrorでもMLAPIでもなく、UE4だからです。
この際ハッキリ言っておきますが、私のような単にネットワークマルチのゲームをサクッと作りたいだけのユーザーが、こんな風にMirrorやらMLAPIやらのDiscordを深堀りしてお互いの事情を調べ上げて、そこまでして初めてどのネットワークライブラリを採用するのか安牌か、高度な政治的判断をようやく下せる…そんな事するハメになるゲームエンジンって、異常ですよ。
それもこれも、Unityがデタラメな事ばかりやってるから、無駄に話がややこしくなってるのです。Unityブログの内容が素直に信用できるなら、こんな裏の裏まで掘り下げて調査に時間を費やす必要は無かったのですから。
何でネットワークライブラリが群雄割拠してんだよ!結局、決定版のライブラリが存在しないからそうなっちゃうんですよね。
そんな風にずーっとネットワーク戦国時代でバベルの塔状態でユーザーに混乱を与え続けてるUnityに比べて、UE4はデフォルトのネットワークひとつで事足りてます!
デフォルトのネットワークが決定版だからです。
そもそも、EpicはUE4のネットワークを使ってフォトナを開発したわけですからね。当然、UE4のネットワークは堅牢で安定していて、高機能なのは当たり前です。
そのおかげで、非常に多くのUE4のゲームで採用されており、マーケットプレイスのアセットもかなり多くがネットワークに対応しており、大きなコミュニティも存在します。
Unityの情報やらなにやらバラッバラに散らばってるネットワーク機能とは大違いです。
多人数マルチが当たり前になっていくであろうこれからの時代、一体どのネットワークライブラリを採用すればいいんだ…なんて不毛な事に悩んでるヒマがあったら、ネットワークが貧弱なUnityから堅牢なUE4に乗り換えるべき…そんな風に思ってますね。
Unityはこの先永遠にネットワーク機能で混乱し続けてそうだよな…別にネットワークマルチを作らないなら全然いいんですが。
じゃあそもそも何でこんな記事を書いたんだよ!と言うと、個人開発はUE4に移行するでいいとしても、仕事での開発は、様々な事情が絡んで、そう簡単にはUnityからUE4なんて移行できなかったりするので、やっぱりしばらくはUnityでのネットワーク機能をどうするかも悩む必要がありそうです。
本気で製品としてネットワークマルチのゲームを開発するなら、混乱しているUnityのネットワーク使って後でトラブルの山を抱えるより、堅牢なネットワークのUE4に移行しちゃった方が結果的に安くつくんじゃないかと思うけどな…。
そういえば、「Unityのネットワークはひどい!バトロワとか作れない!」とか文句を言うと、Unityは「でもFall GuysはUnityでネットワークマルチ60人対戦を実現してるもんね!」って反論してくるのが常態化してましたよね。
Unityは相当Fall Guysの事を誇りに思ってたらしく、ブログやPVで紹介しまくって自慢しまくってました。
そんでそのFall Guysを開発したMediatonicはどうなったかと言うと、UE4のEpicに買収されちゃったというオチが付くわけですが。
まあ、最近のUnityのネットワーク事情を象徴してるような出来事だと思います。
オマケ:Epic Online Servicesがアツい
先ほど、Mirrorでネット越しのマルチプレイを実現するのに、NobleConnectが利用できるという話をしました。しかし、NobleConnectは同接数を増やそうとすると、高額な料金プランを契約する必要があります。
私が今注目しているのは、Epic Online Services(EOS)です。
実は、EOSではNobleConnectが提供してるようなNATパンチスルーやリレーサーバが完全無料で提供されています!
タダは嬉しいですよね。
以前の記事で、SteamP2Pも無料のリレーサーバが使えるという話を書きましたが、SteamP2Pの弱点は、Steamじゃないと動作しない事です。つまり、スマホアプリでは使えないし、Steam以外のストアからのアプリでは使えません。
EOSが凄いのは、そのような縛りも一切なく、どんなストアでも、マルチプラットフォームで動作するとの事です。
EOSはEpicのサービスですが、UE4だけじゃなくて、Unityからも使用する事が可能です。
実際、Mirror向けのEOSトランスポートが用意されてます。
https://github.com/FakeByte/EpicOnlineTransport
私も機会があればぜひ試してみたいと思ってます。