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,
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) :
- le décor est une image gif (640x288) contenue dans un Morph.
- 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@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Le 22 juin 07 à 15:12, FERRERE Frédéric a écrit :
Bonjour,
Voici un petit retour d'expérience sur smalltalk/squeak en développement.
Salut Frédéric. Merci, c'est important d'avoir ce genre de retour d'expérience
J'ai découvert smalltalk/squeak avec le numéro 82 de linux magazine france (avril 2006).
Cela fait plaisir de savoir que notre série d'articles lance de nouvelles vocations ;-)
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).
C'est un jeu dont tu avais conservé les images ?
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é.
En ce qui concerne la documentation, n'hésite pas à prendre un peu de temps pour compléter le wiki et nous faire ainsi partager tes nouvelles connaissances. Cela facilitera d'autant la tâche pour les nouveaux utilisateurs de Squeak. Si tu as écrit des description de classes, il faut les faire remonter pour qu'elles soient intégrées au noyau. Chaque petite modification améliore la qualité de la documentation.
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.
Oui, la gestion sous forme d'image est assez déroutante pour tous ceux qui ont l'habitude de manipuler des fichiers.
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.
Si tu as écrit des choses, envoie les pour intégration au noyau.
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
Impressionantes ces vidéos ! Beau boulot. Comment as tu reproduire le gameplay aussi précisemment ?
Voici quelques informations sur la conception :
La scene graphique est construite en trois couches (3 niveau de morphs) :
- le décor est une image gif (640x288) contenue dans un Morph.
- 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.
Détrompe toi, cela nous intéresse. La communauté ne tourne pas qu'autour des Etoys et de Seaside. Nous sommes très nombreux ici à faire du hardcore Smalltalk.
Merci de nous faire partager ton travail. En ce qui concerne la mise à disposition du code, je pense que cela nous intéresse, mais il y a le problème de droit autour des images du jeu d'origine que tu as utilisé.
A+ -- oooo Dr. Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##
Détrompe toi, cela nous intéresse. La communauté ne tourne pas qu'autour des Etoys et de Seaside. Nous sommes très nombreux ici à faire du hardcore Smalltalk.
oui et des tas d'autres choses :)
Merci de nous faire partager ton travail. En ce qui concerne la mise à disposition du code, je pense que cela nous intéresse, mais il y a le problème de droit autour des images du jeu d'origine que tu as utilisé.
bof on s;en fout il ne va pas faire du fric avec....
A+ -- oooo Dr. Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Le 22 juin 07 à 16:53, stephane ducasse a écrit :
Merci de nous faire partager ton travail. En ce qui concerne la mise à disposition du code, je pense que cela nous intéresse, mais il y a le problème de droit autour des images du jeu d'origine que tu as utilisé.
bof on s;en fout il ne va pas faire du fric avec....
On reconnait ceux qui veulent y jouer ;-)
-- Valentin Guerlesquin -- valentin@guerlesquin.net
Le 22 juin 07 à 16:53, stephane ducasse a écrit :
Détrompe toi, cela nous intéresse. La communauté ne tourne pas qu'autour des Etoys et de Seaside. Nous sommes très nombreux ici à faire du hardcore Smalltalk.
oui et des tas d'autres choses :)
Merci de nous faire partager ton travail. En ce qui concerne la mise à disposition du code, je pense que cela nous intéresse, mais il y a le problème de droit autour des images du jeu d'origine que tu as utilisé.
bof on s;en fout il ne va pas faire du fric avec....
Ouais, mais bon cela serait con de prendre un procés sur la tête ... On ne sait jamais, il y a tellement de débiles.
-- oooo Dr. Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##
Bonjour,
Quelques réponses aux commentaires :
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
C'est un jeu dont tu avais conservé les images ?
Non, mais aujourd'hui on trouve quelques sites sur internet de passionnés de cette machine (Amstrad CPC), qui mettent à disposition des émulateurs ainsi que les jeux et programmes d'origine. J'ai donc récupéré un émulateur (WinAPE) et le fichier correspondant à l'image de la disquette du jeu original que l'on trouve ici : http://tacgr.emuunlim.com/
Ensuite j'ai écrit quelques lignes de code pour récupérer les images. Pour les différentes salles je fais des captures d'écran.
Selon stephane ducasse stephane.ducasse@free.fr:
bof on s;en fout il ne va pas faire du fric avec....
En effet, ce n'est absolument pas le but.
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
Merci de nous faire partager ton travail. En ce qui concerne la mise à disposition du code, je pense que cela nous intéresse, mais il y a le problème de droit autour des images du jeu d'origine que tu as utilisé.
Ok pour le partage, mais pas pour tout de suite, le code doit être pas mal nettoyé et surtout documenté :) Pour les droits d'auteur je suis tout à fait conscient des problèmes afférents, c'est pour ça que les graphismes actuels ne sont qu'une étape. Vu que les jeux originaux sont disponibles sur internet, il semble exister une certaine tolérance qui, je suis conscient, ne met pas à l'abri d'éventuels ennuis juridiques.
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
En ce qui concerne la documentation, n'hésite pas à prendre un peu de temps pour compléter le wiki et nous faire ainsi partager tes nouvelles connaissances. Cela facilitera d'autant la tâche pour les nouveaux utilisateurs de Squeak. Si tu as écrit des description de classes, il faut les faire remonter pour qu'elles soient intégrées au noyau. Chaque petite modification améliore la qualité de la documentation.
Je vais attendre d'acquérir un peu plus d'expérience pour ne pas écrire n'importe quoi :)
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
Impressionantes ces vidéos ! Beau boulot. Comment as tu reproduire le gameplay aussi précisemment ?
J'avoue ne pas trop savoir quoi répondre :) La lecture du code ou une description détaillée (et longue) de la conception serait le meilleur moyen de répondre j'imagine :) Ceci dit le gameplay actuel n'est pas parfait et surtout pas vraiment fidèle à l'origine, par exemple : - les monstres qui suivent le pauvre joueur vont tous à la même vitesse alors que dans l'original ce n'est pas le cas. - Le mécanisme de diminution d'énergie est trop rapide - le livre en bas à droite de l'écran est un compteur de temps qui s'efface au cours du temps, je ne suis pas sur d'avoir correctement évalué la vitesse. - il y a aussi la possibilité de mettre le jeu en français, car j'ai construit mon propre système de traduction (j'ai découvert que récemment que squeak disposait de quelque chose en ce sens)
Prochaine étape : nettoyage du code et mise à disposition au sein d'un cercle restreint pour ne pas tenter les foudres juridiques sur les graphismes.
Cordialement, -- Frédéric
je pense que pour les licenses et les droits y a pas de problemes. Vraiment ce jeu est disponible en ligne avec un emulateur.....
Stef
On 23 juin 07, at 16:58, frederic.ferrere@free.fr wrote:
Bonjour,
Quelques réponses aux commentaires :
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
C'est un jeu dont tu avais conservé les images ?
Non, mais aujourd'hui on trouve quelques sites sur internet de passionnés de cette machine (Amstrad CPC), qui mettent à disposition des émulateurs ainsi que les jeux et programmes d'origine. J'ai donc récupéré un émulateur (WinAPE) et le fichier correspondant à l'image de la disquette du jeu original que l'on trouve ici : http://tacgr.emuunlim.com/
Ensuite j'ai écrit quelques lignes de code pour récupérer les images. Pour les différentes salles je fais des captures d'écran.
Selon stephane ducasse stephane.ducasse@free.fr:
bof on s;en fout il ne va pas faire du fric avec....
En effet, ce n'est absolument pas le but.
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
Merci de nous faire partager ton travail. En ce qui concerne la mise à disposition du code, je pense que cela nous intéresse, mais il y a le problème de droit autour des images du jeu d'origine que tu as utilisé.
Ok pour le partage, mais pas pour tout de suite, le code doit être pas mal nettoyé et surtout documenté :) Pour les droits d'auteur je suis tout à fait conscient des problèmes afférents, c'est pour ça que les graphismes actuels ne sont qu'une étape. Vu que les jeux originaux sont disponibles sur internet, il semble exister une certaine tolérance qui, je suis conscient, ne met pas à l'abri d'éventuels ennuis juridiques.
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
En ce qui concerne la documentation, n'hésite pas à prendre un peu de temps pour compléter le wiki et nous faire ainsi partager tes nouvelles connaissances. Cela facilitera d'autant la tâche pour les nouveaux utilisateurs de Squeak. Si tu as écrit des description de classes, il faut les faire remonter pour qu'elles soient intégrées au noyau. Chaque petite modification améliore la qualité de la documentation.
Je vais attendre d'acquérir un peu plus d'expérience pour ne pas écrire n'importe quoi :)
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
Impressionantes ces vidéos ! Beau boulot. Comment as tu reproduire le gameplay aussi précisemment ?
J'avoue ne pas trop savoir quoi répondre :) La lecture du code ou une description détaillée (et longue) de la conception serait le meilleur moyen de répondre j'imagine :) Ceci dit le gameplay actuel n'est pas parfait et surtout pas vraiment fidèle à l'origine, par exemple :
- les monstres qui suivent le pauvre joueur vont tous à la même
vitesse alors que dans l'original ce n'est pas le cas.
- Le mécanisme de diminution d'énergie est trop rapide
- le livre en bas à droite de l'écran est un compteur de temps qui
s'efface au cours du temps, je ne suis pas sur d'avoir correctement évalué la vitesse.
- il y a aussi la possibilité de mettre le jeu en français, car
j'ai construit mon propre système de traduction (j'ai découvert que récemment que squeak disposait de quelque chose en ce sens)
Prochaine étape : nettoyage du code et mise à disposition au sein d'un cercle restreint pour ne pas tenter les foudres juridiques sur les graphismes.
Cordialement,
Frédéric
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Salut Pour la traduction, il faut faire suivre les chaines à traduire de translated.
Le code ci-dessous permet de mettre les traductions dans le dictionaire, il faut être sur français pour que LocaleID current charge la traduction dans le dictionnaire français:
LocaleID current translator phrase: 'string' translation: 'chaine'
Il est aussi possible de donner les traductions à l'aide de l'outil de traduction du menu ouvrir.
Il y a un projet qui permet de manipuler les traductions mais il ne foctionne qu'avec l'image plugin de squeakland.
http://ofset.org:8000/super/uploads/outilTraduction.020.pr
J'ai une question :
Comment faire exécuter du code dans un change set ?
Si j'ai changeset modifiant ou ajoutant du code, comment mettre la traduction française qui va avec dans le dictionnaire, pour celà il faudrait faire exécuter une boucle du genre:
*(('string' 'chaine) ('english')('anglais')) do: [:t|LocaleID current translator phrase: t first translation: t last]
Ceci pour que le changeset contienne aussi la traduction)
Amitiés
-------- Message d'origine-------- De: squeak-fr-bounces@lists.squeakfoundation.org de la part de stephane ducasse Date: sam. 23/06/2007 22:39 À: Squeak in french / Squeak en français Objet : Re: [Squeak-fr] Retour d'experience
je pense que pour les licenses et les droits y a pas de problemes. Vraiment ce jeu est disponible en ligne avec un emulateur.....
Stef
On 23 juin 07, at 16:58, frederic.ferrere@free.fr wrote:
Bonjour,
Quelques réponses aux commentaires :
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
C'est un jeu dont tu avais conservé les images ?
Non, mais aujourd'hui on trouve quelques sites sur internet de passionnés de cette machine (Amstrad CPC), qui mettent à disposition des émulateurs ainsi que les jeux et programmes d'origine. J'ai donc récupéré un émulateur (WinAPE) et le fichier correspondant à l'image de la disquette du jeu original que l'on trouve ici : http://tacgr.emuunlim.com/
Ensuite j'ai écrit quelques lignes de code pour récupérer les images. Pour les différentes salles je fais des captures d'écran.
Selon stephane ducasse stephane.ducasse@free.fr:
bof on s;en fout il ne va pas faire du fric avec....
En effet, ce n'est absolument pas le but.
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
Merci de nous faire partager ton travail. En ce qui concerne la mise à disposition du code, je pense que cela nous intéresse, mais il y a le problème de droit autour des images du jeu d'origine que tu as utilisé.
Ok pour le partage, mais pas pour tout de suite, le code doit être pas mal nettoyé et surtout documenté :) Pour les droits d'auteur je suis tout à fait conscient des problèmes afférents, c'est pour ça que les graphismes actuels ne sont qu'une étape. Vu que les jeux originaux sont disponibles sur internet, il semble exister une certaine tolérance qui, je suis conscient, ne met pas à l'abri d'éventuels ennuis juridiques.
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
En ce qui concerne la documentation, n'hésite pas à prendre un peu de temps pour compléter le wiki et nous faire ainsi partager tes nouvelles connaissances. Cela facilitera d'autant la tâche pour les nouveaux utilisateurs de Squeak. Si tu as écrit des description de classes, il faut les faire remonter pour qu'elles soient intégrées au noyau. Chaque petite modification améliore la qualité de la documentation.
Je vais attendre d'acquérir un peu plus d'expérience pour ne pas écrire n'importe quoi :)
Selon Serge Stinckwich Serge.Stinckwich@info.unicaen.fr :
Impressionantes ces vidéos ! Beau boulot. Comment as tu reproduire le gameplay aussi précisemment ?
J'avoue ne pas trop savoir quoi répondre :) La lecture du code ou une description détaillée (et longue) de la conception serait le meilleur moyen de répondre j'imagine :) Ceci dit le gameplay actuel n'est pas parfait et surtout pas vraiment fidèle à l'origine, par exemple :
- les monstres qui suivent le pauvre joueur vont tous à la même
vitesse alors que dans l'original ce n'est pas le cas.
- Le mécanisme de diminution d'énergie est trop rapide
- le livre en bas à droite de l'écran est un compteur de temps qui
s'efface au cours du temps, je ne suis pas sur d'avoir correctement évalué la vitesse.
- il y a aussi la possibilité de mettre le jeu en français, car
j'ai construit mon propre système de traduction (j'ai découvert que récemment que squeak disposait de quelque chose en ce sens)
Prochaine étape : nettoyage du code et mise à disposition au sein d'un cercle restreint pour ne pas tenter les foudres juridiques sur les graphismes.
Cordialement,
Frédéric
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
_______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
squeak-fr@lists.squeakfoundation.org
-
Dreyfuss Pierre-André (EDU) -
FERRERE Frédéric -
frederic.ferrere＠free.fr
-
Serge Stinckwich -
stephane ducasse -
Valentin Guerlesquin