Tagcon, où comment écrire simplement les templatetags, cong !!

Oui, je sais, je devrais renouveler un peu mon stock de blagues. Parce que mettre des cong à la fin de tout et n’importe quoi, pour singer l’accent marseillais, ça commence à …. Je sais. (j’en profite pour vous rappeler que le 24 et 25 avril, il va y avoir la DjangoCong à Marseille, une super convention fr où ça va parler django, encore et encore).

Et, oui, la django-app du mois de janvier arrive vraiment sur le fil, à quelques heures du dépassement de délai. Mais faudra dire ça au crétin qui a décidé qu’une journée ça ne serait que 24h et qu’il fallait obligatoirement dormir chaque nuit, ou presque … (bordeille comment je vais faire en février moi..)

Enfin, je reste dans les délais, c’est le principal. Et pour le deuxième mois consécutif, je fais une petit entorse au principe de cette catégorie, vue que ce mois-ci, encore une fois, ce n’est pas une vrai django-app que je présente, mais un ‘simple’ module python.

0- Et ça sert à quoi ?

En fait tagcon est ‘inutile’ (donc indispensable vous allez me dire… ne niez pas, je vous ai tous entendu le dire…). Il sert simplement à faciliter l’écriture des templatetags (et surtout des templates tags à argument). On pourrait se dire que c’est assez inutile. Mais en fait, ça permet de gagner un peu de temps et de réduire d’une façon assez intéressante la taille de son code. Donc..

Un petit exemple, tiré de la doc, parce que comme me l’a fait remarquer daks (dont je conseille le blog, qui vient d’arriver dans mes RSS) , ça manque :

from django.contrib.auth.models import User
from django.template import Library
import tagcon

register = Library()

class UserListTag(tagcon.TemplateTag):
limit = tagcon.IntegerArg(default=10)

def render(self, context):
self.resolve(context)
yield "<ul>"
for user in User.objects.all()[:self.args.limit]:
yield "<li>%s</li>" % (user.username,)
yield "</ul>"

1- Où on le trouve, comment on l’installe, tout ça quoi ?

Alors alors, sur le github qui va bien. (une petite remarque qui a rien à voir, je préfère de loin bitbucket à github … et pas juste parce que mercurial c’est mieux que git).

Une fois qu’on a récupérer le package (par fork si on a un compte github ou avec un petit tar.gz), il y a deux façon de l’installer:

un petit python setup.py install
en copiant directement le fichier base.py qui se trouve dans tagcon.tagcon (dans ce cas là on pourra renommer base.py en tagcon.py).

2- La documentation.

Alors là… Il n’y a pas grand chose. Un fichier readme qui donne un petit exemple et c’est tout. Après, il vous faudra lire les tests et le fichier source directement. Ce n’est pas donc super fourni, mais d’un autre coté, vous me direz que le module est tellement simple que ça suffit. Et vous ne seriez pas loin d’avoir raison. Mais bon.

3- En conclusion

Au départ, quand j’ai découvert ce petit module (je crois que je dois, encore une fois, remercier benoitc pour cela), je n’étais vraiment pas convaincu de son utilité. Il me semblait presque inutile et puis un peu restrictif en obligeant à utiliser la fonction render (alors que j’ai plus l’habitude d’enregistrer les fichier template html avec le décorateur inclustion_tag). Mais au final, on se ren compte que ça simplifie pas mal les choses et on y prend rapidement goût.

4- dernier paragraphe complètement HS.

Ma liste de django-app à tester est loin d’être vide (avec entre autre piston, haystack,..) et ça ne risque pas de changer, vu que chaque semaine, je découvre une nouvelle app. Toutefois, j’écris ces billets avant tout pour qu’ils soient utile . Donc, si vous connaissez des app que vous adorez et que vous aimerez faire découvrir à tous. Laissez moi leur nom en commentaire et je m’efforcerais de les tester.

Piratage en blouse blanche (épisode 1)

Voilà le premier épisode de ma contribution à Polar Geek. Je sais, c’est très court. Mais ce n’est que le premier épisode, une petite scène d’ouverture pour présenter les personnages. Et puis c’était histoire de me mettre en jambe, avant d’attaquer les choses sérieuses. J’espère en tout cas que ce premier épisode vous plaira (et les suivants encore plus). Allez hop, place à Polar Geek (j’espère trouver rapidement un nom pour cette histoire) :

Je déteste les matins, et encore plus les lundi matins. Surtout que depuis peu, pour réduire les coûts, j’ai installé mon bureau dans mon petit chez moi. Je ne peux donc même plus rester à trainasser en nuisette le lundi matin. Bon d’accord, je ne mets que des pyjamas. Mais le problème reste le même. Le lundi matin est, j’en suis certaine, le premier des cercles de l’enfer. Une espèce d’avant goût de ce qui attend les méchants. Du coup, je croise les doigts pour avoir le droit de faire la bise à Saint Pierre.

Voilà à peu près les pensées qui me trottaient la tête ce matin là. Toute à ces joyeuses pensées, je regardais le temps passer en discutant sur IRC, d’un sujet hautement important : est-ce qu’il était plus viril de dire «pain au chocolat» ou «chocolatine». Qu’une fille parle de virilité, ce n’est pas commun vous allez me dire. Et vous aurez raison. Mais j’ai tendance à oublier que je suis une fille. Et puis une fille qui vit seule avec ses ordinateurs et des peluches de petits démons ou de pingouins, ce n’est de toute façon pas commun. J’étais donc en train d’occuper mon temps d’une manière très instructive lorsque la sonnette de l’immeuble sonna.

«Oui ?», demandais-je, en essayant d’avoir l’air heureuse de répondre. Je sais, je suis d’une inventivité rare lorsque je parle à d’autres personnes, mais je vous l’ai déjà dit, c’était un lundi matin.
«Je viens voir A. Oscar», me répondit sèchement une voix d’homme, un brin essoufflé.
«Je vous ouvre, c’est au cinquième mais l’ascenseur est en panne», lui répondis-je avec toujours autant d’imagination, tout en lui ouvrant la porte.

Quelques dizaines de marches plus tard, j’entends mon visiteur, qui totalement haletant, frappe à ma porte. Je suis très fière de ma porte. Une belle porte blindée, vert pisseux mais sur laquelle sont collées, en lettres dorées, les mentions «A. Oscar» et juste en dessous «détective informatique». J’ai à chaque fois l’impression, lorsque je rentre chez moi, que je suis dans un vieux polar américain et que lorsque je rentrerais dans mon appartement, Bogart se retournera en me lançant un langoureux t’as de beaux yeux tu sais avant de… Enfin, voilà, j’adore ma porte. Mais revenons à mon visiteur qui entre, tout essoufflé. La quarantaine bien tassée, il détaille mon salon, contemple avec un petit air méprisant ma collection de figurines en vinyle puis me lance «Bonjour, je suis venu voir Monsieur Oscar, pourriez-vous m’annoncer ?».

Tu l’as bien cherché pourriez-vous me dire. Et vous auriez raison. Ce n’était d’ailleurs pas la première fois, loin de là, que l’on me prenait pour la secrétaire de Monsieur Oscar. Pourquoi est-ce que je n’écrivais pas mon prénom en toutes lettres alors, pourriez-vous continuer à me demander. Ne vous méprenez pas, je n’ai pas honte de mon prénom, même si Alana ce n’est pas très commun (que voulez-vous, il doit y avoir peu de petites filles dont le papa admire Alan Turing), j’ai appris à l’aimer mon prénom. Non, il semblerait simplement que la plupart des gens qui pourrait avoir besoin de mes services pensent qu’une fille ne peut pas être compétente. Ce qui m’oblige à ruser. Mais qui du coup m’énerve lorsque l’on me prend pour la secrétaire. Je me rendis d’ailleurs compte que je l’étais, énervée, lorsque je pris conscience que je tapotais machinalement le filtre d’une de mes Lucky Strike contre mon clavier. J’essaie d’arrêter de fumer voyez-vous. Et mon patch de nicotine à moi, c’est de tapoter sans fin le filtre d’une Lucky contre mon clavier. Mais revenons à ce brave homme, que je fais patienter depuis quelques temps maintenant et qui visiblement commence à s’énerver, là debout dans mon salon bureau.

«Excusez-moi Monsieur, une affaire urgente à régler, permettez-moi de me présenter Alana Oscar, détective» (j’adore prononcer ce mot, à ce moment là, ça me donne des petits frissons partout). Je continue, sans lui laisser le temps de me couper. «Non ne vous excusez pas, les gens font souvent l’erreur, mais que voulez-vous, il se trouve que parfois un prénom féminin fait peur quand on parle d’informatique. Mais asseyez-vous et dites moi pourquoi vous êtes venus».

Mon bonhomme, ayant eu le temps de se reprendre son souffle, s’assit dans mes fauteuils décoration Star Wars et lâcha une seule phrase, d’un ton catastrophé. «Nous nous sommes fait pirater». C’est toujours pareil avec les clients, au moindre pépin, c’est la faute aux méchants pirates d’Internet. Aucune autre explication ne leur vient à l’esprit, non, c’est un piratage. J’essayais de cacher mon petit sourire amusé.

«Vous voulez un café pendant que vous me donnerez un peu plus de détails ?».

To be continued…

Types de joueurs et conception d’applications

Je l’ai déjà dit, et je le redirais, il peut être, à mon avis, très interagissant d’utiliser les mécanismes des jeux vidéos pour améliorer l’expérience utilisateur des logiciels non jeux vidéos. Je vais essayer dans ce petit billet de mettre en relation les types de joueurs avec des idées de trucs à intégrer dans les applis.

Le classement de types de joueurs que j’utiliserais est le classement du Bartle Test of Gamer Psychology, classement utilisé dans les MMORPG (et que l’on retrouvera aussi dans toute première partie de manuel du maître de n’importe quel jeu de rôle, avec parfois des noms différents).

Il classe les joueurs suivant une pondération de 4 catégories: achiever, explorer, socializer, killer. La somme des quatres ‘notes’ d’un joueur doit faire 200 et aucune ne peut être supérieure à 100. Vous pouvez donc être le joueur suivant : 55 % killer, 75 % socializer, 20 % achiever et 50 % explorer. Ce doit être, de mémoire, presque mon profil de joueur. Voyons voir un peu plus en détail ce que signifie ces catégories (pour une description précise, je vous renvoie à la très complète page Wikipedia sur le sujet).

1- Les types de joueurs

1.1 Le collectionneur compulsif (aka l’achiever)

Le joueur collectionneur adore par dessus tout… Collectionner. C’est logique. Il aime réussir à avoir tous les succès, même les plus inutiles ou les plus difficile à avoir. Mettez en place un système de badges et il passera ses journées à les traquer et ce jusqu’à avoir la veste qui ressemble à un général de l’armée. Et si vous voulez vraiment lui faire faire nuits blanches sur nuits blanches, prévoyez un système très fourni d’équipement. L’achiever se sentira obligé d’avoir tous les sets possibles d’armes et d’armures, surtout les plus puissants.

1.2 L’Indiana Jones du dimanche (aka l’explorer)

Lui, ce qu’il aime c’est la sensation grisante de la découverte, le frisson de l’exploration, la montée d’adrénaline du mystère. Il passera des nuits blanche à voyager dans l’univers du jeu, parcourant chaque colline, cartographiant chaque grotte, espérant toujours arriver dans une zone de jeu vierge, ou aucun autre joueur n’aura encore mis les pieds.

1.3 Le “putain ferme la, on veut aller nettoyer l’instance, marre des blabla à la taverne”(aka le socializer)

Lui, ce qui l’intéresse, c’est de papoter. De raconter une histoire commune avec d’autres joueurs dans lequel il inclura son personnage. Il aime les titres parce qu’il peut les intégrer dans l’histoire de son personnage. Il adore pouvoir décider de chaque infime détail de son avatar et passera des heures sur le chat de son MMORPG à balancer des emotes et à offrir des tournées dans les tavernes des différentes villes, stations spatiales, bases sous-marines que comporte le jeu.

1.4 Le petit faquin de merde qui vous a lâchement démoli en vous attaquant dans le dos (aka le killer)

Lui, il n’a qu’un but, larder les autres personnages de coups de dagues, épées magiques, balles de snipers, sorts de boule de feu. Ce qui l’intéresse c’est le duel. Le défi de se mesurer à d’autres joueurs et de tenter de les dominer pour pouvoir ensuite crier un ‘haha’ triomphant à son écran que sa malheureuse victime ne verra pas (ce qui a pour effet de le faire passer pour un fou). Suivant les jeux il passera donc de longues heures à s’entrainer pour devenir le meilleur ou de longues heures à chercher le meilleur équipement possible pour être sûr d’écraser ses ‘concurrents’.

2- Et maintenant, je fais quoi avec mon appli là ?

Ok, ok, j’ai compris. Vous voulez savoir à quoi ça sert de savoir de connaître les différents types de joueurs. C’est tout simple, les joueurs qui sont des achievers dans le jeu vidéo, se sont des achievers aussi quand ils utilisent un logiciel quelconque. Donc en intégrant dans ledit logiciel quelconque des concepts qui plaisent aux achievers dans les jeux vidéos, vous leur ferrez plaisir. Et ils utiliseront avec plus de joie votre appli.

2.1 Ce qui plait aux achievers

Là, c’est assez facile. Et ça va presque être de la redite avec mon précédent billet. Les joueurs achievers adorent les système de succès. Un petit système avec des badges suivant les choses qu’il fait et vous l’avez définitivement conquis. Et là soyez malin. Mixez les types de succès. Par exemple, mettez en place un système de succès qui contient :

des succès reliés à ce que font vos utilisateurs (le succès du profil rempli, le succès du tuto d’apprentissage fini, le succès de la lecture de l’aide, etc.),
des succès liés à l’assiduité (le succès des 1 000 heures passées sur l’appli ou des 10 000 cellules de tableur remplies),
des succès inconnus (dans le panneau des succès ils sont notés comme non réussis, mais on ne connait ni leur nom ni les modalités pour les débloquer).

Vous verrez que vos utilisateurs achievers vont adorer.

2.3 Explore ma nouvelle appli

Pour les explorateurs, c’est déjà plus difficile. Après tout, une appli, c’est une appli. Pour les applis lourdes, je n’ai pour l’instant pas d’idées. Pour les applis web par contre, j’ai quelques pistes. En voilà déjà une. Des pages vers du contenu nouveau qui ne se débloquent qu’à certaines heures ou qu’après avoir résolu une énigme ou avoir accomplis certaines actions dans un ordre bien précis. Bien entendu il faut que les utilisateurs soient au courant que ces zones vierges existent et qu’ils aient des pistes pour arriver à y accéder. Mais une mise en pratique d’un tel système, je suis certain que cela tiendra en haleine vos utilisateurs explorateurs.

2.4 Discute avec les autres, soit sociable

Bon alors pour les socializers, rien de plus facile, et puis tout est déjà là. Permettre à vos utilisateurs de discuter entre eux, d’échanger, de commenter. Quelle application web ne le fait pas, aujourd’hui ? Par contre pour les applications lourdes, c’est déjà beaucoup moins le cas. Et c’est dommage. Intégrer des espaces de discussion (comprendre des forums light) dans les applications lourdes, même si c’est pour les limiter aux questions/réponses que peuvent avoir les utilisateurs, ce serait déjà un grand pas, à mon avis.

2.5 Et ma grosse épée, tu veux que je…

Là aussi, pour les killers, à priori, ce n’est pas super facile de mettre en place des mécanismes leur rappelant leur pratique du jeu vidéo (à moins d’intégrer un fps dans votre appli, qui se lancera grâce un raccourci clavier tarabiscoté). On peut toutefois en se rappelant que pour la plupart des joueurs de ce type, ce n’est pas le plaisir d’ennuyer les autres qui les motivent, mais la saine compétition. Mettre en place des systèmes des highscore peut donc être une façon de motiver les joueurs de ce type là.

3- En conclusion

Je vais me répéter, encore. Je vais insister sur le fait que se mettre à la place de l’utilisateur lorsque vous concevez une appli, c’est primordial.

Parce que vos utilisateurs sont peut-être obligés d’utiliser votre appli (cas d’une appli métier dans le cadre d’une entreprise). Mais ils ne le sont peut-être pas. Et même s’ils le sont, si vous voulez limiter les appels de mécontentement et autre ennuis, il faut leur faire aimer votre appli. Il faut que lorsqu’ils lancent/se connectent, ils soient impatients, joyeux. Cela ne se suffit pas/plus qu’une application soit fonctionnelle. Il faut aussi qu’elle soit plaisante, un minimum tout au moins.

Pour presque finir, je rajouterais, une dernière chose en tout cas dans ce billet, que l’on peut réutiliser du monde du jeu vidéo. C’est l’attrait de la nouveauté, le rajout de contenu. Là aussi, c’est bien plus facile avec une application web. Mais bon, c’est pas non plus impossible avec des applis lourdes. Pensez à ajouter du contenu dans vos applis. Ici le contenu pourrait être de nouvelles features ajoutées petit à petit, de temps en temps. Ou alors de nouveaux badges/succès. Ou de nouveaux accès cachés. Mais il faut penser à faire vivre son appli, à maintenir ses utilisateurs sous le charme.

Mais, et je finirais presque ainsi, ne me faites pas écrire ce que je n’ai pas écrit. C’est à dire que rajouter des mécanismes venus du jeu vidéo, c’est bien. C’est comment dire, la cerise sur le gâteau. Si l’application en dessous est pourrie ou ne sert à rien, vos utilisateurs fuiront ou râleront très fort et continuellement. C’est d’ailleurs la même chose pour les jeux vidéos. Un mauvais jeu vidéo avec le meilleur système d’achievement du monde, personne n’y jouera bien longtemps (ou alors votre ‘habillage’ fera que vous retiendrez vos utilisateurs un peu plus longtemps, mais ça ne durera pas).

Enfin, et là, c’est vraiment la fin de mon billet, la plupart des mécanismes de ‘rétention du joueur’ se basent, il faut bien l’avouer, sur l’égo du joueur. Mais bon, faites attention à ne pas abuser de ces mécanismes. Personne n’aime être pris pour un con.

Le PHP ne serait-il pas le WoW du dev web ?

Je sais, je sais. Ce billet ne sert à rien, ce billet n’est qu’un gros troll tout poilu et j’aurais mieux fait de ne pas l’écrire. Et en plus, ce n’est même pas encore vendredi (mais presque, jeudi, c’est presque comme un vendredi qui serait un peu en avance).

Mais tant pis. Et puis il faut bien écrire, de temps en temps, des billets engagés, des billets qui dénoncent.

Le seul et unique but de ce billet est donc d’étayer l’hypothèse, fortement plausible, que le PHP soit le WoW du dev web. Pour cela, on étudiera la question suivant deux angles. Tout d’abord, en se concentrant sur les ressemblances (ou pas) du PHP et de WoW puis ensuite en disséquant les comportements des utilisateurs, joueurs de WoW ou codeurs PHP (et non, n’insistez pas, ce billet ne donnera pas lieu à une dissection de joueurs de WoW, non, après c’est pas vous qui nettoyez hein…).

1- WoW et le PHP

1.1 WoW

WoW est un MMORPG, tout le monde le sait.

Il a été conçu et lancé dans un but et un seul, démocratiser le jeu en ligne. Pas parce que Blizzard a reçu la parole divine du dieu des MMO et a décidé d’en devenir le prophète mais tout simplement parce qu’avec une pratique du jeu online démocratisée et rentrée dans les mœurs, Blizzard avait plus de chance de se faire tout plein de sous. Et oui… C’est triste, mais WoW ce n’est qu’une grosse machine à vous prendre vos sous.

Réduire la barrière à l’entrée pour le joueur moyen, voire même pour le non joueur, même s’il a 12 ans. Je suis sûr que cette phrase était gravée dans le marbre sur le fronton de chacun des openspaces de Blizzard.

1.2 Le PHP

Remontez dans le temps, non non, stop, pas jusque dans les années 80… Revenez juste après le début des années 90. Rappelez-vous avant 1995, quand pour dev du web c’était soit du Perl, soit des choses pires encore…
Autant dire qu’il n’y avait pas beaucoup de codeurs web. Et là est apparu le PHP. Un langage volontairement simple (mais non j’ai pas dit simpliste, tss, tss), facile à comprendre et à apprendre. Un langage pour mettre le développement web à la portée de tout le monde, pour que n’importe qui puisse en 20 minutes avoir des trucs qui s’affichent dans son navigateur (tiens, ça me rappelle un peu le pourquoi de la création du VB… Je dis ça…).

1.3 Bilan

Sur le point des ‘logiciels’ en eux-mêmes, il semblerait bien que mon hypothèse se valide. Dans les deux cas, on voit bien qu’il y avait une volonté de démocratisation qui se traduit par un abaissement de la difficulté (mais non je ne pense pas nivellement par le bas, mais non…) de prise en main et d’apprentissage.

2- Les utilisateurs

2.1 Le joueur de WoW

Le joueur de WoW ne connaissait pas les MMORPG avant le jour qui restera dans les mémoires comme LE jour, le 23 novembre 2004, jour de la sortie de WoW. Ce jour là, ce fut la révélation. Il découvrit le monde merveilleux du MMORPG et ses gentils habitants appelés Leg0lasdu33 ou SoRrOn ou encore BobQuiLol… Notre joueur ébahi découvrit que l’on pouvait parler SMS ailleurs que dans ce qui s’appelait alors les textos.

Depuis cette découverte, il joue. Encore et encore. Jamais lassé, jamais déçus, parce que WoW, waouh, c’est trop bien. Alors oui parfois, il faute. Il se laisse aller à écouter les sirènes du marketing. Et il achète un autre MMO. Il l’installe, le lance et la première remarque ‘Mais… C’est pourri ce jeu, c’est pas comme dans WoW‘. Et finalement, au bout de quelques heures, voire au maximum quelques jours, il désinstallera ce jeu ‘complètement raté‘, parce que ‘pas comme WoW‘. Il retournera ensuite jouer à WoW, parce que WoW, c’est bien, vu que c’est comme WoW.

2.2 Le codeur PHP

Le codeur PHP a appris la programmation avec le PHP. Par lui même, grâce aux tutos qu’il a trouvé sur le net ou alors en cours. Il ne connait pas d’autres langages que le PHP, parce que de toute façon le PHP c’est le mieux, c’est le langage le plus utilisé sur le web et que ‘ceux qui font pas du web, ils ont rien compris, c’est des has been‘. Algorithmique, complexité des algorithmes, POO ou design pattern, c’est du chinois pour lui. Ce qui compte c’est que les coms de son dernier site 2.0 presque 3.0 s’affichent, et vite.
Parfois, tout de même, il est pris de curiosité. Alors il essaie un autre langage. Pour voir si quelque chose arriverait au niveau du PHP. Il y croit pas, mais ‘il faut savoir garder l’esprit ouvert‘ dira-t-il doctement aux autres codeurs PHP avec qui il discute. Ça peut être Ruby, Erlang, Python, ou n’importe quoi d’autre. Mais invariablement, au bout de quelques secondes, il s’exclamera ‘Mais… C’est pourri ce truc, c’est pas comme en PHP’ .. Et au bout de 4 ou 5 tests de “hello world”, parfois sans même essayer d’apprendre le langage en question, juste en ‘essayant’, il abandonnera et retournera se vautrer dans son PHP, parce que ‘décidément il y a rien de mieux que le PHP’‘.

2.3 Bilan

On le voit, nos deux populations sont très très similaires. Même réflexes, même façon d’envisager les choses qui ne sont pas ce dont ils ont l’habitude. Et très souvent le même argument pour essayer de vous convaincre à savoir ‘Tu sais, WoW c’est super bien, c’est pas pour rien que c’est le MMO le plus joué, hein, c’est parce que c’est le meilleur‘ ou pour le PHP ‘Tu sais, php c’est le langage le plus utilisé pour le web, c’est pas pour rien, c’est parce que c’est le mieux‘. A croire que les codeurs PHP jouent à WoW et inversement.

3- Bilan des bilans

Après une aussi brillante démonstration qui a prouvé que :

WoW était similaire au PHP,
que les utilisateurs avaient des comportement similaires,
que les usages étaient similaires.

On est bien forcé d’en déduire que oui, le PHP est bien le WoW du développement web. J’avais donc raison.

Pour ceux qui se demanderait quel légitimité j’ai pour faire cette étude, je leur répondrais que j’ai la légitimité d’une très longue pratique, à savoir :

4 jours de test de WoW en août 2009 (merci le trial),
quelques mois de dev PHP, du pire type la modification de code existant, pour des projets clients.

Note de bas de page, pas en bas de page.

Il faut bien entendu prendre ce billet avec humour. Mais non très chers codeurs PHP et très chers joueurs de WoW, je n’ai rien contre vous. Certains de mes amis font d’ailleurs partie de vos cohortes (et parfois même, ils cumulent, eux, j’évite de les voir trop souvent, c’est mauvais pour ma réputation). Et puis rassurez-vous, il y a pire que vous, genre les joueurs de Dofus ou les codeurs Perl… Mais ceci est une autre histoire.

Succès et titres : quand les mécanismes des jeux vidéos s’invitent dans vos applis

Cela fait quelques temps que je n’avais pas fait de billet ‘théorique’ sur les mécanismes du jeu vidéo. L’actualité (on va dire ça comme ça) me donne l’occasion d’en faire un, non pas directement sur un mécanisme bien précis des jeux vidéos mais sur une appropriation par les éditeurs de logiciel non jeux vidéos (je n’allais quand même pas dire sérieux) de ces mécanismes.

1- Succès et titres, mais c’est quoi ça ?

1.1 Les succès

En anglais on les appelle achievement, en français vous les trouverez sous le nom de succès ou d’accomplissement. Le principe est très simple. Pour gagner un succès, il faut le débloquer. Pour le débloquer, il faut faire quelque chose ou N fois quelque chose (tuer 45 sangliers pour avoir le succès Boucher, se balader complètement nu pendant 10 heures de jeu pour avoir le succès naturiste). Suivant les jeux vous saurez ou vous ne saurez pas quoi faire. Savoir quoi faire simplifie les choses, vous n’aurez alors plus qu’à faire la chose en question. Ne pas savoir quoi faire rajoute un peu de piment à la chose, parce que vous allez devoir découvrir comment avoir le succès. Et quand vous l’aurez vu, vous croiserez les doigts pour rester le plus longtemps possible le seul à avoir ce succès là. Il existe également des succès ‘qui se moquent de vous’, comme le succès maladroit, par exemple, que l’on pouvait gagner dans un MMORPG après être mort souvent. Ou le succès lâche lorsque l’on s’enfuit trop de fois d’un combat.

Dans tous les cas, vous l’aurez compris, le mécanisme de succès a un seul but: vous faire jouer plus longtemps sans que vous vous ennuyez. En faisant appel à deux sentiments très courants chez les joueurs : l’ego et la fièvre du collectionneur.

L’ego, parce que oui, tout de même, vous ne pouvez pas être le seul de votre guilde a ne pas avoir ce succès là. Tant pis si vous devez chasser 3458 araignées géantes des abysses, tant pis si cela vous prend 34 heures, mais vous l’aurez ce succès et vous pourrez alors le clamer haut et fort et ainsi maximiser votre vie sociale comme jamais.
La fièvre du collectionneur, parce qu’il vous les faut les 532 succès du jeu. Il vous les faut tous, absolument. Ce n’est pas possible de contempler votre feuille de profil avec tous ses emplacements manquants. Non, vous les aurez tous.

Et puis les succès ont un avantage, c’est du contenu ludique facile à mettre en place et à ajouter (à propos des succès, un bon article qui en parle sur New Game +).

1.2 Les titres

Les titres, en fait c’est presque comme les succès. Sauf qu’en plus de pouvoir les gagner en faisant des choses, on peut aussi parfois les acheter, quand le jeu intègre une dimension économique.

Succès et titres ont toutefois des différences importantes :

Les titres sont souvent ‘uniques’. Imaginons que nous soyons dans un jeu médiéval fantastique où les titres de noblesse existeraient, il ne pourrait y avoir qu’un seul baron de la contrée des quatre collines ;

Vous pouvez les perdre. Si le titre correspond par exemple à une performance. Si un autre joueur fait mieux que vous, c’est lui qui gagne le titre (on se retrouve là avec la notion de champion de…) ;

Un titre peut être ‘anonyme’. Ce peut être un simple classement et le numéro un sera le meilleur, le champion donc.

2- Bon ok, et maintenant ?

Maintenant, je vais en venir au sujet de mon billet. A savoir, le fait que ces deux mécanismes commencent à être intégré dans des applications autre que les jeux vidéos. Un exemple, que j’ai découvert très récemment, c’est Foursquare. Foursquare est un réseau social tout neuf qui vous fait découvrir des endroits où vous pourriez aller (restos, bars, théâtres, discothèques…). A chaque fois que vous allez dans un lieu, vous gagnez un checkin dans ce lieu. Dès que vous avez un checkin dans un lieu, vous pouvez lire les avis laisser par les autres utilisateurs.

J’en avais entendu parlé mais cela n’avait pas plus piqué ma curiosité que ça. Jusqu’à ce que je reçoive un tweet, de @xpoxpo qui disait : “‘I just unlocked the “Newbie” badge on @foursquare! http://4sq.com/5SfMFD”. Étrange me suis-je alors dit… Qu’est-ce que c’est que ce truc de badge. Et je suis donc aller voir (j’ai même fini par créer un compte pour tester). En fait les badges c’est des succès. Vous avez le badge newbie (un passage dans un endroit), aventurer (10 passages dans 10 lieux différents), local (3 passages dans le même lieu), etc. Mais ce n’est pas tout. Il y a mieux. Il y a même la gestion des titres. Enfin, d’un titre pour être précis. Celui de maire (mayor) d’un lieu. L’utilisateur qui a le plus de checkin dans un lieu devient alors maire de ce lieu. Mais attention, dès qu’un autre utilisateur a plus de checkin que lui, hop c’est ce nouvel utilisateur qui devient maire de ce lieu.

3- Et l’intérêt de tout ça ?

3.1 Pour l’utilisateur

L’utilisateur lui permet de rajouter un peu de fun dans son expérience utilisateur. Il n’utilise plus simplement un logiciel, il joue en même temps, il s’amuse et il peut se mesurer aux autres utilisateurs, chose qui en ces temps de ‘web social’ et de ‘mesurage de qui a la plus grosse de toutes les manières possibles’ intéressent au plus au point les gens.

3.2 Pour les éditeurs

Là, les bénéfices sont les mêmes que dans le jeu vidéo. Les utilisateurs deviendront bien plus rapidement addict à un service si le service leur procure, en plus de ce pourquoi il est là, du fun. Et puis n’oublions pas les deux leviers sur lequel s’appuient le mécanisme des succès. Ego et esprit de collectionneur. Si je reprends l’exemple de Foursquare, le fait de savoir qu’il y a des badges à collectionner va créer une barrière à la sortie. Et le titre de maire, plus encore. Comment va réagir l’utilisateur lambda s’il se rend compte qu’il s’est fait ‘voler’ son titre de maire ? Il va foncer dans le lieu en question et faire en sorte de redevenir maire.

3.3 Mais encore…

Foursquare a d’ailleurs bien compris l’intérêt du titre maire. Et semble avoir réussit à le faire bien comprendre à certains des gestionnaires des lieux dans lesquels les utilisateurs vont. Pourquoi dis-je cela ? Parce que si vous allez sur cette page, vous aurez la liste des lieux qui offrent des réductions ou des verres gratuits au maire. De quoi rendre la bataille pour le titre de maire encore plus intéressante…

4- Mais dis moi, ce billet, c’est pas un billet sponsorisé pour Foursquare ?

Non, mais il se trouve que l’idée du billet étant venu en découvrant ledit service, il était donc facile pour moi de l’utiliser comme exemple. Un autre exemple de l’intégration des accomplissements dans une application non jeu vidéo que je pourrais citer (et d’ailleurs je le fais) c’est le Nokia Image Space. Pour plus d’infos sur cette intégration, il faut aller voir le pdf appelé ‘Applying Game Achievement Systems to Enhance User Experience in a Photo Sharing Service’ que vous pourrez récupérer sur cette page.

Pour finir, je rajouterais que cette démarche (utiliser les mécanismes des jeux vidéos dans des applications autres) me semble normale et va aller en s’accélérant. Et cela pour deux raisons :

Je pense que le principe du ‘c’est une application sérieuse, elle n’a pas besoin d’être jolie ou agréable à utiliser’ a vécu. Que de plus en plus, les applications, même de gestion, vont avoir tendance à s’embellir et à rendre leur utilisation plaisante. Et être plaisant à l’utilisation, ça, c’est un truc que savent faire les jeux vidéos ;

Les jeux ont le même problème que les applications web-sociales d’aujourd’hui. Faire en sorte que les utilisateurs les utilisent le plus longtemps possible. Par tous les moyens. Et les jeux étant plus vieux que les applications web d’aujourd’hui, il est normal que les secondes aillent piquer des idées éprouvées aux premiers.

(Sinon, pour la franche rigolade de fin de billet, en faisant quelques recherches sur le sujet, je suis tombé sur la description d’un vieux brevet logiciel américain qui ‘protège’ le fait de mettre en place un mécanisme d’accomplissement… Youpi… Regardez qui l’a déposé, le brevet).

Où les middleware envahissent la django-application du mois

Je sais, je suis impardonnable, je n’ai pas fait de billet sur la django-application de décembre. Vous pourriez même rajouter que je le suis encore plus parce que décembre c’est le mois des vacances de Noël et que qui dit vacances dit temps pour écrire un billet.

Oui, mais non. Parce que faut pas croire, ça prend du temps tout ces repas de fêtes. Plein de temps. Sans compter le temps que l’on passe à arpenter les magasins (IRL ou sur le net d’ailleurs) pour trouver des cadeaux. Et sans parler du fait que comme décembre est un mois de vacances, pendant les jours de non-vacances, faut bosser encore plus pour essayer de faire autant que pendant un mois normal, mais en moins de jours.

Autant dire que non, je n’ai pas eu le temps pour la django-app du mois.

Et que vu mon emploi du temps en janvier, ça va être tendu pour le billet de celle de janvier. Mais, mais, dans ma grande mansuétude, j’ai décidé de faire un billet de django app du mois de décembre, en retard.

Et pour une fois, je ne parlerais pas de django-app, mais de middleware. Mais oui, les middleware django, vous savez, ce mécanisme génial qui permet de pluger de petit bout de code à différents niveaux de traitement des requêtes. Ce qui permet de modifier plus ou moins profondément le comportement de django au niveau de la gestion de ses entrées / sorties.

Ca permet de faire plein de trucs, et plus encore.

Aujourd’hui je parlerais de deux d’entre eux, un que j’utilise très souvent et un autre que je vais utiliser sous peu..

1- Loguer les requêtes SQL que fait django

from django.db import connection
from django.template import Template, Context
from django.conf import settings

#
# Log all SQL statements direct to the console (when running in DEBUG)
# Intended for use with the django development server.
#

class SQLLogToConsoleMiddleware:
def process_response(self, request, response):
if settings.DEBUG and connection.queries:
time = sum([float(q['time']) for q in connection.queries])
t = Template("{{count}} quer{{count|pluralize:"y,ies"}} in {{time}} seconds:\n\n{% for sql in sqllog %}[{{forloop.counter}}] {{sql.time}}s: {{sql.sql|safe}}{% if not forloop.last %}\n\n{% endif %}{% endfor %}")
print t.render(Context({'sqllog':connection.queries,'count':len(connection.queries),'time':time}))
return response

J’ai trouvé ce tout petit middleware sur djangosnippets. Il se contente d’afficher la liste de toutes les requêtes SQL faites par django, en donnant le temps pris par leur execution.

C’est bien utile pour vérifier que ces vues ne font pas de la merde et pour tenter d’optimiser en factorisant des choses.

2- Django-maintenancemode

Celui-là, je l’ai découvert au détour d’une conversation sur #django-fr. Carrément plus pratique que la bête page html qui dit ‘en maintenance’, utile à connaître et à avoir dans sa django-boîte à outil.

Les nouveautés de django 1.2 alpha

Avant de commencer à te faire perdre ton temps, je tiens à te prévenir cher lecteur. Si tu as lu la release note de django 1.2 alpha 1, tu n’apprendras rien de plus en lisant ce petit billet.

Pourquoi alors l’écrire ?

Au cas où tu n’aurais pas encore lu la release note et que lire du français t’amuse plus que lire de l’anglais. Et puis comme ça, en plus, tu as le lien vers la release note.

1- Les trucs nouveaux

1.1- protection contre les attaques CSRF.

Les attaques CSRF (Cross-Site Request Foregery) sont rendus possible par le partage des données de login/session entre les différents onglets d’un navigateur. Du coup, si vous êtes logués sur un site quelconque (prenons facebook comme exemple) et que vous allez sur le site d’un vilain méchant pirate, le vilain méchant pirate pourrait faire des actions sur Facebook, comme si c’était vous qui les faisiez. (Bon pour pouvoir faire cela, il faut que vous cliquiez sur un lien du site du vilain pirate, ou que vous soumettiez un formulaire ou que vous executiez du js).

Django implémente maintenant une façon cool de s’en protéger. (avant il existait un middleware pour le faire). Moralité, si Facebook était en django 1.2, les attaques CSRF ne seraient pas possible.

1.2- Backends des emails

On peut maintenant configurer la façon que django aura d’envoyer des emails. Sympa pour pouvoir debugger et tester les envois d’emails, ça évitera d’avoir à passer par des simulateurs de SMTP.

1.3- Le framework d’envoi de messages

Il remplacera l’ancienne API d’envoi de message et apparemment, il va être juste terrible. Les users authentifiés ou anonyme pourront en envoyer, on pourra les stocket en session ou en cookie, gérer des levels, des tags, que du bon quoi

1.4- Support des multiples bases de données

Alors ça, je l’attendais avec une impatience extrême. On pourra maintenant dire à django de se connecter à X bd différentes, choisir pour chaque requête bd sur quelle base on veut la faire ou où est ce que l’on veut sauver une instance de modèle. Que du bon quoi. Pour ne pas dire de la tuerie

1.5- Un tag if coolos

Là on peut résumer en une phrase : ‘Fini le ifnotequal a b et vive le if a != b’.

Les opérateurs de comparaisons sont enfin supporté. On pourra donc utiliser :

==
!=
<
>
<=
>=
in
et and or et not (qui fonctionnaient déjà).

Et en plus, on pourra utiliser des filtres en même temps. Avec un {% if inst1.var1|bla == inst2.var2|tut %}

Le pied je vous dis.

1.6- Gestion du cache des templates

On pourra configurer un truc de gestion de cache des templates. Et ça, c’est bien.

1.7- Clés en BD

On peut maintenant utiliser les naturals keys dans les fixtures (j’ai pas trouvé de traduction française qui me convenait). Ce qui peut-être bien sympa quand par exemple on a des fixtures qui bossent avec des content types (au hasard hein )

Et on peut maintenant utiliser des int de 64 bits avec le BigIntegerField .

1.8- En vrac

une commande en plus sur le runtest qui permet de faire sortir le lanceur de test dés qu’il y a une erreur.
Une amélioration de la localisation pour les dates et les nombres qui seront affichés (si l’option est activée) de la façon qui va bien en fonction de la locale.
L’ajout de la propriété readonly_fields pour les champs non éditable (enfin)
la possibilité de customiser les couleurs pour les highlight dans la parti admin.

2- Les trucs obsolètes ou incompatibles

Bon alors déjà, une nouvelle qui va faire que tout le monde va respirer, dans le 1.2 les trucs obsolètes seront encore supportés. Le support n’en sera supprimé que dans la version 1.4. Ça laisse donc un peu de temps pour organiser ses migrations.

2.1- Le middleware CSRF

Forcément si la protection anti CSRF est refait d’une manière mieux, l’ancienne manière devient obsolète.

2.2- SMTPConnection

Ceux qui utilisaient la classe SMTPConnection pour envoyer des mails devront changer leur code. Heureusement les modifs sont légère (il suffit apparemment de remplacer l’appel au constructeur de la classe par un appel a get_connection () )

2.3- La configuration de la base de données

Forcément ça change. Faudra passer dans la syntaxe multidb, même si on a qu’une seule db.

2.4- L’API d’envoi de message.

Là encore, faut passer à la nouvelle version. Mais ça n’a pas l’air super compliqué. Du replace de nom de fonction et ça devrait le faire.

2.5- Les helpers de formatage de date.

Les fonctions django.utils.translation.get_date_formats() et django.utils.translation.get_partial_date_formats() sont obsolètes et il faudra les remplacer par django.utils.formats.get_format()

2.6- En vrac

Du fait des nouvelles fonctionnalités du if, appeler des variable ‘and’, ‘or’ ou ‘not’ est encore moins une bonne idée, vu que vous allez vous manger des TemplateSyntaxError. Bon de toute façon, c’était déjà une très très mauvaise idée d’appeler des variables ‘and’, ‘or’ ou ‘not’, donc …
Le LazyObject. Ceux qui utilisaient cette classe non documentée vont devoir modifier leur façon de l’utiliser.
Modification de ce que contient le __dict__ dans les instances de Model : Jusqu’à présent le __dict__ ne contenait que les attributs qui correspondaient au champ du modèle. Maintenant il contient un attribut _state qui sert à gérer les db multiple. Ceux qui itere sur le __dict__ de Model devront faire attention à filtrer le _state
les fonction get_db_prep_* des Fields ont changé de signature (et il y en a 2 de plus get_db_prep_save et get_prep_lookup )
du fait de l’utilisation du cache loader, il faut bien vérifier que les templates tags utilisés sont bien thread-safe (je sais pas pourquoi je sens que ce point là va être le point de départ de dizaines de touffes de cheveux de geeks arrachées).
Code de retour du lanceur de test : Le code de retour du lanceur de test ne correspond plus au nombre de test raté. C’est maintenant 0 si aucun test n’a merdé, 1 si il y a eu des merdes.

3- Conclusion

Que du bon dans cette nouvelle version donc. Et en plus pas spécialement beaucoup de modifications à faire pour profiter des nouvelles améliorations. Vivement le 9 mars que la stable sorte quoi. 🙂

Indicateurs et tableaux de bord

Un chef d’entreprise se doit de gérer (ou piloter) son entreprise. Jusque là, on est tous d’accord. Mais pour arriver à faire cela, il lui faut des infos, des données, des choses sur lesquelles s’appuyer pour prendre des décisions. C’est ou ça ou se faire tirer les cartes pour décider quoi faire. Alors je sais qu’à différentes époques, les plus hautes instances ont pu faire confiance aux cartes, aux étoiles ou à d’autres systèmes pas vraiment cartésiens de prise de décisions.

Mais imaginons que notre gentil entrepreneur décide de ne pas s’en remettre à ce qui ressemble à du hasard. Non, il prendra des décisions réfléchies, qui s’appuie sur du concret.

Mais comment faire pour avoir ces données concrètes ? C’est tout simple. Il faut prendre les données que l’on a sous la main et les hiérarchiser, les traiter, les synthétiser et au final s’en servir pour calculer des indicateurs qui se mettront à jour, dans le meilleur des cas, automatiquement. Ce qui nous donnera des tableaux de bords qui nous permettront :

d’avoir une vision globale , d’un seul coup d’œil de la santé de sa société,
de prendre des décisions,
de voir les résultats des décisions prises.

On peut (que dis-je, on doit) bien entendu avoir des tableaux de bords pour tous les domaines où l’on a besoin de visibilité. Dans le domaine commercial, cela peut être pour mesurer une action ou les performances commerciales, pour voir les dérapages sur les projets, etc. Dans ce billet, quand je donnerais des exemples, je resterais sur des indicateurs de gestion d’entreprise. Si le sujet des indicateurs de pilotage vous intéresse mes chers lecteurs, je ferais d’autres billets (promis).

1- Où prendre les données et quoi en faire

J’aurais envie de dire “là où elles sont”.
En fait, ça dépend, là encore, du pourquoi de vos indicateurs. Pour des indicateurs de pilotage d’entreprise vous pouvez par exemple prendre votre pile de factures, vos liasses de bons de commandes et vos classeurs de devis, ainsi que tous vos calculs prévisionnels des charges de votre entreprise.

Ensuite, une fois que vous avez toutes vos données, il faut les consolider, en faire un tout qui ait du sens. Par exemple, à partir de calculs de vos charges de l’année d’avant, vous pouvez mettre en place un calcul de vos charges prévisionnelles de l’année prochaine (ou en cours) que vous ventilerez par mois. Ça vous donnera en même temps votre point mort prévisionnel.

De même, votre pile de factures vous permettra d’avoir votre CA fait, vos bons de commandes validés, votre CA à venir ainsi que vos devis et votre portefeuille futur.

Vous pouvez aussi du coup, rapprocher le CA mensuel ensuite (ainsi que le CA prévisionnel) pour voir quels sont vos bons ou vos mauvais mois.

2- Less is more (merci monsieur Mies)

Une fois que vous avez toutes vos données bien rassemblées ensemble, avec plein de tableaux, de calculs, de totaux, etc., il faut sélectionner vos indicateurs.

Pour cela, il n’y a qu’une règle. Il vous en faut peu. Et qu’ils soient vraiment percutant.

Pourquoi peu ? Parce qu’il faut que, chaque matin, vous puissiez en un coup d’œil, voir tout ce qu’il y à voir. Savoir là ou ça va et où ça ne va pas.

Vous aurez toujours le temps après d’aller voir plus loin dans les données brutes ou dans les dizaines de calculs intermédiaires que vous avez fait, l’explication du pourquoi du comment de la valeur de votre indicateur.

Si je prends mon cas comme exemple, j’ai en ce qui concerne la partie “gestion financière”, quatre indicateurs principaux :

la visibilité au niveau trésorerie en nombre de mois qui correspond au nombre de mois pendant lesquels on peut payer les charges,
le nombre de jour/hommes qu’il faut que l’on facture encore à notre taux journalier moyen pour atteindre le point mort,
le total de tout ce qui a été facturé mais non encore encaissé,
la valeur du portefeuille client possible (la somme des devis pondérés à chaque fois par la probabilité d’avoir le contrat).

Pour les deux premiers indicateurs, je les calcule de deux façons différentes :

avec les montants facturés (même si non encaissés),
avec les montants facturés et qui seront facturés (on bosse souvent sur de longs projets qui durent plusieurs mois, avec des facturations multiples en cours de projet, il est donc intéressant d’avoir cette vision de ce qui est signé mais pas encore facturé).

J’ai bien entendu des indicateurs secondaires comme :

le chiffre d’affaires déjà effectué,
le total des charges prévisionnelles de l’année (que je recalcule en fonction des charges réelles des mois passés),
les indicateurs de gestion de fonds de roulement.

Pourquoi avoir les indicateurs de besoins en fonds de roulement en indicateurs ‘secondaires’ ? Parce qu’on a un besoin en fonds de roulement assez faible et très stable. Et qu’au vu de l’historique de la société, on a mis les moyens pour se prémunir, en tout cas pour l’instant, de problèmes de BFR.

Au final, j’ai donc seulement quatre indicateurs qui me font six valeurs. Facile à regarder, rapide à comprendre. Et je n’ai pas besoin de plus pour voir la situation globale.

3- Tips

Bon, allez, je vais vous faire part de ma grande sagesse (…) et finir ce billet par quelques petits conseils.

3.1 De la couleur

Pensez à colorer vos indicateurs. C’est bien plus parlant qu’une valeur numérique. Deux exemples.
Mon indicateur de visibilité peut avoir trois couleurs :

vert quand la visibilité est supérieure à 6 mois,
orange entre 3 et 6,
rouge en-dessous.

Idem le nombre de jours à facturer qui peut être rouge ou vert. Il est vert quand les jours à facturer sont en phase avec le temps restant, en rouge sinon (expliqué simplement, cela veut dire que s’il nous reste 70 % du CA point mort à faire, donc 70 % des jours à facturer alors qu’on est en novembre, l’indicateur sera rouge. Si par contre on a déjà fait 80 % du CA point mort, et qu’il donc reste que 20 % de CA à faire alors qu’on est en mai, le nombre de jours restants à facturer sera vert).

3.2 Les mises à jour

Vous allez mettre vos données à jour assez souvent. A chaque devis, chaque modification du calcul des charges, chaque facture. Pensez donc à construire dès le début une structure qui puisse se mettre à jour simplement et dont les maj se propagent. Ajouter 1 000 € par mois dans les charges prévisionnelles doit permettre de tout recalculer, CA point mort, visibilité, etc.

4- Conclusion

Je suis sûr que je ne vous ai rien appris en vous disant qu’il fallait définir des indicateurs pour pouvoir piloter son entreprise.

Mais je voudrais vraiment insister sur deux points. Il est vraiment important d’être capable d’avoir peu d’indicateurs. 3, 4 , 6 maxi. Pour avoir eu beaucoup de mal avec ce point là, je sais que ça peut être difficile. Avoir 20 indicateurs, ça peut rassurer. Mais au final, vous vous en rendrez compte, c’est bien moins productifs que 4, 5 ou 6.

Il y a autant de tableaux de bord que d’entreprises. Vos indicateurs, ça doit être les vôtres. Ceux qui vous seront vraiment utile. Alors posez vous, réfléchissez et définissez ceux qui seront les plus pertinents pour votre activité.

Et puis quel bonheur ensuite, de voir ces jolis petits indicateurs, qui nous indique en un clin d’oeil, comment vont les choses.

MUNCHKIN QUEST, ou le retour de l’humour potache

Ayant offert à mon frère le tout nouveau (en tout cas en VF, vu qu’il est sorti en novembre) jeu de plateau MUNCHKIN QUEST à Noël, j’ai eu l’occasion de le tester dans une longue partie débridée (que j’ai fini, bien entendu, par gagner malgré le fait que tous les autres se soient ligués contre moi dès qu’ils leur aient apparu que j’étais le plus fort… Les vils).

Et qui dit test, dit petit billet pour en parler. J’avais prévu de commencer par un billet sur la version deux joueurs des Colons de Catane (qui se transforme pour l’occasion en jeu de cartes), ça sera pour une prochaine fois.

MUNCHKIN Quest est donc l’adaptation 3D et en mode plateau du jeu de cartes du même nom. On y retrouve donc l’humour potache, les blagues débiles, les monstres ridicules (comme le monstre nez flottant ou encore mieux l’ombre du nez flottant) et les cartes à la description totalement déjantée. C’est d’ailleurs une partie importante du fun du jeu, s’amuser à lire la description des cartes ou à regarder les dessins des monstres (bon faut avoir le sens de l’humour Munchkin, moi ça me fait beaucoup rire).

Les règles sont en fait assez simples, surtout si l’on connait le jeu de carte. Le but est d’arriver le plus rapidement possible à être niveau 10 (niveau que vous comptabiliserez sur la roue des niveaux).

Pour cela il convient d’explorer un donjon qui se construit aléatoirement et d’occire tous les monstres que l’on croisera. Le donjon se construit petit à petit grâce à des tuiles (représentant de salles) qui sont piochés aléatoirement par les joueurs. Les salles sont séparées par des couloirs, portes, passages secrets qui là aussi sont agencés aléatoirement. Chaque salles ont des caractéristiques bien précises, comme les salles marché où l’on peut vendre et acheter son équipement, mais aussi la salle fosse puante, la salle de torture ou au trésor, etc.

Pour tuer un monstre, rien de plus simple. Si le niveau du Munchkin est plus élevé que celui du monstre, le monstre est mort. Pour augmenter son niveau, on peut utiliser de l’équipement (armes, armure, collier, casque, chaussures, main en plus pour pouvoir utiliser encore plus d’armes). Et pour ajouter un peu de piment le joueur et le monstre lance un ou plusieurs D6 qui s’ajouteront à leur niveau respectif. Et comme Munchkin est un jeu hautement coopératif, les autres joueurs pourront vous aider à rendre votre combat plus palpitant… Après tout, se battre contre une pinacolata niveau 2, ça serait trop facile et hop elle passe niveau 12 grâce à l’intervention d’un joueur…

Remporter un combat contre un monstre vous ferra gagner des niveaux mais aussi des trésors. Trésors qui vous permettront de vous équiper ou d’augmenter votre argent de poche.

Comme dans le jeu de cartes, on peut également choisir une race et une classe, si on a les bonne cartes qui vont bien (la classe voleur qui permet de poignarder un autre joueur dans le dos pendant un combat, j’adore). Il y a cependant quelques différences comparé au jeu de cartes.

Tout d’abord, alors que dans le jeu de cartes on peut jouer à N joueurs, on sera ici limité à 4 joueurs. Quelques autres points de règles ont également changé. Les Munchkins ne peuvent s’aider que lorsqu’ils sont dans des salles adjacentes (ou dans la même salle) .
Enfin, les monstres ne sont plus défaussés lorsque l’on déguerpit. C’est d’ailleurs un des points importants du jeu et stratégiques. Les monstres que l’on ne tue pas restent dans le donjon et errent de pièces en pièces, se regroupant parfois en meute. Gare alors au Munckin qui croisera une meute de monstres aux abois…

Au final Munchkin Quest est un excellent jeu de plateau, si vous êtes rolistes ou geek et que vous avez le sens de l’humour. Pour les autres, vous vous ennuierez assez vite surtout que les parties sont plutôt longues (comptez plus 4 h que 2/3 h comme c’est indiqué sur la boite) et que la mécanique du jeu, assez simpliste, pourrait paraître répétitive.