Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

07/07/2009

Tools of The Trade: Introduction to virtual machines and scripting languages

De nos jours, l’utilisation des langages de script en cours de développent s’est grandement généralisé, pourtant il suffit de mentionner le besoin de debugger une machine virtuelle (ou VM de son petit nom) pour en général envoyer des frissons glacés dans le dos de tout programmeur un tant soit peu sensé.

 

Retour sur un sujet plus ou moins à la mode, et en tout cas membre de la trousse à outil moteurs des jeux modernes.

 

Le langage de script (et la VM généralement associées) participent de la notion de moteur « data driven » i.e permettre de séparer la logique du jeu (règle, scénarisation, entité, IA…) de la logique système (rendu, inputs, gestion des assets…). Dans un monde idéal, et si on pousse cette logique au bout, le langage de script doit permettre de décrire n’importe quel type de jeu avec le même moteur (ce qui reste à ce jour une complète utopie).

 

Pour ce faire, au fond, peu importe le langage. Javascript, Python, Lua, même Lisp, ils ont tous des avantages et des inconvénients qui doivent être mesuré au regard de considérations comme la productivité, la lisibilité, la maintenance ou les performances de la VM. Si l’idéal cité plus haut est l’objectif, plus le langage sera générique (et donc expressif), plus l’on pourra décrire de jeu différent.

 

Mais ce n’est parfois pas la bonne voie.

 

Après tout, à quoi bon prendre un langage de script si il faut qu’il soit « Turing Complete » ? Autant garder le bon vieux C ou C++. Du coup, il y a une autre approche qui tient plus du « Domain Specific Langage », ou DSL pour les intimes.

 

L’utilisation d’un langage de script propriétaire (Unreal Script par exemple) trouve une origine simple : pour développer un jeu moderne, on a besoin de manipuler un certain nombre de notions de haut niveau qui sont plus ou moins liés aux spécificités du moteur ou du game design, notions qui ne sont tout simplement pas disponible de façon native dans des langages plus bas niveau comme le C ou le C++, ou plus générique comme LUA.

 

Décrire de nouveaux types d’acteurs en les composant plutôt qu’en les dérivant, abstraire et nommer des notions spécifiques au gameplay, ajouter des meta data avec des mots clefs qui serviront pour l’édition ou le streaming ou la sérialisation ou la sauvegarde ou encore la réflexion, créer des structures de contrôles permettant de décrire des machine à état (Finite State Machine) ou un système de messagerie nativement supporté par le langage, etc etc…

 

Le langage propriétaire permet de façonner les scripts pour intégrer toutes les notions haut niveau spécifique au domaine du jeu, ce qui est parfois plus délicat avec des langages génériques. C’est en cela qu’ils tiennent plus des DSL, mais le jeu en vaut parfois la chandelle.

 

Dans tout les cas, on se retrouve dans la grande majorité des choix de langage à devoir générer du bytecode (version compilé des scripts), bytecode qui sera exécuté en temps réel dans le jeu par une (ou plusieurs) machine virtuelle. Et c’est là que la magie opère.

 

Comme son nom l’indique, la VM n’est ni plus ni moins qu’une émulation d’un système qui n’existe pas dans la réalité. Comme toute machine, la VM est souvent doté d’un certain nombre de registre, d’une stack d’exécution, d’un système d’interruptions, d’un gestionnaire mémoire (si les allocations sont permises) etc etc. A ce titre, le bytecode lui opère comme de l’assembleur classique que l’on exécute grâce à la VM.

 

Du coup, le bytecode devient lui-même donné, au même titre que toutes les autres assets (assets que le bytecode peut être amené à référencer dynamiquement). En séparant le code logique du code système, on augmente la stabilité et la réutilisabilité du moteur, et, si tout se passe bien, l’expressivité et la productivité du programmeur script. Et dans certain cas, on permet peut être même de supporter le live editing des scripts (après tout, le bytecode n’est qu’une donnée comme une autre).

 

Mais évidemment, tout cela à un prix. En premier lieu, le bytecode va obscurcir ce que le jeu doit faire du point de vue du moteur. Sans un bon outil de debug du script, bonjour les nuits blanches. La VM elle-même est un composant complexe, peut être l’un des plus délicat à l’œuvre dans le moteur, et debugger son fonctionnement est en général assez intimidant.

 

Le compilateur de script générant le bytecode, étant en principe dissocié des considérations hardwares de la machine, ne peut pas effectuer beaucoup d’optimisations efficaces (à la différence du compilateur C ou C++). Et d’ailleurs, ce n’est pas forcément son propos : la VM agissant comme une couche d’émulation sur le hardware, il ne faut pas en espérer grand-chose du point de vue des performances.

 

Du coup, il est parfois primordial de garantir que seul du « code froid » soit décrit en script (code exécuté peu de fois par frame), à l’opposé du « code chaud » (implémentation d’algorithmes faisant appels à des centaines de boucles par frames et/ou nécessitant l’accès à une masse de donnée conséquente). En script, on cherche plus à décrire des structures de données qu’à implémenter des algorithmes complexes.

 

Implémenter le pathfinding ou la gestion des listes de rendu en script n’est pas la meilleure façon d’obtenir le frame rate optimal.

 

Et je n’ai abordé là que les features les plus simples d’un langage de script.

 

Parfois, on veut pouvoir faire appel à une méthode moteur directement depuis le script, ce qui implique encore plus de travail en terme de RTTI. L’inverse est vrai aussi d’ailleurs, puisque l’on peut désirer que le moteur face appel à une routine script depuis le code C.

 

On peut souhaiter suspendre l’exécution d’un script, le temps que le moteur effectue un calcul complexe (collisions, IA avancée), puis reprendre le script là où on l’avait arrêté. Enfin, on peut aussi imaginer de décrire des portions de code parralèlisable, comme deux FSM travaillant sur deux entités différentes par exemple.

 

Pire, certains langages permettent d’insérer directement dans le script du code C ou C++, ce qui implique que le jeu doit être compilé en plusieurs passes (compiler le script, puis compiler le jeu).

 

Bref, si la VM part d’une bonne intention, c’est aussi probablement l’un des composants les plus problématique dans un moteur moderne, et en tout cas l’un de ceux qui peux monopoliser un temps de développement conséquent. Après tout, c’est le cœur du jeu en principe.

 

Personnellement, pour mes outils de prototypage, j’ai choisi une autre approche.

 

Je fais en sorte que le langage de script que je défini puisse être compilé en code natif C et C++. Ca me permet d’effectuer toute une passe d’optimisation et d’extraction d’informations en amont, tout en bénéficiant de la facilité de debug et de liberté d’implémentation dans le moteur.

 

Le code ainsi généré ne matche pas celui du script à 100%, les abstractions moteurs ne sont pas forcément équivalentes à celle de mon script, mais le process de conversion est suffisamment simple pour permettre d’annoter le code afin de permettre un debug tout à fait raisonnable, sans sacrifier mes performances.

 

Et vous, quel est votre approche ?

Commentaires

En général, on m'a toujours vendu un système de scripts avec ces qualités:
- Gain de temps en production
- Séparation gamecode/engine
Cela au pris de peu de pertes de performances (bytecode/VM).
Le gain de temps en production ne m'a pas paru si évident que cela. Je me sent les mains liées quand je fais du script par rapport au C/C++. Ne pas avoir à relancer le jeu pour tester une feature et ainsi gagner du temps n'est pas toujours automatique et peut être prévu en amont. Le débuggage est difficile voire inexistant et l'IDE jamais aussi poussé qu'un visual.
La séparation gamecode/engine peut être faite sans VM. Aux architectes de bien prévoir le coup.
La différence de performances est assez importante dans ce que j'ai vu (LUA sur PS2 et PSP). Suffisament pour qu'on recode des 'classes' LUA en C++ et qu'on code aussi le binding, et qu'on reteste et qu'on relivre....
Le bytecode peut aussi être compilé pour une target (HLSL vers carte graphique, bytecode LUA vers code x86).
L'utopie d'investir dans de la technologie (moteur 3D) interne et de rajouter une couche de VM par dessus pour pouvoir 'pisser' du gamecode dessus que ce soit du prototypage interne ou de la production me semble possible néanmoins.
Réutiliser du code C/C++ est une réalité. En faire de même pour du DSL me semble délicate. Déjà qu'en interne , entre 2 livraisons, des méthodes et objets changent dans le moteur et que c'est seulement au runtime qu'on se rend compte qu'on a pas changé le script. Forcément, on a déjà une passe de validation en C/C++. Et les heures passées à lire et relire des pages de LUA pour se rendre compte que la case entre 2 noms de variable est différente...
En tout cas, la ou on gagne du temps, c'est sur l'architecture et la préproduction (utiliser rational rose pour modéliser son gameplay) et pas sur la passe de codage directement.

Au final, je suis plus que partagé.

Écrit par : skaven | 08/07/2009

Salut Skaven ^_^

Ton point de vue me rappelle celui que j'ai lu il y a quelques jours sur le blog de Pierre Terdiman, qui semble avoir été très sévèrement brulé par l'utilisation de LUA à Grin.

http://www.codercorner.com/blog/?p=278

"As for the argument that LUA scripts give faster iteration times because you can reload them without leaving the engine, well, there is some truth to this but it comes with the proverbial grain of salt.

If you put your gameplay code in a separate DLL, there is not much difference in the end between your “game” and, say, a custom format plug-in for Flexporter. Remember Flexporter?

Did you have to shut down 3DS MAX to compile your plug-in and try your changes? Nope, you just had one button to press in Flex. How long did it take to recompile your custom format plug-in? Exactly : something like 2 seconds.

Iteration times for developping your own format plug-in in Flex were super fast. Well there is no difference with KP.

Flexporter is the game engine, the format plug-in is Konoko Payne. It does not compile as quickly as a real Flexporter format plug-in because, of course, there is more code in a “full” game, but the idea is the same, and the iteration times are fast.

Sometimes way faster than what we had at Grin."

Dans l'absolu, Pierre a parfaitement raison.

Pour nuancer, quand le langage de scripts laissent au programmeur l'impression d'avoir les pieds et mains liés, il y a deux explications rationnelles à cela:

- Soit le codeur s'est "stratifié" dans tel ou tel idiome de tel ou tel langage (on les repère souvent dans les forums quand il s'agit de discuter quel ou quel langage est le meilleurs. Les bon codeurs savent qu'il n'y a pas de réponse à cette question.)

- Soit le langage de script et/ou son utilisation est faite à mauvais escient.

Un bon langage de script doit être "libérateur", au sens où il doit me permettre d'exprimer des choses que je mettrai plus de temps à faire ou de façon moins robuste avec le C ou le C++.

Si ce n'est pas le cas, cela signifie que:

- soit le langage est mauvais: si j'ai un jeu que je peux écrire avec des FSM et que mon langage ne permet pas de déclarer les FSM en quelques lignes, EPIC FAIL.

- soit que ce qu'on me demande à faire avec le langage est mauvais: non, je ne vais pas scripter en LUA ma décompression d'animation Wavelet. EPIC FAIL.

En pratique, j'ai souvent vu les deux travers en actions. Le premier apparait souvent quand on réutilise un langage de script sur un nouveau jeu. Le second est fréquent quand le langage est trop puissant, trop "turing complete" et pas assez restrictif (DSL).

Du coup, comme tu le dis, souvent, on se retrouve à devoir recoder en C certaines portions du script (voir la totalité des scripts, à l'aide d'un outils par exemple).

C'est pour ça que les VMs sont de vraies armes à double tranchant ^_^ Ne pas utiliser sauf si on sait ce que l'on fait!

Un exemple intéressant de DSL caché: le système de caméra dans Prince Of Persia, présenté à la dernière GDC.

Dans POP, le comportement des caméras est obtenue par composition d'un certain nombre de composant, chacun s'occupant d'une portion spécifique (FOV, distance au personnage, offset...).

Comme pour les shaders, le résultat final (les matrices de la caméras) sont obtenues en passant de composant en composant, dans un flow spécifié par un "artiste camera".

La création de ces comportements se fait à l'aide d'un outil visuel permettant d'explorer et de reexploiter des combinaisons déjà existante.

Bien. Ca peut surprendre, mais ça, c'est bel et bien du script. Ce qui est formalisé visuellement peut parfaitement être écrit en code, il y a une grammaire, un flow d'exécution, une entrée et une sortie.

Le système de caméra de Pop est une DSL, particulièrement réussi parce que très bien exécuté, et invisible (ou presque) à l'œil de l'artiste...

C'est vers ce type d'approche que je m'orienterai maintenant...

De toute façon, dans l'absolu, dans un pipeline, on n'est jamais aussi rapide que son stage le plus lent: le code n'est pas forcément la passe la plus couteuse. A condition d'avoir un système suffisamment robuste pour ne pas avoir à faire de la maintenance et du debug trop souvent ^_^

Et ça c'est dur... :)

Écrit par : Daz | 08/07/2009

Je vois qu'on traine tous sur les mêmes blogs :).

En fait, le type de DSL dont je me méfie, ce sont celles qui sont le backbone des moteurs. LUA (bon exemple puisque surement le plus utilisé), permet tellement de choses de part sa nature que tu as tendance a tout exposer. Ou du moins, au 1er soucis venu, tu exposes ou caches une fonctionnalité du moteur. Alors peut-etre que certains studios utilisent LUA différement de moi mais je l'ai toujours vu ainsi.
Pour les autres DSL, ceux sans VM, c'est impossible de passer outre. Mais comme dans les caméra pour POP, je les utilise pour une activité spécifique et très très très bien cadrée. Liste non exhaustive des tâches:
- HLSL
- Descriptions de datas
- build system
- extraction de documentation
- génération procéurale
Liste non exhaustive des langages liés:
- C
- perl
- batch
- XML

Écrit par : skaven | 08/07/2009

Ok, puisqu'on étend le sujet aux DSL au sens large, essayons de formaliser les choses.

Les DSL permettent d'utiliser un langage pour décrire des structures de données, les données elle même, de scripter un workflow ou une méthode, et enfin de programmer du code travaillant sur ces instances de données (ou tout ça à la fois, en fonction de la témérité du langage).

En fonction de son usage, toutes les DSL doivent être transformés par le pipeline afin d'être utile.

Par exemple, pour reprendre l'un de tes exemples, de nombreux moteurs ont leurs propres format de descriptions des matériaux (en général, une sorte d'arborescence de transformations), que l'on recompile au gré des besoins en shaders HLSL ou CG.

Un autre exemple: Cruise Control que l'on utilise parfois pour les machines de build utilise le XML pour scripter son comportement.

Dans cet idée, transformer la DSL en bytecode pour être exploité dans une VM en temps réel n'est qu'un exemple parmi tant d'autres pour l'usage des DSL dans les jeux.

Mais on digresse là, n'est ce pas ? ^_^

Écrit par : Daz | 08/07/2009

Sans entrer dans des détails stratégiques, quels DSL as-tu utilisé ces dernières années? Qu'y as tu trouvé de bon/moins bon?
Je suis super pragmatique en ce moment. C'est parce que les vacances approchent :)

Cruise control me semblait bien sur le papier mais quand j'ai vu la quantité de scripts a mettre en place pour un simple build, j'ai pris peur. Finalement, un ensemble de .bat (on peut faire des trucs costaud avec) est finalement efficace.

Écrit par : skaven | 08/07/2009

Pour faire cour, en terme de langages génériques de script: Lua, Pyhton, Javascript... En terme de langages propriétaires: Piccolo (Motivate de Motion Factory il y a 10 ans déjà), Unreal Script, Action Script (Flash), et tout les langages propriétaires des sociétés pour lesquelles j'ai travaillé.

A Darkworks, on utilise Unreal, donc je peut aussi inclure des choses comme Kismet (qui est un langage de script visuel, voir post quelques mois plus tôt). Pour Heavenly Sword, c'était du LUA.

Si on étend ça au DSL au sens large, la liste est encore plus grande évidemment ^_^

Le XML est un DSL permettant de décrire des données. XAML permet de décrire des interfaces. Les fichiers batch que tu rappelles à juste titre.

Même les vulgaires fichiers ini sont une forme de DSL (ils sont parsées, ils ont une grammaire).

En fait, les DSL sont absolument partout dans nos pipelines (juste de façon plus ou moins caché). En faire une dichotomie me semble un sacré travail ^_^

Pour ma part, comme souvent, je n'en ai pas trouvé de meilleurs que d'autres, juste de bonnes et de mauvaises utilisations. Et toi ?

PS: Cruise control est pas si mal, mais il requiert en effet un gros travail de maintenance. Dans le cadre d'un studio, c'est possible (surtout si tu veux distribuer ça sur plusieurs machines), mais dans le cadre d'un projet perso, écrire ses propres batchs me semble plus raisonnable...

Écrit par : Daz | 09/07/2009

il fallait bien que j'intervienne a un moment ou un autre dans cette conversation ;)

Pour re-formuler ce que tu as pu dire sur les DSL voici mon avis sur le sujet. Ce sont des languages de programmation restreints a un champs d'expertise donne. Ils peuvent encoder de choses multiples (structures de donnees, control flow, etc.) en utilisant une syntaxe dediee et donc plus rapide a assimiler et souvent assimilable par d'autres personne que les programmeurs (puisque la syntaxe est censee modeliser le domaine d'expertise, les experts de ce meme domaine devraient pouvoir s'y retrouver sans pour autant etre des programmeurs (avertis ou non) ).

XML est language de modelisation (modeling language) et le nombre de parser disponible fait qu'il a ete utilise pour modeler des DSL (ex de cruise control pour le systeme de build). Ce pendant c'est un language extrement verbeux, tres bien pour la modelisation de donnees dumpees et interpretees par un ordinateur, mais tres chiant a ecrire pour l'humain. XML n'est donc pas une DSL, mais on peut utiliser les parser XML pour obtenir des abstract syntax trees, ce qui fait 50% de la dsl ;P

skavel: les avantages des dsl sont multiples. a mon sens deux des plus importants sont qu'ils offrent la possibilite a des non-programmeurs de modeliser les problemes et solutions lies a leur domaine a l'aide d'un outil simple (visuel sous forme de gui ou texte sous forme d'un language dont le scope est restreint). Le second point important c'est l'abstraction que t'apporte un tel outil : tu peux lui laisser generer du code specifique dans un language adapte a tes besoins runtime, ou generer le data , ou encore un peu des deux. Et tu peux changer l'utilisation que tu en fais quasiment n'importe quand sans impacter les differents corps de metiers (finalement l'outil reste l'outil, qu'il produise de la donnee ou du code l'utilisateur s'en fou).

Ce que j'ai pu voir de bien, c'est que ca apporte une reflexion plus intense quand au domaine des problemes que l'on rencontre et donc une analyse de bien meilleure qualite. Ca permet aussi de resserer les liens entre experts du domaine (les utilisateurs des dsl) et programmeurs, puisque le process de creation des dsl prend souvent la forme d'un echange programmeur - expert pour utiliser les bons mots clefs ou interface visuelle et donc de la des discussion longues mais enrichissantes sur la forme que doit prendre l'outil. Cela donne generalement des produits (dsl) plus performants et donc un pipe plus fiable.

Par contre le gros defaut que j'ai pu rencontrer des dsl, c'est que cela tend assez rapidement a devenir turing complete :P On commence par modeliser le premier probleme, puis le second , puis le troisieme qui n'est pas exactement du meme domaine mais tres lie, puis le quatrieme ...
Lorsque cela arrive, il faut que le programmeur soit tres attentif, et puisse expliquer au troisieme probleme qu'il vaut mieux creer une nouvelle dsl pour un probleme d'un nouveau domaine, plutot que d'etendre un domain specific language a un nouveau domaine (et donc perdre la specificite).

C'est en ca qu' on arrive a des languages de programmation generale avec des mots clefs specifiques a un domaine et qui, de ce fait, seront utilises par des programmeurs et non des experts d'un quelconque domaine.

Donc la (plus grande?) difficulte des dsl c est de les garder specifique au fil du temps !
La seconde difficulte des dsl c'est de bien choisir l'interface , les mots clefs qui decriront au mieux le domaine, etc. Enfin ca c'est proche du design d'API et finalement les programmeurs qui peuvent faire de bonnes API ou qui se sont interesse au sujet , seront les meme qui designeront des languages specifiques ...
Comme dit le dicton "library design is language design"...

my 2 cents ....
Gab'

PS : desole pour la longueur de ce post ...

Écrit par : Gabriel Ware | 09/07/2009

Salut Gab ^_^

Merci pour ces précisions, j'y croyais plus dis donc ;-)

Il faudra vraiment qu'on prenne le temps de redéfinir ce qu'on peut/dois faire avec les DSL autrement qu'autour de la machine à café. J'avoue que je n'avais pas fait le rapprochement entre le design des librairies et le design des langages, mais en effet, c'est très juste !

Tu poses aussi à juste titre la question de l'évolution des DSL, de leur construction. Comme beaucoup de chose dans nos process, on part du postulat que la DSL va grandir itérativement, au grè de la découverte des problèmes au cours de la prod.

Cela implique dés le départ que la DSL et le code associé puisse autoriser cette extensibilité. C'est l'une des premières propriétés fondamentales à garder à l'esprit.

Une DSL peut grandir dans plusieurs directions, elle peut aussi avoir des features qui peuvent devenir obsolete. Bien gérer ce processus, et savoir quand il faut séparer un langage pour en faire deux, c'est très important.

Comme beaucoup, je crois au principe de "simple is beautiful". Le problème de beaucoup de langage de script, c'est qu'ils essayent d'en faire trop (genre 2000 mots clefs différents, et 150 features par exemple).

Il y a aussi un autre problème que les programmeurs doivent garder à l'esprit: souvent, on t'impose (ou tu t'impose) une DSL déjà existante, ou/et difficile à étendre et à maintenir.

Dans ce cas, surtout si il y a une VM dans l'histoire, il faut garder à l'esprit que c'est peut être là que va se jouer pas mal de noeud de tensions au cour de la prod: performance, scripting, mémoire... Si la VM permet trop de choses, il faut mettre en place un certain nombre de garde fous.

A priori, on est bien tous d'accord, les DSL font partie de la trousse à outils de tout bon programmeur moteur... ^_^

Écrit par : Daz | 10/07/2009

et puisqu'on parle de DSL:

Soccer-Fun: Teaching Functional Programming
...a domain specific language for simulating football. ...

We have used Soccer-Fun in teaching during the past four years. We have also experience in using Soccer-Fun for pupils in secondary education. ... It engages students to problem solving with functional programming because it allows them to compete at several disciplines: the best performing football team can become champion of a tournament; the best written code can be awarded with a prize; students can be judged on the algorithms used. This enables every student to participate and perform at her favourite skill. ... It can be implemented in any functional programming language that supports some kind of windowing toolkit.


http://lambda-the-ultimate.org/node/3483

Écrit par : Daz | 10/07/2009

En ce qui concerne une definition plus "concrete" des DSL, je crois que c'est un des enormes probleme de la technique.
C'est un exercice tres difficile et, malgres le fait que la technique existe depuis des annees, personne ne s'est mis d'accord sur une definition formelle, des exemples clairs et precis, des bornes pour definir a quel moment la DSL n'est plus specifique, ou encore un process decisionel pour choisir si oui ou non c'est le tool qu'il faut etant donne un probleme.

J'ai recement eu l'occasion d'ecrire un abstract sur le sujet qui sera "publie" un jour ou l'autre ;)
Pour les gens interesses, Martin Fowler est, a mon sens, la personne la plus proche d'une bonne definition de ce qu'est et font les DSL (http://martinfowler.com/dslwip/) .


Gab'

PS: attention, je peux tres rapidement poluer les commentaires de blogs techniques ! mais je vais essayer de ne pas trop poster sur ton blog, et plutot sur le mien!:P

Écrit par : Gabriel Ware | 10/07/2009

Lol ^_^

Je serai déjà heureux si tu continues de poster sur ton blog vieux ;-)

Écrit par : Daz | 10/07/2009

Alors le script dans les jeux c'est un domaine où j'ai fais pas mal de conneries, on va donc les partager...

Sur mon premier jeu, Desperados, comme on était chaud comme la braise vu qu'on sortait tout juste de la fac, qu'on avait aucune méthode de dev, et que notre grand leader cumulé les postes de directeur artistique, lead game designer et chef de projet (et que donc il avait le temps de rien controller en fait) on a écrit notre propre langage de script.

... et genre on a tout fait, le langage à coup de flex et bison, la machine virtuelle qui exécutait le bytecode toussa. Au moins maintenant je peux frimer avec les mecs qui ont fait de la compil en disant que moi je l'ai utilisé en vrai dans le cadre de mon job. Autant dire que c'était beaucoup de temps utilisés pour quelque chose qu'on aurait gagné à intégrer de déjà tout fait. Surtout qu'après on se prends la tête à sérialiser des machins etc... en gros la maintenance du truc a consommé du temps, surtout qu'on l'a réutilisé sur les deux jeux suivants en ajoutant des fonctionnalités au fur et à mesure.

Le truc ressemblait beaucoup à du C++ fortement allégé, il permettait de surcharger le comportement des ennemis dans le jeu et ça a très bien fonctionnait même si rapidement on a eu la question du "mec qui a pas de formation en code et qui peut claquer un truc infâme" genre un if avec une conditionnelle de 72 lignes pour tester les états des acteurs. Bon ce type bosse maintenant chez Darkworks donc c'est plus *mon* problème :)

Après j'ai fait pas mal de test pour intéger python, simplement parce que je trouve que ce langage est beaucoup plus adapté à des débutants et à de la programmation structurée que Lua. D'ailleurs j'ai jamais aimé Lua, même si visiblement il a en parti gagné la guerre.

Sur DS on avait à un moment besoin de scripts, on a tenté de faire rentrer python dedans mais après il y avait plus trop de place pour faire autre chose, donc on a finalement du Lua (oui je me mords la main au moment d'écrire ça). C'est juste un système d'évènement qui appelle du Lua depuis le C++ pour permettre au LD de customiser des trucs, on a aussi un système pour écrire des minijeux DS en Lua, l'objectif étant de pas mobiliser un programmeur pour des trucs pas trop dure à écrire (bon accessoirement dans les GDs j'ai un mec qui avant a écrit l'IA de desperados, donc c'est loin d'être une quiche en code). Ca n'empêche de faire des code reviews histoire d'instiller la peu... euh d'expliquer aux LD les trucs à pas faire.

Pour résumer je dirais que :
- le scripting c'est important car il permet de donner un levier à la créativité des LD/GD
- un langage limité permet de limiter la casse si il est relaché dans un groupe de LD "pas formé".
- les code reviews c'est bien.
- du langage de script pour le corps du jeu pourquoi pas, mais dans ce cas fournir un langage qui tient vraiment la route (ruby, python) et pas un truc pseudo bricolé qui manque de philosophie à la base.
- pas réinventer la roue soi même
- le XML c'est verbeusement grave.

My 2 cents

Écrit par : Whirly | 12/07/2009

LOL!!! Maintenant, il va falloir que tu me donnes des noms vieux ;-)

Moi aussi, je suis un grand fan de Python dans l'absolu, même si il est encore bien trop "puissant" pour la majorité des cas...

Et en parlant de ça, que penses tu de te passer de VM, et de transcrire le script en C ou en C++?

J'en profite aussi pour rebondir sur ce que le problème des expressions de contrôles (if then else, while do et autres switch case ou équivalent). Ce sont des constructions fondamentales pour être vraiment expressif, mais ils sont la source de bien des prises de têtes.

Est ce que l'on peut s'en passer dans le cadre d'un langage de scripte i.e un langage pour pouvoir exprimer des séquences d'actions ?

Écrit par : Daz | 12/07/2009

Les commentaires sont fermés.