Interview de Kam publiée le 19/12/2003 par Francis Bourre sur Tweenpix.net
|
Salut Camille,
Ankama c'est quoi ? |
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. |
Bonne complémentarité dés le départ
! |
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). |
Aujourd'hui vous êtes
combien ? |
Aujourd'hui,
Ankama et Ankama-Studio font vivre 10 personnes (plus quelques stagiaires). |
Dix personnes à plein
temps, ou est-ce que vous travaillez avec des freelances ? |
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). |
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 ? |
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) |
Est-ce que l'on peut
donc dire que pour l'instant Ankama-Studio est totalement financé par
Ankama ? |
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. |
Des investisseurs sinon
pour l'une des deux boites ? |
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 ! |
Est-ce que Dofus se
doit d'être rentable (investissements à amortir) à l'avenir
ou est-ce une pure vitrine technologique ? |
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 :) |
Avez-vous defini une
stratégie particulière pour récupérer votre
mise ? |
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. |
Sous quelle forme si
ce n'est pas indiscret ? |
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. |
Est-ce que le pari
n'est pas trop osé, on entend souvent : "Payer pour un
jeu flash ? ... pfff" :) |
"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
! |
Flash manque-t-il de
crédibilité au niveau ludique ou est-ce que les choses
vont en s'arrangeant ? |
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, ... |
Pourquoi Flash ? Avez
vous hésité pour l'utilisation d'une autre technnologie
ou le choix s'est-il imposé de lui-même ? |
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 ? |
Certes ! Dofus est-il
l'unique projet d'Ankama-Studio à ce jour et quel sera l'après
Dofus ? |
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
! |
Donc Moon n'est qu'un
vague projet, aucun éditeur en vue ? |
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. |
Pourrais-tu comptabiliser
approximativement combien d'heures par mois vous travaillez sur Dofus
? |
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. |
Dans ces cinq personnes, qui fait quoi ? |
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. |
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 ? |
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. |
Quelles sont les spécificités
de chacun ? |
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. |
Est-ce que les rôles sont ouverts, ou chacun se cantonne
vraiment à sa partie ? En résumé, êtes vous
polyvalents ? |
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. |
Parlons du serveur, c'est quoi ? Serveur Java xml socket
j'imagine ? :) |
Perdu. C'est bien du java, ce sont bien des socket, mais
ce n'est pas du XML qui passe dessus. |
Un protocole fait maison ? |
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. |
Pourquoi avoir privilégié le développement
d'un serveur de A à Z plutôt que l'utilisation d'un moteur
déjà existant ? |
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. |
C'est vrai que flashcom, c'est une grosse baffe pour le
porte monnaie ^^ |
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 :) |
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
? |
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. |
Pas d'objectifs en vue, genre écrire une api et
dealer le serveur à des boites tiers ... ? |
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. |
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 ? |
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 :) |
Utilisez-vous des outils particuliers
pour bosser en équipe
? Tests unitaires, CVS, Project ? |
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... |
J'imagine aisément :) |
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... :) |
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 ...? |
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. |
Tu veux dire que les clients flash ne sont que des view/controller
du moteur du jeu ? |
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 ... |
Donc full sync garantie pour le pathfinding, collisions,
combats ... ? |
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. |
Comment gérez-vous les déplacements des joueurs à l'intérieur
du village par exemple ? |
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 :) |
Pour le pathfinding, l’algorithme est fait maison
? Et qu'avez-vous privilégié, performances ou qualité ? |
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). |
Est-ce que vous gérez
les obstacles en cours de route ? |
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 :) |
Comment gérez-vous la fluidité des déplacements,
c'est du case à case avec le serveur ou vous faites des queues
? |
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é |
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
? ^^ |
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. |
Donc pas de grand plan papier,
fini, établi et scellé ?
^^ |
Si si, mais on s'y tient pas. Ou 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 :)) |
Pour le moteur graphique, si
j'ai bien compris, il s'agit d'un tilegame isométrique ? |
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. |
Comment avez vous géré le problème
des profondeurs en isométrie ? |
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.... |
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
... ? |
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, .... |
Les actions sont-elles géographiques ou purement
associées aux objets ? |
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. |
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 ? |
Toujours au format texte, mais
encodé de manière
bizarre, plus ou moins au format Base64. |
Base64 pour gagner du poids j'imagine ? |
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. |
Et c'est pas trop galère de parser tout cela à Flash,
vous avez optimisé l'envoi par blocs ? |
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. |
Comment gérez vous les éléments
graphiques ? |
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 :) |
Vous en êtes à combien
au niveau du poids pour le client ? |
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 :) |
Le code Flash est structuré comment ? Tout dans
un fla ? En fichiers .as séparés ? Librairies de classes
? AS1 j'imagine ? |
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). |
Ca donne quoi au résultat ? Orienté objet
? :) |
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 :) |
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 ? |
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 ! |
Donc il ne s'agit en aucun cas
d'un moteur 3d iso générique
? |
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. |
Sinon FlashMx2004, t'en penses quoi ? |
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 :) |
AS2, tes premières impressions
? |
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. |
Dofus porté en AS2 bientôt
? |
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 :) |
Sinon pour le gameplay, peux-tu
me résumer vite
fait ce que vous prévoyez dans l'année qui vient, un scoop
? ^^ |
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... |
Pour conclure, on gagne bien
sa vie en tant que développeur
Flash chez Ankama (enfin si c'est pas indiscret) ? |
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 !!!!) |
Merci Kam, c'était vraiment
super sympa :) |
Ben y a pas de quoi :) |
Haut
de la page |