Re : Gamemaker vs Fusion 2.5

Bonjour à tous,

j'ai eu l'occasion de tester GameMaker intensivement depuis l'apparition du Humble Bundle et voici mon appréciation toute personnelle des deux moteurs de jeux.
Je suis un utilisateur convaincu des produits Clickteam et je pense qu'il est très interessant de pouvoir comparer les forces et les faiblesses des différents outils actuels. On pourra bientôt rajouter une colonne Fusion 3 qui explose tout. :)
Pour certains critères comme les performances, je dois encore faire un benchmark que je publierai ici pour avoir une appréciation quantitative.
J'ai pris le deuxième chapitre de Cardinal comme base de travail pour comparer. Sur un projet de taille moyenne donc. L'appréciation peut être différente suivant la taille du projet.

J'actualiserai ce tableau en fonction de vos retours et de mes découvertes sur Gamemaker.

	Gamemaker		Fusion 2.5
[/td] [td]Courbe d'apprentissage/ Accessibilité	[/td] [td]
[/td] [td]-    Nécessite un background en programmation pour des projets moyens ou gros. Nécessite d'assimiler les quelques spécificités du langage GML et de son moteur.	[/td] [td]++    Très rapide pour des petits projets et facile d'accès pour les non programmeurs. Peut se révéler ardu pour des projets d'envergure, notamment pour l'optimisation du code
[/td] [td]-    Logiciel et documentation uniquement en anglais	[/td] [td]++    Logiciel en anglais, français et japonais. Documentation en anglais et français. Japonais?
[/td] [td]Code et données	[/td] [td]
[/td] [td]++    Evénements par script	[/td] [td]+++    Scripting visuel
[/td] [td]-    Langage de script propriétaire à assimiler (GML)	[/td] [td]+++    Scripting visuel (éditeur d'événements), langage paramétrable
[/td] [td]+++    Code géré par instance ou global au choix	[/td] [td]-      Sélection du code par instance possible mais compliquée
[/td] [td]+++    Réutilisation du code facile	[/td] [td]-      Réutilisation du code peu pratique (copier/coller)
[/td] [td]+++    Contrôle des sources partagées facile: un fichier par objet/script/scène et gestion des versions intégrée (Git par exemple)	[/td] [td]-      Contrôle des sources partagées difficile: un seul fichier mfa
[/td] [td]++    Variables par objet au choix: en type et en nombre	[/td] [td]-      Variables limitées aux entiers et texte
[/td] [td]+++    Héritage des événements d'objets parent	[/td] [td]++    Qualifieurs pour généraliser le code à plusieurs objets
[/td] [td]	[/td] [td]
[/td] [td]Ressources et Performances	[/td] [td]
[/td] [td]++    Gestion des ressources plus pointues: occupation mémoire par sprite, création des objets sans instance dans la scène	[/td] [td]-      Gestion des ressources limitée: occupation mémoire globale à l'application, objet sans instance peu intuitive (créer un objet dans une scène, puis un événement associé et enfin supprimer l'objet dans la scène
[/td] [td]+++    Très bonne performance même sans optimisation	[/td] [td]-      Performance moyenne sans optimisation
[/td] [td]	[/td] [td]
[/td] [td]Sprites et animations	[/td] [td]
[/td] [td]-    Quasiment pas de gestion des animations malgré quelques options de l'éditeur d'animations sympathique: stretch(réduire le nombre d'images), trim (ajuste toutes les images sur la partie non transparente)	[/td] [td]++/-    Beaucoup d'options automatiques: animations prédéfinies, animations associées à une direction, possibilités de bouclage automatique de l'animation sur une image en particulier. Certaines de Ces options automatiques peuvent être considérées comme négatives si tout est fait en custom.
[/td] [td]-    Point chaud global à l'animation, pas de point d'action	[/td] [td]++    Point chaud par image, point d'action disponible
[/td] [td]+    Gestions des images avec transparence, importation de sprites avec squelette supportée, importation de fichiers vectoriels (swf) partiellement supportée	[/td] [td]-    Gestion des images avec transparence parfois hasardeuse
[/td] [td]	[/td] [td]
[/td] [td]Editeurs	[/td] [td]
[/td] [td]-    Editeurs de niveaux pas très intuitif	[/td] [td]++    Editeurs d'événements et de niveaux facile à prendre en main
[/td] [td]Fonctionnalités	[/td] [td]
[/td] [td]-    Peu d'objets disponibles de base, de nombreuses choses doivent être codées	[/td] [td]+    De nombreuses extensions disponibles et facile à intégrer
[/td] [td]++    Pathfinding A* intégré de base et facile à utiliser	[/td] [td]+    Extension de pathfinding (seulement Windows) mais peu intuitive pour les débutants
[/td] [td]++    Gestion du jeu en réseau intégré	[/td] [td]+    Une seule extension robuste de gestion de jeu en réseau (lacewing) qui tend vers l'obsolescence
[/td] [td]---    Aucune possibilité de contrôle de base. La programmation d'éditeur ou d'applications est donc plus longue et compliquée	[/td] [td]+++    Nombreuses possibilités de contrôles de bases: textBox, combobox, edit box
[/td] [td]	[/td] [td]
[/td] [td]Debugging	[/td] [td]
[/td] [td]+++    Debugger complet avec points d'arrêt	[/td] [td]+    Debuggeur mais limité (pas de points d'arrêt, vue des valeurs d'objets seulement à la fin de la loop)
[/td] [td]	[/td] [td]
[/td] [td]Extensibilité / Capacité d'évolution	[/td] [td]
[/td] [td]+    Extensions disponible mais peu pratique (ajouts de Dlls), documentation quasi inexistante	[/td] [td]++    SDK de développement d'extension complet même si documentation limitée
[/td] [td]?    Développement de nouvelles fonctionnalités??	[/td] [td]++    Debugging très réactif, outil en évolution constante

Bonjour,

Je suis obligé de réagir à ce topic étant donné que je possède les deux et que j'ai testé les deux, mais j'ai pas testé tous les points cela dit je vais parler plus généralement.

Game Maker Studio est un bon produit, mais il tends à être excessivement cher. Je ne parle pas de humble, je parle en général. Exporter à 299 l'unité ca coûte un bras.

Concernant le produit en lui même, il a certes des choses plus pointues, notamment au niveau de la gestion des sources, et des alloc mémoires, etc...mais il y a plusieurs zones d'ombres.

- Leur éditeur d'events drag & drop est en réalité inutile. En effet, pour peu qu'on veuille faire quelque chose d'un peu plus concret, la programmation à la mano est obligatoire.

- Mon dieu que c'est le bordel. Pour faire un casse brique c'est simple mais dès qu'on commence à vouloir un truc un peu plus costaud, l'organisation de leur système et interface fait qu'on a du code partout, partout, partout et cela devient vite le bazar. Coder en global c'est le mal absolu, ils ont un système objet autant l'utiliser mais le soucis c'est que quand on cherche une erreur on est obligé de passer par plusieurs objets pour voir le code ce qui rend le débogage un cauchemar (du moins pour moi qui aie l'habitude d'avoir une tronçon de code complet sous les yeux). Du coup on ouvre, on regarde, on ferme, on ouvre un autre objet, on regarde et euh mince c'était quoi déjà la ligne dans l'objet d'avant ?...

- Leur éditeur de niveau, n'a jamais évolué, il est pas pratique. A sa décharge, il offre cependant la gestion des tiles.

- Leur système de script, et encore ils ont amélioré l'affaire, mais bon , créer une fonction avec des arguments ayant pour nom arg1, arg2 etc... c'est juste pénible, on peut grâce aux commentaires faire en sorte d'avoir une aide visuelle après quand on appelle la fonction, mais si on est pas pointilleux la dessus, quand on appelle la fonction, on ne sait plus à quoi correspondent les arguments. Avant il n'y avait pas l'aide visuelle, du coup on se paumait direct sur des fonctions complexes.


En fait quand Yoyo dit que GMS c'est même pour les débutants, je dirai que non. En effet, leur truc drag & drop reste limité à mon goût si on veut faire des trucs, faut vraiment se mettre au GML. Du coup la plupart des routines sont à se coder nous même et pour les débutants, c'est pas forcément évident. Le GML propose des outils pour aider pour l'animation etc... mais il faut tout de même se faire les routines. Donc pour les débutants en soif d'apprendre ouais, mais pour un gars qui veut faire un jeu sans se prendre la tête : non.

Cela reste un bon produit, mais vite bouffe fric si on veut faire autre chose que du Windows. Les extensions de clickteam ne sont pas tous données, mais reste dans la moyenne. J'ai rien contre GMS me suis déjà amusé avec, car j'aime bien le "code pur" aussi de temps en temps, mais par contre leur système de code peut devenir vite le bazar.

Jolie travaille !
Par contre l'extension de pathfinding existe pas sur fusion non  ????
il y en a bien une mais compatible que windows et pas top top et faut la télécharger

Tu as raison Crystal Noir, c'est pas vraiment pour les débutant, en revanche les performances de GM sont énormes

Ca je ne nie pas les perfs.

Pour les extensions clickteam oui c'est un peu le problème, c'est que si on a besoin d'une extension, et que elle est que pour windows, cela limite les possibilités d'export par la suite.

Mais c'est le prix à payer pour avoir du natif et de la fonctionnalité. Je préfère cela à un C2 par ex qui se focalise que sur une plateforme (soyons clair, C2 fait plusieurs plateformes mais se base uniquement sur du html 5 donc pas de natif).

Ah oui en effet, j'ai oublié l'aspect courbe d'apprentissage que je voulais intégrer. Je vais rajouter cela. Je suis d'accord que Gamemaker s'adresse plus à un public avec un minimum de background en programmation.

Pour le prix, je suis d'accord que GameMaker est plus cher que Fusion 2.5 mais avec toutes les promos et humble bundle qui passent, une comparaison chiffrée des prix brut ne me semblait plus refléter l'état du marché actuel.

Pour la structuration du code, je ne suis pas d'accord. C'est pour moi tout le contraire: Fusion 2.5 est plus simple pour des petits projets et plsu compliqué pour des gros projets. La programmation orienté objet dans Gamemaker est une véritable bénédiction. C'est justement une structuration du code obligatoire qui facilite les choses. Dans Fusion 2.5, tu peux mettre un bazar complet et il faut se discipliner encore plus pour créer cette structure.
Le code dans Gamemaker est exécuté pour chaque instance séparément: plus de Loop à la Fusion 2.5 pour récupérer la bonne instance. Comme tout programme, il faut définir l'architecture avant de commencer. Ensuite cela vient tout seul. L'héritage est aussi quelque chose de génial. Tu crées les comportements des objets généraux (héro ou ennemi par exemple) et tu n'ajoutes que les comportements spéciaux (un Boss par exemple). Fusion 3 d'ailleurs utilisera les même paradigmes et j'en suis vraiment content (même si on pourra toujours programmer en global et ne pas utiliser l'héritage). Par contre je suis d'accord qu'il faut plus de clics pour arriver au code des objets. Comme dans un programme classique Avec un langage de programmation.

Pour debugger, Gamemaker a des breakpoints, tu peux donc parcourir le code comme n'importe quel environnement de développement. Dans Fusion 2.5, la pause du debuggeur ne s'arrête qu'à la fin de la boucle d'événements donc si tu as 2 événements qui se contredisent dans la même boucle tu n'as aucune chance de trouver la source facilement. 

Je trouve aussi l'éditeur de niveau pas génial. Je vais rajouter cela dans la liste.

Pour les scripts, ajouter l'aide visuelle et nommer ces paramètres dès l'entrée du script suffisent (var pointsDeVie = argument1) comme tu l'as dit Crystal Noir. Comme indiquer précédemment, il faut de la structure.
Et c'est encore pire dans Fusion 2.5: programmer l'équivalent d'une fonction avec différents arguments est une vraie plaie.
Dans Gamemaker, une machine d'états et tu n'as plus d'encapsulation de groupes compliqués et de if à rallonge.

@graboide: en effet Pathfinding n'est pas multiplateforme. Je vais le repréciser.

Je ne compare pas la programmation de fusion 2.5 et GMS en fait, car fusion on est sur de l'évènementiel, GMS c'est différent.

Et crois moi, je t'assure que c'est le bordel :)

[quote]La programmation orienté objet dans Gamemaker[/quote]

Le terme n'est pas vraiment approprié même si je comprend ce que tu veux dire. Disons que ce qui est pas mal c'est que, même si le script n'a rien d'orienté objet (car bon soyons honnête, les principes de GMS font penser à la poo, mais le langage on est loin du compte quand même :) ), un graph d'uml fonctionnerait avec GMS pour réfléchir à la structure, avec fusion, c'est plus compliqué ^^

Pour l'héritage oui c'est super pratique c'est certains. Et justement quand on vient de la poo GMS n'est pas si évident, car tellement l'habitude de toute définir : classes, agrégat, compo, relations, design pattern etc... que arrivé la dedans, au lieu d'avoir 3 classes avec leurs  méthodes, tu as 3 objets mais avec du code explosé à l'intérieur d'évènements et c'est très déstabilisant, car au final point de méthodes mais des fonctions script (arg1, arg2 etc...) à appeler qui n'ont rien à voir avec l'objet en question (donc plus génériques) et c'est là que ca "casse" l'aspect objet de la chose et que cela déstabilise :)

Pour le debug je suis d'accord sur ce point, je parlais juste de la lecture du code, car au final tu lis pas le code que pour debug, donc au final quand tu as un code explosé entre events et objets (controleur, objet sprite, hud etc...), cela peut vite devenir l'anarchie (enfin c'est mon avis).

Je ne parle pas de fusion car par définition fusion n'a pas de "code" à proprement parlé et ne se base exclusivement que sur une logique event => action. Donc c'est très différent comme principe (et moins souple je le reconnais).

Ok, je n'avais pas compris que tu parlais de manière générale et sans comparaison avec Fusion 2.5.
Personnellement cette logique me va très bien. Dans le SDK de Fusion 2.5, les choses ne sont pas très differentes: une méthode pour l'initialisation (Create), une pour l'update (Step) et une pour l'affichage sur l'écran (Draw). Les deux dernières sont appelées à chaque boucle d'événements. Unity fait la même chose aussi. Je pense qu'on peut donc comparer Gamemaker à Fusion 2.5 sur ces points.
Les événements de Fusion 2.5 sont l'équivalent des événements custom de Gamemaker.

Je ne suis pas arrivé au bout du projet mais pour l'instant, tout est venu naturellement: j'assimile les bouts de code dans les objets sur appel de Create/Step/Draw comme des méthodes prédéfinies de mes objets. Et les scripts je ne les utilises que dans un contexte plus globale comme fonction statique ou comme ma fonction main .
Cela ne me paraît pas si loin que ça de la base de la programmation objet. Je n'utilise pas les scripts à outrance, c'est peut-être pour ça. Je suis d'accord sur le fait que les scripts il faut bien les ranger sous peine de ne  plus bien savoir où ils se cachent. Il aurait été pas mal de pouvoir aller à la définition du script directement depuis l'appel de celui-ci ailleurs.
Mais bon quand il s'agit d'anarchie, dans n'importe quel projet de programmation sur un langage classique tu peux avoir ce genre de choses.

Peut-être l'expérience me montrera que tu as raison. Cet article tient surtout à comparer la facilité de développement et la différence de fonctionnalités entre Gamemaker et Fusion 2.5.
Certains se retrouvent mieux dans Fusion 2.5 et d'autres mieux dans Gamemaker mais je ne pense pas être le seul à dire que la manière dont Fusion 2.5 gère les instances est galère.

La grosse nuance quand il s'agir de pondre un proto, un klik soft gère les sprites, Game Maker fait avec.

Versions gratuites, GM est largement au dessus de CTF.

On sait programmer, vive le GML, on ne sait pas vive le tableau cases à cocher, au moins on a le choix.

Effectivement la version gratuite de GM est plus avantageuse.

Non attention hein j'ai pas dit que GMS n'était pas bien ou ingérable, je dis juste qu'il demande pas mal de rigueur. Moi je l'aime bien perso, mais c'est vrai que j'ai souvent des difficultés à m'y retrouver dessus (peut être l'habitude de coder en java ? XD)

Concernant  Unity et cie de toute façon ils font tous la même chose. Car finalement c'est ce que fait un framework en général (et finalement unity c'est qu'un framework avec un éditeur hein si on le ramène à sa plus simple expression), c'est qu'ils fonctionnent sur le principe du init, update, draw.

Pour l'anarchie tu as tout à fait raison, on peut retrouver cela partout, mais sous gms, pour peux qu'on pense pas son truc à l'avance, c'est vite le bouzin. Perso je le trouve bien même si j'ai quelques soucis avec à certains niveaux, mais je persiste par contre à dire qu'il n'est pas pour le débutant débutant, car soyons honnête sans GML c'est compliqué à partir du moment où on veut aller plus loin.

Mais sans aucun doute c'est un très bon maker.

Un autre bon exemple, moi par ex, mon problème avec fusion c'est d'adapter des algos que j'ai en tête sur le tableau d'events, parfois un algo qui marche dans un langage n'est pas facile à porter sur fusion car il réagit pas pareil enfin parfois les évènements ont des particularités qui fait que c'est pas si simple ^^

Cela dit même si on sait programmer (j'en reviens à ce que disait Kloug), Fusion a quand même ce petit truc qui fait qu'on l'aime bien avec son tableau d'events ^^

Tout à fait d'accord avec toi. Fusion 2.5 a ce quelque chose qui fait qu'on l'aime bien.
Je suis juste parfois frustré de n'avoir sur certains forums aucun retour lorsque je fais la promotion de ce superbe logiciel. Par contre 2-3 mots sur Unity, Gamemaker ou Construct 2 et tout le monde se réveille. C'est mon coup de gueule du vendredi soir. ^^
Quand on voit mon tableau comparatif, on voit bien qu'il a plein de choses pour lui.
Merci à toi pour ces retours constructifs Crystal noir et bon rétablissement.

Merci :) et ce fut un plaisir ^^

L'intérêt de CTF la translation de notions de programmation, via un tableau cases à cocher "limité", car passant par une interface (éditeurs divers et variés).

Sur ce forum, il y a un crack.

Algorithme récursif (backtracking).
http://comptoir-mmf.eu/Forum/index.php?topic=1523.0

Tien, mon post n'a pas passé. J'ai été modéré ? xd

J'ai du mal à situer GM. La possibilité (et l'obligation même) de programmer en dur, est pour moi un atout ! Car quand on a un peu de bouteille en programmation, il y a beaucoup de chose qui vont plus vite à mettre en place que d'utiliser Fusion. J'ai toujours cette exemple pour assembler les cartes / niveau faite en tiles sous fusion ou programmer les boucles divers c'est fastidieux et long alors qu'en programmant c'est plus facile. Deux boucles For/to imbriqué(X et Y), lire le numéros de tiles et poser l'image, le tour est joué)

MAis des qu'un logiciel intègre un langage de programmation pur et dur et plus ou moins obligatoire pour l'utiliser, ce logiciel en question ne s'adresse plus vraiment au personne qui veulent créer un truc sans "programmer".  GM et son drag and drop est quand même limité.  Cela me fais penser à Rpg Maker XP qui intègre le ruby pour les scripts. Sans programmer ce logiciel est vraiment naze à mes yeux surtout qu'il avait éliminé pas mal d'option native pour faire du RPG même si RM Xp apporte beaucoup.

Ceci dit si il faut programmer, pourquoi utiliser GM après tout. Gm apporte finalement seulement son langage, un éditeur de map, son système sonore, son rendu graphique et ses modules d'exportation. N'est-il pas plus plus plus mieux à ce tarif de partir sur un langage de programmation et des bibliothèque divers pour faire un jeu ? Ceci GM évite les tas de paramétrage de bibliothèque externe xd

Ceci dit comparer GM avec Fusion c'est quand même difficile. Cela s'adresse quand même à des gens différents. Fusion tu n'utilises pas de langage programmation pur et dur.  Il est beaucoup plus facile à utiliser donc tout comme Rpg Maker et son système d'événement. Ce qui n’empêche pas d'avoir des notions de programmation pour s'en sortir quand on veux faire des jeux sérieusement.

Fusion peut se comparer à construct ou game dev mais GM beaucoup plus difficile à mes yeux.

Pour moi, le fait que Fusion soit en français est aussi un plus non négligeable. Je suis beaucoup moins à l'aise en anglais.

Si il faut programmer pourquoi ne pas partir sur un langage et des lib ? La réponse est simple, tous les langages ne sont pas accessibles. D'autant plus que GMS proposent énormément d'instructions "out in a box" sans prise de tête.

Dans un même ordre d'idée, Spiderbasic (rien à avoir avec le jeu), permet de faire de la web app sans avoir à se faire chier avec js. Alors attention hein, quand je dis web app, je parle pas d'une simple interface et je clique sur un bouton, on peut faire des choses très complexe avec, mais avec spiderbasic et son langage facile à implémenter, c'est rapide (surtout par un dev alone), alors qu'en js ca serait un bazar pas possible ou compliqué. De plus ils vont intégrer bientôt node.js et là ca va être terrible, et derrière il pond du js en fait, bon je m'égare...

C'est le même principe. Après ouais vu comme cela pourquoi pas utiliser libGDX et Overlap2D pour l'édition de niveau ^^ ? Moi j'aime bien Java mais il faut avouer que c'est pas un langage donné à tout le monde (et il demande en plus une bonne structuration). Moi j'ai tout de même un coup de coeur avec le langage "Monkey X" qui est un langage pur (donc pas d'éditeur de niveau), qui peut travailler avec des frameworks faits par les utilisateurs et qui en prime permet de faire de la Poo à sa manière ^^ Et au final son transcoder fait un projet natif (dépendant de la plateforme, par ex pour windows, un projet c++).

Pour finir je pense que si GMS avec son GML n'avait aucun intérêt et qu'il était aussi simple à ce moment là de coder en C++/Sfml ou en Java/LibGDX, personne ne l'utiliserait :) Il semblerait même que certaines personnes qui ont de la bouteille en programmation, l'utilise justement par gain de temps sur pas mal d'aspect.

Le petit souci de GM, on débute Drag and Drop, on commence à se débrouiller super Drag and Drop, on souhaite s'attaquer à du lourd, GML obligatoire.

Donc d'un côté GM avec son GML obligatoire et rébarbatif pour les novices, et de l'autre CTF, un pseudo langage de programmation, accessible aux novices.

Comparer GM et CTF, en exagérant c'est comparé un maker code pour adolescent et un terrain de jeu pour enfant.

Pour ma part j'utilise un logiciel "fast food" non pour me prendre la tête, mais pour m'amuser.

Ceci dit, c'est toujours intéressant d'avoir un comparatif détaillé.

Edit:
Il s'agit d'un constat, concernant le GML rien d'autre.
Pub GM "sans jamais avoir à écrire de code!"
Pour un jeu basique d'accord, genre pong et encore sans IA (humour).

@Seyjin: tu as raison, je l'ai rajouté dans la liste.

De mon point de vue, la comparaison est complètement légitime en terme d'objectif. Si nous imaginons quelqu'un qui souhaite créer des jeux vidéos qui ne connaît ni Fusion 2.5 ni Gamemaker ou alors qui ne connaît que l'un des deux, ce type de comparaison peut l'aider à voir si l'un ou l'autre des outils est fait pour lui.
Je comparerai cela à un voyage: s'il on doit choisir entre la voiture, le bateau, le train ou l'avion qui sont complètement différents en tant que tel, on peut quand même les comparer en terme de temps de trajet, changement, restauration à bord, prix, voir du paysage pour savoir lequel nous convient le mieux pour atteindre notre objectif. Il est clair qu'en partant sur le critère que l'on a aucune base de programmation et qu'on ne souhaite pas l'apprendre, un outil comme Fusion 2.5 s'impose de lui-même.

D'un autre côté, la comparaison aide à voir dans quel mesure le produit que l'on aime tous ici sur ce forum peut s'améliorer mais aussi les choix de design qui en font un outil vraiment utile.

Concernant la  programmation, comme l'a dit Crystal Noir, on n'est loin de ce que font les autres langages en terme de programmation. C'est vraiment basique.
La charge de travail n'est donc pas du tout la même que d'autres frameworks tels que cités par Crystal Noir.

"Sans jamais écrire une ligne de code" ils disent tous cela de toute façon maintenant :D (Dans le cas de fusion c'est plutôt vrai il n' y a qu'un tableau d'events (je met hors jeu les extensions lua etc...).

C'est certains, dès qu'on veut faire un truc un peu plus poussé, t'es obligé de passer par l'uml car leur drag&drop est vite limité. En fait ce qui fait les points forts de GMS sont les points faibles de Fusion si on décortique le truc, mais l'inverse est vrai aussi.

L'idée je pense c'est de s'amuser, on a vu que, que ce soit avec fusion ou avec GMS , il y a de grosses prods qui ont marché que ce soit sur steam ou ailleurs. Donc les deux outils se valent en fait, ce qui fait que ca change, c'est l'utilisateur : qu'est ce qui lui convient le mieux ? avec quel outil il arrive le mieux à s'en sortir ? etc...