80

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

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

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

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

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

言語はC#ですが、任意の.NET言語でスクリプトを記述できる場合は、追加のボーナスがあります。

4

9 に答える 9

42

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

別のアプローチは、 IronRubyIronPythonLuaなど、スクリプト用に特別に構築された言語を検討することです。

IronPythonとIronRubyはどちらも今日利用可能です。

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

Luaは、ゲームで一般的に使用されるスクリプト言語です。.NET用のLuaコンパイラがあり、CodePlexから入手できます-http ://www.codeplex.com/Nua

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

まったく別の角度は、PowerShellを試すことです。PowerShellをアプリケーションに埋め込む例は多数あります。このトピックに関する徹底的なプロジェクトは次のとおりです 。Powershellトンネル

于 2008-08-02T01:49:46.220 に答える
8

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

それ以外の場合は、プリコンパイル済みアセンブリを配置するディレクトリを用意することをお勧めします。次に、DB でアセンブリとクラスへの参照を作成し、リフレクションを使用して実行時に適切なアセンブリをロードできます。

実行時にコンパイルしたい場合は、CodeDOM を使用できます。その後、リフレクションを使用して動的アセンブリをロードできます。役立つかもしれないマイクロソフトのドキュメント記事

于 2008-08-02T04:18:15.517 に答える
7

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

于 2008-08-06T16:28:19.783 に答える
6

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

于 2008-08-02T06:16:23.967 に答える
5

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 ライブラリ内にありました。

Lua 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から

これを行うと、メモリ リークはすべてなくなり、アプリケーションは非常に安定しました。

于 2012-07-17T17:08:51.790 に答える
5

LuaInterfaceを使用することをお勧めします。これは、Nua が完全ではなく、いくつかの非常に便利な機能 (コルーチンなど) を実装していないように見える Lua を完全に実装しているためです。

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

于 2008-09-17T01:41:29.067 に答える
4

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

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

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

于 2008-08-10T15:24:23.553 に答える
4

はい、私はそれについて考えました、しかし私はすぐに別のドメイン固有言語(DSL)が少し多すぎるだろうと思いました。

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

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

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

于 2008-08-01T23:49:57.103 に答える
3

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

于 2010-11-27T02:12:59.443 に答える