Mokona Guu Center

Mon top 5 des jeux 2011

Sylvain Glaize — Sat, 31 Dec 2011 14:50:00 +0100

2011 se termine, et j'ai eu envie de regarder un peu sur cette année là les jeux auxquels j'avais joué et qui m'avaient le plus accrochés. Ce genre de classement est toujours difficile : l'arbitraire de l'année comme limite, les différents types de jeux,...

J'ai pris le parti de faire un top 5 pour différentes catégories concernant les jeux de société/plateau auxquels j'ai joué dans l'année. Ce sont donc des jeux qui ne sont pas forcément sortis en 2011, mais cela représentent ceux autour desquels je me suis le plus amusé en 2011.

En famille

J'ai mis dans cette catégorie dedans ce que je peux proposer en famille, ou bien avec des joueurs occasionnels qui viendraient à passer par là. N'étant pas très Party Games, on n'en retrouve aucun dans le top 5, le premier étant en 11ième position avec Identik.

1. Jamaïca

Voici un jeu qui propose une maîtrise du hasard lors d'une course de bâteaux autour d'une île. Matériel superbe, mécanique simple et fluide. On se tape dessus à coups de canons, mais pas trop et la programmation des bâteaux étant simultanée pour tous les joueurs, le temps d'attente est assez faible évitant le syndrome du joueur qui quitte la table pour aller faire quelque chose le temps que cela soit à lui de jouer.

Les petits bâteaux en plastique, les doublons, le plateau... on trouve ici le savoir faire de Gameworks en terme d'édition, ce qui ajoute au côté agréable.

2. Crôa

Crôa est un jeu où des grenouilles luttent pour la suprématie de la mare. Un jeu guerrier ? En quelque sorte, mais très balancé par son design très mignon. Crôa est un jeu de pions thématisé grenouilles avec un côté chaotique. En effet, les cases du plateau, constituées de tuiles en carton, ont des effets différents et surtout, des effets cachés au début du jeu. Un grenouille qui arrive sur une case/tuile retourne celle-ci. En fonction de la nature du plateau qui se révèle petit à petit, la stratégie se met en place.

Un défaut pour un jeu familial à plusieurs : l'élimination de la reine grenouille élimine le joueur, qui doit alors trouver une autre occupation. Heureusement, les parties sont rapides.

3. Timeline

Assez du Trivial Pursuit et de sa course au camabert qui n'en fini jamais ? Déçu par tous les clones basés sur des cartes avec questions/réponses, thématisés différemment ?

Avec Timeline, la question se résumé à : quand est-ce qu'à eu lieu l'évènement indiqué sur votre carte par rapport à la frise constituée de toutes les cartes déjà placées ? À partir d'une première carte, chaque joueur doit se débarasser à son tour d'une de ses cartes en la plaçant correctement.

Ça se sort n'importe où, s'explique et se comprend en deux minutes. C'est rapide, fun et il existe déjà trois boites avec des thématiques légèrement différentes.

4. Smallworld

Smallworld s'adresse à un public plus restreint un peu plus joueur. Le thème est fantastique avec nains, elfes, zombies et autres classiques. Dans Smallworld, chaque joueur choisi un peuple muni d'un pouvoir (les associations sont renouvelés à chaque parties) et va partir à la conquète d'un monde... bien trop petit pour contenir tout le monde, comme le laisse supposer le nom.

Au bout d'un moment, le peuple en expension stagne et pour continuer à gagner des points, il faut alors changer de peuple, laissant l'ancien en déclin. Le timing du passage en déclin est le principal à comprendre dans le jeu et c'est probablement ce qui le rend moins accessible, demandant plusieurs parties pour « comprendre » le jeu correctement.

5. Qwirkle

L'avantage des jeux abstraits, c'est qu'il ne sont pas thématisés ^[1]. Du coup, le thème ne peut pas rebuter et tout le monde s'y retrouve... sauf ceux pour qui le thème est très important. Bizzarrement, dans le jeu familial, l'absence de thème est souvent un atout, surtout pour les joueurs très occasionnels. Peut-être parce que ceux-ci ont été familiarisés avec les jeux de pions et qu'ils se sentent en terrain connu.

Dans Qwirkle, le but est de marquer un maximum de point en plaçant au mieux des pièces de bois sur la table. Les règles de pose sont simples : les tuiles doivent être sur une même ligne et être soit de la même couleur que le reste de la ligne mais de formes différentes, soit de même forme mais de couleurs différentes. Il y a six formes et six couleurs, la ligne maximum non interrompue est donc de taille six, taille qui octroit d'ailleurs un bonus à celui qui termine à six la série.

Ce dernier bonus fait le sel du jeu : doit-je poser une combinaison qui empêche les autres joueurs de poser pour arriver à six, ou bien est-ce que je tente de construire pour moi-même ?

Accessible à des âges relativement bas, Qwirkle rassemble. Le seul ennui est qu'il faut tenir les comptes avec un crayon et un papier, à l'ancienne, en additionnant les points à chaque tour d'un joueur.

Aguérris

1. Horreur à Arkham

L'indétrônable à la maison. Un jeu consommateur de temps, les parties durant rarement moins de trois heures et demi. Mais le temps passe vite, tous les joueurs se concertant sans cesse pour tenter de faire reculer la menace qui plane sur Arkham.

Horreur à Arkham est un jeu collaboratif : tous les joueurs tentent de battre le jeu. C'est un jeu au livret de rêgles touffu, un jeu qui peut être difficile à battre. Un jeu où le hasard peut se retourner contre vous à chaque instant. Un jeu où il faut faire des choix que l'on peut regretter aussitôt, mais aussi faire emettre un « yes ! » lorsque le tour se passe comme prévu.

Un jeu monstrueusement bon.

2. Automobile

Avec Automobile, on quitte les monstruosités cosmiques pour se diriger vers l'industrie automobile. Chaque joueur est un constructeur automobile qui doit produire des véhicules dans ses usines puis les vendre. Est gagnant le joueur le plus riche à la fin du tour. Austère ? Peut-être. Mais c'est un de ces jeux de Martin Wallace où le thème est servi par une bonne mécanique. Obligé de faire des choix de production et de vente tendues, un oeil sur les concurrents pour ne pas saturer le marché.

3. String Railways

Poser des cordes sur une table pour symboliser des lignes de chemin de fer. Il fallait y penser pour s'éloigner des classiques tuiles dans les jeux de placement. Ici, on ajoute une petite dose de manipulation et de jugement de longueur vraiment sympathique. Il y a une composante aléatoire dans le tirage des stations qui peut vraiment tourner en défaveur d'un joueur, mais l'expérience de jeu peut néanmoins la balancer.

Le tout tient dans une toute petite boite mais nécessite une grande table. Vivement l'édition française !

4. King of Tokyo

King of Tokyo pourrait être dans la section familiale. Il l'est, mais en 13ième position. Étrangement pour un jeu aussi simple et rapide, c'est avec les joueurs les plus réguliers que j'y joue le plus souvent.

King of Tokyo est un Yams thématisé gros monstres. Plutôt que d'y faire des combinaisons un peu froide, on y donne des baffes aux autres monstres, on gagne en énergie et on y achète des pouvoirs qui nous rende encore plus puissant.

Ça tourne très rapidement, c'est générateur de bonne ambiance et ça comble les débuts ou fin de soirées.

5. Thunderstone

Dans Thunderstone, vous allez vider un donjon de ses monstres et y chercher une pierre légendaire. Le thème est plutôt superficielle, quoique moins qu'à son grand frêre Dominion, et est prétexte à un jeu de deck building. Vous commencez le jeu avec un petit paquet de cartes et à chaque tour, vous décidez soit d'y ajouter une carte (en l'achetant), soit d'écarter définitivement une carte de votre main soit d'envoyer une équipe aux trousses d'un des trois monstres qui rodent dans le donjon.

Le but du jeu est donc d'optimiser son deck pour maximiser ses chances de battre les monstres.

Avec mon fils

Mon fils a entre 4 et 5 ans. Jouer avec lui est très agréable,

1. Crôa

J'ai déjà parlé de Crôa au-dessus. Avec mon fils, il est possible de jouer à ce jeu qui est indiqué pour 6 ans et plus à condition de ne jouer qu'à deux, pour limiter le temps d'attente entre deux tours et la complexité de la reflexion. Le fait que le jeu soit caché au début donne une chance de balancer le manque de tactique de déplacement. Il est même possible de jouer à Crôa en version « memory » en retournant une tuile face cachée une fois qu'aucune grenouille ne se trouve dessus. Cela donne un avantage aux plus jeunes ; cependant, il n'aime pas trop car il préfère voir la marre se dévoiler petit à petit.

2. Labyrinthe

Un grand classique. Là encore, la stratégie mise en place ne va pas très loin, mais le jeu n'en demande pas tant. Le tirage de carte rend de toute façon certaines positions aventageuse juste par opportunisme, ce qui laisse une chance aux plus jeunes de gagner. Et le côté manipulation des tuiles est plaisant.

3. Ramses II

Un jeu de memory dont j'ai déjà parlé. Il a toujours la côte.

4. Qwirkle

Voir ci-dessus dans le classement famille. Qwirkle fonctionne avec de très jeunes enfants. Il est même possible d'y jouer à trois. À vrai dire, cela donne une composante choatique au jeu. En effet, mon fils ne cherche pas à optimiser sa main, c'est encore un peu complexe. Il cherche plutôt à placer au mieux une tuile choisie. Parfois deux. Cela ne lui permet pas de gagner, mais la construction de l'espace de jeu est assez fun en lui-même.

5. Pique Plume

Un archi-classique, Pique Plume associe parcours et memory. Des poules en bois, chacun avec une plume dans le derrière, sont disposées sur un circuit constitué de cases avec sur chacune un dessin. Au milieu, un memory avec ces mêmes dessins. Pour avancer se poule d'une case, à son tour, il « suffit » de retourner la tuile centrale correspondante. Si ce faisant on saute par dessus une poule adverse, on lui pique sa plume. Lorsqu'une poule a récupéré toutes les plumes, le jeu s'arrête et son joueur est vainqueur.

La matériel est très adapté, les dessins sont juste assez bien choisis et nombreux pour qu'il soit facile de se tromper. Sauter par dessus une poule adverse est un grand moment !

À deux

1. Stronghold

Stronghold est un jeu qui peut se jouer à 2, 3 ou 4 joueurs. Mais à vrai dire, c'est surtout un jeu à deux joueurs. L'un d'eux joue l'assiégé, l'autre l'assiégeant. Des hordes de gobelins, orcs et trolls à n'en plus finir, des machines de guerres qui s'installent, des sorts qui fusent face à des guerriers en nombre très limités mais pouvant aussi construire des machines et lancer des sorts.

Malgré le côté cubes en bois, l'ambiance s'installe vraiment. L'assaillant, malgré ses hordes, doit contrôler ses ressources pour frapper au bon endroit et au bon moment. Car la forteresse tient bon, et le but du jeu est de se couvrir de gloire. Entrer dans la forteresse trop tard, épuisé, c'est perdre pour l'assaillant. Le défenseur aura prouvé sa valeur, et c'est tout ce qui compte.

Malgré des règles revues à la clareté pour la seconde édition, Stronghold reste un jeu assez lourd à prendre en main. Mais une fois compris, il est fluide et on n'a qu'une envie, essayer une autre tactique.

2. A Few Acres of Snow

L'Angleterre et la France se battent pour le contrôle du Canada. Et ici, la bataille aura lieu autour de la ville de Québec, que les français devront protéger. A Few Acres of Snow réussi à allier un wargame et un jeu de deck building : entre les joueurs, une carte du Québec, dans les mains des deux joueurs, une main de cartes indiquant les possibilités d'action.

C'est très prenant et les possibilités sont très nombreuses.

3. Gosu

Gosu est un jeu de cartes dans lequel deux joueurs font se batailler des gobelins. Les gobelins ont différentes factions et différents styles de pouvoir.. Des contraintes de pose dirigent la manière dont l'armée va être créée en plaçant les cartes devant soit. Puis, au signal, les deux armées se ruent l'une sur l'autre et donne un point de victoire. Les restes des armées sont alors prêtes pour une nouvelle préparation.

Gosu à l'air d'un bête Magic like à première vue. Une différence est que ce n'est pas un jeu à collectionner. Les deux joueurs se partagent la centaine de carte (ou plus avec l’extension). Les possibilités de combo sont multiples et il faut du temps pour arriver à maîtriser le jeu.

4. Can't Stop

Pour changer, voici un jeu simple, rapide et fun que l'on peut sortir n'importe où l'on peut lancer quelques dés et poser un petit plateau. Can't Stop est un jeu de stop ou encore. Chacun son tour, les joueurs lancent quatre dés qu'ils assemblent en pair pour donner deux résultats. Ils avancent ensuite leur pion sur une piste correspondant aux résultats et dont la longueur correspond à la probabilité de sortir ce résultat. Seules trois pistes peuvent être "grimpées" lors d'un même essai.

Après chaque déplacement, le joueur peut choisir de s'arrêter et de valider son avancée ou de continuer à lancer les dés. Si les dés n'indiquent pas de déplacement possible, le joueur perd toute sa progression de ce round et son tour s'arrête.

Le nom est bien choisi : il est difficile de s'arrêter ! Quelque chose nous dit toujours que non, là, on va pouvoir battre le hasard !

5. 7 Wonders

Étonnant de trouver 7 Wonders ici, dans les jeux à deux. Et pourtant, même si ce déjà grand classique et sur-primé est un jeu qui se joue entre 3 et 7 joueurs, la variante à 2 joueurs est très agréable.

7 Wonders est un jeu dont la nature change en fonction du nombre de joueurs. À 3, le contrôle sur le jeu est assez important, il n'y a pas de carte en double et l'on reverra passer les cartes. Cela permet de construire une stratégie. À 7, je jeu est très aléatoire et les joueurs sont à la merci du mauvais sort, le jeu consiste alors à essayer de maximiser les points un peu au petit bonheur, mais plutôt d'embêter ses voisins.

À deux, le jeu offre encore plus de contrôle sur ce que l'on fait et la présence de la cité franche ouvre de nouveaux horizon.

Seul

Les jeux seuls sont nettement moins nombreux que les jeux à plusieurs. Normal, les jeux de "société" s’accommodent mal des joueurs solitaires. Pour cette section, je me suis restreint à un top 3.

1. Vendredi

Aidez Robinson à quitter votre île ! Décidez de ses actions (retourner à son épave, explorer l'île,...), augmentez ses capacités à survivre, gérez son capital d'énergie. Pendant ce temps, Robinson vieilli, ce qui lui donne quelques malus.

Au final, envoyez Robinson vaincre deux pirates pour qu'il vous laisse enfin tranquille.

Vendredi est un jeu de deck building en solitaire, vraiment immersif. Il faudra prendre des risques au bon moment, choisir les bonnes récompenses. Et recommencer avec un nouveau Robinson si celui-ci succombe.

2. Onirim

Onirim est étrange et prenant. La thématique du rêve peut sembler venir de nulle part, mais elle fonctionne. Les dessins des cartes y sont certainement pour quelque chose. Dans la mécanique, c'est un jeu de type "réussite" avec plusieurs variantes. Mais une réussite où l'on a des choix à faire, on ne se contente pas de retourner les cartes.

Onirim peut se jouer à deux aussi, mais je n'ai jamais essayé.

3. Death Angel

Death Angel peut se jouer à plusieurs en coopération, mais fonctionne tout aussi bien à 1. C'est une version carte du vénérable Space Hulk, au moins pour la thématique : des Space Marines dans un vaisseau doivent accomplir une mission extrêmement dangereuse, sous l'assaut incessant de hordes d'Aliens.

Tout comme dans son grand frêre, Death Angel est difficile à battre.Les Space Marines ont l'air bien démuni face aux menaces. Mais un peu de réflexion aide à contrer les coups du sort de ce dé qui décide de la vie et de la mort des membres de escouades.

Notes

[1] Même si, parfois, un auteur se sent obligé de coller un thème sur une mécanique

Capteurs photos de téléphones portables

Sylvain Glaize — Sun, 04 Sep 2011 18:00:00 +0200

Faire des photos avec un téléphone portable est devenu assez courant. Mais à moins d'avoir un superbe éclairage, un téléphone qui a mis la priorité sur la fonction photographique et avoir des sujets ne bougent pas trop, le résultat est souvent assez catastrophique.

C'est la même chose pour les appareils photos numériques premiers prix et/ou pour enfants, qui doivent probablement utiliser les mêmes capteurs et lentilles.

J'ai par hasard pris une photo qui révèle un effet intéressant de ces capteurs.

Comme il n'y a pas d'obturateur mécanique, ils font appel, comme les compacts numérique, à une sorte d'obturation électronique : le but est que toutes les cellules du capteur commencent à capter la lumière en même temps et que la lecture du résultat soit faite simultanément. Probablement que, pour économiser de l'énergie, mais à vrai dire, je n'en sais rien, le capteur de ces appareils font un balayage des cellules pour prendre la photo en entier : l'image finale ne représente donc pas un instantané. . Résultat, une superbe distorsion de l'image lorsque le sujet (ou l'appareil) est en mouvement.

Add-ons faciles pour Firefox

Sylvain Glaize — Fri, 08 Jul 2011 22:37:00 +0200

Il y a quelques années, j'avais voulu créer un petit module pour gérer mes bookmarks dans Mozilla/Firefox qui étaient assez nombreux et difficile à classer. J'avais été arrêté par la complexité d'avoir un environnement de développement pour utiliser XUL.

Il fallait installer une version spécifique du navigateur, compilée d'une manière spécifique. Ça a probablement évolué depuis ce moment, mais j'avais laissé de côté l'idée de faire un module pour le navigateur. Je n'avais surtout pas vraiment de besoin : les modules existant me suffisaient et je ne gérais de toute façon plus mes bookmarks de la même manière.

Et puis il y a deux semaines, j'ai vu une nouvelle sur un SDK simplifié. Et il se trouve que j'avais une idée en tête à ce moment là. J'ai donc un peu joué avec et cela a donné un module qui fonctionne sur le site Jeux sur un Plateau.

Que dire donc de ce SDK ?

Mise en place

La mise en place est vraiment facile. Une archive à extraire sur le disque, avoir Python d'installé (une évidence) et un Firefox (forcément). Le démarrage un peu pénible car local au terminal dans lequel il est activé, mais cela ne pose pas tant de soucis que ça.

Utilisation

Tout se fait à travers l'utilisation d'une commande cfx. Celle-ci permet de créer un module (quasi) vide pour démarrer le sien. Pourquoi pas complètement vide ? Bizarre.

La commande permet aussi de lancer la documentation locale, les tests et avoir une instance de Firefox lancée dans un profile vierge avec juste le module d'installé.

Tests automatique

C'est un peu la déception. Peut-être que je m'y prend mal, peut-être que le SDK ne peut pas être utilisé sans d'autres outils. Mais les outils du SDK pour le test sont assez basiques et avoir un bon harnais de sécurité semble un peu complexe. À poursuivre.

L'API

L'API de ce SDK ne permet pas d'accéder à tout ce que présente le SDK complet. Mais il permet déjà pas mal de choses : injecter du javascript dans une page, afficher des pages HTML + Javascript qui permettent de dialoguer avec l'utilisateur, envoyer des notifications.

C'est simple à utiliser. Ça reste principalement du javascript avec ses défauts et il y a quelques petits trucs à comprendre au delà des exemples.

Quelques trucs

Dans la plupart des exemples qui dialogues avec des pages web, la communication se fait au travers d'un worker. Ça marche pour des exemples simples, mais il est en fait important de gérer qu'il peut y avoir plusieurs workers et que certains peuvent être détachés.

Et effet, dès que le code se complexifie un peu (et mon module n'est pas si gros que ça) on peut rapidement se retrouver avec des workers qui ne sont plus valides car la page a été fermée ou rechargée.

Ne pas aussi copier le style des exemples : tout en ligne, comme on voit souvent en javascript. Comme dans n'importe quel développement, une architecture maîtrisée vous gardera sur les rails.

Soyez un utilisateur positif : râlez !

Sylvain Glaize — Tue, 15 Feb 2011 21:00:00 +0100

Vous avez probablement déjà vécu ce moment où le programme que vous utilisez cesse d'être l'outil qui vous permet d'avancer dans vos tâches. Ou bien de ce site web qui se met à afficher des résultats aberrants. Tout cela bien entendu exactement au moment où vous n'avez pas de temps à perdre.

En fait, même lorsque vous ne faites rien de bien important ou que vous n'êtes pas dans l'urgence, le défaut d'un programme devient rapidement irritant.

Alors vous râlez, vous pestez après ces maudits programmeurs. Vous trouvez ou ne trouvez pas une solution temporaire pour vous sortir de la situation et puis...

Et puis souvent, c'est tout. Le problème est oublié, jusqu'à la prochaine fois. Ou bien encore plus souvent, l'utilisateur fait avec et intègre sa solution temporaire à ses habitudes de travail.

Dans un article précédent, je montrais déjà comme il pouvait être dangereux de contourner un problème plutôt que de le résoudre. Dans le cas d'une utilisation de programme cependant, l'utilisateur n'a pas forcément la possibilité à court terme de résoudre la situation.

Mais si le contournement est intégré dans les habitudes, le danger est similaire : la dette est payée sur le long terme.

Ainsi, on voit parfois des utilisateurs de longue date d'un programme être moins efficace sur une tâche qu'un débutant. L'habitué évite un défaut dans le programme que le débutant n'a jamais rencontré, ce défaut ayant été corrigé entre temps.

Contre ce dernier soucis, l'habitude à prendre est de régulièrement analyser sa manière de faire et de suivre la documentation d'évolution du programme.

Prévenir les secours

L'utilisateur n'a donc pas de moyen immédiat de correction du défaut, mais il a cependant un moyen puissant de contribuer à cette résolution : le « rapport de bugs »^[1].

Les développeurs sérieux ont tous à disposition un moyen de répertorier l'ensemble des défauts connus de leur logiciel. À chaque défaut est assigné plusieurs caractéristiques permettant de les trier. Parmi elles, on en trouve deux très importantes : la sévérité (est-ce que le défaut faire s'arrêter brutalement le programme ? ou pire, le programme corrompt-il silencieusement les données ?) et la fréquence (est-ce arrivé une seule fois ?, ou bien est-ce systématique sous certaines conditions d'utilisation ?).

Ainsi, on peut classer les défauts pour traiter en priorité les plus sévères et fréquents.

Ce que l'on voit rapidement, c'est que la fréquence, ou plus exactement l'occurrence, est un facteur multiplicatif : un défaut sévère mais qui ne se produit jamais (ex : car il survient dans le cadre d'une utilisation vraiment anormale du logiciel) sera moins prioritaire qu'un défaut juste un peu pénible (ex : une valeur qui ne se rafraichit pas immédiatement) mais qui se produit chez tous les utilisateurs.

La fréquence d'un bug est donc très importante pour déterminer la priorité des défauts. Mais c'est aussi une valeur complexe à obtenir. En effet, elle nécessite la coopération des utilisateurs à travers le signalement des défauts.

Le développeur de logiciel à d'autre outils pour repérer les défauts d'un logiciel et nourrir la base de données qui les centralise. Mais sans retour utilisateur, celle-ci ne sera pas correctement triée ; dans le sens où, par ignorance de ce qui pourrait augmenter le plus rapidement possible la qualité perçue, elle sera probablement triée selon des critères purement techniques.

Un lourd passé

Malheureusement, l'histoire de l'informatique n'a pas fait grand chose pour montrer à l'utilisateur que son retour était essentiel. Celui-ci s'est souvent vu le cobaye involontaire de logiciels et systèmes d'exploitation présentant de nombreux défauts ; sans moyen facile de déclarer un défaut et d'en suivre son traitement ; sans aucune réactivité de la part du développeur.

À cela on peut ajouter le prix parfois élevé d'un logiciel qui à tendance à entraîner la fausse idée que s'il est cher, c'est que le développeur a les moyens de trouver les défauts seul^[2].

Et parfois, un seul logiciel cumule le tout.

Des années de ce régime dans les logiciels parmi les plus populaires ont amené une situation terrible^[3] : la grande majorité des utilisateurs pense qu'un logiciel avec des défauts est normal et qu'il faut faire avec.

Faites-vous entendre

Qu'un logiciel ait des défauts, on peut s'y attendre. Les considérer comme une fatalité n'est pas normal. Et si par hasard le développeur du logiciel ne vous fournissez aucun moyen d'agir sur la qualité en signalant les défauts ou en ne les prenant pas en compte, vous devriez vous en méfier et regarder si un autre logiciel ne vous conviendrait pas mieux.

Et si vous avez la chance d'utiliser un logiciel développé par une équipe facilement accessible, par exemple dans votre propre entreprise, c'est encore plus simple car vous pouvez communiquer avec eux facilement.

N'hésitez pas ! S'ils sont un tant soit peu concernés par la qualité de ce qu'ils développent, ils n'attendent que ça !

J'espère vous avoir fait comprendre à quel point l'utilisateur avait la possibilité d'agir sur la qualité d'un logiciel, à quel point il était important qu'il ne se prive pas de le faire et à quel point un développeur devait prendre cela en compte.

Alors, la prochaine fois que vous êtes la victime d'un défaut logiciel, je compte sur vous pour râler, mais râler utilement^[4].

Notes

[1] J'emploie dans cet article indifféremment défaut ou bug, mais le plus souvent défaut.

[2] Peut-être qu'il le peut, mais comme on vient de le voir, sans priorité déduite de la fréquence d'apparition, la liste n'a pas le sens qu'elle devrait avoir.

[3] Toute proportion gardée.

[4] Cependant, les bases de bugs ne sont pas des défouloirs, il est inutile d'y insulter les développeurs.

Sélection de jeux à deux

Sylvain Glaize — Fri, 11 Feb 2011 21:00:00 +0100

L'avantage du jeu à deux, c'est que ce n'est pas bien compliqué à organiser. Il suffit de... deux personnes. Et un week-end en amoureux, c'est l'occasion d'être deux. Si l'on est joueur, il serait dommage de ne pas glisser un ou deux jeux peu encombrant dans le sac.

Voici une petite liste non exhaustive de jeux qui répondent à ces critères, basés sur ce qui était dans mon sac de voyage récemment.

Sun Tzu

Sun Tzu arrive en premier car c'est le dernier jeu auquel j'ai joué à cette date. C'est une réédition 2010 d'un jeu de 2005. C'est un jeu pour 2 joueurs, un petit jeu de conquête de territoire rapide (moins de 30 minutes) dans une petite boite bien remplie.

Dans Sun Tzu, chaque joueur est un général qui va devoir conquérir des territoires pour amasser des points. Le jeu dur au maximum neuf tours, et les points sont comptés aux troisième, sixième et neuvième tour. À chaque tour de décompte, les territoires changent de valeur et si lors d'un décompte, l'un des joueurs atteint les 10 points, le jeu s'arrête.

Ces deux règles obligent les joueurs à regarder dans le court terme, pour ne pas être éliminé rapidement, mais aussi un peu plus loin, pour être certain de pouvoir changer la disposition de ses troupes.

La conquête des territoires se fait par l'utilisation de cartes de valeurs. À chaque tour, chacun des joueurs pose face cachée une carte pour chacun des territoires. Puis lors d'une phrase de résolution, les cartes sont comparées et leur différence de valeur donne directement la modification en nombre de pion troupes sur le territoire. Chaque joueur possède, outre des cartes permanente, des cartes spéciales, dont l'utilisation est unique, qu'il tire à chaque tour.

Sun Tzu tourne vite et bien et est plutôt joli.

Jaipur

Jaipur est un jeu de cartes qui tient dans une petite boite contenant aussi quelques jetons. Vous y jouez un marchand qui achète, échange et vend des marchandises. Les règles sont très simples mais le jeu n'est pas simpliste.

Le matériel est agréable (une tautologie chez cet éditeur, Gameworks) et pour compenser l'éventuelle malchance au tirage qui peut vous guetter, la partie se joue en deux manches gagnantes.

Jaipur est une valeur sûre du jeu à deux. N'hésitez pas à l'emporter.

Citadelles

Citadelles est, comme Jaipur, un jeu de carte avec un peu de matériel en plus, ici, des jetons. Les points communs s'arrêtent là. Citadelles est un jeu pour 2 à 7 joueurs ou chacun choisi dans un premier temps, avec un système de draft, un rôle qui, dans un second temps, lui permettra d'effectuer des actions.

Au fil des tours, chaque joueur va développer une cité en achetant des bâtiments tout en volant les autres joueurs (ou pire), récupérant des subsides grâce aux bâtiments construits. À la fin du jeu, on compte les points des bâtiments posés, avec un bonus pour la diversité de ceux-ci.

Le jeu oblige donc à faire des choix cornéliens (sans nécessité une trop longue réflexion cependant) entre les rôles qui nous arrangent et ceux que l'on n'aimerait pas laisser aux autres joueurs,

Le jeu à deux est un peu différent car les joueurs y jouent deux rôles et non un seul. Mais cela fonctionne tout de même très bien.

Le collier de la Reine

Le collier de la reine est un jeu pour deux à quatre joueurs qui fonctionne beaucoup mieux à deux qu'à quatre.

En effet, il comporte un mécanisme de carte dont le coût diminue avec le temps (le tour des joueurs ). Et on perd à quatre la prise de risque que l'on trouve à deux : est-ce que je laisse passer cette carte afin de ne pas la payer cher à mon prochain tour.

Dans ce jeu, les joueurs sont des joaillers qui vont acheter des pierres avec de fabriquer la parure à la fois la plus rare et la plus appréciée à la cours, ceci à travers trois ventes dont la dernière clôture la partie.

Un jeu avec un peu de bluff, quelques coups en douce à travers des cartes spéciales et des règles très simples.

Le matériel est de qualité et pourra être sorti de sa boîte d'origine pour prendre moins de place dans le sac.

Dungeoneer

Envie d'aller explorer des donjons peuplés de monstres, tapissés de pièges et garnis de trésors ? Vous avez le choix, le thème est assez souvent exploité. Dungeonner à l'avantage de proposer ça sous forme de cartes avec quelques marqueur. La boite contient même un peu de place pour y caser des dés et quelques figurines, plus sympathiques que les marqueurs de carton fournis de base.

Le jeu se jour de 2 à 4, mais est sympathique à 2. Chaque joueur joue son tour en trois phases : l'extension du donjon en y ajoutant une carte, le rôle des monstres, puis le rôle de son aventurier. L'aventurier d'un joueur va se déplacer dans le donjon, éviter les pièges et tenter de résoudre des missions. Trois missions réussies, et c'est la victoire.

Un mécanisme de points de bravoure et points de menace oblige l'aventurier à prendre des risques : il a besoin de points de bravoure pour effectuer ses actions, mais les points de menace permettent aux autre joueurs d'utiliser des actions néfaste en tant que maître du donjon contre lui.

Dungeoneer est en fait une série de jeux, dont deux seulement traduits en français actuellement.

C'est du Porte Monstre Trésor, ça ne demande pas vraiment de réflexion, mais le thème est plutôt bien rendu.

Comment renouveler le Memory

Sylvain Glaize — Sat, 06 Nov 2010 23:00:00 +0100

Le Memory, c'est ce jeu où des cartes ou pions présentant des paires d'images identiques (ou associables) que l'on retournent pour ensuite les retrouver. C'est un jeu simple et accessible, qui ne demande rien d'autre que de la mémoire.

Le principe est tellement simple qu'on n'en compte plus les déclinaisons, autant de versions dont seul change le thème des illustrations, collant le plus souvent à la thématique du magazine dont il est le bonus, le département marketing n'étant pas très créatif niveau jeu.

Récemment, cependant, grâce à une brocante, j'ai découvert Ramses II, un jeu de société qui montre bien qu'en travaillant un peu un concept mille fois copié, on peut en renouveler l'intérêt. Qui montre aussi qu'en poussant trop le dépoussiérage, on peut faire retomber l'intérêt que l'on vient de susciter.

Ramses II est donc un jeu qui fait appel à la mémoire. Avant de parler du principe du jeu, parlons de l'emballage. Au delà de la qualité des éléments du jeu, j'ai particulièrement apprécié le soucis du détail qui, pour une thématique égyptienne, affiche sous forme de hiéroglyphe le principe de la règle sous le titre du jeu.

Voici ce que je pense lire : les deux mains indiquent qu'il faut lire cette suite. Puis : question, se souvenir (yeux vers le cerveau), pousser des pyramides, regarder (yeux vers le plateau), la pyramide, exclamation, corne. Que je veux bien lire : vous devez vous souvenir de l'emplacement de l'objet demandé et pousser les pyramides pour trouver la corne (la corne est un des objets du jeu).

Voilà, vous connaissez presque les règles. Ce qu'il faut ajouter est que l'on ne déplace qu'une pyramide à la fois, suivant le principe du pousse pousse, que chaque pyramide cache soit un objet soit rien et que, lors de vos déplacements pour retrouver l'objet indiqué sur la carte que vous avez pioché, révéler un autre objet vous fait perdre votre tour. Le joueur suivant prend alors le relai des recherches.

Simple et astucieux, voilà qui renouvelle le sempiternel Memory pour faire travailler sa mémoire.

Les objets étant demandés plusieurs fois, et les erreurs, surtout en début de partie, faisant trouver l'emplacement des objets, la visualisation des emplacements cachés se met en place au fur et à mesure (l'emplacement des objets est différent à chaque partie).

Et cela marche vraiment bien.

Sauf que...

... l'auteur, entraîné par son idée, peut-être poussé par son éditeur, ajoute un chaos inutile à tout cela.

Les cartes de questions sont séparés en trois niveaux. Dans le premier niveau, il n'y a que des objets à trouver, mais déjà, un point chiffonne : chaque objet est demandé plusieurs fois (2 fois il me semble) avec un nombre de point différent (1 et 2). Ainsi, si vous trouvez la momie à 1 point, vous marquez 1 point. Si vous trouvez celle à 2 points, vous marquez 2 points.

Inutile ! Et frustrant ! Le sel du jeu est de se retrouver dans une sort de labyrinthe dont on se fait un plan mental. Pas d'avoir de la chance !

Chez nous, les points des cartes ne sont donc pas comptés. Seul le nombre de cartes acquises en fin de partie (on garde la carte lorsque l'on trouve l'objet) fait fois pour désigner le vainqueur.

Dans les deux autres niveaux de carte, on trouve toujours les mêmes objets rapportant plus de points (je viens de dire ce que je pensais de ce système) mais aussi des cartes « spéciales ».

L'une d'entre elle est intéressante : sa pioche entraîne une rotation du plateau. Voilà une carte intéressante, qui relève un peu la difficulté.

Mais que dire des autres : lancer des défis et en fonction de la réussite, s'échanger des cartes. Encore une fois, c'est perdre le cœur du jeu pour mettre un chaos inutile et frustrant. Celui qui gagne n'est plus forcément celui qui trouve le mieux les trésors, c'est celui qui a les meilleurs cartes...

Vous l'aurez probablement deviné, ces cartes n'ont pas le droit de cité lorsque nous jouons. Elles sont impitoyablement mises de côté.

Un jeu très sympathique, donc, qui marche sans adaptation (mises à part celles indiquées ci-dessus) pour des beaucoup plus jeunes que l'âge indiqué (8 ans, alors que nous jouons avec un enfant de 3 ans sans problème, et qu'il fait un adversaire coriace !).

Et qui montre qu'une bonne idée peut renouveler un genre, mais que vouloir en rajouter peut nuire au plaisir du jeu.

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