[Squeak-fr] Retour d'experience

[stephane ducasse]

On 22 juin 07, at 15:12, FERRERE Frédéric wrote:

> 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 n'y a pas de doc. pas insuffisante. pas de doc

> 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.

je suis impressionne

> 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 :).

il ne faut pas utiliser les projets.

> 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.

merge permet de merger ce que tu charges avec ce qui est dans l'image.


> 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

excellent j'y ai jouer des heures :)

>
> 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)

impressionnant car morph est trop lent pour moi....

>
> 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.

Mais il faut faire une announce sur Squeak-dev

>
> Pour finir, un merci aux membres de liste pour toutes les réponses.
>
> Cordialement,
> -- 
>
> Frédéric Ferrère
> _______________________________________________
> Squeak-fr mailing list
> Squeak-fr at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
>