1)  Trouver l'idée

Il n'y a pas de mystère : soit on est créatif et les idées de jeu viennent toutes seules, soit on trouve l'inspiration auprès de l'existant ou de l'ayant existé. Les sources d'inspiration sont nombreuses : d'anciens fascicules ou d'anciennes brochures. Les documents datant des années 1980 font la part belle aux programmes ludo-éducatifs, les idées de jeux simples étaient nombreuses du fait de la saisie à la main du code. des souvenirs de jeux électronique du type « watch and play », des jeux classiques recontextualisés, ...

2) Adapter l'idée

Si le plus dur est d'avoir l'idée, il est absolument nécessaire de réaliser le codage :

• pour voir s'il y a des difficultés majeures
• pour cerner les concepts algorithmiques impliqués
• voir si certaines subtilités de programmation devront être exposées aux élèves, etc.

Pour réaliser les scripts, il nous a aussi semblé intéressant de travailler à partir d'une grille qui sert à élaborer une version de travail. Cela permet de modéliser facilement des contextes tels que des terrains de jeu, des labyrinthes... Les déplacements sont alors plus faciles à modéliser car il suffit de se déplacer de case en case.

3) Simplifier le script le script pour le rendre accessible aux élèves

Cette phase d'analyse est a priori assez complexe à mener. Nous avons trouvé pertinent de travailler à plusieurs sur ces projets de manière à contourner les difficultés et faire évoluer les scénarios envisagés. Nous conseillons fortement ce travail à plusieurs qui permet de mettre au point un scénario accessible aux élèves, ouvert, avec une identification des difficultés qui seront rencontrées, ce dernier point étant difficile à percevoir quand on a mis au point un script fonctionnel. Il ne faut cependant pas oublier que les élèves sont en formation et ne sont donc pas des experts en programmation.
De nombreuses idées que nous pensions développer en scénarios pédagogiques ont du être abandonnées ou ont subi une évolution significative.
On peut ainsi voir dans l'exemple suivant comment nous avons élaboré un code a priori accessible pour des élèves de fin de cycle 4 à partir d'une idée trouvée dans un ouvrage.

4) Le scénario pédagogique

Notre objectif lors de la mise au point ce script n'était finalement pas de créer le jeu initial mais de faire coder un déplacement de type « snake ». Au fur et à mesure des évolutions, la tache s'est concentrée sur ce seul objectif en allégeant le cahier des charges. Le travail d'élaboration et de simplification a permis aussi d'envisager des pistes de différenciation :

a. Proposer des défis pour les élèves les plus performants

Dans l'exemple précédent, le script final obtenu apparaît comme un produit ultime que seuls les élèves les plus performants pourront mettre au point alors que l'objectif pour tous est de réaliser un tour de jeu au cours duquel le renard a un déplacement de type « snake », non accéléré, pour attraper une poule apparue aléatoirement. Il ne doit jamais toucher le bord.
Des défis supplémentaires peuvent alors être proposés aux plus rapides :

• Enchaîner des tours de jeu jusqu'à ce que le renard touche le bord
• Créer un score
• Accélérer le mouvement au fur et à mesure des tours de jeu
• Faire se déplacer la poule

Le script très complet élaboré au préalable permet d'envisager la faisabilité de tous ces défis par certains élèves.

b. Proposer des coups de pouce pour les élèves en difficulté

A contrario, des élèves peuvent avoir du mal à obtenir le script minimal attendu. On peut alors leur proposer des coups de pouce :

• un script en parti réalisé, par exemple celui d'un objet,
• un script en désordre
• un script à lire et interpréter qui permet de lever un obstacle

5 - Des dysfonctionnements à anticiper...

Les choix de fonctionnalité des objets proposés par les concepteurs de Scratch sont générateurs de fonctionnements spécifiques qui peuvent être difficiles à appréhender.
Par exemple, en développant des jeux, on en vient très vite à tester des contacts entre objets pour faire évoluer des scores. Or, lors d'un déplacement, un objet peut être touché plusieurs fois, ce qui modifiera d'autant le score.
Il faut donc bien comprendre ce que sous entend "objet touché" : un premier contact ? Tout contact ? Contact avec le centre de l'objet ? N'importe quelle partie de l'objet ?...
Cela va nécessairement orienter la manière de coder et conduira à développer des astuces de programmation pour rectifier certains dysfonctionnements qui ne seraient pas apparus avec un autre langage.
Le décompte du score dans l'activité Krampouezh en est un exemple. Le codage de la chute d'une crêpe n'est pas « naturel » pour les élèves. Lors des premières expérimentations, nous avons pu constater que certains cachaient la crêpe après un premier contact avec le tas pour qu'il termine sa chute jusqu'au sol.  L'objet, toujours présent même s'il est invisible, continue à détecter le tas de crêpes, le score se modifiant d'autant. L'astuce consistant à modifier l'ordonnée est un obstacle à anticiper : les élèves se retrouveront sinon avec un script qui paraît fonctionner mais pour lequel le score affiché est non fiable.

Découvrir la synthèse et toutes les activités du groupe TraAM de l'académie de Rennes