Au détour d'une naviguation web fortuite mais bienheureuse, je suis tombé sur CipherSaber. Vous savez, c'est ce genre de moment où on tombe sur une initiative sympa, facile à suivre et qui fait sens. Bref, j'ai accroché tout de suite, alors j'ai laissé tomber ce que j'étais en train de faire et y ai consacré mes heures suivantes.
CipherSaber, c'est la reprise du concept selon lequel il faut en savoir faire un minimum, tout seul, comme un grand. A l'instar des Jedis dans l'univers Star Wars qui vont réaliser eux-même leur sabre laser (vous comprenez maintenant le nom du projet), on nous propose de réaliser nous-même notre petit logiciel de chiffrement. Je vous laisse parcourir le site pour une explication plus en détail de la philosophie derrière ce petit combat pour la cryptographie, mais l'idée est là : A n'importe quel moment, nous devrions être capable de produire un logiciel de chiffrement suffisamment solide pour être utilisé sans risque, afin de s'affranchir des éventuelles lois contre l'exportation et garantir notre liberté de parole, autant que faire se peut. Joli programme !
Voici les instructions que l'on nous fournit pour réaliser cet outil (directement traduites depuis le lien du début de l'article) :

1. Utiliser l'algorithme de chiffrement ARCFOUR (ou RC4), tel que décrit par exemple ici.
2. Chaque fichier chiffré se compose d'un Vecteur d'Initialisation (IV) de 10 octets, puis du contenu chiffré. Un nouveau vecteur aléatoire devra être généré à chaque chiffrement de fichier.
3. La clé de chiffrement se compose elle de la clé que l'utilisateur nous fournit suivie de ce même Vecteur d'Initialisation.

Et effectivement, ce sont les seules indications dont nous aurons besoin. Une fois le programme réalisé, nous aurons la possibilité de déchiffrer un certificat en gif, preuve de notre petite réussite. Si l'idée vous plait et que vous souhaitez vous contenter de ces informations pour vous-même construire votre CipherSaber, alors ne revenez lire la suite de cet article que quand vous aurez votre certificat !

ARCFOUR ?

ARCFOUR, c'est l'algorithme libre identique au RC4 qui lui est une propriété de RSA Security. Ici, pas de clé publique/privée, pas d'algorithme alambiqué, mais une solution implémentable "de tête", pour peu qu'on fasse l'effort de la comprendre et d'en retenir les fondements.

Bon, ok, c'est gentil, mais le ARCFOUR moi, je ne le connais pas. Qu'à cela ne tienne, il suffira de suivre le lien donné ou de rechercher RC4 sur le web pour que l'algorithme nous tombe tout cru, ou presque. Mais j'insiste, le but ici est de pouvoir à tout moment réécrire ce logiciel de mémoire, donc on apportera un soin tout particulier à en retenir les principes de fonctionnement.

C'est un algorithme de chiffrement à flot, il repose sur deux phases :

1. A partir de la clé K que nous donne l'utilisateur, on va générer un tableau d'état S que l'on va mélanger de nombreuses fois afin d'obtenir une suite de chiffres pseudo-aléatoires.
2. On va ensuite chiffrer le contenu sensible par un simple XOR entre ses octets et ceux du tableau d'état. Si c'est votre tout premier pas dans le monde de la cryptographie, sachez que l'opération XOR est "réversible" (il y a sûrement un terme mathématique approprié à cette propriété, pardon à eux pour mon ignorance), c'est à dire que si A xor B = C, alors A xor C = B. On utilise donc exactement la même procédure et la même clé pour chiffrer et déchiffrer.

Maintenant qu'on saisit la généralité de la méthode, voyons comment la réaliser plus en détail :

1. Créons notre tableau d'état :
   1. Soit la clé K d'une taille de 256 octets (si elle fait moins, on la répète à la suite jusqu'à obtenir 256 octets pile)
   2. Construisons un tableau S de 256 valeurs, chacune contenant son index basé à 0 : S[0] = 0, S[255]=255.
   3. Mélangeons S, avec i allant de 0 à 255 et j démarrant à 0:
      1. Inverser l'élément i de S avec celui de rang (S[i]+K[i])+j, j étant le rang du "mélangé" précédent. Autrement dit, ajouter S[i]+K[i] à j et inverser S[i] et S[j]
2. Chiffrons :
   1. Boucler sur chaque octet du fichier à chiffrer, et avec i et j démarrant à 0 :
      1. incrémenter i
      2. Un peu comme précédemment, inverser l'élément i de S avec celui de rang (S[i]+j), j étant le rang du mélangé précédent. Autrement dit, ajouter S[i] à j et inverser S[i] et S[j]
      3. Combiner l'octet à chiffrer avec la valeur de l'élément S[i]+S[j] par un XOR.

J'ai conscience que ce n'est sûrement pas clair au premier abord, mais j'ai essayé ici de résumer l'algorithme par ses opérations logiques, afin que ce soit appréhendable pour l'esprit et donc plus aisé à retenir. Pour une version plus proche de l'implémentation, il vous reste votre moteur de recherche préféré. Retenez par contre un détail important : Chaque éléments de chaque tableau est un octet, il en va de même pour i et j. Par conséquent, chaque addition se fait modulo 256.

Une fois votre implémentation écrite, n'hésitez pas à la tester. Un petit chiffrement/dechiffrement pour s'assurer que tout va bien ne sera pas de trop, croyez-moi.

IVs et tests

Maintenant que votre ARC4 est implémenté et testé, reste à en faire quelque chose. Oui car utilisé tel quel, c'est un algorithme tout à fait prévisible, or nous recherchons un chiffrement suffisament fort. La règle qui semble être celle de base, c'est qu'un même chiffrement appliqué à un même fichier ne doit pas donner le même résultat. L'idée est donc d'ajouter un IV, l'Initialisation Vector dont on parlait plus haut. Ainsi, lors du chiffrement, on va générer un IV aléatoire de 10 octets, qu'on va :

• Mettre à la suite de la clé que nous a fourni l'utilisateur pour produire une clé unique à fournir à l'argorithme de chiffrement
• Ajouter en clair au début du fichier crypté, afin quand même que l'on puisse connaitre la clé à utiliser pour déchiffrer.

L'IV est donc une donnée "publique" puisqu'en clair, mais cela suffit à notre besoin de non-répétition. Par contre son choix est important, crucial même, alors attention à la méthode de génération pseudo aléatoire que vous allez utiliser.

Et voilà ! Une fois ce dernier détail implémenté, il ne vous reste plus qu'à tester votre programme sur les fichiers chiffrés fournis sur le site. Si vos tests ne fonctionnent pas, vous trouverez dans la FAQ quelques points à vérifier dans votre code pour trouver le bug. Voici ceux qui m'ont servi :

• Si vous programmez en C/C++, ouvrez vos fichiers en binaire... On aurait tendance à l'oublier.
• Double, triple-vérifiez vos index et les combinaisons de tailles, ajout, suppression, décalages.

Aller un peu plus loin

Ainsi que vous avez peut-être lu quelque part, certaines faiblesses ont été décelées dans l'ARC4. Elles sont notamment à la base des attaques contre le protocole WEP maintenant si rapides qu'on peut faire tomber un réseau Wifi en 15 minutes. L'auteur recommande donc de passer à... CipherSaber 2 ! <Musique épique, et là avouez, ça picote !>

En fait ce n'est qu'une petite évolution de votre programme actuel : le moyen le plus simple de sécuriser son CipherSaber est de démultiplier le nombre de mélanges de S. Ainsi, à l'étape 3 de la création de notre tableau d'état décrite ci-dessus, on va non pas effectuer ce mélange complet de S une fois mais N fois, N étant une donnée qu'il faudra bien évidemment connaitre lors du déchiffrement. Pour être tranquille, utilisez un N de 15 ou 20.

Aller vraiment au bout de son sabre

Mais toute bonne votre méthode de chiffrement soit-elle, si vous utilisez une passphrase de 3 lettres ou votre date d'anniversaire, tout cela n'aura servi à rien. Ce n'est pas le but de l'article que de décrire un moyen efficace d'en générer une, mais sachez qu'il existe des méthodes comme celle décrite sur Diceware (c'est depuis ce site que j'ai découvert CipherSabre, ce n'est donc pas par hasard que je met ce lien ici). Retenez tout de même qu'un mot de passe n'est pas une.. hm, et bien phrase de passe. Le premier est adapté à un contexte local, lorsque vous avez besoin d'un mot court à entropie forte. La passphrase, de ce que j'en comprend, permet de s'affranchir plus ou moins du coté "impossible à retenir" d'un vrai de mot de passe fort, en augmentant la taille de la clé à 15 ou 20 caractères avec des mots courants, tout en fournissant pour peu qu'elle soit bien choisie (aléatoire) un entropie plus que satisfaisante.

Et alors ?

Et bien voilà, maintenant vous savez écrire un logiciel de chiffrement. Gardez bien-sûr conscience qu'il ne remplacera jamais une vraie solution comme OpenPGP, qui malgré sa puissance est deja suffisament mal diffusée pour qu'on n'en rajoute pas à vouloir utiliser notre solution personnelle moins pratique et moins sûre. Mais enfin, à votre niveau vous savez reproduire tout seul un outil basique mais potentiellement utile en situation réelle, vous avez limité votre dépendance à ceux qui savent, ceux qui dirigent, ceux en qui on vous demande d'avoir une confiance presque aveugle. Et enfin, vous en aurez un peu appris sur les fondements de la cryptographie, peut-être plus qu'en jouant avec AirCrack sur votre propre réseau ou celui du voisin...

Cela fait maintenant un moment que j'apprends et pratique la programmation fonctionnelle, aussi bien sur le point de vue théorique en m'intéressant à ses relations avec la théorie des catégories (mathématiques) entre autres, que sur le point de vue pratique, c'est à dire que j'ai mené quelques projets (de petite envergure... oui, c'est proportionnel au temps que je peux passer dessus) à bien.

Quand on dit "langage fonctionnel" ou "programmation fonctionnelle", les gens s'imaginent (pour ceux qui ne connaissent pas) des programmes avec tout un tas de fonctions, c'est tout. Ce n'est pas ça la programmation fonctionnelle. Enfin biensûr il y a des fonctions, mais la programmation fonctionnelle ne s'arrête pas là.

Déjà, la programmation fonctionnelle, c'est une toute autre façon de concevoir des programmes. Détailler toutes les différences avec la programmation impérative serait pire que les 12 travaux d'Hercules et c'est pourquoi je ne le ferai pas. Je vais toutefois vous parler des points qui font que je suis désormais adepte de ce style de programmation.

Tout d'abord, étant assez orienté mathématiques, il y a une première chose qui me plaît. Dans les langages de programmation fonctionnelle (du moins la plupart), on définit des types, des opérations sur ces types, le tout très simplement et de manière on ne peut plus cohérente.

Ensuite, pour les langages fonctionnels compilés et typés statiquement, on est généralement accompagné d'un compilateur très strict, qui tentera d'éliminer un maximum d'incohérences (comprendre "erreurs") en nous envoyant des erreurs très précises en rapport avec le fait que nous n'avons pas bien typé des parties de notre programme. De plus, les 3 langages majeurs pour une utilisation "real world", Haskell, OCaml et F#, ont vu leur compilateur se doter de l'inférence de type ; il s'agit de la capacité qu'a un compilateur a donner lui-même un type à vos valeurs dans le programme (fonctions, expressions, ...). Entre ceci et la vérification des types, la compilation possède une part de travail autour des types en action dans votre code.

De plus, en programmation fonctionnelle, il s'agit de ne pas avoir ce que l'on appelle des effets de bords ; on parle de programmation fonctionnelle pure ; dans un tel cadre, une fonction à qui l'on donne les mêmes entrées renverra toujours la même sortie. Les programmeurs fonctionnels font en sorte d'isoler les parties pour lesquelles ce n'est pas vrai (lecture d'un fichier, intéraction réseau, ...) : monades en Haskell, on laisse la possibilité de faire de l'impératif pour OCaml et F#, ...

Continuons sur la curryfication. Cette dernière consiste à faire par exemple d'une fonction de 2 arguments 2 fonctions à 1 argument, qui pourront s'appliquer partiellement. Si l'on définit une fonction "add" pour ajouter 2 nombres x et y, alors on pourra appliquer add à son premier argument, x, en lui donnant par exemple la valeur 12, pour obtenir une fonction à UN SEUL argument qui additionnera son argument à 12.

Les fonctions sont capitales en programmation fonctionnelle. Contrairement à dans un certain nombre de langages (beaucoup), les fonctions peuvent être stockées, passées en argument, construites à la volée, retournées par d'autres fonctions, etc. Elles deviennent des valeurs de première classe.

A propos du passage en argument, une chose très importante en programmation fonctionnelle est la possibilité d'abstraire une partie des algorithmes et d'en confier la responsabilité à une fonction donnée en argument par exemple. Une fonction qui prend une autre fonction en argument est appelée "fonction d'ordre supérieur". Cela permet de factoriser un maximum de code tout en laissant la variabilité possible grâce au passage de fonction en argument. Le compilateur fera les vérifications nécessaires pour voir si les types concordent, ne vous inquiétez pas.

La paresse est également quelque chose qui s'avère bien sympathique parfois. Il s'agit de n'évaluer une expression qu'au moment où l'on en aura besoin (affichage du résultat de l'évaluation de l'expression -- comme une addition -- par exemple). Elle est mise en oeuvre différemment selon les langages (implicitement en Haskell, c'est le compilateur qui gère cela, alors que c'est explicit en OCaml -- module Lazy).

Tout cela, rajouté aux syntaxes assez simples, donne une très grande expressivité aux langages fonctionnels, proche de l'expressivité que l'on a en mathématiques. Qui plus est, rappelons-le, les langages fonctionnels sont des langages dits "déclaratifs". On exprime le problème, on obtient la solution, contrairement à ce que l'on fait dans un langage impératif où l'on doit donner toutes les étapes à la main nous-mêmes.

Bref, beaucoup d'avantages, un tout nouveau style de programmation, cela ne vaut-il pas le détour ? Allez, si vous voulez en savoir plus, voici quelques liens essentiels pour terminer ce billet sur la programmation fonctionnelle.
Cours d'introduction à OCaml de Damien Guichard -- dont je me suis beaucoup servi et que j'apprécie beaucoup
Traduction de "A gentle introduction to Haskell" -- un peu rude pour débuter, mais vous fera comprendre pas mal de choses.

N'hésitez pas à utiliser le forum pour donner vos avis et retours d'expérience ou pour des questions, bien évidemment !

Étant tombé amoureux du langage OCaml, et comptant propulser cette activité de blog sur Coder-Studio, j'aimerais savoir ce que vous, amateur du langage OCaml, de la programmation fonctionnelle en général ou tout simplement curieux, vous souhaiteriez lire en rapport avec OCaml sur notre site préféré

Alors ?
Quelques grandes lignes qui pourraient intéresser :
- OCaml et les maths (comme mon billet précédent)
- OCaml et les GUIs
- OCaml et le multimédia (OCamlSDL, OCaml/OpenGL, ...)
- OCaml et la conception de compilateurs/interpréteurs (lexing, parsing, etc)
- ...

Merci de donner votre avis !

J’ai quitté l’équipe de Simerion, après 5 ans de conception et développement, il y a un peu plus d’un mois pour différentes raisons que j’aborderai plus loin. Mais je profite de ce billet pour faire une sorte de bilan du projet, de mon point de vue. L’idée étant de faire un retour d’expérience afin de pointer du doigt ce que nous avons pu apprendre mais aussi afin de mettre en évidence les erreurs que nous avons commises. Le tout dans l’espoir de pouvoir aider des personnes s’engageant dans un projet similaire.
Tout d’abord, je précise que le jeu n’est pas arrêté. Il est toujours en développement, je n’ai fait que quitter l’équipe. Donc si mon article vous donne envie d’en savoir plus ou de rejoindre l’équipe de développement, n’hésitez pas à vous rendre sur www.simerion.fr

Tout d’abord, un rapide historique :

2005 : Wett et moi-même avons ressorti du fond d’un tiroir les bases d’un projet que j’avais esquissé 2 ans plus tôt. Durant 5 mois nous mettons ainsi à plat toutes nos idées sur un forum et wiki. Mais très rapidement nos études respectives (classes prépa) nous ont poussées à mettre en pause le projet.
Juillet 2006 : Un an plus tard nous reprenons notre projet en main et continuons à travailler sur la conception durant un mois de manière soutenue.
Août 2006 : Nous commençons enfin le développement et devenons membre de l’association Nainwak qui nous hébergera par la suite.
Août 2007 : Un an plus tard, avec l’aide d’Altheran qui nous a rejoint en mars, nous sortons notre première version alpha avec une cinquantaine de joueurs.
Mars 2009 : Plus d’un an et demi plus tard, la beta alors que je quitte l’équipe.

Voici donc une suite de points, qui maintenant avec le recul me semblent importants à souligner.

Travailler en équipe

A travers ce projet j’ai pu découvrir la nécessité de travailler à plusieurs. Et cela pour plusieurs raisons. Tout d’abord afin de s’entre-motiver lorsque certains d’entre nous sont démotivés. Voir d’autres personnes travailler sur le projet peut très facilement nous remonter à bloc. Le développement d’un jeu web comme Simerion ne doit pas se faire en comité réduit. Attention l’effet inverse n’est pas pour autant une bonne idée. S’entourer de trop de monde peut être néfaste pour le projet. Il faut prendre le juste nombre de programmeurs, en prenant en compte leurs disponibilités et leurs compétences.

Bien choisir son langage

Notre choix s’est porté initialement sur le PHP couplé à de l’Ajax afin de bénéficier d’un jeu accessible partout depuis Internet avec une grande interaction avec les joueurs. Pourquoi le PHP ? Parce que ce langage m’était déjà familier et était simple à prendre en main. Cependant avec le recul, nous n’aurions sans doute pas dû employer celui-ci préférant sans doute le JAVA ou le C++ afin de réaliser un véritable MMORPG. A maintes reprises nous nous sommes mordus les doigts quant à notre choix de technologie. Nous avons très rapidement atteint les limites du PHP et de l’Ajax. Nous avons été bridés par nos choix initiaux qui nous ne ont pas permis pleinement de faire ce que nous souhaitions réaliser. Mais il était trop tard pour changer.
Je conseille vraiment au départ de faire le tour de toutes les technologies lorsque l’on s’aventure dans un projet web d’ampleur. Chaque langage possède ses avantages et inconvénients qu’il faut comparer. Nous ne l’avons pas fait, et cela nous a desservis.

Ne pas réinventer la roue

Une autre erreur que nous avons commise a été de ne pas faire le tour des Frameworks PHP et Ajax existants. En jeunes fous que nous étions, nous avons créé notre propre moteur de jeu de A à Z et notre propre Framework Ajax. Nous avons réinventé la roue et avons perdu un temps fou. D’un autre côté, nous ne savions pas forcément que des outils tout fait existaient, cela nous a toutefois permis de comprendre le fonctionnement d’un certain nombre de techniques et technologies. Mais si c’était à refaire j’utiliserais au maximum des outils déjà disponibles.
Avant de commencer un projet conséquent. Je pense qu’il faut vraiment regarder, comparer les outils à sa disposition et ne pas fonce dans le tas tête baissée. Utiliser des outils déjà faits peut faire réellement gagner un temps précieux.

Utiliser des schémas et diagrammes UML

L’utilisation de diagrammes UML est assez primordiale. Il est difficile d’être rigoureux sur la durée afin de mettre sur papier les idées avant de coder. Mais c’est un mal pour un bien au final, car c’est un gain de temps non négligeable. Toutefois les diagrammes UML ne sont utiles que si l’on ne change pas d’idée en permanence. Auquel cas, les diagrammes sont en permanence remis en cause, ce qui est pour ce coup-ci une grosse perte de temps.

Eviter l’approche du « tout objet »

L’approche objet d’un jeu web est assez complexe. A première vue, le « tout objets » peut sembler être une bonne chose, mais les objets ne sont pas les amis des bases de données. Qui dit objets, dit attributs, et qui dit attributs dit base de données derrière chargée et mise à jour en permanence. Travailler avec les objets et leurs instances implique d’optimiser en permanence le code afin que le serveur ne s’écroule pas sous les requêtes SQL. Par exemple, si je veux charger une instance d’appartement d’un joueur dans Simerion, nous devons charger un objet qui va définir son type (classe), puis un objet qui va définir son instance de conteneur (bâtiment) ainsi que la classe de celui-ci. Vu que nous avons besoin parfois de localiser cet appartement, nous avons besoin de charger la région dans laquelle se trouve notre bâtiment (une table supplémentaire). Comme il y a plusieurs planètes il faut également charger sur quelle planète se trouve cette région (une table de plus). Au final la création d’un objet devient pharamineuse en terme de ressources, nécessitant une flopée de requêtes SQL. Imaginez comment charger des collections entières d’appartements... De quoi mettre à terre le serveur. Nous sommes alors obligés d’optimiser en nous éloignant peu à peu du système classique d’objets. Travailler en objet est intéressant, mais dès que l’on se met à travailler sur des pages qui vont recevoir énormément de visites, l’intérêt en prend un sérieux coup.
Je pense qu’il n’y a pas de solution absolue et qu’il faut privilégier les objets pour la maintenabilité du code. Par contre, en ce qui concerne le lien avec les BDD, il faut trouver un compromis et essayer de s’éloigner du schéma classique qui consiste à tout charger lors de la création de l’objet. Je pense qu’il suffirait de regarder du côté des gros Frameworks ce qu’il se fait en la matière. La liaison avec la BDD est une chose assez pointilleuse et complexe, je pense que même au bout de 5 ans, le code n’est pas optimisé au maximum de ce côté-là. Par conséquent, aller voir les outils qui existent déjà peut être d’une très grande aide.

Ne pas remettre en question son code en permanence

Une des choses qui nous a fait le plus perdre de temps a été la permanente remise en question de notre code. C’est bien plus facile à dire qu’à faire, mais il faut à tout pris se contenter au plus tôt de son travail pour avancer de l’avant. De la même façon, il faut éviter d’optimiser à mort tout et tout de suite, il faut le faire au fur et à mesure en trouvant un juste milieu. J’aborderai plus loin la question du travail étape par étape, mais il est très très important, d’après l’expérience que j’ai tirée de Simerion, de se contenter de ce qui fonctionne et aller de l’avant pour avoir du concret et non pas du code en permanence remanié. Une fois que le code fonctionne il est alors possible de l’optimiser, mais il faut viser à mon sens le fonctionnel avant de foncer tête baissée sur la sécurité et l’optimisation du jeu.

Bien choisir son cycle de développement

Le choix de notre cycle de développement n’a définitivement pas été le bon. Et ce dernier est à mon sens la raison de notre (mon) échec. 5 ans ! Nous avons passé 5 ans sur ce projet et toujours pas de jeu jouable en version publique à mon départ … C’est entre autres une des raisons de mon arrêt. C’est même un exploit d’avoir tenu aussi longtemps. Nous avons choisi en effet de n’ouvrir le jeu que lorsqu’une version du jeu serait suffisamment jouable pour retenir le joueur. Or, le principe de Simerion est de pouvoir tout faire. Tout est interdépendant, et tout s’équilibre. Il est alors impossible de sortir une version jouable tant que TOUT le jeu n’a pas été programmé. Quelle erreur nous avons faite ici !
Dès que le concept est posé sur papier un jeu amateur doit, selon moi, sortir au plus vite en production. A la fois pour avoir des retours des joueurs, mais aussi afin de se motiver dans son travail de développement. C’est extrêmement déprimant de ne pas avoir de retour de joueurs avant des mois, voir des années dans notre cas. La motivation est naturellement en constante baisse, et pas un joueur pour vous rebooster. Il ne faut compter que sur les membres de l’équipe qui eux aussi sont en manque de motivation.
Donc vraiment je conseille vivement de développer les jeux web sur des versions fréquentés par les joueurs (tout du moins pour les jeux amateurs). Il faut sortir régulièrement les versions de développement et surtout ne pas attendre aussi longtemps que nous entre chaque version. En faisant cela on entretient la communauté de joueurs qui nous supporte et nous est très utile, et on entretient notre motivation dans le projet. Sans cela, tout s’effondre au bout de X mois ou années. Et tout l’investissement aura été vain.

Créer une communauté autour de son jeu

Comme je le disais précédemment, il est nécessaire de s’entourer dès le début d’une communauté de joueurs. Ces derniers pourront tester votre jeu, donner leur avis, proposer leurs idées d’améliorations etc. N’ayant pas lancé de version jouable durable de Simerion, nous n’avons pas eu de communauté derrière nous pour nous soutenir dans notre développement. Et c’est une conséquence très négative, qui va avec notre mauvais choix de cycle de développement.
Je conseille donc vraiment de travailler dès le début à la création d’une communauté entourant le projet à la fois pour y puiser de la motivation, mais aussi afin de se faire aider. Car bien souvent, la communauté gravitant autour de votre jeu est source de nouveaux membres pour votre équipe de développement.

Les amateurs ne peuvent pas rivaliser avec les pros

Cela fait mal à dire, mais la création d’un jeu RPG complexe n’est pas à la portée d’une équipe d’amateurs. Qu’on me montre le contraire et j’en serais ravis ! Mais le fait est que la création d’images, de décors, d’histoires, de scénarios, de quêtes et de missions nécessite un travail pharaonique. J’ai les 95% du temps endossé le rôle du développeur, du scénariste et de l’illustrateur à la fois. Ceci est quasiment impossible à gérer dans un tel projet. Idéalement il faudrait avoir dans son équipe au moins un graphiste / illustrateur et plusieurs scénaristes pour remplir le jeu. Mais il s’agit d’atouts rares, et il faut bien souvent ne compter que sur soi même. Sur cet aspect je suis assez pessimiste hélas, je pense qu’un jeu de l’envergure de type Fallout, Baldur’s gate, Final Fantasy, ou même Zelda n’auraient pas pu être réalisés par des amateurs. Cela demande trop de travail en dehors de la partie programmation. Le jeu ultime est à mon sens impossible à développer par des amateurs, hélas… A mon sens, un jeu amateur ne doit pas voir trop gros dès le départ. Il faut y aller au fur et à mesure, en se faisant plaisir et tout en gardant à l’esprit que nous ne pouvons pas rivaliser avec les grands. Le jeu ultime amateur n’est pas réalisable, cela demande beaucoup trop de travail. Avec Simerion nous sommes partis sur un concept trop complexe, trop utopique … La clé de la réussite est un cadrage dès le départ qui trouve un compromis entre un concept novateur et le minium de code possible.

Tenir un cahier des charges et une documentation à jour

Un point important dans le cycle de développement réside dans la tenue d’un cahier des charges et d’une documentation à jour. En effet, il n’est pas rare de mettre en pause le projet pendant X mois. Et reprendre le code après une période d’inactivité est vraiment très difficile (même pour du code tapé soi même). Le cahier des charges permet de garder une vue globale sur le projet avec un certain recul, il vous permet de poser au clair toutes les idées et mieux structurer ses idées. La documentation permet, elle de son côté d’expliquer le fonctionnement du jeu (aspect technique) mais aussi d’expliquer pourquoi tel ou tel choix d’algorithme. La documentation peut vous faire gagner un temps fou pour vous remettre dans votre code, ou pour comprendre le code d’un autre programmeur. Ces deux outils permettent également l’intégration de nouveaux membres à l’équipe de développement (chose à laquelle on ne pense pas forcément). Le fait est que Simerion est devenu une véritable usine à gaz et que plusieurs personnes se sont cassées les dents à essayer de comprendre notre code pas toujours commenté ni expliqué. Le manque d’explication peut alors être un frein au recrutement de nouveaux développeurs.

Se faire soutenir

Nous avons rejoint dès le départ l’association Nainwak, qui nous a hébergés, soutenus et conseillés. Nous n’aurions sans doute pas tenu autant de temps sans elle. Nous avons même eu la chance grâce à elle d’être exposant à 2 reprises au festival du jeu vidéo. Nous avons pu rencontrer des professionnels qui ont été intéressés par notre jeu. Cela fut une expérience très enrichissante.
Je conseille vivement à toute personne se lançant dans un jeu web sérieux de contacter Nainwak. La mission de cette association est d’aider les amateurs, et elle y travaille à merveille.

Bilan

J’ai complètement arrêté Simerion tout d’abord parce que je ne prenais plus aucun plaisir à travailler dessus. Le développement était devenu interminable et j’avais besoin de passer à autre chose. A cela se sont ajoutés des problèmes de santés plus une saturation du web en général. Abandonner Simerion alors que ce projet me tenait tellement à cœur a été une chose très difficile, mais je pense qu’au bout de 5 ans, il fallait simplement passer à autre chose.
Simerion a été une expérience vraiment très enrichissante. J’ai pu apprendre énormément et rencontrer beaucoup de monde. Mais je pense que si nous nous étions pris autrement dès le départ nous aurions sans doute bien mieux réussi, et je serais encore sur le projet. Mais tout cela fait partie de l’apprentissage. C’est chuter pour mieux se relever et mieux démarrer mes prochains projets.
Toutefois, nous nous sommes lancés dans un concept dément, où tout devait être possible. Le jeu ultime en quelques sortes. Un tel jeu n’est tout bonnement pas réalisable et complètement utopique (A moins d’être un studio de jeu vidéo avec de la monnaie sonnante et trébuchante pour assurer le coup). Mauvais choix de départ, concept trop ambitieux, mauvaise démarche de développement, réinvention de la roue ont été autant d’erreurs qui ont amenés Simerion à ne pas arriver au point escompté. On apprend de ses erreurs et j’espère que les nôtres pourront vous êtes bénéfiques également.

Un billet à propos d'OCaml, encore. Je me suis amusé à implémenter la construction de l'Ensemble de Cantor (version anglaise un peu plus complète). Vous voulez en savoir plus ?

Première étape, il me fallait une fonction qui à partir d'une liste et d'un couple (a,b) de nombre réels, représentant l'intervalle [a,b], rajoute les deux intervalles qui en sont générés par une itéraction de la construction de l'ensemble de Cantor, c'est à dire les intervalles [a, (2a+b)/3] et [(a+2b)/3, b], à la liste. Voici la fonction en question, appelée cantor_step ici :

let cantor_step l (a,b) =
 (a, (a +. a +. b) /. 3.) :: ((a +. b +. b) /. 3., b) :: l

Ensuite, il fallait une fonction qui permettre d'appliquer cette fonction sur une liste de couples (a,b) pour passer d'une liste d'intervalles à une autre, c'est à dire passer à l'étape suivante de la génération de l'Ensemble de Cantor. J'ai par la même occasion profité pour rajouté un paramètre n permettant de réaliser cela n fois. J'ai appelé cette fonction map_n.

let map_n f l n = match l with
  | [] -> []
  | l -> aux l n 
      where
	rec aux l = function 
	  | 0 -> l
	  | k -> aux (List.fold_left f [] l) (k-1)

List.fold_left est ce que l'on appelle un "pliage" (fold en Anglais). Pour vous familiariser avec ces derniers, une recherche sur "functional programming fold" devrait vous apporter le nécessaire ). Il permet de parcourir la liste d'une certaine façon en appliquant une certaine fonction sur l'élément courant et le résultat de ce qui a été fait jusque là de la même façon, et ainsi de suite.

Enfin, définissons une fonction nth_cantor qui permet d'obtenir la liste des intervalles qui constituent la n-ème itéraction de la construction de l'Ensemble de Cantor.

let nth_cantor = function
  | 0 -> [(0.,1.)]
  | k -> map_n cantor_step [(0.,1.)] k

On voit donc que l'on part de l'intervalle [0,1], et que l'on va répéter k fois l'itéraction.

Deux fonctions utilitaires, dont une qui utilise non pas le module List standard mais le module List de OCaml Batteries Included, pour la fonction print. (en fait, List.fold_left ci-dessus est également celui de OCaml Batteries Included, étant donné que le programme sera compilé avec OCaml Batteries Included).

let couple_printer output (a,b) = Printf.printf "(%f,%f)\n" a b
 
let list_printer l =  (* List.print couple_printer stdout l ;*)  Printf.printf "\n%d intervals in list\n" (List.length l)

La première permet d'afficher un couple de réels depuis ... un couple de réels.
La seconde permet d'afficher une liste en précisant quelle fonction utiliser pour afficher chaque élément. Elle affiche ensuite la taille. Ici, le passage d'affichage des éléments est commenté (entre (* ... *)) car ayant testé mon code avec notamment 25 itérations, on se retrouve avec beaucoup trop de choses à afficher pour que ça soit supportable pour un être humain normal.

Enfin, le code qui est exécuté :

let main () = 
  try 
    let n = int_of_string Sys.argv.(1) in
    let cn = nth_cantor n in
      list_printer cn
  with _ -> print_endline "Use : ./cantor n, where n is an integer" ; exit 0
 
let _ = main ()

Pour terminer, la compilation :

$ ocamlfind batteries/ocamlopt -o cantor cantor.ml

(pas d'optimisation ici, si vous les voulez, rajouter -cc -On après ocamlopt)

Et on exécute :

$ time ./cantor 25
33554432 intervals in list

real 0m25.553s
user 0m23.481s
sys 0m2.060s

En activant l'affichage des éléments, sur un petit nombre d'itérations :

$ time ./cantor 4
[(0.740741,0.753086)
; (0.765432,0.777778)
; (0.666667,0.679012)
; (0.691358,0.703704)
; (0.962963,0.975309)
; (0.987654,1.000000)
; (0.888889,0.901235)
; (0.913580,0.925926)
; (0.074074,0.086420)
; (0.098765,0.111111)
; (0.000000,0.012346)
; (0.024691,0.037037)
; (0.296296,0.308642)
; (0.320988,0.333333)
; (0.222222,0.234568)
; (0.246914,0.259259)
]
16 intervals in list

real 0m0.013s
user 0m0.000s
sys 0m0.016s

Vous avez surement remarqué que cette méthode ne préserve pas l'ordre des intervalles... Ce n'a pas vraiment été mon soucis premier, et ce serait arrangé avec la méthode décrite ci-dessous.

Au passage, si j'utilisais des arbres binaires pour toutes les étapes intermédiaires et que je produisais une liste depuis cet arbre, je gagnerais pas mal en efficacité, disons que je vous le laisse à titre d'exercice

Enjoy !

PS : la capture d'écran ci-dessus provient d'un programme que j'avais réalisé il y a quelques mois et qui faisait une construction itérative représentée graphiquement, mais la méthode de génération était moins efficace, et j'ai la flemme de refaire la même chose maintenant...

Donc pour rappel, nous avons a notre disposition une classe Factory qui nous permet de créer des instances d'objets héritant tous d'une interface de base.
i.e. Shape était notre interface Cylinder, Sphere nos instance a créer.

Le désavantage principal de l'implémentation était l'obligation d'écrire dans chaque classe une méthode statique créant l'instance :

static Shape *Sphere::create(void);

Heureusement, les template vont encore une fois nous aider a nous abstraire de cette contrainte.

La factory retourne des objets de type Object (paramètre de la classe templatée) elle stocke pour chaque clef une fonction dont le prototype est :

Object *()(void);

L'idée va être de ne plus stocker une fonction mais un objet au sens C++ jouant le rôle de cette fonction.

Dans notre cas, le foncteur a donc une méthode CreateInstance(void) retournant un Object

template  struct InterfaceCreator{
   virtual Object *CreateInstance(void) = 0;
};

on modifie en conséquence la classe Factory :

template  class Factory{
public:
 
// on redéfinit notre nouveau type comme
// etant un InterfaceCreator<object width="100" height="100" type="application/x-shockwave-flash"></object>

Maintenant, il nous faut specialiser des Creator pour notre Sphere, Shape, etc...

template
class Creator : public InterfaceCreator
{
public:
  BaseClass *CreateInstance(void){
     RealClass instance = new RealClass();
     return static_cast(instance);
  }
};

Petite explication de cette double paramétrisation. Nous avons besoin du type réel de l'objet (Sphere) pour le créer et le type abstrait(Shape) pour pouvoir heriter de InterfaceCreator

Passons a l'utilisation :

Factory shapeFactory;
...
 
class Sphere : public Shape{
  ....
  static bool registered;
};
 
bool Sphere::registered = shapeFactory.register("Sphere", new Creator );
bool Cylinder::registered = shapeFactory.register("Cylinder", new Creator );

j'espère que ca vous aura plu un minimum
a+
Twxs