ナラティブ（または少なくとも時空間的でない）に焦点を当てたエンジン/フレームワークはありますか？[閉まっている]

編集（2）：2つの答えがあり、それらのいずれも受け入れていないので、私はここで答えを検討することを動機づけると思いました：そのようなアプローチを強く示唆する何かが不可能/まったく役に立たないか、あるいは、テキストアドベンチャーゲーム/インタラクティブフィクションを超えた、少なくともある程度一般的なそのようなシステムの研究（フィールド）または例への言及。

詳細な調査を行ったふりはしませんが、調べたすべてのゲームエンジン/フレームワークは、形やエンティティを2つに分けて表現しているという意味で、美化されたグラフィックエンジンのようなものであることに気付きました。または、多分ある種の並行処理モデルが「組み込まれた」3次元ユークリッド空間で、これらの「エンティティ」に接続されたロジックの形式を指定できるようにします。

ゲームの「ルール」とナラティブは、これらのプリミティブの上に（エンジンに関して）アドホックな方法で書かれています。

明らかに、上記の説明はかなり単純化されています（何らかの形のクエスト/ナラティブシステムを含む無限エンジンなどのより専門的なエンジンを使用します）。 。

しかし、ゲームルール/ロジックの説明（または高レベル）（または少なくともゲームの非空間的な側面）などの概念を取り入れたエンジン/フレームワークを作成するためにどのような試みが行われたのでしょうか。基礎？

編集（4）：これは、ゲームに空間的/グラフィック的側面が含まれないことを意味するのではなく、ロジックを関連付ける空間エンティティーではなく、プロット（またはゲームプレイまたは「ボードゲームルール」）の概念があります。 ）次に、グラフィカルインターフェイスを実現するために記述します。

特に私は、実際の実装に役立つ方法で（たとえば、専用のフレームワークとは対照的に）ある程度大きなクラスのゲームのある種の（半）形式的なセマンティクスをキャプチャしようとする宣言的アプローチに興味がありますゲーム/ナラティブの定性分析）。

私が見たのは、ペトリネットベースのモデルを使用した物語のモデリング/分析に関する調査と、インタラクティブフィクションを作成するための言語における興味深いアプローチです。

編集（1）：説明するためにおもちゃの例を追加すると思いました。

ポイントアンドクリックスタイルのアドベンチャー（SCUMMゲームなど）の作成に興味があったとしましょう。これらは、開始状態から終了まで、ほぼ線形で離散的な進行の概念に基づいていると分析することができます。

離散的な進行の概念に焦点を当て、ある程度の非直線性を考慮に入れて、基本的な理論として（制限された）DAGの理論を選択できます。したがって、このタイプのゲームを（この理論に対して）最も抽象的な形式で指定することは、この理論に公理を追加することに相当します（理論が特定のグラフを指定するか、単純に、グラフをキャプチャするために必要と思われるものをキャプチャするのに十分です） "プロット"）。

これを実際のゲームに変えると、この理論を再生可能なものに埋め込むというHCI /インターフェース設計の問題に変わります（つまり、理論のモデルを構築する/遷移のあるユーザーインターフェースの状態のコレクションからグラフのホモ（イソ？）モルフィズムを見つける） DAGに「ゲームを指定する」）。

上記の架空のシナリオでは、ライブラリに取り込むことができるはずの少なくとも3つのことがわかります。まず、DAGまたはグラフ全般に​​関する変換/推論のためのツールが必要です。次に、プレイ可能なゲームとしてのグラフの表現が実際にグラフをモデル化していることを確認するのに十分なほど巧妙なユーザーインターフェイスライブラリ（たとえば、少なくとも部分的または非公式に、境界条件により、ゲームにスタック状態がないことを証明します） 。最後に、グラフを指定するためのより高レベルのライブラリのコレクションを指定できます。キャラクターとその相互作用を表現し、そのような観点からグラフ（の一部）を生成するためのライブラリーなど。

いくつかのヘルプライブラリを上にして低レベルの実装を行うだけでなく、DAGの「中間」理論を維持する理由は何ですか。答えは、正式なセマンティクスのすべての通常の理由です。正式な基盤を決めたので、ゲームの特定のプロパティを確認して、低レベルのインターフェイスライブラリの最適化などについて推論できるようにします（DAGをモデル化している限り、必要なことを実行できます）。それらの記述自体がそのような構造を記述しなければならないので、（文字/ダイアログなどの）高レベルの記述との比較ができないことを心配します。

私は上記のアプローチが具体的に機能することを決して意味していませんし、DAGが実際にメモリに保持されるものである必要はないということではありません（ラムダ計算などの計算形式に似たものを形成します）。しかし、これが私が興味を持っている種類のアプローチを示すことを願っています。

要するに、私はこの質問の代わりのタイトルがあったかもしれないと思います：どのようにダイクストラはコンピュータゲームを書いたでしょうか？

ナラティブとゲームのルールに関する簡単なメモ：インタラクティブなフィクションでは、ゲームは分岐するナラティブのグラフをトラバースするものであると主張できますが、最終的にはナラティブはゲームメカニックの外に生息します。それでも、ゲームを完了する（またはゲームをプレイするときに失う）手順はまったく同じです。これは、開発者が一方を他方に合うように変更することを選択する場合を除いて、物語がゲームプレイに無関係であることを意味します。ゲームでは、ナラティブは本質的に、そのナラティブを楽しむプレイヤーにとってメカニックをより説得力のあるものにすることができる、メカニックに対するファサードですが、それだけです。いくつかのゲームがあります（ただし、ゲームと呼ばないものもあります）。ナラティブが娯楽の主要な形式であり、ゲームのメカニズムはほとんどがおかしなものです。Esther様。ただし、フィクションの作者が行うのと同じように、開発者が正式な方法でストーリーを伝える必要はないので、これ以上の説明はしません。一般的に言えば、「プレイアブルナラティブ」のように見えるゲームは、存在し、ナラティブなしで有意義に議論できるゲームイベントのツリーまたはグラフです。

私が調べたすべてのゲームエンジン/フレームワークは、2次元または3次元のユークリッド空間の形状/エンティティについて話すという意味で、美化されたグラフィックエンジンのようなものであることに気づきました[...]

はい、ほとんどの「ゲームエンジン」は明らかに「ビデオゲームエンジン」であり、それらの主な責任は、ゲーム側ではなくビデオゲームのソフトウェアエンジニアリング側を促進することでした。ソフトウェアエンジニアリングが最新で最も高価であり、したがって最も危険な側面であるため、これは間違いなく理にかなっています。比較すると、抽象的な意味でのゲームデザインは、ツールを使用せずに何千年もの間手動で行われてきたため、これがなぜ当てはまるのかをある程度説明できるかもしれません。

ゲームルール/ロジックまたはナラティブ（または少なくともゲームの非空間的側面）の（高レベル）説明などの概念を主な基礎とするエンジン/フレームワークを作成するためにどのような試みが行われましたか？

私の知る限り、深刻な試みはほとんどなく、成功もしていません。

Storytronは1つです。「従来のインタラクティブなフィクションとは異なり、ストーリーワールドは、ゲームの世界の地理やそれに登場するありふれたオブジェクトよりも、俳優の行動と反応、感情と傾向のモデリングに重点を置いています。」これはErasmatronと呼ばれる以前の取り組みの結果ですが、実際には成功しませんでした。Storytronも実際には成功したようには見えません。次の記事はこれをよく読んでいます：ドラゴンを追いかける

それほど野心的なレベルではありませんが、単純なゲームを表現する単純な方法を考え出した人はたくさんいます。多くのうちの1つの論文は次のとおりです。マルチゲーム—ボードゲームを説明するための非常に高水準の言語（リンクはログインの背後にありますが、検索できる場合があります）が、最後にコンピューターで読み取り可能なすべてのセットです。状態、状態遷移、および勝利条件またはスコア保持機能-チェスなどの個別のボードゲームやポーカーなどのカードゲームには問題ありませんが、大量の連続的な状態のゲームや、より多くのセマンティクスを持つゲームには一般化しませんシミュレーション（例：シューティングゲーム）やスポーツ（例：レーシングゲーム）など。このようなゲームは、ゲームの状態の単純なツリーでは適切に表現できません。

これらのより複雑なシステムの理解に取り組む1つの方法は、既存の各メカニズムをいくつかの基本的なフォームの1つに分類して、すべてのゲームプレイが可能であるという前提の下で、基本的なフォームを組み合わせてより複雑なゲームプレイを形成する方法を理解することですこれらの基本単位、またはそれらの組み合わせで構成されます。ダンクックには、「ゲームの仕組みとは」という記事があります。そしてフォローアップ「ゲームデザインの化学"ゲーム構成へのこの構成的アプローチを文書化しようとします。理論的にはその上に宣言型システムを構築することは可能かもしれませんが、実際にはメカニズムはゲームのごく一部を形成するだけなので、結果の出力はおそらく制約されますほとんどのゲーマーの注意を引くには柔軟性に欠けるプレゼンテーションフレームワーク内。

ゲームデザインの概念を定式化する他の試みは、しばしば「ゲーム文法」と呼ばれます-そのような記事の1つは「マルチプレイヤーゲームアトム」と呼ばれますが、これは以前のさまざまな作品を参照しています。

ポイントアンドクリックスタイルのアドベンチャー（SCUMMゲームなど）の作成に興味があったとしましょう。[...]（有界）DAGの理論を基本理論として選択することができます。[...]最初に、DAGまたはグラフ一般に関する変換/推論のためのツールが必要です。次に、プレイ可能なゲームとしてのグラフの表現が実際にグラフをモデル化していることを検証するのに十分なほど巧妙なユーザーインターフェイスライブラリ（たとえば、少なくとも部分的または非公式に、境界条件により、ゲームにスタック状態がないことを証明します） 。最後に、グラフを指定するためのより高レベルのライブラリのコレクションを指定できます。たとえば、文字とその相互作用を表現し、そのような観点からグラフ（の一部）を生成するためのライブラリなどです。

ここでの問題は、コンピュータがプロセスに多くを追加しないことです。このようなゲームの設計者は、まさにこれを正確に作成します。これは、ゲームの流れを示すデジタル形式または物理形式のグラフです。ゲームが理論的に完了することができるかどうかを確認するのは簡単です。ポイントアンドクリックアドベンチャーを進めるためのさまざまなルールをエンコードすることも簡単です。難しいのは、興味深い物語に沿って、説得力のある世界に設定し、アートとサウンドアセットを作成して、ゲームとインターフェイスを適切に表現し、さまざまなソフトウェアエンジニアリングタスクを組み合わせて、すべてをまとめるということです。ゲーム全体の重要な状態の有向グラフは通常、比較的簡単です。問題となるのは、周りのすべてのものです。これがあまり関心がない理由です

私は現在、Storybricksという製品のチームで個人的に作業していますこれは、さまざまなルールを指定することで興味深いゲームプレイの構築を可能にすることを試みます。これらのルールは、人の初期状態やニーズなどを述べます。これらのルールを取り、その人のニーズが満たされるかどうか、また満たされる場合はその方法を簡単に確認できるため、ゲーム内で完了する必要のあるタスクを宣言的に作成できます。しかし、これ自体は本質的に興味深いゲームプレイを作成しません。なぜなら、「XはYが必要です-それらのためにフェッチする」というレベルまで抽象化すると、プレーヤーはパターンを見つけ始め、それを楽しむことができなくなるためです。（例：Skyrimで自動生成されたクエストにすぐに飽きてしまったのは、デザイナーが作成したものと比較して、手続き的に生成されたミッションには本質的な意味がないことがわかったからです。）したがって、私たちの仕事は、AIメソッドを使用してこれらの状況をより面白くすることであり、それは私たちがまだ取り組んでいるものです。（ストーリーブリックはまだ非常に初期のアルファ段階です）。しかし、私たちの調査では、このようなことを試みている人はほとんどいないこと、そしてそれは非常に難しい問題であることを示しています。

宣言型アプローチのもう1つの問題は、あまり使用できないことです。たとえば状況が解決可能であること、または一連の論理ルールが一貫していることを証明するために処理するのが簡単であるため、科学者はそれを好みます。しかし、現実の世界では、コンピューターゲームプログラマーもエンドユーザーも、結果を発生させるためにどのように行動するかを指示する命令型の表現と同じくらい、結果に焦点を当てた宣言型の表現に慣れていません。現在のトップ10のプログラミング言語はすべて必須であり、実際の命令も、ケーキの焼き方や家具の作り方など、一般に必須の形式です。。スペクトルの両端からのこの熱意の欠如は、現代のゲームの正式な仕様を作成する商業的インセンティブがないことを意味し、これは近い将来変更される可能性は低いようです。

私はしばらくの間どのように返信するかを考えていましたが、これをどのように表示するかはよくわかりません。

いい質問ですね。残念ながら、答えは結局のところ、ゲームエンジンはもちろん、この方法で何かをプログラムすることは意味がないか、またはこれはすでにある種のことであるということです。

オブジェクトの物理的な存在を定義する方法が必要であるため、グラフィックスにこの重点が置かれているようです。私たちが実際に話しているのは次元の表現なので、これは実体化し始めるようなものですが、今のところこれを無視してみましょう。重要な点は、これは本当にかなり複雑なことです。空間の表現を可能にすることは、本質的にゲームエンジンのプログラミングの多くを占めるものになるでしょう。また、デザイナーが素敵なシーンを作りたい場合は、配置方法を細かく制御する必要があります。したがって、グラフィックについて多くのことがわかります。

だから、それは物事の低レベルの側面です。誰かがこれらの小さな技術的な問題のすべてに深く深く考える必要があります。

物語とゲームのルールに関してはどうですか？これは、ゲームエンジンの本来の目的の範囲外です。これは、開発グループが参加する部分です。

さらに、プログラミングを通じてアイデアを表現する方法について、多くの考えが払われていないようではありません。それこそが、コンピュータサイエンスの歴史です。そして、これがゲームエンジンが高級言語へのインターフェースを頻繁に持つ理由です。それらを通して思考を表現する方が簡単です。

それを念頭に置いて、物語を強調するゲーム専用の言語を作ることはできますか？私はおそらくそうは思いません。繰り返しますが、これはすべて表現に帰着します。言語は、コンピュータがそれをどうするかを知っているような方法で詳細を説明できるようにする必要があります。ゲームの作成に固有の言語を作成することを目的とする場合、設計に関する決定はその中心に行う必要があります。

繰り返しになりますが、言語にはさまざまな選択肢があります。そして、ゲーム業界の人々よりも多くの人々がそれらを開発しています。通常は、これらのいずれかを使用するのが理にかなっています。

要約すると、興味深いが非常に難しい質問をしました。そして、それが何であるか、または実際にそれに答えたかどうかは完全にはわかりません。

*編集：振り返ってみると、私は3Dゲームエンジンしか存在していないかのように考えていたことがわかりました。一部のゲームでは、物理的な空間で人がまったく行動しません。そのような場合でも、ゲームエンジンが大きく貢献するかどうかはわかりません。

ホビーコンピューティングの歴史の初期（80年代など）には、テキストベースのゲームとスプライトベースのゲームの両方で利用できる市販のゲーム開発キットがいくつかありました。スプライトベースのものは、現在の「グラフィックエンジン」に非常に似ていました。

もう1つのタイプには、自然言語パーサーなどがあります。このタイプは、現代の「レベルエディタ」で生きているようです。それらのほとんどは、LuaやPythonスクリプトなどのサポートを含んでいるようです。また、オープンソースレベルの編集ではあまり活動が見られないことにも気づきますが、それは、これらの問題が通常、問題のゲームの詳細に非常に密接に関連しているためです。ここでは、エルダースクロールのコンストラクションセットのようなものについて考えています。

Kinectはパーサーを元に戻す場合があります。古いテキストベースのアドベンチャーゲームのファンとして、ここでもベセスダの方向性に興奮しています。それは確かに独占的ですが、おそらくいくつかの若い天才...