Voeg skripfunksionaliteit by .NET-toepassings

Question

Ek het 'n speletjie wat in C# geskryf is.Dit gebruik 'n databasis as back-end.Dit is 'n handel kaart spel, en ek wou die funksie van die kaarte as 'n skrif implementeer.

Wat ek bedoel is dat ek in wese 'n koppelvlak het, ICard, wat 'n kaartklas implementeer (public class Card056: ICard) en wat funksie bevat wat deur die speletjie aangeroep word.

Nou, om die ding onderhoubaar/moddabel te maak, wil ek graag die klas vir elke kaart as bronkode in die databasis hê en dit in wese saamstel met die eerste gebruik.So wanneer ek 'n kaart moet byvoeg/verander, sal ek dit net by die databasis voeg en my toepassing vertel om te verfris, sonder om enige samestelling-ontplooiing nodig te hê (veral aangesien ons van 1 samestelling per kaart sou praat, wat honderde samestellings beteken) .

Is dit moontlik?Registreer 'n klas vanaf 'n bronlêer en instansieer dit dan, ens.

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

Die taal is C# maar ekstra bonus as dit moontlik is om die skrif in enige .NET taal te skryf.

Answer 1

Oleg Shilo se C# Script-oplossing (by The Code Project) is regtig 'n goeie inleiding tot die verskaffing van skrifvermoëns in jou toepassing.

'n Ander benadering sou wees om 'n taal te oorweeg wat spesifiek vir scripting gebou is, soos YsterRuby, IronPython, of Lua.

IronPython en IronRuby is albei vandag beskikbaar.

Lees vir 'n gids vir die inbedding van IronPythonHoe om IronPython-skrifondersteuning in u bestaande toepassing in te sluit in 10 maklike stappe.

Lua is 'n skriftaal wat algemeen in speletjies gebruik word.Daar is 'n Lua-samesteller vir .NET, beskikbaar vanaf CodePlex -- http://www.codeplex.com/Nua

Daardie kodebasis is 'n goeie leesstof as jy wil leer oor die bou van 'n samesteller in .NET.

'n Ander hoek is om te probeer PowerShell.Daar is talle voorbeelde van die inbedding van PowerShell in 'n toepassing - hier is 'n deeglike projek oor die onderwerp:Powershell-tonnel

Answer 2

Jy kan dalk IronRuby daarvoor gebruik.

Andersins stel ek voor dat jy 'n gids het waar jy vooraf saamgestelde samestellings plaas.Dan kan jy 'n verwysing in die DB hê na die samestelling en klas, en refleksie gebruik om die regte samestellings tydens looptyd te laai.

As jy regtig wil saamstel tydens looptyd, kan jy die CodeDOM gebruik, dan kan jy refleksie gebruik om die dinamiese samestelling te laai. Microsoft dokumentasie artikel wat dalk kan help.

Answer 3

As jy nie die DLR wil gebruik nie, kan jy gebruik Boo (wat 'n tolk het) of jy kan dit oorweeg die Script.NET (S#)-projek op CodePlex.Met die Boo-oplossing kan jy kies tussen saamgestelde skrifte of die gebruik van die tolk, en Boo maak 'n lekker skriftaal, het 'n buigsame sintaksis en 'n uitbreidbare taal via sy oop samesteller-argitektuur.Script.NET lyk egter ook mooi, en jy kan maklik daardie taal uitbrei sowel as 'n oopbronprojek en gebruik 'n baie vriendelike samestellergenerator (Irony.net).

Answer 4

U kan enige van die DLR-tale gebruik, wat 'n manier bied om u eie skrifplatform regtig maklik te huisves.U hoef egter nie 'n skriftaal hiervoor te gebruik nie.Jy kan C# gebruik en dit saamstel met die C#-kodeverskaffer.Solank jy dit in sy eie AppDomain laai, kan jy dit na hartelus laai en aflaai.

Answer 5

Ek stel voor om Lua-koppelvlak aangesien dit Lua volledig geïmplementeer het waar dit blyk dat Nua nie volledig is nie en waarskynlik nie 'n paar baie nuttige funksionaliteit (coroutines, ens.) implementeer nie.

As jy van die buite-voorverpakte Lua-modules wil gebruik, stel ek voor dat jy iets in die lyn van 1.5.x gebruik in teenstelling met die 2.x-reeks wat volledig bestuurde kode bou en nie die nodige C API kan blootstel nie.

Answer 6

Ek gebruik LuaInterface1.3 + Lua 5.0 vir 'n NET 1.1-toepassing.

Die probleem met Boo is dat elke keer as jy jou kode dadelik ontleed/saamstel/evalueer, dit 'n stel boo-klasse skep sodat jy geheuelekkasies sal kry.

Lua, aan die ander kant, doen dit nie, so dit is baie baie stabiel en werk wonderlik (ek kan voorwerpe van C# na Lua en agtertoe stuur).

Tot dusver het ek dit nog nie in PROD gesit nie, maar dit lyk baie belowend.

Ek het probleme met geheuelekkasies in PROD gehad met LuaInterface + Lua 5.0, daarom het ek Lua 5.2 gebruik en direk na C# gekoppel met DllImport. Die geheuelekkasies was binne die LuaInterface-biblioteek.

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

Sodra ek dit gedoen het, was al my geheuelekkasies weg en die toepassing was baie stabiel.

Answer 7

Die hooftoepassing wat my afdeling verkoop, doen iets baie soortgelyk om kliëntaanpassings te verskaf (wat beteken dat ek geen bron kan plaas nie).Ons het 'n C#-toepassing wat dinamiese VB.NET-skrifte laai (alhoewel enige .NET-taal maklik ondersteun kan word - VB is gekies omdat die aanpassingspan uit 'n ASP-agtergrond gekom het).

Met behulp van .NET se CodeDom stel ons die skrifte saam vanaf die databasis, met behulp van die VB CodeDomProvider (dit is irriterend genoeg, dit is verstek na .NET 2, as jy 3.5-kenmerke wil ondersteun, moet jy 'n woordeboek met "CompilerVersion" = "v3.5" aan sy konstruktor deurgee).Gebruik die CodeDomProvider.CompileAssemblyFromSource metode om dit saam te stel (jy kan instellings deurgee om dit te dwing om slegs in die geheue saam te stel.

Dit sal honderde samestellings in die geheue tot gevolg hê, maar jy kan al die dinamiese klasse se kode saamvoeg in 'n enkele samestelling, en die hele lot hersaamstel wanneer enige verandering.Dit het die voordeel dat jy 'n vlag kan byvoeg om op skyf saam te stel met 'n VOB vir wanneer jy toets, wat jou toelaat om deur die dinamiese kode te ontfout.

Answer 8

Ja, ek het daaroor gedink, maar ek het gou agtergekom dat 'n ander domein-spesifieke-taal (DSL) 'n bietjie te veel sou wees.

In wese moet hulle op moontlike onvoorspelbare maniere met my gamestate interaksie hê.Byvoorbeeld, 'n kaart kan 'n reël hê "Wanneer hierdie kaarte speel, kry al jou dooies volgelinge +3 aanval teen vlieënde vyande, behalwe wanneer die vyand geseën is".Aangesien handelskaartspeletjies op die beurt gebaseer is, sal die GameState-bestuurder OnStageX-geleenthede afvuur en die kaarte ander kaarte of die GameState laat verander op watter manier die kaart ook al benodig.

As ek probeer om 'n DSL te skep, moet ek 'n taamlik groot kenmerkstel implementeer en dit moontlik voortdurend bywerk, wat die instandhoudingswerk na 'n ander deel verskuif sonder om dit eintlik te verwyder.

Dit is hoekom ek by 'n "regte" .NET-taal wou bly om in wese net die gebeurtenis te kan afvuur en die kaart die spelstatus op watter manier ook al te laat manipuleer (binne die grense van die kodetoegangssekuriteit).

Answer 9

Die volgende weergawe van .NET (5.0?) het baie gepraat oor die opening van die "samesteller as 'n diens" wat dinge soos direkte skrif-evaluering moontlik sou maak.