c# - Ajout de fonctionnalités de script aux applications .NET

Translate

J'ai un petit jeu écrit en C #. Il utilise une base de données comme back-end. C'est unjeu de cartes à collectionner, et je voulais implémenter la fonction des cartes sous forme de script.

Ce que je veux dire, c'est que j'ai essentiellement une interface,ICard, qu'une classe de carte implémente (public class Card056: ICard) et qui contient la fonction appelée par le jeu.

Maintenant, pour rendre l'élément maintenable / modifiable, j'aimerais avoir la classe de chaque carte comme code source dans la base de données et la compiler essentiellement lors de la première utilisation. Donc, quand je dois ajouter / changer une carte, je vais juste l'ajouter à la base de données et dire à mon application de se rafraîchir, sans avoir besoin de déploiement d'assembly (d'autant plus que nous parlerions d'un assemblage par carte ce qui signifie des centaines d'assemblages) .

Est-ce possible? Enregistrez une classe à partir d'un fichier source, puis instanciez-la, etc.

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

Le langage est C # mais un bonus supplémentaire s'il est possible d'écrire le script dans n'importe quel langage .NET.

This question and all comments follow the "Attribution Required."

Toutes les réponses

Translate

La solution C # Script d'Oleg Shilo (sur The Code Project) est vraiment une excellente introduction pour fournir des capacités de script dans votre application.

Une approche différente consisterait à envisager un langage spécialement conçu pour les scripts, tel queFerRuby, IronPython, ouLua.

IronPython et IronRuby sont tous deux disponibles aujourd'hui.

Pour un guide sur l'intégration d'IronPython, lisezComment intégrer la prise en charge des scripts IronPython dans votre application existante en 10 étapes faciles.

Lua est un langage de script couramment utilisé dans les jeux. Il existe un compilateur Lua pour .NET, disponible sur CodePlex -http://www.codeplex.com/Nua

Cette base de code est une bonne lecture si vous souhaitez en savoir plus sur la création d'un compilateur dans .NET.

Un angle complètement différent est d'essayerPowerShell. Il existe de nombreux exemples d'intégration de PowerShell dans une application - voici un projet approfondi sur le sujet:Tunnel Powershell

La source
Translate

Vous pourrez peut-être utiliser IronRuby pour cela.

Sinon, je vous suggère d'avoir un répertoire dans lequel vous placez des assemblys précompilés. Ensuite, vous pouvez avoir une référence dans la base de données à l'assembly et à la classe, et utiliser la réflexion pour charger les assemblys appropriés au moment de l'exécution.

Si vous voulez vraiment compiler au moment de l'exécution, vous pouvez utiliser le CodeDOM, puis vous pouvez utiliser la réflexion pour charger l'assembly dynamique.Article de documentation Microsoft qui pourrait aider.

La source
Translate

Si vous ne souhaitez pas utiliser le DLR, vous pouvezutilisez Boo (qui a un interprète)ou vous pourriez envisagerle projet Script.NET (S #) sur CodePlex. Avec la solution Boo, vous pouvez choisir entre des scripts compilés ou utiliser l'interpréteur, et Boo fait un joli langage de script, a une syntaxe flexible et un langage extensible via son architecture de compilateur ouverte. Script.NET a l'air bien aussi, cependant, et vous pouvez facilement étendre ce langage ainsi que son projet open source et utiliser un générateur de compilateur très convivial (Irony.net).

La source
Translate

Vous pouvez utiliser n'importe lequel des langages DLR, qui offrent un moyen d'héberger très facilement votre propre plate-forme de script. Cependant, vous n'êtes pas obligé d'utiliser un langage de script pour cela. Vous pouvez utiliser C # et le compiler avec le fournisseur de code C #. Tant que vous le chargez dans son propre AppDomain, vous pouvez le charger et le décharger à votre guise.

La source
Translate

Je suggérerais d'utiliserLuaInterfacecar il a entièrement implémenté Lua où il semble que Nua n'est pas complet et n'implémente probablement pas certaines fonctionnalités très utiles (coroutines, etc.).

Si vous souhaitez utiliser certains des modules Lua préemballés à l'extérieur, je vous suggère d'utiliser quelque chose du type 1.5.x par opposition à la série 2.x qui construit du code entièrement géré et ne peut pas exposer l'API C nécessaire.

La source
Translate

J'utilise LuaInterface1.3 + Lua 5.0 pour une application NET 1.1.

Le problème avec Boo est que chaque fois que vous analysez / compilez / évaluez votre code à la volée, cela crée un ensemble de classes boo afin que vous obteniez des fuites de mémoire.

Lua en revanche ne fait pas ça, donc c'est très très stable et fonctionne à merveille (je peux passer des objets de C # à Lua et inversement).

Jusqu'à présent, je ne l'ai pas encore mis dans PROD, mais cela semble très prometteur.

J'ai eu des problèmes de fuites de mémoire dans PROD en utilisant LuaInterface + Lua 5.0, j'ai donc utilisé Lua 5.2 et lié directement en C # avec DllImport.Les fuites de mémoire se trouvaient à l'intérieur de la bibliothèque LuaInterface.

Lua 5.2: à partir dehttp://luabinaries.sourceforge.netethttp://sourceforge.net/projects/luabinaries/files/5.2/Windows%20Libraries/Dynamic/lua-5.2_Win32_dll7_lib.zip/download

Une fois que j'ai fait cela, toutes mes fuites de mémoire avaient disparu et l'application était très stable.

La source
Translate

L'application principale que ma division vend fait quelque chose de très similaire pour fournir des personnalisations aux clients (ce qui signifie que je ne peux publier aucune source). Nous avons une application C # qui charge des scripts VB.NET dynamiques (bien que n'importe quel langage .NET puisse être facilement pris en charge - VB a été choisi car l'équipe de personnalisation est issue d'un arrière-plan ASP).

En utilisant le CodeDom de .NET, nous compilons les scripts à partir de la base de données, en utilisant le VBCodeDomProvider(ennuyeux, il est par défaut .NET 2, si vous voulez prendre en charge les fonctionnalités 3.5, vous devez passer un dictionnaire avec "CompilerVersion" = "v3.5" à son constructeur). Utilisez leCodeDomProvider.CompileAssemblyFromSourcepour le compiler (vous pouvez passer des paramètres pour le forcer à se compiler en mémoire uniquement.

Cela entraînerait des centaines d'assemblys en mémoire, mais vous pourriez rassembler tout le code des classes dynamiques dans un seul assembly et recompiler le tout en cas de changement. Cela présente l'avantage que vous pouvez ajouter un indicateur pour compiler sur le disque avec unPDBlorsque vous testez, vous permettant de déboguer via le code dynamique.

La source
Translate

Oui, j'y ai pensé, mais j'ai vite compris qu'un autre langage DSL (Domain-Specific-Language) serait un peu trop.

Essentiellement, ils doivent interagir avec mon domaine de jeu de manière éventuellement imprévisible. Par exemple, une carte pourrait avoir une règle "Quand ces cartes entrent en jeu, tous vos serviteurs morts-vivants gagnent +3 d'attaque contre les ennemis volants, sauf lorsque l'ennemi est béni". Comme les jeux de cartes à collectionner sont au tour par tour, le GameState Manager déclenchera les événements OnStageX et laissera les cartes modifier d'autres cartes ou le GameState de la manière dont la carte a besoin.

Si j'essaie de créer un DSL, je dois implémenter un ensemble de fonctionnalités assez volumineux et éventuellement le mettre à jour constamment, ce qui déplace le travail de maintenance vers une autre partie sans la supprimer.

C'est pourquoi j'ai voulu rester avec un "vrai" langage .NET pour pouvoir essentiellement déclencher l'événement et laisser la carte manipuler le gamestate de quelque manière que ce soit (dans les limites de la sécurité d'accès au code).

La source
Translate

La prochaine version de .NET (5.0?) A beaucoup parlé d'ouvrir le "compilateur en tant que service" qui rendrait possible des choses comme l'évaluation directe des scripts.

La source