Révélation
Attention ! je vais parler d’informatique
Ca fait un petit moment que j’étudie le langage Haskell pendant mes heures perdues. Ca fait aussi un moment que j’ai dans mes cartons le projet de programmer un générateur de personnages pour Shadowrun 4. Alors forcément, j’ai fini par faire le pont entre les deux activités.
Coder un générateur de personnages n’est pas chose facile - tout du moins en coder un qui soit complet et propre. Parce que la création de personnages, c’est des tonnes de petites règles à la con dans tous les sens, qui s’influencent les unes les autres. Et au final, c’est un enfer.
Pendant longtemps je suis resté bloqué à la phase de conception, avec quelques essais peu concluants ici et là. Mais cette semaine, les choses ont changé. D’un coup, j’ai réalisé que pendant tout ce temps, mes tentatives de conception étaient franchement influencées par mon expérience de la programmation orientée objet. Que si je voulais m’en sortir, il fallait que je vois les choses sous un jour différent.
Jusqu’alors, je voyais les choses sous cet angle :
- j’ai un énorme type de données très compliqué qui représente le personnage,
- il est accompagné d’un ensemble de fonctions permettant de le modifier,
- il y a un ensemble de règles qui testent la validité du personnage.
Là où je me prennais la tête, c’était sur l’interaction avec l’utilisateur : l’utilisateur peut décider de prendre un avantage qui va modifer le personnage, puis de retirer cet avantage. Devrait-on alors définir une fonction qui applique les modifications et une seconde qui applique les modifications inverses ?
Cette semaine, j’ai changé de point de vue. Je me suis rendu compte que c’était ma vision du processus de création d’un personnage qui était biaisée.
Au final, créer un personnage, c’est partir d’une base commune et faire une série de choix qui vont modifier cette base jusqu’à arriver au résultat final. Plutôt que de se focaliser sur le personnage en lui même, il faut se focaliser sur le processus de création, c’est à dire l’enchainement de modifications appliquées à la base.
Et là, tout devient plus simple : chaque choix de l’utilisateur doit s’exprimer sous la forme d’une fonction Personnage -> Personnage, qu’on enchainera pour obtenir le résultat final. Si l’utilisateur décide finalement de ne pas prendre tel avantage, rien de plus simple : on retire la fonction correspondante de la liste de modifications, on réapplique les modifications suivantes et on a le personnage corrigé.
11 janvier 2008 à 10:35
Je serais très intéressée de voir ce que ça donne, à la fin ^_^
11 janvier 2008 à 15:01
faudra que tu installes linux
non je déconne, ca sera peut être compilable pour windows.
Et puis on n’en est pas là. Pour l’instant j’écris le coeur du programme. Pour l’instant ca tourne dans une console et c’est très incomplet - mais la partie conceptuelle est là, et c’est le principal !
14 janvier 2008 à 11:39
C’est vrai que penser la création de perso dans ce sens là, ça change son angle d’attaque, un peu comme quand on le fait sur papier finalement, et, chaque modification devenant une fonction, il doit être plus facile de les ajouter en cas de Maj de règle que si tout est codé de manière rigide au départ.
Après vu ce que je connais en programmation
14 janvier 2008 à 12:07
Tiens azmo ! c’est pas banal, ca …
14 janvier 2008 à 12:15
Oui je passe de temps à autre lire ta prose que je trouve intéressante, change rien !!
16 janvier 2008 à 10:06
Hello Thomas,
Tout d’abord meilleur voeux pour cette année 2008 !
Et ensuite, ton approche est très intéressante car elle ressemble à un processus décisionnel de Markov (MDP). Un MDP fonctionne exactement de cette manière.
Pour un agent A , tu pars d’un état initial E1, à cette état initial tu définis un certain nombre d’actions possibles F1… FN. Ces actions te définissent le passage de ton état E1 à un ensemble d’état E2…EN.
Donc : A(E1) –> F1 –> A(E2) ou bien A(E1) –> F2 –> A(E3). Ton agent passe d’état en état en appliquant des actions.
En gros tu as juste à définir : l’ensemble de tes actions et la manières dont elles agissent sur ton état initial.
De cette manière, si tu retires une actions; il suffit de reparcourir ton MDP à partir de ton état initial.
Il existe une version intégrant des probabilités : les POMDP. C’est passionnant.
16 janvier 2008 à 12:47
Hey saminf ! bonne année !
Je connais les modèles de markov, en particulier les modèles de markov cachés pour la découverte de séquences de symboles - mais de ce que j’en sais, les transitions entre états sont probabilistiques …
Du coup, j’ai l’impression que le parallèle avec les modèles de markov vient surtout du fait que les deux se représentent facilement par des graphes.
1 mars 2008 à 1:53
Plop ^^
Alors, tu as avancé là-dessus ? Tu en es où ?
- Daegann -
1 mars 2008 à 12:42
ca avance petit à petit. mais il n’y a toujours pas d’interface graphique pour le rendre utilisable.