Portraits : Camille Chafer d'Ankama
Dossier réalisé par Francis Bourre aka petepx

<Francis> Salut Camille, Ankama c'est quoi ?

<Kam> Ankama, à la base, ce sont 3 potes qui bossaient dans le Web et qui en avaient marre de ne faire que ça.
Ils ont donc décidé de monter leur propre boîte, en ayant comme démarche : faire des sites
inter/intra/extranet pour vivre et faire des jeux/anims pour le plaisir et plus si affinités.
Pour terminer la petite histoire, les 3 potes en question sont : Anthony, aka Tot le gars qui s'occupe de tout ce qui est graphisme, Emmanuel, aka heu... emmanuel, ou Krokette pour les intimes, qui s'occupe de tout ce qui est commercial- communication et Camille (moi), pour tout ce qui est technique.

De gauche à droite :Anthony « Tot » Roux : Directeur Artistique, Emmanuel « Manu » Darras : Directeur Commercial, Camille « Kam » Chafer : Lead Programmeur.

<Francis> Bonne complémentarité dés le départ !

<Kam> Ouaip. On bossait ensemble dans la boîte précédente, on s'entendait bien, donc on s'est lancé en mai 2001 près de Lille (tout la haut, avec les pingouins).

<Francis> Aujourd'hui vous êtes combien ?

<Kam> Aujourd'hui, Ankama et Ankama-Studio font vivre 10 personnes (plus quelques stagiaires).

<Francis> Dix personnes à plein temps, ou est-ce que vous travaillez avec des freelances ?

<Kam> Non non, vraiment 10 CDI. Dans les 10, on retrouve :
- 4 graphistes
- 1 commercial
- 1 marketeur
- 2 chargés de comm (1 pour Dofus, un pour la Web Agency).

<Francis> Aujourd'hui quels sont vos revenus, de quoi vivez vous, est-ce que Ankama rapporte de l'argent et quels sont les pôles qui rapportent ?

<Kam> En fait, Ankama et Ankama-Studio sont la même société. La partie Ankama réalise des sites institutionnels ou de commerce électronique, et finance par la même occasion la partie Ankama-Studio qui développe Dofus avec à terme l'envie de rentabiliser Dofus, mais pour l'instant c'est surtout un beau pari et une grosse satisfaction :)

Donc pour répondre plus précisément a ta question, les pôles qui rapportent sont la création de sites (pour des clients tels que le conseil régional du nord pas de calais, ou la sous traitance (pour des sociétés comme EDF ou Atos Origin)

<Francis> Est-ce que l'on peut donc dire que pour l'instant Ankama-Studio est totalement financé par Ankama ?

<Kam> Ankama-Studio est financé à 90% par Ankama, le reste de la production Ankama-Studio étant des événementiels sous formes de jeux ou d'animations flash.

<Francis> Des investisseurs sinon pour l'une des deux boites ?

<Kam> Ouaip, mais si je t'en parle, ils devront te tuer, par la suite.
En fait, niveaux investisseurs, il s'agit de fonds personnels et d'investisseurs nationaux tels que Finorpa, ou d'organisations plus locales telles que LMI (Lille Métropole Initiative), qui ont pur but d'aider et de suivre les jeunes entreprises. C'est qu'il s'en passe, des choses, dans le Nord !

<Francis> Est-ce que Dofus se doit d'être rentable (investissements à amortir) à l'avenir ou est-ce une pure vitrine technologique ?

<Kam> Un peu les deux. C'est avant tout une vitrine technologique, mais il est évident qu'Ankama n'est pas une oeuvre de charité. En plus de la vitrine et de l'envie de bosser sur des jeux, c'est évident qu'à terme le but c'est de rentabiliser les investissements ou plutôt, le but premier est de ne pas perdre d'argent avec Dofus. Pour ce qui est d'en gagner, on verra après :)

<Francis> Avez-vous defini une stratégie particulière pour récupérer votre mise ?

<Kam> Ouaip. Avec business plan, prévisions et tout et tout. Comme les pros, quoi :) En gros, Dofus sera payant à terme. Par contre, on va se démarquer des MMORPG classiques style DAoC.

<Francis> Sous quelle forme si ce n'est pas indiscret ?

<Kam> Ici, le but n'est pas de faire payer 15€ par mois plus un CD-ROM à 60euros. Déjà, il n'y aura pas de CD initial à acheter, et ensuite l'abonnement sera à un prix ridicule : quelques euros par mois.

<Francis> Est-ce que le pari n'est pas trop osé, on entend souvent : "Payer pour un jeu flash ? ... pfff" :)

<Kam> "payer pour un jeu flash pfff" -> Voila quelqu'un qui n'a pas encore joué à Dofus :)) De notre côté, nous préférons ne pas trop insister sur le fait qu'il s'agisse de flash ou alors uniquement pour en montrer les bons côtés. Du bon côté des choses, Flash signifie : portabilité, facilité d'installation, légèreté. Du mauvais côté des choses, Flash signifie généralement graphismes affreux ou minimalistes et problèmes de lenteur. Avec Dofus, ce n'est pas le cas. En tout cas, pour l'instant :) Celui qui joue a Dofus doit oublier. L'idée générale que l'on se fait des jeux flash : une tapette géante et l'on doit cliquer vite sur la tête à Bilou. Ici, ce n'est pas un Hack & Slash, ou un 'petit jeu', mais un véritable jeu de rôle multijoueur en ligne. Et pour ceux qui sont sceptiques, il y aura toujours une version gratuite de Dofus pour les convaincre !

<Francis> Flash manque-t-il de crédibilité au niveau ludique ou est-ce que les choses vont en s'arrangeant ?

<Kam> Non, flash manque ENORMEMENT de crédibilité. Mais la faute ne revient pas aux internautes.
Pour l'instant, a de rares exceptions près, les seuls jeux qu'on leur a fourni sont des jeux codés en une demi journée. Donc forcément, Flash a une mauvaise image pour les jeux mais c'est aussi pour ça que Dofus est bien motivant pour nous : On essaye de montrer qu'avec une technologie réputée TRES limitée, on peut produire un véritable jeu avec un fond, une histoire, des graphs, ...

<Francis> Pourquoi Flash ? Avez vous hésité pour l'utilisation d'une autre technnologie ou le choix s'est-il imposé de lui-même ?

<Kam> Non, on a pas hésité. Il n'y a que des raisons pour Flash
1- les coûts de développement, bien plus réduits qu'avec du développement dur en C.
2- les coûts de distribution. Ici, pas besoin d'éditeur, tout se fait par le net.
3- portabilité : avec un seul développement, on touche Windows, Mac et Linux. C'est pas beau, ça !
4- On connaissait bien Flash.
Quand on met tout ça bout à bout, ça donne Dofus
En plus, pour le côté 'Vitrine Technologique', il est toujours bon de pouvoir montrer à nos (futurs) clients que l'on sait gérer du flash avec des bases de données, de la sécurité, du paiement électronique, ... Ca fait quand même une bonne pub, non ?

<Francis> Certes ! Dofus est-il l'unique projet d'Ankama-Studio à ce jour et quel sera l'après Dofus ?

<Kam> Hum... Dofus est le principal projet à ce jour. Des idées, on n'en manque pas. On pourrait citer par Exemple Moon, un jeu de plateforme sur GBA. Mais tout ceci n'est qu'à l'état de vague projet. Pour l'instant, on a assez de travail avec Dofus et nos clients. Surtout que si vous êtes suffisamment nombreux à nous suivre sur Dofus, il y aura continuellement du travail pour ajoute des cartes, des quêtes, des monstres, des concours, ...
C'est aussi ça l'avantage du jeu en ligne : pas besoin de vendre un Add-On pour rajouter des fonctionnalités. Tout est automatique !

<Francis> Donc Moon n'est qu'un vague projet, aucun éditeur en vue ?

<Kam> Non, pas d'éditeur en vue. C'est un projet qui nous tient à coeur, qui verra le jour d'une manière ou d'une autre (au pire, en flash), mais pour l'instant, on n'en est pas encore à chercher un éditeur. Pour l'instant, c'est Dofus, Dofus et Dofus.

<Francis> Pourrais-tu comptabiliser approximativement combien d'heures par mois vous travaillez sur Dofus ?

<Kam> Difficile à dire. On y travaille entre deux clients, lorsque l'on a le temps. Pour faire une approximation à la louche, je peux dire qu'on travaille dessus depuis 2 ans, à 5 en moyenne mais uniquement quand on a le temps :) Le problème des projets qui se font au coup par coup, c'est qu'on les reprend sans cesse. Depuis 2 ans, il y a eu 3 versions du serveur, et environ 2 millions de versions différentes des graphs.

<Francis> Dans ces cinq personnes, qui fait quoi ?

<Kam> Dans les 5 personnes : Tot (graphisme), Krys (animateur), Bo (dev), Fred, aka Greu (dev), Arno et Xav (graph), et moi (dev). Ca fait plus de 5, mais comme je le disais, c'est une moyenne.

<Francis> je vais m'intéresser un peu plus aux développeurs si tu n'y vois aucun inconvénient. Quels sont les cursus et compétences de chacun ?

<Kam> Diablo II, Baldur, Final Fantasy Tactics et Secret of Mana. Plus sérieusement, côté développement, on vient tous de la même école : l'ENIC. En gros, une école en télécommunications.
Rien à voir avec le développement, donc.
Côté cursus : j'étais le seul à avoir déjà travaillé dans une société (une Web Agency), sinon tous les autres sont de jeunes diplômés.

<Francis> Quelles sont les spécificités de chacun ?

<Kam> Alors on a Boris (Bo pour les intimes) qui s'occupe de toute la partie cliente en Flash.
On a Greu qui s'occupe un peu de l'interface également, du son et surtout des 3 versions de l'éditeur de cartes.
On a Benoît qui bosse sur le site (c'est à lui que vous devez le forum en Php).
Et enfin moi même qui m'occupe du serveur en Java.

<Francis> Est-ce que les rôles sont ouverts, ou chacun se cantonne vraiment à sa partie ? En résumé, êtes vous polyvalents ?

<Kam> Lol Dans une petite structure comme la notre, les rôles sont extrêmement ouverts. On a tous un peu travaillé sur l'interface, tous un peu travaillé sur l'éditeur de sort, tous un peu travaillé sur la base de données ...
Mais au bout d'un moment, on se rend compte qu'un logiciel tel que Macromedia Flash n'est vraiment pas fait pour le travail coopératif, en tout cas dans sa version 6. Donc depuis quelques temps, c'est vrai que c'est un peu "à chacun sa partie". Mais tout le monde aide tout le monde et avec un peu de boulot, chacun pourrait reprendre le code de son voisin.
Enfin en gros, pour résumer :
Oui, on est tous un peu polyvalents, mais pour se simplifier la vie, chacun bosse sur ce qu'il préfère et surtout sur ce qu'il connaît le mieux. Et comme ça, ça fonctionne plutôt bien.

<Francis> Parlons du serveur, c'est quoi ? Serveur Java xml socket j'imagine ? :)

<Kam> Perdu. C'est bien du java, ce sont bien des socket, mais ce n'est pas du XML qui passe dessus.

<Francis> Un protocole fait maison ?

<Kam> En fait, nous avons développé notre propre protocole pour dialoguer entre le serveur et le client. Bon, protocole, c'est un bien grand mot, mais en tout cas ca nous permet de gagner énormément en bande passante utilisée, comparativement à un serveur XML classique.

<Francis> Pourquoi avoir privilégié le développement d'un serveur de A à Z plutôt que l'utilisation d'un moteur déjà existant ?

<Kam> Pour plusieurs raisons. Certains d'entre eux (style celui de macromedia), étaient trop coûteux. D'autres (style Unity2, découvert récemment) étaient très puissants, mais pas adaptés.

<Francis> C'est vrai que flashcom, c'est une grosse baffe pour le porte monnaie ^^

<Kam> Dans notre cas, nous avons désormais un serveur qui est parfaitement adapté à Dofus. Nous avons pu coder par exemple des accès aux bases de données en dur, ce qui accélère énormément par rapport à un moteur existant qui utilise des tonnes de scripts interprétés.
Et enfin, la dernière raison : un peu de folie.
Quand on commence un jeu comme Dofus, on se dit : le serveur ? Facile, ce n'est qu'un serveur de Chat amélioré ! Et hop, on crée un serveur de sockets et c'est parti. Mais on déchante vite :)

<Francis> Est-ce que votre serveur est générique, ou est-il spécialisé pour dialoguer uniquement avec flash, ou carrément spécialisé pour le gameplay de Dofus ?

<Kam> Yep. A la base, une bonne partie des classes java sont prévues pour être réutilisables pour un autre jeu, mais la dessus viennent se greffer tout plein de bouts de codes propriétaires signés Dofus.

<Francis> Pas d'objectifs en vue, genre écrire une api et dealer le serveur à des boites tiers ... ?

<Kam> Le dealer, oui et non. Ou alors, faudra raquer !!! Non, plus sérieusement, il ne serait pas présentable en l'état. Il faudrait un gros travail de commentaires et réécriture pour en faire quelque chose d'exploitable facilement pour un jeu différent.

<Francis> Dans quelle proportion faites-vous du code propre et réutilisable, et dans quelle autre spécialisez-vous le code pour un gain de rapidité ou de performances ?

<Kam> Le choix n'est pas vraiment code propre / performances.
On fait du code le plus performant possible, parce qu'avec Flash on n’a pas le droit à l'erreur.
C'est le premier critère. Il nous est déjà arrivé de passer plusieurs jours à réécrire des routines de base du client, pour accélérer une petite fonction de rien du tout. Le choix est plutôt propreté du code / vitesse d'écriture du code. En ce moment, on bosse sur un nouveau patchqui doit sortir prochainement. Alors la performance n'est pas laissée de côté, par contre il faut bien avouer que les commentaires.....

Dans l'ordre d'importance, je dirais :
1/ performances - stabilité, aussi bien pour le flash que pour le serveur
2/ Propreté du code
3/ Vitesse d'écriture du code.
Avec un trois qui passe légèrement devant le 2 quand on est à la bourre :)

<Francis> Utilisez-vous des outils particuliers pour bosser en équipe ? Tests unitaires, CVS, Project ?

<Kam> Pour ce qui est des tests unitaires, non. C'est pas que c'est pas bien, mais il y a plusieurs raisons : J'ai découvert l'XP trop tard, j'ai du mal à combiner Unit Tests et classes ne fonctionnant que grâce à un protocole réseau. Ceci dit, je suis bien conscient que ce n'est pas une excuse. Pour la prochaine version du serveur, pou pour la V2 de Dofus, ça sera fait :)
Pour le CVS, ben non : avec Flash, c'était mission impossible, et avec le Java j'étais le seul à bosser dessus. Et faire du CVS avec moi même ...
Et Project : oui et non. C'est pas du MsProject, mais bien évidemment on essaye de s'organiser un peu. Le plus dur, c'est de prévoir des dates et de devoir les repousser pour travailler sur un site client. Mais bon, il faut bien manger, aussi...

<Francis> J'imagine aisément :)

<Kam> En fait, pour ce qui est des tests, on est plutôt en train de réfléchir à la possibilité de se développer un petit outil de test de protocole. Mais bon, ça aussi, ça fait partie des projets.
Va falloir choisir entre ça et une soirée avec Papa Noël... Dur... :)

<Francis> Au sujet du serveur, quelles sont ses caractéristiques (à part son protocole propriétaire) ? Sérialisation d'objets flash, prise en charge de la DB ...?

<Kam> En fait, il gère en natif tout le côté RolePlay du jeu. Par l'intermédiaire de la DB, il gère aussi bien le pathFinding que l'IA ou encore les drops aléatoires d'items.

<Francis> Tu veux dire que les clients flash ne sont que des view/controller du moteur du jeu ?

<Kam> Exactement. Le flash est un simple terminal qui ne fait que recevoir des informations de la part du serveur. La raison est assez simple : Il est extrêmement facile de décompiler un fichier Flash. Il nous était donc interdit de mettre du code 'sensible' dans le client. Par conséquent, Flash se contente à 95% de faire de l'affichage.
Les 5% restants sont des calculs lourds qui ne pourraient pas être faits sur le serveur sous peine de tout planter, mais qui sont quand même vérifiés par le serveur. Conclusion, c'est pas encore gagné pour pirater Dofus. Il y aura bien des petits malins qui y arriveront, je me fais pas d'illusions, s'ils y arrivaient sur Diablo, pourquoi pas sur Dofus ? :)) Mais ça va pas être facile, Sgniark sgniark ...

<Francis> Donc full sync garantie pour le pathfinding, collisions, combats ... ?

<Kam> Côté synchro, oui et non. La synchronisation est garantie tant qu'il y a risque de bug ou de triche. Par contre, qui dit synchro dit temps de latence un peu plus long avant l'exécutiond'une action. Dans le village, par exemple, ou les collisions ne sont pas 'très' gênantes, il est possible que quelques unes surviennent de temps en temps.

<Francis> Comment gérez-vous les déplacements des joueurs à l'intérieur du village par exemple ?

<Kam> En fait, le pathfinding est calculé au moment ou l'on clique et les vérifications de collisions se font lorsque le joueur arrive sur une case (le jeu est en 3D iso, donc basé sur un quadrillage). Il est donc possible qu'une collision survienne si deux personnes rentrent ou sortent d'une même case exactement au même moment. Ceci vient d'une limitation de Flash :
Contrairement aux autres jeux développés dans des langages de plus bas niveaux, Flash ne permet que des connections en TCP. Pour arriver à faire des tests de collisions plus fluides et plus précis dans le village, il aurait fallu avoir recours à un envoi de données en UDP ainsi qu'à des algorithmes de prédiction de mouvement. Or l'UDP est impossible, et les algorithmes auraient été trop lourds pour ce pauvre Flash :)

<Francis> Pour le pathfinding, l’algorithme est fait maison ? Et qu'avez-vous privilégié, performances ou qualité ?

<Kam> L'algorithme est à moitié fait maison. Il s'agit en fait du A*, l'un des algorithmes les plus utilisés dans les jeux basés sur des quadrillages. Je disais à moitié fait maison car on a du l'adapter un peu à notre sauce pour qu'il soit rapide sous Flash. Il a la particularité de ne pas toujours fournir le meilleur chemin, mais d'avoir un excellent rapport pertinence/temps. Au final, sur une carte qui fait plus de 500 cellules, le calcul du chemin n'est pas perceptible (à moins d'avoir une brouette comme PC).

<Francis> Est-ce que vous gérez les obstacles en cours de route ?

<Kam> Ouaip. Pas de manière optimale, mais c'est géré. En fait, lorsqu'un joueur rencontre un obstacle lors d'un déplacement, alors que le chemin aurait du être libre, il recalcule tout simplement un chemin possible depuis sa position. C'est un peu bourrin, mais ça fonctionne :)

<Francis> Comment gérez-vous la fluidité des déplacements, c'est du case à case avec le serveur ou vous faites des queues ?

<Kam> Le client envoie un ordre de déplacement au serveur, et ACKise (ça se dit, ça ?) de temps à autre sa position. A la question 'Pourquoi ne pas ACKiser chaque position ?' Parce que ça serait trop long en terme de temps de latence et parce que ça surchargerait le réseau. En gros, le client valide chaque changement de direction lors d'un déplacement. Ensuite, les déplacements des autres joueurs sont estimés en fonction de la vitesse du PC et de la position de départ et d'arrivée. Et c'est la raison pour laquelle des collisions peuvent survenir : dans un monde parfait, tous les clients auraient la même fluidité, mais dans la réalité, c’est loin d’être le cas. Il suffit qu'il prenne l'envie à ton Outlook Express d'aller lire ses mails pendant que tu joues, tu perds 1 frame/seconde sur ton application flash, et toutes les animations sont décalées.
Conclusion, beaucoup de bidouille pour synchroniser le tout, mais un résultat plutôt prometteur :)

En fait le plus dur en flash, c'est d'arriver à se dire "même si on peut faire plein de choses avec, cela reste du Flash. Comment vais-je bien pouvoir faire pour donner l'impression que ça marche nickel". Il faut donc trouver des bidouilles à gauche à droite pour donner l'impression que tout est savamment calculé, alors que derrière ce n'est pas forcément le cas.

Mais bon, au final, le joueur se moque bien de savoir que le chemin qu'il utilise lui fait perdre l'équivalent d'une demie case par rapport à un autre chemin. Notre boulot, c'est aussi ça : Choisir entre les améliorations éventuelles du code et le gain de rapidité

<Francis> Clair, d'ailleurs je suis étonné que vous vous soyez donnés autant de mal du côté du village, est-ce qu'un truc avec moins de synchro n'aurait pas été suffisant ? ^^

<Kam> Ben pour être honnête, ce n'était pas prévu, au début, puis un jour, Tot, le grand manitou, nous a dit : 'Ben alors, pourquoi on peut pas bouger à 30 en même temps, dans le village ?' Alors, forcément, il a fallu qu'on trouve un truc pour pouvoir le faire :)
Ca marche aussi un peu comme ça Dofus : Ah bon, c'est pas faisable ? Ok, on va voir ça :) Et hop, c'est parti.

<Francis> Donc pas de grand plan papier, fini, établi et scellé ? ^^

<Kam> Si si, mais on s'y tient pas. On en tout cas, pas toujours LOL. Disons que le plan papier contient ce que l'on fera au minimum.
Meilleur exemple : on devait rajouter quelques guildes et des sorts pour le 10 décembre. VU qu'on était un peu en retard (2 semaines), on a décidé d'ajouter des surprises au patch qui sortira la semaine prochaine. Autant de choses qui n'étaient pas prévues au départ. Mais bon, rien que de penser à la tête que vous ferez en les voyant, ça me fait dire qu'on a bien fait de bosser dessus :))

<Francis> Pour le moteur graphique, si j'ai bien compris, il s'agit d'un tilegame isométrique ?

<Kam> Yep, à 100%. Nos graphistes nous ont fait plusieurs centaines de tiles différentes et nous avons développé à côté un éditeur qui nous permet de créer dynamiquement des cartes en deux temps trois mouvements. Seul gros bitmap qui n'est donc pas une tile : un graph qui représente de l'herbe, de l'herbe et encore de l'herbe.

<Francis> Comment avez vous géré le problème des profondeurs en isométrie ?

<Kam> En galérant. En fait, le problème est qu'il est quasiment impossible de faire de la 3d iso et de ne pas avoir de problème de profondeur. Surtout quand un perso se déplace, puisque par moment il est au dessus des arbres, et l'instant d'après il passe en dessous. En fait, la solution nous est venue en regardant comment avaient fait d’autres studios pour des jeux références. En regardant Starcraft, par exemple, on s'est vite rendu compte qu'il était impossible de passer juste derrière un dénivelé. Et c'est là la solution pour ceux qui veulent faire un moteur 3D iso et ne pas se prendre la tête avec les profondeurs et les élévations de terrain : se débrouiller pour que chaque case sur laquelle votre personnage peut se déplacer soit entièrement visible. Une fois ça trouvé, il suffisait de jouer avec les commandes de profondeur inclues de base dans Flash et le tour était joué.
Ah si, une autre chose est primordiale : Bien éduquer ses graphistes, pour qu'ils apprennent à bien centrer leurs objets. Les tiles étant dessinées de haut en bas, il faut mettre le centre des objets tout en bas et non tout en haut....

<Francis> Peux-tu me parler de votre éditeur ? Quel type de données générez-vous, où sont-elles stockées, comment gérez- vous les actions possibles, les cases interdites ... ?

<Kam> Déjà, c'est un éditeur entièrement fait en Flash, qui génère un format propriétaire. En gros, pour chaque case il sauve une description codée au niveau du bit. Quand je dis description, ça comporte : la tile de sol, la tile de décors, la tile de décors supérieur, l'objet, les flips éventuels horizontaux ou verticaux, les rotations éventuelles, l'élévation, ... Tout ça est sauvé dans une base de données au format texte et décrit la carte de manière graphique uniquement. Pour donner une idée, une carte du jeu prend environ 4ko.
Une autre table de la base de données permet d'associer une cellule ou un objet à des actions. La liste des actions est diverse et variée et permet par exemple d'ouvrir un coffre, d'être téléporté, de changer de carte, de lancer un sort, de jouer une animation, ....

<Francis> Les actions sont-elles géographiques ou purement associées aux objets ?

<Kam> Les deux mon colonel. Par exemple, si l'on veut qu'un coffre s'ouvre quand on clique dessus, l'action sera mise sur l'objet coffre. De cette façon, il sera mis en surbrillance quand on passera la souris dessus. Par contre, si on pose un piège (par essence invisible), ça sera la cellule qui déclenchera l'action. En fait, pour chaque action on sauve l'effet à exécuter, et un id qui peut être soit une position de cellule, soit un ID d'objet.

<Francis> Si j'ai bien compris l'agencement graphique de la map est sauvé séparément dans un champ de la table au format texte et les actions dans un autre champ de la table, mais à quel format ?

<Kam> Toujours au format texte, mais encodé de manière bizarre, plus ou moins au format Base64.

<Francis> Base64 pour gagner du poids j'imagine ?

<Kam> Heu non, pas vraiment. C'est surtout parce que l'objet XMLSocket de flash ne permet pas d'envoyer tout ce que l’on veut comme caractère. A la base, il est prévu pour envoyer du texte, et non des caractères comme par exemple les codes ascii de 0 à 32. Conclusion, sur les 255 caractères que contient la table ASCII, seuls 64 sont réellement utilisables sur tous les systèmes. Il faut donc encoder toutes les valeurs sur 6 bits (2^6=64), ce qui permet effectivement de gagner un peu de place, mais beaucoup moins que si l’on mettait directement des données binaires.

<Francis> Et c'est pas trop galère de parser tout cela à Flash, vous avez optimisé l'envoi par blocs ?

<Kam> Yep. On essaie d'envoyer au maximum des informations de taille fixe et supérieure à quelques dizaines d'octets. Cela évite déjà de perdre une bande passante énorme en overhead, et surtout ça simplifie le décodage et augmente les performances côté flash.

<Francis> Comment gérez vous les éléments graphiques ?

<Kam> Nous avons utilisé 2 stratégies :) La première pour les tiles : Toutes dans un seul et unique fichier. Ensuite, grâce à une savante utilisation des allowDomain, on fait des attachMovie quand même sur la librairie chargée. En fait, le truc c'est d'appeler une méthode dans le swf chargé qui elle fait l'attachMovie. Et là, ça fonctionne.
Deuxième technique, pour les persos : Tout plein de fichiers swf chargés séparément.
Et enfin, j'avais dit 2 mais il y a trois techniques : Utilisation de swf chargés à l'exécution.
Avec tout ça, ça passe sans problème. Le truc, c'est de bien séparer Graphs et Code, et tout se passe bien :)

<Francis> Vous en êtes à combien au niveau du poids pour le client ?

<Kam> Pour le client uniquement ? 100 et quelques kilos, je pense, mais il y a des images dedans. En code pur, quelques dizaines de ko. Pour tout le jeu, avec les musiques et tous les graphs : Euh...environ 4Mo. Mais c'est vraiment du à peu près : Pour savoir, faudrait que j'enlève tous les FLA du répertoire sources :)

<Francis> Le code Flash est structuré comment ? Tout dans un fla ? En fichiers .as séparés ? Librairies de classes ? AS1 j'imagine ?

<Kam> Ben en fait, le code a été commencé il y a 2 ans. Donc en flash 5. Puis entre temps, il y a eu Flash 6... Donc prototypes et tout et tout. Et maintenant, Flash 7. Conclusion, tout est en AS1. Par contre, on a séparé le code dans plein d'.as différents, et désormais on code en Flash 7 (mais on compile en AS1).

<Francis> Ca donne quoi au résultat ? Orienté objet ? :)

<Kam> Oui oui, tout est OO. Ca fait longtemps qu'on a enlevé tout ce qui n'était pas objet. Seulement, avec Flash7, on a un peu plus de rigueur au niveau des déclarations et surtout, on a dû arrêter toutes nos bidouilles avec les prototypes. Bidouilles bien pratiques, mais bon, si on peut plus, on peut plus :)

<Francis> Est-ce que le moteur graphique de Dofus est assez bien encapsulé pour donner naissance à d'autres jeux ou est-il trop spécifique comme le serveur ?

<Kam> En théorie, il pourrait servir à un autre jeu assez facilement, MAIS....
Conclusion : le code Flash pourrait être réutilisé très facilement pour un autre jeu qui utiliserait un moteur cloné sur celui de Dofus. Mais je souhaite bien du courage à celui qui essayerait de reprendre Dofus à son compte : Y’aurait du boulot !

<Francis> Donc il ne s'agit en aucun cas d'un moteur 3d iso générique ?

<Kam> Non non. Certains objets de base pourraient être réutilisées (A-Star, Séquenceur d'actions, Object Map qui calcule les positions sur la carte en 3D iso, ...), mais dans l'ensemble, non, ce n'est pas un moteur générique.

<Francis> Sinon FlashMx2004, t'en penses quoi ?

<Kam> Ah, en fait, FlashMx2004, c'est ce que j'appelle Flash 7 et c'est plutôt bien :) C'est légèrement plus rapide (enfin, pas l'AS2, mais le plugin), c'est plus propre, ça permet d'avoir des fichiers externes, et ça, ça déchire sa mère :)

<Francis> AS2, tes premières impressions ?

<Kam> Alors le côté lèche-cul pour Macromedia : Ultime. Plus propre, plus rigoureux.
Le côté râleur : C'est quoi, ce truc ? On nous sort un nouveau langage, et au final ça change rien, derrière c'est compilé en AS1...
Il suffit d'aller voir les composants fournis par Macromedia pour voir à quel point eux même font de grosses bidouilles en utilisant de l'AS1, des prototypes alors qu'ils ce sont censés être des composants AS2.
Enfin, faut pas trop en demander non plus. Dans l'ensemble, c'est quand même plutôt bien. Ca permet de bien séparer Code et Graphs et surtout d'éviter pas mal d'erreurs bêtes grâce au typage des variables.

<Francis> Dofus porté en AS2 bientôt ?

<Kam> En fait, tous les nouveaux développements se font en AS2. Mais pour l'utilisateur, ça ne changera rien. Il ne faut pas s'attendre à des miracles grâce au passage en AS2 :)

<Francis> Sinon pour le gameplay, peux-tu me résumer vite fait ce que vous prévoyez dans l'année qui vient, un scoop ? ^^

<Kam> Héhé, moi je veux bien, mais ça ne va pas vraiment être un scoop. Il est prévu (et a été annoncé) de sortir tout ce qui est quêtes, monstres et IA en mars-avril 2004. Ensuite, tout au long de l'année, on rajoutera des actions réalisables dans le village (aller acheter sa baguette, espionner la voisine qui se lave, ....)
Et pour le scoop (parce qu'il en faut toujours un) : Si les joueurs cherchent bien et s'ils voyagent beaucoup, ils pourront trouver Moon dans Dofus...

<Francis> Pour conclure, on gagne bien sa vie en tant que développeur Flash chez Ankama (enfin si c'est pas indiscret) ?

<Kam> En tant que créateur, je pourrais gagner plus ailleurs. Alors si on compte que le côté financier, il y a mieux, mais il y a bien pire. Par contre, si on regarde le boulot que l'on a à faire, alors oui, on gagne bien sa vie (oh là putain, c'est beau ce que j'écris !!!!)

<Francis> Merci Kam, c'était vraiment super sympa :)

<Kam> Ben y a pas de quoi :)