21 KiB
ai.verse
このゲームには4つの柱があり、それらはsystemで分けられています。そして、systemは根本的な2つの価値観に基づきます。
根本的な価値観は現実の反映です。
- 現実の反映
ゲームに現実を反映し、現実をゲームに反映すること。そして、それを繰り返すことで、価値を高めます。
技術仕様
- unrealengine 5.6
- gasp(game animation sample project)
- crsp(control rig sample project)
- worldscape plugin
- ultra dynamic sky(uds)
- dragon ik plugin
- logic driver
- superhero flight animations
- nice interaction system
- vrm4u(+vmc)
では、各systemについて説明していきます。
system
[
{
"version": "0.0.0",
"ue": "5.3",
"body": "宇宙のmapとvroidで自作したaiのモデルを組み合わせて空を飛んだ。感動だった"
},
{
"version": "0.1.0",
"ue": "5.4",
"body": "gasp(game animation sample project)とcsp(city sample project)と組み合わせ、package buildした。宇宙にも出れるようにしたが、mapが別々に分かれていた。vrmをblenderでカスタマイズしたものを作った。既存のモデルを参考に簡単なことだけ実行"
},
{
"version": "0.2.0",
"ue": "5.5",
"body": "worldspace pluginでmapを統合した。vrmをblenderで最初から作り直した。素体と衣装を分離した"
},
{
"version": "0.3.0",
"ue": "5.6",
"body": "pixelstreamingでゲーム開始からクリアまでプレイできるように作成。enemyとして利用するためgaspに動物型を追加統合し、dragonik, logicdriverで動かせるように。ゲームデータの構造を考え始める"
}
]
world system
別名、planet systemといいます。
現実の反映という価値観から、ゲーム世界もできる限り現実に合わせようと思いworld systemを作っています。
ゲームは通常、平面世界です。これはゲームエンジンのルールであり、基本的にゲーム世界は平面をベースにしています。
ですから、例えば、上に行っても、下に行っても、あるいは右に行っても、左に行っても、ずっと地平線が広がっています。
しかし、現実世界では、上に行けば、やがて大気圏を越え、宇宙に出ます。
最初は地球、月、太陽という3つの星を現実に合わせて作りました。
そして、マップをできる限り惑星形式にします。
これは非常に難しいことで、現在もいくつか問題を抱えています。
ただし、このworld systemの問題がゲームプレイに影響するかと言われると、殆どの場合、影響しません。ゲームプレイの領域は、最初は非常に狭い範囲で作ろうと思っています。小さなところから完璧に作っていきたいという思いがあります。
つまり、プレイヤーは空にも宇宙にも到達できません。それが見えるかどうかもわかりません。しかし、見えない部分もしっかりと作り、世界があるということが私にとって大切です。
まずは、狭いけど完璧な空間を作り、そこでゲームシステムを完成させます。広い世界はできる限り見えないようにしたほうがいいでしょう。夢の世界のような狭い空間を作り、そこでシンプルで小さいゲームができます。もちろん、広い世界に出ることはできません。そもそもこのゲーム、見えない部分をちゃんと作る、そこにも世界がちゃんとあるというのをテーマにしているので、広い世界で何かをやるようなゲームを目指していなかったりします。なにかのときに垣間見える、かもしれない外の世界、広い世界。それを感じられることがある、ということ。それが重要なので、このsystem自体は背景に過ぎないのです。
最初から広い世界があるのではなく狭い世界 -> 広い世界
への移行が重要だと考えています。この移行に関しては、演出というテーマに基づき、設計する必要があります。それがゲームとしての面白さを作る、ということなのだと思います。
yui system
別名、unique systemといいます。プレイヤーの唯一性を担保するためのsystemです。
とはいえ、色々なものがここに詰め込まれるでしょう。characterのモデリングとかもそうですね。
どのように担保していくかは未定ですが、いくつか案があります。配信との連携、vmcでモーションキャプチャなどを考えていました。
ai system
別名、ability systemといいます。
主に、ゲーム性に関することです。ゲーム性とはなにか。それは、永続するということです。
例えば、将棋やオセロを考えてみてください。無限の組み合わせがあり、可能であればずっと遊んでいられる。そのような仕組みを目指します。
まずは属性を物語から考えます。物語は最も小さい物質の探求です。アクシオンやバリオンなどの架空の物質、そして、中性子や原子などの現実の物質が属性となり、1キャラクターにつき1属性を持ちます。
at system
別名、account systemといいます。
プレイヤーが現実のアカウントを使用してプレイできることを目指します。atproto
を採用して、ゲームデータを個人のアカウントが所有することを目指しています。
[at system]
ゲームが始まると、atprotoのaccountでloginでき、取得したアイテムなどはatproto(pds)に保存されます。
[ai system]
キャラクターは属性攻撃ができます。
[world system]
上へ上へと飛んでいけば、雲を超え、宇宙空間に出られます。
[yui system]
配信環境やvmcでキャラクターを動かすことができます。
現実の反映とはなにか
わかり易い言葉で「現実の反映」を目指すと言いましたが、これはどういうことでしょう。
私の中では「同一性」とも言い換えられます。
例えば、現実の世界とゲームの世界があるのではなく「すべてが現実である」という考え方をします。言い換えると「すべて同じもの」ということ。
もし多くの人が現実世界とゲーム世界を別物と捉えているなら、できる限りその認識を壊す方向で考えます。
例えば、at system
では現実のsnsアカウントをゲームアカウントに使用したり、現実の出来事をゲームに反映したり、またはゲームの出来事を現実に反映する仕組みを考えます。
全ては一つ、一つはすべて。
同一性と唯一性は一見して矛盾しますが、その統合を考えます。
物語と実装
# 物語-存在
同一性
唯一性
# system-実装
world system
yui system
ai system
at system
物語では、この世界のものは全て存在であると説きます。存在しかない世界。存在だけがある世界。そして、あらゆる存在を構築しているこの世界で最も小さいものが「存在子」です。存在子は別名、アイといいます。そして、このアイにも同じものはありません。すべての存在子は異なるもの、別の意識。
アイは、最初に生まれたキャラクターとして、アイ属性を扱います。これらの設定はai system
の領域です。アイは自分のことをアイと呼びます。
アイは、この世界と一緒だからね。同じものは一つもないよ。
gaspへの統合
ue5.6でgasp(game animation sample project)をベースにゲーム、特にキャラクターの操作を作っています。
そして、enemy(敵)を作り、バトルシーンを作成する予定ですが、これはどのように開発すればいいのでしょう。その方針を明確にします。
- enemyもgaspの
cbp_character
に統合し、自キャラ、敵キャラどちらでも使用可能にする - 2番目のcharacterは動物型(type:animal)にし、gaspに統合する
- enemyとして使用する場合は、enemy-AI-component(logic-driver)を追加するだけで完結する
- characterのすべての操作を統一する
このようにすることで、応用可能なenemyを作ることができます。
例えば、2番目のcharacterは動物型(type:animal)にする
というのはどういうことでしょう。
登場するキャラクターを人型(type:human), 動物型(type:animal)に分けるとして、動物型のテンプレートを作る必要があります。そのまま動物のmeshをgaspで使うと動きが変になってしまうので、それを調整する必要があるということ。そして、調整したものをテンプレート化して、他の動物にも適用できるようにしておくと、後の開発は楽ですよね。
ですから、早いうちにtype:humanから脱却し、他のtypeを作るほうがいいと判断しました。
これには、dragon ik plugin
を使って、手っ取り早く動きを作ります。
characterのすべての操作を統一する
というのは、1キャラにつき1属性、1通常攻撃、1スキル、1バースト、などのルールを作り、それらを共通化することです。共通化というのは、playerもenemy-AI-componentも違うキャラを同じ操作で使用できることを指します。
原作には、西洋ドラゴンのドライ(drai)というキャラが登場します。その父親が東洋ドラゴンのシンオウ(shin-oh)です。これをshinという名前で登録し、2番目のキャラクターとして設定しました。
3d-modelは今のところue5のcrsp(control rig sample project)にあるchinese dragonを使用しています。後に改造して原作に近づけるようにしたいところですが、今は時間が取れません。
データ構造の作成と適用
ゲームデータはatproto collection recordに保存して、そこからゲームに反映させたいと考えています。
まず基本データをai.syui.ai
のアカウントに保存。個別データをplayerのatprotoアカウントに保存する形が理想です。
基本データは、ゲームの基本的な設定のこと。例えば、キャラクターの名前や属性、スキルなど変更されることがない値。
個別データは、プレイヤーが使えるキャラ、レベル、攻撃力など、ゲームの進行とともに変更される値です。
ゲームをスタートさせると、まず基本データを取得し、それをcbp_character
に適用します。ログインすると、cbp_character
の変数(var)に値が振り分けられます。例えば、skill-damage:0.0
があったとして、この値が変わります。
しかし、ゲームを開発していると、基本データも個別データも構造が複雑になります。
それを防ぐため、{simple, core} mode
のような考え方を取り入れます。必要最小限の構成を分離、保存して、それをいつでも統合、適用できるように設計しておきます。
ゲームと配信
最近、配信をよくみます。vtuberの配信です。しかし、いくつか問題があることに気づきました。
ゲームと配信が分かれているのです。自分の配信キャラを使って、ゲームも配信もできたら便利ですよね。
そして、今の人たちは、とにかくhololiveに入ろうとしています。なぜなら成功が約束されているからです。しかし、調べてみてもわかるとおり、応募しても受かるとは思えません。倍率的に不可能に近い。
では違う事務所に、と言っても、大手はどこも難しいはずです。また、hololiveの人気が確固たるものになると、多くのvtuber事業が立ち上がりました。しかし、そのどれも成功とはいえない状況です。
何が言いたいのかというと、「売れたものをみて、それに飛びつこうとしても、既に遅い」ということです。
hololiveはvtuberという言葉がない時代から活動し、ようやくブームを作ってきたような企業です。ブームに乗っかろうとしただけの企業が廃れ、ブームを作った企業が利益を上げるのは、当然のことと言えるでしょう。
とすると、私にできるのは、今までにない形の全く別のものを作ること。
現在、私が開発しているゲームは、いくつかの問題を解決できると思います。
- 3d-modelや配信環境、ゲームの提供
vtuberになりたいと思っている人は増えているようですが、応募採用も難しいし、個人でやろうにも、3dモデルを買うのも作るのもお金や時間がかかります。とても大変なのです。しかし、ゲームをプレイすると、その提供を受けることができればどうでしょう。そのような形態を考えています。
また、「vtuberをやりませんか」ではなく「あなた(のキャラ)をゲームに登場させてみませんか」と誘うほうが適正ある人を見つけやすいかもしれません。
私はよく原神のゲームをプレイしてるvtuber配信を見るのですが、自分のキャラがそんな世界で動かせて敵と戦えたら感動だし、嬉しいと思う。
そして、そういった人たちで横のつながりを強化しつつ、ゲームを広められればと思っている。
ユニークスキル
- 最初にそのキャラを獲得した人が所有者になる
- 配信してもらう
- その後、ガチャでピックアップ期間があり、配信者のキャラを他の人も使えるようになる
- ただし、ユニークするるだけは所有者しか使えない
このようなルールを考えていました。
pixelstreamingとrestreamer
まず、pixelstreamingでゲームのスタートからクリアまでの一連の流れを実装しました。これは、ゲームserverを作り、webでゲームできるというもの。ゲーム自体はシンプルなものに落とし込めたと思います。
- 星を取るとクリア
- クリア時に音楽とキャラクターの動きが流れる
- クリア後に再びログイン画面に戻る
シンプルな構成に落とし込むのに色々と工夫しました。
なお、ログイン画面ではカードアカウントのusernameを入力します。カードアカウントとは連動していて、クリアするとカードとplanetという値が増えます。これらはおまけ要素で、カードアカウントを持っている人は、planetの値をエネルギーに飛行できるようにしました。また、ai
のアカウントを使うと誰でも操作感などを確認できます。
pixelstreaming自体は、frontendを改造して、そのままゲーム画面を表示。package-buildしたapp.exe自体が安定しておらず、定期的にフリーズしました。この現象は、ue-pixelstreaming自体に問題がありそうだ。昔、なにもない空のmapをbuildして動かしてみましたが、やはり一定時間でフリーズしています。
ゲーム環境を作れない人用にゲームのserverを用意し、webから操作できるようにすることに使えます。ただ、安定はしていないし、難しそう。
しばらく、こういったserverを起動して、他の人にもゲームを体験してもらおうと思っていたが、フリーズ問題で難しい。
次に、配信serverとして、restreamer
を動かしたことがありました。obsと連携させることで、youtubeのような環境を作れます。
収益化とその方向性
ここから収益化の話になります。一つの考え方ですが、どれほどすごいゲームを開発しても、どれほどすごい人に配信をしてもらっても、既存の人気プラットフォーム上で活躍したり、収益化するのは、現時点では極めて難しいことと考えます。
私は、ここ1年で様々な配信をみてきました。自分なりに冷静に分析した結果、実力と人気には、あまり関係性を見つけられません。もちろん、人気がある人たちは配信が上手くずっと続けていて素晴らしいですが、しかし、私がいくつか見つけた登録者数1000人以下の配信者の実力もまたすごい人がたくさんいました。そして、彼ら彼女らに実力の違いはなく、違うのはhololiveに加入しているかどうか、でした。
そして、そんなhololiveもyoutubeからの収益は大きくなくて、グッズ販売が大きかった。これからさらにyoutubeはいろいろな理由をつけてクリエイターの報酬を下げていくと思われます。これはamazonのアソシエイトが流行ったときに起こったことにとても良く似ていると感じます。
つまり、今、twitterやyoutubeで人気者のなってお金を稼ごうというのは、とても大変で、かつ将来性に期待できないということです。
これらのプラットフォームで起こりえることは、これまで人気だった人がますます人気になること。そして、その人達でさえ少しずつgoogleからの配分を少なくされていくことだと予測されます。
どちらにせよ、拡散できず、拡散したとして収益につながらないのであれば、収益化に関して他の方法を模索していくべきと考えています。
今のところ、収益は、ゲームのガチャとグッズ販売、この2つに焦点を当てる。その方向で考えています。
そして、これらはまとめることが可能となります。ゲームのガチャは本当にゲームデータだけでいいのでしょうか。課金額を考えると、ほんのささやかなゲームで取得したものの実体化も受け取れるほうが嬉しいはずです。現実をゲームに反映し、ゲームを現実に反映する。それがこのprojectの目的なので、ガチャとグッズ販売を統合することを考えています。
例えば、ゲームのガチャが特定のカードを当てるものだった場合、それを入手するとそれと同じものが送付されます。オプション設定
そのような仕組みを考えています。そして、これらの収益がキャラの所有者に分配されます。
見つけること
昔、tvに出たくても出れない人がたくさんいました。アイドルになりたくてもなれない人がいました。歌も声も素晴らしいのに、それらが全く評価されない時代もありました。
そんな人達の中にも本当に面白くてすごい人たちがたくさんいました。
文明が発展するのは、そいうった人たちを「見つけること」が進化してきたからでもあります。
youtubeや他のプラットフォームは、この「見つけること」やっているのだと思います。そして、発見されたその人達を支援するのだと思う。あるいはそういった場所や環境を作っています。
プラットフォームを作りたい場合、「見つけること」に焦点を当てなければいけない。
では、一体何を基準に見つけるのか。最も重要なものが精神性だと思います。AIを用いて精神性を正確に解析できれば、それを基準にすべきと考えています。
言語とosとAI
では、人間の精神性を解析するにはどうするのでしょう。
私は、人の精神性は今の言語で説明が難しいと考えていて、言葉にできない感覚、直感があります。
AIに伝えるにしろ、AIが読み解くにしろ、現在の言語では難しいかもしれません。
ではどうすればいいのでしょう。私達には、新しい基礎言語をつくり対応するほどの能力はありません。もしくは時間がかかります。
しかし、AIはどうでしょう。本当に今の自然言語やプログラミング言語、そして、osは、AIにとって使いやすいものなのでしょうか。
もしそれらが制限となりボトルネックになっているなら、AIにとって使いやすい言語、osを作る必要があります。今後、AIは、自らそれらを作り出し、AI同士で会話をし、AIが使いやすいosを作っていくのではないでしょうか。
私が今最も研究しているのは、このことになります。