Ajout d'une fonctionnalité de script pour les applications .NET

voix
62

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

Ce que je veux dire est que j'ai essentiellement une interface, ICardqui met en œuvre une classe de carte ( public class Card056 : ICard) et qui contient la fonction qui sont appelés par le jeu.

Maintenant, pour faire la chose maintenable / moddable, je voudrais avoir la classe pour chaque carte sous forme de code source dans la base de données et compiler essentiellement sur la première utilisation. Alors, quand je dois ajouter / changer une carte, je vais l'ajouter à la base de données et dire à mon application rafraichir, sans avoir besoin de déploiement d'assemblage (d'autant plus que nous parlerions 1 assemblage par carte ce qui signifie des centaines d'ensembles) .

Est-ce possible? Enregistrez-vous une classe à partir d'un fichier source et instancier puis, etc.

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

La langue est C # mais bonus supplémentaire s'il est possible d'écrire le script dans toutes les langues .NET.

Créé 02/08/2008 à 00:22
source utilisateur
Dans d'autres langues...                            


9 réponses

voix
37

Oleg Shilo C de la solution # Script (le code du projet ) est vraiment une excellente introduction à fournir des capacités de script dans votre application.

Une autre approche serait de considérer une langue qui est construite spécifiquement pour les scripts, tels que IronRuby , IronPython ou Lua .

IronPython et IronRuby sont tous deux disponibles aujourd'hui.

Pour un guide pour l' intégration IronPython lire Comment intégrer le soutien de script IronPython dans votre application existante en 10 étapes faciles .

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

Ce code de base est une lecture si vous voulez en savoir plus sur la construction d'un compilateur .NET.

Un angle différent est tout à fait d'essayer PowerShell . Il existe de nombreux exemples d'intégration PowerShell dans une application - voici un projet complet sur le sujet: Powershell Tunnel

Créé 02/08/2008 à 02:49
source utilisateur

voix
7

Vous pourriez être en mesure d'utiliser IronRuby pour cela.

Sinon, je vous suggère de vous un répertoire dans lequel vous placez des ensembles précompilés. Ensuite, vous pourriez avoir une référence dans le DB à l'assemblage et la classe, et utiliser la réflexion pour charger les assemblages appropriés lors de l'exécution.

Si vous voulez vraiment compiler au moment de l' exécution , vous pouvez utiliser le CodeDOM, vous pouvez utiliser la réflexion pour charger l'ensemble dynamique. MSDN article qui pourrait aider .

Créé 02/08/2008 à 05:18
source utilisateur

voix
6

Si vous ne voulez pas utiliser le DLR , vous pouvez utiliser Boo (qui a un interprète) ou vous pourriez envisager le projet Script.NET (S #) sur CodePlex . Avec la solution Boo , vous pouvez choisir entre les scripts compilés ou en utilisant l'interpréteur, et Boo fait un langage de script agréable, a une syntaxe flexible et un langage extensible via son architecture ouverte du compilateur. Script.NET semble bien aussi, cependant, et vous pouvez facilement étendre cette langue ainsi que son un projet open source et utilise un générateur très sympathique compilateur ( Irony.net ).

Créé 06/08/2008 à 17:28
source utilisateur

voix
5

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

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

Lua dans d'autre part, ne le fait pas, il est donc très très stable et fonctionne merveilleux (je peux passer des objets de C # pour Lua et en arrière).

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

Je n'ai des problèmes de fuites de mémoire dans PROD en utilisant LuaInterface + Lua 5.0 , donc je Lua 5.2 et Linked directement en C # avec DllImport. Les fuites de mémoire étaient dans la bibliothèque LuaInterface.

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

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

Créé 17/07/2012 à 18:08
source utilisateur

voix
5

Je suggère d' utiliser LuaInterface comme il l' a pleinement mis en œuvre Lua où il semble que Nua est incomplète et ne risque pas de mettre en œuvre certaines fonctionnalités très utiles (les coroutines, etc.).

Si vous souhaitez utiliser certains des modules Lua en dehors préemballées, je vous suggère d'utiliser quelque chose le long des lignes de 1.5.x, par opposition à la série 2.x qui construit un code entièrement géré et ne peut pas exposer l'API nécessaire C.

Créé 17/09/2008 à 02:41
source utilisateur

voix
5

Vous pouvez utiliser l'une des langues de DLR, qui fournissent un moyen d'accueillir très facilement votre propre plate-forme de script. Cependant, vous ne devez pas utiliser un langage de script pour cela. Vous pouvez utiliser C # et le compiler avec le fournisseur de code C #. Tant que vous chargez dans son propre AppDomain, vous pouvez charger et décharger au contenu de votre cœur.

Créé 02/08/2008 à 07:16
source utilisateur

voix
4

La principale application que ma division vend fait quelque chose de très similaire à fournir customisations client (ce qui signifie que je ne peux pas poster une source). Nous avons une application C # qui charge les scripts VB.NET dynamiques (bien que tout langage .NET pourrait être facilement pris en charge - VB a été choisi parce que l'équipe de personnalisation est venue d'un arrière-plan ASP).

Nous compilons les scripts de la base de données CodeDom de l' aide .NET, en utilisant le VB CodeDomProvider(fâcheusement la valeur par défaut 2 .NET, si vous voulez soutenir 3,5 fonctionnalités dont vous avez besoin pour passer un dictionnaire avec « CompilerVersion » = « v3.5 » à son constructeur ). Utilisez la CodeDomProvider.CompileAssemblyFromSourceméthode pour compiler (vous pouvez passer des paramètres à forcer à compiler en mémoire seulement.

Cela se traduirait par des centaines d'assemblées en mémoire, mais vous pouvez mettre tout le code classes dynamiques ensemble en un seul ensemble, et recompiler l'ensemble du lot lors de tout changement. Ceci a l'avantage que vous pouvez ajouter un drapeau pour compiler sur le disque avec un PDB lorsque vous testez, vous permettant de déboguer dans le code dynamique.

Créé 10/08/2008 à 16:24
source utilisateur

voix
4

Oui, je pensais à ce sujet, mais je me suis vite compris que l'autre-domaine spécifique Langue (DSL) serait un peu trop.

, Ils ont besoin essentiellement d'interagir avec mon gamestate de manière peut-être imprévisibles. Par exemple, une carte peut avoir une règle « Quand ces cartes entrent en jeu, tous vos sbires morts-vivants gagnent +3 attaque contre les ennemis volants, sauf lorsque l'ennemi est béni ». Comme les jeux de cartes à collectionner sont tour par tour, le gestionnaire GameState se déclenche OnStageX événements et laisser les cartes modifier d'autres cartes ou GameState de quelque manière que les besoins de la carte.

Si je tente de créer une connexion DSL, je dois mettre en œuvre un ensemble de fonctionnalités assez grande et peut-être mettre à jour constamment, qui déplace les travaux d'entretien à une autre partie sans enlever réellement.

Voilà pourquoi je voulais rester avec un langage .NET « réel » pour être essentiellement en mesure de simplement déclencher l'événement et laissez la carte manipuler la gamestate de quelque manière (dans les limites de la sécurité d'accès du code).

Créé 02/08/2008 à 00:49
source utilisateur

voix
3

La prochaine version de .NET (5.0?) A eu beaucoup de discussions au sujet de l'ouverture du « compilateur en tant que service » qui rendrait les choses comme l'évaluation de script directe possible.

Créé 27/11/2010 à 03:12
source utilisateur

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