Index — Projets inachevés

Réussir Prologin

2009-10-25T17:17:55Z

Vous êtes un jeune, intéressé par l’informatique et vous venez de découvrir l’existence d’un concours portant sur votre activité préférée, Prologin. Plutôt sûr de vous-même vous décidez de tenter votre chance. Mais bientôt, vous commencez à douter ; mais sur quoi peut bien porter ce concours ? Vous parcourez le site officiel à la recherche de renseignements, mais vous n’êtes pas satisfait. À force d’acharnement, de contacts un peu louches et de recherches Google douteuses vous arrivez sur un billet apparemment peu digne de confiance qui prétend exposer les connaissances requises pour Prologin.

* <----- vous êtes ici

Comme vous le savez sûrement, le concours Prologin se déroule en trois temps : qualification, demi-finale et finale. Il se trouve que la qualification est tellement facile qu’elle est à la portée de tout un chacun. La finale quand à elle est tellement spéciale que la seule préparation efficace à une finale est … une autre finale. Lors de votre première vous ferez probablement n’importe quoi, de préférence en vous amusant et vous vous en contenterez.

Gardez à l’esprit que ce billet n’est qu’un modeste résumé des compétences que prologin requiert et en aucun cas une référence exhaustive sur le sujet.

Rédaction

Premièrement, apprenez à présenter. Plus votre copie sera agréable à lire moins le correcteur prendra de temps pour la lire. Le correcteur est un bénévole, il corrige les copies parce que c’est un mal nécessaire et probablement pas pour le plaisir. Moins il passera de temps à tenter de déchiffrer ce que vous avez écrit plus il sera content. Un code indenté, aéré, coloré et une écriture lisible seront toujours récompensés.

Deuxièmement, accompagnez votre code d’explications claires et concises. Le correcteur n’est pas là pour le plaisir de déchiffrer des codes obscurs. Vous ne risquez donc pas de lui gacher le plaisir en lui expliquant comment votre algorithme fonctionne, au contraire.

Un dicton de programmeur dit : Keep It Simple, Stupid (KISS). Dans la mesure du possible, vous devriez chercher la solution la plus simple. C’est celle qui a le plus de chance d’être juste et en plus les correcteurs la comprendront aisément. Si toutefois vous séchez n’hésitez pas à écrire ce à quoi vous avez pensé. Même si votre algorithme est un peu alambiqué, qu’il ne marche pas tout le temps ou qu’il ne vous satisfait pas en matière d’efficacité n’hésitez pas à montrer au correcteur que vous avez fait l’effort de chercher. Qui sait, peut-être que vous n’étiez pas si loin de la solution ?

Algorithmique

Lorsqu’on conçoit des algorithmes, on est tout particulièrement intéressé par leur efficacité (à plusieurs points de vue) algorithmes, par exemple le temps qu’ils mettent à s’executer.

Ce qu’on nomme complexité d’un algorithme est la quantité de ressources (temps ou mémoire principalement) consommée en fonction de la taille de l’entrée. On utilise généralement des notations appelées de Landau pour obtenir un aperçu du comportement pour de grandes entrées (on parlera de comportement asymptotique) de cette consommation. Ces notions sont abordées et expliquées en détail dans le tutoriel "L’algorithmique pour l’apprenti programmeur" (suivez le lien).

Une structure prépondérante en informatique est celle de graphe. On peut se représenter un graphe par un ensemble de points (qu’on appelle en fait noeuds) reliés par des traits (qu’on appelle en fait arrêtes). Tous les problèmes où vous aurez affaire à un ensemble d’éléments reliés les uns aux autres parlent en fait de graphes. On a fréquemment besoin de chercher un élément dans un graphe. On utilise pour cela des algorithmes de parcours de graphe comme BFS ou DFS. Le tutoriel précédemment cité traite aussi de manière assez intéressante ce sujet, ici par exemple.

Mais puisque toutes les questions ne portent pas sur les graphes (heureusement) introduisons maintenant une autre technique, plus universelle : la programmation dynamique. L’idée est très simple, on conçoit un algorithme qui appelle une fonction récursive, pour optimiser cet algorithme on enregistre les résultats des appels dans une structure de données à temps d’accès constant de sorte que si l’algorithme en vient à appeler deux fois la fonction avec les mêmes valeurs il ne recalcule rien.

Une application basique de ceci est le calcul des nombres de Fibonacci. On définit ,F_0 = 0 et F_1 = 1 et F_(n+2) = F_(n+1) + F_n. Si on utilise un algorithme récursif classique on peut montrer que le calcul a une complexité exponentielle, c’est pas terrible. En fait cela est du au fait que certains nombres de Fibonacci sont calculés plusieurs fois. Par exemple, pour calculer F₄ on calcule F₃ et F₂ puis pour calculer F₃ on calcule F₂ et F_1. On a calculé F₂ au moins deux fois. En utilisant la programmation dynamique on garantit que chaque nombre n’est calculé qu’une fois et on peut donc montrer que l’algorithme a une complexité linéaire. Un programme qui était trop lent est devenu assez rapide.

Une remarque assez importante, puisqu’on utilise une matrice pour accéder aux résultats (ou à l’absence de résultats) de l’appel de la fonction avec des paramètres donnés, ces paramètres doivent être entiers pour pouvoir garantir un accès en temps constant et une occupation mémoire décente. Si vous voulez utiliser la programmation dynamique avec des chaines de caractère, des listes ou je ne sais quoi de différent d’un entier (ou pire, si vous voulez les convertir en entier), vous vous trompez. Toute la difficulté d’un certain nombre de problèmes est justement de se ramener à des paramètres entiers biens trouvés pour réduire le nombre de situations différentes.

Exemple : Le problème du sac à dos, version facile. Soit n objets différents disponibles à volonté de poids p_i entier. On a un sac à dos qui peut contenir un poids P, quel est le poids maximum qu’on peut y mettre à l’aide de nos n objets.

Solution : Ici, on remarque que le problème peut se ramener à résoudre le problème dans le cas où on commence par mettre l’objet 1, puis dans celui où on commence par mettre l’objet 2, etc. Il suffira de prendre le maximum de ces sous-cas qui couvrent bien tout l’éventail des possibilités. L’astuce consiste à voir que deux sous-problèmes ont la même réponse si le poids des objets qu’on considère comme étant de toute façon dans le sac est le même dans les deux cas. Ainsi si on considère le sous-problème où on commence par rentrer 1 puis 2 et celui où on commence par rentrer 3 puis 4, il suffit que p₁ + p₂ = p₃ + p₄ pour que ces deux problèmes aient la même réponse. Le paramètre de notre fonction récursive sera donc la poids cumulé des objets imposés a priori. On commencera par appeler la fonction avec ce paramètre valant zéro. L’algorithme en lui-même est laissé en exercice au lecteur.

Ce sujet n’est malheureusement pas traité par "L’algorithmique pour l’apprenti programmeur" (peut-être cela viendra un jour) ainsi je vous recommande de vous tourner vers des ouvrages certes un peu moins abordables mais bien plus complets comme l’excellente "Introduction à l’algorithmique".

Bien qu’il soit primordial de posséder un certain nombre de bases, il est tout aussi important de savoir ce que vous ne devez pas savoir. Les algorithmes avancés de pathfinding dont vous pourriez avoir entendu parler (Djikstra, A*) ne vous seront d’aucune utilité de par la complexité de leur implémentation (qui utilise par exemple des files de priorité dont l’implémentation optimale est tout sauf triviale). Ne pensez même pas à les utiliser, rabattez-vous sur DFS et BFS.

Je tiens également à vous prévenir de quelques questions classiques des sujets d’écrit. La première question qui vous sera posée est presque toujours la même, "Quelle structure de donnée allez-vous utiliser pour stocker blah ?". Généralement les structures qu’on vous demande sont simples. C’est la première question on n’allait pas vous demander des structures exotiques. Une autre question "piège" c’est l’évaluation du temps d’execution de votre algorithme. Vous venez de calculer la complexité de votre algorithme (O( n² ), par exemple) et on vous donne les paramètres (donc n) et les spécifications d’une machine notamment (ce qui est le plus important) sa fréquence d’horloge, par exemple 500 MHz (c’est-à-dire 500 x 10⁶ instructions par seconde). Il suffit donc de diviser le nombre d’instructions que vous avez à calculer (n² dans ce cas là, il y a des constantes cachées mais on ne vous demande qu’une estimation) par le nombre d’instructions executées par secondes.

Un petit résumé des ressources qui vous permettront d’approfondir le sujet :

"L'algorithmique pour l'apprenti programmeur", tutoriel traitant de manière pédagogique mais malheureusement incomplète des bases de l’algorithmique.
"Introduction à l’algorithmique" de T.H. Cormen, ouvrage de référence sur le sujet mais peut-être un peu trop touffu pour un débutant.
Prologin.org et France-IOI.org, deux sites proposant des exercices pour mettre ces notions en pratique.

Programmation

Il vous faudra aussi être au point niveau programmation et connaissance de votre langage.

On va vous fournir des codes pour gérer les entrées-sorties. Parfois ils marcheront. Parfois non. Vous feriez donc mieux de connaitre les primitives d’entrée-sortie de votre langage, au cas où.

De manière plus générale, il est indispensable de s’exercer à la pratique de son langage pour pouvoir d’une part éviter de faire trop d’erreurs (qui peuvent faire perdre un peu de temps si ce sont des erreurs de syntaxe voire beaucoup si elles sont plus subtiles) et d’autre part les corriger pus rapidement. N’hésitez pas à demander de l’aide (à des amis, sur des forums ou bien encore sur IRC) si vous ne comprenez pas une erreur, vous aurez bien moins d’aide à disposition le jour J !

Là encore je vous conseille de traiter les exercices de Prologin.org et France-IOI.org.

Bonne chance !

OneSwarm, un système peer-to-peer inspiré des réseaux sociaux.

2009-08-29T18:37:11Z

OneSwarm est un logiciel de peer-to-peer dont le but est de garantir l’anonymat au contraire des protocoles du type BitTorrent. Pour cela, l’information sur les fichiers disponibles sur les réseaux n’est plus centralisée dans des trackers mais est au contraire décentralisée. Avec BitTorrent, il suffit de se connecter au tracker d’un fichier pour savoir qui le possède ; avec OneSwarm cela n’est plus possible. Les transferts de fichiers se font en effet qu’avec des pairs de confiance choisis par l’utilisateur. On parle alors d’un système friend-to-friend. Les avantages au niveau sécurité sont clairs : seuls les gens en qui vous avez confiance peuvent voir vos données.

Le paper en question décrivant l’architecture d’OneSwarm est disponible sur leur site.

Deux points sont intéressants dans ce papier sans être trop technique. D’une part, le design de OneSwarm est basé sur une analyse des réseaux sociaux et peer-to-peer existants, d’autre part le moyen démarrer (bootstrap) le réseau est lui aussi intéressant.

L’étude d’un réseau social, lastfm

Le paper commence par une analyse du réseau social last.fm et notamment étudie la structure du graphe social. Par exemple, le chemin moyen pour aller d’un utilisateur A à un utilisateur B passe par 7 utilisateurs ; tandis que les deux utilisateurs les plus éloignés sont distants de 14 utilisateurs. Il est également déterminé la bande passante utilisé pendant les deux semaines durant lesquelles les données ont été récupérées : 4.66 TB. Ce qui ne fait qu’environ 4MB de données transférées par utilisateur, cela est bien en-dessous de la capacité des lignes ADSL actuelles.

D’autres remarques sur le comportements des utilisateurs sont faites :

la majorité des chansons ne sont écoutées que par un seul utilisateur ;
malgré tout, ce sont les chansons les plus populaires qui représentent la majorité du traffic ;
il n’y a pas de corrélation évident entre être intégré socialement et écouter beaucoup de chansons.

La conclusion tirée de cette étude est la suivante : les réseaux p2p ont largement plus de capacité totale que de demandes. OneSwarm se fixe donc pour objectif d’utiliser cet excès de capacité au service de l’anonymat.

Présentation de OneSwarm

OneSwarm n’est pas le premier système friend-to-friend, par exemple freenet et son mode DarkNet proposait un p2p privé de ce type. Un des problèmes des réseaux de ce type, c’est le début : chaque utilisateur étant identifié par sa clé publique, pour ajouter des utilisateurs il doit connaître leur clé publique et les ajouter. C’est là la solution retenue par freenet : l’ajout manuel de clés.

OneSwarm propose une solution originale : au final avec un système d’ami, on dote le système d’une structure de réseau social. Or les utilisateurs sont déjà inscrits dans d’autres réseaux, et il est fatiguant pour eux de toujours reconstruire ce graphe. Ainsi OneSwarm permet d’utiliser un réseau déjà existant pour importer les amis. Pour l’instant ils n’ont l’air que de supporter Google Talk au moyen d’un bot auquel OneSwarm fait des requêtes régulières.

S’en suit une description (étonnamment assez peu technique) du protocole et du fonctionnement interne de OneSwarm.

Avis

Le papier en lui même est très accessible et finalement ce n’est pas tant les connaissances réseaux qui manquent mais plutôt les connaissances en théorie des graphes. Cependant, une question reste, bien que partiellement résolue à la fin du papier. Qu’est-ce qu’apporte au point de vue sécurité et anonymat OneSwarm sur les réseaux type freenet ? À mon avis OneSwarm repose un peu trop sur le concept de friend-to-friend pour assurer l’anonymat (en tout cas la sécurité des transferts en eux-même est très peu évoquée dans le papier). La réponse apportée par les auteurs est la possibilité d’avoir des permissions plus fine. À mon avis, OneSwarm représente un bon compromis entre les performances des réseaux p2p traditionnels et la sécurité des réseaux p2p anonymes.

Le fonctionnel, c'est bien aussi pour les jeux

2009-07-25T17:04:19Z

Cet article a pour but d’exposer les avantages de la programmation fonctionelle dans le cadre dans la création de jeux vidéos. Cet article se base un peu (sinon beaucoup) sur l’expérience personnelle obtenue avec (un)faithful, un hack&slash tour par tour (un rogue-like en fait), ainsi les exemples en sont tirés.

Le dessin

La solution que l’on utilise pour éviter des appels à des routines de dessins un peu partout dans le code est pure et permet de factoriser les dépendances à la bibliothèque chargée du sale boulot.

L’idée est de caractériser ce que l’on affiche ; ainsi on construit un type dessin qui contient toute l’information nécessaire à l’affichage du jeu, un dessin peut être un morceau de texte à afficher, un rectangle à dessiner, tout dépend du type de jeu. Un dessin inclut aussi la position à laquelle il doit être dessiné ; il suffit ensuite d’écrire une fonction dessiner qui sera la seule à faire appel aux routines graphiques.

Ainsi une fonction de dessin retourne une liste de dessins (le fonctionnel c’est aussi l’art d’énoncer les bonnes tautologies) et zou il suffit d’itérer sur les dessins et on a l’affichage de la scène.

Cette méthode possède un avantage assez conséquent, on peut effectuer du post-processing sur les dessins générés — c’est le mécanisme de base utilisé dans les fondus de (un)faithful — autant pour les déplacer à l’écran que pour modifier leur couleur ou le texte affiché. Déplacer la caméra ? Il suffit de décaler tous les dessins d’une fonction linéaire du temps pendant le fondu. Pour ce faire, on préferera utiliser, à la place d’une boucle, des combinateurs sur les listes qui permettent d’exprimer les traitements les plus communs sur les listes de façon plus concise. Ici on utiliserait map qui applique une fonction sur tous les éléments d’une liste et retourne la liste des résultats.

Un monde immuable

En programmation fonctionelle, on préfère ne pas modifier l’état du monde par effet de bord mais plutôt par mise à jour. Cela possède un certain nombre d’avantages. Premièrement, il est très facile de mettre de coté les états pour retourner dans le passé de la partie ou pour faire un replay. Ensuite cela permet d’éviter que n’importe quelle fonction touche au monde, là on sait que chaque fonction ne pourra rien modifier autrement qu’au travers de sa valeur de retour, ça permet de vite retrouver l’origine d’un bug.

On s’en sert également pour organiser la transition graphique entre deux tours, avec une fonction prenant en argument le monde à la fin du tour précédant et le monde au début du tour suivant génère un diff qui sert à une partie des fondus. Bien sûr pour éviter que ce soit une usine à gaz, les garbage collector sont prévus pour ça(en).

Gestion d’événements

Pour gérer les évènements, un des moyens les plus adaptés au fonctionnel est probablement l’utilisation de callbacks. On associe donc à chaque type d’évenements une fonction différente. Ce moyen est très répandu aussi en impératif et en orienté objet. Le fonctionnel rend ça encore plus attrayant en permettant la création de callbacks dynamiquement.

Par exemple, dans (un)faithful, on a une fonction move qui prend deux arguments, le premier est un vecteur désignant la direction du mouvement, le second est le monde, et cette fonction renvoie le monde modifié — on note le type d’une telle fonction vecteur -> monde -> monde. En fait on peut voir cette fonction comme prenant en argument un vecteur et renvoyant une opération sur le monde (monde -> monde) — on écrit alors vecteur -> (monde -> monde). Cette fonction, dite curryfiée, peut alors être appliquée partiellement. Ainsi move (0, 1) est une opération sur le monde qui déplacera le personage d’une case vers le haut.

Cela permet de créer une liste associant des touches appuyées à des opérations sur le monde. Cette liste peut ressembler à :

[(Left, move (1, 0)); (Right, move (-1, 0)); …]

Un compromis à établir : équilibre entre données et fonctions

Il ne faut pas tomber dans un extrémisme du « tout fonction » ; le problème de la fonction c’est que c’est une boîte noire aux yeux de l’appelant, il n’y a aucun moyen de savoir ce qui est fait durant or l’appelant peut vouloir avoir des détails. Si on modélise un effet affectant un joueur par une fonction de type monde -> monde, on va peut être se retrouver à coder des systèmes pour gérer la durée dans chaque effets, etc. Parfois il est intéressant de restreindre les possibilités pour pouvoir automatiser une partie des effets.

Un autre problème des fonctions est la sauvegarde ; il est très difficile (sinon impossible) de sauvegarder une fonction telle quelle, une solution est d’associer à chaque effet une clé, et de stocker une liste constante (clé, effet), ainsi il suffit de stocker la clé (on perd une partie de l’extensibilité offerte par l’application partielle, en pratique on adopte donc un système plus sophistiqué).

Conclusion

Génération aléatoire de maps

2009-07-23T15:31:29Z

(un)faithful

Dans le cadre d’(un)faithful, notre projet pour les Novendiales, nous avons eu à coder un générateur de maps aléatoires.

Traditionnellement, dans un rogue-like les maps ne sont en effet pas dessinées à l’avance mais générées on-the-fly pour offrir une plus grande durée de vie (il est courant de recommencer un rogue-like des dizaines voire des centaines de fois avant de le finir).

De nombreux algorithmes permettent d’accomplir cette tâche. Il y en a des plus ou moins subtils, plus ou moins efficaces et les résultats varient grandement d’un algorithme à l’autre. Au final, c’est surtout une question de goût.

Cet article a pour but de décrire l’algorithme utilisé dans (un)faithful qui sans être révolutionnaire produit des résultats assez satisfaisants.

Imaginez un instant que vous êtes l’heureux possesseur d’un donjon sous-terrain flambant neuf, malheureusement rempli de terre. La façon la plus naturelle de construire un dédale de salles et de couloirs serait de creuser une première salle puis de partir de là en creusant un peu partout. C’est exactement ce que fait le générateur de maps d’(un)faithful.

Un des aspects important du système est qu’on travaille sur des briques élémentaires. Dans (un)faithful leur nombre est limité, ce sont les couloirs et les salles. Les salles se déclinent en plusieurs briques en fonction des monstres qu’on peut trouver dedans, par exemple.

Pour placer ces briques dans notre niveau en construction on maintient une liste des "murs", endroits où on peut placer de nouvelles briques. La liste des briques fournissant des probabilités on choisit ainsi la brique qu’on veut placer. L’algorithme boucle ensuite jusqu’à trouver un mur où il peut placer cette brique. Une fois la brique placée la fonction correspondante renvoie une liste de murs à ajouter à la liste actuelle et il suffit de continuer. Généralement, on définit a priori un nombre de briques à placer.

  ++++++	    ++++++
  +    +	    +    ++++
  +    O	    +    *  +
  +    +	    +    +  +
  ++++++	    +++++++++

O est l’endroit où l’on place la nouvelle pièce.

Cette méthode telle quelle présente un gros inconvénient. Les couloirs ne débouchent génŕalement sur rien ce qui est assez frustrant pour le joueur et peu réaliste. Ainsi, en tant que post-traitement on parcourt la map pour supprimer les bouts de couloir inutiles. Deux cas se présentent alors. Certains couloirs ont simplement besoin d’être amputés à partir du moment où ils deviennent inutiles. D’autres doivent être intégralement supprimés, y compris la porte qui y mène.

      ++++++
  OOOOo    *#####OOO
      +    + +++*++
      +    + +    +
      ++++++ +    +
             +    +
             ++++++

Les deux types de couloirs à enlever. Les O sont des couloirs qui vont être supprimés, le o est une porte qui va disparaitre.

On parcourt toute la carte précédemment générée et pour chaque case on teste si c’est :

Un couloir ;
Ne touchant aucun autre couloir ;
Ne touchant qu’une porte (en effet le cas particulier où deux portes sont reliées par une seule case est possible).

Si la case satisfait ces conditions, on la supprime mais on supprime également la porte qu’elle touche et le parcours de la map continue. Sinon, si la case est :

Un couloir ;
Touchant un unique autre couloir ;
Ne touchant pas de portes ;

Auquel cas on supprime le couloir et on recommence les tests sur le couloir adjacent. Si la case ne vérifie aucune de ces conditions on continue à parcourir la carte.

Cette procédure permet de supprimer tous les couloirs qui ne débouchent sur rien. Les couloirs qui se divisent sans être utilisés par la suite sont aussi nettoyés. Dans un premier temps une première branche est supprimée jusqu’à arriver à l’embranchement qui a 2 voisins donc ne peut pas être suprrimé. Dans un deuxième temps la seconde branche est supprimée et quand l’algorithme arrive à l’embranchement il n’a plus qu’un voisin.

Au niveau du comportement des briques il est intéressant d’ajouter un facteur aléatoire, la position de la porte sur la pièce nouvellement créée afin de rendre les niveaux plus variés. La taille des pièces peut également varier, en revanche les couloirs sont de taille fixe puisque de toute façon ils seront nettoyés par la suite.

Nous avons aussi utilisé une technique pour tracer des murs plus jolis qu’un simple caractère. Il existe des caractères Unicode (vous pouvez aussi travailler avec des symboles ASCII ou des tiles graphiques) qui représentent tous les embranchements possibles, par exemple : "┼", "─", "│", "┌", "┬", etc.

  ┌─────┐
  │     │
  │     ├──┐
  │     *  │
  └─────┤  │
        └──┘

  mur_a_droite + mur_a_gauche * 2 + mur_en_haut * 4 + mur_en_bas * 8

qui génère un entier différent pour chacune des 16 configurations (mur_foo vaut 0 ou 1). Stockez ensuite les 16 tiles correspondantes dans un tableau (certaines peuvent être identiques) et le tour est joué :-) . Pour des résultats convenables il faut tout de même associer à chaque mur un identifiant correspondant au numéro (unique) de la salle à laquelle il appartient. Un mur n’est alors adjacent à un autre que s’ils ont le même numéro. Losrqu’une salle partage un mur avec une autre celui-ci doit alors porter les deux identifiants. On peut aussi imaginer utiliser cette méthode pour dessiner des portes orientées.

Il est enfin intéressant d’apporter un soin particulier à la première salle générée. Dans notre jeu, celle-ci contient toujours un escalier, montant ou descendant. Ainsi, il ne nous reste plus qu’à placer l’autre ce que nous faisons en calculant la case la plus éloignée (:-’). Cette salle initiale peut aussi être l’antre d’un monstre particulièrement puissant qui garderait l’escalier. Si vous désirez y placer un complexe de plusieurs salles formant une suite logique il est conseillé de ne spécifier qu’une des cases comme mur. Ainsi, le jeu ne permettra pas au joueur d’accéder à une salle sans passer par la précédente. Combinée avec notre système d’effets, cette astuce permet de réaliser des niveaux où le joueur doit rejoindre la première pièce générée, tuer le boss qu’y s’y trouve et ainsi ouvrir une salle annexe contenant un escalier descendant.

L’article qui m’a inspiré : Dungeon-Building Algorithm - Mike Anderson .

Novendiales - Jours 7 et 8

2009-07-21T19:38:44Z

Théorème : "Toute fonction d'un projet ayant une deadline est isomorphe à un Goo"

Corollaire : "À tout instant, le graphe d'appel du programme est isomorphe à la tour de Goo au même instant"

Théorème : "Toute fonction d'un projet ayant une deadline est isomorphe à un Goo"

Corollaire : "À tout instant, le graphe d'appel du programme est isomorphe à la tour de Goo au même instant"

Les deux derniers jours des Novendiales sont passés à une vitesse hallucinante, quand bien même on a beaucoup plus codé durant ces deux jours. Il nous restait toute la finition en fait, qu'on a bien sûr codé à l'arrache d'où le trip au-dessus :-' .

Il faut dire qu'on avait pas mal de trucs à faire. On a d'abord eu à retoucher le système d'effets pour pouvoir faire vraiment ce qu'on voulait. Ensuite on a improvisé pas mal de sorts (et revu le fonctionnement des personnages evil au dernier moment, pas des plus productif). Après avoir testé tout ça il a fallu créer les monstres et les équilibrer avec le reste du jeu.

On avait jamais développé de RPG (pas jusqu'à ce stade du moins) et il faut bien dire une chose : équilibrer un jeu ça prend du temps, beaucoup de temps. Le jeu n'est d'ailleurs toujours pas bien fini de ce point de vue là.

Une fois la deadline passée on a commencé à s'intéresser au port Windows, on est toujours dessus (stay tuned!). Cependant, si vous êtes sous Linux (binaires dispos) ou un autre Unix-like pas trop moche vous devriez pouvoir le compiler sans trop d'efforts. Contrairement à ce que certains semblent croire, le jeu est tout à fait jouable. Il parait même que certains l'ont fini.

Pour plus d'informations, consultez la documentation d'(un)faithful .

Novendiales - Jour 6

2009-07-18T11:05:22Z

Deux jours avant l'échéance, la productivité est à son maximum.

Le moteur de jeu est quasiment terminé, il ne nous reste que quelques choses à fignoler pour avoir terminé (encore et toujours les maps). On a maintenant un donjon de dix niveaux (qui sont sauvegardés à l'arrache dans des fichiers, sinon caml est à genoux), on peut acheter des armes, des sorts, on peut choisir sa destinée (true story), et bien plus encore.

Est implémentée aussi, la gestion de l'alignement, ce qui détermine la foi obtenue en tuant des personnes ; plus elle est grande et plus vous êtes fidèles à votre Dieu qui vous récompense ; plus elle est faible et votre Dieu vous rejette (attention à ne pas trop l'énerver !).

Il nous reste principalement à faire des donjons de difficulté croissante, rajouter des objets / sorts / effets, bref du contenu, et le boss de fin aussi.

Voici un screenshot de l'interface des autels pour acheter des sorts ou des objets :

Novendiales - Jour 5

2009-07-17T10:45:17Z

Sur les huit jours que nous nous sommes accordés pour réaliser notre jeu, cinq ont déjà passés, c'est l'heure d'un petit bilan.

(un)faithful, puisque c'est désormais le nom du jeu, est encore au stade de "prototype". L'aspect roguelike est presque pleinement testable (sinon fonctionnel) et les fonctionnalités basées sur le sacrifice commencent à faire leur apparition.

Ce que nous avons fait :

Menu avec système de sauvegarde ;
Génération aléatoire d'une map et de créatures dessus ;
Affichage graphique évolué : fondus, caractères UTF-8 ;
Système de combat classique (caractéristiques, combat au tour par tour) ;
Système de sorts consommant de la foi, d'objets et d'effets à durée variable.

Ce qui nous reste à faire :

Perfectionnement du générateur de map (plus de diversité, à la fois dans les maps et dans les créatures générées, génération plus subtile des créatures) ;
Quelques bugs à corriger sur le moteur graphique ;
Items, Skills.

La dernière ligne peut sembler anecdotique. C'est loin d'être le cas. Toute l'innovation de notre jeu est dans le système qui gère à la fois les skills, les items lootés dans le donjon, l'expérience, le mana de manière à obliger le joueur à faire des choix.

Économiser du mana pour acheter des skills, détruire de puissants items qui risqueraient de corrompre votre âme de paladin ou au contraire basculer dans la nécromancie, voilà autant d'expériences qui vous attendent.

Novendiales - Jour 4

2009-07-16T09:53:55Z

And the Lord spoke saying...

« Three shall be the number, thou shalt count... »

And the Lord spoke saying...

« Three shall be the number, thou shalt count... »

Il a fallu attendre trois jours pour voir le PC d'haveo ressuciter. Mais tout est bien qui finit bien, on peut de nouveau être productifs.

Novendiales - Jour 3

2009-07-15T02:13:43Z

Ça fait deux jours que les morts se sont réveillés.

Une lueur malsaine d'intelligence semble briller dans leurs orbites vides. Dans ce dédale de couloirs, la plupart sans issue, je dois leur échapper si je veux me maintenir en vie. Je ne sais combien de temps je vais pouvoir encore survivre, les salles s'enchaînent sans que je puisse en garder une image claire. Paranoïaque, ça fait des nuits que je vis dans la peur.

Mon seul but est de m'enfoncer toujours davantage dans ce donjon pour trouver la cause de ce mal — existe-t-elle seulement ? En tout cas la sortie est maintenant hors d'atteinte et je ne saurais jamais retrouver la lumière du jour, toutes ces salles à peine éclairées sont indiscernables, les corps putréfiés en pleine chaleur me donnent la nausée.

Mon épée, ma seule amie encore fidèle, m'a sauvé des mains de ces êtres dénués de pitié. J'espère seulement que la corruption qui les anime ne m'atteindra pas et que jamais je ne les rejoindrai.

Aidez-moi.

Les types existentiels (2/2)

2009-07-14T17:15:00Z

Maintenant que l'on sait comment implémenter des types existentiels en caml, je vais vous montrer les quelques usages que l'on en fait dans le code pour notre projet pour les novendiales.

State, l'état du jeu à tout instant

Dans un jeu il y a principalement trois choses à faire :

dessiner le monde ;
réagir lors de l'appui d'une touche ;
prendre en compte l'influence du temps.

Supposons que notre type représentant l'état du monde soit 'a, cela nous donne le type suivant :

type 'a état = {
  dessiner : 'a -> dessin list; 
  temps : float -> 'a -> 'a;
  touche_appuyée : touche -> 'a -> 'a;
}

Quelques commentaires :

seul temps et touche_appuyée sont susceptibles de modifier le

monde, dessiner s'occupe juste de représenter le monde ;

dessiner retourne une liste de dessin, cela permet d'avoir tout

le code de dessin complètement pur et indépendant de la bibliothèque utilisée et une fonction dessiner_dessin : dessin -> unit qui varie selon la bibliothèque utilisée. Les avantages de cette méthode seront présentés dans un article ultérieur

il n'est pas dit qu'on ait qu'un seul type de monde tout au long de

notre programme, notamment avec les menus ce type peut varier.

Le problème de ce type c'est qu'il ne permet pas de changer d'état. Il faut donc changer le type de retour de temps et touche_appuyée. Cependant, remplacer 'a par quelque chose du genre de

Continuer of 'a | Changement_d_état of 'a état

ne résoud pas le problème — et si on veut changer de type d'état ? L'intérêt des types existentiels arrive ici, si on a un type état_quantifié on peut écrire simplement

type 'a retour = Continuer of 'a | Changement_d_état of 'a état_quantifié

type 'a état = {
  dessiner : 'a -> dessin list; 
  temps : float -> 'a -> 'a retour;
  touche_appuyée : touche -> 'a -> 'a retour;
}

Quelques exemples d'état actuellement implémenté (en plus de celui du jeu) :

un état pour les transition graphique entre deux états (l'état est un flottant compris entre 0 et 1) ;
un état pour récupérer une touche (désignant un objet) au joueur, l'état est ici le monde (mais ça n'est pas nécéssaire)
un état pour sélectionner un ennemi, l'état est ici l'index du monstre sélectionné (qui varie quand l'utilisateur change de monstre).

Des effets en pagaille !

Autre utilité des types existentiels : permettre d'avoir une grande variété d'effet.

En tant que roguelike, notre jeu est en tour par tour et ainsi un effet est grosso modo une fonction qui est appelé à chaque fin de tour pour agir sur le monde d'une façon ou d'une autre. Sauf qu'un effet peut maintenir un état — par exemple le nombre de tour avant qu'il disparaisse, ou plus élaboré si l'effet est moins conventionnel — et donc un type existentiel résoud ce problème.

Pour appliquer les effets, il suffit ensuite d'itérer sur les effets. En pratique ça pose quelques problèmes de récursivité car le monde dépend des effets et vice-versa or notre effet quantifié est construit via un module … Bref c'est pas la joie.