Discussion :

[RPG-man]

Bonjour,
Je réalise actuellement le portage d'un jeu vidéo que j'avais programmé en Ruby, vers C# et Xna.
La version Ruby possède un mécanisme qui permet de charger du code depuis un fichier, et d'en faire un éval à l'intérieur d'une méthode d'une instance (où ce code a accès au variables d'instances de l'objet etc...).

Problème
Le problème c'est que ce n'est apparemment pas possible (ou alors très compliqué) à faire en C#.
Ce qu'il faudrait faire, en résumé, c'est exécuter du code, propre à une seule instance d'un objet, à l'intérieur de cette instance (donc ayant accès à toutes ces variables).

Pistes
J'ai fait de longues recherches sur le net afin d'essayer de trouver une solution. Voici ce que j'ai exploré (et qui n'a pas marché) :
- C# parser : Le nom pourrait faire penser que c'est une solution, mais je n'ai trouvé aucune documentation ou explication le concernant. J'ai tout de même téléchargé et compilé les sources, mais je ne vois pas du tout comment on l'utilise.
- Cet article, où il est fait question de compiler du code pendant l'exécution. Seul problème, on parle de compilation d'assemblys entiers...


Y'a-t-il donc une solution à mon problème ?
Merci de votre aide !

Solutions
Dans le but d'aider ceux qui auraient le même problème quoi moi, voici les solutions qui ont été données :

- Utiliser le langage de script LUA.
Un tutoriel ici : http://www.gulix.fr/blog/IMG/pdf/Lua.pdf

- faire comme cela (pour mon cas) :

Compile-time :
- Ecriture des comportements des events d'un niveau dans un fichier.
Chaque comportement sera caractérisé par un ID, identique à celui de l'Event correspondant.
- Compilation des comportements :
Assembly : path.du.niveau
Comportements stockés dans des méthodes statiques de la classe correspondant à path du niveau (à moins qu'on puisse faire une même classe notée partial, mais je sais pas si ça fonctionne si on compile pas tout en un assembly), dans le namespace qui sera le même que celui des Events

Run-time :
- Premier chargement du niveau : chargement de l'assembly qui porte le nom du path du niveau (avec les slashs remplacés par des ".").
- Initialisation de chaque Event : création des delegates de comportements (Delegates déclarés non statiques, et initialisés lors du chargement de données d'un event (et non pas forcément lors de la création de l'instance) => pas besoin de les stocker dans un dictionnaire à la limite, surtout que chacun est unique).
- Quand nécessaire : exécution des delegates avec pour argument l'Event en question.

Et ici un petit bout de code assez utile, provenant de DonQuiche :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Signature que devront avoir les méthodes
delegate void Behaviour(IActor actor, IActorState state);
 
// Code pour charger la méthode comportementale "rock014" au début du niveau
Assembly asm = Assembly.LoadFrom(".\\customscripts.dll");
Type type = asm.GetType("Scripting.CustomScripts");
MethodInfo method = type.GetMethod("rock014", BindingFlags.Public | BindingFlags.Static);
Behaviour behaviour = (Behaviour)Delegate.CreateDelegate(method, null, typeof(Behaviour));
 
// On la stocke dans le dictionnaire des comportements
behvioursDictionary["rock014"] = behaviour;
 
// On pourrait appeler behaviour ainsi :
behaviour(someActor, someActorState);

[Bluedeep]

La deuxième solution (compilation dynamque) répond à cette problèmatique.

L'unité minimale de compilation en .Net est l'assembly de toute manière; je ne comprends pas bien ce qui te pose problème pour ce cas là ?

Mais ceci dit, tu peux t'interroger sur le besoin fonctionnel de chargement dynamique de code. Pour quelle raison veux tu faire cela ?

[Themacleod1980]

Salut

pour le code en clair laisse clairement tomber... le c# n'est ni du Ruby ni du VBS...

si tu veux pouvoir changer des fonctionnalités sans avoir à recompiler à chaque fois soit :

1) tu te crées ton propre langage de script (Gaaaaaa) que tu devras interpréter toi même (pourquoi pas... mais t'as pas fini) ou peut-être voir du coté de "LUA"

2) tu peux toujours charger dynamiquement des DLL... mais déjà compilées

3) tu demandes à tous les gens à qui tu veux refiler ton jeu de s'installer visual studio et XNA et de le recompiler à chaque fois qu'ils modifient le code. (<= Mouahaha ^^)

[RPG-man]

Merci de cette réponse si prompte

La deuxième solution (compilation dynamque) répond à cette problèmatique.

L'unité minimale de compilation en .Net est l'assembly de toute manière; je ne comprends pas bien ce qui te pose problème pour ce cas là ?

Mais ceci dit, tu peux t'interroger sur le besoin fonctionnel de chargement dynamique de code. Pour quelle raison veux tu faire cela ?

Bon, dans ce cas là je vais rentrer un peu plus dans les détails.

Dans mon système de jeu (plateformes 2D), la Map contient des Event, qui sont des objets tels que des plateformes, ennemis, etc... interagissant entre eux et avec le joueur.

L'éditeur que j'ai programmé permet d'insérer du code (pour l'instant Ruby) destiné à être exécuté à des moments spécifiques (Event à l'écran, contact Event/héros, contact Event/tir etc... : Voir Screenshot en pj).

Les caractéristiques de ce code :

• [LI]Ce code a besoin de références vers des variables internes à l'Event (au pire, je peux passer une référence vers l'Event pour accéder aux champs public ferait l'affaire).[/LI]
  [LI]Ce code n'est utilisé que pour une instance d'Event.[LI]

Il faut que je précise que j'utilise un système de Pooling pour ces Events, donc que je ne crée pas de nouvelles instances pendant le jeu, même quand de nouveaux Events apparaissent à l'écran (ils sont déjà instanciés). Ce qui fait que compiler une classe pour chaque Event n'est pas possible (puisqu'il faudrait les instancier en jeu, et que je ne peux pas prévoir le nombre d'Event qui vont être ajoutés à la map).

-> Compiler des assemblys entiers ne semble pas bon
-> Je suis obligé de charger ce code dynamiquement.

Ce que je voudrai, c'est créer une méthode dynamique par exemple, que je puisse lier à un objet, et dont le corps serait créé à partir de code source

Edit :

1) tu te crées ton propre langage de script (Gaaaaaa) que tu devras interpréter toi même (pourquoi pas... mais t'as pas fini) ou peut-être voir du coté de "LUA"

Oui j'y ai pensé, sauf que ça me semble :
- long à faire
- gourmand en ressources

2) tu peux toujours charger dynamiquement des DLL... mais déjà compilées

Euh, au vu de ce que j'ai expliqué au dessus ça serait pas possible ^^"
Pis, ça consommerai énormément de mémoire je pense non ?

3) tu demandes à tous les gens à qui tu veux refiler ton jeu de s'installer visual studio et XNA et de le recompiler à chaque fois qu'ils modifient le code. (<= Mouahaha ^^)

Bien sur

[Bluedeep]

2) tu peux toujours charger dynamiquement des DLL... mais déjà compilées

Si c'est pour changer des fonctionnalités, autant en effet introduire un concept de plug-in, car on ne voit pas bien l'avantage qu'il y aurait à livrer du code non compilé.

[Bluedeep]

Ce que je voudrai, c'est créer une méthode dynamique par exemple, que je puisse lier à un objet, et dont le corps serait créé à partir de code source

Ben c'est du plug-in, non ? je ne pense pas que les utilisateurs du jeu soient sensés coder eux même leurs "Event" non ?

La problématique me parle assez peu (n'étant ni utilisateur ni développeur de jeux vidéos) mais je ne vois rien qui ne puisse se faire avec une interface de type plug-in adéquate.

[RPG-man]

Non, ce n'est pas vraiment du plug-in.
Chaque plateforme, personnage, porte, etc.. comportera des lignes de code (en gros je code des objets qui ne seront pas compilés). Et des Events, il y en aura surement des millions dans tout le jeu.

En gros ce que je voudrais faire (et c'est un peu de l'utopie surement), c'est utiliser C#, en quelque sorte, comme un langage de script.

Par exemple, dans le code d'un event, onglet "Contact Héros" écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Player.damage(5);
this.Dispose();

C'est sur, s'il n'y avait que ça ça serait simple, mais je veux gérer tout ce qu'un langage de programmation peut gérer : boucles, accès aux objets, etc...

[Bluedeep]

Non, ce n'est pas vraiment du plug-in.
Chaque plateforme, personnage, porte, etc.. comportera des lignes de code (en gros je code des objets qui ne seront pas compilés).

MAIS QUEL INTERET A CE QU'iLS NE SOIENT PAS COMPILES ?

Et des Events, il y en aura surement des millions dans tout le jeu.

Euh, oui, et alors ?

En gros ce que je voudrais faire (et c'est un peu de l'utopie surement), c'est utiliser C#, en quelque sorte, comme un langage de script.

Mais quel interêt ?????

C'est sur, s'il n'y avait que ça ça serait simple, mais je veux gérer tout ce qu'un langage de programmation peut gérer : boucles, accès aux objets, etc...

Encore une fois, je ne vois pas du tout la finalité.

[Nathanael Marchand]

J'avais pas capté non plus jusqu'à ce que je regarde le screenshot.
C'est enfait pour créer un logiciel à la "Click'n'Play" ou Kodu
Par exemple je droppe un bonhomme sur la zone de jeu et c'est le comportement de cet instance du bonhomme que je définis (et non pas le comportement de tous les bonhommes).

Il n'empeche que l'un empeche pas l'autre. Il suffit de créer une classe abstraite bonhomme et definir les membres en abstrait. Ensuite tu peux compiler dynamiquement une classe qui hérite de cette classe abstraite et où tes membres sont ceux que l'utilisateur a programmé

[RPG-man]

MAIS QUEL INTERET A CE QU'iLS NE SOIENT PAS COMPILES ?

Tout simplement parce qu'il faudrait créer des instances de sous classes d'Event à chaque fois, et que justement l'interêt de mon système de pooling est dans le fait que je ne crée pas d'instances après la seule et unique fois où c'est fait.

Euh, oui, et alors ?

Charger des millions de classes en mémoire je pense que la RAM de la xbox apprécierai pas ^^
A moins qu'il y ait un moyen de décharger au fur et à mesure.

Mais quel interêt ?????

Bah, mon système Ruby fonctionnait comme ça. Sauf qu'avec Ruby c'est possible de faire des eval et pas avec C#. Et que c'est la manière la plus pratique de procéder ^^"

Encore une fois, je ne vois pas du tout la finalité.

Si je veux gérer une personnage ayant des actions complexes, j'ai besoin de ces fonctionnalités.

Après, si y'a moyen d'intégrer un langage de script je suis preneur !

[RPG-man]

J'avais pas capté non plus jusqu'à ce que je regarde le screenshot.
C'est enfait pour créer un logiciel à la "Click'n'Play" ou Kodu
Par exemple je droppe un bonhomme sur la zone de jeu et c'est le comportement de cet instance du bonhomme que je définis (et non pas le comportement de tous les bonhommes).

On va dire que c'est à peu près ça. Je crée un Event qui aura un comportement unique, et tous les autres Event n'auront pas son comportement.

Il n'empeche que l'un empeche pas l'autre. Il suffit de créer une classe abstraite bonhomme et definir les membres en abstrait. Ensuite tu peux compiler dynamiquement une classe qui hérite de cette classe abstraite et où tes membres sont ceux que l'utilisateur a programmé

Oui mais je vais devoir créer des instances de ces Evènements (pas bon pour le système de pooling).
En gros, l'idée c'est ça, sauf que ça se passe sur un objet déjà instancié ^^"

[Bluedeep]

Tout simplement parce qu'il faudrait créer des instances de sous classes d'Event à chaque fois, et que justement l'interêt de mon système de pooling est dans le fait que je ne crée pas d'instances après la seule et unique fois où c'est fait.

Mais il n'y a aucun interêt à ne pas créer d'instances !!

Charger des millions de classes en mémoire je pense que la RAM de la xbox apprécierai pas ^^

Il ne s'agit pas de millions de classes ici mais de millions d'instances

A moins qu'il y ait un moyen de décharger au fur et à mesure.

Ben, c'est le boulot du GC quand elles ne servent plus ....

Bah, mon système Ruby fonctionnait comme ça. Sauf qu'avec Ruby c'est possible de faire des eval et pas avec C#. Et que c'est la manière la plus pratique de procéder ^^"

C# n'est pas un langage de script et il n'y a aucun sens à appliquer des patterns de programmation de langages de scripts vers un langage compilé (que ce soit C# ou Java ne change rien ici au problème) et inversement.

Après, si y'a moyen d'intégrer un langage de script je suis preneur !

ce ne sont pas les langages de scripts qui manquent.

[Bluedeep]

J'avais pas capté non plus jusqu'à ce que je regarde le screenshot.
C'est enfait pour créer un logiciel à la "Click'n'Play" ou Kodu
Par exemple je droppe un bonhomme sur la zone de jeu et c'est le comportement de cet instance du bonhomme que je définis (et non pas le comportement de tous les bonhommes).

Tu as l'air de comprendre sa problèmatique; mais, je suppose que les degrés de libertés sur le comportement ne sont pas infinis; donc en quoi serait ce inaccessible à une typologie objet classique ?

EDIT : j'ai regardé ton lien, mais ça ne me parle pas du tout, du tout.

[RPG-man]

Mais il n'y a aucun interêt à ne pas créer d'instances !!

En fait si, car d'après ce qu'on m'a dit, et ce que j'ai lu, le GC sous xbox provoque des glitchs. Donc y'a 2 moyens d'éviter ça : pas d'alloc de mémoire OU pas de références d'objets (j'ai choisi l'option 1). Donc je fais du pooling.

Il ne s'agit pas de millions de classes ici mais de millions d'instances

Si, vu que je devrai compiler (que ce soit à l'éxécution ou pas), une classe pour chaque comportement (des millions).

ce ne sont pas les langages de scripts qui manquent.

Alors comment ça s'implémente ?

En tout cas merci des réponses ! Ca me permet de réfléchir à nouveau sur la nécessité du système... mais faut tout de même trouver une solution, le langage de script me semble être une bonne solution, mais je ne sais pas comment on implémente ça.

Edit : trouvé un lien pour LUA.
Pour ceux que ça intéresse :
http://www.gulix.fr/blog/IMG/pdf/Lua.pdf


Re-Edit :

Lua convient parfaitement finalement, je vous remercie de m'avoir amené à ça !!

[Nathanael Marchand]

Euh oui parceque j'avais pas tilté mais si ca se trouve la dll qui te permet de faire ca n'est pas dispo dans XNA...

[DonQuiche]

@RPG-Man
Malheureusement, si tu compiles du code, cela signifie des allocations mémoires (et, à moins de passer par des dynamic methods, c'est une mémoire irrécupérable jusqu'à la fermeture du jeu, à moins d'utiliser des domaines d'application, voir AppDomain). Si tu utilises un interpréteur, il faudrait en examiner le code, celui-ci va peut-être créer des AST (abstract syntax tree) à la volée à chaque interprétation, donc un grand nombre d'allocations.


Faisons d'abord le tour de ce qui est possible en termes de compilation dynamique ou d'interprétation de code en C#.
* Il est possible d'utiliser des objets DynamicMethod pour du code compilé à la volée, dont la mémoire est récupérée une fois la référence perdue mais qui n'est pas persistable pour une réutilisation à une prochain exécution. Soit directement (on rentre du code IL), soit via le biais des Expression (on génère un AST qui s'occupera de compiler le code).
* Il est possible de compiler des assemblies, soit directement (via l'IL), soit depuis un code source textuel avec MCS (compilateur C# libre de mono, licence compatible avec appli commerciale), ou via RunSharp (biblio permettant de générer un AST de façon naturelle qui s'occupe ensuite de créer une assembly).
* On peut trouver des interpréteurs comme celui du LUA. Cet interpréteur devra être assez rapide (mais l'exécution d'une fonction sera vraisemblablement plus long qu'une passe du GC), tu souhaiteras peut-être pouvoir compiler et, sans doute, définir toi-même les objets que le LUA est autorisé ou non à manipuler (un bonhomme, oui, ton moteur graphique, non). La perle rare sera difficile à trouver. Au passage, MCS peut aussi servir d'intepréteur C#.

Note qu'à l'exception de l'émission directe d'un flux IL, tout passe par un AST, à moins peut-être qu'il existe un interpréteur purement conçu en programmation fonctionnelle. Et encore l'émission d'IL est-elle difficilement envisageable sans la création d''un AST.

Tout ceci étant dit, pourrais-tu nous préciser quel est ton scénario exact ?
* Tu souhaites créer un éditeur de comportement à destination des développeurs ou d'un éditeur de niveaux, ce ne serait pas une fonctionnalité du jeu lui-même, ou alors rarement utilisée : la compilation est alors le bon choix. Elle sera dynamique dans l'éditeur et sérialisée pour l'exécution du jeu (ton assembly ne sera alors qu'une ressource à charger comme une autre : graphique, sonore, etc)
* Si au cours du jeu tu dois générer de nouveaux comportements et qu'au cours d'une même session de jeu tu vas typiquement en générer de nombreux (trop fréquents pour une compilation dynamique), ton meilleur choix est de définir ces comportements par la création d'arbres d'objets. Via un système astucieux, des ressources statiques et du recyclage d'objets, le GC ne sera pas un problème, surtout si les comportements sont définis par des interactions de l'utilisateur (pas plus d'un nouvel étage de comportement par seconde, ce n'est rien).
* Un interpréteur n'est en général pas la bonne solution, à moins que tu veuilles explicitement mettre à disposition des utilisateurs un langage de script interprété pour des fonctionnalités légères (UI par exemple). En tout cas, ça ne devrait pas être un médium de génération de code ou de comportement, il y a de meilleurs choix.

Dans tous les cas, j'insiste : nous devons vraiment comprendre tes besoins, tu dois les préciser.


@Nathanael
Tant que la biblio ne fait pas d'appels Win32, on peut l'utiliser sur Xbox je pense. Je crois que le P/Invoke est impossible par contre.

[Nathanael Marchand]

Nop! Si ca utilise CodeDom, ca passe pas sur XNA...
Pareil pour les Expression<TDelegate>, existe pas sur XNA...

[DonQuiche]

Huh huh... Ah, oui, c'est du compact framework. Bon, ben au cas où l'OP repasserait par ici, on peut éliminer les DynamicMethod (Mono dispose d'un interpréteur pour les Expression trees sur CF toutefois, me semble t-il). Pour la compilation d'assemblys à la volée, Cecil et MCS restent d'actualité en revanche.

[RPG-man]

Bon, dans ce cas là je vais mieux expliquer mes besoins à nouveau, surtout que finalement, j'ai une erreur lorsque j'instancie l'interpréteur Lua.

L'assembly en mode mixte est créé avec la version 'v2.0.50727' du runtime et ne peut pas être chargé dans le runtime 4.0 sans d'autres informations de configuration.

Pour vous donner une idée de ce qu'est le jeu, voici une vidéo youtube qui montre la démo technique d'Octobre 2010 en action (car ces maps qui sont assez démonstratives ne sont plus compatibles avec la nouvelle version du moteur Ruby).

Vous pouvez voir que certains objets (comme le rocher) ont un comportement unique.
Ce comportement est défini dans le système de scripting que j'ai intégré dans mon éditeur de jeu.
Une petite vidéo montrant à peu près comment est fichu l'éditeur pour la programmation des Events :

Etant donné que j'utilisais ruby comme langage pour le moteur, y'avait pas de problème à l'utiliser en plus comme langage de script.
L'éditeur quand à lui, est exclusivement réservé à l'équipe de développement, et y'a que moi qui touche à la partie programmation des Events car je suis le seul programmeur.

Donc maintenant que je suis passé à C#, le mieux ça serait d'avoir
- un langage de script
OU un interpréteur CS
OU autre chose qui ne nécessite pas de créer une classe pour chaque Event "différent" (par différent j'entends avec des lignes de codes différentes) qu'on va voir en jeu.
Et le tout compatible Xna...
J'en demande beaucoup certes, et si ce n'est pas possible je créerai un interpréteur de commandes limité tant pis...

Après, ça fait pas longtemps que je code en C#, donc je ne me sens pas prêt à utiliser les méthodes de Reflexion ou d'Emission de code IL...

En tout cas merci beaucoup de votre aide !

[DonQuiche]

Mais c'est très facile alors !
Enfin...

Tu as deux choix pour le script : un langage souple interprété (il faudrait recompiler l'intepréteur LUA pour le framework que tu vises, c'est l'origine de ton erreur), ou un langage compilable. La seconde serait l'idéal en termes de performances : plus rapide, pas d'assignations dynamiques, etc. Ce ne sera pas le cas avec un langage interprété. Mais les langages interprétés sont typiquement plus faciles pour des non-codeurs. En termes de perfs, si tu utilises le script simplement de temps à autre (le rocher seulement, tandis que les ennemis, le bonhomme et les pièges sont codés en dur), ce n'est pas un souci. Si tout utilise ce script, en revanche, là... A toi de voir mais ne sois pas parano vis-à-vis d'une ou deux assignations par seconde. Au pire envisage de fournir à tes designers de quoi éviter de passer par des scripts : possiblités de combiner des briques comportementales que tu pourrais assembler à la compilation en un seul comportement compilé (méthode des éditeurs de Bethesda si tu y réfléchis : des dialogues hiérarchisés avec des références à des variables choisies dans des combobox... je doute que ce soit compilé au bout cela dit mais bon).

Si tu te tournes vers un langage compilable (C# par exemple), rien de bien sorcier vu que ton éditeur tourne sous Windows : tout peut être compilé sur un PC, soit directement (appli Windows avec fenêtre XNA pour le rendu, possible ?), soit indirectement (appli XNA enregistrant des fichiers XML+script représentant les comportements, appli Windows utilisant ces données pour compiler l'assembly). L'assembly (une seule pour tout le jeu) sera chargée au début du jeu, elle ne devrait peser que quelques Mo. Tu peux utiliser le compilateur mono ou le compilateur officiel. Qui plus est, tu peux réutiliser les composants de visual studio pour fournir une fenêtre avec coloration syntaxique, intellisense, etc : tu pourras alors créer une appli tombant sous le coup des licences de Visual Studio Express il me semble (à vérifier). Mono propose aussi un compilateur qu'on doit pouvoir réutiliser. Enfin, des outils comme yaccs permettent de créer "aisément" ses propes compilateurs et CodeDom ou Runsharp aideront à mettre le code IL ou le code C# réel.

Grosso modo, pour éviter toute instanciation/nettoyage au cours du jeu, ton assembly peut être un seul type composé de milliers de méthodes (tu conserves dans des membres statiques une copie de chaque méthode et tu les assignes aux objets réutilisables), ou bien tu pourrais avoir un singleton par type d'objets, chaque comportement unique n'étant instancié qu'une fois au chargement d'un niveau (du coup, des arbres comportementaux feraient aussi bien l'affaire que du code compilé). Ce sera un peu plus compliqué si tes objets ont des états et que tu veux éviter des instanciations : tes objets devront conserver des dictionnaires (string, int), (string, bool) réutilisables pour tous les comportements et il y aura pas mal de boulot au niveau de la compilation. Cela dit, dans ton niveau, tu as quoi ? 200 ou 500 objets ? Autant les instancier au chargement et ne pas se prendre la tête.