Dans un billet précédent, j'avais fait l'exercice de développer un petit jeu avec Scratch. L'idée était de m'en faire une référence pour évaluer les alternatives à Scratch.

En effet, Scratch a fait des émules. Soit vers des environnements assez similaires, soit dans d'autres environnements qui en reprennent le langage graphique.

Snap!, de son ancien nom Build Your Own Blocks, fait parti de la première catégorie. Lorsqu'on lance l'environnement, on se retrouve dans un version plus austère de Scratch, mais assez familière. La palette des blocs est quasi identiques, avec les groupes d’événements et contrôles regroupés, tout comme les blocs utilisateurs le sont avec les variables. À l'usage, on fait un peu moins d'aller-retours entre les catégories et c'est assez agréable.

Côté interface, les premiers pas sont sympathiques : on n'est plus dans une application en flash mais dans une application en Javascript. C'est nettement plus réactif et surtout, le bouton droit fonctionne ! Avec le choix de la langue est conservé, on a une première impression de quelque chose de plus abouti.

Cependant, certaines fonctionnalités de Scratch disparaissent. Par exemple, pas de mode vectoriel dans l'édition du sprite, et pas d'ajout de texte dans l'édition bitmap. Vu la pauvreté de l'éditeur de sprite, il vaut mieux passer par un programme externe et importer le résultat. C'est un peu dommage.

Une fonctionnalité hyper pratique de Scratch est que le block \"se déplacer en x/y\" prend les coordonnées actuelles du sprite par défaut lorsqu'il est utilisé. Dans Snap!, le défaut est à 0 pour x et y. Dommage. Un pattern classique de Scratch est de prendre les blocs de déplacement, rotation et zoom avec les valeurs courante pour en créer une séquence d'initialisation. Avec Snap!, il faudra y aller au jugé.

Toujours dans les blocs, la visée est bien meilleure dans Snap! que dans Scratch. On vise l'emplacement recevant le bloc avec la souris, et non pas avec le bord gauche du bloc. Mais à l'inverse, Scratch montre des exemples de valeurs dans les blocs lorsqu'ils sont encore dans la palette, Snap! ne le fait pas, et cela nuit à la découverte des blocs lors de l'apprentissage.

Une chose qui est intéressante dans Scratch est que les références à des sprites réagissent au changement du nom du sprite. Pas besoin d'aller modifier tous les blocs référençant un sprite dont on vient de changer le nom. Snap! à l'air de stocker l'information sous forme de texte indépendant du sprite lui-même. Des bugs en perspective... ou bien de la peur à changer les noms des éléments.

Lequel est le meilleur alors ?

Pour le moment, les deux environnements ont l'air assez similaires avec des éléments mieux d'un côté et moins bon d'un autre. La grosse différence de Snap! par rapport à Scratch est sa possibilité de manipuler des blocs définis par l'utilisateur.

Tout d'abord, les blocs peuvent être définis pour le sprite en cours ou pour tous les sprites. La limitation des blocs définis par l'utilisateur au seul sprite courant est quelque chose qui m'avait déçu dans Scratch. Avec Snap!, je peux donc enfin gérer mes déplacements d'une manière générique.

Snap! peut aller beaucoup plus loin, car le bloc est pour ce système un type de donnée de base. On peut donc manipuler des blocs sans les évaluer, les combiner,... oui, nous avons affaire à un langage fonctionnel. Au passage, Snap! défini quelques types de données, dont des listes, manipulables aussi. C'est puissant, c'est agréable... et cela vient aussi malheureusement avec la possibilité d'écrire des blocs invalides, dont l'impossibilité à être exécutés ne seront trouvé qu'à l'exécution.

Différents

Snap! va plus loin dans les possibilités de programmation que Scratch, tout en conservant les bases de son vocabulaire graphique. Mais Scratch offre une expérience à mon avis plus simple, complète et solide, particulièrement pour l'apprentissage.

Et le truc étrange : il me semble que mon jeu tourne moins vite avec Snap! qu'avec Scratch...