開発でスクリプトを使用する理由


67

私の現在のプロジェクトでは、Luaスクリプトはサーバー側のC ++関数によって呼び出されます。その後、スクリプトは再びそのソリューションにまだあるC ++関数を呼び出します。なぜ私たちはそのようなことをすべきで、C ++関数を直接呼び出さないのですか?スクリプトが必要な状況は何ですか?

回答:


73

通常、スクリプトは実行時にコンパイルされますが、ホスト言語はコンパイル時にコンパイルされます。つまり、スクリプトが変更されても、再コンパイルする必要はありません。完全なゲームの再コンパイルには数分から数時間かかる場合があり、これは生産性の大きな打撃を意味します。

通常、重要なコードまたはバックエンドコードはスクリプト化されません。このコードは高速で実行されるはずであり、多くの場合、メモリ管理が重要です。
ゲームでは、通常、ゲームのロジックと構成はスクリプトファイルに含まれています。これらのスクリプトはプログラマではないデザイナー(デザイナーなど)が簡単に更新して、ゲームプレイを微調整できます。スクリプト言語は簡単で、そのために寛容な方法で動作します。

多くの場合、スクリプト言語はリアルタイムでスクリプトを作成するためにも使用されます。これは、ゲームプレイの要素を微調整したり、デバッグする場合にも役立ちます。多くのゲームは、この(主に社内の)目的のためのコンソールを提供します。

スクリプトを作成するだけで、既存のゲームエンジンを使用してゲームを作成することは可能です。したがって、ゲームエンジンレイヤーは、ゲームロジックレイヤーから完全に切り離されます。通常、最新のエンジンを使用してこのようにFPSまたはRTSゲームを簡単に作成できますが、どのジャンルでも使用できません。MMOはおそらく別のタイプのエンジンを必要とします。

結論としては、デカップリングです。上記の利点は、多くの場合、スクリプト言語を作成または統合するための余分な作業を上回ります。


7
+1は、通常、非プログラマーがスクリプトを更新する方が簡単だと言っているためです。デザイナーは常にプログラマーであるとは限らず、そうである必要はありません。
オーク

19
スクリプトに関するすべての質問で自分自身を繰り返しているように感じます-ワークフローにプログラマー以外の人が(スクリプトを含む)プログラムする必要がある場合、後でお尻に噛み付くでしょう。デザイナーは常にプログラマーというわけではありませんが、自明ではないスクリプトを書くとすぐに(たとえば、関数を定義したりループを使用したりすると)、デザイナーのふりをします。彼らがプログラミングのトレーニングを受けていなければ、それはすべての人にとって涙と時間の無駄に終わるでしょう。

5
ジョー-これは議論を無効にするものではなく、「プログラミング」と「デザイン」を分離する場所を決める必要があることを意味します。その)。
イアンシュライバー

3
自尊心のあるデザイナーは少なくとも1つの言語で十分に教えられていると確信しています。物事を少し明確にするために、「非プログラマー」という用語をニュアンスしたいと思います。専門家はソフトウェアエンジニアの専門家ではないからです。私はこの言葉を使って後悔している、ジョーのおかげであいまいだと思う。単純なXMLを記述するプログラマーからハードコアアセンブリー、数学的な重い信号処理まで、幅広いプログラマーがいると思います。これが「プログラマーではない」双対性の問題を解決することを願っています。
ネフ

8
設計者が制作のために複雑でミッションクリティカルなスクリプトを書くべきだと提案する人はいませんでした。ただし、プログラミングをある程度理解している設計者は、いくつかのスクリプトを実験的に調整することができます(そして実際のプログラマーに引き渡します)。実行時にコンソールから簡単なアドホックスクリプトを作成して、独自のテストを容易にすることができます。デザイナーは、新しい画面デザインのプロトタイプを作成するために基本的なスクリプトを活用したいと思うかもしれません(たとえそれらが半機能的なインタラクティブなモックアップにすぎない場合でも)。大量の非実動コードを作成する必要があります。
マイクストロベル

38

間違った質問をしました。本当の質問は、なぜC、C ++、Javaなどの「非スクリプト」言語に我慢するのでしょうか。そして、答えは1つの理由です:パフォーマンス。(そしておそらく慣性ですが、その慣性はパフォーマンスのために存在し、優れたC / C ++ / Javaを作成できる人なら誰でも少なくとも許容できるRuby / Python / Lua / JavaScriptを作成できます。)

「スクリプト」言語(実際には、非常に高レベルのガベージコレクション、および通常は緩やかなタイピングと動的コンパイルを意味します)を使用します。一般に、プログラマーを含む誰もがコードを記述しやすい言語だからです。malloc後に解放することを忘れたり、コードが例外セーフであることを確認したり、すべてのデストラクタを仮想化することを忘れないなどの愚かなことです。コンピューターが無限に高速であれば、すべてに「スクリプト」言語を使用することになります。


4
「デザイナーがプログラムできるようにする」よりも、この議論非常に好きです。迅速な開発の価値を捨てて、すべてを再コンパイルせずに変更を試すことができるのは非常に悪い考えです。
ojrac

10

ゲームロジック用のスクリプト言語は、ハードアーキテクチャとソフトレイヤの交互のソフトウェアアーキテクチャパターンの非常に良い例です。そのサイト(および私が確信している他のサイト)では、そうすることの利点について良い議論があります。


8
  1. 新しいluaクラスはそれぞれ2行です。新しいC ++クラスはそれぞれ面倒です。
  2. 必要なのは値をシャッフルするだけである場合、型について泣くことはありません。
  3. ガベージコレクション。
  4. スクリプトコードは、これらの厄介なさまようセグメンテーション違反や配列オーバーフローから離れて、仮想マシンでうまく分離されています。

5

スクリプトの変更は簡単に展開できます。たとえば、スクリプトをデータベースに保持することができます。つまり、完全なバイナリ再デプロイと可能なサービス再起動の代わりに、単一のSQL UPDATEステートメントを発行するだけで、実行中のサービスにスクリプトをリロードするためのシグナルが続きます。

また、スクリプト言語は多くの場合、理解するのが簡単でプログラミングも簡単なので、大部分のコード(大規模なRPGの場合、メモリ管理/ポインターおよびCPUレベルの最適化を扱うもの)を必要としません。 AI、スペル、アイテムエフェクト、および世界自体のスクリプトは、多くの場合、エンジンコードよりも大きくなります)。スクリプト言語を使用すると、ガベージコレクション(Luaの場合)とより高いレベルの抽象化により、「方法」ではなく「内容」に集中することができます。


4

スクリプトが便利なシナリオの1つは、プラグイン/アドオンによってエンジンを拡張できるようにする場合です。これらの拡張機能は、多くの場合、非専門家(上級ゲーマーや愛好家など)によって作成されます。この目的のために、スクリプトはより安全で簡単です。スクリプトを使用することにより、コンパイラーを使用する必要がなくなり、ポインターを意識する必要がなくなります...

これの素晴らしい例は、World of Warcraftのゲームです。コミュニティによって作成された数千のアドオンがあります。これらのアドオンは、LUA + XMLを使用して記述されています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.