Discussion :

[Driktheviking]

Tout d’abord bonjour.

Voila mon problème:
Pour passer le temps et développer un peu mes compétence j'ai choisie de crée un petit moteur de jeu a base de c++\sfml et un langage de script pour gérer tous ce qui concerne le déroulement du jeu\événement.

Et c'est là que cela coince car je n'ai absolument aucune expérience dans un quelconque langage de script et en fouillant un peu j'ai rapidement entendue parler de lua,python et autre donc je viens ici pour quelque conseille qui si possible devrai tenir compte des point suivant :

• Facile d'utilisation
  
• Possibilité de créer de nouvelle classe a partir du script ( exemple dans un rpg avec l'éditeur pouvoir cree de nouvelle classe de personnage qui heriterai d'une classe plus générique.
  
• j'ai entendu parler de c# qui pourrai semble t-il servir de script mais je n'ai rien trouver de concret es-ce possible ?
  
• j'ai vus le tuto lua sur le site mais malheureusement on ne peut que manipuler des classe et non pas en créer avec le binding présenter (lunar)

Merci d'avance.

[pyros]

Salut,

Dans mon ancienne boite on utilisait python pour scripter une appli en c++. Le binding python/C++ est très simple parait-il et je n'ai jamais eu d'écho négatif de ce langage.

[oxyde356]

Le LUA est très bien aussi et souvent utiliser pour scripter les moteurs de jeux vidéo (par exemple Supreme Commander qui est très largement scripté). De plus il existe de nombreux binding qui te permettent de faire ce que tu veux.

[Blustuff]

Ce n'est pas vraiment le forum adapté pour cette question qui n'a absolument rien à voir avec le c++. D'abord, une chose essentielle : ce n'est pas parce que beaucoup de gens utilisent un langage que ce langage est nécessairement bon, ou qu'il est le plus adapté à ce que tu veux faire.

Il y a d'autres langages de script, moins connus : squirrel, game monkey. Ils sont fait spécifiquement pour le développement de jeu mais l'intérêt n'est pas évident.

L'enjeu du choix d'un langage ou d'un autre n'est pas très important. Si c'est un projet personnel, plus important que tout c'est que tu aimes programmer avec ce langage. Même si le langage est pourri, le fait que tu aimes développer avec changera tout et le placera en première place.

Quelques indices peut être pour t'aider à chercher :

Python : Langage très innovant, un certain nombre de concepts assez intéressants peuvent t'aider, mais il ne faut pas que tu sois réfractaire à l'indentation comme syntaxe.
LUA : Langage simple dont la puissance est bâtie sur l'ajout de modules. (Par exemple, il faut un module pour utiliser des classes) On considère que c'est la grande puissance de LUA, mais note que c'est en fait à de nombreux égards un inconvénient car les features classiques des langages ne sont jamais aussi bien intégrées par un module LUA que s'ils avaient été dans le noyau du langage.
Squirrel : Inspiré par LUA et Python majoritairement, mais avec une syntaxe C-like. (probablement l'argument marquant pour ceux qui l'ont choisi) Il y a de bons choix mais le langage (et les compilateur/VM) manquent de maturité et de pérennité.
Game Monkey : Je n'ai pas encore essayé celui là. Il a, il me semble un certain nombre de features intéressantes, notamment l'intégration d'automates qui sont monnaie courante dans les jeux.

A titre personnel, je pense que plus le projet est gros (et un moteur de jeux est gros) moins il est intéressant d'utiliser LUA au profit de langages plus complexes comme Python. La légereté de LUA ne devient plus un argument intéressant, et on regrettera l'absence d'un certain nombre de constructions des autres langages.

Et enfin, j'aimerais signaler le Unreal Script, non pas comme langage à utiliser puisqu'il est il me semble nécessairement lié au Unreal Engine, mais comme langage curieux à aller voir puisqu'il innove dans l'intégration de concepts qui sont centraux dans le développement des jeux commerciaux, et qui ont de grande chances d'être utiles dans n'importe quel jeux : on peut se demander comment faire les choses aussi bien dans d'autres langages.

[Klaim]

Ce n'est pas vraiment le forum adapté pour cette question qui n'a absolument rien à voir avec le c++.

C'est une érreur fondamentale : le choix du language de script dépends énormément du language sur lequel l'application scriptée va reposer.

Surtout dans le cas de C++, il y a des choses languages plus ou moins adaptables.

Voilà ce que j'ai accumulé comme connaissances :

Lua

Utilisé massivement dans l'industrie du jeu vidéo, pour plusieurs raisons.

1. c'est très léger niveau mémoire
2. c'est très facile à intégrer : tu copies colle les sources dans le projet et hop c'est pret. Ajoute LuaBind pour aider au binding.
3. c'est rapide : une des language de script à embarquer les plus rapides du moment
4. la syntaxe est minimaliste : ce qui est souvent un avantage pour mettre en place un dialecte spécifique à l'application.

Ce dernier point est aussi un handicap parceque même si il est possible d'ajouter des nouveaux paradigmes au languages (comme l'orienté objet), il est parfois préférable d'avoir un language moins minimaliste tout en restant puisssant.

D'où les alternatives.

Python

C'est un language carrément super puissant et facile à suivre.

En revanche, ça n'a pas été pensé dés le départ pour être embarqué dans une application. Du coup le coup en mémoire peut être couteux, par exemple si le jeux vise la console. Sur PC ça devrait aller, on perds juste quelques megas.

La vitesse n'est pas son fort mais généralement on ne verra pas de différence sauf si on met beaucoup de code purement mécanique de gameplay dedans.

L'intégration au C++ est couteuse : Boost.Python n'est pas si trivial que ça et implique boost (ce qui est parfois innacceptable).

Si tu veux y aller avec une solution admise et "simple", choisis l'un de ces deux là.

Si la syntaxe de Lua ou de Python ne te suffit pas, ou si tu veux une meilleure intégration à C++, les autres alternatives sont interessantes :

Squirrel, AngelScript, Game Monkey, Io

Tous interessants, marchent globalement comme des Lua avec syntaxe "a la javascript" ou "a la c++" pour la plupart.
Ils sont plus couteux en mémoire et vitesse que Lua mais troquent cela contre une syntaxe plus "complete".

Pour moi, ils se valent tous sauf sur le plan syntaxique.

ChaiScript

Un des deux seul languages que je connaisse qui sont explicitement fait pour profité d'être embarqué dans une application spécifiquement C++.

En gros, ce sont juste des headers, donc tu inclus et c'est intégré. Pour le binding, ça profite des mêmes techniques que pour LuaBind, donc c'est très facile.

Pour la syntaxe, ça ressemble pas mal a du C++ symplifié, donc ça peut rebuter selon le type d'utilisateur que tu vas avoir dans tes scripts.

Je te conseil de jetter un oeil parcequ'il est très prometteur.


Falcon

Celui ci est à mon avis le plus intéressant mais est tellement peu connu que je ne peut le recommandé qu'à ceux qui maitrisent. En plus ils sont en train de sortir une nouvelle version carréement mieu que ce qu'il y a actuellement de dispo.

En gros, syntaxe qui ressemble à Python ou Ruby, mais avec bien plus de paradigms.
C'est plus lourd que Lua niveau mémoire, mais moins lourd que Python.
C'est totallement pensé pour l'intégration avec C++ (le language et tous les modules sont implémentés entièrement en C++).

Par contre le binding n'est pas forcément toujours super évident parcequ'ils ont une aproche non-naive du problème. La nouvelle version doit simplifier l'intégration mais t'obligera a comprendre ce que tu es exactement en train de faire.

Cela a des avantages si ton application va être utilisée pour beaucoup de choses subtiles (comme pour un des jeux que je fais), mais sinon ça reviens à avoir un Python en "pensé pour l'intégration C++".

Et surtout : c'est aussi rapide que Lua à l'execution.

Pour te donner une idée du type de choix :

- pour un prototype de jeu rapidement développé, j'ai utilisé ChaiScript - dans le genre rapide à intégrer ya pas mieu;
- pour un jeu développé sur NintendoDS, j'ai utilisé Lua (pour limiter les coups perfs/mémoire). (cela dit ça peut être important sur certains jeux pc aussi évidemment)
- pour un "gros" jeu sur lequel je travaille, j'ai besoin d'un environnement de scripting plus poussé mais totalement pensé pour l'intégration au code C++ du jeu, donc j'ai choisis Falcon. C'est un choix un peu plus difficile à faire parceque j'ai hésité avec Python. La vitesse d'execution et l'intégration au C++ m'ont fait préféré Falcon. Je pense qu'il est interessant de suivre ce language au moins de loin quand ont veux avoir un language de script avec C++ sous la main.

[Klaim]

J'ai oublié d'ajouter:

Dans ton cas spécifique, si je ne veux pas me prendre la tête et selon ce que tu décris, je prendrais ChaiScript :

- tu l'intègres très très facilement;
- tu peux créer (et même hériter) des classes;

Seul éventuel problème : il te faut (certaines libraries de) boost. Si tu ne l'utilises pas, ça te fait une dépendance de plus.

[Blustuff]

C'est une érreur fondamentale : le choix du language de script dépends énormément du language sur lequel l'application scriptée va reposer.

Ce n'est pas ce que j'ai dit. Ce n'est pas parce que le choix du langage de script dépend du langage avec lequel on l'interface que la question doit être posée sur le forum de ce même langage. Le lien est uniquement pratique et n'a pas à voir avec le langage en lui même.

[Klaim]

Ben a priori si, beaucoup même, puisque les gens qui touchent au C++ sont les plus à même de donner leur expérience si l'application est en C++, quel que soit le choix du language de script. Les autres ont des chances de faire des suggestions innapropriées sous prétexte que le language de script est mieu. Par exemple, si on suggère Ruby comme languge de script, sous pretexte que le languge es sympas, c'est une très mauvaise idée du point de vue d'un projet C++. De même, si on était en Java, des scripts Groovy seraient interessants, mais n'auraient strictement aucun interet en C++.

Donc pour moi, ça compte beaucoup, et mieu vaut demander dans le forum lié au language de l'application.

Mais on a le droit de différer d'avis, evidemment.

[Joel F]

perso, LUA ou Python sont clairement effectivement les 2 top a considere avec l'integration C+.

Klaim, un chtit lien pour Falcon ?

[Davidbrcz]

....
Klaim, un chtit lien pour Falcon ?

http://tinyurl.com/6c6glho

Oui, oui, ->[]

[Goten]

2. c'est très facile à intégrer : tu copies colle les sources dans le projet et hop c'est pret. Ajoute LuaBind pour aider au binding.

C'est même pas vrai quand on pousse un peu. La virtual stack peu être une vrai plaie.
Fin, tiens, jsuis pas le seul à le dire :
http://julien.danjou.info/blog/2011.html#Why_not_Lua

(accessoirement auteur d'awesome wm qui je le rappelle utilise Lua pour le scripting (conf / widgets etc))

[Klaim]

perso, LUA ou Python sont clairement effectivement les 2 top a considere avec l'integration C+.

Klaim, un chtit lien pour Falcon ?

Ouep http://falconpl.org/

Cela dit avec la nouvelle version qui vient et le passage à git (avec mirroir sur github mais je sais pas si il est souvent mis à jour), visiblement le site va radicalement changer dans les jours/semaines qui viennent. Tu peux quand même déjà avoir un aperçu.

[Klaim]

C'est même pas vrai quand on pousse un peu. La virtual stack peu être une vrai plaie.
Fin, tiens, jsuis pas le seul à le dire :
http://julien.danjou.info/blog/2011.html#Why_not_Lua

(accessoirement auteur d'awesome wm qui je le rappelle utilise Lua pour le scripting (conf / widgets etc))

Oui mais je parlais plutot de ce que ça te coute d'intégrer le projet (pas le code) dans ton projet. LuaBInd règle une grande partie de ces problèmes. Quasimment tous les autres languages ont le même souci de toutes façons, même si ya des facilités dans certains.

Mais globalement je suis d'accord avec l'article, je pense qu'il y a pas mal de ces raisons qui m'ont incité a envisager Python, puis à m'interesser a d'autres alternatives (Falcon) pour mon jeu.

Edit> Un bémol cependant : quelques points de l'articles sont particulièrement naifs (et on dirait que le mec ne connait pas LuaBind). Notemment le point sur la taille qui est hyper importante même pour une application sur PC. Déjà, allez dire aux développeurs de jeux sur console que ça compte pas, ou même pour déveloper sur n'importe quel téléphone/smartphone. Ca compte, c'est super important et globalement ça coute aussi au niveau de la rapidité d'éxécution.

Personnellement c'est principalement le manque de paradigms qui m'empêche d'envisager Lua comme mon systeme de script par defaut sur des nouveaux projets C++.

[Blustuff]

Notemment le point sur la taille qui est hyper importante même pour une application sur PC. Déjà, allez dire aux développeurs de jeux sur console que ça compte pas, ou même pour déveloper sur n'importe quel téléphone/smartphone. Ca compte, c'est super important et globalement ça coute aussi au niveau de la rapidité d'éxécution.

L'auteur n'a pas tout à fait tort en ce sens qu'il y a un accent publicitaire énorme mis sur le nombre de lignes de code. Sur Wikipédia, on trouve un comparatif des langages de script avec le détail du nombre de lignes de code des compilateurs / machines virtuelles. Si la taille du binaire est importante, le nombre de ligne de code n'intervient pas dans des considération de taille pour l'embarqué. Et même si on regarde la taille des binaires et non la taille des sources, on se bat pour des tailles insignifiantes même pour des téléphones portables.

L'argument de la simplicité de LUA pourrait tenir. Moins de ligne de code, ça signifie un code moins bugué et plus facile à maintenir ou faire évoluer. Dans la publication scientifique décrivant l'implémentation de LUA il est vanté le fait que la compilation se déroule en une passe. C'est fantastique. Enfin, c'était fantastique il y a vingt ans, quand les ressources CPU étaient si maigres qu'il fallait impérativement que la compilation soit optimisée pour ne pas passer plus d'une nuit à compiler. Aujourd'hui, dans un compilateur moderne, on abuse du nombre de passes parce que ça simplifie la compilation sans agir de manière notable sur le temps d'exécution. Il est préférable de prendre le temps de construire un arbre syntaxique plutôt que de produire directement du bytecode dans un analyseur LL. Utiliser des représentations intermédiaires éprouvées en compilation permet d'assurer une bien plus grande facilité de validation et d'évolution du compilateur. Mais ça augmente aussi le nombre de lignes de code, sans forcément augmenter la taille du binaire. C'est le genre d'absurdités qu'on trouve dans LUA et dans d'autres langages de script qui font la course à la simplicité.

Pour sortir de mon hors sujet donc, je concluerai en disant que la simplicité de LUA est un peu fausse, qu'il faut s'en méfier et ne pas lui sacrifier les avantages d'autres langages. Ce qui fait bien entendu que LUA reste un langage tout à fait raisonnable quand il s'agit par exemple de définition de donnée ou de fichiers de configuration, ce qui ne nécessite pas plus que ce que LUA apporte.