Mokona Guu Center

GameDaba suite de la série sur l'affichage

Mokona — Tue, 21 May 2013 11:20:00 +0200

Ça aurait pris un peu de temps et deux écritures avec un angle différent du même article. Dans l'un, j'explorais peut-être un peu trop mes souvenirs et le résultat ne me plaisait pas. Celui publié évoque quelques tactiques et limitations de la couleur sur les ordinateurs de l'époque dite familiale.

C'est un survol assez haut, toujours par rapport à mon expérience. J'ai beaucoup utilisé le CPC, c'est peut-être la première machine que j'ai connue vraiment dans ses moindres détails (à l'époque), je connaissais un peu le ZX Spectrum pour avoir des copains qui avaient cette machine.

La fin de l'article évoque la 3D, mais je pense aller vers d'autres horizon avant. En premier lieu, suite à la vision d'un épisode de l'émission Very Hard de NoLife, un commentaire sur le VCS2600 m'a interpellé et je voudrais creuser.

En attendant, le lien vers l'article : Que la couleur Soit !.

Jeu de Mémoire

Mokona — Wed, 27 Feb 2013 22:00:00 +0100

Pour mon jeu de février dans le cadre du défi One Game A Month, j'ai créé un petit jeu de Memory.

Ce jeu avait deux buts : d'une part continuer à me familiariser avec les jeux dans navigateur, d'autre part créer un jeu pour mon fils en utilisant des images qui lui sont familières.

Pour le côté technique, j'ai donc choisi d'utiliser Dart et son environnement. Découvrir un environnement, surtout lorsque celui-ci est en construction, n'est jamais simple, et ce simple jeu d'appariement de tuiles m'aura finalement pris un mois à faire ^[1].

Le résultat est là, dans une version qui n'est pas celle prévue pour mon fils, qui n'est destinée qu'à lui.

On s’apercevra rapidement que je n'ai pas travaillé avec un graphiste. Tout cela manque d'unité, de détails.

Niveau Dart, depuis mon dernier billet, j'ai progressé dans la compréhension du framework, qui lui même à de son côté progressé simultanément.

Je ne suis toujours pas extraordinairement conquis par Dart. C'est correct. Par rapport à Javascript, l'analyse syntaxique, l'annotation des types et les tests m'ont certainement fait gagner du temps (que j'ai perdu car je suis en phase d'apprentissage). Mais il y a encore du chemin pour en faire un langage avec une vraie identité. On sent que, surtout au niveau du SDK, ça se cherche encore.

Où alors, je n'ai pas encore trouvé les bonnes sources, et c'est moi qui cherche. C'est possible.

Au final, j'ai fait pas mal d'erreurs et il me faudra un second projet avec Dart à démarrer sur des bases plus saines en prenant en compte ces erreurs afin de les éviter.

Cependant, pour le mois prochain je pense approfondir ce que j'ai commencé dans le cadre des Novendiales (organisé par les GCN avec pour thème "Portail". J'ai rendu quelque chose d'à peine commencé dont je parlerai dans un prochain billet.

Note

[1] à un rythme des 3 à 5 heures par semaine avec une concentration légère.

Mon top 5 des jeux 2012

Mokona — Tue, 22 Jan 2013 00:45:00 +0100

Voici ma deuxième édition de mon multiple top 5 des jeux de société auxquels j'ai pu jouer en 2012. Rappel de ce que j'avais fait pour la précédente édition :

Le top 5 est divisé par catégories en fonction des environnements dans lesquels je peux avoir joué. Ce ne sont pas forcément des jeux sortis en 2012, mais des jeux auxquels j'ai eu l'occasion de jouer en 2012.

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

1. Jamaïca

Premier l'année dernière, toujours premier cette année. Toujours une valeur sûre. Vous pouvez aller voir ce que j'en disais l'année dernière, rien n'a changé.

Vivement la prochaine partie.

2. Small World

Quatrième l'année dernière, le voilà second. Small World a gagné cette année une nouvelle version, Realms. Je n'y ai pas encore joué, je n'ai pas encore d'avis dessus. Je n'ai d'ailleurs toujours pas joué non plus à la version Underworld.

Le frein est pour ce jeu toujours les pouvoirs qui, pour des joueurs qui débutent ou qui reviennent au jeu après un moment, doivent être relus ou re-expliqués.

3. Strike!

Voilà un petit nouveau. Et quel petit nouveau ! Combien de lancés de dés depuis sa sortie ? Un principe extrêmement simple : dans une arène, vous devez lancer des dés un par un et récupérer les figures identiques présentes dans cette arène. Une fois des dés récupérés ou à n'importe quel moment après avoir lancé un dé, c'est au joueur suivant. Si vous n'avez plus de dés, vous avez perdu.

Deux accélérateurs de jeux sont aussi présents. Le premier élimine un dé dont la face 1 (remplacée par une croix) sort. Le second est une règle spécifique : si à votre tour de jeu (à part pour le premier lancé de la partie) l'arène est vide, vous devez lancer tous les dés en votre possession.

Rapide, fun, hasardeux avec un mini brin de stratégie sur les probabilités. Accessible à tous, sorti rapidement, rangé rapidement !

Un excellent jeu à caser n'importe quand.

4. Tobago

Cela faisait longtemps que je voulais jouer à ce jeu. C'est chose faite, et c'est une très bonne expérience. Tout en restant sur un format qui ne demande pas des calculs très intenses, voilà un jeu qui offre de la prise de risque et du placement dans un enrobage vraiment réussi.

Dans Tobago, les joueurs sont à la recherche de trésors sur une île à bord de jeeps par très écologiques. En plaçant des cartes d'indice, les joueurs restreignent les cases probables pour trouver un des quatre trésors simultanément en jeu. Lorsqu'il n'y a plus qu'une seule case, un joueur peut aller creuser et répartir le contenu du trésor entre tous les joueurs ayant posé des indices pour ce trésor-ci. Mais attention aux malédictions.

Un système d'équilibrage est présent à base d'amulettes qui apparaissent après la découverte d'un trésor. Cependant, l'équilibrage n'est pas automatique, il faut aller chercher ces amulettes. C'est un jeu qui demande de l'attention, un peu de calcul, un bon placement et même des concessions (on ne peut pas tout avoir).

5. Formula Dé

Quand je vous disais qu'il ne s'agissait pas des jeux sortis en 2012... En voilà bien un exemple, un vénérable ancien. C'est à la version Eurogames que je joue, même si j'ai aussi pu jouer à la version Asmodée.

Ce jeu tourne toujours aussi bien et peut rassembler même des gens qui ne sont pas fans de sports mécaniques (moi le premier) pour un petit tour de course. Je n'ai jamais essayé de proposer la version trois tours avec météo et tour de qualification. Je pense que ça serait un format un peu long pour cette catégorie.

Et du coup, j'aimerais tenter ça un jour ou l'autre.

Les sortants

Où sont passés les jeux du top 5 de l'année dernière ? Crôa aurait peut-être pu être là, je n'y ai tout simplement pas joué en 2012 ! Quant à Timeline, qui est en 19ième position, j'explique la chute par des parties qui se renouvellent assez peu. Le jeu était soutenu par une promesse de nouvelles cartes mais finalement, cela s'est transformé en une boite multi-thème et une dérive sur le Cardline: Animaux, qui lui se retrouve 8ième dans mon top en catégorie « Avec mon fils ».

Aguérris

Voilà la section du lourd, du gros, ou du léger mais aux thèmes moins faciles. Les jeux de cette catégorie nécessitent d'avoir avec soi des joueurs qui n'ont pas peur de règles parfois touffues, ou de règles simples aux multiples implications.

1. Steam

Il n'était pas là l'année dernière pour une bonne raison : je n'y avais pas joué en 2011. Placer ses voies, acheminer les marchandises, prévoir plusieurs tours à l'avance, ne pas emprunter trop, emprunter assez, bien timer le changement de locomotive,... se faire prendre un emplacement peu coûteux, voir les marchandises convoitées partir par un autre chemin, devoir emprunter les lignes des autres joueurs,...

Un régal.

2. Eclipse

Prévoyez une grande table pour Eclipse. Non, encore plus grande, celle que vous utilisez pour jouer à Descent première édition ou Railroad Tycoon, on va visiter la galaxie !

Dans Eclipse, vous commencez tout seul dans votre secteur galactique de départ, avec des vaisseaux poussifs. Mais comme tout bon expansionniste qui se respecte et qui sait que s'il ne va pas visiter ses voisins, ceux-ci viendront de toute façon, vous allez utiliser ces vaisseaux poussifs pour explorer les alentours, trouver des vaisseaux anciens, trouver des planètes à coloniser.

Grâce à vos ressources judicieusement utilisées, vous allez découvrir de nouvelles technologies pour aller plus vite, plus loin, avec de plus gros vaisseaux,... Vous pourrez former des alliances, la jouer conquérante ou dissuasif. Vous spécialiser dans la technologie, prendre le centre de la galaxie,...

Eclipse n'est pas un jeu complexe, même si les règles sont longues à expliquer et le matériel foisonnant. Une fois dedans, ça tourne vraiment très bien. Ce qui tourne très bien aussi, ce sont les neurones qui n'auront de cesse de planifier même lorsque ce ne sera pas votre tour.

Avec une première petite extension sous forme de super nova suivi d'une plus grosse extension avec plusieurs choses dedans et permettant de jouer à 8 (ouch !), ce jeu n'est pas près de lasser.

3. Dominion

Ma première rencontre avec Dominion, l'année de sa sortie, m'avait laissée sur un sentiment assez mitigée. J'avais joué une partie avec des joueurs connaissant déjà bien le jeu et j'ai eu l'impression de ne rien pouvoir faire, de ne rien comprendre. Le thème n'étant pas là pour prêter main forte, je sentais bien une mécanique sympathique, mais un goût amer.

Je m'étais plutôt orienté vers Thunderstone, dont le thème est plus présent et qui était dans le top 5 l'année dernière.

Mais depuis, j'y suis revenu. J'ai un peu fait le tour de Thunderstone (même si je n'ai pas essayé certaines des variantes qui relancent le jeu) mais joué, joué et rejoué à Dominion.

4. Troyes

Un jeu où l'on lance des dés mais pas si hasardeux que ça. Ça valait le coup de découvrir. De plus, l'ambiance moyen-âge soutenue par un graphisme impeccable et de circonstance est très bien rendue. J'aime beaucoup.

À Troyes, on va pouvoir agir sur les trois corps de la population : nobles, clergé et tiers-état. Les dés que l'on lance vont déterminer ce qu'on pourra en faire. Mais ces dés pourront être achetés par les autres joueurs (et nous pourrons acheter les leurs).

De plus, une phase semi-coopérative oblige à dépenser des dés sous peine de sanctions généralisées (qui peuvent cependant être plus pénibles pour les autres joueurs que pour soi).

Troyes est un jeu où le hasard est présent et où il doit être maîtrisé : soit en adaptant sa stratégie, soit en achetant les dés manquant aux autres joueurs, tout en veillant à minimiser l'intérêt des dés que les autres joueurs pourraient nous acheter.

Un petit objectif secret par dessus tout pour le suspens du score final, et voilà un jeu très prenant.

5. Horreur à Arkham

Toujours présent, ce jeu tentaculaire promet encore de belles aventures. Cette année, nous nous sommes lancées dans de nouvelles extensions pour un peu de surprise. Mais nous sommes toujours loin d'en avoir vu le bout.

Son passage de la première à la cinquième place vient surtout du fait que c'est un jeu que l'on ne peut pas sortir tout le temps, même Eclipse est plus léger.

Les sortants

Beaucoup de changements dans cette catégorie. À vrai dire, il n'y a aucun jeu identique à ceux de l'année dernière. C'est normal, les joueurs aguerris varient les plaisirs. Et vu que ces jeux demandent plus d'investissement, j'y joue moins souvent et avec moins d'occasions de réunir les bonnes personnes.

Je n'ai pas mis King of Tokyo dans cette section cette année, et il est à la 9ième position en catégorie Famille. En effet, j'ai pu y jouer avec des publics variés et la simplicité des règles ainsi qu'un thème pas si geek que ça me fait le changer de catégorie.

Thunderstone a chuté en 34ième position. Comme je le disais juste avant, je pense avoir fait le tour du jeu et j'ai bien peur que les extensions n'y feront rien. Quitte à jouer à ce type de jeu, je préfère sortir Dominion.

Quant à Automobile et String Railways, malheureusement, je n'ai pas eu l'occasion d'y jouer en 2012, à mon grand regret.

Avec mon fils

Mon fils à maintenant 5 ans passé, ce qui ouvre d'autres horizons de jeu, tout en gardant certains classiques.

1. Strike!

Voir au-dessus. Strike! fonctionne vraiment bien, même pour les plus jeunes qui, même s'ils n'ont pas la petite partie stratégique, n'ont pas plus ni moins de chance que les autres. Et lancer des dés, c'est toujours amusant.

2. Les P'tites Locos

Un jeu de petits chevaux amélioré, très amélioré. Et au matériel vraiment très joli.

Les petits chevaux est un jeu interminable. Dans les P'tites Locos, on doit aussi amener une série de pièces vers une arrivée après un parcours, avec risque de se faire pousser par les autres joueurs. Mais le jeu amène plusieurs accélérateurs : tout d'abord, la possibilité de pousser les autres locos avec celle que l'on déplace. Celles des autres, pour les faire dérailler, mais aussi les siennes, pour optimiser son placement.

Un autre accélérateur est la présente de parties de voies ferrés qui se déplacent à chaque tour. En étant au bon endroit au bon moment, on peut se retrouver en très bonne position pour terminer le parcours rapidement. Si on n'y prend pas garde par contre,...

Il existe une règle optionnelle que je trouve indispensable sous la forme d'un pion d'équilibrage : si une de nos locos déraille et revient donc à son point de départ, un pion est gagné et pourra être dépensé dans un tour ultérieur pour manipuler le tirage du dé qui décide du déplacement des morceaux de voies ferrés.

Cela ajoute à celui qui doit recommencer une possibilité d'ajouter un cran de tactique supplémentaire.

Seul bémol : les parties peuvent quand même durer un peu et à 5 ans, l'attention n'est pas forcément au rendez-vous à chaque partie. À sortir uniquement dans les bons jours.

3. Klack!

Klack est un jeu où il faut être attentif, avoir des réflexes et en plus manipuler des pièces aimantées qui font "klack".

Il faut retrouver parmi des pièces disposées sur la table (et qui font klack) celles qui répondent à des caractéristiques d'un lancé de dé.

Ce n'est pas très original, mais c'est rapide, amusant, tout public et ça fait klack.

4. Trésor de la Momie

Des archéologues en herbe vont pouvoir choisir parmi des piles de trésors ceux qui correspondent à des lancés de dés consécutifs sur une base de yams (3 lancés, on écarte ceux qui nous intéressent). Ces trésors qui sont inscrits sur des tuiles aux formes diverses doivent ensuite être placés sur un plateau personnel de façon à ce que ce plateau soit entièrement recouvert à la fin de la parte. Il faut donc optimiser son placement.

Le Trésor de la Momie est un jeu avec deux mécaniques en une, simple, rapide mais qui nécessite une intuition des probabilités et de la prise de risque. Pas si évident pour les plus jeunes, qui s'en sortent quand même bien.

5. Le Petit Poucet

Il fallait bien un jeu de mémoire dans ce top 5... Il y avait Pique Plume l'année dernière, mais cette année, on quitte la basse-cour pour se rendre dans une forêt sombre où habite en ogre et d'où des enfants doivent s'enfuir.

Le Petit Poucet reprend les éléments du conte : la forêt, l'ogre, les bottes de sept lieues, un grand arbre pour se repérer.

Chacun son tour, un joueur va demander aux autres joueurs, un par un, de retourner des endroits dessinés sur des tuiles cachées. Ces endroits lui sont dictés par une série de cartes tirées au hasard.

Que l'un se trompe, et l'ogre se rapproche. Si trois endroits sont trouvés sans erreur, et les enfants s'avancent dans la forêt. Mais en s'avançant, de nouveaux endroits apparaissent.

Attention aussi aux loups, qui ont la fâcheuse tendance de se déplacer dans la forêt, perturbant l'agencement des tuiles face cachées.

Le Petit Poucet est un jeu coopératif. Pour une fois, un memory n'est pas une compétition et la mémoire de tous devra être mise à l'épreuve. Le déplacement des loups rend le jeu aussi difficile pour les enfants que pour les parents. Et si jamais vous avez une mémoire d'éléphant mêlée à quelques astuces de jeu le rendant plus facile, il existe quelques variantes qui vous rendront la tâche plus ardue.

Les sortants

La encore, une tableau entièrement changé depuis l'année dernière. Crôa, comme indiqué précédemment, n'a pas eu l'honneur de notre table de jeu en 2011, Labyrinthe non plus. Ramses II est 17ième, probablement à cause d'une petite lassitude pour un jeu qui est sorti de très nombreuses fois. Qwirkle 16ième probablement pour suivre Ramses II. Et Pique Plume 10ième car légèrement détrôné par le Petit Poucet.

À deux

Dans cette catégorie, on trouve des jeux qui sont de la catégorie aguerris, mais qui sont spécialisés sur le jeu à deux (ou qui fonctionnent très bien dans cette configuration).

1. A Few Acres of Snow

Les britanniques et les français vont s'affronter dans la neige du Québec en posant des cartes permettant des actions. À la fois une sorte de wargame card-driven et deckbuilding (que de termes anglais !), a Few Acres of Snow est une lutte tendue ou il ne faut pas être trop gourmand sans se laisser marcher sur les pieds.

En effet, les ressources sont rares, les cartes qui permettent des actions arrivent quand elles arrivent. Il faut donc jongler avec plusieurs possibilités tactiques pour arriver à grignoter les points qui mèneront à la victoire.

2. Dominion

Ce jeu est déjà présent dans le top aguerris. Il l'est ici aussi car il tourne bien aussi à deux joueurs, avec une autre façon de jouer, certaines cartes se comportant différemment en fonction de nombre de joueurs autour de la table.

3. Summoner Wars

Un jeu de figurines... sans figurines. Et sur une grille, certes. Dans Summoner Wars, deux factions s'affrontent et chacune doit éliminer l'invocateur adverse. Le joueur peut invoquer de nouvelles créatures ou lancer des sorts en fonction de cartes qu'il a au préalable défaussées ou en fonction des pertes faites à l'adversaire.

Le système est bien trouvé, le jeu agréable et fluide, les possibilités nombreuses. Ce qui est extrêmement bien réussi et qui l'est souvent bien moins dans un jeu de ce type, c'est l'équilibre des différentes factions tout en les gardant très diverses, très typées.

Une réussite. À noter que le jeu peu aussi se jouer à deux contre deux.

4. Magic: The Gathering

Un vénérable de retour. Je me suis laissé convaincre de rejouer en 2012 à ce jeu. Cela faisait bien longtemps que je n'y avais pas joué, et à la vue rétrospective de l'extrême longévité de ce jeu, on peut dire que je m'étais arrêté peu après sa naissance.

J'y jetais un œil de temps en temps, j'ai fais une ou deux parties par-ci par-là avec un deck que je n'avais pas construit moi-même.

J'ai redécouvert un jeu qui est toujours aussi plaisant, aux mécaniques huilées qui offrent de multiples jeux en un : la partie en elle-même bien entendu, mais la construction de deck sous ses différents formats, dont le draft, forme à lui-même un meta-jeu.

Bien entendu, la machine marketing de Wizards est elle aussi parfaitement huilée.

5. Bonbons

Après ces poids lourds, un peu de sucrerie. Bonbons est un jeu de mémoire qui varie un peu du jeu de « memory » classique. Dans Bonbons, les paires se font entre une grille de cartes retournées et des tuiles rondes dont vous devez vous débarrasser (cachées elles-aussi).

C'est une compétition, et il est aussi possible d'aller prendre des bonbons chez vos adversaires si vous vous souvenez mieux qu'eux des tuiles qu'ils possèdent.

Le thème et la boite ajoutent au plaisir du jeu.

Les sortants

Je n'ai pas réussi a jouer à Stronghold en 2012, malheureusement. Le jeu intimide un peu et les règles sont un peu longues à expliquer à un nouveau joueur. Du coup, on choisi autre chose.

Gosu non plus, pas de parties. Ce jeu aussi demande beaucoup d'investissements.

Can't Stop est neuvième. Toujours plaisant à sortir, c'est un jeu dont j'ai quand même fait le tour.

Pour 7 Wonders, après un an et demi de frénésie, le soufflet est tombé. L’extension Cities n'a pas reboosté mon nombre de parties... à vrai dire je n'y ai toujours pas joué. Mais je ne refuserai pas une partie.

Seul

Il n'y a que trois jeux dans cette catégorie. Contrairement à l'année dernière, ce n'est pas spécifiquement une limite que je me suis donné, mais uniquement car je n'ai joué qu'à trois jeux de ce type.

1. Vendredi

Premier l'année dernière, toujours premier. C'est le petit jeu que je sors de temps en temps. Les règles restent bien en tête, probablement grâce au matériel très bien pensé. Il est facile à installer. Et même en connaissant les ficelles du jeu, surtout en n'y jouant que de temps en temps, il reste un challenge sympathique.

2. Space Hulk: Death Angel

Ce jeu à plusieurs qui peut se jouer à un est lui aussi un défi intéressant. Deux petites extensions ont permis de le renouveler (deux autres sont sorties, mais je les ai manquées).

Cela reste un jeu difficile où il faut avoir pas mal de chance.

3. Equilibrion

La « suite » d'Onirim, en quelque sorte. Là où Onirim m'avait bien accroché par son univers et sa mécanique, Equilibrion m'a moins convaincu.

J'y reviendrai, ne serait-ce parce que je n'ai jamais gagné une seule partie !

Le sortant

Onirim est le seul sortant, remplacé par Equilibrion. J'ai joué à l'un, pas à l'autre. Les deux restent des expériences intéressantes.

My first (near) submission to Ludum Dare

Mokona — Sat, 19 Jan 2013 11:52:00 +0100

I had never participated to Ludum Dare. Sometimes because of lack of inspiration, very often because of lack of time, sometimes because when I noticed that the jam had began, it was already ended. For Ludum Dare 25 that was organized last month, I was aware of it just some hours after the launch. The theme was inspiring and I also had a funny (at least in my opinion) idea.

(this post is an english translation of the original post here).

But as it's often the case, I also had a week-end with very little time for this activity. Even in the Jam category, which is specifically organized for those on who the "real life" as un impact, which is a day longer and smoother rules, it felt like it was too short for me.

So I worked a bit the subject in my head, but after 24 hours without having the chance to really concentrate and produce something, I abandoned the idea to enter the jam.

Meanwhile, I was looking at what Ebene was doing after she announced her entry on a well known social network.

On Sunday evening, she announced that the developer she found for the project wouldn't be able to finish it. So I've looked closely to what had already been done in terms of Game Design and Graphics. I liked it. On the programming side, it felt it was doable in a week-end of time for someone who can really concentrate. I thought I would be able to found the same number of hours in a week time.

So I told Ebene I'd do what I can. No guaranty. On my side, clean my Javascript and HTML skills on a real project is great for improving myself. So, let's go.

After a week, the game implementation is at a correct level. Some added hours the next week have been added to smooth the rough edges.

In the post-mortem tradition, I'll answer next two questions : what can I improve and what went well?

What can I improve?

Javascript

My former experiences had already given me the taste of it. This is not a surprise to me that language was considered badly before the creation of AJAX then HTML5. Iterations are quick (add a function, reload the page,...) but the number of traps in this language slowed me a lot at the beginning, while I was remembering them.

While developing, stupid mistakes went scarcer but never completely gone.

I was on the run without too much possibility of stopping to build myself a comfortable environment. But at the end of the development, I searched for static analysis programs like "jhlint". This allowed me to improve a couple of things, but that would have been really interesting from the beginning of the development to avoid a test when a file has syntax error and is just not loaded into the browser.

My conclusion is that Javascript really needs a toolchain to continuously verify the obvious mistakes. Most of the tools I've tested are heavy to launch, which decrease the raw iteration time, while maybe improving the quality in the long run.

Another way of study would be to study languages build upon Javascript, like CoffeeScript or Dart.

Quality tools

Static analysis or test framework are tools I cannot program without in my daily professional environment. As I didn't know them enough for this project to rely on them, I didn't use any.

Before starting a new session of this kind, I must have found, tested and almost mastered such tools for the Javascript world. These are great time improver and time is a precious resource.

Deployment / Collaboration

We were two on the project. Ebene was producing the Game Design document, the graphic resources, the HTML integrations and the game data. All these data were available on a web server for me to fetch.

On my side, I was providing the zip archive extracted from a Mercurial depot, containing the working (most of the time) game.

The steps for me were:

- updating the new data with wget when an update was available - data copy on my depot - comparing the updates (mostly the HTML/CSS files) and manually update the in the final integration files. - export of game data to the file format used by the program (OSD to JSON) - verify / submit

Then, after a session of work on an improvement:

- archive creation - send the archive by sftp to a HTTP served depot - tell about the update

These are a lot of manual operation that should be automated. What I see for improvements:

- work on a commoin depot; not a must have, but really interesting - for an HTML game, a better integration process by better thinking how to fetch the new page updates - automated export of data - continuous build system with static analysis and deployment.

What went well?

1. A pretty well detailed game design document and a function first version of the game data. Thanks to Ebene for that. Apart from some written questions on some points, I was able to go fast with a good idea of what would the game look like, even if I really discovered it while programming it.

2. Le platform choice. Even with what I just said on Javascript, using scripted HTML is good for this kind of game.

A test editor, a browser with developer tools (I've used Firefox + Firebug) are ok. The few data needed by the game allowed to start quickly and work by little iterations.

3. Development loop

The development loop I've globally followed was: choice for a missing feature, feature prototype, writting the complete feature, cleaning.

Regularly cleaning the code avoided too much technical debts, even while missing quality tools.

Even on small project, the technical debt can quickly rise and crush any speed in your programming. And what comes with it this decrease in speed is the rise of frustration because of bugs.

This also allowed me to separate the responsibilities in the code. Mainly the game logic from the HTML integration.

4. Developing Time

Because I wanted to know if it was really possible for a dedicated guy to achieve the same amount of work during a game jam, I've tracked the number of hours on the project for the programming part.

The "Beta" level for the game (working game with a few minor bugs) took my around 20 hours, 5 of them really dedicated and without distraction.

I guess that for someone with a good environment during the event would have spend 10 to 15 hours. Fair enough for a game jam.

After the beta version, little improvements and bug fixes took me something around 2 to 3 hours spread in a week long period.

Conclusion

This was a really interesting experience and the result is pleasing. I've improved my skills in Javascript + HTML on a real project with new ideas to improve the way I work. My personal objective is to improve on my productivity to get the most of those few little time period I can spend on hobby programming.

And the game? It's here (for a better experience, switch to full screen with, probably, the F11 key)

You can also read: the post presenting the game, explanations, game design and much more or the previous post.

Deux semaines avec Dart

Mokona — Wed, 16 Jan 2013 22:00:00 +0100

Suite à mon expérience sur Goldkeeper, je me suis orienté vers l'étude de Dart. Après deux semaines de découverte, de tatonnement et d'implémentation d'un petit jeu, voici une première impression.

Tout d'abord, Dart est plus qu'un langage de programmation, c'est un environnement assez complet avec son langage, sa bibliothèque standard, son éditeur, son debuggeur, ses outils,... Comme c'est encore en plein développement, ça bouge pas mal. Mais c'est très acceptable pour construire quelque chose.

Les outils

Avant de parler du langage, je vais faire un tour par les outils fournis. Le premier d'entre eux est l'éditeur. Bonne chose, il est basé sur Eclipse ^[1]. Environnement connu, complet, fonctionnel. Du mauvais côté, par contre, plutôt qu'un plugin/view ajouté à un Eclipse de base, c'est un Eclipse très allégé. Et donc, par exemple, pas de support de gestionnaire de version, pas possible d'ajouter ses propres plugins préférés.

Je pense que c'est un choix délibéré pour éviter d'avoir à faire du support sur une multitudes de versions différentes.

(Mise à jour : en fait, il existe un plugin officiel Eclipse et un pour IntelliJ. Je n'avais pas vu.).

L'éditeur offre en plus une analyse statique. Pour le moment, je n'ai pas vu de l'analyse très poussée, mais l'éditeur analyse au moins les erreurs de base au niveau de la syntaxe et des types.

Dartium, la version de Chromium avec machine virtuelle Dart intégrée est lancée directement depuis l'éditeur, qui peut récupérer le log.

Je n'ai pas utilisé le debuggeur intégré pour le moment. Non pas que je n'ai pas besoin de debuggeur, mais que j'ai utilisé celui de Dartium directement, ce qui est plus facile pour un debug d'application Web.

Tout cela donne une vitesse d'itération très correcte... correcte, mais pas exceptionnelle. J'y arrive.

Dart vs. Javascript

L'un des objectifs de Dart est d'offrir un environnement de programmation dans le monde Javascript en apportant de la rigueur, en évitant les erreurs de design de Javascript et en apportant des facilités.

Forcément, tout cela vient avec son coût. D'après les études de performances disponible sur le site officiel, Dart dans sa VM est plus rapide que JS dans V8. Par contre, Dart traduit en JS est plus lent. Je n'ai pas encore vu cette partie, et le jeu que je développe n'a pas de problème de performances.

Par contre, l'application en Dart démarre beaucoup plus lentement qu'une application pure Javascript. Probablement que l'initialisation de l'environnement Dart est plus coûteux, mais je ne sais pas exactement.

Cela ralenti la vitesse d'itération, certes. Mais d'un autre côté, la rigueur du langage évite beaucoup d'erreurs sournoises faites lors d'un développement en Javascript et qui sont sources de ralentissement aussi. Au final, je pense qu'on s'y retrouve. C'est un peu plus lent, mais on lance moins "pour rien".

Au niveau des lourdeurs, lorsque l'on traduit du Dart en Javascript et que l'on regarde le résultat sur un simple "Hello World", on constate que Dart amène beaucoup de choses. Le coût supplémentaire est très probablement amorti sur une application réelle, tout comme lors de l'utilisation d'un toolkit en Javascript. C'est à garder en tête : si vous n'avez que deux trois broutilles à faire dans un navigateur, aujourd'hui, restez en Javascript pur. Si vous développez une application complète, Dart est un candidat.

Le langage

Dart, c'est un peu de Javascript, un soupçon de C#, un pincée de Python, une cuillerée de jQuery,... C'est assumé. Le but étant d'offrir un langage à la syntaxe sans surprise (sauf si vous êtes spécialisé en Haskell).

De Javascript, il hérite la majeur partie de la syntaxe en enlevant toutes les surprises (les bêtises ?) de Javascript. Par exemple, la gestion de la portée est plus naturelle. Pas besoin non plus de contorsions pour essayer de cloisonner ses espaces de nom.

Les fonctions sont des objets de premier ordre, avec fermeture. Les maps et les tableaux sont là, implémentant une interface de type "Collection".

Du C#, on retrouve une syntaxe simplifiée pour les fonctions retournant une expression (utilisation de l'opération =>), des getters et setters de propriétés. De jQuery, on retrouve la fonction de requête dans le DOM. Et de Python, le préfixe de tiret bas pour notifier le caractère privé d'un symbole.

Au niveau du typage, Dart offre la possibilité d'annoter les symboles. Le langage en lui-même est aussi peu typé que Javascript et peut se contenter de définition via 'var'. Cependant, si vous utilisez des noms de types (de base ou de classe), alors Dart, via son éditeur, pourra vérifier les types et réagir en conséquence. Le langage offre aussi de vraies constantes.

Objets

Dart a un modèle objet là encore sans trop de surprise. Les classes peuvent implémenter des interfaces, étendre d'autres classes, être abstraites, être génériques,... On est dans du connu, et c'est agréable.

Petite chose chose étonnante, comme tout est objet et que la valeur d'un objet par défaut est null, toutes les valeurs par défaut est null. Écrire int i; déclare i et l'initialise à null.

La déclaration des constructeurs propose des simplifications syntaxiques pour des cas courants (MaClass(this.x); suffit à implémenter un constructeur initialisant le membre x avec son seul paramètre) et offre aussi une syntaxe pour les factories (un constructeur qui peut renvoyer autre chose que le type de sa propre classe).

Javascript nous a habitué à des appels de fonctions en cascade. Dart ajoute un opérateur intéressant, le double point (..). Cet opérateur peut enchaîner les actions sur les membres d'un objet. Plutôt pratique pour éviter des répétitions inutiles et éviter les copier/coller non maintenus.

Fonctions

Tout comme Javascript, Dart a un côté pseudo fonctionnel. Pseudo car, à part les fonctions comme objet de premier ordre et les fermetures, on est loin d'un Lisp ou dans Caml. Dart n'innove pas vraiment mais ajoute quelques fonctionnalités classiques : paramètres optionnels et paramètres nommés.

Grâce à une série de fonctions de traitement sur les collections, on pourrait être tenté de verser dans la programmation fonctionnelle. Cependant, la bibliothèque standard accroche un peu : cela manque de vision globale fonctionnel, beaucoup de méthodes et fonctions sont des procédures qui ne retournent pas de valeur. Rien de rédhibitoire, mais c'est dans ces coins là que l'on sent que la peinture est encore fraîche.

De plus, le manque de protection de style pure en D n'incite pas à faire confiance aux fonctions. Le langage n'offre pas de système pour prévenir les effets de bord.

Plus gênant par contre, il n'y a pas de constructeur de liste (list comprehension). Écrire les listes « à l'ancienne » dans un langage de ce type, ça donne une impression de manque. Je n'irai pas jusqu'à dire qu'il manque un système aussi puissant que Linq, mais presque. On verra bien les développements futurs.

Qualité

Une application Dart peut s'exécuter en mode production ou en mode debug. En mode debug, le langage supporte les assertions.

Dart a aussi une bibliothèque de tests unitaires et de « mock objects ». Les tests sont déclarés via des fonctions et il faut les appeler explicitement. C'est un peu dommage. Je n'ai pas encore plongé dans le code, mais j'ai l'impression que les tests ne sont pas lancé dans une vraie isolation. Il faut donc faire attention à bien nettoyer à la fin d'un test et ne rien retenir dans des objets potentiellement encore actifs, le garbage collector n'est pas forcément encore passé.

Plus complexe, le DOM n'étant pas réinitialisé à la fin d'un test, c'est à gérer manuellement.

Autre problème, où placer les tests ? S'ils sont placés en tant que part of de la bibliothèque à tester, on peut tester les fonctions privées. Mais les tests sont alors transportés avec le code de la bibliothèque. Si les tests sont en dehors de la bibliothèque, on ne peut plus tester les fonctions privées. Autant tester des fonctions privées à une classe est une mauvaise idée, autant ne pas pouvoir tester des fonctions privées à une bibliothèque est plus gênant.

Je continuerai à regarder l'existant. Apprendre un langage, c'est aussi voir comment sont faites les choses de la bonne manière.

Conclusion temporaire

Dart est une bonne promesse. Je n'ai pas encore le niveau nécessaire pour être vraiment à l'aise. Je regarde encore pas mal la documentation et je dois chercher des exemples de code pour cerner la philosophie d'ensemble. Cependant, c'est assez clair pour progresser rapidement.

Je vais donc continuer mon aventure dans le monde de Dart.

Note

[1] voir un précédent billet à ce propos.

GameDaba : série sur l'affichage

Mokona — Fri, 11 Jan 2013 13:00:00 +0100

J'ai commencé sur GameDaba une série d'articles parlant de l'évolution de l'affichage sur les ordinateurs, plutôt orienté affichage pour les jeux, et non exhaustif.

À vrai dire, j'ai commencé à écrire ça en septembre dernier je crois. Je publie aujourd'hui une première partie. J'ai quelques pistes pour la seconde partie mais je dois d'abord faire un peu de recherche dans mes souvenirs et les confronter à des ressources techniques. Du coup, pour quand la deuxième partie ? On verra.

En attendant, au début était le pixel...

Combien d'éditeurs de code utilisez-vous ?

Mokona — Thu, 03 Jan 2013 23:57:00 +0100

Visual Studio, PyCharm, IntelliJ, PyDev, vim, Eclipse, Netbeans,... vous pouvez en aimer certains, ne pas en supporter d'autres, mais au final, il y en a un que vous utilisez par défaut lorsque vous avez le choix.

L'ennui, c'est quand vous n'avez pas le choix, et que ce que l'on vous impose n'a aucun sens.

Sur des plateformes plus confidentielles, le constructeur fourni souvent une suite d'outils pour développer sur son matériel. Un ensemble de bibliothèques, un compilateur, des outils de contrôle et j'en passe.

C'est bien, et c'est là-dessus qu'ils ont quelque chose à apporter. Ils connaissent leur matériel.

Là où je ne comprends plus, c'est lorsque ce même constructeur s'échine à proposer des outils d'édition de code, ou des frontends graphiques de debug. Faire une interface, c'est long, c'est coûteux, ce n'est généralement pas le métier d'un constructeur ni de ses développeurs de software spécialisé.

C'est avec une mine déconfite que chaque jour, vous vous retrouvez à utiliser un logiciel aux raccourcis exotiques, à l'intégration hésitante et parfois à la stabilité douteuse. Quand ce ne sont pas certaines fonctionnalités comme le copier/coller depuis une fenêtre de log particulière qui n'est tout simplement pas implémentée.

Alors, s'il vous plaît, s'il vous arrive d'être dans le cas où vous devez fournir une interface d'édition de code, de debug, de gestion de ressources, de construction de diagrammes, avant de vous lancer dans ce travail ingrat qui consiste à tout réécrire de zéro, regardez comment utiliser les services qu'offrent, par exemple Eclipse ou Netbeans, voire même Visual Studio si vous vous limitez à un OS.

Faites comme l'éditeur de jMonkeyEngine (Netbeans), ou bien l'éditeur de [Dart (Eclipse).

Et merci d'avance de la part de tous les développeurs.

Nouveau thème 2013

Mokona — Wed, 02 Jan 2013 23:54:00 +0100

Ouf, voilà. Cela faisait un bout de temps que je voulais changer le thème d'affichage du blog. Voilà qui est fait. Je l'ai voulu plus clair, pour plus de lisibilité, en essayant de ne pas être trop austère.

Le thème précédent, avec lequel j'avais rompu avec le traditionnel bleu du site, ne me plaisait pas vraiment au final, je trouve qu'il ne facilitait pas la lecture.

Il reste deux trois détails à régler, dont un style d'impression pour qui voudrait imprimer l'un de mes billets, mais dans l'ensemble, je suis satisfait.

Ma première (presque) participation au Ludum Dare

Mokona — Tue, 01 Jan 2013 23:38:00 +0100

Je n'ai jamais participé à un Ludum Dare. Parfois par manque d'inspiration, très souvent par manque de temps, parfois tout simplement parce que le temps que je m'aperçoive que ça avait commencé, c'était déjà terminé. Pour le Ludum Dare 25 qui vient d'être organisé, j'ai été au courant à peine quelques heures après le lancement, le thème m'inspirait et j'avais même une idée amusante (du moins j'imagine).

Mais comme souvent, j'avais aussi un week-end qui ne laisse pas de temps à cette activité. Même le Jam, catégorie spécifiquement prévue pour ceux que la vie réelle impactent et qui laisse un jour le plus et des règles plus libres, me semblait trop restreint.

J'ai donc un peu travaillé le sujet dans ma tête et, au bout de 24h sans avoir eu le loisir de vraiment me poser sur le sujet, j'ai abandonné l'idée de participer.

Cependant, je regarde d'un œil ce que lance Ebene qui annonce sa participation sur un réseau social bien connu.

Le dimanche soir, elle annonce que son développeur ne pourra pas terminer le projet. Du coup, je regarde d'un peu plus près ce qui a déjà été fait côté game design et graphismes. Ça me plaît. Et côté programmation, ça me semble faisable en un week-end pour quelqu'un qui s'y atèle et et je pense pouvoir trouver en une semaine le temps correspondant.

Je propose donc à Ebene de faire ce que je peux. Pas de garantie. De mon côté, dépoussiérer mon Javascript + HTML sur un vrai projet me paraît enrichissant. Donc go.

Au bout d'une semaine, l'implémentation est à un niveau correct. Quelques heures supplémentaires seront prises sur la semaine suivante pour peaufiner un peu.

Dans la tradition des post-mortems, je vais répondre à deux questions : qu'est-ce que je pourrais améliorer et qu'est-ce qui s'est bien passé ?

Qu'est-ce que je pourrais améliorer ?

Javascript

Mes précédentes expériences m'avaient déjà donné un goût de la chose. Ce n'est pas pour rien que ce langage, avant d'être popularisé par l'arrivée d'AJAX puis confirmé par HTML5, était très mal considéré. Si les itérations sont rapides (ajout du fonction, rechargement de la page,...), les nombreux pièges m'ont beaucoup ralentis au début, le temps que je me les remémore.

Au fil du développement, les erreurs se sont atténuées, mais pas effacées complètement.

J'étais sur ma lancée et je ne pouvais pas trop m'arrêter pour me faire un environnement confortable. Cependant, sur la fin du développement, je suis allé fouiller dans les programmes d'analyses statiques de type jhlint. Cela m'a permis d'améliorer deux trois petites choses, mais ça aurait été surtout intéressant pendant le développement pour éviter un test alors qu'un des fichiers contient une erreur de syntaxe.

Au final, Javascript a besoin d'une toolchain qui puisse vérifier en continue les erreurs évidentes. La plupart des outils que j'ai pu tester depuis sont cependant assez lourds au lancement, ce qui atténue la force de l'environnement en ce qui concerne son temps d'itération.

L'autre piste que je peux étudier, c'est d'utiliser des langages construits au dessus de Javascript, comme CoffeeScript ou Dart.

Outils garde-fou

Analyse statique ou environnement de tests, des outils que je trouve indispensables professionnellement au quotidien et dont j'ai du me passer pour cette exercice. En effet, je n'en connaissais pas, ou en tout cas pas assez pour me reposer dessus.

Avant de démarrer une prochaine session de ce type, il me faut tout ça en place et à peu près maîtrisé. Ce sont de grands vecteurs de gains de temps et le temps, c'est une ressource très précieuse.

Distribution / Collaboration

Nous étions deux sur le sujet. Ebene fournissant le document de Game Design, les ressources graphiques, les intégrations HTML et les données du jeu. Toutes ces données étaient disponibles via HTTP.

De mon côté, je fournissais irrégulièrement une archive de mon dépôt Mercurial avec le jeu fonctionnel.

Mes opérations étaient donc :

- aspiration différentielle du site via wget lorsqu'une mise à jour était signalée. - copie des données voulues sur mon dépôt. - comparaison des modifications (surtout sur les fichiers HTML/CSS) et report dans le fichier d'intégration finale. - export des données de jeu vers le format utilisé par le programme. - vérification et submit.

Puis, après une séance de travail sur une amélioration :

- création de l'archive. - envoi de l'archive via sftp sur un dépôt servi en HTTP. - signalement de la mise à jour.

Ce sont beaucoup de manipulations manuelles qui devraient être automatisées. Ce que je vois en améliorations :

- travailler sur un dépôt commun, pas essentiel, mais intéressant. - pour un jeu en HTML, mieux réussir l'intégration en prévoyant mieux la manière de récupérer les pages. - automatisation de l'export des données. - système de build en continu avec analyse statique et création automatique d'une archive et/ou d'un déploiement.

Qu'est-ce qui s'est bien passé ?

1. Un game design bien détaillé / une première version des données fonctionnelles : merci à Ebene pour ça. Mises à part quelques questions pour éclaircir certains points, j'ai pu avancer vite grâce à une bonne idée de ce que devait être le jeu, même si je l'ai vraiment découvert en l'essayant au fur et à mesure de l'implémentation des fonctionnalités.

2. Le choix de la plateforme. Malgré ce que j'ai pu dire sur Javascript, utiliser du HTML scripté convient très bien pour un jeu de ce type.

Un éditeur de texte, un navigateur avec des outils de développeurs (j'ai utilisé Firefox + Firebug) et voilà. Le peu de données nécessaires au jeu permet de le démarrer rapidement et de travailler par petites itérations.

3. Boucle de développement.

La boucle de développement que j'ai respecté globalement était : choix d'une fonctionnalité manquante, prototypage de la fonctionnalité, écriture de la fonctionnalité, assainissement.

Le fait de régulièrement assainir le programme a évité, malgré l'absence d'utilisation d'outils de vérification de qualité, l'accumulation d'une trop grande dette technique.

Même sur un aussi petit projet, la dette peut rapidement s'envoler et réduire la rapidité de programmation de manière drastique. Avec son corollaire : augmenter la frustration des fonctionnalités bancales.

Cela m'a aussi permis de bien veiller à séparer les différentes responsabilités, principalement la logique du jeu et son intégration HTML.

4. Temps de développement

Afin de vérifier qu'un tel développement était possible pour une personne côté programmation lors du game jam, j'ai tracé le nombres d'heures passées.

L'arrivée à un niveau "beta" (jeu fonctionnel mais avec quelques bugs mineurs) a pris 20h environ, dont 5h dans un vrai état de concentration. L'autre quinzaine d'heure a été passée dans un environnement avec des distractions.

Autrement dit, pour quelqu'un qui bénéficie d'un environnement dédié à la participation à l'event, entre 10 et 15h étaient nécessaires. Largement suffisant pour un game jam.

Après la version beta, les petites améliorations et corrections de bugs ont du prendre deux ou trois heures réparties sur une semaine par petites interventions.

Conclusion

L'expérience était vraiment intéressante et le résultat est plaisant. J'ai pu progresser en Javascript + HTML sur un vrai projet et j'ai de nouvelles pistes pour améliorer ma façon de travailler. Mon défi personnel étant de pouvoir être assez efficace pour profiter au maximum des moments courts dont je dispose.

Et le jeu ? Il est là (pour une meilleure expérience, passez en plein écran avec probablement la touche F11 de votre navigateur).

Mais aussi : le billet de présentation du jeu, les explications, les game design et plus encore, ainsi que le billet précédent.

Gamedaba, un blog qui parle jeux vidéo

Mokona — Wed, 05 Sep 2012 22:47:00 +0200

Un blog qui parle jeux vidéo ? Voilà bien une annonce qui va provoquer un séisme dans l'univers digital. Enfin, quelqu'un se lance dans cet océan bleu et calme du critique de pixel.

Ironique, un peu. Mais j'ai le droit, ou je le prends, car je participe.

Le lancement de GameDaba n'est donc pas vraiment la nouveauté qui fera trembler la rentrée, mais le fait qu'y soient contributeurs une bande de (pour le moment ?) deux potes et moi-même change l'importance que j'y attache. Forcément.

Et si le mieux était de définir une VM ?

Mokona — Fri, 27 Jul 2012 14:11:00 +0200

Du pire au mieux

Il faudrait être aveugle pour ne pas remarquer l'engouement grandissant ces dernières années pour l'utilisation de Javascript dans les navigateurs pour la construction de la partie client d'une application navigateur.

Ce langage qui a sa création a été perçu, avec raison, comme une chose bancale, lente et aux implémentations hasardeuses est devenu en quelques années un langage présent au cœur d'applications très sérieuses. La littérature produite autour de son utilisation est aussi passée de petits livres d'astuces à de vraies livres d'informatique couvrant les meilleures pratiques, les performances ou encore l'architecture logicielle.

C'est que, même si le langage et son environnement était mal définis, mal implémentés, ils se sont révélés composer tout de même le moyen le plus simple de transformer un monde de pages web statiques en une utilisation dynamique plus habituelle dans les applications traditionnelles.

L'ajout de la possibilité d'emmètre des requêtes http depuis l'intérieur d'un programme Javascript client (dans un navigateur) a ouvert la voie à des échanges avec le serveur plus fluides, plus légères et a permis à des armées de départements marketing de manipuler des termes évocateurs comme « cloud » ^[1] ou « webapp ».

Avec son utilisation côté serveur, avec par exemple node.js, et le fait qu'il soit à présent mieux implémenté côté clients, Javascript obtient ses lettres de noblesse. On peut même trouver des environnements pour créer des applications de bureau traditionnelles en Javascript (par exemple Gnome Seed).

Du mieux au pas pire

Pourtant, à quelques modifications près, Javascript a peu bougé. C'est plutôt son environnement qui a été mieux défini et de manière plus uniforme (le DOM par exemple), ou bien grandement amélioré (VM plus performantes, apparition de <canvas>,...) ; ainsi que la maîtrise du langage et les outils disponibles.

À la lecture d'ouvrages ou articles sérieux sur le Javascript, ce qui revient le plus souvent est la nécessité pour fabriquer des applications qui tiennent la route d'avoir recours à des pratiques de programmation rigoureuses appuyées par des outils d'analyse statique et des systèmes de constructions permettant de produire un « exécutable » final.

Les risques du langage étant à présent plutôt bien connus, des outils existent pour les réduire. Par exemple, Google Closure permet d'annoter le code source pour faciliter l'analyse statique. Cependant, la syntaxe en devient assez alourdi, et, étant un outil externe, n'est pas partagée avec d'autres outils d'analyse.

Au final, la communauté a produit de quoi construire des applications robustes sur des bases qui le sont peu. On pourrait rapprocher cela du C, langage très permissif qui, au fil de nombreuses années, a développé un bagage énorme permettant au programmeur attentionné d'être aidé contre ses possibles erreurs d'étourderie.

Langage ou environnement ?

Une autre façon de contourner les lacunes du Javascript en tant que langage (sans prendre en compte son environnement d'éxecution) a été de proposer des langages qui se compilent en Javascript. Coffee Script par exemple produit un exécutable en Javascript et offre des constructions plus sûres en gardant une parentée avec le Javascript.

D'autres initiatives proposent un langage différent dans l'optique d'offrir une alternative dans le domaine d'utilisation de Javascript. Dart par exemple.

Récemment sont aussi apparus des compilateurs pour différents langages de programmation allant du C++ au Caml en passant par Python qui prennent des fichiers sources dans ces langages et produisent un code Javascript équivalent.

Ces différents projets font se poser la question : finalement, est-ce le Javascript qui est au cœur du développement web, ou plutôt son environnement naturel, le navigateur web ?

Avec le développement des capacités des navigateurs, l'arrivée du HTML5 (lui-même associé au développement du Javascript), de WebGL, de leurs stabilisations, de leurs performances accrues, de leurs présence sur de très nombreuses plateforme et de leur connectivité naturelle, on se retrouve avec un environnement d'exécution très agréable au-dessus du système d'exploitation natif.

Cet environnement offre naturellement des capacités d'affichage, une couche réseau, de la sérialisation locale. Malgré certaines limitations, comme le traitement sonore ou certains périphériques d'entrée, l'environnement permet de développer des applications avec assez peu de code.

Le langage de script naturel de ces navigateurs (le défaut pour la balise <script>) étant le Javascript, l'utilisation de l'environnement s'est historiquement fait en Javascript, permettant de développer encore plus l'environnement.

Mais on vient de le voir, l'époque est à présent au contournement des limitations du Javascript. Au niveau des chaînes de fabrication, l'une des dernières étapes avant déploiement est même la diminution du nombre de fichiers de script (voire même la construction d'un fichier unique) et la diminution de leur taille par compactage de code ^[2] et même par compression ^[3].

Une machine virtuelle standardisée

Finalement, ce qui a l'air d'intéresser une bonne partie des développeurs web (voire la majeure partie des développeurs) n'est pas spécifiquement le Javascript, qui est un moyen, mais la possibilité d'utiliser un environnement d'exécution pratique et facile à déployer.

La manière de construire une application web actuellement ressemble tout à fait à une application standard, ou plutôt à une application qui cible une machine virtuelle comme du Java ou du C#. Le résultat de la construction du programme ressemble à du bytecode à ceci près que c'est du Javascript compacté.

Ce qui m'amène à cette question qui est aussi le titre du billet : est-ce qu'il ne vaudrait pas mieux pour les navigateurs offrir l'accès à la machine virtuelle qui est nécessairement présente pour exécuter le Javascript ? Si celle-ci était normalisée et disponible sans passer par la phase d'analyse du Javascript, on aurait alors éviter l'étape maladroite de détournement du Javascript en pseudo bytecode, et différents langages pourraient cibler directement cette machine.

Ce qui n'empêcherait pas les navigateurs de garder la possibilité d'exécuter directement du Javascript. La prise en charge native éviterait de plus l'échec qu'on connu les applets Java.

Notes

[1] même si ce terme est assez vague et permet de couvrir beaucoup plus de sujets

[2] réduction des noms des variables, suppression des espaces inutiles...

[3] en profitant des capacités des navigateurs à décompresser des images ; cet usage est plutôt limité au domaine de la démo actuellement car pas forcément portable et sans feedback utilisateur

Mon top 5 des jeux 2011

Mokona — 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

Mokona — 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

Mokona — 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 !

Mokona — 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

Mokona — 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

Mokona — 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

Mokona — 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

Mokona — 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

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