Agregar funcionalidad de scripting a aplicaciones .NET

Tengo un pequeño juego escrito en C #. Utiliza una base de datos como back-end. Es un juego de cartas coleccionables , y quería implementar la función de las cartas como un guión.

Lo que quiero decir es que esencialmente tengo una interfaz, ICard , que implementa una clase de tarjeta ( public class Card056 : ICard ) y que contiene funciones que son llamadas por el juego.

Ahora, para hacer que la cosa sea mantenible / modificable, me gustaría tener la clase para cada tarjeta como código fuente en la base de datos y básicamente comstackrla en el primer uso. Entonces, cuando tengo que agregar / cambiar una tarjeta, simplemente la agrego a la base de datos y le digo a mi aplicación que actualice, sin necesidad de ninguna implementación de ensamblaje (especialmente porque estaríamos hablando de 1 ensamblado por tarjeta, lo que significa cientos de ensamblajes) .

¿Es eso posible? Registre una clase de un archivo fuente y luego ejecútelo, etc.

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

El lenguaje es C # pero una bonificación adicional si es posible escribir el guión en cualquier idioma .NET.

La solución C # Script de Oleg Shilo (en The Code Project ) realmente es una gran introducción para proporcionar habilidades de script en su aplicación.

Un enfoque diferente sería considerar un lenguaje específicamente creado para scripting, como IronRuby , IronPython o Lua .

IronPython e IronRuby están disponibles hoy.

Para obtener una guía sobre cómo incrustar IronPython, lea Cómo integrar el soporte de script de IronPython en su aplicación existente en 10 sencillos pasos .

Lua es un lenguaje de scripting comúnmente utilizado en juegos. Existe un comstackdor Lua para .NET, disponible en CodePlex – http://www.codeplex.com/Nua

Esa base de código es una gran lectura si quieres aprender a comstackr un comstackdor en .NET.

Un ángulo diferente en conjunto es probar PowerShell . Hay numerosos ejemplos de incorporación de PowerShell en una aplicación: aquí hay un proyecto completo sobre el tema: Powershell Tunnel

Es posible que pueda usar IronRuby para eso.

De lo contrario, te sugiero que tengas un directorio donde coloques ensambles precomstackdos. Entonces podría tener una referencia en el DB para el ensamblaje y la clase, y usar el reflection para cargar los ensamblajes apropiados en el tiempo de ejecución.

Si realmente desea comstackr en tiempo de ejecución, podría usar el CodeDOM, entonces podría usar el reflection para cargar el ensamblaje dynamic. Artículo de MSDN que podría ayudar .

Puede usar cualquiera de los lenguajes DLR, que proporcionan una forma de alojar fácilmente su propia plataforma de scripting. Sin embargo, no tiene que usar un lenguaje de scripting para esto. Podría usar C # y comstackrlo con el proveedor del código C #. Siempre y cuando lo cargue en su propio Dominio de aplicación, puede cargarlo y descargarlo a su gusto.

Si no desea usar el DLR, puede usar Boo (que tiene un intérprete) o puede considerar el proyecto Script.NET (S #) en CodePlex . Con la solución Boo puede elegir entre scripts comstackdos o usar el intérprete, y Boo crea un buen lenguaje de scripting, tiene una syntax flexible y un lenguaje extensible a través de su architecture de comstackción abierta. Script.NET también se ve bien, y se puede ampliar fácilmente ese idioma, así como es un proyecto de código abierto y utiliza un generador de comstackdores muy amigable ( Irony.net ).

Sugiero usar LuaInterface, ya que ha implementado Lua por completo, donde parece que Nua no está completo y es probable que no implemente algunas funciones muy útiles (corutinas, etc.).

Si desea utilizar algunos de los módulos Lua preenvasados ​​externos, le sugiero que use algo similar a 1.5.x en comparación con la serie 2.x que crea código completamente administrado y no puede exponer la API C necesaria.

Sí, pensé en eso, pero pronto descubrí que otro Dominio Específico del Dominio (DSL) sería demasiado.

Esencialmente, necesitan interactuar con mi sistema de juego de formas posiblemente impredecibles. Por ejemplo, una carta podría tener una regla: “Cuando estas cartas entran en juego, todos tus súbditos no-muertos ganan +3 ataques contra enemigos voladores, excepto cuando el enemigo es bendecido”. Como los juegos de cartas coleccionables se basan en turnos, GameState Manager activará eventos de OnStageX y permitirá que las cartas modifiquen otras tarjetas o GameState de la forma que la tarjeta necesite.

Si trato de crear una DSL, tengo que implementar un conjunto de características bastante grande y posiblemente actualizarlo constantemente, lo que cambia el trabajo de mantenimiento a otra parte sin eliminarlo realmente.

Es por eso que quería quedarme con un lenguaje .NET “real” para poder simplemente activar el evento y dejar que la tarjeta manipule el estado del juego de cualquier forma (dentro de los límites de la seguridad de acceso al código).

Estoy usando LuaInterface1.3 + Lua 5.0 para una aplicación NET 1.1.

El problema con Boo es que cada vez que analiza / comstack / evalúa su código sobre la marcha, crea un conjunto de clases de boo para que tenga pérdidas de memoria.

Lua, por otro lado, no hace eso, así que es muy estable y funciona maravilloso (puedo pasar objetos de C # a Lua y viceversa).

Hasta ahora no lo he puesto en PROD todavía, pero parece muy prometedor.

Tuve problemas de pérdida de memoria en PROD usando LuaInterface + Lua 5.0 , por lo tanto, utilicé Lua 5.2 y me vinculé directamente a C # con DllImport. Las pérdidas de memoria estaban dentro de la biblioteca LuaInterface.

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

Una vez que hice esto, todas las pérdidas de memoria se habían ido y la aplicación era muy estable.

La aplicación principal que vende mi división hace algo muy similar para proporcionar personalizaciones del cliente (lo que significa que no puedo publicar ninguna fuente). Tenemos una aplicación C # que carga scripts VB.NET dynamics (aunque cualquier lenguaje .NET podría ser fácilmente compatible, se eligió VB porque el equipo de personalización provenía de un fondo ASP).

Usando CodeDom de .NET, comstackmos los scripts de la base de datos, usando el VB CodeDomProvider (molestamente, por defecto, es .NET 2, si quieres soportar las características 3.5 necesitas pasar un diccionario con “CompilerVersion” = “v3.5” a su constructor). Utilice el método CodeDomProvider.CompileAssemblyFromSource para comstackrlo (puede pasar configuraciones para forzarlo a comstackr solo en la memoria).

Esto daría como resultado cientos de ensamblajes en la memoria, pero podría poner todo el código de las clases dinámicas juntas en un solo ensamblaje, y recomstackr todo cuando se produzca algún cambio. Esto tiene la ventaja de que puede agregar un indicador para comstackr en el disco con un PDB para cuando está probando, lo que le permite depurar a través del código dynamic.

La próxima versión de .NET (5.0?) Se ha hablado mucho acerca de abrir el “comstackdor como servicio”, lo que haría posible la evaluación directa de los scripts.