[Squeak-fr] Retour d'experience

[FERRERE Frédéric]

Bonjour,

Voici un petit retour d'expérience sur smalltalk/squeak en développement.

J'ai découvert smalltalk/squeak avec le numéro 82 de linux magazine france (avril 2006).

Je ne me suis intéressé qu'à l'aspect programmation donc pas d'Etoys, etc.

Pour pouvoir un peu avancer dans l'apprentissage de nouveaux outils rien ne vaut
un petit challenge. Donc après avoir regardé de près les quelques exemples
de morphs animés dans l'image de squeak, ou bien les tutoriels sur le net,
je me suis lancé dans le portage d'un jeu.

Le jeu original est un jeu sorti en 1985 sur Amstrad CPC.
Ce choix a été guidé par un brin de nostalgie :).
J'ai réutilisé les graphismes originals (mes talents
de graphistes étant inexistants) pour me concentrer uniquement
sur le moteur du jeu.
L'utilisation des graphismes original n'est qu'une étape, il me faut trouver
un graphiste :)
Comme le monde du jeu vidéo, en termes de développement, m'est totalement inconnu,
j'ai quand même passé beaucoup de temps pour faire le lien entre mes besoins
et l'API squeak dont la description des classes ne m'inspirait pas grand chose
(ex: BitBlt).

D'ou de nombreuses heures pour éplucher ici et là morceaux de code ou idée
sur la gestion des collisions, de l'affichage, de la superposition des dessins
et la gestion des évènements clavier (voir mon mail d'avril 2006).
Je pense avoir réinventer la roue plusieurs fois :)

Comme je n'ai pas forcément beaucoup de temps à consacrer à cette activité
le tout traine un peu, mais aujourd'hui le moteur est suffisament avancé
pour que je fasse un petit bilan.

L'environnement de développement Squeak est vraiment très plaisant à utiliser
, les différentes bibliothèques sont suffisament fournis pour qu'on trouve
les outils nécessaires (son, clavier, affichage).

Les difficultés/Inconvénients : la documentation
La documentation est, à mon sens, insuffisante ou tournée vers ceux qui ont déjà
suffisament d'expérience.
Il en manque principalement sur la description des classes ou des catégories.
En fait lorsque l'on rencontre un problème on ne sait pas trop comment chercher.
Par exemple pour supprimer les halos d'un morph il faut surcharger la méthode wantsHaloFromClick
qui n'est pas documentée.
Heureusement il y a le wiki et la liste de diffusion de la communauté.

Pour résumé, la prise en main du langage est assez rapide, la prise en main
de l'environnement aussi.
Côté développement la gestion du code et de l'image est un peu déroutante
(sauvegarde projet, sauvegarde monticello, sauvegarde image), là encore sans le wiki
et la liste point de salut :). Concernant l'outil de gestion de version de code Monticello,
ne connaissant pas parfaitement tous les concepts, je n'ai pas saisi le rôle des boutons Adopt et Merge.
Il faut passer beaucoup de temps dans le code pour trouver une classe et/ou une méthode qui correspond
à ce qu'on cherche.
Il manque peut être une documentation à la java ou à la php sur les API
avec leur description et ce que l'on peut en faire.

Pour en revenir au jeu, vous pouvez voir une petite
vidéo
- format ogg : http://frederic.ferrere.free.fr/sorcery.ogg
- format mpeg4 : http://frederic.ferrere.free.fr/sorcery.mpeg

Voici quelques informations sur la conception :

La scene graphique est construite en trois couches (3 niveau de morphs) :
1) le décor est une image gif (640x288) contenue dans un Morph.
2) Les autres éléments (joueur, objets, enemis) sont des morph que l'on ajoute
au décor (couche 1).
3) un décor d'avant plan un morph (640x288). De la sorte, les objets de la couche 2 semblent passer derrière
les éléments contenus dans ce "plan".

Les test de collisions avec le décor ne se font qu'entre les éléments
de la couche 1 et 2.

L'animation des éléments est basée sur les méthodes step et stepTime de la classe Morph (tic toutes les 300ms)

La gestion du clavier est basée sur les évènements handleKeyUp et handleKeyDown :
- handleKeyDown on stoke la valeur dans une collection
- handleKeyUp on efface la valeur de la collection
la collection est ensuite analysée toutes les 20ms.

Pour finir je souhaite faire tourner le tout sur une image squeakland
pour diffusion via le web. Pour l'instant mes premiers essais sont infructueux.

Je ne suis pas convaincu que ce type de développement pourra interessé la communauté
qui semble plus orientée Etoys, Robots et Web, mais le code sera mis à disposition
le cas échéant.

Pour finir, un merci aux membres de liste pour toutes les réponses.

Cordialement,
-- 

Frédéric Ferrère