Mokona Guu Center

Outils de production, outils de consommation

Sylvain Glaize — Tue, 24 Aug 2010 16:00:00 +0200

Lorsque Mickaël me demande lors d'un billet précédent ce qui m'a poussé vers Android comme plateforme pour mon téléphone, je me dis que la réponse est assez complexe car le résultat d'une série de considérations et un vécu personnel au contact de l'outil informatique.

Et l'on va pour cela commencer par remonter quelques trente années. À ce moment là, l'ordinateur est bien éloigné de ce qu'il est à présent. Pourtant, il sert aux même choses : aide au travail (calcul, traitement de texte), enseignement, communication, jeux. Il y a beaucoup de machines de types différents, peu de normes, l'informatique se détache tout juste de l'électronique et il y a une chose qui est certaine : programmer fait partie de l'utilisation de l'ordinateur. Ce n'est pas une obligation, l'outil peut être utilisé sans, mais tout magazine informatique contient sa partie programmation et tous les ordinateurs (ou peu s'en faut) sont livrés avec un moyen d'être programmé.

Cet ordinateur, lorsqu'il est personnel, est un outil que l'on peut utiliser et bricoler dans son intégralité. Construire le sien était un hobby accessible ^[1].

La première machine que j'ai eu livrée sans moyen d'être programmée était un Atari STe. Une incompréhension pour moi à l'époque, qui avait fait qu'en même temps que la machine, j'avais acheté le GFA Basic.

Puis, progressivement, le nombre de systèmes a diminué et le principal qui commence alors à s'imposer, Windows 3.1, ne fourni pas de moyen d'être programmé. Le BASIC livré avec le DOS (Windows est alors une surcouche du DOS) disparaît tout à coup.

C'est à ce moment là que j'entends parler de Linux. J'avais découvert les systèmes Unix entre temps, un Unix à installer chez soi, ça me semblait plutôt pas mal. Et FreeBSD, vers la même époque, demandait trop à mon PC. Ne pas pouvoir me servir pleinement de ma machine me rebute, je vire Windows 3.1 et j'installe un Linux. Double bonheur, je peux exploiter mon ordinateur comme je l'entends et le système de base l'exploite mieux.

Arrive Windows 95. Pas de possibilité de programmation livré avec, des performances catastrophiques sur une machine qu'un copain me prête, des capacités en réseau proche du néant. J'ai l'impression que, sous couverture d'être simple pour l'utilisateur, la machine échappe à l'utilisateur qui veut s'approprier son outil. En parallèle, j'ai l'occasion de donner quelques cours d'informatiques qui me montrent que pour le moment, aucun des systèmes ne se met réellement à la hauteur d'un utilisateur néophyte. Les distributions Linux n'essaient pas vraiment, et Windows ne fait que le clamer sur les dépliant publicitaires. Mes élèves ont déjà assez de mal avec le concept de pointeur souris. Je ne vois donc pas d'intérêt à lâcher ma liberté d'utilisation de mon PC pour la promesse d'une utilisation plus facile.

Cette notion continuera à se fortifier au fil des années : j'ai un outil qui me sert à produire des choses, qui m'aide dans mon travail ou qui me fourni des loisirs. Je tiens à garder le contrôle de cet outil, je ne veux pas que l'on m'en ferme des parties arbitrairement et, si je choisis d'utiliser un logiciel qui me cache ce qu'il fait, je veux que cela soit mon propre choix en fonction de la confiance que j'accorde au fournisseur.

De nos jours, beaucoup de fournisseurs de services ou de logiciels voudraient fermer le fonctionnement de la machine à leur utilisateur. En façade, la raison est la facilité d'utilisation ou chez les plus retords, l'assurance d'une « expérience de qualité » ^[2].

Chez Windows, il n'y a toujours pas possibilité de programmation avec l'ordinateur seul. En fait, jusqu'aux versions les plus récentes, il n'y avait pas beaucoup de possibilités. Heureusement, le développement d'Internet permet, via des sites spécialisés, d'équiper rapidement, facilement et librement sa machine de programmes en fonction des besoins.

Chez Apple côté bureau avec MacOS-X, le système est installé avec Python et des outils de développement sont fournis et installables. Ce n'est pas écrit en gros sur la plaquette, mais pas en petit non plus. Apple vend un système qui se programme. Certaines parties sont restent fermées.

Chez les différents revendeur/packageur de Linux, programmer ou même modifier son système sont des utilisations permises, documentées et naturelles. Elles ne sont pas mises en avant dans les grandes distributions (Ubuntu par exemple), mais elles sont là. L'utilisateur peut, s'il le souhaite, faire ce qu'il veut de son système. Et s'il ne le veut pas, ce n'est pas nécessaire non plus. Il a acheté son PC, il y a installé un système : il est libre de faire ce qu'il veut de son outil.

Puisque les ordinateurs personnels semblent pouvoir échapper à des enfermements de l'utilisateur et puisque les utilisateurs se tournent de plus en plus vers des solutions mobiles (Smartphones et Tablets) pour leur utilisations courantes, c'est sur ce terrain que se joue à présent la bataille qui oppose, grossièrement, d'un côté ceux qui veulent garder un contrôle sur le logiciel et le matériel, au dépend de l'utilisateur mais en lui présentant ce système comme un avantage et de l'autre ceux qui considère qu'un outil aussi versatile que les outils informatiques ne doit pas être limité arbitrairement.

Dans le camp fermé, il est difficile de programmer son propre matériel (il est nécessaire d'obtenir un sésame, payant, pour devenir développeur). Il est parfois interdit d'y installer ce que l'on veut sans passer par une plateforme centralisée. Pour contre balancer cette forte limitation, le fournisseur du matériel (qui est aussi le contrôleur/censeur du logiciel qui pourra être installé) va tabler sur une grosse logithèque. Côté développeurs, ils promettent une rétribution (potentielle) qui rentabilisera rapidement le coût d'entrée pour attirer un maximum d'entre eux. Côté utilisateur, ils promettent que l'application dont ils auront besoin sera forcément disponible. À vrai dire, il y en aura probablement trop, ce qui permettra à la plateforme centralisée de jouer sur la visibilité des applications pour en avantager certaines.

Dans le camp ouvert, ce système est incompréhensible. Si je suis moi même développeur et que je fais une application pour mes propres besoins, pourquoi irai-je payer une société tierce pour installer mon programme sur mon matériel ? Et que je sois ou non développeur et que je veux installer telle application, sans que celle-ci passe par le filtre d'une société tierce, car je considère qu'elle n'a pas à savoir ce que je fais de ma machine, ni même qu'elle me donne son avis sur cette utilisation, pourquoi en serais-je empêché ?

C'est là que je fais la différence entre un outil de consommation, qui met en avant l'intérêt de l'outil par le catalogue disponible à l'achat, très étoffé mais qui par ses diverses restrictions entrave la liberté de l'utilisateur (et donc sa liberté à produire quelque chose), et l'outil de production, qui ne met pas d'entrave à l'utilisation de l'outil, laissant l'utilisateur décider de ce qu'il en fera.

C'est tout cela qui m'a amené à choisir Android comme système pour mon smartphone. À un bouton prêt dans la configuration, le système permet d'être utilisé en mode de développement. À un autre bouton prêt, l'utilisateur signal au système qu'il l'autorise à installer des applications qui ne passe pas par la plateforme officielle. Notez bien : l'utilisateur autorise le système à effectuer une opération ! Et non pas le contraire (le système autorise l'utilisateur), comme il est d'usage dans les systèmes fermés.

Il y a une petite ombre au tableau cependant : les smartphones ne sont généralement pas complètement ouverts. Lorsqu'ils sont livrés par un opérateur téléphonique, cet opérateur ne donne pas l'accès au cœur du système. Généralement, cette limitation peut être levée, mais pas officiellement. Chez certains constructeurs, comme Motorola, quelques smartphone ont des parties chiffrées qui empêchent cet accès au cœur du système.

Il reste donc un peu de chemin à parcourir, dans le sens de l'ouverture, bien entendu.

Notes

[1] cette pratique existe toujours (voir là par exemple), mais plus sous la forme de défis personnels ou de projets étudiants.

[2] autre façon de dire : ne venez pas nous ennuyer avec vos problèmes en SAV.

Cadavre Exquis Creajol / Le Dixième Art

Sylvain Glaize — Thu, 05 Aug 2010 18:00:00 +0200

Creajol et Le Dixième Art ont organisé il y a peu une animation basée sur le principe du Cadavre Exquis. Lors de l'annonce de cette animation, je savais que j'allais avoir un peu de temps à y consacrer et j'ai demandé si je pouvais participer.

Je ne suis pas graphiste, je n'étais pas certain d'avoir ma place dans l'animation mais je n'étais apparemment pas le seul dans ce cas. Et puis, si ça ne donnait rien, on pouvait toujours annuler ma participation, je n'y aurais pas vu d'inconvénient. Ma participation était aussi un prétexte pour moi à me lancer dans quelque chose qui n'est pas vraiment de mon domaine, même si je n'y suis pas complètement étranger.

J'ai donc reçu mon petit bout d'image à compléter. Par chance, ce petit bout d'image m'a fait visualiser immédiatement ce que je voulais mettre à la suite. Dans les grandes lignes du moins, car le dessin au final n'est pas tout à fait tel que je l'avais imaginé. Le temps et surtout mes capacités ont joué sur ce que je pouvais livrer dans le temps imparti.

Au final, trois posters ont été crées. Ils ont été publiés hier. L'un sur Creajol que je trouve vraiment bien, les transitions se passent bien, l'impression d'ensemble est bonne et le thème est là.

Deux autres sont sur Le Dixième Art. Là, c'est un peu plus compliqué, un premier poster est séparé en deux images avec un lien dans la description vers l'image en entier. Le dernier poster est caché dans un lien dans la description du poster précédent, ainsi que dans certains commentaires. J'ai mis personnellement du temps avoir de le trouver.

Mais j'y tenais un peu, vu que c'est sur ce dernier que se trouve ma contribution.

Je trouve le premier poster un peu moins bon que celui de Creajol : les transitions se font parfois moins bien, mais c'est le risque de l'exercice et l'impression d'ensemble est plus fouillis. Tout le passe de la main et du bras ressort du reste : je trouve ce passage plus soigné.

À droite, j'ai inclus un aperçu du poster auquel j'ai participé. Pour le voir en grand, allez sur le site Le Dixième Art. La partie que j'ai dessinée est le passage au niveau de la lanterne japonaise.

L'image que j'ai reçu pour la continuité était constituée des deux coulures rouges juste au dessus du grand œil et des cheveux au même niveau. Je ne savais pas qu'il s'agissait de larmes de sang ni qu'il s'agissait de cheveux. Il est amusant de voir que je suis reparti sur des cheveux.

Ma contribution est donc une allusion à la série de jeux vidéo Project Zero. On y trouve un personnage inspiré par les fantômes que l'on y trouve, une lanterne japonaise pour évoquer les décors dans lesquels on se déplace dans le jeu et le cercle magique de l'appareil photographique.

Les larmes se transforment en espèce d'éclairs rose chair. Je trouvais ça menaçant et contribuant à l'atmosphère. Cela peuplait aussi l'arrière qui contenait à la base dans mon esprit un bâtiment japonais, finalement abandonné par manque de temps et d'inspiration sur comment le placer correctement.

Au final, je trouve ma contribution correcte même si un peu brouillonne. Quelque chose de propre m'aurait demandé encore pas mal d'efforts. Mais je suis content car en faisant cet exercice, j'ai appris des choses.

Le poster, dans son ensemble, a un côté malsain qui me plait, au moins sur les deux tiers haut, même s'il y a quelque chose au niveau des couleurs qui me gêne. Mais bon, c'est toujours le risque avec l'exercice des Cadavres Exquis. C'est aussi ce qui est intéressant.

Générations d'assistants électroniques

Sylvain Glaize — Mon, 26 Jul 2010 22:00:00 +0200

Pendant un nettoyage de printemps, j'ai eu l'idée de faire la photo des différents assistants électroniques qui m'ont suivi ces vingt dernières années.

De gauche à droite :

Casio fx-8500G. Certes, c'est avant tout une calculatrice, mais à cette époque, la mémoire transportable se trouve principalement là. Calculatrice scientifique programmable, elle possède aussi un mode « fichiers » qui permet de stocker du texte. Mieux vaut taper avec des abréviations, la mémoire est très limitée.
kb-1106 Digital Diary 2KB : c'est la meilleure référence que j'ai pu trouver. Visiblement, ça peut toujours se commander comme cadeau d'entreprise. Ça date un peu quand même. J'avais eu cet appareil en cadeau avec un abonnement de magazine. Ça valait ce que ça valait, mais il y avait un clavier et quelques fonctions d'agenda et de stockage de texte. J'ai utilisé cet appareil environ 3 ans je crois. Là encore, il fallait jouer avec la mémoire limitée. L'appareil me servait surtout à noter rapidement des idées pour les recopier plus tard sur mon ordinateur personnel.
Pas sur la photo : un calepin. À vrai dire, depuis longtemps, c'est un calepin en bête papier qui me suit. Pas de problèmes de piles, mais souvent des problèmes de stylo. Une mémoire de stockage importante et la possibilité d'écrire et de faire des dessins facilement.
Pocket LOOX N520 : c'est en 2004 que l'on m'offre ce PDA qui va me sortir pendant 6 ans. Wifi, extensible par SD Card, un très bon appareil. Le calepin va en prendre un coup, tout en restant dans le coin, car un calepin n'a pas besoin de recharger sa batterie et taper du texte avec un stylet n'est pas toujours le plus optimal.
Motorola Dext. Alors que mon téléphone et mon PDA montrent tous les deux des signes de faiblesse dus à leur âge, c'est l'occasion de passer au Smartphone. Jusqu'à présent, rien ne m'avait bien tenté et mon matériel fonctionnait bien. L'arrivée d'Android sur des appareils aux capacités intéressantes finissent de me convaincre.

Horreur à Arkham

Sylvain Glaize — Tue, 13 Jul 2010 13:00:00 +0200

Shub-Niggurath, Nyarlathotep, Cthulhu,... si ces noms vous évoquent de bon souvenirs de lecture ou de parties de jeux de rôle et que vous aimez les jeux de plateau coopératifs et de longue durée, alors Horreur à Arkham est fait pour vous.

Horreur à Arkham fait partie des jeux classés sous l'anglicisme "monster games" : beaucoup de matériel, un livret de règles de plus de vingt pages, la nécessité d'avoir une grande table pour jouer et une durée de jeu qui se compte en heures. Ne vous fiez pas à la durée indiquée, entre deux et quatre heures. Je n'ai jamais fait une partie de moins de trois heures beaucoup plus souvent tâté les cinq heures de jeux.

Cinq heures de jeux ! À l'heure des jeux vidéo sur le web pliés en deux minutes, cela laisse songeur. On est plus près du temps consacré à une partie de jeux de rôles. Pourtant, Horreur à Arkham n'est pas le seul "monster game" dans le paysage ludique actuel, preuve que cela peut toujours plaire.

Mais que fait-on dans ce jeu ?

Dans Horreur à Arkham, chaque joueur joue (au moins) un personnage investigateur^[1] qui doit parcourir la ville imaginaire d'Arkham et fermer des portails donnant sur des mondes extérieurs pour repousser l'arrivée d'une créature qui ne présage rien de bon pour l'avenir de l'humanité.

En d'autres termes, il va vous falloir sauver le monde ! Et comme il est difficile de sauver le monde seul, c'est en coopération avec les autres joueurs que vous allez vous lancer dans cette folle entreprise.

À chaque tour de jeu, un personnage va pouvoir se déplacer dans Arkham, combattre les monstres qui s'insinuent dans la ville, faire des rencontres dans des lieux spécifiques. Si le personnage est passé par un portail, il fera un petit tour par un monde extérieur avant de revenir à Arkham et, fort de cette expérience, pouvoir fermer le portail.

Mais à chaque fin de tour, les forces horrifiques s'emparent du plateau : ouverture potentielle d'un portail, libération de monstres dans la ville, phénomènes étranges qui modifient légèrement les règles du jeu, fuite des alliés potentiels et fermeture des magasins, approche du moment fatidique où le monstre final débarque. La fin du tour est rarement annonciateur de bonnes nouvelles.

Et c'est ce qui fait le croustillant de ce jeu qui tourne vraiment bien. Les personnages partent avec peu de connaissances, peu de matériel et immédiatement, ils sont confrontés à des choses qui les dépasse. Dès le premier tour, la course contre le jeu démarre. Il ne faut pas perdre de temps, se coordonner entre joueurs pour savoir qui va chercher les indices nécessaires à la fermeture définitive des portails, qui va s'occuper des monstres qui gênent le mouvement, qui va acheter du matériel. Une stratégie se met en place, mais est souvent mise à mal par les évènements dictés par les cartes tirées. Il faut alors choisir autre chose.

Comme dans le jeu de rôle l'Appel de Cthulhu, les investigateurs à Horreur à Arkham ne sont pas des héros, ils n'ont pas le dessus. Ils font au mieux. Et le jeu est assez bien réglé pour qu'une victoire ne s'obtienne la plupart du temps que sur le fil... quand il y a victoire.

J'en veux encore plus !

Le jeu de base contient 16 investigateurs aux capacités et caractéristiques variées ainsi que 8 Grands Anciens. De quoi faire quelques parties avant de faire le tour du jeu de base, qui lui même se renouvelle de lui-même grâce aux cartes de Mythe (les cartes évènements tirés à chaque fin de tour).

Mais qu'à cela ne tienne, ce jeu est augmenté de quelques extensions qui modifient la difficulté du jeu (je vous laisse deviner dans quel sens) et ajoute quelques règles intéressantes. Il y a deux types d'extension, le type petite boite, qui contient des cartes et quelques pions, et le type grande boite, qui contient en plus un plateau et du matériel en plus qui augmentera votre temps de préparation de jeu, la place nécessaire sur votre table de jeu et... votre plaisir de jeu.

Je n'ai joué qu'à deux d'entre elles :

La Malédiction du Pharaon Noir : une exposition se déroule à Arkham et ajoute de nouveaux évènements. Le but du jeu ne change pas, mais les investigateurs devront en plus résoudre les problèmes posés par la présence de l'exposition. L'extension ajoute de nouvelles rencontres, un nouveau concept de bénéfice/désavantage qui affecte les investigateurs, de nouveaux objets, dont ceux de l'exposition,... L'extension ajoute une bonne dose de difficulté, les objets de l'exposition compensant légèrement cette difficulté.
L'Horreur de Dunwich : ici, c'est une extension de type grosse boite à laquelle nous avons affaire. Le plateau principal se voit adjoindre un nouveau plateau, beaucoup plus petit, qui représente une autre ville, Dunwich. Cette ville vient avec son problème : une expérience qui libère l'Horreur de Dunwich, un monstre particulièrement difficile à battre. L'extension apporte aussi une règle de blessures et de folies intéressante qui permet à un investigateur de subir une affliction plutôt que de passer par la règle de base lorsqu'il perd tous ses points de vie ou de santé mentale. L'extension apporte aussi son lot de nouveaux investigateurs, alliés, objets et Grands Anciens.

À l'heure actuelle, il y a trois extensions supplémentaires en français et une en plus en anglais. Le jeu a une base de joueurs assez active, ce qui a donné lieu à des créations amateurs par-dessus le jeu. Faites un petit tour du côté du Wiki sur le jeu pour un aperçu de tout cela.

Nul doute que ce jeu sortira encore de nombreuses fois lors des longues soirées jeux.

Notes

[1] dans les jeux basés sur le Mythe de Cthulhu, le personnage aventurier confronté à l'horreur est classiquement nommé l'investigateur.

B81500 en Charentes

Sylvain Glaize — Sat, 03 Jul 2010 00:54:00 +0200

Sur la ligne Angoulême - Royan, où l'on pouvait voir passer il y a encore deux ou trois ans des compositions éclectiques, un coup de balai a limité la variété.

À la place, beaucoup de matériel neuf et quelques X2200 (ou peut-être une seule rame que j'ai vue plusieurs fois). C'est du matériel récent que j'ai pris en photo ici. La B81701, automotrice bi-mode diesel électrique, sans le pelliculage régional. En regardant un peu sur Internet, je vois cette rame, avec la B81702, photographiée sur une autre ligne. Peut-être une nouvelle arrivée donc.

La photo est malheureusement un peu floue.

La saison des projets d'été

Sylvain Glaize — Sun, 30 May 2010 20:00:00 +0200

L'été arrive, et avec, ses longues vacances scolaires. La fin d'année étudiante se fait sentir et les idées de projets commencent à fleurir sur les différents forums de discussion. Tout ce temps libre jusqu'à la reprise semble ouvrir des horizons infinis. Enfin, les idées qui trottaient dans la tête alors qu'il fallait s'occuper de révisions vont pouvoir s'exprimer, être réalisées.

Vous êtes de ces personnes là ? Excellent. Je ne peux que vous encourager.

Dans cet article je fais quelques constatations suite à une dizaine d'étés à voir des projets venir et s'en aller. Faites-en ce que vous voulez.

Les vacances d'été, il y a plusieurs manières d'en profiter. On peut aller se couvrir de coups de soleil à la plage, se rendre sourd en boite, faire le tour des fêtes de village, faire un boulot d'été,... ou encore développer l'idée de jeu vidéo qui nous trotte dans la tête depuis quelques mois.

Et vous auriez tort de ne pas en profiter.

Deux mois (un peu plus pour certains, un peu moins pour d'autres), c'est beaucoup. Et lorsque les vacances commencent, cela parait être une période suffisante pour changer le monde. À vrai dire, ça passe très vite. D'autant plus que cette période, faite pour décompresser, n'est pas propice à la concentration. Mais ce sont des vacances, et c'est fait pour ça.

Au début des vacances, on peut avoir l'impression qu'une période indéfinie de liberté s'ouvre devant nous. En vérité, la fin de cette période est extrêmement bien définie : elle s'arrêtera avec la reprise. Tous les ans, les projets que je vois démarrer en début ou milieu d'été sont faits avec le fervent espoir qu'avec l'inertie acquise pendant l'été, il sera facile de continuer en parallèle des cours.

En pratique, c'est faux : les projets s'arrêtent à l'instant de la reprise des cours. Les gens disparaissent des forums. Certains reviennent le temps de vacances d'automne ou d'hiver. La plupart pour se contenter de dire qu'ils n'ont plus de temps. Vous pensez que vous n'êtes pas dans ce cas, et que vous pourrez concilier études et projet personnel ? Tous ceux qui se sont arrêtés le pensaient aussi.

Ce qu'il faut comprendre, c'est que les vacances scolaires commencent dans un état d'esprit très particulier : on vient de quitter le rythme scolaire, un rythme demandeur en ressources de concentration, de temps passé. Et on arrive dans une période relativement libre de contraintes avec cet esprit. De l'énergie, du temps, de la motivation. L'idéal !

Mais rapidement, le rythme scolaire s'estompe. Les vacances, ce sont les vacances. On décompresse. Et puis il y a probablement d'autres projets qui trainent et finalement, aller prendre quelques coups de soleil à la plage, ce n'est pas si mal. Rapidement, on reporte à demain les activités liées au projet. L'esprit a besoin de se reposer. Et puis il y a le temps. Et le temps passe.

En résumé : l'implication dans le projet, que l'on peut croire indéfectible, de fer, inépuisable en début de vacances, va baisser avec le temps. Il va falloir une bonne discipline pour garder le rythme d'avancé du projet.

N'attendez pas non plus de réunir une équipe autour de vous, d'avoir les graphismes du jeu fini avant de démarrer, ou tout autre excuse pour ne pas démarrer. C'est le meilleur moyen de ne rien faire. L'année dernière, lors d'un des ateliers du GameCamp Paris avec pour thème les projets personnels, l'une des constatations était que la grande majorité des projets amateurs qui réussissaient étaient porté par une personne qui aurait pu faire 80% à 100% du boulot tout seul.

Il y a plusieurs problèmes à constituer une équipe pour votre projet personnel d'été. Le premier est dans l'énoncé : votre projet est personnel. Ce sont vos idées, vous y tenez. Vous allez convaincre d'autres personnes sur des généralités et celles-ci ne seront probablement pas la même motivation que la votre. De plus, ces personnes n'ont généralement pas le même planning ni les mêmes priorités que vous.

Beaucoup de projets d'été se retrouvent donc avec des personnes très motivées dans les premiers jours mais qui doivent partir en voyage, qui ont un boulot d'été, qui finalement préfèrent monter un groupe de musique, qui trouvent l'âme sœur,...

La cohésion du groupe va baisser encore plus vite et être un chef de projet demande beaucoup d'efforts. Vous risquez donc de passer l'été à coordonner des personnes qui n'oseront jamais vous dire que finalement, elles ne tiennent pas tant à vos idées que ça. Pire, qui promettent qu'elles seront disponibles dès la fin de l'été. Ce qui, on l'a vu au-dessus, est absolument impossible, même si le mensonge est par ignorance. Ce temps sera du temps perdu pour votre projet.

Si vous devez partir sur un projet en équipe, que ce soit une petite équipe, que ce soit une ou deux personnes que vous connaissez, avec qui vous avez déjà discuté, avec qui vous avez déjà échangé des petits travaux, des projets. Des gens de confiance. Pas rencontrés ou recrutés au détour d'un forum ou d'un canal de discussion. L'équipe doit être déjà formée et prête dès le début des vacances.

Sinon, allez-y seul !

Vous lisez toujours, vous êtes toujours motivés, mais vous n'avez pas encore ignoré d'un geste de la main le contenu de l'article jusqu'ici ? Alors continuons.

Une chose importante à définir dès le début est le but de votre projet. Voulez-vous tâtonner dans divers domaines pour vous faire de l'expérience ? Voulez-vous utiliser vos connaissance pour avoir un jeu abouti ?

Ces deux buts sont difficilement conciliables. Il est très difficile d'apprendre et de produire simultanément. Si vous avez un projet de jeu fini mais considérez n'avoir pas les connaissances nécessaires, séparez votre projet en deux. Apprenez dans un premier temps ce qui vous semble nécessaire. Rassemblez les informations, affutez vos compétences. Ensuite, lancez vous dans la production du jeu en elle-même.

Mener un projet de jeu complet demande des compétences diverses : programmation ou utilisation d'un logiciel de « game making », game design, graphismes, son,... N'espérez pas, pour les raisons évoquée au-dessus, trouver les compétences qui vous manquent chez d'autres. Sachez tout faire (même mal) tout seul. Ne vous laissez pas bloquer pour la raison que vous ne savez pas dessiner : faite avec des graphismes du pauvre, moches, ou essayez de vous améliorer sur ce point. Si vous attendez après un graphiste pour vous motiver à avancer, c'est que vous n'êtes pas assez motivé.

À quoi va ressembler votre jeu fini ? Je ne sais pas. Mais si vous tenez à ce qu'il soit terminé, soyez humble. On ne fait pas un MMORPG en deux mois, même avec la meilleur volonté du monde. Et pourtant, chaque année, ce sont des dizaines de projets de MMORPG qui sont postées dans les forums. Tous ces MMORPGs ont les meilleurs idées du monde, sont originaux, font ce que les autres ne font pas. Vous comprendrez si vous avez bien tout lu jusque là que ce n'est pas un projet adéquat à une période d'été.

Non, soyez humble.

Un projet humble permet d'avoir en fin d'été, si ce n'est un projet terminé, au moins un projet bien avancé. Un projet bien avancé peut se reprendre aux vacances suivantes.

Un projet bien avancé peut aussi prétendre enfin à intéresser d'autres personnes constituant une équipe.

La première chose à faire, donc, est de mettre vos idées à plat, de considérer ce que vous pouvez et faire ou non et démarrer !

Et venez relire ce billet à la fin des vacances.

Jeux sous Linux, est-ce si difficile ?

Sylvain Glaize — Wed, 26 May 2010 21:00:00 +0200

Parfois, au détour d'un article sur le jeu vidéo, je lis des phrases du type les « développeurs font très peu de jeux sous Linux car la plateforme est difficile à programmer ». Comme ça, sans se perdre dans les détails de la difficulté. Et parfois même dans des magazines ou des sites de bonne qualité... quand ils parlent jeu. La raison du manque de jeux natifs sous Linux semble donc être d'ordre technique. Voyons ça de plus près.

Définissons un peu le contexte : nous parlons ici de jeux natifs, c'est-à-dire que l'on installe sur le disque dur et qu'on lance localement et non des jeux de technologies web, comme les jeux Flash ^[1].

Je vais passer en revue différents domaines de la création d'un jeu, d'un point de vue technique, pour voir où cela pourrait coincer.

Le hardware

Mentionner Linux est assez vague, Linux est techniquement le nom d'un noyau de système d'exploitation qui peut se lancer sur de nombreuses plateformes, avec du hardware très différent. Cependant, lorsque l'on mentionne Linux dans un contexte d'ordinateur personnel, et encore plus lorsque l'on parle de jeux, il y a abus de langage. Lorsque ces articles parlent de Linux, ils parlent en fait des systèmes d'exploitation basées sur le noyau Linux (on appelle ça des distributions) utilisées sur un ordinateur personne de type "PC".

Autrement dit, on parle ici de Linux tournant sur du hardware qui pourrait faire tourner Windows.

Même si ces deux systèmes d'exploitation ont une manière de voir leur environnement différente, il reste que, derrière, ce sont donc les mêmes périphériques avec les mêmes normes techniques, les mêmes processeurs, les mêmes cartes graphique et mêmes cartes son.

Du fait du peu de support de certains constructeurs au niveau des drivers, il y a même moins de périphériques compatibles Linux que compatibles Windows. On verra plus loin que c'est un avantage du point de vue du développeur.

Accéder au hardware

Si le hardware est sensiblement le même sous un PC sous Windows ou Linux, cela peut être la manière d'y accéder qui gêne. En effet, il n'y a par exemple pas DirectX(R) sous Linux, du moins pas nativement. Sous MacOS-X ou Playstation 3 non plus. Ce qui ne gêne pas certains développeurs de développer des jeux sur ces plateformes.

Forcément, un développeur qui choisi une solution technique fortement ancrée pour une plateforme spécifique va avoir une certaine difficulté à faire tourner son jeu sur une autre plateforme. Mais c'est un choix, qui peut d'ailleurs être tout à fait judicieux, pas une obligation.

On pourrait alors arguer qu'il est plus difficile de programmer un jeu sous Linux car les environnements dédiés jeu sont plus nombreux et plus facile à mettre en œuvre sous Windows. C'est un argument recevable pour les petites productions qui vont développer sur du XNA ou du Unity3d. Si je doute que XNA permette de faire un jour des jeux sous Linux, cela ne doit poser aucun soucis technique à Unity3d, qui cible déjà des plateformes bien plus variées qu'un simple changement d'OS sur un même matériel.

D'autres plateformes, comme Unreal, ciblent déjà Linux.

Les assets

On pourra noter aussi que, puisque seul la couche logicielle change, deux versions Linux et Windows d'un même jeu peut partager ses assets (textures, meshs, sons,...). Les performances seront similaires et il est de toute façon d'usage dans le monde du jeu PC de permettre à l'utilisateur de régler le niveau de détail du jeu, sachant qu'il tournera sur des machines à des puissances très différentes.

C'est à comparer avec un jeu commun entre une console de salon et un PC, voire entre deux consoles de salon, où il n'est pas rare de devoir adapter les assets pour tirer le meilleur parti des différences de plateforme.

Conclusion sur le hardware

Si un jeu Linux est plus difficile à programmer qu'un jeu Windows, on vient de voir que cela ne venait pas du hardware. Programmer un jeu sous console, et encore plus multi-plateforme PC/Console, est bien plus complexe. Et de nombreux développeurs le font quand même.

Cherchons ailleurs.

Compétences logiciel

Puisque le matériel n'est pas en cause, regardons du côté logiciel. Il y a bien sûr de quoi programmer le hardware sous Linux : des jeux existent, même s'ils sont peu nombreux. Peut-être s'agit-il de manque de compétences pour programmer la plateforme ?

Là encore, je dis non. D'abord car les API disponibles sous Linux sont souvent déjà connues des développeurs (OpenGL ou FMOD par exemple) et qu'ensuite, encore une fois, des développeurs qui sont capables de réapprendre à chaque nouvelle génération de console un matériel et des API nouvelles peuvent très bien apprendre à programmer sous Linux.

Je n'ai pas de chiffres, mais quelque chose me dit qu'il y a bien plus de programmeurs au fait des technologies utilisées sous Linux que de programmeurs sur console.

Autres raisons

Le temps

On ne peut pas le nier : développer pour une plateforme en plus, en considérant que la version maitresse est la version Windows, prend du temps. Il y a deux manières de faire une version multi-plateforme :

développer les versions simultanément : beaucoup plus facile car les problèmes sont détectés sur le moment, la méthode demande cependant plus d'investissement.
développer une version, puis l'autre : cela peut amener la seconde version à hériter de bugs cachés dans la première version et demander un peu plus de travail ; l'avantage étant que l'investissement est décalé par rapport au développement de la première version.

Le temps de développement supplémentaire est-il si gros ? Rappelons encore que nous sommes là sur une même machine. Seule la couche logicielle change. Si les bons choix architecturaux et technologiques sont fait dans la version initiale en prévision de son portage, alors le temps d'adaptation à l'autre plateforme n'est pas si énorme.

À titre d'exemple, j'ai adapté pour Linux un jeu Windows. Je n'ai pas vraiment compté le temps que j'y ai passé, mais cela n'a pas dépassé 10 heures (j'évalue plutôt à 7 heures, temps de tests compris). Ce jeu était déjà adapté au multi-plateforme et l'adaptation consistait à implémenter quelques fonctions et recompiler le tout. Quelques bugs sont apparus (méthode numéros deux ci-dessus) et ont fait que cela a pris un peu de temps. L'adaptation n'est pas parfaite : il resterait à faire un package avec gestion de dépendances, méthode préférée sous les distributions Linux au simple .zip que j'ai livré. Il reste aussi quelques soucis qualitatifs à l'installation.

Il reste probablement 2 ou 3 heures à passer dessus.

10 heures... 10 heures pour un programmeur seul. Ce n'est pas un gros programme, mais cela donne une idée du peu de travail nécessaire.

En fait, et cela se ressent dans les problème qualitatifs que j'ai mentionné, ce qui a manqué est principalement du test : j'ai testé le jeu sur deux ordinateurs, il a été testé par quelques personnes qui ont bien voulu faire un retour. Cependant, il manquait une vraie phase de tests sur différents matériels et différentes distributions.

Et c'est cela qui prendrait du temps pour une adaptation complète. Et le test sur ordinateur personnel est long car il nécessite beaucoup de tests matériel, ce qui n'est pas le cas sur console.

En cela, oui, adapter un jeu sous Linux est plus long qu'adapter un jeu sur console. À balancer avec le temps de développement, qui lui, est plus court.

Et c'est là, je l'évoquais tout à l'heure, que le matériel plus restreint supporté par les distributions Linux est un avantage. Moins de matériel à tester.^[2]

Diversité des distributions

Comme je l'évoquais au début, Linux est un abus de langage pour désigner de nombreux systèmes d'exploitation ayant pour base commune le noyau Linux. Cependant, cet abus de langage est assez limité : on ne désigne pas Android sous le nom de Linux, pourtant, s'en est un. Le noyau Linux est présent dans de nombreux matériels sans que leurs utilisateurs soient au courant.

Finalement, sont appelés Linux un nombre restreint de produits. Restreint mais nombreux tout de même : Debian, Red Hat, Ubuntu, Suse, Slakware,... La page sur Wikipedia présente même un arbre généalogique des différentes distributions.

Cela fait peur : est-ce que le programme tournera de la même manière sur toutes les distributions ? Il y a des solutions techniques, plus ou moins élégantes, mais dans les grandes lignes, cela ne pose pas vraiment de problèmes. La difficulté se situe à nouveau dans le test, qui sera multiplié par le nombre de distributions supportées. Elle se situera aussi éventuellement dans l'intégration naturelle à une distribution, l'histoire de package que je citais au début.

À noter que dans le monde Windows, le problème de disparité des versions existe aussi : toutes les versions de Windows ne se comportent pas de la même manière. Le monde Windows a réglé le problème : à une époque donné, un jeu n'est généralement compatible qu'avec la dernière version grand public et sa précédente.^[3] Peut-être qu'il tournera avec d'autres versions. Cela n'est juste pas garanti.

On peut imaginer la même chose dans le monde Linux : un développeur peut garantir le fonctionnement pour Ubuntu et toucher ainsi la grande majorité des utilisateurs grand public, éventuellement une autre grande distribution. Sur le reste... et bien cela fonctionnera peut-être.

D'autres plateforme ont des éclatements bien pire : dans les téléphones portables, il faut à peu près faire une version du jeu par modèle de téléphone. Même sur des plateforme concentrées comme iPhone ou Android, les divers matériels et les diverses versions obligent à gérer la diversité des plateformes.

Là encore, finalement, tout n'est question que de temps, de volonté de faire. Il n'y a pas d'obstacle technique insurmontable, et aucun qu'on ne trouve déjà ailleurs.

Les outils

Le sujet est un peu annexe, car lorsque l'on programme pour console, on ne programme pas sur console. Et il n'est pas obligatoire lorsque l'on programme pour Linux de programmer sur Linux.

Mais cela serait dommage de s'en passer.

Cependant, lorsque je parle de programmer sur Linux à certains programmeurs, j'ai parfois droit à des yeux ronds. Particulièrement chez les plus anciens qui ont gardé des souvenirs visiblement douloureux de leurs études à programmer avec des outils vus comme rustiques.

Autrement dit : il n'y a pas Visual Studio sous Linux, comment on va faire ?

Heureusement, sur Linux sont disponibles de nombreux outils de développement. Si l'on veut quelque chose d'aussi peu pratique que Visual Studio ^[4], on peut retrouver une sorte de clone avec Code::Blocks. Mais on peut aussi aller vers Eclipse, pour citer un autre environnement bien connu, ainsi que des solutions libres ou propriétaires de différents types. Il y en a pour tous les goûts.

Et non, vous n'êtes pas obligés d'utiliser gdb en ligne de commande pour débugger.

Mais alors ?

Si tout à l'air si simple et si rose dans le développement de jeux sous Linux, pourquoi y en a-t-il si peu ?

Cet article, qui est écrit en réaction à la phrase « la plateforme est difficile à programmer », a tenté de montrer brièvement que la technique n'était pas en cause. Les programmeurs de jeux vidéo ont l'habitude de résoudre de problèmes et de programmer sous des plateformes bien plus complexes qu'un simple changement de couche logicielle sur une plateforme PC.

C'est ailleurs qu'il faut chercher l'absence de gros titres sur Linux. Alors qu'on y trouve de plus en plus d'indépendants.

Tout simplement, le retour sur investissement n'est pas évident. Il n'est même probablement pas calculé par la plupart des éditeurs. La plateforme Windows est une plateforme très piratée et je pense qu'il y a une crainte que, pour une même plateforme matérielle, la situation soit la même sous Linux.

Les joueurs étant peu nombreux sous Linux (puisqu'il y a peu de jeu ; problème de l'œuf et de la poule), ce marché de niche est délicat à négocier, particulièrement si le développement conjoint ou le portage du jeu coûte cher.

Pourtant, les sorties de World of Goo l'année dernière et du Humble Indie Bundle cette année ont montré deux choses : il y a un public joueur et demandeur qui utilise Linux d'une part et ce public est près à payer d'autre part. En effet, quand World of Goo est passé en "Payez ce que vous voulez", les statistiques ont montré que les joueurs Linux avaient en moyenne dépensé plus pour le titre. La même chose a été constatée sur l'Humbel Indie Bundle.

On pourra penser que la rareté du jeu sous Linux provoque ce paiement plus fort. Peut-être. Mais on voit surtout qu'il y a un marché qui ne demande qu'à s'emballer.

Qui fera le premier pas ? Des tentatives d'éditions ont été faites pour les jeux sous Linux. Quelques gros jeux, comme Unreal ou Quake, ont été sortis dessus^[5].

Ce qu'il manque, à mon avis, et qui pourrait rassurer les éditeurs sur les risques de piratage sur un marché de niche, c'est une plateforme de vente online. Steam sous Linux par exemple ? Après tout, Steam est à présent disponible sur MacOS-X, une autre plateforme traditionnellement pauvre en jeu vidéo.

Même si j'aimerais qu'un concurrent sérieux à Steam apparaisse, pour éviter les risques de monopole qui seraient dommageables, je verrai l'arrivée de Steam sous Linux d'un très bon œil. C'est le genre de choses qui me feraient jouer à nouveau sur PC.

Messieurs les éditeurs, à vous ! Ne vous inquiétez pas, les studios de production sauront faire.

En guise de continuité, je vous propose d'écouter le podcast Du pain et des jeux épisode 1 où l'on retrouvera un passage sur Steam sur Mac avec une évocation d'un éventuel Steam sur Linux.

Notes

[1] Ces derniers sont à présent bien supportés sous Linux, pour peu que l'on installe le plugin Flash officiel

[2] Tout ce que l'on peut espérer, finalement, c'est un cercle vertueux où des joueurs supplémentaires sous Linux incitent les constructeurs à livrer des drivers pour plus de matériel.

[3] À une certaine époque, Windows Me a tout simplement été boudé et n'était pas supporté par la plupart des jeux, alors que c'était la dernière version.

[4] j'ai longtemps hésité à laisser ça dans l'article, mais finalement...

[5] Qui sont aussi des vitrines technologiques dans ces deux cas

Frein à la programmation : l'ajout de fichier

Sylvain Glaize — Wed, 05 May 2010 22:00:00 +0200

Lorsque l'on regarde l'ensemble des actions que doit effectuer un programmeur pour faire son travail et que l'on réfléchi à ce qui pourrait être amélioré pour lui faciliter la vie, on tombe sur des petites choses qui n'ont l'air de rien et qui pourtant ont de grosses répercussions.

L'ajout d'un fichier à un projet en est une.

Lorsqu'un programmeur ajoute un fichier à un projet auquel il participe, voici généralement ce qui doit être fait :

créer le fichier sur le disque,
l'ajouter à la solution,
l'ajouter au gestionnaire de version,
l'ouvrir et en écrire le squelette.

Ces actions peuvent être regroupées. L'idéal est qu'elles le soient. L'idéal serait d'utiliser un éditeur qui ajoutera le fichier dans la solution, l'écrira _au bon endroit_ sur le disque, l'ajoutera au gestionnaire de version et écrira un squelette.

C'est le cas lorsque j'utilise Eclipse sur un petit projet personnel en Java. Les manipulations restent un peu trop nombreuses à mon goût, mais on s'approche de l'idéal.

Cependant, dans la quasi totalité des projets auxquels j'ai pu participer ou que j'ai pu voir en action, on est loin de l'idéal :

la création depuis l'IDE d'un fichier n'est pas reflété correctement sur le disque, ce qui oblige à créer le fichier puis à l'intégrer dans le projet (à ce propos, voir mon article sur le sujet) ;
le connecteur entre l'IDE et le gestionnaire de version ne fonctionne pas très bien : cela implique que les programmeurs se battent contre le plugins et ne l'utilisent pas à 100% ;
la création de squelettes de fichiers se fait généralement par copier/coller, ce qui induit parfois (et trop souvent) des erreurs de nommages ou, en C++, des erreurs de gardes d'inclusions.

En C++, le travail de création d'un fichier est au moins doublé (entêtes et sources) voire triplé (fichier séparé pour les inlines).

Si vous pratiquez le TDD, alors il faudra aussi créer le fichier de tests associé.

Quels sont les problèmes que cela entraîne ?

Si une de ces étapes est manquée, le projet ne compile plus :

la création du ou des fichiers, bien entendu, est obligatoire.
oublier de l'ajouter à la solution ne fera pas prendre en compte le fichier : j'ai déjà eu l'occasion de voir des fichiers compilés à part, utilisés depuis le reste du programme, archivés... sans avoir compilé le projet en entier. Cela est particulièrement vrai si un même fichier est utilisé par plusieurs projets.
oublier de l'ajouter au dépôt : tout se passera bien jusqu'à ce que la machine de build ou un collègue reprenne le code. À noter une version voisine : les fichiers sont bien archivés, mais pas le projet modifié, erreur classique lorsque l'IDE utilisé nécessite une action supplémentaire explicite pour sauver la nouvelle version du projet.
bien évidemment, ne rien mettre dans les fichiers n'avancera pas à grand chose. À noter qu'au moins, il n'y aura pas de soucis. Ici, le problème viendra plutôt d'un copier/coller malencontreux qui ne posera pas de problème sur la machine du programmeur mais qui pourra en poser lors du passage sur la machine (ordre de compilation différent, projet utilisé dans un autre contexte).

Toutes ces étapes prennent du temps et les risques d'erreurs sont nombreux.

Puisqu'un programmeur veut généralement développer en un minimum de temps, ces actions sont considérées comme un frein et la tentation est grande de les éviter. Mon expérience me montre que beaucoup (trop) de programmeurs se laissent aller à cette tentation.

Dans les faits, éviter de créer un nouveau fichier entraîne des conséquences en cascade :

puisque ajouter un fichier est long et source d'erreur, s'il y a le choix de ne pas en ajouter, ne pas l'ajouter,
de nouvelles fonctionnalités qui ont besoin d'une nouvelle classe se voient insérées dans un fichier dont la classe est connexe,
puisque les fonctionnalités sont dans le même fichier, l'étape d'après est de s'insérer directement dans une classe existante.

Au final, moins de classes, des fichiers plus gros, des problèmes de dépendances entre système, une architecture qui s'écroule^[1].

Tout cela à cause d'une simple petite chose : la création d'un fichier dans un projet n'est pas simple !

C'est un point à ne pas négliger si vous mettez en place un projet ou que vous en maintenez un. Pensez à tout ce qui peut aider un programmeur à ajouter un nouveau fichier dans le projet.

Quelle est la solution idéale ?

J'en ai soufflé en mot au début. L'idéal est bien entendu que le programmeur ait un moyen très simple (une boite de dialogue et un bouton de validation) d'ajouter un fichier dans le projet. Eclipse en mode Java s'en approche, il ne me manquerait pas grand chose^[2].

La boite de dialogue, à partir des renseignements donnés, doit pouvoir :

créer le ou les fichiers au bon endroit en respectant l'architecture physique du projet.
remplir les fichiers avec le minimum : entêtes légales si vous en avez, inclusion de l'entête correspondant au source et inclusion éventuelle de pre-compiled header en C++, écriture des espaces de noms, d'un squelette de classe en fonction des choix de la boite de dialogue.
ajouter les fichiers dans la solution ; bien entendu, si votre solution est dynamiquement générée depuis le contenu du disque, cette action est gratuite. Avec un IDE, ce n'est pas forcément évident, sauf si la méthode de création est intégrée à l'IDE, au prix d'une dépendance forte avec l'utilisation de cet IDE.
ajouter les fichiers au gestionnaire de version ; si votre gestionnaire de version scan les nouveautés automatiquement (subversion, bazaar, git,...) cela ne demande pas d'effort, dans d'autres cas (Perforce,...) cela est une étape obligatoire pour palier aux défaillances de certains connecteurs d'IDE.

J'ai eu l'occasion de mettre en place un tel système pour un projet personnel, j'ai aussi mis en place une partie de ce système (pas d'intégration avec l'IDE utilisé) sur un projet professionnel.

Dans mon cas, le gain de temps m'a aidé à me concentrer sur l'écriture du programme plutôt que sur l'écriture des détails (et certains langages, comme le C++, sont bavards et demandent beaucoup d'à côté avant de pouvoir écrire une première ligne qui fait réellement quelque chose).

Dans le cas du projet professionnel, j'ai eu des retours positifs des utilisateurs et j'ai pu constater une chute des erreurs de copier/coller dans les en-têtes ainsi que moins de réluctance à créer un fichier par classe et au bon endroit de surcroit.

Je vous conseille donc de vous attacher à cette petite chose dans la vie d'un programmeur qu'est la création d'un nouveau fichier.

Notes

[1] pour le cas où une architecture était en place.

[2] la boite de dialogue par défaut est un peu trop touffue et la création automatique du fichier de tests ne correspond pas par défaut à mon architecture physique, ce qui m'oblige à éditer plusieurs champs toujours de la même manière

Pommes, Manchots et Allumettes

Sylvain Glaize — Mon, 26 Apr 2010 23:55:00 +0200

Le jeu de nim fait partie de ces jeux simples dont les mécanismes forment les bases de bon nombres d'autres jeu. Il peut se jouer de plusieurs manières différentes, mais le mécanismes est celui-ci : deux joueurs alternativement prennent d'un ensemble d'objet 1 à 3 éléments, celui qui joue le dernier coup (plus d'éléments restant) est le gagnant (ou le perdant, suivant la variante).

Ayant découvert le jeu avec des ensembles d'allumettes, le jeu reste pour moi le « jeu des allumettes ». Je ne dois pas être le seul car lorsque je parle du jeu de Nim avec quelqu'un et que je ne le vois pas comprendre, je parle alors du jeu des allumettes et je suis compris.

Le mécanisme du jeu de nim faisant partie des bases, on le retrouve sous diverses formes dans les jeux. Et deux parties de deux jeux jouées hier me font écrire ce billet.

22 pommes

Dans 22 pommes, chacun des deux joueurs doit ramasser exactement 22 pommes (d'où le nom). Mais pas n'importe comment : 11 pommes rouges et 11 pommes vertes exactement.

Le principe du jeu de nim se retrouve assez facilement : les deux joueurs se partagent le même fermier et à son tour, un joueur est obligé de prendre des pommes. 1, 2, 3 ou 5. Si la prise amène un joueur a 11 pommes de chaque couleur, il gagne la partie. Si la prise amène un joueur a plus de 11 pommes d'une même couleur, il ne pourra pas gagner, il a donc perdu. Tout comme au jeu de nim, il n'y a pas d'égalité possible.

Là où 22 pommes s'éloigne du jeu de base, c'est dans le mécanisme de prise. En effet, le jeu de nim n'est pas très intéressant lorsque l'on connait le truc. Si les deux joueurs connaissent le truc, alors le premier à jouer détermine qui va gagner et perdre (voir l'article Wikipedia à ce sujet).

Dans 22 pommes, on ne choisit pas directement le nombre de pommes prises : le choix est limité par le déplacement du fermier, qui ne peut se déplacer qu'horizontalement ou verticalement dans un verger de 5 par 5 arbres (jetons) et est obligé de s'arrêter sur un jeton, que le joueur prend.

Comme les deux joueurs se partagent le même fermier, chacun d'eux doit prévoir son déplacement non seulement en fonction des pommes dont il a besoin, mais aussi pour limiter les choix de l'autre joueur et l'obliger à dépasser les 11 pommes d'une couleur.

22 pommes est un petit jeu fun. Les règles s'expliquent en deux minutes, une partie ne dure pas longtemps, on y réfléchi, mais pas trop et ça tient dans une petite toute petite boite. Et pour le même prix, il y a dedans une variante pour corser la difficulté, une recette de cuisine et quelques informations sur les pommes.

Des manchots et des poissons

En variant encore le principe, on arrive à « Pingouins » ou encore « That's my fish » ou « Packeis am Pol » suivant la version que vous trouvez. Preuve que dans le jeu de société comme au cinéma, un nom peut changer du tout au tout pour le même contenu.

Dans Pingouins, la ressource qui se raréfie est double : les poissons, dont le nombre donnera le score final, mais aussi la banquise, qui va disparaitre sous les pattes des manchots affamés.

Chaque joueur, qui peut aller de 2 à 4, contrôle de 4 à 2 manchots placés sur une banquise formée d'éléments hexagonaux. À son tour, un joueur déplace l'un de ses oiseaux en ligne droite de la distance qu'il souhaite. Il doit cependant arrêté par les autres manchots ainsi que par l'absence de banquise. L'élément quitté par le pion est pris par le joueur et gardé comme score.

On s'éloigne un peu du jeu de nim : chaque joueur influe sur les éléments à prendre grâce à ses propres pions, il peut y avoir des égalités.

Mais pas tant que ça : le nombre de poissons pouvant être pris va de 1 à 3 (même si ça n'a pas la même influence qu'au jeu de nim, la ressource qui disparait est avant tout la banquise), un élément devient de plus en plus rare, il est possible de bloquer ses adversaires dans des situations désavantageuses en les forçant à prendre la dernière pièce.

En effet, comme à 22 pommes, le but d'un joueur est à la fois de maximiser son nombre de points, mais aussi de se déplacer de façon à interdire aux autres joueurs des déplacements avantageux.

Autre petite particularité par rapport au jeu de nim : il est possible de créer des sous-jeux (des morceaux de banquises indépendants). C'est ce qui arrive à peu près tout le temps à partir du milieu de partie. Cette sous-partie peut être catastrophique pour le ou les pions qui s'y trouvent (pas assez de place, plus beaucoup de déplacements possibles). Mais c'est aussi un moyen de se réserver un bout de banquise en isolant l'un de ses manchots qui ne sera alors plus gêné par le déplacement des autres.

« Pingouins » est un peu plus long que 22 pommes. La mise en place (construire la banquise est plus long que construire le verger), le nombre de joueurs, la taille du terrain de jeu qui font que les premiers coups demandent plus de réflexion. Et à moins de mettre les éléments de jeu dans une boite à vous, moins transportable : la boite de jeu est démesurément grande par rapport à son contenu (un moyen d'être visible sur les étagères d'un magasin).

Cependant, le jeu permet de réunir quatre personnes autour d'une table. Le principe s'explique en deux minutes et les manchots sont plus amusants que le fermier. Un bon petit jeu de réflexion pas trop prise de tête.

La Grille

Sylvain Glaize — Sun, 24 Jan 2010 12:00:00 +0100

À l'origine de « La Grille », il y a un atelier du Games Creators Network sur la création automatique de grilles de mots.

J'y travaille de temps en temps, et j'ai décidé de faire de ma contribution à l'atelier un site dans lequel j'explique ma démarche de développement lors d'optimisations et d'ajouts de fonctionnalités.

Le site a débuté début janvier 2010, il n'y a pas encore beaucoup d'articles, mais déjà pas mal de choses à lire.

Rendez-vous sur « La Grille ».

Divers modélisme et figurines

Sylvain Glaize — Wed, 20 Jan 2010 20:00:00 +0100

En triant un peu les images que j'avais mises sur le site avec probablement l'idée d'en faire un article sur le moment, j'en retrouve certaines qui n'ont jamais eu cet honneur.

Voici donc, avec du retard, quelques travaux personnels :

Cela date d'août 2008. Le principe est de faire tenir un élément de décors pour jeu de figurine sur un CD-Rom sacrifié pour l'occasion. Très probablement en ancien CD publicitaire, ou bien une gravure échouée.

Un nain de chez Fenryll. J'ai du mettre 5 ans à peindre ce Nain... Pas en continue, bien entendu. La photo a été prise en décembre 2008. Le décors dessous est du Fat Dragon.

Plus vieux, ce décors a été fait pour un petit concours organisé en début 2005 par Urban Zone, autour du jeu Urban War.

Android : affichage et profiling à tatons

Sylvain Glaize — Thu, 14 Jan 2010 20:00:00 +0100

En regardant la documentation, les exemples et les codes sources disponibles sur Android, on s'aperçoit qu'il y a beaucoup de manières différentes de mettre à jour un affichage. Je vais devoir en choisir un et ne pas me fermer la porte aux autres.

Affichage

En effet, j'ai à présent un serpent qui bouge, il faut donc que je mette à jour l'affichage de l'état du jeu. J'ai déjà fait une interface dans le programme avec dans l'idée que je pourrais un jour passer d'une méthode à une autre, mais sans connaître la plateforme dans les détails, je ne suis pas certain d'avoir tout prévu.

Pour le moment, j'affiche en passant par un Canvas qui m'est envoyé dans le onDraw() de ma View. C'est une des méthodes les plus simples. Est-elle adaptée, je n'en sais rien.

Dans un premier temps, je me contente d'invalider la surface dès que j'ai terminé mon affichage : à la fin du onDraw(), j'appelle invalidate(). J'ai le sentiment que ce n'est pas une méthode terriblement bonne. Que se passe-t-il quand j'appelle invalidate() ? Est-ce que je ne risque pas de tirer un peu trop sur les ressources de la machine ?

Je vois un autre soucis : puisque le contrôle du jeu se fait depuis le onDraw() de la View, je suis dans un contexte d'affichage. D'après les informations que j'ai pu glaner, j'ai plutôt intérêt à ne pas trop bloquer dans cette méthode et à rendre la main au système « rapidement ».

On sent venir le thread séparé qui va s'occuper de la mise à jour du jeu...

Comme j'ai besoin que cela bouge à l'écran et que je n'ai pas forcément envie de jouer une séquence à chaque fois, j'implémente rapidement une petite IA de serpent qui suit les bords de la grille.

Profiling

J'ai donc besoin de savoir ce qu'il se passe sur la machine. Pour cela, le SDK propose plusieurs choses : DDMS, qui se charge de se connecter à la machine (l'émulateur dans mon cas) pour aller y récupérer des informations sur la mémoire, les threads ; un outil de profiling, TraceView ; une possibilité de dump HPROF.

Pour le moment, je ne fais pas assez de choses dans le jeu pour que la mémoire ait une importance. Cela alloue quand même déjà 3 Mo, probablement le système.

Je commence par m'assurer de quelque chose : est-ce que la méthode du invalidate() dans le onDraw() génère beaucoup trop d'appels. Pour cela, je mesure le temps entre deux appels à onDraw à l'aide de SystemClock.uptimeMillis(). J'obtiens une moyenne de 1/60ième de seconde avec des périodes stables et quelques pics à 1/30ième et quelques fois à 1/20ième. Mais c'est assez stable.

je ne sais pas si le rafraichissement au 1/60ième de seconde est une constante sur les différents téléphone, mais en tout cas, je vois que l'OS met l'invalidation de la surface dans une fil d'attente pour la frame suivante. C'est une bonne chose, cela signifie que même cette méthode basique ne va pas faire écrouler les ressources du téléphone.

Un petit coup de HPROF me montre quelque chose : je ne consomme rien en mémoire par rapport aux objets Android que je consomme. Il y a un poids de base pour une application Android qui n'est pas à négliger.

Passons à Traceview. J'encadre le code de onDraw() avec les fonctions de démarrage et d'arrêt de profiling. Première constatation, ça ralenti pas mal l'exécution. Seconde constatation, ma fonction de déplacement gère le « delta t » sans borne maximale. Du coup, je me trouve avec des consommation aberrantes dans la mise à jour des déplacements.

Petite modification donc : je limite le « delta t » maximum.

Que me dit alors le profiler : que je passe la moitié du temps à afficher la grille de debug...

Je profile alors entre onStart() et onStop() pour avoir une vue d'ensemble de l'application. Le résultat est que 50% du temps de l'application est passée dans le framework Android, et le reste dans mon application. Sur émulateur, j'ai calculé que mon temps de mise à jour du jeu était en peu en dessous de 2ms. Ce qui donne un poids côté Android de 2ms.

On me souffle cependant qu'un vrai téléphone est plus rapide que l'émulateur.

Android : deuxième pas

Sylvain Glaize — Mon, 11 Jan 2010 20:00:00 +0100

Je continue mon petit jeu sous Android.

Après un peu de refactoring sur mon affichage de grille et quelques petits ajouts pour la placer correctement sur l'écran et que les cases soient carrées, je me lance dans l'affichage du serpent puisque mon jeu est un « snake ».

Je m'aperçois alors qu'il n'y a pas spécialement de classe pour gérer des vecteurs au sens mathématique. Or je préfère travailler avec des objets contenant des coordonnées plutôt que le couple (X,Y). Qu'à cela ne tienne, ce n'est pas bien compliqué à implémenter. J'ai cherché un peu sur le net et je n'ai pas trouvé de classe toute faite et simple à intégrer. Je n'ai pas non plus cherché très longtemps. Si j'ai besoin de plus d'outils de ce style, il faudra probablement que je cherche mieux. Cependant, un « snake » a des besoins mathématiques très modestes.

Pas de soucis pour implémenter la notion de « snake », c'est du Java pur, pas besoin de toucher à Android.

Petite surprise au niveau de la classe View, qui ne possède pas dans son constructeur ses information de hauteur et de largeur. Ce n'est pas extraordinaire, les vues sont probablement arrangées après le setContentView(). D'autant plus que ces valeurs peuvent changer en fonction de l'orientation de l'écran.

Mis à part ça, pas de surprise, et en affichage de debug, voici l'état d'un serpent de taille 4 ayant fait les mouvements « bas », « droite » puis « bas ».

Pour le moment, toute l'instanciation du jeu ainsi que les trois mouvements du serpent, sont fait à la main, de même que l'envoi à l'affichage.

Android : premiers pas

Sylvain Glaize — Thu, 07 Jan 2010 20:30:00 +0100

Après avoir un peu lu les pages pour développeur Android et pas mal discuté avec un collègue, j'ai décidé de découvrir un peu l'univers Android côté programmeur.

Un SDK qui se charge et s'installe sans soucis, avec des étapes bien documentées. Un émulateur de téléphone qui se configure et se lance depuis Eclipse comme un charme. Voilà qui change de mes essais de programmation sous Windows Mobile.

Le site d'Android côté développeur présente les concepts généraux d'une application sur téléphone Android et propose quelques exercices pour découvrir l'environnement. C'est plutôt bien fait et assez facile à suivre si vous connaissez déjà Java et Eclipse. Rapidement, vous avez vos premières applications qui tournent.

Après un petit tour des exemples et quelques essais seul, je décide de me lancer dans une application complète. Il n'y a que comme ça que l'on peut comprendre plus profondément. J'écris donc un mini game design : cela sera un jeu style « snake ». Rien de bien original, l'intérêt n'est pas là.

Tests !

Si vous lisez les billets Informatique de ce blog, vous avez déjà du comprendre que je suis un adepte des tests et du TDD. Il me faut donc mettre en place un projet de tests. Cela tombe bien, à la création d'un projet Android par Eclipse, l'aide à la création demande si l'on veut aussi créer un projet de test. Ce que je fais. C'est du jUnit3 et le système avec un projet complètement séparé ne me plait pas forcément. J'aurais préféré jUnit4 et un seul projet avec les tests justes séparés dans un autre package.

Mais comme je ne connais pas encore bien le framework, je vais laisser comme ça pour le moment.

J'écris mes premiers tests et... ah oui, il me faut un framework de mock aussi.

Sur le net et via mon collègue, je trouve quelques pistes sur le blog de Diego Torres Milano ainsi que sur celui de stanb.

Je choisi EasyMock. Sa syntaxe à l'air simple et ses capacités correctes. J'avoue, c'est un peu au feeling, ma connaissance des frameworks de mock en Java est assez limité.

C'est parti

De mon game design, je déduis quelques tâches simples avec un résultat visible. La première, avoir une grille de debug à l'écran (le jeu se passera sur une grille) va me permettre de mettre en place l'architecture de base. Je lutte un peu avec EasyMock car je dois apprendre son fonctionnement en même temps, mais ça se passe bien.

Après un petit moment, me voici avec une View que je peux contrôler et qui affiche une grille à l'écran. Ça n'a l'air de rien, mais cela m'a permit d'avoir une structure de base d'un renderer d'objet. On est loin d'un moteur d'affichage complet, ce n'est pas le but de l'exercice, mais j'ai les bases pour afficher des objets à l'écran, c'est ce que je voulais.

Rien de bien excitant, mais au passage, j'ai aussi appris à me servir du debugueur (en partie, il y a des choses comme le profiler de mémoire que je n'ai fait qu'explorer).

Debug : un état d'esprit

Sylvain Glaize — Sat, 02 Jan 2010 23:30:00 +0100

Il y a peu, un chef de projet demandait à l'équipe informatique : « comment vous faites pour trouver des bugs ? ». La question m'a surprise et ma réponse fut quelque chose du genre « si tu as quelques jours devant toi, je t'explique ». À vrai dire, je n'avais pas vraiment de réponse à donner et l'ampleur de la réponse me semblait importante.

Cependant, cela m'a fait réfléchir à la question, car il y a effectivement un apprentissage du debug (déverminage en français... ce sera la dernière fois de l'article que j'utiliserai ce mot) et tous les programmeurs ne sont pas forcément à l'aise avec cette partie du développement.

C'est d'ailleurs le première chose qui m'est venu à l'esprit : il y a des débutants qui se lancent dans du debug efficace et des programmeurs de longues dates qui ne s'en sortent qu'avec difficultés. Je me suis donc dit qu'il y avait quelque chose de plus que l'expérience, qui compte néanmoins, pour aborder un debug avec efficacité.

Le debug commence par une constatation : il y a un bug. Le programmeur peut être confronté à ce bug directement ou indirectement, via un rapport de testeurs ou d'utilisateurs. Cette première phase est importante car elle nécessite une lecture de ce bug. S'il est souvent facile de comprendre un bug lorsqu'il se produit juste après un développement, il est beaucoup moins facile à interpréter lorsqu'il intervient plus tard, voire lorsqu'il intervient beaucoup plus tard chez un utilisateur qui n'est pas forcément en mesure de reproduire les étapes d'utilisation du logiciel qui l'ont amené à ce bug.

Ici, avoir des testeurs aide grandement : ils sont capables, généralement, d'isoler le bug et de trouver un chemin minimum permettant de le reproduire. Ils peuvent ensuite rédiger un rapport sur les étapes à effectuer et les résultats.

Le programmeur n'est cependant pas sorti d'affaire avec sa lecture du bug : ce qu'un testeur ou un utilisateur peut reporter est une suite d'actions et un résultat perçu. Ce résultat étant perçu (l'affichage s'arrête, le programme plante, le son se met à boucler, un pad n'est plus reconnu, un personnage du jeu se met à faire n'importe quoi, un message à l'écran est mauvais), il ne reflète pas forcément le domaine du programme dans lequel le bug est présent.

Dans un jeu vidéo, il est très possible qu'un bug de simulation mécanique soit causée par un problème dans le gestionnaire de temps qui lui même est perturbé par la gestion de la pause du jeu. Un testeur risque de relever alors : après avoir fait une pause, choisi telle option puis être revenu dans le jeu, les voitures foncent dans les murs. Le rapport de bug mentionne les voitures et la pause, mais ne mentionne pas la cause du bug, qui se trouve dans le gestionnaire du temps.

J'en viens donc au titre de cet article : l'état d'esprit.

Afin de corriger un bug efficacement, ce qui signifie préalablement dentifier sa cause, il faut avoir, ou se mettre dans, un certain état d'esprit. Je le pense fondé sur une base : l'absence de préjugé.

L'absence de préjugé

J'entends souvent à la lecture d'un bug : « ah oui, je sais d'où ça vient ! »

J'entends aussi, mais en tendant l'oreille car c'est dit sur un ton plus confidentiel : « mouais, ça doit être machin qui a archivé une bétise ! »

D'expérience, ces deux préjugés font perdre du temps. Il est possible que le programmeur ait une intuition de la provenance du bug, il est même possible que la correction soit évidente. Il est aussi possible que ce soit machin qui soit à l'origine du problème.

Mais ignorer ces préjugés est une bien meilleure réaction.

Je sais d'où ça vient !

Ce préjugé entraine une correction rapide, un archivage plein de confiance et... un autre bug. Oh, pas tout le temps ! Mais assez souvent pour que cela mérite l'attention.

S'il y a une erreur dans le programme, c'est que quelque chose s'est mal passé. Si ce quelque chose s'est mal passé, c'est que le programmeur qui a révélé le bug avec ses ajouts n'a pas été cohérent avec l'existant. Comme ce n'est pas forcément le code ajouté qui introduit le bug, mais qui le révèle, corriger ce que l'on pense être la source du bug peut avoir pour résultat de dissimuler l'erreur et non la corriger.

L'exemple classique est la ligne que l'on ajoute et qui fait planter le programme. On l'enlève, ça ne plante plus, on l'ajoute, ça plante. Le programmeur essai alors de modifier cette ligne pour avoir toujours le même effet sans le plantage (qui est souvent incompris, même pas analysé). Ça ne plante plus... jusqu'à plus tard. À vrai dire, la ligne ajoutée bougeait un peu le comportement du système, et l'erreur venait d'à côté.

Un exemple concret en C/C++ est le classique débordement de tableau stocké en variable automatique. Le débordement est inoffensif jusqu'au moment où, lors d'une modification du code source, il écrase une valeur importante. On peut modifier le code jusqu'à ce que le débordement soit à nouveau inoffensif, mais la vraie correction est celle qui corrige le débordement.

Parfois, la précipitation dans la correction du bug fait que l'on ne cerne pas bien le système et que la correction révèle un autre bug. Dans les pires cas, qui ne sont pas si rares, cela peut entraîner des révélations de bugs en cascade sur plusieurs heures, voire plusieurs jours. J'ai cette image lorsque cela arrive d'une coque de navire que l'on rafistole avec des planches et des clous, mais qui se casse à un autre endroit à cause des coups de marteaux.

Je sais qui c'est !

Cette réaction est gênante car souvent répétée, elle amène dans une équipe une méfiance entre les programmeurs (ou bien, puisque les données aussi peuvent provoquer des bugs, entre les programmeurs et les utilisateurs). Cette réaction a tendance à désigner les « mauvais programmeurs », ceux qui introduisent fatalement des bugs dans la base. Du coup, plutôt que de chercher à corriger le bug, le correcteur va d'abord chercher à savoir ce qu'à fait ce ou ces « mauvais programmeurs » (qui peuvent être différent suivant les membres de l'équipe d'ailleurs).

C'est une perte de temps !

D'abord car cela peut laisser le correcteur sur une fausse piste pendant plus longtemps que nécessaire. Et ensuite car, si effectivement l'archivage en question a révélé le bug, ce n'est peut-être, comme au paragraphe précédent, qu'un révélateur. J'ai vu plus d'une fois quelqu'un commencer sur cette voie, annoncer que tel archivage d'untel avait créé introduit le bug et se faire tout petit quelques temps après lorsque le bug est enfin trouvé... parfois dans du code du correcteur.

Le programme est une œuvre collective et lorsqu'un bug apparaît, il est inutile de savoir qui en est à l'origine. Le plus souvent, il s'agit d'une mauvaise conceptualisation du système par l'ensemble de l'équipe : certains pensent qu'il fonctionne d'une certaine façon, d'autres d'une autre façon.

Un bug doit être corrigé vite, car sa présence coûte au projet (temps de correction, mais aussi temps d'indisponibilité de la fonctionnalité). Il ne faut pas perdre du temps à savoir qui, ni même à partir sur une piste à partir d'une présomption. L'évaluation des membres de l'équipe fait partie du travail de management, pas de debug.

La piste à suivre...

Je pense que l'absence de préjugé nécessaire à un bon debug est ce qui fait qu'un débutant peut très bien être plus efficace que certains programmeurs d'expérience. Un débutant n'a pas de préjugé : ni sur le code, car il n'a pas l'historique nécessaire, ni sur les personnes, car il ne connait pas encore le fonctionnement d'une équipe. La bonne chose à faire, qui est aussi la difficulté, est de garder cette absence de préjugé tout en gagnant de l'expérience. Ce n'est pas simple et il faut parfois s'y contraindre. Mais je sais que depuis que je m'applique cette discipline, j'ai gagné en efficacité lors d'une correction de bug. Débarrassé des préjugés, je peux me concentrer sur le suivi de la piste du bug.

Suivre une piste de bug est autre sujet passionnant, mais cet article ce termine ici.

Un piège n'est qu'un piège

Sylvain Glaize — Tue, 29 Dec 2009 23:59:00 +0100

C'est chez Daz que j'ai vu en premier la présentation « Pitfalls of OOP », puis je l'ai reçue de diverses sources dans les jours qui ont suivi, je l'ai vu sur d'autres sites. Souvent, les commentaires incluaient quelque chose comme : il faut éviter la programmation orientée objet dans les jeux vidéo.

Ce commentaire à l'emporte pièce (la programmation dans le jeux vidéo couvre divers domaines avec des besoins différents) m'a immédiatement agacé pour deux raisons. Le première est que ce n'est absolument pas le sujet de la présentation, qui parle de certains pièges et de comment les éviter, la seconde est que les solutions pour éviter ces pièges peut très bien passer par de la programmation objet.

Le sujet de la présentation est tout à fait juste. Pas récent, mais comme à chaque fois que quelqu'un sort une présentation sur la gestion mémoire, une grande partie de la population des programmeurs découvre que gérer sa mémoire n'est pas simple et est extrêmement important dans les jeux vidéos (ceux qui ont besoin de performances en tout cas).

Je n'ai pas grand chose à dire sur la présentation. Elle est bien faite, je trouve les explications claires et les conclusions sont justes. À un bémol prêt (Optimize for Data first, then Code) : s'il est important de prévoir de ne pas faire n'importe quoi avec sa mémoire dès le début d'un développement, il est fort peu probable qu'une équipe ait toute l'expérience nécessaire sur console de jeu pour trouver le meilleur modèle du premier coup. Et justement, une programmation objet peut fortement aider !

C'est sur les commentaires sur la présentation que j'ai des commentaires à faire : à vrai dire, je pense qu'elle a été mal lue, ou mal comprise. Peut-être est-ce tout simplement le terme de « Data Oriented Design » qui a brouillé les pistes. En voyant ce terme, certains lecteurs se sont visiblement dit que cela remplaçait la « Programmation Orientée Objet ».

Cependant, ces deux concepts sont orthogonaux ! La « Programmation Orientée Objet » implique des paradigmes de programmation qui peuvent être utilisés de diverses manières. Et une utilisation d'une certaine manière est un design, une architecture. Le « Data Oriented Design » que je traduirais par « Architecture Orientée Données » n'est donc qu'une manière d'agencer son programme, ses objets dans le cas de la POO.

La POO n'implique pas une architecture précise, il n'y a qu'à regarder deux ou trois programmes venant de personnes ou entreprises différentes pour voir que les choix d'architectures peuvent être nombreux. Un exemple classique est celui de l'architecture de moteur de jeu à hiérarchie profonde contre celle à composant (une piste par ici).

Là où la présentation tend le bâton pour se faire battre, c'est qu'elle commence par un exemple d'architecture extrêmement simple, naïve, pour montrer l'impact négatif sur la mémoire. L'ennui étant que cette architecture naïve est très souvent utilisée, par les débutants bien sûr, mais pas qu'eux... Dans cette architecture, on utilise une encapsulation très forte : un objet a la propriété de tous ses éléments.

La suite de la présentation s'attache à comment agencer sa mémoire, mais ne donne plus d'exemple complet. C'est normal, adapter l'architecture à la POO n'est pas le sujet de la présentation.

Et cela donne le raccourci : l'exemple POO au début est mauvais, la solution de l'agencement mémoire à la fin est bonne, donc la POO est mauvaise. Pas de chance, la conclusion n'est pas la bonne, la conclusion est : donc l'agencement mémoire du début est mauvais.

Un exemple

Prenons un exemple un peu bateau pour voir comment on peut changer la façon dont des données sont stockées en mémoire tout en gardant une programmation objet.

Attention : moi, je ne parlerai pas de cache miss, je vais juste montrer sur un exemple que l'on peut changer de structure de stockage en mémoire tout en restant dans de la programmation objet.

Les exemples seront simples, pour donner une idée, l'architecture sera loin d'être aussi bien qu'elle pourrait l'être, et chaque exemple sera dans un fichier (autant pour l'architecture physique d'un projet). Chaque propos en son temps :)

L'énoncé de l'exemple est simple : j'ai une classe People qui stocke un nom, chaque instance représente donc une personne avec son nom.

Dans un système, je vais avoir plusieurs personnes (People) et je veux connaître le nombre d'utilisation pour chaque prénom.

L'exemple est très simplifiée donc, mais on a plusieurs concepts : une classe, une liste d'instance de cette classe, et une fonction de comptage.

Niveau 0 : naïf que je suis

#include <iostream>
#include <string>
#include <list>
#include <map>
 
class People
{
    public:
        People(const std::string & name) :
            name(name)
        {
        }
 
        const std::string & GetName() const
        {
            return name;
        }
 
    private:
        const std::string name;
};
 
class NameCounter
{
    public:
        NameCounter(const std::list<People *> & peopleList)
        {
            std::list<People *>::const_iterator it = peopleList.begin();
            std::list<People *>::const_iterator itEnd = peopleList.end();
 
            while (it != itEnd)
            {
                People * people = *it;
                if (count.count(people->GetName()))
                {
                    count.insert(std::pair<std::string, int>(people->GetName(), 0));
                }
                ++count[people->GetName()];
                ++it;
            }
 
        }
 
        void Print()
        {
            std::map<std::string, int>::const_iterator it = count.begin();
            std::map<std::string, int>::const_iterator itEnd = count.end();
 
            while (it != itEnd)
            {
                const std::pair<const std::string, int> & entry = *it;
 
                std::cout << "Name : " << entry.first << " with count : " << entry.second << "\n";
                ++it;
            }
        }
 
    private:
        std::map<std::string, int> count;
 
};
 
void CleanList(std::list<People *> & peopleList)
{
    std::list<People *>::const_iterator it = peopleList.begin();
    std::list<People *>::const_iterator itEnd = peopleList.end();
 
    while (it != itEnd)
    {
        delete *it;
        ++it;
    }
}
 
 
int main(int argc, const char *argv[])
{
    std::list<People * > peopleList;
 
    peopleList.push_back(new People("Pierre"));
    peopleList.push_back(new People("Paul"));
    peopleList.push_back(new People("Jean"));
    peopleList.push_back(new People("Paul"));
 
    for (int i = 0; i < 1000; ++i)
    {
        peopleList.push_back(new People("Luc"));
 
        NameCounter counter(peopleList);
        counter.Print();
    }
 
    CleanList(peopleList);
 
    return 0;
}

Dans cette première version, j'utilise une structure de données très simple pour People. Puisque chaque personne a un nom, People stocke le nom directement, il a la propriété de l'objet std::string. J'initialise ma liste (une bête std::list) avec le résultat de new (qui pourraient venir d'ailleurs). Pour le comptage, je parcours toute la liste et je stocke dans une std::map une paire (nom, occurrences).

J'affiche ensuite 1000 fois le résultat en ajoutant une personne à chaque fois, histoire de mettre un peu de dynamisme à l'exemple.

Ce niveau est globalement ce que l'on trouve le plus souvent. Du point de vu de cet article, il y a deux soucis : tout n'est pas encapsulé (new est un détail d'implémentation de la création des objets, la destruction explicite de CleanList n'a rien à faire dans main, l'utilisation de std::list ne devrait pas être visible) et les données sont dispersées en mémoire.

Encapsulons !

Première étape pour nous permettre de modifier tranquillement les structures de données sans modifier le code client : encapsuler ! Il faudrait ajouter : bien définir ses interfaces, nous nous en passerons ici, ce n'est pas le sujet.

J'ajoute donc un PeopleList qui contiendra une liste de personnes. On peut ajouter un élément à cette liste et obtenir la liste interne. Les éléments sont ajoutés via un nom, la construction de l'objet étant interne. Sur ce point, une exemple plus complet ferait probablement différemment, mais restons simple. L'obtention de la liste interne doit par contre attirer le regard : elle brise l'encapsulation en donnant accès à des détails interne.

Ce n'est pas très grave car c'est temporaire et non utilisé par le code client (ici, main).

Il faut bien entendu apporter quelques modifications à NameCounter pour recevoir une PeopleList.

À partir de maintenant, le code client ne bougera plus. Cependant, nous pourrons bouger les structures de données interne au système sans changer son fonctionnement (en fait, en l'accélérant beaucoup).

#include <iostream>
#include <string>
#include <list>
#include <map>
 
class People
{
    public:
        People(const std::string & name) :
            name(name)
        {
        }
 
        const std::string & GetName() const
        {
            return name;
        }
 
    private:
        const std::string name;
};
 
class PeopleList
{
    public:
        PeopleList()
        {
        }
 
        ~PeopleList()
        {
            CleanList();
        }
 
        void Add(const std::string & name)
        {
            peopleList.push_back(new People(name));
        }
 
        const std::list<People * > GetList() const
        {
            return peopleList;
        }
 
    private:
        std::list<People * > peopleList;
 
    private:
        void CleanList()
        {
            std::list<People *>::const_iterator it = peopleList.begin();
            std::list<People *>::const_iterator itEnd = peopleList.end();
 
            while (it != itEnd)
            {
                delete *it;
                ++it;
            }
        }
 
};
 
class NameCounter
{
    public:
        NameCounter(const PeopleList & peopleList)
        {
            const std::list<People *> internalList = peopleList.GetList();
            std::list<People *>::const_iterator it = internalList.begin();
            std::list<People *>::const_iterator itEnd = internalList.end();
 
            while (it != itEnd)
            {
                People * people = *it;
                if (count.count(people->GetName()))
                {
                    count.insert(std::pair<std::string, int>(people->GetName(), 0));
                }
                ++count[people->GetName()];
                ++it;
            }
 
        }
 
        void Print()
        {
            std::map<std::string, int>::const_iterator it = count.begin();
            std::map<std::string, int>::const_iterator itEnd = count.end();
 
            while (it != itEnd)
            {
                const std::pair<const std::string, int> & entry = *it;
 
                std::cout << "Name : " << entry.first << " with count : " << entry.second << "\n";
                ++it;
            }
        }
 
    private:
        std::map<std::string, int> count;
 
};
 
 
int main(int argc, const char *argv[])
{
    PeopleList peopleList;
 
    peopleList.Add("Pierre");
    peopleList.Add("Paul");
    peopleList.Add("Jean");
    peopleList.Add("Pierre");
 
    for (int i = 0; i < 1000; ++i)
    {
        peopleList.Add("Luc");
 
        NameCounter counter(peopleList);
        counter.Print();
    }
 
    return 0;
}

Premier mouvement

Dans le premier design, People avait la propriété du nom. L'énoncé de l'exemple donnait un indice sur le fait que cela n'était pas la meilleure idée : il va y avoir des doublons !

Ainsi, dans les programmes précédents, il y a 1000 fois une chaîne "Luc" en mémoire, alors même que le champ name de People est constant (People est une classe non mutable : une fois qu'elle est créée, ses valeurs ne changent pas).

Plutôt que de stocker un nom dans chaque instance de People, je crée donc un dictionnaire de nom dont PeopleList a une instance. Lors de la création d'une instance de People, le nom est tout d'abord ajouté au dictionnaire s'il n'est pas déjà présent, puis l'instance de People est créée avec pour nom une référence vers l'entrée du dictionnaire.

On y gagne en place utilisée (un peu plus de 80ko pour la version précédente pour environ 64ko maintenant). Forcément, plus un même prénom est utilisé, plus cette structure est rentable.

Mais elle est de toute façon flexible, la seule contrainte est que le stockage des noms dans le dictionnaire soit stable. Comme People a une référence vers une entrée de dictionnaire, cette entrée ne doit pas changer en mémoire. C'est pour cette raison que dans cette implémentation, j'utilise une std::list. Si le nombre de prénom maximum était connu, un tableau ferait l'affaire. Évidemment, d'un point de vue cache, le std::list n'est pas un très bon choix. Mais comme le dictionnaire n'expose pas ses détails d'implémentation, ceux-ci pourraient être modifiés pour une meilleure disposition en mémoire sans rien changer au reste du programme.

À partir de maintenant, la classe People ne bougera plus. On notera que l'on peut toujours l'utiliser comme un objet normal. Simplement, ses données étant encapsulées, le client n'a pas à se soucier de leur stockage. À noter d'ailleurs que mis à part un changement de nom pour le paramètre du constructeur, l'interface de People n'a pas changé. Du code client écrit utilisant People n'aurait pas à être réécrit alors que, en-dessous, nous avons remanié grandement le stockage de ses données !

#include <iostream>
#include <string>
#include <list>
#include <map>
#include <algorithm>
 
class People
{
    public:
        People(const std::string & nameInDictionary) :
            name(nameInDictionary)
        {
        }
 
        const std::string & GetName() const
        {
            return name;
        }
 
    private:
        const std::string & name;
};
 
class NameDictionary
{
    public:
        NameDictionary()
        {
        }
 
        const std::string & SetAndGetName(const std::string & name)
        {
            std::list<std::string>::iterator found = std::find(allNames.begin(), allNames.end(), name);
            if (found == allNames.end())
            {
                allNames.push_back(name);
                found = std::find(allNames.begin(), allNames.end(), name);
            }
 
            return *found;
        }
 
    private:
        std::list<std::string> allNames;
 
};
 
class PeopleList
{
    public:
        PeopleList()
        {
        }
 
        ~PeopleList()
        {
            CleanList();
        }
 
        void Add(const std::string & name)
        {
            const std::string & nameInDictionary = dictionary.SetAndGetName(name);
            peopleList.push_back(new People(nameInDictionary));
        }
 
        const std::list<People * > GetList() const
        {
            return peopleList;
        }
 
    private:
        NameDictionary dictionary;
        std::list<People * > peopleList;
 
    private:
        void CleanList()
        {
            std::list<People *>::const_iterator it = peopleList.begin();
            std::list<People *>::const_iterator itEnd = peopleList.end();
 
            while (it != itEnd)
            {
                delete *it;
                ++it;
            }
        }
 
};
 
class NameCounter
{
    public:
        NameCounter(const PeopleList & peopleList)
        {
            const std::list<People *> internalList = peopleList.GetList();
            std::list<People *>::const_iterator it = internalList.begin();
            std::list<People *>::const_iterator itEnd = internalList.end();
 
            while (it != itEnd)
            {
                People * people = *it;
                if (count.count(people->GetName()))
                {
                    count.insert(std::pair<std::string, int>(people->GetName(), 0));
                }
                ++count[people->GetName()];
                ++it;
            }
 
        }
 
        void Print()
        {
            std::map<std::string, int>::const_iterator it = count.begin();
            std::map<std::string, int>::const_iterator itEnd = count.end();
 
            while (it != itEnd)
            {
                const std::pair<const std::string, int> & entry = *it;
 
                std::cout << "Name : " << entry.first << " with count : " << entry.second << "\n";
                ++it;
            }
        }
 
    private:
        std::map<std::string, int> count;
 
};
 
 
int main(int argc, const char *argv[])
{
    PeopleList peopleList;
 
    peopleList.Add("Pierre");
    peopleList.Add("Paul");
    peopleList.Add("Jean");
    peopleList.Add("Pierre");
 
    for (int i = 0; i < 1000; ++i)
    {
        peopleList.Add("Luc");
 
        NameCounter counter(peopleList);
        counter.Print();
    }
 
    return 0;
}

Changeons les calculs

Dans cette nouvelle étape, je m'attaque au NameCounter. Celui-ci a en effet un gros problème : à chaque fois que l'on veut obtenir le nombre d'occurrences de chaque prénom, l'objet refait les calculs et en profite pour allouer une structure gourmande en mémoire (le std::map). L'avantage est que cette mémoire n'est utilisée que lors du besoin de comptage. L'inconvénient est que cela prend vraiment beaucoup de mémoire et de temps.

L'idée est donc de garder la statistique qui nous intéresse quelque part et de la calculer au fur et à mesure de l'ajout de personnes à l'instance de PeopleList. C'est facile, car il n'y a qu'un seul moyen d'ajouter des personnes. Défense cependant d'ajouter le comptage directement à PeopleList, je vais utiliser un objet spécialisé dans ce comptage.

Il y a un autre choix à faire : est-ce que le nombre d'occurrence est à stocker dans le dictionnaire de noms ou pas. Je choisi que non. Au final, la mémoire utilisée sera légèrement plus importante, mais on conserve une flexibilité intéressante : pas besoin de changer le dictionnaire lorsque l'on ne veut pas compter les occurrences.

La classe ajoutée est NameUsageCounter. À chaque ajout de personne à la liste, on lui signal le prénom utilisé. L'objet enregistre une référence vers le dictionnaire et augmente une compteur.

L'usage de cette classe permet de se passer du GetList() de PeopleList qui cassait l'encapsulation en le remplaçant par GetCounter(). On pourra objecter que l'on expose toujours des détails internes. Dans une certaine mesure, oui, et on pourrait pousser le design pour éviter cela, mais il faut mettre une limite à cet article.

NameCounter profite grandement de NameUsageCounter et se contente d'aller y piocher les informations à afficher.

C'est beaucoup plus rapide, et ça prend beaucoup moins de place (un peak de moins de 40ko).

NameUsageCounter utiliser un std::vector en interne. Là encore, ce n'est pas une structure bien stable en mémoire, même si pour le faible nombre de prénoms de mon exemple, cela a peu d'influence. Connaître le nombre maximum de prénom permettrait une structure plus fixe et plus gentille avec les accès mémoire.

#include <iostream>
#include <string>
#include <list>
#include <map>
#include <vector>
#include <algorithm>
 
class People
{
    public:
        People(const std::string & nameInDictionary) :
            name(nameInDictionary)
        {
        }
 
        const std::string & GetName() const
        {
            return name;
        }
 
    private:
        const std::string & name;
};
 
class NameDictionary
{
    public:
        NameDictionary()
        {
        }
 
        const std::string & SetAndGetName(const std::string & name)
        {
            std::list<std::string>::iterator found = std::find(allNames.begin(), allNames.end(), name);
            if (found == allNames.end())
            {
                allNames.push_back(name);
                found = std::find(allNames.begin(), allNames.end(), name);
            }
 
            return *found;
        }
 
    private:
        std::list<std::string> allNames;
};
 
class NameUsageCounter
{
    public:
        struct Entry
        {
            Entry(const std::string & nameForEntry) :
                name(&nameForEntry),
                count(0)
            {
            }
 
            const std::string * name;
            int count;
        };
 
        typedef std::vector<Entry> EntryCollection;
 
    public:
        NameUsageCounter()
        {
        }
 
        void AddUsage(const std::string & name)
        {
            int * counter = FindCounter(name);
            if (!counter)
            {
                counter = CreateCounter(name);
            }
 
            ++(*counter);
        }
 
        const std::vector<Entry> & GetEntries() const
        {
            return counters;
        }
 
    private:
        EntryCollection counters;
 
    private:
        int * FindCounter(const std::string & name)
        {
            int counterCount = counters.size();
            for (int index = 0; index < counterCount; ++index)
            {
                if (counters[index].name == &name)
                {
                    return &counters[index].count;
                }
 
            }
            return NULL;
        }
 
        int * CreateCounter(const std::string & name)
        {
            counters.push_back(Entry(name));
            return &(counters.back().count);
        }
};
 
std::ostream & operator << (std::ostream & out, const NameUsageCounter::Entry & entry)
{
    out << "Name : " << *entry.name << " with count : " << entry.count << "\n";
    return out;
}
 
 
class PeopleList
{
    public:
        PeopleList()
        {
        }
 
        ~PeopleList()
        {
            CleanList();
        }
 
        void Add(const std::string & name)
        {
            const std::string & nameInDictionary = dictionary.SetAndGetName(name);
            peopleList.push_back(new People(nameInDictionary));
 
            counter.AddUsage(nameInDictionary);
        }
 
        const NameUsageCounter & GetCounter() const
        {
            return counter;
        }
 
    private:
        NameDictionary dictionary;
        NameUsageCounter counter;
 
        std::list<People * > peopleList;
 
    private:
        void CleanList()
        {
            std::list<People *>::const_iterator it = peopleList.begin();
            std::list<People *>::const_iterator itEnd = peopleList.end();
 
            while (it != itEnd)
            {
                delete *it;
                ++it;
            }
        }
 
};
 
class NameCounter
{
    public:
        NameCounter(const PeopleList & peopleList) :
            counter(peopleList.GetCounter())
        {
        }
 
        void Print()
        {
            NameUsageCounter::EntryCollection::const_iterator it = counter.GetEntries().begin();
            NameUsageCounter::EntryCollection::const_iterator itEnd = counter.GetEntries().end();
 
            while (it != itEnd)
            {
                std::cout << *it;
                ++it;
            }
        }
 
    private:
        const NameUsageCounter & counter;
 
};
 
 
int main(int argc, const char *argv[])
{
    PeopleList peopleList;
 
    peopleList.Add("Pierre");
    peopleList.Add("Paul");
    peopleList.Add("Jean");
    peopleList.Add("Pierre");
 
    for (int i = 0; i < 1000; ++i)
    {
        peopleList.Add("Luc");
 
        NameCounter counter(peopleList);
        counter.Print();
    }
 
    return 0;
}

Une dernière modification mémoire

Le programme est donc bien « orienté objet », il y a même plus de classes qu'au début, avec une encapsulation correcte sans être académiquement parfaite.

Je donne un dernier petit exemple de modification de structure de données pour montrer à quel point l'architecture orientée données est orthogonale, et même facilitée, par une programmation objet.

Imaginons que lors de notre profiling, nous découvrions que l'indirection dans NameUsageCounter::Entry pour afficher le nom soit coûteuse (le programme n'est pas assez complexe et la plupart des performances sont de toute façons impactées par l'utilisation de std::string et de std::ostream...). Nous aimerions avoir dans Entry une copie de la donnée prénom.

Voyons comme les modifications sont minimes. Une taille maximum de chaine est nécessaire pour que Entry puisse être accédée directement. Entry gagne un tableau de caractères local. NameUsageEntry gagne un std::vector de références vers les entrées du dictionnaire nécessaire à FindCounter().

Et voilà, Entry est prête pour des traitements de longs tableaux contigus en mémoire. Seul du code de NameUsageCounter (et l'operator << associé) a du être modifié.

#include <iostream>
#include <string>
#include <cstring>
#include <list>
#include <map>
#include <vector>
#include <algorithm>
 
class People
{
    public:
        People(const std::string & nameInDictionary) :
            name(nameInDictionary)
        {
        }
 
        const std::string & GetName() const
        {
            return name;
        }
 
    private:
        const std::string & name;
};
 
class NameDictionary
{
    public:
        NameDictionary()
        {
        }
 
        const std::string & SetAndGetName(const std::string & name)
        {
            std::list<std::string>::iterator found = std::find(allNames.begin(), allNames.end(), name);
            if (found == allNames.end())
            {
                allNames.push_back(name);
                found = std::find(allNames.begin(), allNames.end(), name);
            }
 
            return *found;
        }
 
    private:
        std::list<std::string> allNames;
};
 
const int MAX_NAME_SIZE = 7;
 
class NameUsageCounter
{
    public:
        struct Entry
        {
            Entry(const std::string & nameForEntry) :
                count(0)
            {
                std::strncpy(localName, nameForEntry.c_str(), MAX_NAME_SIZE);
                localName[MAX_NAME_SIZE] = '\0';
            }
 
            char localName[MAX_NAME_SIZE+1];
            int count;
        };
 
        typedef std::vector<Entry> EntryCollection;
 
    public:
        NameUsageCounter()
        {
        }
 
        void AddUsage(const std::string & name)
        {
            int * counter = FindCounter(name);
            if (!counter)
            {
                counter = CreateCounter(name);
            }
 
            ++(*counter);
        }
 
        const std::vector<Entry> & GetEntries() const
        {
            return counters;
        }
 
    private:
        EntryCollection counters;
 
        std::vector<const std::string * > names;
 
    private:
        int * FindCounter(const std::string & name)
        {
            int counterCount = counters.size();
            for (int index = 0; index < counterCount; ++index)
            {
                if (names[index] == &name)
                {
                    return &counters[index].count;
                }
 
            }
            return NULL;
        }
 
        int * CreateCounter(const std::string & name)
        {
            counters.push_back(Entry(name));
            names.push_back(&name);
            return &(counters.back().count);
        }
};
 
std::ostream & operator << (std::ostream & out, const NameUsageCounter::Entry & entry)
{
    out << "Name : " << entry.localName << " with count : " << entry.count << "\n";
    return out;
}
 
 
class PeopleList
{
    public:
        PeopleList()
        {
        }
 
        ~PeopleList()
        {
            CleanList();
        }
 
        void Add(const std::string & name)
        {
            const std::string & nameInDictionary = dictionary.SetAndGetName(name);
            peopleList.push_back(new People(nameInDictionary));
 
            counter.AddUsage(nameInDictionary);
        }
 
        const NameUsageCounter & GetCounter() const
        {
            return counter;
        }
 
    private:
        NameDictionary dictionary;
        NameUsageCounter counter;
 
        std::list<People * > peopleList;
 
    private:
        void CleanList()
        {
            std::list<People *>::const_iterator it = peopleList.begin();
            std::list<People *>::const_iterator itEnd = peopleList.end();
 
            while (it != itEnd)
            {
                delete *it;
                ++it;
            }
        }
 
};
 
class NameCounter
{
    public:
        NameCounter(const PeopleList & peopleList) :
            counter(peopleList.GetCounter())
        {
        }
 
        void Print()
        {
            NameUsageCounter::EntryCollection::const_iterator it = counter.GetEntries().begin();
            NameUsageCounter::EntryCollection::const_iterator itEnd = counter.GetEntries().end();
 
            while (it != itEnd)
            {
                std::cout << *it;
                ++it;
            }
        }
 
    private:
        const NameUsageCounter & counter;
 
};
 
 
int main(int argc, const char *argv[])
{
    PeopleList peopleList;
 
    peopleList.Add("Pierre");
    peopleList.Add("Paul");
    peopleList.Add("Jean");
    peopleList.Add("Pierre");
 
    for (int i = 0; i < 1000; ++i)
    {
        peopleList.Add("Luc");
 
        NameCounter counter(peopleList);
        counter.Print();
    }
 
    return 0;
}

Et donc ?

J'espère avoir montré, malheureusement sur un petit exemple seulement, que la programmation orientée objet et l'architecture orientée données ne se marchent pas sur les pieds, mais concourent ensemble pour le meilleur.

Je n'ai pas traité le cas de classes virtuelles, cela m'aurait pris quelques heures de plus pour finalement pas grand chose : vous avez du comprendre que l'on pourrait avoir plusieurs types de People virtuels qui pourraient être utilisés comme tels, tout en utilisant des structures de données internes calibrées pour les traitements nécessaires au programme.

Oui, il y a des pièges à la POO. Tout outil mal utilisé peut présenter des pièges.

La présentation dont il est question initialement montre comment éviter l'un des pièges, mais il ne montre pas qu'il faut murer l'entrée amenant à ce piège.

Gamecamp Paris #1

Sylvain Glaize — Tue, 15 Dec 2009 08:00:00 +0100

Samedi 5 décembre 2009 a eu lieu le premier Gamecamp à Paris. Il s'agissait d'un Barcamp ayant pour thème la création de jeux vidéo.

L'idée avait commencé à germer dans des commentaires de blogs et twitter. Cela faisait quelques temps que Whirly parlait du format Barcamp et du fait que cela n'avait pas été fait en France sur le thème de la création de jeux vidéo.

Quelques personnes, dont Daz et Pedro ont pris le sujet à bras le corps et, d'un coup (2 semaines !), tout a pris forme : le (ou la ?) Gamecamp Paris avait pris forme. Date, lieu, organisation, t-shirts,...

Pas évident de dégager tout à coup un samedi aussi rapidement pour moi, et je remercie ma femme d'avoir pris sur elle pour que je puisse me rendre à cet évènement.

Arrivée

À 9h10, j'arrive chez PlayAll, qui prête ses locaux gracieusement. Il n'y a pas encore grand monde, mais ça arrive a un rythme soutenu. Tout le monde discute en attendant le démarrage des sessions.

Puis, à 9h30, Daz et Whirly font un petit discours de bienvenu et d'introduction du principe de la journée. Dans un Barcamp, il n'y a pas de programme, il y a un grand tableau croisé entre salles disponibles et horaires (une heure par session) et, sur la même base que le fait d'être venu, la volonté, chacun peut remplir une case avec un thème. À l'heure dite, il se rend alors dans la bonne salle et voit qui vient.

Cela a tendance à gêner les habitués de la sur-planification, de même que le format d'une heure semble gêner les bavards.

Pour la planification : on est ici dans l'« agile », beau buzzword qui sert surtout à décrire un fonctionnement où l'on s'adapte au fil de l'eau. Pas besoin de programme : les gens qui sont venus, un samedi, hors boulot, sont a priori des gens qui ont envie de faire quelque chose de cette journée. Ils ne sont pas là en touriste. On peut donc leur faire confiance.

Sur le second point : une heure, c'est très bien. S'il reste des choses à dire, des sujets annexes qui sont apparus, pas de soucis, il suffit de noter un nouveau créneau sur le tableau. Il faut cependant veiller à garder le cap de la discussion pendant l'heure qui lui est consacrée.

Un autre point qui a été soulevé est celui du mélange des métiers : je trouve au contraire que c'est une bonne chose si le sujet s'y prête. Pour filtrer un métier, ce n'est pas compliqué, il suffit d'intituler une session de manière précise. Lorsque j'ai proposé le thème un peu technique des bases de code décentralisé (voire plus loin) j'étais à peu près certain de n'y retrouver que des métiers techniques.

J'attends de voir deux premiers thèmes inscrits, je jette un coup d'œil à mes notes, et j'inscris à mon tour deux thèmes en faisant attention que cela ne chevauche pas un thème qui m'intéresse.

Puis à 10h, débute la première session.

1. Méthodes agiles

Un sujet assez vaste et qui draine pas mal de monde. Dans le groupe, il y a des gens qui ne connaissent pas et sont venus pour découvrir, un petit rappel de quelques principes de méthodes agiles est donc fait.

Une méthode agile est un ensemble de processus pour une gestion de projet qui puisse réagir rapidement aux changements ; c'est un ensemble d'outils pour une planification flexible et les métriques qui vont avec.

Expérience de Creative Patterns

Whirly (patron de Creative Patterns) expose brièvement sa mise en place de méthodes agiles, d'abord avec XP (eXtreme Programming) en 2001 puis Scrum (ces deux méthodes ne s'occupent pas exactement des mêmes choses et leurs principes sont compatibles).

Les discussions vont ensuite flotter, mais Whirly va régulièrement donner des retours d'expérience tout au long de la session. Je regroupe le tout :

Creative Patterns utilise Scrum avec le designer en tant que client des programmeurs.
Pour les estimations, ils utilisent un story point en tant qu'une heure de Perfect Engineering (une heure consacrée entièrement à la tâche, sans interruption et avec toutes les ressources nécessaires disponibles : une heure idéale).
Après un suivi avec des cartons sur un tableau, l'équipe utilise Trac pour la gestion des stories.
Au début, ils testaient absolument tout, jusqu'à des tests d'interface utilisateurs. Maintenant, ils implémentent les tests "gratuits" (ceux qui ne demandent pas d'effort particulier et sont faits en parallèle du développement). Pour les tests plus complexe, une évaluation de l'intérêt du test par rapport à sa complexité et surtout, sa future maintenance, est faite avant de l'implémenter.

Comme il y avait beaucoup de monde, que prendre la parole était assez difficile lors de cette session et que mon argument n'aurait pas avancé à grand chose sur place, je l'ajoute ici : j'ai le même constat à propos des tests. Globalement, plus on s'enfonce dans les couches basses dans du code qui ne va pas changer, plus il est intéressant de faire du test. Plus on monte vers du code gameplay sensible aux modifications design, moins il est intéressant de faire du test automatique.

Il donne aussi des conseils sur l'application de méthodes agiles lorsque d'autres intervenants avec des expériences malheureuses les rapportent :

il est important que l'équipe de production soit protégée de l'éditeur/client. Cela fait partie de la conduite d'un projet que de filtrer les demandes externes.

Note personnelle : je suis absolument d'accord, mais je précise qu'il ne faut pas traduire "filtrage" par "mentir à l'équipe". Certains chefs de projet font cette erreur.

lors d'une réunion hebdomadaire de suivi de projet, la première question posée à chaque membre de l'équipe est : "comment te sens-tu ?" Pendant la réponse, il n'est permit aucune interruption de parole et aucun jugement ne doit être porté sur la réponse. Après des premières semaines méfiantes où personne ne va oser se lancer, cette question devient une soupape de sécurité qui aide à faire remonter les problèmes le plus rapidement possible.
mettre en place une méthode agile ne s'impose pas. C'est une méthode qui doit venir de l'équipe, qui pourra avoir besoin d'un temps d'adaptation. Pour cela, le mieux est d'avoir dans l'équipe au moins une personne (et éventuellement un noyau) à l'aise avec ces concepts. Le changement se fait alors par contamination, naturellement, lorsque les réfractaires se rendent compte des bénéfices qu'ils gagnent avec ces méthodes.
il conseille aussi de segmenter l'équipe complète en cellules entre lesquels ont détermine des point de communication. Ces points de communication sont des membres d'équipe qui s'assurent que l'information passe ; cela ne signifie donc pas que toute information ou demande doit passer par eux.

Ces conseils se retrouvent généralement sous une forme ou une autre dans les livres ou articles à propos des méthodes agiles. Avoir quelqu'un qui raconte son expérience en face (ou presque) de soi est cependant un plus car il peut réagir aux mésaventures de ceux qui ont vécu de mauvaises expériences dans ce domaine.

Autres expériences

Des intervenants, la plupart des autres rapportaient de mauvaises expériences avec les méthodes agiles. Ou plus précisément avec Scrum. Ils étaient tous du même studio et s'étaient vu imposer Scrum par leur éditeur... sans mode d'emploi.

Vu l'ampleur du changement, l'absence de compétence Scrum dans les équipes, la rigidité du fonctionnement qui transparaissait des témoignages et la taille des équipes de Scrum (jusqu'à 35 !), l'échec était assuré.

Des exemples d'interventions directes du client/éditeur dans l'équipe ont été aussi rapportées.

Pour un employé d'un autre studio, Scrum était vu dans son environnement pour quelque chose de trop raffiné.

Ma conclusion

Beaucoup de monde à cette session a empêché d'approfondir les choses. La majorité avait eu une mauvaise expérience avec Scrum. J'espère que cela ne les a pas empêcher d'écouter les très bonnes pistes de Whirly. Du fait du dialogue qui s'est instauré entre ces deux expériences, pratiquement aucune place n'a été laissé au reste.

Cependant, la session a ouvert une autre session sur Scrum en particulier. Je ne l'ai pas suivie, mais d'après les retours que j'ai vu, il s'agissait d'expliquer un peu Scrum.

C'est un avantage du fonctionnement par sessions d'une heure : pour l'approfondissement d'un sujet, il suffit de proposer une nouvelle session sur le projet.

2. Perforce vs. Git

C'est une session que j'ai proposée, avec en sous-titre : intérêt et mise en œuvre des bases décentralisées. Comme on peut le voir sur la photo du whiteboard, j'ai ajouté SVN sous Perforce et Bzr sous Git ; c'était suite à des commentaires derrière moi lorsque j'écrivais le sujet.

Une erreur : mieux vaut un titre clair. La session s'auto-régule par la suite.

Un sujet un peu plus technique donc, à laquelle je ne m'attendais pas à voir grand monde... mais peut-être un peu plus quand même. Nous avons commencé à 3 et terminé à 5. L'avantage étant qu'avec ce format là, nous avons pu creuser un peu plus en profondeur.

J'ouvre la session. Nous sommes deux à avoir utilisé Git ou un autre système décentralisé. On discute donc un peu de l'intérêt d'une solution ou d'une autre. L'accord est vite trouvé : Git intéresse surtout les programmeurs, qui y gagnent en flexibilité de contrôle de révisions (branches gratuites, pas de blocage en cas de fermeture temporaire de base en vue de milestone, possibilité de travailler sur la même fichier dans deux « changelist » différentes,...).

Il y a aussi consensus sur le fait qu'à moins d'outils pour cacher le fonctionnement, imposer Git à d'autres corps de métier n'est pas une bonne chose. De plus, ces autres métiers ont très souvent besoin de locker des fichiers binaires sur la base, ce que ne permet pas Git seul.

Des essais ont été fait. On évoque une base de 17 Go a un historique de près de 230 Go. Git stockant l'historique sur chaque poste, cela peut poser des problèmes de place disque. Surtout si l'on travaille sur plusieurs projets. Chez un studio qui fait du jeu pour téléphone, les volumes sont de l'ordre de cent fois plus petit. Pour ces volumes, une solution Git complète (en gardant à l'esprit les commentaires sur les utilisateurs non programmeurs) peut être envisageable.

Sam propose alors une piste qu'il creuse lui-même en ce moment, à base d'un mélange de Perforce comme base centrale et de Git pour les programmeurs qui le veulent. Il utilise pour cela git-p4, qui permet de migrer les historiques entre les deux systèmes. Grâce à un jeu de Workspace (pour perforce), les données restent gérées par Perforce et seules les sources sont gérées par Git.

Il mentionne aussi une version patchée de Git de son cru, git-bigfiles, qui a de meilleures performances sur les gros fichiers (voir son site).

La solution de Sam me plait. Je pense creuser dans cette direction dès que j'en ai le temps.

Autres choses notées à cette session :

une remarque de Daz, qui était à cette session : on a des process de plus en plus long dans le jeu vidéo et il faut trouver les bon outils qui peuvent nous aider. Question base, à peu près tous les studios se greffent sur une solution Perforce ou Subversion, sans se poser trop de questions.

d'un point de vue stockage, Nicolas L. fait remarquer que stocker des formats compressé n'est pas efficace avec Subversion (et probablement les autres). Les révisions étant stockées sous forme de diff compressés, cela fonctionne mieux sur des formats de fichier où une petite modification entraine un petit changement dans le fichier. Ce n'est pas le cas des fichiers déjà compressés.

Pause déjeuner

C'est aussi un moment de discussion.

3. Outils libres dans la production

C'est le second thème que j'ai proposé. Une dizaine de personnes autour de la table, le plus gros des troupes étant parti sur les sessions sur Unreal et le piratage sur mobiles.

Rapidement, on sépare deux grandes utilisations du libres : bibliothèques intégrées à un jeu et outils utilisés de production.

Un des premiers soucis de l'utilisation du libre dans une entreprise est la mauvaise connaissance de leurs licences par les départements légaux. Il y a souvent de la méfiance et une réaction qui consiste à refuser l'utilisation du libre car il n'est pas compris. Certaines entreprises n'aiment pas non plus n'avoir personne contre qui se retourner en cas de problème.

À cela, les intervenants de la session partagent sur des pistes :

communiquer sur les licences, les expliquer. Il faut aussi les expliquer aux employés pour éviter de retrouver du code GPL dans un jeu au code propriétaire par exemple. Lever la confusion entre libre et gratuit.
montrer qu'avoir un éditeur contre qui se retourner n'est pas une garantie car 1/ des données perdues sont perdues, faire un procès n'arrange pas grand chose 2/ l'éditeur se retranchera à coup sûr derrière une mauvaise utilisation du produit par l'utilisateur 3/ l'éditeur peut tout simplement disparaitre, laissant l'utilisateur avec un produit non soutenu et un coût de migration obligatoire vers une autre solution.

Pour ce dernier exemple, autour de la table, nombreux sont ceux à avoir connu l'épisode du rachat de RenderWare par EA. C'est un bon exemple à montrer à quelqu'un qui voit dans l'existence d'un éditeur une garantie forte.

Les intervenants sont aussi d'accord sur un point : il faut être pragmatique. Si un outil correspond à un besoin, libre ou propriétaire n'est qu'une des variables permettant de choisir son utilisation ou non.

D'après Whirly, il manque au secteur une vraie success story autour du libre, une entreprise qui communique sur le gain que lui a apporté le libre.

Suivent les notes que j'ai pu prendre sur divers points, sans trop de mise en forme :

la publication des modifications : c'est une évidence pour quiconque a une sensibilité au logiciel libre, ça ne l'est pas forcément pour une entreprise qui n'utilise pas.
le management confond souvent libre et gratuit. Une solution à base de logiciel libre ne doit surtout pas être présentée comme gratuite, ce qui est de toute façon faux.
le coût du logiciel libre correspond en gros à la ressource qu'il faudra allouer localement à la maîtrise du produit, aux temps de merge du code, à la maintenance,...
ce coût n'est pas inexistant pour du logiciel propriétaire : ce n'est pas parce qu'il y a du support que tout est gratuit pour une équipe. Autour de la table, tout le monde est bien conscient que pour une solution propriétaire, il faut aussi une ressource locale allouée pour la maîtrise du produit, du temps pour le merge, de la maintenance,...
ces coûts doivent être intégrés à la méthode de développement. Par exemple, un coût en story points pour une méthode agile.
le libre présente un avantage d'indépendance par rapport à une entreprise tierce (qui peut-être rachetée par un concurrent ou déposer le bilan).
des pistes pour présenter l'intérêt d'une entreprise à contribuer au code libre : il y a un intérêt à ce que plusieurs personnes réussissent au même endroit, c'est une sphère de prospérité ; tout le monde gagne à ne pas perdre du temps sur des outils dont tout le monde à besoin.
il y a beaucoup d'outils de base (voire d'outils "jouets") dans le libre concernant le jeu vidéo. Il manque au-dessus de ces projets des outils plus avancés. C'est là que devrait se concentrer l'effort d'entreprises intéressées par le libre, plutôt que sur une énième version d'outil déjà existant.
il y a peu de temps, le middleware propriétaire était mal vu des entreprises, son utilisation et les bénéfices que cela apporte est à présent un fait bien intégré. Ce n'est pas encore le cas pour le libre.
un soucis qui est relevé par le management est parfois de se dire que si on revend le produit contenant des modifications à des licences forçant la redistribution, du code confidentiel risque d'être rendu public. Cette question est tout à fait hypothétique. Autour de la table, personne n'a vu le cas se présenter. De plus, toutes les licences ne forcent pas la divulgation de l'intégralité du code attaché. On rejoint là l'un des premiers points : former au libre.

Ma conclusion

Comment conclure sur ce sujet ? Je ne m'y risquerai pas. Je peux conclure sur la session : une bonne session qui a montré une véritable envie de partager, au moins sur des points qui font perdre du temps aux productions. Nous avons tous des exemples d'outils ou des parties d'un moteur refait sur plusieurs projets différents de la même façon.

Éduquer sur le sujet du libre sera un véritable gain pour les entreprises de jeu vidéo.

4. Partager les modifications custom aux moteurs et middleware

Une sorte de suite logique à la précédente question, proposée par Sam. Beaucoup de participants pendant cette heure étaient sur la session "Prototypage" juste à côté.

Le constat de base de cette session est un de ceux faits lors de la sessions précédentes : beaucoup de studios font les mêmes modifications, les même bugs fixs, aux mêmes moteurs et middleware. Cependant, ces modifications ne sont pas partagées, même dans les rares cas où le fournisseur du produit offre un espace de partage ou encourage aux retours pour intégration dans leur produit.

Les participants à la session étant déçu de ce fait et certains acteurs dans le logiciel libre, nous avons essayé de comprendre pourquoi ce qui fonctionne bien dans le libre ne fonctionne pas dans ce cas.

Voici quelques pistes :

Volonté de garder les ressources pour soi : les studios passent du temps à corriger des produits qui ne sont pas à eux. L'intérêt immédiat est de pouvoir avancer dans sa production. Étant donné que l'on paye déjà pour le produit, donner le résultat des corrections est souvent vu comme un cadeau au fournisseur, sans intérêt.
Manque de ressources à allouer à la gestion et communication sur le sujet : remonter des patchs au fournisseur est un travail complexe car ces produits sont généralement lourds dans leur processus. De plus, les branches locales des productions peuvent avoir beaucoup divergées et la production du patch en est aussi lourde (il faut le rendre publiable, exempt de code confidentiel, ce qui n'est pas toujours évident suivant la qualité du produit).

Cependant, un avantage évident à partager son code est à noter : remonter un patch et le voir intégrer dans la version officielle du produit, c'est s'éviter un coût de merge lors de l'intégration d'une nouvelle version du produit. Ainsi, on paye une fois pour la production du patch, mais on ne paye plus à chaque intégration. Cela peut être très avantageux.

Un autre obstacle au partage de modification à du middleware ou moteur est tout simplement le fournisseur : il peut ne pas avoir mis en place un processus facile de remontée de patch, il peut n'avoir pas envie de voir ses clients communiquer, il peut y avoir quelques obstacles contractuels sur la propriété du code,...

Ma conclusion

Cette session est vite arrivée à une conclusion : le partage de code dans du middleware propriétaire, pour être efficace, doit être encouragé et facilité par le fournisseur. Contrairement à un logiciel libre ou les différents clients/contributeurs sont libres (!) de ce qu'ils font, le code propriétaire nécessite que le fournisseur joue le jeu. En sachant qu'il y gagnera aussi.

5. Bosser sur des projets persos, chez soi

Au début de cette session, nous étions moins d'une dizaine. Personne ne semblait avoir lancé l'idée de la session, c'est donc Christophe de DK-Games qui se charge d'animer et l'on commence un tour de table.

Et tout à coup, il semble que la moitié des participants à l'évènement vient nous rejoindre, sans trop de considération pour le fait que la session a déjà commencé. Petit bémol sur ce coup-là. Le début des sessions a lentement glissé le long de la journée, mais essayer d'arriver au début de la session et se faire discret lorsqu'on est en retard me semble une bonne chose.

Du coup, le périmètre de la discussion a sensiblement varié. D'un départ a peu de personnes où nous allions parler de nos expériences précises, nous passons à beaucoup de personnes avec beaucoup de vues différentes. Comme je le disais au début, ce n'est pas forcément un mal, cela permet de donner des pistes sur des réflexions ultérieures plus précises.

Motivations

En début de la session, les participants essaient de savoir pourquoi il y a ce besoin d'avoir des projets personnels. Ce qui en ressort est que pour la plupart, il s'agit de faire quelque chose d'autre que ce que l'on fait au boulot, le plus souvent sans finalité de vente. Les projets avec finalité de transformation en projet professionnel sont minoritaires.

'J'ajoute un cas, non évoqué pendant la session : celui de la formation personnelle continue, sans finalité de produit fini.'

Au niveau des moyens, tout le monde autour de la table connait les outils dont il a besoin, ou presque. Ceux qui ont des projets de game design utilisent des plateforme (moteurs ou mod), ceux qui font de la programmation utilisent du middleware,...

Motivation et temps

Reste le principal problème : le temps à y consacrer et la motivation que l'on a.

'On se rend compte sur cette partie que les professionnels chez eux ont strictement les mêmes problématiques que les amateurs. La différence se situe essentiellement dans la conscience de ces problèmes.'

Question motivation, tout le monde est d'accord : il est très difficile de la garder sur le long terme. Six ou sept mois en continu sur un projet semble être une limite pour la majorité. Les moyens de conserver sa motivation varient cependant beaucoup d'une personne à l'autre.

Certains préfèrent avoir plusieurs projets de front pour pouvoir changer de projet et revenir plus tard. L'avantage est de ne pas abandonner ses idées, l'inconvénient est que cela rallonge la durée d'un projet au point d'en être dégouté, une sorte de perte de motivation de second niveau.

Une autre manière de garder sa motivation est de viser un projet de taille raisonnable. Raisonnable s'entend en fonction de ses capacités mais aussi et surtout du temps que l'on peut consacrer au projet chez soi. Éventuellement, un projet de plus longue haleine peut être découpé en tâches modestes avec à la fin de chaque tâche, un produit fini. Une sorte de "Scrum personnel". Pour aider dans cette méthode, utilisée par quelques participants, il est noté qu'un bug tracker, gestionnaire de tickets ou tout simplement un fichier de tâches est utilisé.

Niveau gestion du temps, il y a presque autant de réponses que de participants prenant la parole: certains préfèrent s'imposer des horaires fixes, d'autre un nombre de tâches par jour, d'autres ne veulent pas de contraintes horaires,... À chacun de trouver ses méthodes.

'Note : les participants ayant des motivations et métiers différents, cela n'aidait pas aux discussions sur la gestion des tâches et du temps. Difficile de prendre des cas précis.'

Motivation de groupe ?

Pour certains, la motivation passe par le groupe : à plusieurs, il est possible d'aller plus loin. Le recoupement des expériences montre que c'est cependant pas magique. La raison principale avancée comme explication à l'échec d'une équipe est que, tout simplement, il est difficile de travailler pour les idées des autres. Comme l'indique l'intitulé de la session, chez soi, on fait des projets personnels.

Les cas d'équipe qui fonctionnent semble être ceux dans lesquels le projet est porté initialement par une seule personne qui fait plus de la moitié du travail et qui est capable de tout faire. Avoir un bon contact et passer du temps en communication aide en plus à fédérer des gens autour de son projet. Cependant, il ne faut pas chercher à garder ces contributeurs comme des employés, mieux vaut les considérer comme des contributeurs occasionnels.

6. Fédérer la communauté indy, partage technologique et autres

Dans cette session, c'est la partie partage qui m'intéressait. Je ne suis pas indépendant. Cependant, cela a du se voir dans les différentes sessions que j'ai suivi, je suis persuadé que le partage fait progresser tout le monde, tout en laissant à chacun de quoi se différencier dans ses projets. Nos métiers concerne le jeu, les moyens de faire des jeux, de bon jeux si possible. Et perdre du temps est un obstacle à la qualité.

Cette session commence par essayer de savoir ce qu'est un indépendant. Ce n'est pas évident. Il n'y a pas eu de réponse claire, et ce n'est pas le sujet qui m'intéresse.

Ce qui m'intéresse est : comment partager ?

Deux des sessions précédentes donnent des pistes, forcément. L'utilisation du logiciel libre est probablement un bon moyen. Whirly ajoute même : une assurance. Une assurance qu'on ai accès à la ressource, que celle-ci ne disparaitra pas avec une entité (association, entreprise ou personne).

La peur du libre est que certains soient des mauvais joueurs, qu'ils prendront sans donner. Le risque est très élevé, le monde du libre nous l'apprend, mais ce qu'il nous apprend aussi, c'est que l'impact est faible, ceux qui contribuent sont gagnants par rapport à ceux qui ne sont que clients.

Un exemple simple, pour un petit studio qui a beaucoup participé à une technologie, voire qui en est le moteur, est qu'elle a ensuite la possibilité de vendre du service sur cette technologie.

Il est évoqué que les outils sont souvent très adaptés aux besoins des studios. À cela, une solution semble se trouver dans les bases décentralisées (comme Git ; comme quoi, les sessions que j'ai suivi dans cette journée se recoupent).

Le libre demande cependant une gestion de communauté. Là-dessus, la session n'a pas trouvé de solution claire, cela nécessite d'être fouillé car les possibilités sont nombreuses. L'exemple de boost et son comité de sélection a cependant été cité.

Attention au phénomène de vide grenier : mieux vaut pour cette hypothétique communauté travailler sur des outils ayant de la valeur ajoutée. Un exemple : Ogre3d manque cruellement d'outils autour du moteur. Un autre exemple : fournir des modules pour Unity3d.

À plus long terme, une telle communauté pourrait s'intéresser au CIR et inversement.

La session s'est beaucoup attachée au partage technologique, mais il n'y avait pas que des informaticiens autour de la table. Il serait possible de partager sur de la gestion de projet, du game design. Un GameCamp est d'ailleurs un bon exemple de partage. Une idée de gestion documentaire électronique est lancée, mais il s'agirait de ne pas copier l'existant (Gamasutra par exemple).

Une autre idée de partage est lancée : le peer review. Les petits studios n'ont pas la possibilité de payer des boites de play tests. Une communauté indépendante pourrait se faire tester ses jeux par les différents studios.

Fin !

La journée arrive déjà à sa fin. Whirly nous avait prévenu : une seule journée pour un BarCamp se termine généralement par de la frustration. Encore tant de choses à dire, à partager.

Daz et Whirly font un petit debrief de la journée, sur le vif, en posant quelques questions. À première vue, tout le monde est satisfait.

Le temps de dire au revoir, je rentre chez moi.

Vraiment une bonne journée. Merci à tous.

Autres articles sur le GameCamp

Vous faites quoi le 13 décembre ?

Sylvain Glaize — Sun, 06 Dec 2009 21:20:00 +0100

Grande campagne d'affichage en ce moment sur le réseau transilien pour l'arrivée de la nouvelle rame nommée « le Francilien ». J'ai cru voir passer qu'il y avait eu des places offertes pour y monter dès le 12 décembre.

Mon emploi du temps de fin d'année étant extrêmement chargé, je n'irai cependant pas le 13 décembre voir les premières rames rouler Gare du Nord.

Pour plus de renseignements, allez voir sur Métro-pole par exemple.

Pourquoi les maths ? Pour Layton bien sûr !

Sylvain Glaize — Thu, 03 Dec 2009 08:00:00 +0100

C'est au collège que j'ai entendu pour la première fois cette question d'élève : à quoi servent les maths ? Il est vrai qu'après une étude très pratique des outils mathématiques dans le primaire, le collège enseigne des outils plus abstraits et que si certains enseignants arrivent à ancrer ces outils dans la pratique, certains oublient complètement cet aspect.

J'ai entendu ensuite cette question plusieurs fois par ans et ce jusqu'au lycée. Les réponses des enseignants variaient et souvent n'étaient pas satisfaisantes, même pour moi qui me plaisait dans la manipulation des outils mathématiques.

Depuis que les jeux vidéo de la série Professeur Layton sont sortis, une réponse est simple : pourquoi les mathématiques ? Mais pour jouer à Layton bien sûr !

Dans le Professeur Layton (deux jeux sortis à ce jour en France), le joueur est amené à résoudre des énigmes : logique, calcul, observation,... Il est aussi essentiel d'être attentif à l'énoncé du problème, quelques pièges y étant glissés.

Les mathématiques de Layton, s'ils sont artificiels par rapport à l'histoire qui se déroule dans le jeu, sont néanmoins graphiques et tangibles dans la plupart des cas. On peut manipuler des objets, essayer des choses à tâtons. Quelques types d'énigmes reviennent, chaque fois dans une forme un peu plus complexe, et le joueur peut profiter de ce qu'il a appris des formes plus simples pour résoudre le problème plus directement. Des explications sur la résolution et sur les probables errements du joueur sont donnés à la fin d'une énigme ou avec des indices que l'on peut demander (en échange d'une perte de points).

Peut-être que Layton peut faire aimer les maths à quelqu'un qui se pose la question de leur utilité.

Puis l'on pourra introduire le fait que, plus que de résoudre les énigmes de Layton, les mathématiques servent à construire ces énigmes. Avis aux futurs créateurs de jeu...

Table de jeu Golgotik

Sylvain Glaize — Wed, 04 Nov 2009 23:40:00 +0100

Pour les détails sur ce projet de table de jeu, je vous invite à aller voir chez les participants au projet. Je me suis contenté de prendre des photos.

Suivant les écrans sur lequel je regarde ces montages, c'est plus ou moins sombre, au point de l'être trop. J'espère que c'est bon pour vous. Je ne pense pas prendre le temps de retravailler les couleurs.