質問

C# で書かれた小さなゲームがあります。バックエンドとしてデータベースを使用します。それは トレーディングカードゲーム, で、カードの機能をスクリプトとして実装したいと思いました。

私が言いたいのは、本質的にインターフェースがあるということです。 ICard, 、カード クラスが実装します (public class Card056: ICard)、ゲームによって呼び出される関数が含まれています。

ここで、これを保守可能/変更可能にするために、各カードのクラスをデータベース内のソース コードとして保持し、基本的に初回使用時にコンパイルしたいと思います。したがって、カードを追加/変更する必要がある場合、アセンブリのデプロイメントを必要とせずに、データベースにカードを追加してアプリケーションに更新するように指示します (特に、カードごとに 1 つのアセンブリについて話しているため、これは数百のアセンブリを意味します)。 。

それは可能ですか?ソースファイルからクラスを登録してインスタンス化するなど。

ICard Cards[current] = new MyGame.CardLibrary.Card056();
Cards[current].OnEnterPlay(ref currentGameState);

言語は C# ですが、任意の .NET 言語でスクリプトを作成できる場合はさらに便利です。

役に立ちましたか?

解決

Oleg Shilo の C# スクリプト ソリューション (The Code Project にて)) は、アプリケーションにスクリプト機能を提供するための優れた入門書です。

別のアプローチとしては、次のようなスクリプト専用に構築された言語を検討することです。 鉄ルビー, アイアンパイソン, 、 または ルア.

IronPython と IronRuby は両方とも現在入手可能です。

IronPython を埋め込むためのガイドについては、こちらをご覧ください。10 の簡単なステップで既存のアプリに IronPython スクリプトのサポートを埋め込む方法.

Lua は、ゲームでよく使用されるスクリプト言語です。.NET 用の Lua コンパイラが CodePlex から入手可能です -- http://www.codeplex.com/Nua

このコードベースは、.NET でのコンパイラの構築について学びたい場合に最適です。

まったく別の角度から試してみることです パワーシェル. 。PowerShell をアプリケーションに埋め込む例は数多くあります。このトピックに関する完全なプロジェクトを次に示します。パワーシェルトンネル

他のヒント

それには IronRuby を使用できるかもしれません。

それ以外の場合は、プリコンパイルされたアセンブリを配置するディレクトリを作成することをお勧めします。その後、DB 内にアセンブリとクラスへの参照を保持し、リフレクションを使用して実行時に適切なアセンブリを読み込むことができます。

本当に実行時にコンパイルしたい場合は、CodeDOM を使用し、リフレクションを使用して動的アセンブリを読み込むことができます。 役立つ可能性のある Microsoft ドキュメントの記事.

DLR を使用したくない場合は、次のようにすることができます。 Boo を使用します (インタープリタを備えています) あるいは検討してもいいでしょう CodePlex の Script.NET (S#) プロジェクト. 。Boo ソリューションを使用すると、コンパイルされたスクリプトを使用するかインタープリターを使用するかを選択できます。Boo は優れたスクリプト言語を作成し、柔軟な構文とオープン コンパイラー アーキテクチャによる拡張可能な言語を備えています。ただし、Script.NET も見た目は素晴らしく、オープン ソース プロジェクトであるだけでなく、その言語を簡単に拡張でき、非常に使いやすいコンパイラ ジェネレーター (アイロニーネット).

独自のスクリプト プラットフォームを非常に簡単にホストする方法を提供する DLR 言語のいずれかを使用できます。ただし、これにはスクリプト言語を使用する必要はありません。C# を使用し、C# コード プロバイダーでコンパイルすることもできます。独自の AppDomain にロードしている限り、思う存分ロードおよびアンロードできます。

使用することをお勧めします Luaインターフェース Nua は完全に実装されていますが、Nua は不完全で、非常に便利な機能 (コルーチンなど) を実装していない可能性があります。

外部の事前にパックされた Lua モジュールの一部を使用したい場合は、フルマネージド コードを構築し、必要な C API を公開できない 2.x シリーズではなく、1.5.x に沿ったものを使用することをお勧めします。

NET 1.1 アプリケーションに LuaInterface1.3 + Lua 5.0 を使用しています。

Boo の問題は、コードをオンザフライで解析/コンパイル/評価するたびに、Boo クラスのセットが作成されるため、メモリ リークが発生することです。

一方、Lua はそのようなことをしないため、非常に安定しており、素晴らしい動作をします (オブジェクトを C# から Lua に、またはその逆に渡すことができます)。

これまでのところ、まだ PROD に入れていませんが、非常に期待できそうです。

LuaInterface + Lua 5.0 を使用した PROD でメモリ リークの問題が発生しました, したがって、Lua 5.2 を使用し、DllImport を使用して C# に直接リンクしました。 メモリ リークは LuaInterface ライブラリ内で発生しました。

ルア 5.2:から http://luabinaries.sourceforge.net そして http://sourceforge.net/projects/luabinaries/files/5.2/Windows%20Libraries/Dynamic/lua-5.2_Win32_dll7_lib.zip/download

これを実行すると、メモリ リークはすべて解消され、アプリケーションは非常に安定しました。

私の部門が販売しているメインのアプリケーションは、クライアントのカスタマイズを提供するために非常によく似た処理を行っています (つまり、ソースを投稿することはできません)。動的 VB.NET スクリプトをロードする C# アプリケーションがあります (ただし、どの .NET 言語も簡単にサポートできます。カスタマイズ チームが ASP 出身であるため、VB が選択されました)。

.NET の CodeDom を使用して、VB を使用してデータベースからスクリプトをコンパイルします。 CodeDomProvider (厄介なことに、デフォルトは .NET 2 です。3.5 の機能をサポートしたい場合は、"CompilerVersion" = "v3.5" の辞書をコンストラクターに渡す必要があります)。使用 CodeDomProvider.CompileAssemblyFromSource メソッドを使用してコンパイルします (メモリ内のみでコンパイルするように設定を渡すことができます。

これにより、メモリ内に数百のアセンブリが作成されますが、すべての動的クラスのコードを 1 つのアセンブリにまとめて、変更があったときに全体を再コンパイルすることができます。これには、ディスク上でコンパイルするフラグを追加できるという利点があります。 PDB テスト時に動的コードを通じてデバッグできるようになります。

はい、それについて考えましたが、別のドメイン固有言語 (DSL) を使用するのは少しやりすぎであることがすぐにわかりました。

基本的に、彼らはおそらく予測できない方法で私のゲーム状態と対話する必要があります。たとえば、カードには「このカードが場に出たとき、敵が祝福されている場合を除き、すべてのアンデッド ミニオンは飛行する敵に対して +3 の攻撃力を得る」というルールを設定できます。トレーディング カード ゲームはターンベースであるため、GameState Manager は OnStageX イベントを起動し、カードが必要とする方法で他のカードや GameState を変更できるようにします。

DSL を作成しようとすると、かなり大規模な機能セットを実装し、場合によっては定期的に更新する必要があるため、実際には削除せずにメンテナンス作業が別の部分に移されます。

そのため、私は基本的にイベントを発生させるだけでカードが (コード アクセス セキュリティの制限内で) 何らかの方法でゲーム状態を操作できるように、「本物の」 .NET 言語を使い続けたいと考えていました。

.NET の次のバージョン (5.0?) では、スクリプトの直接評価などが可能になる「サービスとしてのコンパイラー」のオープンについて多くの話題がありました。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top