前回の記事の続きになります。
前回の記事はコチラ↓
前回の記事では、メタバースの同時参加人数を左右する様々な要素について考察を行いました。
記事の最後では、「そもそも論として同時参加人数って、多けりゃ多いほどいいってもんなのか？」という疑問提起を行いました。
現実世界では、他人がウジャウジャいても邪魔なだけで嬉しくありませんが、プレイヤー同士で交易（アイテムの交換など）が行えるとしたら、他のプレイヤーの存在は邪魔なだけでなく、利益の可能性となりますし、さらに積極的にコミュニケーションを取る動機付けにもなりますから、そういう場合は同時参加人数が多いほどいいかもしれないという話をしました。
さらにNFTだかブロックチェーンなどでゲーム内経済も持ち込めばもっと良いかもしれないという話もしましたが、この点については後から考えるとそうでもないかもと思いました。
というのも、ゲームに経済を持ち込むと、それはゲームでは無くなってしまうからです。
ゲームスタディーズの本では、ゲームの定義の一つとして”取り決め可能な帰結”が挙げられています。どういう意味か？というと、ゲームは勝ち負け自体で損したりトクしたりするわけじゃないという事です。
例えば将棋やサッカーで、勝ったからどうしたとか負けたからどうしたという事はありません。まあ買ったら気分がいいし、負けたら悔しいという事はあるでしょうけど。
ただし、金を賭けてゲームをする事は可能ですし（ちなみに賭博罪です）、プロのサッカー選手は給料のためにサッカーをプレイしたりしますが、そういうのはゲームの外での取り決めの話で、ゲーム自体で損得が発生するわけではありません。
それに対して選挙とか株取引は、勝ち負けが直ちに現実の損得に繋がりますので、こういうのはゲームと見なされません。
じゃあ経済を持ち込んだゲームは？というと、例えばデイリークエストをこなすと100円もらえるゲームは、明らかにゲームの結果が現実の損得に繋がりますので、これはゲームではない、という事が分かります。
ちょっと調べた感じでは、ブロックチェーンやNFTを使ったPlay-to-Earn（遊んで稼ぐ）ゲームはあまりうまく行ってないケースが多いようです。
まあ、これについては別途ブログ記事を書きたいですが、とにかく前回の記事での「ゲーム内経済があるといいかも」という話は一旦撤回させて頂きます。ゲーム内経済についてはもっとよく調べて慎重に検討する必要がありそうです。
作るメタバースにゲーム性がある場合の話
前回の記事では、作ろうとしているメタバースの同時参加人数について検討しただけで終わりましたが、今回はゲーム性の有無で設計とかに大きな違いが出てくるよという話をします。
メタバースと言ってももはや何でもアリな感じになってきていて、実際にどういうモノを指すのかよく分からなくなってるのが現状ですが、例えばメタバースを取り上げてるテレビ番組で扱われてるのはVRChatやClusterが多いようです。
他にも、フォートナイトのEpicや、原神のMiHoYoもメタバースを目指していくと発表しています。
VRChatとフォートナイトと原神、これらに共通するのは、画面上に自分のアバター（プレイヤーキャラ）が表示されて、３D空間を自由に歩き回れる事と、マルチプレイで複数人で参加できる事、くらいでしょうか。
しかし、VRChatはVRSNSですし、フォトナはバトロワゲームですし、原神はオープンワールドMOソシャゲであって、これらは中身はまるっきり別物です。
設計レベルで全く話が違ってくるので、作ろうとしているメタバースがゲームなのか、ゲームじゃ無いのかは、一番最初によく考えて決めてください。後から変更しようとしてもこれらはそもそも別物なのですから、不可能です。
例えば、VRChatが今からフォトナや原神みたいになろうとしたら、イチから作り直すしかないでしょう。
どれも３D空間でマルチプレイするってのは同じなのに、一体なにがそんなに違うのか？
全ての問題の根源は、チーターです。
チーターというのは、ゲームで不正行為（チート、ハック）を行う人達です。
ゲームが人気になると、必ずチーターが湧いてきます。ゲーム内でチートが横行するようになると、そんなイカサマで勝つヤツだらけのゲームでマトモに遊ぼうという人はいなくなりますから、ゲームは崩壊します。
つまり、作ろうとしているメタバースがゲームである場合、根本的なチート対策を考えないといけないという話になります。ゲームの設計レベルでチートを防ぐ作りにしなくてはいけません。
チートが問題になるケースとそうでもないケース
ちなみに必ずしも全てのゲームでチートが問題になるわけではありません。
ネットワークに接続しない、1人用の買い切りゲームとかではチートでズルしようが、それは本人だけの問題なので、あんまり問題になりません。
一人でトランプのソリティアを遊んでる人がそこでズルをしようがしまいが本人の勝手です。
前のブログでも書きましたが、例えばSkyrimという一人で遊ぶRPGではMod文化がかなり盛んです。
Modというのは要するにゲームの改造ですが、ベセスダも黙認しています。
チートが問題になるかどうかは、他人（ひいてはゲーム会社）に迷惑をかけるかどうかが大きなポイントのようです。（Skyrimは買い切りゲームですから、ユーザーが金払ってゲームを買った上で改造しようがどうしようがベセスダは困りません。むしろ私のようにエロModの存在につられてゲーム買っちゃう人とかも出てきますから、ベセスダはModが盛り上がるほど売り上げ増えてトクします）
さらに、そのゲームの世界がグローバルな繋がりか、ローカルな内輪の繋がりかどうかも関係するようです。
例えば、マイクラにはマルチプレイがありますが、マイクラもMod文化が盛んです。
マイクラはマルチプレイと言っても誰かが自前でサーバを建てる必要上があり、そのサーバにModを入れたとしても、遊ぶのは仲間内のローカルな繋がりですので、誰にも迷惑は掛かりません。
マイクラはPvPは可能っちゃ可能ですが、対戦よりも普通に一緒に協力して遊ぶCo-opがメインという事もあります。
ちなみにマイクラ公式レンタルサーバのRealmsではModは入れられません。
Rustもサバイバルゲームでマルチという意味ではマイクラに似てますが、RustではサーバがPvEとPvPの２種類があります。
PvPサーバには当然プレイヤー同士で戦いたい血気盛んな人たちが集まります。
また、Rustでは公式で大人数参加可能なサーバが豊富に用意されています。つまり、マイクラに比べると見知らぬ人同士がグローバルに繋がれるゲームとなります。
こういうゲームはチーターにとって格好の餌食です。
こちらの記事のよると、Rustは素晴らしいゲームだったけどチーターによって命運が断たれたとまで言われてます↓
ここまでの流れを見ていると、ひとり用ゲームやCo-opマルチのゲーム、内輪マルチのゲームでは、チートによる被害は大した事ない事が分かります。チートしても大して他人に迷惑をかけませんし、そういうゲームではチーター側も大して熱意を燃やしてチートしたりしません。
しかし、グローバルなマルチとか、競争性のあるゲーム、PvPとかの要素が出てくると、チートによるダメージは最大化されますし、チーターも凄い熱意でチートしてきます。
RustはCo-opもPvPもできるよというゲームでしたが、これがFPSとかバトロワになると、もっぱら競争とかPvPだけするゲームとなっていきます。
当然、このようなゲームはチーターの脅威がもっともヤバくなります。
ですからシューターゲームの歴史と言うのは常にチート対策の歴史でもありました。
昔はマイクラのように野良でサーバーを立てて、内輪とかでマルチする形でしたから、クライアントからのチート攻撃ができないように、マルチプレイゲームの全てのゲームロジックの処理はサーバ（またはホスト）側で行うように進化していきました。
しかし、それでも結局サーバー側はチートし放題ですし、FPSやバトロワで本当に公平な競争が重視され始めると、野良サーバじゃなくて、公式で全ての専用サーバを管理するという究極の仕組みが導入されました。
この方法なら、まあ原理的には一応絶対に誰にもチートはできません。
「な～んだ、じゃあそんなに鉄板な方法があるんだったら自作メタバースも全部その方法で作ればいいじゃん！」と思うかもしれませんが、まあ話はそう簡単ではありません。
公式で全てのプレイヤーを賄える専用サーバを用意するというのは、鬼みたいにコストがかかります。
専用サーバというのはサーバ上でゲームそのものを動かすわけですから。
Fall Guysはゲームの購入時に2千円くらい払ってもらってるからこそ専用サーバをホストするコストが賄えてますし、フォトナはスキンなどの販売で儲かってるからFree-to-Play（基本プレイ無料）でも何とかなってます。
また、公式で専用サーバをホスティングするにはGameLiftやPlayfabゲームサーバ、Multiplayerなどのサービスを使う形になったりしますが、こういうのはバトロワのように一度のゲームセッションが割と短めのゲームに向いていて、マイクラのようなまったり遊ぶゲームには向いてません。
MMOの強固なチート対策
FPSやバトロワの専用サーバというのは、実際にはUnityとかUE4でビルドされた、サーバー向けに最適化されたゲームそのものです。
それに対して、ちゃんとしたMMOではいわゆる普通のWeb系サーバで全てのロジックが制御されています。
ちゃんとしたMMOゲームは、一切の処理をサーバ上で行っています。クライアントアプリは、ただサーバから送られてくる情報を元に、画面をレンダリングしてるだけで、ゲームロジックは一切クライアント側では実行していません。
クライアント側でゲームロジックを実行する＝チートされるという事を意味するからです。
まあ、プレイヤーのコマンド入力だけはクライアントからサーバへ送信されます。
ですからチーターにできるチートは、せいぜい画像認識で自動操作するbotを作るくらいしかできないでしょう。
さて、全てのロジックをサーバで実行するという事は、例えばマップの衝突判定もサーバ側で行う必要があります。サーバは全てのコリジョンデータを保持して、プレイヤーの方向キー入力に対して結果を返す必要があります。（ただ、本当にチートされようがどうでもいいようなゲーム進行と関係ない部屋の中の机のコリジョンとかはクライアント側で判定しちゃったりするようです。）
まあシンプルなコリジョン判定はWebサーバで実行できるでしょうが、物理ロジックは不可能です。
ですから、MMOには物理が存在しません。
まあオープンソースの物理エンジンとかもありますから、メッチャ頑張れば物理ロジックをWebサーバで制御する事もできるっちゃできるでしょうが、結局CPUの負荷は増大しますから、だったらゲームエンジンからビルドした専用サーバ使った方が手っ取り早いという話になります。
で、何なのか？というと、MMOは全てのロジックをサーバ側で制御する事でチートを完全に防げますが、MMOの考え方ではアクション性のある３Dゲームは作れないという話です。何故ならアクションゲームには物理ロジックが必須と言っていいですし、物理ロジックはサーバ側で制御できないからです。
究極のチート耐性を持つクラウドゲーミング
ここまでの話で、公式で専用サーバをホストしているバトロワや、MMOはサーバ側でロジックを制御しているので根本的にチートが防げる。という話をしました。
しかし、そうは言ってもクライアント側だけでできてしまうウォールハック（壁の向こうが見えるようにする）のチートとかもあるっちゃあります。
そういうチートも完全に防げる技術として、クラウドゲーミングがあると思います。
クラウドゲーミングではレンダリング処理さえクライアント側では無くサーバサイドで処理されて、クライアントにはレンダリングされた映像だけが送信されるので、絶対にチートしようがありません。
まあそうは言っても画像認識ベースのオートエイムのチートとか、プレイヤーからの入力自体をハックする（Bot）タイプのチートは防げませんが。
あらゆるゲームでオートエイムを可能にする検出困難なチートツールが開発されてしまう、なんと家庭用ゲーム機にも対応
色んなゲームやメタバースのチート耐性
ここまでで、ゲームのチート問題とその対策の概要について話してきました。
では次に、実際のゲームやメタバースでのチート耐性がどうなってるのかという話をしていきます。
①Rust
Rustというか、まずUnityの話をしたいんですが、前回の記事でRustやUnityの初期のネットワーク機能はP2Pメッシュ型ネットワークだったという話をしました。
P2Pメッシュ型では全てのクライアントが他の全てのクライアントと直接通信し合います。
これはつまり、ゲームロジックがクライアント側で実行されるという意味です。
今までの話から分かる通り、クライアント側でロジックが実行されるというのはチート防止の観点から言うと、一番ダメな奴です。
ですからUnityの初期ネットワーク機能ではチートし放題だったために、新しく作られたUNETではクライアントサーバ型ネットワークに移行して、セキュリティが強化されました。
しかし、RustはRaknetが使われており、RaknetのネットワークはP2Pメッシュ型なので、チート耐性が致命的に欠如していて、チートの温床になってしまってます。
そもそもP2Pメッシュ型では原理的にチートを防ぐことができないという事です。
②VRChat
VRChatではPhotonServerが使われています。
まず、PhotonCloudは、サーバー側は単なるリレーサーバで、一切ゲームロジックの制御は行いません。単に通信を中継しているだけです。PhotonServerは一応サーバ側ロジックを書くことができますが、そうは言っても基本的にはリレーサーバに毛が生えたようなものである事には違いないでしょう。
さらに、PUN（Photon Unity Network）はUnityのNetworkViewを参考に設計されているため、PUNもP2Pメッシュ型のネットワークとなってます。
つまり、PUNで普通にゲームを作ると、クライアント同士が通信して、チートし放題になりがちです。
まあエンジニアが相当注意して実装すれば、少なくともホストがゲーム全体の制御を実行するような形で実装する事も可能ですが、Netcode for GameObjectやMirrorのように、何も考えなくてもサーバクライアント型ネットワークを強制できる最近のライブラリに比べるとセキュリティ面で劣ります。
しかし、そもそも論としてVRChatにはゲーム性はありません。基本的には集まってお喋りするだけのアプリです。
だからチーターなんて湧かないだろうし、チート耐性なんて必要無いんじゃないでしょうか？
最近ではVRChatにはUDONというノードプログラミングでワールドにロジックを実装できるようになったので、まあミニゲームみたいなので遊ぶことも可能ですが、そういうゲームでチートなんかするヤツいるのか？
しかしVRChatでチートする人達はいます。
ゲーム性も勝ち負けもへったくれもないVRChatで何が楽しくてチートするのか分かりませんが、まあ荒らし行為みたいなものでしょう。
チートコマンドを見ると、任意のプレイヤーを強制的にテレポートするチートとかが出来てしまっていて、深刻です。
このようなチートが出来てしまっているという事は、VRChatではゲームロジックがサーバ側で制御されていない事を意味しており、さらにホスト（Master Client）に処理を集約する実装さえされてない事が予想されます。
まあ、普通にPUNを使ってメタバースを実装してしまうとこのような感じになってしまいます。
そういえば、VRChatではアバターのリッピング（盗難）も深刻な問題です。
とは言え、他のプレイヤーの画面上に自分のアバターを表示するには当然自分のアバター3Dモデルのデータを相手のPCに一旦送信せざるを得ないので、原理上から言ってアバター盗難を防ぐのは現代のテクノロジーでは難しいようです。
私もこの問題について考えた事がありましたが、結論としてはVRChatが全てクラウドゲーミングだったら他人のPCに自分のアバターデータを送信せずに済みますので盗難は防げると思いました。
③Cluster
Clusterのネットワークマルチプレイは、MQTTサーバで実現しています。
https://resources.awscloud.com/vidyard-all-players/cus-64-aws-summit-online-2020-cluster-inc
MQTTってのはWebSocketみたいなヤツです。
Unityでのマルチプレイの話とかをブログで書いた時に、「サーバサイドは自分で書くべき」みたいな反応がありました。
それはこういうWebSocketサーバみたいなモノをイメージしているんでしょうが、それだとクライアントでコリジョンや物理などのロジックを制御して、サーバ側は各プレイヤーの座標を受け取って他のプレイヤーに送信して同期する形になってしまうでしょう。
ですがサーバサイドでロジックを制御しないと、クライアントでロジック実行するほどチートし放題になるという観点が抜けてるんじゃないかと思ったりします。
ClusterがマルチプレイにMQTTサーバを使っているという事は、物理やコリジョン、アバター移動などのゲームロジックをクライアント側で制御してしまっている事を意味します。そして、クライアントから自己申告で送信されてくる座標情報などを素直に信じてそれを同期する作りになっているハズです。
しかし、クライアントから送信されてくる情報が改竄されていた場合はどうしますか？
ClusterはVRChatと同じでゲームというよりVRSNSみたいなアプリなので、チーターなんて湧かないだろうからチート耐性なんて要らんでしょう？という意見もあるでしょうが、しかし実際VRChatではチーターが湧いてます。
とは言えClusterでチーターが湧いたという話はあまり聞きません。
何故かと言うと二つの可能性があって、一つ目は、Clusterのユーザーはもっぱら日本国内のユーザーが多いから、チーターは外国人が多いからClusterにはまだチーターが湧いてないだけという説。
もう一つの可能性は、Clusterには私が知らない未知のチート対策がしっかり組まれている説です。
もしClusterがチートに対して無策だった場合、例えばClusterでは音楽ライブ配信とかも行われますが、その際に観客はステージには入れないようになってますが、座標チートでステージに侵入するようなチーターが出現したらかなりマズい事になりそうですから、何らかの対策が必要になるでしょう。
④Diarkis
前回の記事で取り上げた、大規模な同時参加人数マルチプレイを実現するフレームワークであるDiarkisについて。
Diarkisは大規模通信を実現してくれるものではありますが、これもPhotonCloudとかMQTTと同様に、サーバサイドでゲームロジックは制御してくれません。
基本的には大量のプレイヤーの通信同期だけを処理してくれるものです。
例えば、こちらにUE4でのDiarkis組み込みのサンプルコードがあります↓
Unreal Engine 4でのFieldモジュールの利用方法
これを見ると、やっぱりクライアントが自分の座標をDiarkisサーバに自己申告している事が分かります。つまり、キャラの移動やコリジョン、物理はクライアント側で制御されます。
という事は、やはりチートによって座標の改竄とかが容易にできてしまうという事です。
ですから、ゲーム性のないNEOKETのようなイベント開催にDiarkisを使うのは問題無いでしょうが、MMOスケールの通信同期ができるからってこれで実際にMMOゲームを作ろうとするとチート耐性的にマズい事になるのではないかと予想されます。
という事は、Diarkisを使って実装されたプロジェクトセカイのライブもチート耐性が無いだろうと推測されます。
ちなみにDiarkis公式ブログでメタバースについての記事があります。
⑤Fall Guys
Fall Guysではゲームエンジン（Unity）でビルドした専用サーバが使われてます。
ちなみに専用サーバはMultiplayでホスティングされてるらしいです。
Fall Guysが偉大だったのは、60人の大規模マルチプレイでみんなで物理ロジックを活かしたギミックを使ってワチャワチャ遊ぶ楽しさを提示した事です。
「物理でワチャワチャマルチプレイで遊んだらおもろいよね」概念はすでにヒューマンフォールフラットで提示されていました。
その楽しさを大規模バトロワに拡張したのがFall Guysというわけです。
よく考えてみると、これは理に適っています。
というのも、公式ホストの専用サーバのメリットは、①チートされない事 ②リッスンサーバより大規模な人数でマルチプレイできる事 ③コリジョンや物理ロジックが使える事 の３つです。
つまり、どうせ専用サーバを使うなら、①チートされないから競技性の高いバトロワでもOK ②大規模マルチでもOK ③思う存分物理で遊べる そういうゲームがベストだよねと言う話で、つまりこれってFall Guysそのものだからです。
さて、そんなFall Guysですが不可解な点もあります。
Fall Guysは公式専用サーバしかないから原理的にチートは不可能だとこれまで散々言ってきましたが、何故かFall Guysでは飛行（加速？）チートが横行しちゃってます。↓
なんで？
キャラの移動をサーバ権限で処理していたらこんな移動チートは起きえないハズですが…。
Mediatonicはロジックの実装方法をなんか間違えちゃってるんじゃないかな？と思います。
ちゃんと全てのロジックをサーバ権限で正しく実装していればこんなチートは起きなかったはずです。
まあ、想像できる理由があるとしたら、キャラの移動をサーバ側で処理すると、サーバで入力を受け付けてからキャラを動かしたのをクライアント側に反映させるという流れになりますから、キー入力から実際にキャラが動き始めるまで目に見えて遅延する事になります。（これについてもキャラ移動について”クライアント予測”という仕組みを実装すれば、キー入力に対してキャラが即時動き始めるので、見た目上の遅延は無くすことが可能です。）
Fall Guysでは割とシビアな入力タイミングが要求されるアクションゲームでしょうから、サーバ権限移動での遅延によるプレイ感の低下を嫌ってクライアントサイドで移動ロジックを実行してしまっているという可能性はあるっちゃあります。（クライアント予測があっても、見た目はラグゼロにできるものの、クライアントからの入力がサーバに到達するまでの反映の遅れは打ち消せませんので、シビアなアクションでは問題になる可能性があります。）
ちなみに上のチーターが暴れてる動画ですが、Fall Guysでは全員で競争する競技以外にもチーム戦の競技とかもあって、その時はチーターも飛行できたってほぼ意味無いですから真面目に普通にプレイせざるを得なくなってるのが何かおもろいです。（これもチート対策の一つなのかもしれない）
ちなみにFall Guysでのチートについて詳しく説明してくれてる記事があります↓
チート行為は検出され次第BANされるそうですが、そもそもどうしてクライアント側でこんなに何でもかんでもパラメータを弄れてしまうのか不思議過ぎて困惑しています。
これはもうクライアント側でロジックを実行しているのは間違いないでしょう。それだとせっかく専用サーバをホスティングしてる意味があまり無い気がします。
一体どうしてこんな事になってしまってるのか、詳しい話を聞きたいところです。
⑥フォートナイト
フォートナイトもFall Guysのように、ゲームエンジン（UE4）でビルドした専用サーバが使われてます。
ところで、フォートナイトを作ったのはEpicGamesです。
EpicはUnrealEngineの開発も行ってます。
というか、フォートナイトはUE4で開発されました。
そして、Epicの社長のティム・スウィーニーはゲームエンジンガチ勢のエンジニアで、最初のUnrealEngineのコードの9割はティム氏が書いたそうです。
何が言いたいかと言うと、そんなティム氏が率いるEpicが作ったフォートナイトは、当然ながら世界最強レベルの技術力でチート防御が組み込まれているという事です。
先ほどリンクを貼った「Rustはチートに弱すぎて終わってる」みたいな話が書かれた記事の中で、フォートナイトについては「素晴らしいアンチチート技術でチーターが駆逐されている！」と褒められています。
そもそもUE4にはデフォルトで強固なチート耐性が備わっています。
例えばキャラクターの移動機能についてです。↓
普通にUE4でゲームを作ってる分には意識してないかもしれませんが、UE4のCharacterMovementコンポーネントには非常に高度なクライアント予測機能が実装されてます。
つまり、デフォルトのサードパーソンテンプレートとかの時点ですでにFall Guysでやられてたようなキャラクターの飛行チートとかは原理的に不可能になってます。
クライアントの不正な移動はサーバが許しません。
しかし、フォートナイトが高い技術力で原理的にチート不可能にしている、と言っても、まだクライアント側だけでできてしまうチートもあります。
ESP（敵の位置を把握）、ウォールハック（壁の向こうに隠れている敵が透けて見える）、エイムボット（自動で敵をエイムしてくれる）などです。
フォトナにはEasy Anti CheatとBattle Eyeの両方のアンチチートが組み込まれており、そのようなチートもビシバシ検出してBANしまくってはいるものの、フォトナはRustやFall Guysと違って無料でプレイできてしまうゲームなので、チーターはBANされたら別のアカウントを作ればいいだけなので痛くもかゆくもありません。
業を煮やしたEpicは、BAN対象のユーザーのPCのLANハードウェアの情報（MACアドレスかな？）を検出して、そのPC自体をBANしちゃうという強硬策も取ってるみたいです。
⑦原神
原神はパッと見は、まるでオープンワールドMMOみたいなゲームに見えますが、しかしよくよく見ると、MMOではありません。
まず、MMOと違って同時参加人数は最大4人と少なめです。
何よりも、MMOはサーバサイドで全てのゲームロジックを制御していますが、原神はクライアント側でゲームロジックを制御してしまっています。
何故そう言い切れるか？というと、原神ではかなりメチャクチャなチートが横行しています↓
スピードハックやテレポート、無限スタミナ、エイムボット、任意ダメージと言った感じで、割と何でもアリです。
MMOならサーバサイドでロジック制御しているのでこのようなチートは起きえません。
原神はクライアント側のロジックでインゲームが制御されている事になります。
クライアント側ロジックだからこそ、MMOでは不可能な物理ロジックを活かした３Dアクション性を持てています。
じゃあ原神はSkyrimみたいに全てが改造し放題なのか？というと、そんな事はありません。
原神のインベントリ（アイテム）やガチャ（キャラクター）などは、いわゆるソシャゲと同様にサーバサイドのロジックでしっかりと保護されています。
つまり、原神は上辺だけを見ると凄い画期的なゲームに見えますが（というかスマホでオープンワールド３Dアクションゲームって時点で実際画期的ですが）、中身は案外ソシャゲに近いです。
ネイティブソシャゲは一般的にアウトゲーム部分はサーバ側のロジックでガチガチに守られてますが、インゲームはクライアント側ロジックで実行されてしまっていてチート耐性が薄いです。
ソシャゲはアウトゲームに包み込まれるような形でインゲームが存在する感じですが、原神は逆にインゲームの中にオプション画面的な感じでアウトゲームが存在します。
原神のようなソシャゲ系のチート対策は、上で書いたようなFPSやバトロワとはまた違った考え方が必要になります。
それについては話が長くなるので次回の記事で書きたいと思います。
おわり
今回の記事では、メタバースと言ってもVRChatとフォトナと原神ではまるっきり設計から別物だという話をしました。
設計の違いの大きなポイントは、どれくらいチート行為に対策する必要があるのか？という点でした。
まず、究極のチート耐性を持っているのは、クラウドゲーミングです。
その次にチート耐性が高いのは、全てのゲームロジックをサーバサイドで制御するMMOです。
そして、フォトナのように、ゲームエンジンからビルドした専用サーバを使う事でもサーバサイドでゲームロジック制御を行うことができますし、専用サーバならWebサーバだと不可能な物理ロジックも簡単に扱えます。
Fall Guysは専用サーバを使ってる割に、クライアント側で色々パラメータを弄れてしまっていて、実装が上手く行ってないようです。
Photonのリレーサーバを使っているVRChatは、サーバサイドでロジックがほとんど制御できないため、かなりチート耐性が貧弱です。他人をテレポートで飛ばすようなヤバいチートが出回ってます。
どういう風に実装したら他人の座標を改竄できるような作りになるんだろう…？
ClusterはMQTTサーバを使っていて、やはりサーバ側でロジック制御は行っていないと思われるため、チート耐性は弱いと思われます。自分の座標を改竄すると飛行チートやテレポートチートが出来てしまうのではないでしょうか。
原神はゲームロジックをクライアント側で制御してしまっているため、チートし放題な状態です。
しかし、原神は中身はソシャゲに近く、ソシャゲ的な考え方でチートに対してのダメージコントロールを行っています。これについては詳しくは次回の記事で書きたいと思います。
このような流れを見ると、要するにゲーム性が高いメタバースほどガチガチにチート対策をしている感じですね。
たしかに、ゲーム性に比例してチート攻撃は激しくなる傾向があります。
内輪だけのマルチプレイとか、Co-opマルチのゲームはあんまりチーターがいないですし、チートされたとしても大きな問題になりません。
PvPとかバトロワみたいな、グローバルなマルチで、競争性が激しく、プレイヤー同士が戦うようなゲームはメチャクチャチート攻撃に晒されます。
じゃあゲーム性が無ければいいのか？というと、ゲーム性が無いはずのVRChatはかなりチート攻撃に晒されています。結果的に、VRChatのパブリックワールドは治安が悪いから入らない方がいい、という事態にまでなっています。
要するに、ゲーム性の有無にかかわらず、世界的に人気なメタバースにはチーターが湧くらしいという事が言えるでしょう。
という事は、ゲーム性があろうが無かろうが、メタバースを作って世界で覇権を取るつもりの人は、チートをどうするかについて設計段階からよく検討しておくに越した事はありません。
ただし、チート耐性があればすべて解決するのか？というと、そうでもない点に注意してください。
チートができなかろうが普通に荒らしは湧いてくるでしょう。荒らしはどうやって対策するか？というのはチートとはまた別の問題です。
それから、専用サーバが一番チート耐性が高いとは言え、フォトナのように専用サーバを大量にホスティングするとサーバ費用が大幅にかさんでしまうトレードオフもあります。
また、クライアント側でゲームロジックを処理するほど原理的にチートされやすくなる、という話をしましたが、”原理的に”というのは”まったくチート対策できない”という意味ではありません。
たとえば、あるクエストが10秒以内にクリアされてたりしたら、普通にプレイしてたら絶対にありえないからチートだと判断してBANする…みたいな対症療法的な対策は工夫次第で色々とできるっちゃできます。
実際、Fall Guysや原神ではそんな感じで不正行為ユーザーを検出してBANしまくっています。
『Fall Guys』にはチーターだけが戦いに参加する「チーター島」があった。開発チームは島を閉鎖するまでのチーターとの戦いの記録を公開
しかし、こういうのはイタチゴッコになりますから、なるべくなら原理的にチート不可能な設計にした方がBAN対応に割くリソースが減らせるため、後々ラクでしょう。
また、設計で原理的にチートできなくする以外の方法として、Easy Anti CheatやBattleEyeといった、ユーザーのPCにインストールさせるアンチチートソフトを導入するという手もあります。
RustもArkもフォトナもApexもアンチチートソフトをガッツリ導入しています。（まあそれでもアンチチートの監視をかいくぐってチートしてる人達がいるわけですが、無いよりはマシ）
というか、Easy Anti Cheatは最近Epicが無料化してくれましたし、とりあえずこれは何も考えずに導入してしまっていいんじゃないでしょうか。
というわけで、メタバース作って一旗挙げるぞ！と思ってる人は、この辺の話を踏まえて設計を考えてみてください。
この辺の話を無視して無策でPUNを使ってバトロワゲームとか作ると後々大変な目に遭うでしょう。
チート問題についてはこんな感じですが、原神をはじめとしたソシャゲ的なゲームにはまたちょっと違った文脈がありますので、それについては別の記事で書きたいと思います。
もしメタバースに課金とかガチャとかソシャゲ的なマネタイズモデルを入れようと思ってるなら、ソシャゲ的な発想が参考になると思います。