🐰

ブラウザベースのメタバースを作る 補足

に公開

この記事の趣旨

以前、ブラウザベースのメタバースを作るテーマで5回の記事を公開しましたが、おそらく大変わかりにくいと思うのでまとめ的なものを書いていきます。

全体の概要

既存の商用サービスを使わずに、ブラウザベースのメタバースを実際に作る流れを環境構築から通しで書いた記事です。
メタバースと言ってますが、具体的に次のものです。

  1. ウェブページを1つのワールドとする。
    ワールドのデザインはウェブページでjsで記述する。
    複数のワールドを作る場合は複数のウェブページを作る。
  2. アバターを操作して他のユーザーと交流できる。
    具体的にはチャットと、所作。
  3. ユーザーはアバターを設定することが出来、他のユーザーの画面にも反映される。
    具体的にはVRMファイルを使う。

ネットゲームの町とハウジング部分というのが実体に近いです。

動画
https://velserm.com/movies/localverse/localverse-001.mp4

最短で動かしたい場合

1.1回目の記事の環境構築手順に沿って環境を構築する。
https://zenn.dev/velserm/articles/localverse_0001
2.gitから以下のファイルを持ってきて配置する。
バックエンド側 (配置ディレクトリ直下)
https://github.com/frakiaongithub/localverse/blob/main/httpd.js
https://github.com/frakiaongithub/localverse/blob/main/wss_signaling.js
フロントエンド側(配置ディレクトリ/web)
https://github.com/frakiaongithub/localverse/blob/main/web/p2p_syncvrm_phys.html
https://github.com/frakiaongithub/localverse/blob/main/web/loadMixamoAnimation.js
https://github.com/frakiaongithub/localverse/blob/main/web/mixamoVRMRigMap.js
3.ログイン設定ファイルを配置する。
配置先
config/users.csv
形式
列見出しなしcsv
id,パスワード,名前
同期テストするので2名分登録

  1. バックエンド起動
    環境構築したディレクトリを「配置先ディレクトリ」とします。
    その後、ターミナルを開いて以下のコマンドを入力してhttpサーバを起動します。
cd 配置先ディレクトリ
node httpd.js

次に、もう1窓ターミナルを開いて以下のコマンドを入力してシグナリングサーバを起動します。

cd 配置先ディレクトリ
node wss_signaling.js
  1. フロントエンド起動
    https://localhost:10443/p2p_syncvrm_phys.html
    を2窓で開く。

各回の概要

  1. https://zenn.dev/velserm/articles/localverse_0001
    何を作ろうとしているのか?
    どういう手段を使うのか?
    環境構築手順
    について書いています。

  2. https://zenn.dev/velserm/articles/localverse_0002
    THREE.JSとthree-vrmを使って3Dアバターシステムを構築しています。

  3. https://zenn.dev/velserm/articles/localverse_0003
    WebRTCを使った通信システムを構築しています。
    動作確認のためにチャットクライアントを作っています。

  4. https://zenn.dev/velserm/articles/localverse_0004
    3を基にして、同期処理を実装しています。
    動作確認のために2Dの箱と画像をアバターに見立てたクライアントを作っています。

  5. https://zenn.dev/velserm/articles/localverse_0005
    2のアバターシステムを4の実装を使って同期します。

FAQと称する自問自答

これは何を目的としていますか?

プログラミング教育の素材になるといいなと思っています。
学生が興味を持ちそうなテーマで、頑張れば理解できる程度の難易度を想定して書いています。

商用サービスに向かない理由は?

  1. ブラウザ上動作なのでアバターモデルが丸見えになる。
    これを回避しようとしたら
    three-vrmごとアバターシステムをwasm化して
    独自形式でアバターを転送することになりますが
    教育用途でソース公開が前提なので不可能です。
  2. ワールドの実装に制限がない。
    ウェブページにjavascriptで記述するということは、悪意を持ったコードを書くことも可能です。

なんでウェブサーバから書いているのか?

インターネット上にサーバを持ってない人でも実際に試せることを目的としています。
既存のhttpサーバを使わずにnode.jsで書いている理由はどうせシグナリングサーバを作るからです。

なんで3回目と4回目を分けているのか?

3回目の部分は、WebRTCを使って何かを作ったことがある人なら読まなくてもわかる内容だからです。

認証処理の強度が弱いのでは?

ソースを公開している関係で凝った認証処理にしても意味がないと判断しています。
最低限の機能だけ実装しているので必要ならカスタマイズしてくださいという方針です。

クライアント側で実行時に改ざんすれば任意のp2p通信できるのでは?

個別チャット可能な時点でシグナリング手段に使えるので、シグナリングサーバ側で認証を要求しています。
もちろんコードの改ざんによる任意のp2p通信は防げませんがログイン記録は残るので完全な匿名にはならないと考えています。

ゲームとかできますか?

この記事で作っているのはフルメッシュ構成のp2pで同期をしているアバターチャットです。
フルメッシュ構成だと判定を行うサーバがないので本質的にゲームに向来ません。
やるなら、部屋のホストを作って、そこから各プレイヤーに星型にp2p接続してプレイヤー状態はホストで集中管理する必要があります。
このホストはネットゲームにおけるインスタンスサーバに相当します。
これについては気が向いたら書くかもしれません。

Discussion