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.

09/02/2009

Script visu-hell

Il y a bientôt presque 10 ans, j’étais en stage à Annecy sur un jeu révolutionnaire pour l’époque : il était scripté à l’aide d’un langage de script partiellement visuel qui s’appelait Piccolo.

 

De nos jours, cette notion de script visuel se retrouve dans pleins de moteurs, Kismet d’UE3 étant l’exemple le plus populaire.

 

 

kismet_2.jpg

 

La dernière fois que j’ai abordé le sujet des éditeurs visuels, c’était pour parler de shaders. Pour être précis, c’était pour se poser la question du bien fondé des éditeurs de shaders visuels.

 

Mais l’idée de scripter visuellement un comportement va bien plus loin que la simple notion de shader. On trouve désormais ces éditeurs aussi bien pour scripter des cinématiques, que des événements dans le jeu, ou pour scripter des IA.

 

D’où viens cette évolution ?

 

Le succès de la notion de langage informatique repose sur les milliers d’années d’évolution du langage humain. En simplifiant à l’extrême, le langage est et reste la technologie la plus avancé pour encoder et transmettre de l’information.

 

Nous utilisons donc des langages de programmation non pas parce que nos machines s’y prêtent particulièrement, mais plutôt parce que nous humains somment des machines incroyablement performantes pour manipuler le langage.

 

Alors, si le langage est la technologie la plus poussé pour manipuler et définir des scripts, d’où viens le besoin de définir des outils graphiques pour faire le même travail ?

 

Le principal problème avec les langages est que le sens de ce qui est exprimé est hautement dépendant du contexte. En d’autre terme, le sens perçus dépend non seulement de la personne qui écrit (l’auteur) et de la personne qui écoute (le lecteur), mais aussi de ce qui a été écris auparavant.

 

En ce qui concerne les langages informatiques, le sens est en règle générale univoque : la machine exécute le code qui a été compilé à partir des textes sources, point barre. Là où le bat blesse, c’est que ce qui a été compilé ne correspond pas forcément à ce que le programmeur pense.

 

Les langages de programmations sont complexes parce que l’ordre d’exécution des instructions n’est pas trivial. Quand on écrit un programme, il ne s’agit pas d’écrire un roman dans lequel chaque chapitre va se suivre les uns après les autres.

 

De plus, la capacité à lire ou à écrire du code source dépend de la capacité de l’opérateur à intégrer non seulement les idiomes du langage, mais aussi le contexte du code en question (ce qui a été exécuté avant, ce qui va être exécuté après, ce qui est attendu en entré et ce qui doit être produit). Le programmeur pour ce faire doit construire un modèle mental du fonctionnement du programme à l’aide du code exprimé dans le langage de programmation.

 

Et ça, c’est dur. Mais alors, vraiment vraiment dur. Et c’est ici qu’entre en jeu la notion de langage visuel.

 

La grande majorité de ces langages visuels reposent sur la même anatomie : Un script visuel est constitué d’une collection de boites - correspondant à diverses actions/états, qui ont diverses entrées/sorties, et des paramètres internes – que l’on a connecté les unes aux autres. Ces boites peuvent parfois s’imbriquer dans des boites conteneurs façon poupées russes.

 

Les scripts ainsi conçus définissent tantôt des machines à états, tantôt des worlkflows, tantôt des graphes.

 

L’attrait principal de ces langages repose sur un principe simple : un dessin vaut mieux qu’un long discours. Et de fait, l’information sur un schéma est incroyablement plus accessible : d’un simple coup d’œil, on a accès à une masse d’informations qui nécessiterait un travail autrement plus ardu si on devait le déduire d’un texte.

 

De plus, il est beaucoup plus facile d’apprendre à lié des boites entre elles que d’apprendre à travailler avec un langage de programmation, n’est ce pas.

 

N’est ce pas ?

 

Tout cela est vrai, tant que les schémas produits sont bons. En fait, en pratique, voilà ce qui se passe.

 

La bonne idée atterrie dans les mains de quelqu’un qui n’est pas programmeur, en général quelqu’un avec un penchant un peu plus artistique, pour qui l’aspect visuel parle naturellement.

 

Cette personne développe des scripts bon an mal an pour définir le contenu du jeu.

 

Quelques mois plus tard, on vous appelle parce que ça « bug », et qu’il faut corriger les problèmes. Quand vous ouvrez le script dans l’éditeur visuel, vous vous retrouver devant un gloubigoulba indigeste de schèma façon spaghetti, avec des dépendances dans tout les sens et au bas mot 3 niveaux d’imbrications.

 

Bref, bienvenu(e) en enfer.

 

Alors, comment une aussi bonne idée peut elle s’avérer aussi dommageable ?

 

Le gain de productivité acquis par l’usage de ces langages visuels est réel. On va plus vite pour assembler visuellement des briques que quand on écrit. Mais la productivité n’est pas forcément positive – en d’autres termes vous pouvez parfaitement plomber un développement si vous ne faite pas attention.

 

Et c’est là le drame. Les langages de programmations sont équipés de toute une batterie d’outils pratiques ou conceptuels pour aider à assurer une productivité aussi positive que possible. Ces outils vont des débuggeurs à l’auto complétion en passant par l’analyse statique du code, les profilers, le développement orienté objet, les design patterns, les différents langages appropriés pour différentes taches, et j’en oublie une pelleté d’autre…

 

Des dizaines d’années de recherches et de développements ont été investis pour permettre au développeur d’aller dans la bonne direction autant que faire ce peux. A minima, ces outils permettent au langage en soi de ne pas devenir par essence un problème.

 

Les abstractions visuelles, elles, n’ont pas eu ce luxe. En somme, en abaissant la barrière de productivité, elles permettent surtout de produire plus facilement du code erroné.

 

Et ce problème n’est pas inhérent aux outils modernes d’un moteur de jeu vidéo. Les langages visuels se retrouvent dans tous les secteurs IT, avec les mêmes symptômes:

 


And in particular, the favorite demo-ware application is their BPEL (Business Process Execution Language) designer. This designer allows you to wire together services by drawing lines between boxes. The lines can include transformations and other sexiness. And it demos great. "Look, just draw a couple of lines here and here, click on the Run button and voila! Instant SOA".


Then, the manager brings it back home and notifies the developers that this is the new tool of choice. When developers start using it, they realize the awful truth: they've been sold a hairball generator. Tools like this work great on really small scales, when it's easy to see all the connections between things. But, as things get complicated, they start suffering from the hairball effect: all the lines start running together, and you can't create a diagram that makes sense to anyone anymore. Perhaps maybe you can fight through this, by creating workflows in chunks, and zooming in and out.


Then reality arrives. Because you create workflows using these tools, you are coding, in the worst possible language (a graphical representation). Thus, you are defining behavior, just like you do when you write source code. But the behavior you define lacks all the benefits you get from writing it in code.


· reuse: you can't really reuse portions of your workflow because their is no method or subroutine functionality (you might get lucky with a sub-workflow). Mostly, people achieve "reuse" by copy and pasting, which you never do in code.


· refactoring: no refactoring, making it harder to identify common workflow chunks for reuse. When you don't have refactoring, you don't watch for opportunities for refactoring as much.


· limited programmability: you don't get if statements and for loops, you get whatever this particular BPEL designer supports. You get flow-chartly looking stand-ins for real decision statements, but they are much more brittle than the facilities offered in modern languages.


· testing: you can't write unit, functional, or integration tests for these workflows. The only real testing option is user acceptance, meaning that the entire universe must be up and running. If you have no unit testing, you also don't have mock objects or other testing techniques common in code.


· hard to diff: lets say you fought the beast and get a non-trivial workflow up and running, and everything is great. In six months, you change it in non-trivial ways, and all is good. Then it comes time to see what's different. BPEL tools don't have diff facilities, so you can either visually diff the diagrams (yuck) or diff 2 10,000 line XML documents (double yuck). BPEL relies on either heavy-weight diagramming tools or raw XML, and nothing in between.


Tools like this fall into the category one of my colleagues identified as doodleware tools. They let you create pretty pictures but collapse under scale.


[ Meme Agora ]

 

Pour conclure, que doit on faire ? Les abstractions visuelles ont une utilité pratique, en particulier là où l’expressivité est un facteur important de la productivité. Difficile de s’en passer.

 

Quelques conseils :

 

- Limitez le scope de ces langages : Si on traite ces langages comme étant des DSL, il est parfaitement imaginable d’en limiter le domaine i.e. scripter un shader ou une machine a état oui, scripter toutes une cinématique, non. Pour les cinématiques, il y a de meilleurs outils (un séquenceur par exemple)

 

- Limitez l’expressivité du langage : Par exemple, vous pouvez parfaitement décider que toute entrée soit liée à une et une seule sortie. Créez des boites spécifiques pour créer des bifurcations par copie si c’est vraiment nécessaire, mais limiter ainsi le nombre de liens qui partent d’un seul point.

 

- Dotez vous d’outils permettant de debugger visuellement le flow : Attention, ce n’est pas une tache aisé. Dans un workflow traditionnel basé sur la notion d’événement, vous pouvez parfaitement passer dans plusieurs boites simultanément.

 

- Agissez en amont : Le comportement est plus facile à exprimer en langage parce que le langage est l’outil le plus puissant qu’il existe pour définir un comportement. Quiconque définit un comportement devient par essence un programmeur, avec tout ce que ça implique.

 

- Exploitez le gain de productivité: En cas de gros pépin, vous pouvez retourner l’avantage des langages visuels à votre profit très simplement. Faites recommencer à zéro le script en question, mais en étant ce coup ci en support de la personne qui l’a écrite à l’origine. Vous irez parfois plus vite à réécrire un script bugée à deux qu’a debugger un plat de spaghetti. Bonus : vous aurez peut être même une chance de faire mieux, plus simple, et plus esthétique.

 

Dans tout les cas, méfiez vous des outils magiques qui permettent de tout faire en connectant 3 boites : ces outils sont toujours merveilleux, géniaux, supers, etc etc… tant que les scripts ainsi écrits fonctionnent…

 

Sinon, ces fameux gains de productivités acquis pendant la production risquent bien de s’envoler en fumée quand le temps du debug viendra.

20:06 Publié dans Code | Lien permanent | Commentaires (2)

Commentaires

J'ai enfin trouvé le temps de lire cet article que je garde de côté depuis un mois.
Juste pour me situer je travaille pour le logiciel Virtools, donc mon opinion n'est pas forcément des plus objectifs mais bon.

À mon avis, le gros problème de ces langages, Virtools inclus, est qu'ils sont vu comme étant magiques, alors qu'ils ne le sont pas. Quand j'enseigne le logiciel à des étudiants, ils pensent que juste en mettant les boites côte à côte le programme va savoir ce qu'ils veulent en faire. Mais malheureusement les compétences nécessaires sont plus importante que ce qu'on imagine.

Quand au fait qu'une image vaut mille mot, c'est vrai jusqu'à un certain point. Quand dans un script, tu as des boites et des fils dans tous les sens, ça devient difficile de comprendre le concept. J'ai eu parfois des sueurs froides en ouvrant certains scripts, que je n'ai d'ailleurs pas encore compris ^^

Écrit par : XGouchet | 08/04/2009

Salut vieux!

Tu as mille fois raisons quand tu évoque le caractère "magique" que ces outils apportent. Ils exercent sur les utilisateurs un pouvoir quasi mystique, car ils ont à la fois l'illusion de la simplicité, et celui du pouvoir d'expressivité.

De mon point de vue, la notion de script visuel, c'est un tank (pour le pouvoir) que l'on as déguisé en Austin Mini (pour l'attractivité). Sauf que - comme tu le soulignes - conduire un tank requiert autrement plus de compétences.

Bon, plus sérieusement, on ne peut pas se passer de ses outils. En tant que programmeur, on as donc la responsabilité de trouver une solution pour bénéficier des avantages tout en contournant les inconvénients...

Et ça, c'est pas facile ^_^

Écrit par : Daz | 09/04/2009

Les commentaires sont fermés.