Het toevoegen van scripting functionaliteit voor .NET applicaties

stemmen
62

Ik heb een beetje spel geschreven in C #. Het maakt gebruik van een database als back-end. Het is een trading card game , en ik wilde om de functie van de kaarten als een script uit te voeren.

Wat ik bedoel is dat ik in wezen een interface, ICarddie een kaart klasse implementeert ( public class Card056 : ICard) en welke functie die worden opgeroepen door het spel bevat.

Nu, om het ding te onderhouden / moddable te maken, zou ik graag de klasse voor elke kaart als broncode in de database en in wezen compileren bij het eerste gebruik. Dus als ik moet toevoegen / wijzigen van een kaart, zal ik gewoon toe te voegen aan de database en vertel mijn applicatie op te frissen, zonder enige montage inzet (vooral omdat we zouden per kaart die honderden vergaderingen betekent praten over 1 assemblage) .

Is dat mogelijk? Registreer een klasse van een bron bestand en vervolgens instantiëren, etc.

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

De taal is C #, maar extra bonus als het mogelijk is om het script te schrijven in een .NET-taal.

De vraag is gesteld op 02/08/2008 om 00:22
bron van user
In andere talen...                            


9 antwoorden

stemmen
4

Ja, dacht ik dat, maar ik heb al snel ontdekt dat een andere Domain-Specific-Language (DSL) een beetje te veel zou zijn.

In wezen, die ze nodig hebben om te communiceren met mijn gamestate in mogelijk onvoorspelbare manieren. Zo kan bijvoorbeeld een kaart hebben in de regel "Wanneer deze kaarten in te voeren spel, al uw ondoden minions krijgen +3 aanval tegen vliegende vijanden, behalve wanneer de vijand is gezegend". Zoals trading card games zijn turn-based, zal de gamestate Manager brand OnStageX evenementen en laat de kaarten aan te passen andere kaarten of de gamestate op welke manier de kaart nodig heeft.

Als ik probeer om een ​​DSL te maken, ik heb een vrij grote feature set uit te voeren en eventueel constant updaten, waardoor het onderhoud verschuift naar een ander deel zonder daadwerkelijk te verwijderen.

Dat is waarom ik wilde verblijven met een "echte" .NET-taal in wezen in staat zijn om gewoon ontslaan het evenement en laat de kaart te manipuleren de gamestate op welke manier (binnen de grenzen van de code toegang beveiliging).

antwoordde op 02/08/2008 om 00:49
bron van user

stemmen
37

Oleg Shilo's C # Script-oplossing (in The Code Project ) is echt een geweldige introductie tot het verstrekken script mogelijkheden in uw toepassing.

Een andere benadering zou zijn om een taal die specifiek is gebouwd voor scripting, zoals overwegen IronRuby , IronPython of Lua .

IronPython en IronRuby zijn beide beschikbaar vandaag.

Voor een gids voor het inbedden lezen IronPython Hoe IronPython script ondersteuning insluiten in uw bestaande app in 10 eenvoudige stappen .

Lua is een scripttaal die vaak gebruikt in games. Er is een Lua compiler voor .NET, verkrijgbaar bij CodePlex - http://www.codeplex.com/Nua

Dat codebase is een geweldige lezen als je meer wilt weten over het bouwen van een compiler in .NET.

Een heel andere kant is om te proberen PowerShell . Er zijn talloze voorbeelden van het inbedden van PowerShell in een toepassing - is hier een gedegen project over het onderwerp: Powershell Tunnel

antwoordde op 02/08/2008 om 02:49
bron van user

stemmen
7

Je zou in staat zijn om IronRuby voor dat gebruiken.

Anders zou ik stel voor dat je een map waar u voorgecompileerde assemblages plaatsen. Dan kun je een referentie in de DB met de assemblage en klasse, en het gebruik van reflectie om de juiste samenstellingen bij runtime te laden.

Als je echt wilt samenstellen op run-time kon je de CodeDom gebruiken, dan kun je ideeën te gebruiken om de dynamische montage te laden. MSDN artikel dat zou kunnen helpen .

antwoordde op 02/08/2008 om 05:18
bron van user

stemmen
5

Je kon een van de DLR talen, die een manier om echt gemakkelijk hosten van uw eigen scripting-platform te gebruiken. Echter, hoeft u niet naar een scripttaal te gebruiken voor dit. Je zou kunnen gebruiken C # en het compileren met de C # code provider. Zolang je het te laden in zijn eigen AppDomain, kunt u laden en lossen aan de inhoud van uw hart.

antwoordde op 02/08/2008 om 07:16
bron van user

stemmen
6

Als u niet wilt dat de DLR gebruikt, kunt u Boo gebruiken (die een tolk heeft) of dat u zou kunnen overwegen het project Script.NET (S #) op CodePlex . Met de Boo oplossing kunt u kiezen tussen gecompileerde scripts of met behulp van de tolk en Boo maakt een leuke scripttaal, heeft een flexibele syntax en een uitbreidbare taal via de open compiler architectuur. Script.NET ziet er ook leuk, hoewel, en je kon gemakkelijk uit te breiden die taal evenals zijn een open source project en maakt gebruik van een zeer vriendelijke Compiler Generator ( Irony.net ).

antwoordde op 06/08/2008 om 17:28
bron van user

stemmen
4

De belangrijkste toepassing die mijn divisie verkoopt doet iets vergelijkbaars als klant maatwerk te bieden (wat betekent dat ik elke bron niet kan plaatsen). We hebben een C # applicatie die dynamische VB.NET scripts laadt (hoewel elke .NET taal gemakkelijk kunnen worden ondersteund - VB werd gekozen omdat het op maat team kwam uit een ASP-achtergrond).

Met behulp van NET CodeDom we compileren de scripts uit de database, met behulp van de VB CodeDomProvider(hinderlijk wordt standaard .NET 2, als je wilt tot 3,5 functies te ondersteunen die u nodig hebt om een woordenboek pas met "CompilerVersion" = "v3.5" om de constructor ). Gebruik de CodeDomProvider.CompileAssemblyFromSourcemethode om het te compileren (u kunt de instellingen overgaan om het te dwingen om alleen te compileren in het geheugen.

Dit zou resulteren in honderden vergaderingen in het geheugen, maar je kon alle dynamische klassen code samen in één vergadering te zetten, en opnieuw compileren van de gehele partij als enige verandering. Dit heeft als voordeel dat je een vlag zou kunnen toevoegen om te compileren op de harde schijf met een VOB voor als u test, zodat u debuggen door de dynamische code.

antwoordde op 10/08/2008 om 16:24
bron van user

stemmen
5

Ik stel voor het gebruik van LuaInterface als deze volledig is geïmplementeerd Lua wanneer blijkt dat Nua niet volledig is en waarschijnlijk niet uit te voeren een aantal zeer nuttige functionaliteit (coroutines, etc).

Als u wilt wat van de buitenwereld voorverpakte Lua modules te gebruiken, zou ik stel met behulp van iets in de trant van 1.5.x in tegenstelling tot de 2.x serie die volledig beheerde code bouwt en kan de noodzakelijke C API niet bloot.

antwoordde op 17/09/2008 om 02:41
bron van user

stemmen
3

De volgende versie van .NET (5.0?) Heeft een veel gepraat over het openen van de "compiler as a service", die zaken als directe script evaluatie mogelijk zou maken gehad.

antwoordde op 27/11/2010 om 03:12
bron van user

stemmen
5

Ik gebruik LuaInterface1.3 + Lua 5.0 voor een NET 1.1 applicatie.

Het probleem met Boo is dat elke keer dat je / compile / eval uw code te parsen on the fly, creëert het een set van boo klassen, zodat u geheugenlekken krijgt.

Lua in de andere hand, doet dat niet, dus het is heel erg stabiel en werkt geweldig (ik kan objecten van C # passeren Lua en naar achteren).

Tot dusver heb ik het niet in PROD nog niet, maar het lijkt veelbelovend.

Ik had geheugenlekkages kwesties PROD gebruik LuaInterface Lua + 5,0 Daarom heb ik Lua 5.2 en is rechtstreeks gekoppeld aan C # met DllImport. De geheugenlekken waren in de LuaInterface bibliotheek.

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

Zodra ik dit deed, werden al mijn geheugenlekken verdwenen en de toepassing was zeer stabiel.

antwoordde op 17/07/2012 om 18:08
bron van user

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