13 KiB
ai.verse
このゲームには4つの柱があり、それらはsystemで分けられています。そして、systemは根本的な2つの価値観に基づきます。
根本的な価値観は現実の反映です。
- 現実の反映
ゲームに現実を反映し、現実をゲームに反映すること。そして、それを繰り返すことで、価値を高めます。
では、各systemについて説明していきます。
system
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の領域です。アイは自分のことをアイと呼びます。
アイは、この世界と一緒だからね。同じものは一つもないよ。
ゲームと配信
最近、配信をよくみます。vtuberの配信です。しかし、いくつか問題があることに気づきました。
ゲームと配信が分かれているのです。自分の配信キャラを使って、ゲームも配信もできたら便利ですよね。
そして、今の人たちは、とにかくhololiveに入ろうとしています。なぜなら成功が約束されているからです。しかし、調べてみてもわかるとおり、応募しても受かるとは思えません。倍率的に不可能に近い。
では違う事務所に、と言っても、大手はどこも難しいはずです。また、hololiveの人気が確固たるものになると、多くのvtuber事業が立ち上がりました。しかし、そのどれも成功とはいえない状況です。
何が言いたいのかというと、「売れたものをみて、それに飛びつこうとしても、既に遅い」ということです。
hololiveはvtuberという言葉がない時代から活動し、ようやくブームを作ってきたような企業です。ブームに乗っかろうとしただけの企業が廃れ、ブームを作った企業が利益を上げるのは、当然のことと言えるでしょう。
とすると、私にできるのは、今までにない形の全く別のものを作ること。
現在、私が開発しているゲームは、いくつかの問題を解決できると思います。
- 3d-modelや配信環境、ゲームの提供
vtuberになりたいと思っている人は増えているようですが、応募採用も難しいし、個人でやろうにも、3dモデルを買うのも作るのもお金や時間がかかります。とても大変なのです。しかし、ゲームをプレイすると、その提供を受けることができればどうでしょう。そのような形態を考えています。
また、「vtuberをやりませんか」ではなく「あなた(のキャラ)をゲームに登場させてみませんか」と誘うほうが適正ある人を見つけやすいかもしれません。
私はよく原神のゲームをvtuber配信を見るんだけど、自分のキャラがそんな世界で動かせて敵と戦えたら嬉しいと思うんだよね。
ユニークスキル
- 最初にそのキャラを獲得した人が所有者になる
- 配信してもらう
- その後、ガチャでピックアップ期間があり、配信者のキャラを他の人も使えるようになる
- ただし、ユニークするるだけは所有者しか使えない
このようなルールを考えていました。
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のような考え方を取り入れます。必要最小限の構成を分離、保存して、それをいつでも統合、適用できるように設計しておきます。