ゲームでのスクリプト言語の役割プログラミング

Question

私は、スクリプト言語の適切な役割がゲーム開発にどのような役割を果たすかについて仕事をしています。私が知る限り、これには2つの考え方があります。

1）スクリプト言語は強力でフル機能です。ゲームコードの大部分は言語で書かれており、コードはパフォーマンスが必要と指示するときにのみC++に移行されます。これは通常LuaやUnrealScriptのようなものです。

2）このスクリプト言語は非常に限定されています。ほとんどすべてのゲームコードはC++であり、その言語はデザイナーに基本的な機能を公開するためのものです。

私の欲求不満は、頻繁に悪用されるアプローチ2を見て、大規模なシステムがそのコードを保守可能にする機能を持たない言語で実装されていることに由来します。

私はアプローチナンバーワンをサポートし始めましたが、デザイナーと話をしたあと、彼らの多くは2番を好むように見えました。

だから私はまだどんなアプローチが良いか不思議に思っています。私はちょうど悪いコードを見て、プログラマーの代わりにツールを責めているか、もっと複雑なツールが本当に必要なのでしょうか？

Answer 1

私はデザイナーは、彼らに適した言語を見なければならないと思う。それは交渉可能ではありません。プログラムを設計するのではなく、設計に時間を費やさなければなりません。

スクリプトが製品価値の高いゲームコードをすばやく開発できる場合は、プログラマーもそれを実行する必要があります。しかし、それは製品価値のあるものでなければなりません。すべてを2回することは時間を節約しません。だからあなたはその場所にスクリプトを残しておく必要があります。開発者が1週間でインベントリシステムをスクリプト化したり、1か月でC++で記述したりすることができれば、フル機能のスクリプティングが必要になります。インベントリ、ハイスコアテーブル、キーマップシステム、キャラクターがやっているような高水準のゲームロジックではありません。プログラマーは、ボトルネックが何であるかを正確に把握する必要があります。シニアプログラマーは、妥当な予測をすることができます。これにより、グラフィックスや物理学のスピードアップに費やす時間を節約できます。そうです。

プログラマがゲームコードを実装するためにスクリプト言語を使用しているかどうかは、デザイナーは知らないでください。彼らは（1）が良いか悪いかにかかわらず意見を持ってはならない。だから、プログラマーが（1）を欲しいのであれば、なぜこれがデザイナーに不便なのでしょうか？スクリプティング言語がフル機能を備えていることに気づいたことがありますか？必要なものすべてが標準レシピの数はかなり少ないのですか？何かが間違っていますが、私はそれがルアがあまりにも良い言語だとは思わないと思います。

一つの可能​​性は、両方に同じスクリプト言語を使用して、ゲームコードの内部設計者によって使用されるインターフェース、およびインターフェース間の鋭い線を引くの障害となることです。それは、私がトップで言ったように、交渉可能ではない。たとえ同じスクリプト言語を使用していても、プログラマは設計者に仕事をするために必要な機能を提供する必要があります。デザイナーがLuaを使ってAI戦略と会話ツリーをコード化するだけで、Luaは物理エンジンを書くことができるフル機能の言語ですから、デザイナーが独自の物理エンジンを書くことを期待するわけではありません。または、Luaの機能の10％以上を使用します。

おそらく（1）と（2）の両方を行うことができます。あなたがプログラマのLuaとLuaにLuaスクリプトで "コンパイル"された、いくつかの小型の低機能DSLを与えることができない理由はありません。

Answer 2

大量のスクリプトコードが大量のC++より優れているという議論は実際には分かりません。 1つは反論をすることができます。私はスクリプティングの考え方から始まったスクリプト言語で書かれた恐ろしい大規模なプロジェクトを見てきました。これは残念ながらうまく拡張できません。プログラミング言語だけに基づいてコード品質の議論をする方法はありません。人々は、メンテナンス可能なコードのゴブを、コンパイルされたかスクリプティングされた言語で書くことができます。

とにかく、パフォーマンスのボトルネックがどこにあるのか、またユーザーが最も「スクリプト化」したいと思うものを知らずに、「アプローチ1」と「アプローチ2」の間の線を知ることは本当に不可能です。

私は「アプローチ3」を提案します。これは、C++で全部または一部を実行し、C++でクリーンなSDKを公開することです。これは、組織外の誰かが使用しなければならないユーザーインターフェイスであるかのように、コードを書くように強制する利点があります。うまくいけばメンテナンスが容易になり、スクリプティングインターフェースを実装するという副作用が増えます。あなたのスクリプトインターフェイスは今すぐあなたのSDKに転送する必要があります。ビオラ！

このアプローチでは、「スクリプト化された」ものとC++のものとの間に線を引く必要はありません。あなたとあなたのユーザーは、SDKを使用してC++で機能を追加するか、スクリプト言語を使用するかの選択肢があります。

Answer 3

いつものように、答えは「それは依存している」と思います。

何もありませんHalo 3またはCall of Duty 4は、主にスクリプト作成に基づいている可能性があります。定格AAAタイトルは、彼らが触れるプラットフォームのエンベロープを明確にプッシュする必要があります。これはスクリプトではできません。

しかし、カジュアルゲームは別の話です。 Unityのような主要なゲームエンジニアリングには、多くのスクリプティングが組み込まれています。

モッズのマーケットもあります。優れたスクリプト環境を備えた堅実なゲームエンジンは、調整、派生、場合によっては全く新しいゲームのためのプラットフォームになることができます。カウンターストライクは私の個人的な好きな例です。私はあなたがこのケースではFPSランアンドガン型ゲームに限定されていると思う。

ゲームではスクリプト作成用の場所がありますが、おそらく小規模/カジュアルなゲームやモデダーの空間にとどまるでしょう。

Answer 4

私はあなたが欲しいのバランスがこの効果に何かあると思う：あなたは、スクリプト内のゲームロジックをしたいが、コード内のゲーム機能。

スクリプトの大きな大きな利点の1つは、簡単に待機を設定できることです。例えば、

敵= GetObjectFromScene（ "enemy01"）; 5秒間で {敵.GrenadeAt（プレイヤー）; }

単なる人工的な例です。そのようなロジックは、C++でセットアップするのは面倒です。スクリプトはこの種のロジックを表現しやすくしますが、実際の機能（それが呼び出す関数）をC++にしたいと思うでしょう。

スクリプトはにはありませんが遅いです。コンソールで60fpsで動作する大量のスクリプトゲームがありますが、上のオプション1と2の間に適切なデザインと適切なバランスが求められます。

Answer 5

ゲーム開発コミュニティは、ユーザーインターフェイスを構築し、AI応答をチューニングする非常に一般的な方法として、既にスクリプトを使用しています。あなたはGamasutraのようなサイトでたくさんの情報を見つけることができます。興味深いのは、標準言語がカスタムインタープリターを置き換え始めていることです。

AAAゲームでは、World of Warcraft（Luaを使用）とEvE Online（Pythonを使用）の2つのスクリプト例がベストです。 EvEはサーバ側でもスクリプトを使用しています。スタックレスPythonに多大な投資をしています。

更新：パフォーマンスは本質的にマルチコアのために問題にはなりません。ローエンドのマシンでさえ、ディスプレイやモデルのアップデートよりも多くのコアが必要になります。これらのコアの1つを、UI用のスクリプトソリューションを実行するのに使うこともできます。

Answer 6

コンパイルされたC++コードのコンパイル、リンク、実行、テストサイクルあなたがビデオゲームは非常に、非常に遅いような複雑なようなものを扱っています。スクリプトエンジンを使用すると、プログラムをコンパイルすることなくゲームに大きな変更を加えることができます。これは大規模かつ大規模な時間節約です。あなたが言うように、最適化が必要なものは、必要に応じてC++に移すことができます。

AAAエンジンは、スクリプト作成によって高度に駆動されます。 Tribes II（および他の多くのゲーム）に使用されているTorqueはスクリプト化されています.UnrealにはUnrealScriptなどがあります。スクリプティングは改造のためのものではなく、効率的な開発の鍵です。

Answer 7

これまでに述べたように、ゲームロジックにはスクリプトを使用し、ゲーム機能にはC++を使用します。たとえば、ゲームモードのスクリプトを作成して、レンダリングにC++を使用する例があります。

Answer 8

実際のスクリプト作成の最良の例の1つはCivilization IVです。 Boost Pythonを使用しています。その結果、それはひどく遅いです。 "コードはパフォーマンスが必要であると指示したときにC++に移される"というステートメントに対する明確な対称性。

適切な方法は、フロンアーキテクチャを設計し、計算が困難であり、フロントを指定するのが複雑であるどの問題を決定することです。グラフィックス、物理学、経路探索、入力時の即時フィードバック、テキストから音声へ - すべてが計算上ハードなもの。 「友好的または敵対的な立場」、「防御するか攻撃する」、「過ごすか節約する」タイプのAI決定はすべて前を特定するのは複雑です。

結論は、あなたができる公開するということですが、あなたのスクリプトコードに魂の俳優。スクリプトコードではと記述されていますが、俳優が何をすべきかはですが、C++コードはの処理方法はです。コンパイルリンクサイクルに関しては

、それは適切なモジュールアーキテクチャを持つことが重要です。パスファインディングロジックで作業しているときは、グラフィックスコードをコンパイルする必要はありません。また、Incredibuildのようなツールは、コンパイル時間を短縮するのに役立ちます。ビッグゲーム企業はおそらく既にレンダリングファームを持っているでしょう。これはコンパイルファームとしても非常によく機能します。

Answer 9

ゲームを2つの部分に分割した場合：エンジンと実際のゲーム（デザイン）。

ソリッドトップクラスのゲームエンジンはC/C++で書かれている可能性が高く、アセンブラコードでさらに最適化する人もいます。あなたは、特定のCPU命令を使ってグラフィックスや物理学のために素早く素早く多くのことを行うことができます。大規模な風景や複数の複雑なオブジェクトをスクリプト言語からのみレンダリングするときにパフォーマンスを得る方法はありません。

ゲーム自体は、より低速ですがより高いレベルのプログラミング言語で実行できる多くの側面があります。 AIや他のゲームロジックは、スクリプトで成功裏に書くことができます。それは開発をスピードアップすることができ、簡単な方法でモデリングやコミュニティ拡張を開くことができます。

Answer 10

だから私はアプローチ ナンバーワンをサポートして始めたが、いくつかの デザイナーに話をした後、私はそれらの多くは、数2、および1つを好むその ほとんどのプログラマを好むように見える ことに気づきました。

これは明らかです。スクリプト言語が「強力でフル機能」であれば、この機会を利用できるため、システムを作成する必要があるという悩みがデザイナーにあります。一方、スクリプティング言語がハードコーディングされたゲームの小さな部分しか公開しない場合、プログラマーはデザイナーができないので、それらのシステムを作成する必要があります。私はそれぞれの側面が怠け者であると言っているわけではありませんが、明らかに両方ともプロジェクトに集中しなければならない個別のスキルを持っています（他の誰も効果的にそれらを行うことができないため）。可能。

これから当然のことながら、適切な役割は、あなたの会社の人材がどのようにレイアウトされているかに依存します。どんな人が何種類のスクリプトを必要としているのか分かっていれば、どれくらいのゲームでそれが必要かを知ることができるので、インターフェースの幅や幅を決めることができます。これは上記のonebyone.livejournal.comで言及されているように、言語の「ドメイン」が何になるかに貢献します。

（少し、それは価値がある何のために、私はプロのゲーム開発者ともGamedev.net上のスクリプト言語のフォーラムのモデレーターです。）

Answer 11

私はここにポスターは、メソッド＃1を支持するために正しいと思います。それはよりクリーンな方法であり、デザイナーの苦情にもかかわらず、より良い長期的結果をもたらすでしょう。最終的にコードは良い（悪い）からgame programmingを決定します。

Answer 12

ゲームはC++だけで（あるいはAAAのタイトルがそのように行われていると主張して）行うべきだと言っているのは無知です。独自のスクリプト言語（UnrealScript）、一般的な言語（Lua、Python、C＃、Javaなど）やデータ駆動型（XML、独自のバイナリ形式など）であれば、ゲームのほとんどは今日のようにスクリプト化されています。いくつかの調査を行い、ほとんどのエンジンがある形式または別の形式でスクリプトを採用していることがわかります。

私は1）強力でフル機能のスクリプティング言語対2）非常に限られたスクリプト言語を持っているかどうかの問題は間違った終わりから問題に近づいていると思う。スクリプト作成環境（言語またはデータ駆動型）は、ゲームを作成するプロセスを最もよくサポートするように設計する必要があります。システムの表現力はここで重要です。デザイナーやスクリプタは、複雑すぎるシステムに曝されるべきではない間に、頭を悩ますことなく、問題を容易に解決できなければなりません。プログラマー（自分自身を含む）は、システムがどのように使用されるかを前提にして、地球と天国の間のすべての機能を実装できるようにすることでシステムを設計する傾向があります。この複雑さに圧倒されて、設計者は最小限の作業で作業を完了させます。

例えば私たちのゲーム（Rochard）では、完全に拡張可能でスクリプト化可能なデータ駆動型AIシステムを設計しましたが、レベルAIはAI AIを使用する時間や労力がなかったため、システムを最大限に活用することができます。だから、結局のところ、私はちょうどそれらのストックAIパターンを簡単に選択するための良いUIを作成しました。

私は、この問題では銀色の弾丸はないと言います。