Aggiunta funzionalità di script per NET

voti
62

Ho un po 'di gioco scritto in C #. Esso utilizza un database come back-end. E 'un gioco di carte collezionabili , e ho voluto implementare la funzione delle carte come uno script.

Quello che voglio dire è che ho in sostanza di avere un'interfaccia, ICardche una classe implementa scheda ( public class Card056 : ICard) e che contiene la funzione che sono chiamati dal gioco.

Ora, per rendere la cosa mantenibile / moddable, mi piacerebbe avere la classe per ogni carta come codice sorgente nel database ed essenzialmente compilarlo al primo utilizzo. Così, quando devo aggiungere / modificare una scheda, mi limiterò a aggiungere al database e dire la mia applicazione per aggiornare, senza bisogno di qualsiasi distribuzione di montaggio (soprattutto perché saremmo a parlare di circa 1 assemblaggio per ogni carta che significa centinaia di assemblee) .

È possibile? Registrare una classe da un file di origine e quindi un'istanza, etc.

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

Il linguaggio è C #, ma bonus extra se è possibile scrivere lo script in qualsiasi linguaggio .NET.

È pubblicato 02/08/2008 alle 00:22
fonte dall'utente
In altre lingue...                            


9 risposte

voti
37

Oleg Shilo C # soluzione Script (al The Code Project ) è davvero una grande introduzione a fornire capacità di script nella vostra applicazione.

Un approccio diverso sarebbe quella di considerare un linguaggio che è specificamente costruito per lo scripting, come IronRuby , IronPython , o Lua .

IronPython e IronRuby sono entrambi disponibili oggi.

Per una guida per l'incorporamento IronPython leggere Come incorporare il supporto di script IronPython nella vostra applicazione esistente in 10 semplici passi .

Lua è un linguaggio di scripting comunemente usato nei giochi. V'è un compilatore Lua per NET, disponibile da CodePlex - http://www.codeplex.com/Nua

Quella base di codice è un grande letto, se si vuole imparare a costruire un compilatore in .NET.

Un angolo di completamente differente è provare PowerShell . Ci sono numerosi esempi di embedding PowerShell in un'applicazione - qui è un progetto approfondito sul tema: Powershell Tunnel

Risposto il 02/08/2008 a 02:49
fonte dall'utente

voti
7

Potreste essere in grado di utilizzare IronRuby per questo.

Altrimenti sarei suggerisco di avere una directory in cui si posiziona assembly precompilati. Poi si potrebbe avere un punto di riferimento nel DB al gruppo e di classe, e utilizzare la reflection per caricare gli assembly corretto in fase di esecuzione.

Se davvero si vuole compilare in fase di esecuzione è possibile utilizzare la CodeDOM, allora si potrebbe utilizzare la reflection per caricare l'assembly dinamico. Articolo di MSDN che potrebbe aiutare .

Risposto il 02/08/2008 a 05:18
fonte dall'utente

voti
6

Se non si desidera utilizzare il DLR è possibile utilizzare Boo (che ha un interprete) o si può prendere in considerazione il progetto Script.NET (S #) su CodePlex . Con la soluzione Boo si può scegliere tra script compilati o tramite l'interprete, e Boo fa una bella linguaggio di scripting, ha una sintassi flessibile ed un linguaggio estensibile tramite la sua architettura aperta del compilatore. Script.NET sembra troppo bello, però, e si potrebbe facilmente estendere quella lingua così come la sua un progetto open source e utilizza un compilatore molto amichevole Generator ( Irony.net ).

Risposto il 06/08/2008 a 17:28
fonte dall'utente

voti
5

Sto utilizzando LuaInterface1.3 + Lua 5.0 per un 1.1 NET applicazione.

Il problema con Boo è che ogni volta si analizza / compilazione / eval il codice al volo, si crea un insieme di classi boo in modo da otterrete le perdite di memoria.

Lua nell'altra mano, non lo fa, quindi è molto molto stabile e funziona meraviglioso (posso passare gli oggetti da C # per Lua e indietro).

Finora non ho messo in PROD ancora, ma sembra molto promettente.

Ho avuto problemi di perdite di memoria in CODICE utilizzando LuaInterface + Lua 5.0 , quindi ho usato Lua 5.2 e collegato direttamente in C # con DllImport. Le perdite di memoria sono stati all'interno della libreria LuaInterface.

Lua 5.2: da http://luabinaries.sourceforge.net e http://sourceforge.net/projects/luabinaries/files/5.2/Windows%20Libraries/Dynamic/lua-5.2_Win32_dll7_lib.zip/download

Una volta che ho fatto questo, tutte le mie perdite di memoria erano scomparsi e la domanda è stata molto stabile.

Risposto il 17/07/2012 a 18:08
fonte dall'utente

voti
5

Io suggerirei usando LuaInterface come è pienamente attuato Lua, dove sembra che Nua non è completa e probabilmente non implementa alcune funzionalità molto utili (coroutine, ecc).

Se si desidera utilizzare alcuni dei moduli preconfezionati Lua fuori, io suggerirei di usare qualcosa sulla falsariga di 1.5.x in contrasto con la serie 2.x che costruisce il codice completamente gestito e non può esporre l'API C necessaria.

Risposto il 17/09/2008 a 02:41
fonte dall'utente

voti
5

È possibile utilizzare una qualsiasi delle lingue DLR, che forniscono un modo per ospitare davvero facilmente il proprio piattaforma di script. Tuttavia, non c'è bisogno di utilizzare un linguaggio di scripting per questo. Si potrebbe utilizzare C # e compilarlo con il provider codice C #. Finché si carica nel proprio AppDomain, è possibile caricare e scaricare al contenuto del vostro cuore.

Risposto il 02/08/2008 a 07:16
fonte dall'utente

voti
4

L'applicazione principale che mia divisione vende fa qualcosa di molto simile a fornire personalizzazioni client (il che significa che non posso postare qualsiasi fonte). Abbiamo un'applicazione C # che carica gli script VB.NET dinamici (anche se qualsiasi linguaggio .NET potrebbe essere facilmente sostenuto - VB è stato scelto perché la squadra di personalizzazione è venuto da un background ASP).

CodeDom Usando di .NET abbiamo compilare gli script dal database, utilizzando il VB CodeDomProvider(fastidiosamente il valore predefinito è .NET 2, se si desidera supportare 3,5 funzioni è necessario passare un dizionario con "CompilerVersion" = "v3.5" per il suo costruttore ). Utilizzare il CodeDomProvider.CompileAssemblyFromSourcemetodo per compilarlo (si può passare le impostazioni per forzarlo a compilare solo nella memoria.

Questo si tradurrebbe in centinaia di assemblee in memoria, ma si potrebbe mettere tutto il codice delle classi dinamiche insieme in un unico gruppo, e ricompilare l'intero lotto in caso di modifica. Questo ha il vantaggio che si potrebbe aggiungere una bandiera per compilare su disco con un progetto preliminare di bilancio per quando si sta testando, che consente di eseguire il debug attraverso il codice dinamico.

Risposto il 10/08/2008 a 16:24
fonte dall'utente

voti
4

Sì, ho pensato, ma presto ho capito che un altro Domain-Specific-Language (DSL) sarebbe un po 'troppo.

In sostanza, hanno bisogno di interagire con il mio gamestate in modi forse imprevedibili. Ad esempio, una scheda potrebbe avere una regola "Quando questa carte entrano in gioco, tutti i tuoi servitori non morti guadagnano +3 attacco contro nemici volanti, tranne quando il nemico è benedetto". Come giochi di carte collezionabili sono a turni, il gamestate Manager fuoco OnStageX eventi e lasciare che le carte modificano altre carte o il gamestate in qualunque modo le esigenze di carte.

Se cerco di creare una connessione DSL, devo implementare un piuttosto grande set di funzionalità e, eventualmente, in costante aggiornamento, che sposta i lavori di manutenzione ad un'altra parte senza realmente rimuoverlo.

Ecco perché ho voluto rimanere con un "vero e proprio" linguaggio .NET per essere essenzialmente in grado di sparare solo l'evento e lasciare che la carta di manipolare il gamestate in qualunque modo (entro i limiti della protezione dall'accesso di codice).

Risposto il 02/08/2008 a 00:49
fonte dall'utente

voti
3

La prossima versione di .NET (5.0?) Ha avuto un gran parlare di apertura del "compilatore come un servizio" che renderebbe le cose come la valutazione di script diretta possibile.

Risposto il 27/11/2010 a 03:12
fonte dall'utente

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more