Nagademon 2013, presque la fin.

Les impératifs du boulot ont fait que j’ai pris du retard concernant mon rétroplanning. En clair :

  • j’ai pu faire des simulations de parties seul (C’est à dire que j’ai fait comme si je jouait tout seul, sur des petits bouts de parties pour voir si la mécanique tournait bien). Cela a abouti à plusieurs modifications (les robots avaient trop de vies, détruire un robot était bien trop difficile, les missiles une portée trop longue et était pas assez cher).
  • je n’ai pas du tout pu faire une vraie partie avec d’autres joueurs. Comme on est jeudi soir tard, je doute de pouvoir faire une partie d’ici samedi, du coup, j’aurais en partie échouer ce nagademon 2013 …
  • j’en ai profité pour faire quelques petites ressources graphiques, des éléments de décors, les pions pour les robots, les cartes pour les points de vies. La encore, j’aurais voulu aller plus loin (en modélisant les pièces de robots et en les intégrant dans le design des cartes robots, mais je n’aurais pas le temps d’ici samedi minuit).

Je ferrais un billet point dimanche sur cette première expérience de Nagademon 2013…

Nagademon , troisième semaine

Bon comme je tiens absolument à le faire depuis que je me suis lancé dans le Nagademon, un petit billet pour expliquer où j’en suis. Cette semaine, il sera toutefois très court.

Pour différentes raisons (un petit déplacement pro, un week-end assez chargé, quelques parties d’hearthstone de trop), je n’ai pas avancé autant que je l’aurais voulu.

J’espérais en effet pouvoir finaliser les règles et les éléments permettant de construire son armée. J’ai finalisé les règles (moins les règles additionnelles), mais je n’ai pas eu le temps de finir la liste et l’équilibrage des éléments.

Du coup, je n’ouvrirais pas le repo Bitbucket que j’avais prévu d’ouvrir dés ce soir et qui me sert à stocker mon travail.

J’espère pouvoir le faire demain ou mardi.

Une fois que j’aurais fini cette première mouture des règles, le grand défi va être de faire tourner le jeu pour le tester, faire les équilibrages nécessaire où le foutre totalement à la poubelle …

Je pense faire quelques parties tout seul pour roder un peu les choses, ensuite .. Ça sera le grand test, jouer avec de vrais gens ….

Je vous tiendrais au courant dimanche prochain, si j’ai validé cette étape ou pas.

Bon comme je tiens absolument à le faire depuis que je me suis lancé dans le Nagademon, un petit billet pour expliquer où j’en suis. Cette semaine, il sera toutefois très court.

Pour différentes raisons (un petit déplacement pro, un week-end assez chargé, quelques parties d’hearthstone de trop), je n’ai pas avancé autant que je l’aurais voulu.

J’espérais en effet pouvoir finaliser les règles et les éléments permettant de construire son armée. J’ai finalisé les règles (moins les règles additionnelles), mais je n’ai pas eu le temps de finir la liste et l’équilibrage des éléments.

Du coup, je n’ouvrirais pas le repo Bitbucket que j’avais prévu d’ouvrir dés ce soir et qui me sert à stocker mon travail.

J’espère pouvoir le faire demain ou mardi.

Une fois que j’aurais fini cette première mouture des règles, le grand défi va être de faire tourner le jeu pour le tester, faire les équilibrages nécessaire où le foutre totalement à la poubelle …

Je pense faire quelques parties tout seul pour roder un peu les choses, ensuite .. Ça sera le grand test, jouer avec de vrais gens ….

Je vous tiendrais au courant dimanche prochain, si j’ai validé cette étape ou pas.

Nagademon, deuxième billet

Comme promis, parce que non je n’ai pas baissé les bras, voici mon deuxième billet concernant ma participation au concours NagaDemon.

J’ai donc passé ma semaine à réfléchir à différentes possibilités pour mon jeu. Je dois bien avouer que dés le début de la semaine, j’avais une idée, un jeu que je voulais faire il y a quelques années en version jeu vidéo mais que je n’avais pas creusé à part en définissant le concept. Concept qui était alors ‘c’est un jeu de bataille de robots’.

Je n’y avais plus pensé depuis et là, impossible de sortir une autre idée que celle là de mon cerveau. Pendant plusieurs jours j’ai lutté pour trouver d’autre idées.. (Parmi les idées farfelues, un concept jeu où on joue des cafards devant survivre dans une maison et voler de la nourriture dans la cuisine, un concept à la loup-garou mais avec un tueur en série, un jeu où les joueurs sont de bibliothécaires qui essaient de ranger leur bibliothèques (avec des fantômes dedans, un peu) et un jeu où les joueurs sont des fantômes qui veulent faire peur aux gens (mais sans bibliothécaires dans celui-là de jeu)  .. ) Mais aucunes n’a réussi à percer suffisamment pour que mon cerveau ne se focalise pas sur mon idée de robot.

Du coup, la semaine prochaine va être centré sur écrire les règles, la dernière semaine me laissera amplement le temps de tester (j’espère).

Je ne vais pas m’étendre sur les règles, vu que je dois les écrire. Mais déjà je vais vous donner un concept.

C’est donc un jeu avec des robots. Il se joue en deux phases. On construit son équipe de robot à partir de pièces ( la base, les armes, le blindage, les moteurs) et ensuite on se bastonne avec une autre équipe.
Le terrain de jeu se construira à chaque début de partie. Il sera constitué de plots où les robots peuvent se tenir et de pont reliant les plots.  L’une des caractéristiques des robots seront la vitesse qui se comptera en nombre de pont par tour. Entre deux ponts il y a un plot. Et les ponts sont toutes de même longueur.

Pour les modes de jeu, j’en prévois deux stratégique et arcade. Le mode stratégique se limitant au terrain plus les équipes de robots, le mode arcade proposant des cartes événements (piochable par les joueurs dans une pile commune) qui permettront de modifier le cours de la partie.

Au niveau des conditions de victoires, je vois bien deux types de parties possibles :

  • match à mort. Chaque équipe possède un commandeur robot. Si celui-ci est détruit, l’équipe a perdu.
  • Points de victoire. Certains plots si ils sont contrôlés par un robot, donne des points à chaque tour, quand une équipe a suffisamment de point, elle gagne.

Voila, c’est tout pour cette semaine, à la semaine prochaine avec, si je ne faiblis pas, des règles.

Allez go, participation au Nagademon 2013 !!

Disclaimer : Because my level of English, all posts on  Nagademon will be in French

Ce coquin de bruno m’a parlé aujourd’hui du Nagademon… Qu’est ce que le Nagademon ? C’est comme le NaNoWriMo mais pour les jeux…

Bon ok, ça ne vous avance pas vraiment.

C’est tout simplement un concours de création de jeux (vidéos, rôle, carte, plateau, etc) qui se tient en novembre. Il commence le premier novembre et fini le 31. Si au 31 novembre, vous avez réussi à finir votre jeu et à y jouer, alors vous avez gagné. Et c’est tout.

C’est donc juste un concours pour la beauté du geste, un exercice de création avec contrainte.

Je ne pouvais résister que quelques minutes avant de dire ‘bon ok j’y vais’. (Alors que les NaNoWriMo, je n’essaie même pas de démarrer, vu que je sais que je ne pourrais jamais y arriver).

Donc voilà, ceci est mon billet de démarrage. J’essaierais d’écrire un billet par semaine, en fin de semaine pour donner mon avancé (ou dire que j’abandonne).

La première problématique, et je me donne une semaine pour y arriver est de trouver le concept du jeu. En effet, je veux vraiment respecter la régle du Nagademon, donc exit tout les jeux auxquels j’ai sur lesquels j’ai commencé à travailler comme le Simon Système ou d’autre jeux qui sont dans mes cartons ..

A la rigueur, je m’autorise a choisir un concept de jeu que je n’ai jamais approfondi réellement, mais c’est tout.

A la semaine prochaine pour un nouveau billet plein d’optimisme (ou un j’en ai marre, j’ai pas de temps, j’abandonne). Et n’hésitez pas à participer !!

Code Retreat

Il y a quelques mois (en juin), j’ai participé à une code retreat sur Lyon. Autant dire que pour prendre un TGV a 6h du mat, je devais être motivé !

Avant de vous parler plus du pourquoi c’est bien une code retreat, je vais quand même vous expliquez ce que c’est.

Prenez un nombre pair de personnes. Prenez un problème d’algo simple mais pas trop. Faites des sessions de 45 minutes, où les gens travaillent par paire (mais avec une seule machine, du vrai pair programming quoi) pour essayer de ‘résoudre’ le problème en TDD. La première session faite la simple, sans contrainte, puis rajouter des contraintes genre ‘ pas de boucle, vous ne pouvez pas parler , vous ne communiquez qu’à travers les tests, une fonction fait 5 lignes max’, etc etc ..

A la fin des 45 minutes, vous supprimez votre code, faites une rétrospective, vous trouvez un/une nouveau binôme et recommençait l’opération, avec un nouvelle contrainte.

Ce qu’il y a de rigolo, c’est qu’à chaque session vous pouvez (c’est conseillé) changer de langage de programmation. Vous pouvez commencer avec du python, puis faire une session PHP, puis ruby, puis C#, etc …

Pour tout dire, lors de la code retreat que j’ai fait, je me suis même retrouvé à faire, pendant une de mes sessions du C# (et ben j’ai pas aimé:) ) .

mais ça sert à quoi de passer 1 journée à faire X fois la même chose, avec des gens différents, et de jeter son travail à chaque fin de session ?

Alors, si vous lisez de la doc sur la question ( où ce billet de jérémy qui présente bien les choses), vous comprendrez que c’est une excellente forme d’entraînement. Pas de pression de la livraison (vu qu’on jette tout), pas de pression du ‘ça va partir en prod’ , vu que l’on jette tout. Pas du pression de ‘il faut finir’, vu que bon, tout va être jeter et qu’il de toute façons, ce que vous diront les orga au tout début, c’est qu’il ne faut pas chercher à finir, parce qu’en 45 minutes, on ne peut pas. Ce n’est pas le but de toute façon, le but c’est de s’exercer.

Donc oui, vous allez voir, ca sera une excellente forme d’entraînement. Mais pas seulement. Enfin, pour moi, cela ne fut pas seulement une session d’entraînement super intéressante.

J’ai trouvé que cela apprenait des choses sur soi même, pas mal et sur notre métier en général. Histoire de ne pas faire trop long, je vais simplement donner deux exemples de ce que j’ai appris lors de cette journée.

Sur moi même tout d’abord.  Ben oui. La première session, je l’ai faite avec quelqu’un qui n’avait fait que très très peu de python et qui voulait s’y ‘remettre’ le temps d’une session. Du coup on avait pas trop la barrière du langage de prog qui est connu que par l’un des deux et on sait dit allez on y va. On a commencé en TDD comme c’est imposé. Et puis on voyait le temps défiler et le code avançait et à un moment, ben c’était possible d’aller vite et de finir. Oui le but est pas de finir, c’est pas fait pour, bla bla bla. Mais on pouvait finir. Et du coup, ben on sait dit ‘ok, on finit et on écrit les tests après’. Et on a finit.. mais quand les 45 minutes ont sonnés, ils nous manquait .. 5 ou 6 lignes de tests pour prouver qu’on avait fini …’ Et on a du faire un rm -rf * … Donc on a pas fini. Et on était dégoûté. Parce qu’on était si proche ..  Mais pour arriver si proche du but (qui n’est même pas le but à atteindre), on avait du contourner les règles. En se disant ‘bon tant pis allez, on fait comme si’.

Je ne pensais pas qu’il me serait aussi facile de lâcher la consigne pour le plaisir d’atteindre un but auto fixé, juste par ‘égo’.
Et sur notre métier et la façon de le faire. Il y a quelques temps, j’avais suivi / lu quelques conférences qui parlait de l’importance de la documentation pour du code (mais de la vrai doc, pas juste des commentaires dans le code). Et sur le fait que la doc pouvait même être plus importante que des tests. Et qu’à choisir entre pas de tests ou pas de doc, il valait encore mieux ne pas avoir de doc.

Sur le coup, j’avais trouvé ça bizarre, voir plus. Après tout la doc c’est le code non ? Et les tests ? Mais j’avais entamé une réflexion sur le sujet.

Et cette code retreat a été un des éléments qui m’a fait comprendre que rien ne pouvait remplacer la doc. Et sûrement pas les tests. Nous avons en effet du faire une session en muet, où la seule communication entre moi et mon binôme c’était les tests. C’est à dire qu’un des membres du binôme écrivait un test, passait le clavier à son compère, celui-ci devait écrire le code qui passait le test puis un nouveau test, et ainsi de suite ….
Ce fut pour notre binôme, mais pour tout les binômes en général, une vraie bérézina. Et pourtant le problème a résoudre était simple, on le connaissait tout les deux. Mais l’enfer ..

Au final, les tests c’est bien pour tester. Pour expliciter des décisions de design de code, des choix d’algo, un parti pri méthodologique, j’en suis de plus en plus convaincu, c’est tout pourri et une vrai doc, c’est mieux !

Pourquoi je vous parle de cela maintenant, en octobre ? Parce que j’ai pas vraiment eu (pris) le temps d’écrire ce billet avant mais que là,  une code retreat s’organise à Marseille, le 14 décembre. Cette retreat du 14/12 était le petit aiguillon qui me manquait pour écrire un billet sur le sujet.

Parce que même si je ne pourrais malheureusement pas y être présent (et ça me chagrine énormément), je ne pouvais pas ne pas expliquer pourquoi c’est bien et pourquoi il faut y aller 🙂

(Juste une dernière chose, les code retreat sont des moments où il faut savoir preuve d’humilité. Y aller en mode ‘ninja’, ‘je vais leur apprendre comment il faut coder moi à ces codeurs du dimanche’, sans arriver à se questionner sur ses pratiques et sur leur améliorations possible, n’est pas une bonne chose. Voir une très mauvaise. Parce que vous allez vous y ennuyer et ne rien en apprendre, mais en plus vous allez occuper la place de quelqu’un qui aurait pu en ressortir avec un vrai gain … )