Exécuter du code C# lu à l'exécution

Merci de cette réponse !

Alors, en effet, y'a un grand nombre de choses qui seront codées "en dur" : les ennemis, les plateformes (avec un peu de script pour l'instant, mais pourquoi pas un système de paramétrage), etc... Après, pour les objets pour le rocher (qui est unique donc), y'aurait une partie scripting (pas plus d'une dizaine de lignes de code).
Mais bon, si ça tourne à 60fps en full-ruby, ça devrait tourner facilement en C# + Un peu de Lua (corrigez moi si je dis une énorme bêtise s'il vous plait).
Bon c'est vrai que c'est discutable mais c'est le plus simple.

Après pour ce qui est de l'utilisation d'un langage compilable pour ça, je pense que ça sera un peu plus compliqué à mettre en place (sachant que la partie codage des Events se fera dans l'éditeur pour les modifier sans avoir à modifier le noyau), mais c'est nettement mieux niveau perfs. Quel dilemne ! :lol:

Citation:

---

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.

---

Avoir un seul type composé de milliers de méthodes il me semble y avoir pensé, mais je me suis posé la question de "comment savoir lesquelles ce sont ?".

Citation:

---

(tu conserves dans des membres statiques une copie de chaque méthode et tu les assignes aux objets réutilisables)

---

Je vois pas trop comment on fait ça désolé ^^"
Par contre le fait est que les objets réutilisables vont devoir "perdre" les méthodes lorsqu'il sont "libérés". Est-ce possible ?

Je vais étudier ces possibilités !
Bon en tout cas merci beaucoup, sincèrement, ça me sort d'un beau pétrin !

Edit : par contre je vais peut être passer pour un n00b mais je n'arrive pas à compiler les sources de Lua. (j'ai CodeBlocks comme IDE pour C)
Et comment faire pour modifier le framework cible ?

Citation:

---

Alors, en effet, y'a un grand nombre de choses qui seront codées "en dur" : les ennemis, les plateformes (avec un peu de script pour l'instant, mais pourquoi pas un système de paramétrage), etc... Après, pour les objets pour le rocher (qui est unique donc), y'aurait une partie scripting (pas plus d'une dizaine de lignes de code).
Mais bon, si ça tourne à 60fps en full-ruby, ça devrait tourner facilement en C# + Un peu de Lua (corrigez moi si je dis une énorme bêtise s'il vous plait).

---

Effectivement, si seule une poignée d'objets a recours au script, pas de problèmes. Le lua sera un peu plus lent que le ruby (interpréteur écrit en C# et non en C, moins populaire donc sans doute moins optimisé) mais le C# sera, lui, beaucoup plus rapide que ruby. Mais du coup tu feras sans doute davantage aussi (quelques effets de particules ?), tes besoins pourraient donc être différents. Mais je ne pense pas que tu auras des soucis de ce côté de toute façon, ça ne devrait donc pas être ton critère de choix.

Un langage compilable n'aurait vraiment rien de sorcier, pas plus qu'un interpréteur. J'ai mentionné le compilateur officiel et celui de mono, dans les deux cas ça peut se résumer à un "Compile(filename)". Un peu de réflexion (5 lignes) pour obtenir la méthode compilée depuis l'assembly et le tour est joué. La difficulté de base est équivalente. Ce qui est plus ou moins compliqué dans les deux cas c'est :
* Eventuellement transformer le code avant de le filer à l'interpréteur/compilateur si c'est nécessaire (voir ma remarque sur des objets ayant des états dans mon précédent post). Ca peut se faire par des expressions régulières, un analyseur comme Yaccs pour transformer le code. Les deux solutions sont logées à la même enseigne je pense (à moins que l'interpréteur n'offre des facilités).
* Définir à quels objets et fonctions les designers doivent pouvoir accéder depuis leurs scripts : en C# ça se résumera sans doute à bien choisir l'espace de noms dans lesquels les fonctions s'exécuteront (tes devs coderaient le contenu d'une fonction et toi tu concatènes le haut du fichier avec usings et espace de noms, le contenu fourni par les designers puis le pied du fichier). Avec l'interpréteur, en revanche, je ne sais pas comment ça se passe, c'est un des points à creuser.
* Fournir un éditeur de code aux designers : encore une fois, pour C# il existe des briques de Visual Studio qui sont réutilisables. Je ne sais pas ce qu'il en est pour le LUA.


Pour identifier les méthodes... Et bien, comment identifies-tu tes ressources graphiques ou sonores ? Le problème est le même, sauf qu'il te faut associer un nom de fonction au lieu d'un nom de fichier de sprites. Ensuite, c'est deux ou trois lignes de réflexion. Voici un petit exemple qui répond à une autre de tes questions (stockage au chargement d'un niveau).

Code:

---

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);

---

Enfin, l'assembly restera toujours en mémoire (impossible de la dégager mais ce ne sont que quelques Mo) mais les délégués instanciés au chargement du niveau sont quant à eux des objets normaux et nettoyables.


Concernant LUA, télécharge plutôt Visual C# Express plutôt que CodeBlocks pour travailler en C#, la solution fournie pour l'intepréteur LUA doit être dans leur format, autant se simplifier la vie.

Bon tout ça est très intéressant !

Je vais faire un schéma demain pour résumer un peu tout ça.
Histoire de me représenter de la compilation des comportements, jusqu'au chargement des assemblys et à l'éxecution des comportements. Je veux voir si j'ai bien compris. :p

Citation:

---

* Eventuellement transformer le code avant de le filer à l'interpréteur/compilateur si c'est nécessaire (voir ma remarque sur des objets ayant des états dans mon précédent post). Ca peut se faire par des expressions régulières, un analyseur comme Yaccs pour transformer le code. Les deux solutions sont logées à la même enseigne je pense (à moins que l'interpréteur n'offre des facilités).

---

Je pense qu'il n'y en aura pas besoin, les objets n'ont pas vraiment d'états qui modifient leur comportement (bien sur des tonnes de variables risque de modifier une partie de ce qu'ils font, mais ce sont des trucs basiques).

Citation:

---

* Définir à quels objets et fonctions les designers doivent pouvoir accéder depuis leurs scripts : en C# ça se résumera sans doute à bien choisir l'espace de noms dans lesquels les fonctions s'exécuteront (tes devs coderaient le contenu d'une fonction et toi tu concatènes le haut du fichier avec usings et espace de noms, le contenu fourni par les designers puis le pied du fichier). Avec l'interpréteur, en revanche, je ne sais pas comment ça se passe, c'est un des points à creuser.

---

Avec l'interpreteur Lua j'ai vu comment ça se passait j'étais même prêt à implémenter le système si l'assembly était bien chargé. ^^"

Au niveau des fonctions accessibles j'ai déjà prévu le topo, de toute façon il n'y a que moi qui code (notre équipe de dev est limité à un graphiste, un compositeur, et moi, et on s'occupe tous les 3 du Game Design et Level Design).
Sinon je vois ce que tu veux dire.

Citation:

---

* Fournir un éditeur de code aux designers : encore une fois, pour C# il existe des briques de Visual Studio qui sont réutilisables. Je ne sais pas ce qu'il en est pour le LUA.

---

Vu que je suis seul codeur et que je me suis toujours débrouillé sans l'IntelliSense quand je bossais avec Ruby sur ce projet de 273 scripts, j'aurai pas de mal à travailler sur des petits scripts de quelques dizaines de lignes :)
Je changerai juste la colo syntaxique je pense...


Par contre au niveau de la génération du fichier à compiler, le mieux c'est de créer un assembly par niveau je pense non ? (sinon à chaque modification d'un Event faudrait recréer un fichier entier, donc chercher dans tous les fichiers de niveaux etc...)
Les méthodes des types qu'il y a dans les assembly doivent être statiques aussi si je ne me trompe pas ?


Finalement, vu comme tu l'as présenté la méthode de la compilation a l'air un poil plus simple, merci !


Concernant Lua :
J'ai Visual Studio 2010 (mais seulement avec C#), le problème est que les sources de Lua sont en C (oui pas C#; à la limite c'est bon j'installe ce qu'il faut en matière de compilo), et que j'ai aucune idée de comment spécifier le framework "cible".

Encore merci de ton aide !

Pour les variables d'état... Et si ton designer veut faire un interrupteur et que tu n'as pas ça codé en dur (peu importe si c'est le cas, c'est pour l'exemple), comment fait-il ? Il utilise une variable globale et redéfinit le script pour chaque interrupteur en changeant le nom de la variable ?

Sinon en vrac :
* Oui, le mieux semble être de faire une assembly par niveau dans ce cas. Par contre, les assemblies des niveaux précédemment joués resteront en mémoire, on ne peut pas s'en débarrasser. Pas grave.
* Ouaip, des méthodes statiques.

Enfin, je viens de jeter un coup d'oeil à LuaInterface. Bon, en fait c'est un wrappper de la lib lua originale pour dotnet. Donc si tu veux l'utiliser, il va falloir recompiler la biblio C pour la Xbox et recompiler également LuaInterface (le wrapper C#) pour le CF (Compact Framework). Ah ! Et il te faudra sans doute aussi une version compilée distincte de la biblio C pour les PC 64-bits et 32 bits. A voir s'il y a des alternatives purement dotnet qui tournent sur le CF, je t'avoue mal connaître cet univers là.

Après tout, ça ne pouvait pas être trop simple non plus, n'est-ce pas ? ;)

Citation:

---

Pour les variables d'état... Et si ton designer veut faire un interrupteur et que tu n'as pas ça codé en dur (peu importe si c'est le cas, c'est pour l'exemple), comment fait-il ? Il utilise une variable globale et redéfinit le script pour chaque interrupteur en changeant le nom de la variable ?

---

Et bien, une simple condition au début du script suffirait, du moins je pense :oops:

Citation:

---

* Oui, le mieux semble être de faire une assembly par niveau dans ce cas. Par contre, les assemblies des niveaux précédemment joués resteront en mémoire, on ne peut pas s'en débarrasser. Pas grave.
* Ouaip, des méthodes statiques.

---

Ok, bon si ça prend quelques Mo les assemblys encore ça va ; mais j'ai que 512Mo de RAM sur Xbox donc va falloir faire gaffe !
Et faudra que je fasse en sorte que le poids total de tous les assemblys de tout le jeu ne dépasse pas la centaine de Mo... au cas où un joueur veuille finir le jeu d'un trait, on sait jamais !

Citation:

---

Enfin, je viens de jeter un coup d'oeil à LuaInterface. Bon, en fait c'est un wrappper de la lib lua originale pour dotnet. Donc si tu veux l'utiliser, il va falloir recompiler la biblio C pour la Xbox et recompiler également LuaInterface (le wrapper C#) pour le CF (Compact Framework). Ah ! Et il te faudra sans doute aussi une version compilée distincte de la biblio C pour les PC 64-bits et 32 bits. A voir s'il y a des alternatives purement dotnet qui tournent sur le CF, je t'avoue mal connaître cet univers là.

Après tout, ça ne pouvait pas être trop simple non plus, n'est-ce pas ?

---

En effet, c'était trop beau pour être vrai :aie:
C'est la première fois que je suis amené à compiler des sources que je n'ai pas écrites moi même, et j'avoue donc que je n'ai aucune idée de la manière dont on dit au compilo "Compile moi tout ça pour la Xbox et ça pour le CF !!!".

Une simple condition, ok, mais qui teste quoi ? ;)
Une variable globale ? Car tu ne sembles pas donner la possibilité de définir des variables d'état pour chaque objet (des membres, quoi). Je veux juste m'assurer que tu as bien prévu ce problème et si c'est un choix délibéré ou non.

Oh ! Aucun risque que tu atteignes 100 Mo. ^^
Si toutes tes assemblies réunies atteignent 5Mo, ce sera déjà du lourd. C'est un autre avantage des langages compilés : le résultat produit est compact.

Pour la biblio LUA à recompiler, et bien... Il y a un makefile donc déjà tu vas devoir installer Cygwin pour avoir les outils linux de base sur Windows afin de l'utiliser. Ensuite, il va falloir modifier le makefile pour spécifier la ou les plateformes qui t'intéressent. Enfin, il va falloir trouver un compilo qui supporte la XBox, gcc fait peut-être ça, sinon MS doit fournir un SDK. A défaut, tu peux peut-être aussi tenter de te passer de tout ça, créer un projet C++ sous Visual Studio à la main, j'imagine que leur SDK peut s'intègrer dans VS.

Citation:

---

Une simple condition, ok, mais qui teste quoi ?
Une variable globale ? Car tu ne sembles pas donner la possibilité de définir des variables d'état pour chaque objet (des membres, quoi). Je veux juste m'assurer que tu as bien prévu ce problème et si c'est un choix délibéré ou non.

---

Alors soit une globale (j'ai déjà prévu l'endroit où les stocker), soit des variables qui leurs seront fournies, soit des valeurs de retours de fonctions. Par exemple des variables ayant une portée de l'ordre de la map, ou juste de l'instance de l'Event, qui seront stockées dans des dictionnaires à taille limitée (pour éviter un redimensionnement à chaque 'ajout' de variable).

Citation:

---

Oh ! Aucun risque que tu atteignes 100 Mo. ^^
Si toutes tes assemblies réunies atteignent 5Mo, ce sera déjà du lourd. C'est un autre avantage des langages compilés : le résultat produit est compact

---

C'est une bonne nouvelle ça alors ! :D

Citation:

---

Pour la biblio LUA à recompiler, et bien... Il y a un makefile donc déjà tu vas devoir installer Cygwin pour avoir les outils linux de base sur Windows afin de l'utiliser. Ensuite, il va falloir modifier le makefile pour spécifier la ou les plateformes qui t'intéressent. Enfin, il va falloir trouver un compilo qui supporte la XBox, gcc fait peut-être ça, sinon MS doit fournir un SDK. A défaut, tu peux peut-être aussi tenter de te passer de tout ça, créer un projet C++ sous Visual Studio à la main, j'imagine que leur SDK peut s'intègrer dans VS.

---

Je vais tenter ça !

Au niveau du petit résumé de comment procéder (si j'ai bien compris) :
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.

Une fois de plus merci !!

Ça paraît impeccable ma foi. Un seul bémol : créer un délégué, même d'une méthode connue, est une instanciation. Donc si tu veux limiter les instanciations, il vaut mieux les stocker.

Bonne chance à toi. :)

Citation:

---

Ça paraît impeccable ma foi. Un seul bémol : créer un délégué, même d'une méthode connue, est une instanciation. Donc si tu veux limiter les instanciations, il vaut mieux les stocker.

---

Hum oui, faut que je voie si j'aurai besoin d'en créer souvent "en jeu" (hors chargement), pour éviter de consommer de la mémoire inutilement. Parce qu'une instanciation toutes les 10 secondes, c'est pas la mort :P

Merci de ta patience ! :ccool:

Nouveau problème :
Maintenant que j'ai fait pas mal de choses faisant partie "du gros morceau", j'ai un problème : comment faire en sorte que les assemblys que je compile ait une référence vers ma classe Event, dont une instance est passée à ces méthodes ? Ou même mieux, qu'elles aient des références vers toutes les classes de mon projet lors de la compilation ?
Est-ce possible ?

Sinon, il va falloir faire du bricolage et ça sera pas super propre...

Je précise, de plus, que la compilation s'effectue dans un content processor, en dehors de l'assembly du jeu.

C'est évidemment faisable, tout dépend de la méthode que tu as utilisée :
* Code C# généré à la mano ? Si tu compiles via CSharpCodeProvider, il y a une méthode "CompileFromSource" qui accepte un objet de type "CompilerParameters" avec une propriété "ReferencedAssemblies".
* Si en revanche tu utilises un compilateur de ligne de commande, c'est une option lui à spécifier.
* Si tu es passé par Codedom, vois alors CodeCompileUnit.ReferencedAssemblies.

Citation:

---

* Code C# généré à la mano ? Si tu compiles via CSharpCodeProvider, il y a une méthode "CompileFromSource" qui accepte un objet de type "CompilerParameters" avec une propriété "ReferencedAssemblies".

---

C'est ce que j'ai fait en fait... mais le problème c'est qu'il faut lui donner un string mais qu'est-ce qu'on met dedans ?
Surtout que mon assembly de jeu est différente de celle où sont compilés les comportements (je l'ai mis dans le Processor de mon ContentPipeline). Et que du coup j'ai aucune idée de :
- comment lui indiquer l'assembly
- si une fois compilée, la dll pourra "reconnaitre" mon assembly, sachant que le chemin relatif de cette dernière change entre la compilation et l'exécution me semble-t-il.

Merci encore !

Bonjour.

C'est assez simple en fait : d'après MSDN, tu dois donner soit le nom simple ou complet d'assembly (voir paragraphe suivant), soit le chemin d'accès actuel (au moment de la création de l'assembly) des assemblies référencées, auquel cas le compilateur se chargera d'extraire le nom complet de l'assembly. Dans tous les cas, seul les noms complets d'assemblies seront enregistrés.

Exemple d'entrées acceptées (à tester tout de même) : "System", "System.dll", "c:\system.dll".

En effet, en dotnet on ne référence pas les assemblies par leur chemin d'accès mais par leur noms complets (nom, version, culture et, pour les assemblies signées, clé de chiffrement) afin d'éviter le problème du "dll hell". A l'exécution, le framework scanne alors différents dossiers, dans un certain ordre:
* Le GAC
* Codebase de l'application - son dossier de démarrage par défaut -
* Les éventuels sous-dossiers du codebase spécifiés comme les privateBinPath du domaine d'application courant (par exemple via le fichier .config de l'appli)
* Certains sous-dossiers du codebase tels que : fr-FR/mylib.dll (<culture>) ou mylib/mylib.dll (<asmname>)

Exemple de nom complet: com.microsoft.crypto, Culture=en, PublicKeyToken=a5d015c7d5a0b012, Version=1.0.0.0

Bonjour,
J'ai tenté d'obtenir les noms complets en utilisant Assembly.GetAssembly(...).FullName ou Assembly.GetExecutingAssembly().FullName. Je les ai du coup obtenus et je les ai ajoutés dans les paramètres de mon compilo.
Et voilà ce qu'il me dit :

Citation:

---

Compiler Errors :
Line 0,0 : Le fichier de métadonnées 'Geex.Play.Rpg, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' est introuvable
Line 0,0 : Le fichier de métadonnées 'Geex.Run, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' est introuvable

---

D'où peut venir cette erreur ? Sachant que j'exécute maintenant ce code depuis l'assembly du jeu (session de compilation), donc qu'il devrait pas y avoir trop de problèmes normalement pour trouver... l'assembly dans laquelle j'exécute le code !

Merci encore de votre aide !

Apparemment, le compilateur cherche à charger le manifeste des assemblies même lorsque tu fournis directement leur nom complet. Comme je ne sais pas quel est le codebase du content processor (je ne sais que très vaguement ce que c'est) ni coment sont organisés tes dossiers, je ne peux pas en déduire quels sont les répertoires sondés et t'expliquer le problème. Peu importe, je te conseille tout simplement de fournir :
* Pour les assemblies du GAC, le nom à moitié complet (simplement nom et version)
* Pour tes assemblies perso, le chemin d'accès.


EDIT: Pour les assemblies du GAC, j'ai un doute vu que tu dois référencer celles du compact framework. Comme je n'ai jamais travaillé avec... Peut-être spécifier aussi leur chemin d'accès alors.

Citation:

---

* Pour tes assemblies perso, le chemin d'accès.

---

Mais vers quoi ? :P

Je donne un chemin d'accès vers un dossier ou un fichier (sachant que mon assembly de jeu est un exécutable et non pas une dll), et lequel ?

Ah ! :lol:

J'ai une mauvaise nouvelle dans ce cas, il va falloir prendre une tronçonneuse et découper : placer dans une bibliothèque les éléments qui doivent être accessibles tant par l'exécutable que par l'assembly que tu cherches à génèrer. Le chemin d'accès à fournir sera donc celui vers ce fichier .dll. Gaffe au passage aux chemins d'accès... to root (file://c:\mylib.dll) or not to root (c:\mylib.dll), that is the question, mieux vaut miser sur la seconde.

L'utilisation de la tronçoneuse a marché, malgré des petits problèmes d'interop au départ, j'ai finalement réussi à m'en sortir.
J'ai réussi à incorporer mes assembly perso mais pas Xna et le reste (de toute façon je pense pas que mes events aient besoin de ce qu'il y a dedans).
La compilation fonctionne (miracle !), il ne reste plus qu'à faire en sorte que le code soit exécuté !

Félicitations, heureux que tout ça ait fini par fonctionner.:D

Encore merci ! :ccool:
Faudra que je pense à faire un tutoriel là dessus un jour, ça pourrait servir à d'autres gens !