Nexus開発日記：エンジンのプロトタイプ

▶

Watch on YouTube

一ヶ月半前、スタジオの計画をサイトに載せた——Nexusエンジンについて、それが何で、その上にどんなプロジェクトを作っていくか、ストラテジーやエジプトシリーズの続編まで含めて。あわせてロードマップも出した。エンジンは複雑で、リスクを抑えるために少しずつ組み上げていきたいと思っていた。でもプレイヤーはコメントではっきり言った——こんなものを組み上げるのは無理だ、と。そこでまずプロトタイプから始めることにした——こういうエンジンがやはり作れるのだと示すために。それをこれから見せる。

今のエンジンはこんなふうだ。見た目はかなり素朴なコンソールアプリケーションだ。でも、いちばん大事なところはよく伝わると思う——異なるメカニクスが一つの汎用エンジンの上で動いている、ということだ。

今この上では四つのシミュレーションが動いている。一つ目はStone Age、スタジオのいちばん最初のゲームで、2013年のものだ。残りの三つは他人のプロジェクトをもとにしている。コピーしたり配布したりするつもりはなく、まったく違うゲームメカニクスが一つのエンジンの上で動くと示すためだけにここにある。

Stone Age

Stone Ageはエンジンの上でまるごと再現している。同じ能力値、年と手番、人口、土地。労働者を森に送るとそこで食料を集め、人口が増え、技術が現れる——それを研究して建物や進化の樹を解放していく、アウストラロピテクスからホモ・ハビリス、そしてその先へ。イベントも、結末も、オリジナルにあったものはすべてそろっている。

Slay the Spire

次はSlay the Spire、よくできたカードローグライクで、遊んだことのある人もきっといるだろう。エンジンに載せたのは戦闘だけだ——プレイヤーにはカード、エネルギー、体力があり、敵には敵の意図がある。Strike (攻撃)で殴り、Defend (防御)でブロックを張る。エネルギーを使い、手番を終え、そうやって交互に、どちらかが勝つまで続く。

GURPS

三つ目のシミュレーションはGURPS、かなり複雑なテーブルトークのシステムだ。そこから一つのモジュール、恒星系ジェネレーターだけを取り出した。面白いのは、このモジュール自体はそもそもゲームではなく、複雑なジェネレーターだということだ。これが恒星を一つと大量の属性を持つ系を組み立てた——軌道が十本、その上にさまざまな世界がある。最初の小さな岩石の世界は水星に似ていて、独自の質量、大気圧、その他もろもろを備えている。このシミュレーションだけで六千を超える事実がある。これは良いストレステストだ——エンジンがどれだけのデータをさばけるかがわかる。

Oregon Trail

四つ目はOregon Trail、1971年の古典で、最初期のコンピューターゲームの一つだ。幌馬車でアメリカを横断する開拓者たちの道のりで、出発前に物資を買い込む——牛、食料、弾薬、衣類——そのあとは狩りをし、食料を配分し、起こる出来事に対処していく。ほら、今こちらは襲われた。そうやって旅の終わりまで続く。

四つのゲームはすべて一つのエンジンで動いていて、そのどれにもコードを書く必要はなかった。

その場で書き換える

でもエンジンはこれらのゲームを動かすだけではない——コードに触れずに、その場で書き換えられる。Slay the Spireを例にとろう。

Strike (攻撃)のダメージを変えて、100にしてみる:

/set Strike.CalcDamage Value 100

その属性は二枚のカードで同時に変わった、同じクラスを共有しているからだ。

まったく新しいカード、Fireball (火球)を足すこともできる:

/add Fireball Is DirectDamage
/set Fireball.CostEnergy Value 2
/add Fireball Has CalcDamage
/set Fireball.CalcDamage Value 20
/add Fireball Has ApplyDamage
/add Fireball.ExecutionEffects Has CostEnergy
/add Fireball.ExecutionEffects Has CalcDamage
/add Fireball.ExecutionEffects Has ApplyDamage

さっきまでなかったのに、今はゲームの中にある——手札にあって、使えて、20ダメージを与えて、ほかのカードと同じように捨て札に行く:

ルールそのものも、コマンド一つで変えられる。使ったカードが捨て札に行く、というルールを外してみる。

/remove PlayCard Has MovePlayedCard

これで手札に残るようになった。Defend (防御)を使うと、ブロックが付き、エネルギーは消費されたが、カードは手元に残った。

プログラミング言語で書かれた普通のゲームなら、これをやるにはコードに分け入ってプロジェクトをビルドし直すことになる。ここではその必要がない。

同じやり方で、そもそもゲームになかったものも足せる。たとえばお金——これを用意して、どう使われるかを記述してみる:

/set Player.Gold Value 100
/add CostGold Output Owner.Gold
/add CostGold Math.Subtract.Apply true

少し前までなかった属性が現れる——お金、それもいきなり丸ごと百。

このお金を使って、新しい行動も作れる——Bribe (賄賂)だ。これはエネルギーではなくお金を消費する:

/add Bribe Is DirectDamage
/set Bribe.CostEnergy Value 0
/set Bribe.CostGold Value 30
/add Bribe Has CalcDamage
/set Bribe.CalcDamage Value 15
/add Bribe Has ApplyDamage
/add Bribe Has CostGold
/add Bribe.ExecutionEffects Has CostGold
/add Bribe.ExecutionEffects Has CalcDamage
/add Bribe.ExecutionEffects Has ApplyDamage
/create Bribe Player.Hand

Bribe (賄賂)はお金を30使って15ダメージを与える——そしてすぐに動く。

これはチートで、こんなコマンドを打つのは面倒だ、と見えるかもしれない。でもこれはチートではない。ゲーム全体を支える論理的な事実とデータ——その対象、属性、メカニクス——を書き換えているのだ。いわば、ゲームそのものを記述している言語を直接いじっているのだ。

この言語を覚える必要はない。普通の言い回しを、Nexusが理解するコマンドに変えてほしいとAIに頼めばいい。たとえば:

give 999 gold

訳せば、ただ「お金を999足して」というだけのことだ。

AIが考え、必要なコマンドを見つけて実行し、お金が999になる。

言い方を変えて「お金 100」でもいいし、それでも動く。「神にしてくれ」と言えばAIは無敵をくれる。手番を終える、攻撃する、回復する——どれも言葉でできて、エンジンが理解する。しかもどれもスクリプトで仕込んだものではなく、すべて本当に動いている。

今後の予定

コマンドはもっと簡単にしたい。今は同じFireball (火球)を作るのに八つほどコマンドが要るが、三つか四つに減らせると思っている。それに次の動画では、もっと目に見えるもの——2Dレンダーを見せてみたい。

エンジンと今後の予定について詳しくはNexusの項目へ。

ことわり：Stone Ageはスタジオのゲームだ。Slay the Spire、GURPS、Oregon Trailはそれぞれの権利者に属し、ここではエンジンのデモとしてのみ示していて——これらのビルドはどこにも配布していない。