Scripting
De Ourscraft.
Aller à :
Navigation
,
rechercher
On cherche à tirer profit de trois avantages du scripting : # Accélération du cycle développement - test. Le jeu implémente déjà une combinaison de touche (ALT + BACKSPACE) qui permet de recharger le script. Ainsi, il n'est pas nécessaire de recompiler et relancer l'application, ce qui peut prendre un temps plus ou moins long (15 secondes à 2 minutes actuellement) Poussé à l'extrême, il devient possible de compiler des commandes de script à la volée dans une console en jeu, ce qui rend certains tests plus faciles. # Accélération théorique de la productivité. Les langages de script sont ''censé'' accélérer la productivité en permettant au programmeur d'éviter des tâches administratives telle la gestion de la mémoire ou la manipulation archaïque de structures de données bas niveau. En pratique, je ne suis pas sûr que le gain de productivité existe vraiment, surtout lorsque le laxisme des langages de script permet à des erreurs de se dissimuler alors qu'elles auraient été détectée à la compilation dans des langages plus restrictifs. # Permet à des programmeurs tiers de modifier le jeu une fois celui-ci distribué. En conséquence, un certain nombre de morceaux de code passent du coté compilé au coté interprété. Il s'agit d'un choix performance vs flexibilité. Tout ce qui doit être rapide doit rester du coté compilé tandis que tout ce qui a un intérêt à être ''modé'' doit être passé coté script. On a donc à peu près du coté script : * toute la mécanique du jeu, gameplay, règles de l'univers, etc., * au moins le contrôle du déplacement, les collisions devant probablement être gérées par un moteur physique compilé, * les éventuelles intelligneces artificielles, * l'interface graphique == Choix du langage de script == Il y a pas mal de langages de scripts plus ou moins dédiés au jeu vidéo. J'ai regardé Lua, Python, AngelScript, GameMonkey, Squirrel. Certains de ces langages pas forcément très connus sont très prometteurs mais je les ai jugés encore trop immatures par rapport à nos besoins. Je me suis donc arrêté sur une nouvelle confrontation Lua vs Python. === Arguments en faveur de LUA === * Le langage est mieux connu du public de modeurs. Il est le langage de script de la plupart des gros moteurs de jeu. * LuaJIT semble mature tandis que Pypy nécessite encore beaucoup de boulot. Du coup, on peut obtiendra de bien meilleures performances avec LUA. On ne sait pas encore si la question des performances est pertinente. * LUA s'embarque beaucoup mieux. Très peu de code nécessaire pour intégrer LUA, pas de dépendances parasyte. Et pas besoin de passer par visual studio pour produire une librairie comme c'est le cas pour Python. Embarquer LUA induit un surcout en terme de taille beaucoup moins important que Python pour lequel il faut aussi embarquer la librairie standard. Ça concerne néanmoins des tailles pas forcément significatives. (embarquer Python nécessite 1mo de plus) * Il n'y a pas d'état global, on peut créer autant de machines virtuelles qu'on veut, on peut accéder à la même machine virtuelle avec différent threads ce qui est important niveau des performances : un serveur gérant beaucoup de connexions aura ''probablement'' besoin de paralléliser le traitement de la mécanique de jeu. * Les librairies courantes dans les jeux ont plus souvent un binding LUA que Python. C'est le cas de CEGUI pour lequel le binding Python 3 n'existe pas encore. (mais devrait bientôt exister) * On peut recharger les scripts en réinitialisant la machine virtuelle LUA. boost::python, quasiment indispensable pour embarquer Python afficher des erreurs quand on tente de faire pareil avec Python. * La syntaxe de Python me semble pouvoir causer plus facilement des erreurs, puisque la sémantique peut varier '''tout en restant correcte''' suivant le niveau de tabulation. Ces erreurs peuvent survenir facilement, si le programmeur est fatigué, s'il copie-colle un morceau de code. Elles sont visuellement difficile à percevoir vu qu'on n'a pas localement la confirmation visuelle qu'un bloc de code doit se terminer. * LUA supporte les coroutines. On les dit très utiles pour la programmation d'intelligences artificielles. Pas encore essayé. === Arguments en faveur de Python === * La syntaxe est beaucoup plus concise. Il est possible que ça améliore la lisibilité quoique je n'en sois pas convaincu. Ce n'est cependant pas le temps économisé à taper moins qui sera significatif. * Python 3 a un très bon support de l'Unicode. Les scripts LUA pourront manipuler de l'unicode, mais ça va nécessiter un travail supplémentaire à fournir. * Python a plus de structures de haut niveau. Manipuler des classes en LUA est peu pratique. * LUA est très laxiste quant à l'accès à des variables / champs inexistant. Ce qui peut provoquer des erreurs '''très''' difficiles à retrouver. Je n'ai pas trouvé de moyen d'empêcher cela. La conséquence est que potentiellement le développement Python sera bien plus rapide que le développement LUA simplement en réduisant significativement la phase de debug.
|
Aide
(ouvre une nouvelle fenêtre)
Affichages
Page
Discussion
Modifier
Historique
Outils personnels
Créer un compte ou se connecter
Navigation
Accueil
Communauté
Actualités
Modifications récentes
Page au hasard
Aide
Rechercher
Boîte à outils
Pages liées
Suivi des pages liées
Pages spéciales