Legge skripting funksjonalitet til .NET applikasjoner

stemmer
63

Jeg har en liten lek skrevet i C #. Den bruker en database som back-end. Det er et samlekortspill , og jeg ønsket å gjennomføre funksjon av kortene som et skript.

Det jeg mener er at jeg egentlig har et grensesnitt, ICardsom en kort klassen implementerer ( public class Card056 : ICard) og som inneholder funksjon som kalles av spillet.

Nå, for å gjøre ting vedlikeholds / moddable, vil jeg gjerne ha klasse for hvert kort som kildekode i databasen og i hovedsak kompilere den ved første gangs bruk. Så når jeg må legge til / endre et kort, vil jeg bare legge det til databasen og fortelle min søknad for å oppdatere, uten behov for montering distribusjon (spesielt siden vi ville være snakk om en montasje per kort som betyr hundrevis av forsamlinger) .

Er det mulig? Registrere en klasse fra en kilde fil og deretter instantiate det, etc.

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

Språket er C #, men ekstra bonus hvis det er mulig å skrive manuset i enhver NET språk.

Publisert på 01/08/2008 klokken 23:22
kilden bruker
På andre språk...                            


9 svar

stemmer
38

Oleg Shilo C # Script løsning (på koden Prosjekt ) er virkelig en flott introduksjon til å gi script evner i programmet.

En annen tilnærming ville være å vurdere et språk som er spesielt bygget for skripting, som IronRuby , Ironpython , eller Lua .

Ironpython og IronRuby er begge tilgjengelige i dag.

For en guide til å bygge Ironpython lese Hvordan legge Ironpython script støtte i den eksisterende app i 10 enkle trinn .

Lua er et skriptspråk som vanligvis brukes i spill. Det er en Lua kompilator for .NET, tilgjengelig fra CodePlex - http://www.codeplex.com/Nua

Det kodebasen er en stor lese hvis du ønsker å lære om å bygge en kompilator i .NET.

En annen vinkel helt er å prøve Powershell . Det finnes mange eksempler på å bygge Powershell inn en søknad - her er en grundig prosjekt om emnet: Powershell Tunnel

Svarte 02/08/2008 kl. 01:49
kilden bruker

stemmer
8

Du kan være i stand til å bruke IronRuby for det.

Ellers vil jeg foreslå at du har en katalog der du plasserer ferdigbygd forsamlinger. Da kan du ha en referanse i DB til montering og klasse, og bruke refleksjon til å laste riktig forsamlinger under kjøring.

Hvis du virkelig ønsker å kompilere på kjøre-tid du kunne bruke CodeDOM, så kan du bruke refleksjon til å laste den dynamiske forsamlingen. MSDN-artikkelen som kan hjelpe .

Svarte 02/08/2008 kl. 04:18
kilden bruker

stemmer
6

Hvis du ikke ønsker å bruke DLR du kan bruke Boo (som har en tolk) , eller du kan vurdere den Script.NET (S #) prosjektet på CodePlex . Med Boo løsningen kan du velge mellom kompilerte skript eller bruke tolk, og Boo gjør en fin skriptspråk, har en fleksibel syntaks og en utvidbar språk via sin åpne kompilatoren arkitektur. Script.NET ser fin også, skjønt, og du kan enkelt utvide det språket samt sin åpen kildekode og bruker en meget vennlig Compiler Generator ( Irony.net ).

Svarte 06/08/2008 kl. 16:28
kilden bruker

stemmer
6

Du kan bruke noen av DLR språk, som gir en måte å virkelig lett vert for ditt eget skript plattform. Men du trenger ikke å bruke et skriptspråk for dette. Du kan bruke C # og kompilere den med C # -kode leverandør. Så lenge du legger det i sin egen AppDomain, kan du laste og losse den til ditt hjerte innhold.

Svarte 02/08/2008 kl. 06:16
kilden bruker

stemmer
5

Jeg bruker LuaInterface1.3 + Lua 5.0 for en NET 1.1 søknad.

Problemet med Boo er at hver gang du analysere / kompilere / eval din kode på fly, skaper det et sett med boo klasser slik at du får minnelekkasjer.

Lua i den andre hånden, ikke gjør det, så det er veldig veldig stabil og fungerer fantastisk (jeg kan passere gjenstander fra C # til Lua og bakover).

Så langt har jeg ikke sette den i VARE ennå, men virker veldig lovende.

Jeg hadde minnelekkasjer problemstillinger i VARE hjelp LuaInterface + Lua 5.0 , derfor brukte jeg Lua 5,2 og knyttet direkte til C # med DllImport. De minnelekkasjer var inne LuaInterface biblioteket.

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

Når jeg gjorde dette, ble alle mine minnelekkasjer borte og programmet var veldig stabil.

Svarte 17/07/2012 kl. 17:08
kilden bruker

stemmer
5

Jeg vil foreslå å bruke LuaInterface som den har fullt implementert Lua der det ser ut til at Nua er ikke komplett, og sannsynligvis ikke gjennomføre noen veldig nyttig funksjonalitet (coroutines, etc).

Hvis du ønsker å bruke noen av de utenfor ferdigpakkede Lua moduler, vil jeg foreslå å bruke noe langs linjene av 1.5.x i motsetning til 2.x-serien som bygger fullt forvaltet kode, og kan ikke utsette den nødvendige C API.

Svarte 17/09/2008 kl. 01:41
kilden bruker

stemmer
5

Ja, jeg tenkte på det, men jeg snart fant ut at en annen Domain-Specific-språk (DSL) ville være litt for mye.

I hovedsak, de trenger å samhandle med min gamestate i muligens uforutsigbare måter. For eksempel kan et kort har en regel "Når denne kortene angir spill, alle vandøde undersåtter få tre angrep mot flygende fiender, unntatt når fienden er velsignet". Som trading kortspill er tur-basert, vil GameState leder brann OnStageX hendelser og la kortene endre andre kortene eller GameState på den måten kort behov.

Hvis jeg prøver å opprette en DSL, må jeg gjennomføre en ganske stor funksjon sett og muligens kontinuerlig oppdatere den, som skifter vedlikeholdsarbeidet til en annen del uten faktisk å fjerne den.

Det er derfor jeg ønsket å bo med en "ekte" .NET språk til å hovedsaklig være i stand til å bare fyre av hendelsen og la kortet manipulere gamestate på den måten (innenfor rammene av tilgangssikkerhetskode).

Svarte 01/08/2008 kl. 23:49
kilden bruker

stemmer
4

Det viktigste programmet at min avdeling selger gjør noe lignende for å gi kundens tilpasninger (som betyr at jeg ikke kan legge inn noen kilde). Vi har en C # applikasjon som laster dynamiske VB.NET skript (selv om noen NET språk kan lett bli støttet - VB ble valgt fordi tilpasning teamet kom fra en ASP bakgrunn).

Ved hjelp av .NET sin CodeDom vi kompilere scriptene fra databasen ved hjelp av VB CodeDomProvider(annoyingly den velger NET 2, hvis du ønsker å støtte 3,5 funksjonene du trenger for å passere en ordbok med "CompilerVersion" = "v3.5" til sin konstruktør ). Bruk CodeDomProvider.CompileAssemblyFromSourcemetode for å kompilere den (du kan passere innstillinger for å tvinge den til å kompilere i minne.

Dette vil resultere i hundrevis av forsamlinger i minne, men du kan sette alle de dynamiske klasser kode sammen til en enkelt enhet, og rekompilere hele mye når noen endring. Dette har den fordelen at du kan legge til et flagg å kompilere på disken med en PDB for når du tester, slik at du kan feilsøke gjennom dynamisk kode.

Svarte 10/08/2008 kl. 15:24
kilden bruker

stemmer
3

Den neste versjonen av .NET (5.0?) Har hatt mye snakk om å åpne "kompilatoren som en tjeneste" som ville gjøre ting som direkte script evaluering mulig.

Svarte 27/11/2010 kl. 02:12
kilden bruker

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