LuaをC ++ゲームに組み込むことの長所と短所は何ですか？

私にはC ++ゲームプログラミングの本があり、その中にLuaセクションがあります。Luaセクションを読み始めましたが、面白いように聞こえますが、C ++ゲームでLuaを使用することの長所と短所を判断することはできません。私が現在考えることができる唯一の利点は、再コンパイルすることなく、Luaを介してコーディングの更新を行うことができることです。それ以外は、何も考えられません。それでは、C ++ゲームにLuaを追加することの長所と短所は何ですか？

例をいただければ幸いです。

私が現在考えることができる唯一の利点は、再コンパイルすることなく、Luaを介してコーディングの更新を行うことができることです。

このユーティリティをそれほど簡単に割引しないでください。再コンパイルのステップを取り除くまで、あなたがどれほど生産的になるかを理解することは決してないでしょう。

「流れ」それが仕事に来るときかなりよく理解心理学的概念です。フローは、アクティビティに集中しているとき、ほとんど考えずに問題を分析して解決しているときなどに得られる感覚です。「フロー」しているときは、最も生産的です。

コンパイル時間はそれらすべてを台無しにします。何かをテストする間に10秒のコンパイルさえあれば、フローにとどまるのは困難です。

ゲームプレイを開発しているとき、通常持っているのは「タイトループ」です。アイデアがあり、テストをコーディングして、それが機能するかどうかを確認してから、試してみてください。動作しない場合は、変更して再試行してください。「コードをテストする」時間は、フローを維持するために非常に重要です。できるだけ小さくすることが重要です。

Lua（または埋め込みスクリプト言語）でできることは、「コンパイル」せずに変更をテストするだけでなく、ゲーム内で実行することです。ゲームのビルド方法に応じて、データを停止したり再ロードしたりすることなく、新しいスクリプトでゲームを再起動するコマンドを実行できます。再コンパイルする必要がないだけでなく、再実行する必要もありません。

適切なエンジンのサポートがあれば、これを実行できるため、生産性が大幅に向上します。

スクリプトのもう1つの大きな利点は、気にしないことです。C ++を書くのに長い時間を費やしているなら、minutaeにどれだけの時間を費やしているのかに驚くでしょう。メモリが削除される場所。これが解放される場所。shared_ptrあらゆる場所で使用している場合でも、これらすべての変数の型名を入力するだけで動作が遅くなります。

動的に型指定されたスクリプト言語では、気にする必要はありません。スコープは簡単です。関数はファーストクラスのオブジェクトです。ファンクタを手動で作成する必要はありません。いくつかのことを行うのはとても簡単です。

あなたが規律のあるプログラマーでないなら、それは否定を持っています。Luaでグローバルを使用するのは非常に簡単です（それを防ぐ方法はありますが）。気遣わないということは、コードを書くときに非常にずさんなことができることを意味します。

しかし、再び、非常にずさんなことには利点があります。

Luaのもう1つの利点は、優れたデータ記述言語を作成できることです。JSONが単に配列/テーブルを構築して返すJavaScriptファイルであるように、テーブルを返すLuaスクリプトを作成できます。

これは構成ファイルに役立ちます。Luaのテーブル形式は、.ini形式よりもはるかに優れています。このフォーマットは、まだかなりきれいで、コンパクトで、拡張可能です。

ああ、それはまだLuaスクリプトなので、実際のロジックを実行できます。その欠点は...まあ、それはLuaスクリプトなので、実際のロジックを実行できます。ユーザーが物事を台無しにする可能性があるため、それはゲームで悲惨なものになる可能性があります。

しかし実際には、これは簡単に対処できます。Luaは埋め込み用に設計されているため、実際には分離は非常に簡単です。実際、新しいLua状態はデフォルトでは何も提供しません。最も基本的な標準Luaライブラリを公開するために、実際に何かをする必要があります。ファイルアクセス、ゲーム状態アクセスなどはすべてオプトインであり、オプトアウトではありません。また、各Luaの状態は互いに独立しています。AIスクリプトに使用するLua状態は、構成ファイルに使用するLua状態である必要はありません。

実際、多くのLua標準ライブラリを登録できるコードがありますが、すべてのファイルIOを削除して削除します。最終的に、Luaスクリプトベースの構成ファイルで発生する可能性のある最悪の事態は、メモリ不足でゲームを実行するとすぐにゲームがクラッシュすることです。また、これらの構成ファイルを手動で共有していないため、ハッカーにとってはあまり面白くないでしょう。

スクリプト言語の最大の欠点はデバッグです。ほとんどのスクリプト言語にはデバッガーがなく、Luaも例外ではありません。Luaには、デバッグツールの構築に必要なツールがすべて揃っています。しかし、実際にはデバッガが組み込まれていません。1つをまとめる必要があります。そして、それには合理的な程度の作業が必要になります。

または、「printfデバッグ」を使用して支払うことができます。それはあなたが書くLuaコードの量に本当に依存します。

勤務地：

長所：

• 反復時間の改善。私たちのゲームは、ホストファイルシステムの変更をポーリングし、変更を自動的に「丸lurみ」するように設定されています。（これらは次のファイルを開いたときにのみ有効になりますが、実際には大きな改善です。レベルをリロードすると、新しいluaの変更がすぐに反映されます。）
• コンソール統合。デバッグ機能はすべて、REPLを使用して従来のQuakeスタイルのコンソールにフックできます。内部ビルドの場合、telaを話す単純なソケットにlua REPLをフックすることもでき、ゲームをネットワークで制御できます。
• APIの削減と学習曲線の低下。非技術系のアーティストやデザイナーは、通常プログラマのボトルネックとなるいくつかのタスクに参加できます。
• 特殊な静的コード分析。luac -lバイトコードの出力を解析し、バイトコードを覗いて分析を行うのは簡単です。特にコーディング規約がある場合は、ほとんどのluaソースファイルを解析することも非常に簡単です。地方大会を実施できます。ここでさらにパワーを得るために、metaluaを調べることもできます。
• エラー処理。APIがクラッシュしない場合、たとえluaが愚かなことをしたとしても、それをキャッチしてを使用して回復できlua_pcallます。
• 簡単なAPI拡張。Lua <-> C ++ APIの新しい関数を作成するのはそれほど難しくありません。これを自動化するのに役立つパッケージもあります。
• シンプルなソース。luaインタープリターでの浮動小数点数学の回避（一部の組み込みプラットフォームで重要）や特定のシステム向けの最適化などの変更は難しくありません！
• メタテーブル。これらは素晴らしいです。実行時に興味深いことを行う可能性が非常に高い。実際にはコンテンツを持たない「仮想テーブル」があり、ゲームのC ++側で複雑なデータ構造を検索します。
• コルーチン。AI動作スクリプトなどを停止および再開できることは驚くべきことです。しかし、luaスクリプト作成者側ではもう少し知識が必要です-エンジンでこれをより「安全」にする方法に取り組んでいます。

短所：

• 予測不可能なGC。stepゲームごとに劇的に変化するものを調整します。フレームごとのフルGC（小さなワーキングセット）でより適切に動作するものもあります。いくつかのパスは、はるかに小さいパスでより頻繁に機能します。新しいluaバージョンといくつかのパッチ（使用することを恐れてはいけません！）でGCを改善するために多くの作業があることに注意してください。
• より高いオーバーヘッド。テーブルエントリごとのメモリオーバーヘッドを回避するために、多くの大きなデータ構造をC側に保持します。C ++、C、およびアセンブリは一般に、より高速なコードを生成します。そのため、パフォーマンスに重要ではないゲームエンジンの90％に維持され、luaからC（またはその逆）に移行することがあります。
• フラグメンテーション。おそらく、小さなメモリシステムでの最大の問題です。通常、luaには小さなオブジェクトプールと完全に独立した大きなオブジェクトヒープを使用します。ゲームの戦略的なポイントにフルGCパスを配置します。lua_State場合によっては、スクリプトをアンロードするか、完全に破棄します。そして、まだ問題がある場合があります。小さなオブジェクトプールのサイズ（単純でオーバーヘッドを減らすために固定されています）とlua固有の大きなオブジェクトヒープのサイズを調整するのは大変です。しかし、約4MBを超えるシステムでは、特殊なヒープとプールにまだ悩まされていません。
• 型の安全性の欠如。優れた静的コード分析ツールセットが構築されていない場合は、多くの実行時エラーチェック（おそらく__indexand を使用__newindex）に頼ります。コンパイル時にエラーをキャッチできればより良いです。これを軽減するためにできることはさまざまです。

Luaを強くお勧めします。少しでも喜んで使用してください。Squirrelもチェックしてみてください。ユーザーベースは小さいと思います。

実際には、3つの大きな利点があります。

• アプリケーションの実行中にスクリプトをロードできるランタイムロード。
• サンドボックスhttps://stackoverflow.com/questions/3400851/execution-time-limit-for-a-lua-script-called-from-the-c-api/3400896#3400896
• 移植性

これらの要素により、ゲーム開発者は開発をスピードアップし、ゲームの品質を向上させる機能を有効にできます。

例えば：

• ファイルまたはネットワークソケットからゲームを更新するだけで、ゲームロジックを変更できます。
• ユーザーが独自のスクリプトを作成できるようにすることができます（ボットまたはmod用）
• ゲームのデザイナーとアーティストは、コンパイルツールセットを使用しなくても、ゲームの一部を更新およびテストできます。
• いくつかのスクリプトを変更するたびに再コンパイルする必要はありません。
• プラットフォーム/エンジン/言語を変更する場合、ゲーム全体を書き換える必要はありません。

私の経験から、少し煮詰めました。

長所

• 最初の統合は本当に簡単です。バインディングの生成を支援するツールはありますが、バインディングメカニズムは非常に単純なので、すぐに独自のカスタム機能を使用して独自のバージョンを作成できます
• ゲームロジックの反復がはるかに高速になります（ランタイムの再読み込みを実装すると仮定します）
• 実験するための解放的な環境が得られます。そのためのオーバーヘッドが大幅に低下するため、より多くのことを試してみることができます。
• なじみのある構文：その違いはすべて、Cプログラマーとしては数時間以内に慣れないように強いられます
• ゲームロジックの「エンジン」へのより良い分離：エンジンは、適切なAPIをLuaクライアントに公開する必要があるサービスプロバイダーになります。言語の壁は、そこに手を伸ばしてメンバー変数をいじるのではなく、あなたがそれについてもっと考えるようにします

短所

• Luaのメモリ管理はゲームには理想的ではありません。あなたはそれに対処します、あなたはそれが好きではありません
• Luaのデバッグはすぐに使用できます。あなたは経験を改善するために働く必要があります
• Luaでデータを保持することは、Luaでデバッグする必要があることを意味します。Cからデータを検査することは、最初は注意が必要です。
• Luaには、デフォルトですべての変数がグローバルであるように、足の構文でかなりの量の自分を撃ちます
• Luaは他の言語と同様にプログラミング言語です。コンパイラーを削除したからといって、非プログラマーが魔法のようにプログラマーになることを期待しないでください。
• Luaの統合とサポートが得意になるのは大変な作業です。箱から出してすぐにゴロゴロすることを期待しないでください。実際に、この費用を数回のゲームで償却する必要があると仮定するのは公平です。

最終的な個人的な判断：適切なサイズのゲームを構築していて、スクリプト言語をまだ持っていない場合は、Luaを入手してください。それだけの価値があるでしょう。

Garry's Modは、LuaとC ++を使用するゲームの一例です。すべてのmodにLuaを使用しているため、人々が作成しやすくなっています。C ++はすべての内部に使用されます。私が考えることができる唯一の欠点は、LuaがC ++ほど速くないという事実です。