Skip to content

哲学

目指す世界

全てに非依存なプレイヤー体験

  • 技術的制約のないクリエイター体験
  • 拡張可能・参入可能・持続可能な開発者体験
  • 全てに非依存なプレイヤー体験

VRChat の例

VRChat 上のプレイヤー体験は、

  • クライアントアプリに依存している
    • サードパーティーのクライアントは規約で NG
    • プレイヤーはファーストパーティーのクライアントを強制される
  • 故に、クライアントアプリの動作するプラットフォームに依存している
    • Windows, Android, iOS でしか動作しない
    • アバターもプラットフォームごとにビルドしないといけない
  • プレイヤーの使用する環境に依存している
    • Android や iOS の場合は表示できるアバターに制限がある
  • プレイヤーの環境のスペックに依存している
    • ネットワークやレンダリングなどのある 1 要因が重くなると、全ての体験が損なわれる
    • レンダリングが遅いなら描画品質を下げる、ネットワークが遅いなら音声品質を下げるなどができると良い
  • VRChat 社に依存している
    • 全ての仕様変更やモデレーションは VRChat 社が管理する
    • 全てのプレイヤーの振る舞いは社の方針に常に従う必要がある

Minecraft の例

Minecraft は Mod 拡張により VRChat と比較し多くの問題が解決されている。しかし、元が Minecraft というゲームであるという性質上、そこから大幅に逸脱した空間は構成されづらい。

目指すこと

全てに対して非依存 (Zero-dependencies) なプレイヤー体験を目指す。

例えば、プラットフォーム (OS、CPU アーキテクチャ、Web) などによって体験が異なってはいけない。

また、環境の品質にも非依存である必要がある。たとえ品質の悪い環境であっても優先する体験を選択可能であるべきで、極端な話、会話したいだけであれば最悪画面は真っ黒でも構わないということもあるはず。

ゲームルールもプロトコルの仕様に依存すべきではない。ある個人や法人の思想によって表現が制限されるべきではない。

空間は

  • プレイヤー、クリエイター、開発者の発想と権利
  • “メタバース”の定義

のみに依存すべきである。

参考

https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r05/html/nd131210.htmlhttps://crexgroup.com/ja/xr/metaverse/souken-definition/ 依然メタバースの定義が曖昧なので、再定義の必要がある。

技術的制約のないクリエイター体験

VRChat の例

VRChat のアバターやワールドは Unity で作成され、Udon アセンブリによって様々な動作が記述されている。また、インタラクトやアニメーションなど、一部の動作は VRChat 固有のシステムに従う必要がある。よって、本来通常の Unity では使用可能な機能が制限されてしまう。

目指すこと

クリエイターがあらゆる制約を受けずにより良い創作体験を追求できる。Unity の Animation Controller や自由な言語で創作できる。

拡張可能・参入可能・持続可能な開発者体験

VRChat の例

VRChat は規約の問題でサードパーティーのクライアントの作成が制限されている。また、Web API 仕様を解析することによる外部ツールの開発 (VRCX や Friend Connect) もグレーゾーンで、問題視されることも多い。一応、OSC という形でパラメータの取得・変更はできる。

目指すこと

開発者コミュニティをもって機能要件の達成を目指す。例えば、マイナーなプラットフォームへの対応なども、それを使いたい人自身でどうにかできるような環境を用意する。

そのために、クライアント、サーバー問わず仕様に対して外部の開発者が自由に拡張できるようにする。その際、開発者に対して冗長な実装を強いるべきではない。適切にレイヤー分けを実施し、変更したい部分、開発したい部分のみ開発できる。

拡張機能の開発は参入が容易である必要がある。複雑なアーキテクチャなどの事前知識がなくとも、低い学習コストで開発できる必要がある。 さらに、プログラミング言語や通信プロトコルのパラダイムシフトに対しても柔軟性を持たせるべきである。

今後のロードマップ

  • 「VRChat の簡単な再現」を目指し実装する ( – 2 月中旬)
  • 「目指す世界」を達成するための機能要件を洗い出す ( – 4 月)
  • 未踏の企画書を書く (2 月 – 3 月)