1

I) IntroductionTraditionnellement, les jeux vidéos se répartissent en trois catégories : les

jeux d’arcades, les jeux de console, et les jeux sur ordinateurs. Le stage au sein dela société Atrébates Editions m’aura permis d’officier sur un jeu sur ordinateur,Rogues Island. Cependant, du point de vue de la programmation il est très facile deconstater que les méthodologies et les structures découvertes pendant le stage etemployées dans la création d’un jeu sur ordinateur sont fondamentalement lesmêmes que lors de la création d’un jeu de console ou d’arcade. Seuls vont parfoischanger les langages de programmations (C++, Java…) ou les outils employés(DirectX, OpenGl…). C’est pourquoi je ferai toujours référence, dans ce rapport, à laprogrammation d’un jeu au sens large.

1.1) Le jeu vidéo

Avec un chiffre d’affaire ayant dépassé celui du cinéma en20041, le jeu vidéo actuel porte sans complexe le nom d’industrie,comprenant donc les notions et les méthodes généralementrattachées à ce terme. Les processus utilisés dans ledéveloppement des jeux vidéos sont désormais à peu de chosesprès les mêmes que ceux employés dans l’industriecinématographique. Ces processus étant à regrouper en troisgrands aspects : le commercial, l’artistique et le technique.

L’aspect commercial est aussi trivial que celui du cinéma : un bonprogrammeur est un programmeur vivant, et ses productions doivent donc luiapporter finances. A un autre niveau, il en est de même d’une entreprise. Or celle-civa essayer d’imposer des critères qualitatifs ainsi qu’une recherche d’originalité à saproduction pour survivre dans un marché économiquement énorme mais où lesplaces sont peu nombreuses.

Derrière cet impératif commercial à lieu une volonté artistique : le jeu estsoumis aux lois des ‘produits’ audiovisuels de divertissement, tout comme le cinémaauquel il emprunte très régulièrement les codes, avec une culture de l’interactionomniprésente.

Mais sous cette volonté artistique se cache une capacité et un savoir fairetechnique. Ce savoir faire est d’autant plus mis à rude épreuve que le commercialcomme l’artistique semontrent exigeants ouambitieux. Ainsi, vouloircréer un jeu avec ununivers très vaste, detrès nombreux lieux etpersonnages auxmultiples possibilités,une très grande

1 Source : site internet de l‘Agence Française pour le Jeu Vidéo

« On appelle jeu vidéoun médium électronique

interactif dedivertissement qui

utilise un écran vidéocomme affichage

principal.»Michael Morrison,

Programmation des jeux,Campus Press (2004)

La programmationd’un jeu vidéo doit

essayer de concilierles exigencesartistiques et

commerciales avecles contraintes

techniques

2

résolution de textures, et le tout en réseau avec une rapidité en temps réel peuventêtre une volonté commerciale et artistique forte, mais qui entraînera une demandede puissance matérielle élevée ou des exigences et des méthodes deprogrammation spécifiques.

1.2) Modalités du stage

Le stage s’est effectué à Lille pendant quatre mois, du 01/04/05 au31/07/2005, dans les locaux de la société Atrébates Editions (au 72 rue Gutenbergà Lille). Pendant ces 4 mois, j’ai été en compagnie de deux autres stagiaires : l’unpendant les trois premiers mois du stage, puis le second prit sa place le quatrièmemois. Comme prévu dès un entretien passé fin Mars 2005, les horaires étaientdéfinis selon le régime des 35 heures par semaine, sans rémunération.

II) La société

2.1) Présentation1

La société Atrébates Editions est une société2 decréation, de développement, d’édition et d’exploitation dejeux vidéos en ligne. Elle développe actuellement le jeu« Rogues Island ».

Ses activités s’étendent également aux services informatiques, aux conseilsd’achats de matériel informatique pour PME, ainsi qu’à la réalisation de sites web.

Son siège Social est à Lille. Le stage s’y est entièrement déroulé.

2.1.1) Quelques dates

- 23 Mai 2003 : Création de la société.- 26 Mai 2003 : Lancement de son activité.- Août 2003 : Démarrage du développement de Rogues Island.- Début 2004 : Ouverture du beta-test.- 8 Avril 2003 : Première version du site en ligne.La sortie de ‘Rogues Island’ est prévue pour Noël 2005.

2.1.2) Dirigeants

La société est dirigée par deux co-gérants :- Monsieur Ingel David, directeur technique responsable du développement

des jeux vidéos.

1 Les informations concernant l’entreprise sont issues du site de la société à www.atrebates-edition.com2 SARL au capital de 8500€, RCS Lille B 448 676 080, APE-NAF 722A, SIRET 448 676 080 000 14

3

- Monsieur Ingels Laurent, directeur commercial responsable dudéveloppement des sites internets.

Ils ont été, tous deux, mes directeurs de stage.

2.2) Vie en entreprise

2.2.1) Une PME, avec ses avantages et ses inconvénients

Rogues Island est le premier jeu que développe AtrébatesEditions. Il a pour objectif de poser les bases de la société.

- Les bases techniques et artistiques : Jeu temps réelmassivement multi-joueur, Rogues Island affichera les capacitéstechniques de la société, tout en montrant un attrait pour le réalisme(absence de magie, armes et armures ayant réellement existé…)

- Les bases financières : les entrées financières de ce jeu permettront à lasociété d’entrer dans une phase d’embauche, afin de pouvoir alors se constituer uneéquipe fixe de programmeurs plus importante. De plus, les abonnements liés au jeupermettront de garantir une stabilité de ces entrées de fonds.

Pendant que la société développe le jeu, elle fonctionne sur un apport limitéd’argent provenant des activités annexes de la société (création de sites Internet,services informatiques…). Mais la priorité est mise sur le développement du jeu, cequi limite ces activités et, donc, l’entrée de fonds.

Actuellement, la société est une PME, à l’image des ‘Start-Up’ si fréquentes eninformatique, avec seulement deux employés à temps complet. Deux stagiairesviennent régulièrement participer au développement du jeu, de formationsdifférentes selon les besoins du moment. Le bureau consiste en une salle dequelques mètres carrés, dans laquelle tous les employés travaillent.

Cette exiguïté n’est pas si handicapante que cela lorsqu’on travaille derrièreun ordinateur (et pour cela nous avions tous bien assez de place) et finit par avoirbeaucoup plus d’avantages que d’inconvénients.

La proximité immédiate des formateurs permet de se débloquer trèsrapidement. Par exemple pour une question que l’on aurait pas posée s’il avait falluarrêter de travailler et changer de bureau. Or, ce genre de questions arrivent trèssouvent quand on entre dans plusieurs milliers de lignes de codes et que l’oncherche la position du fichier de telle ou telle classe. Ensuite, au niveau du travaild’équipe, des fichiers sont utilisés par certains développeurs et se retrouvent enaccès bloqué pour les autres. La perte de temps cumulée à chercher desinformations peut vite être importante. De travailler tous côte à côte renforce nonseulement le sentiment d’appartenance à une équipe, mais permet aussi un gain detemps d’information non négligeable. De plus, les formateurs peuvent ainsi nousencadrer et surveiller que nous ne faisions pas n’importe quoi dans les premièresmodifications du programme du jeu. Ils peuvent également intervenir si, parmanque de connaissances, nous sommes bloqués trop longtemps sur un bug.

De plus, cette proximité permet aux stagiaires d’être en permanence acteuret/ou spectateur des discussions.

Originaires de larégion du Nord, les

fondateurs de lasociété ont adopté le

nom d’une tribugauloise dont la

capitale était Arras.

4

2.2.2) Participation collective

Une participation collective dans la plupart des domaines est recherchée etencouragée par la société. Elle est particulièrement motivante et valorisante pour lestagiaire tout en renforçant l’ambiance de travail.

Quelques réunions ont eu lieu pendant le stage. Tout le monde pouvait yapporter ses idées, jusqu’à des décisions importantes pouvant réellement infléchir legameplay1 du jeu. Le sentiment d’écoute de la part des stagiaires était fort etchacun pouvait apporter sa propre vision du jeu. Personnellement, le côté politiquedu jeu m’avait séduit et me semblait très intéressant à exploiter. Aussi, j’essayais leplus souvent possible de présenter des idées essayant de le renforcer. J’imagine quechaque stagiaire doit apporter à chaque fois un regard nouveau, un autre regard dejoueur, qui doit au fur et à mesure permettre de se faire une idée sur les‘demandes’ des joueurs actuels.

De simples discussions entre un formateur et un stagiaire ou les problèmesque ce dernier expose à un formateur, peuvent également se transformer enréunion improvisée au vu de l’importance du sujet débattu. De même, chaquestagiaire peut intervenir et donner son avis (éclairé) dans toute discussion.

Je pense que cette écoute accordée au stagiaire participe à l’instaurationd’une excellente ambiance de travail, constamment et régulièrement renforcée pardes activités de groupes annexes au travail2 (jeu en réseau pendant les pauses…).

Lors de plusieurs rencontres avec des clients ou des éditeurs de jeu vidéos,j’ai également eu la possibilité d’assister à l’aspect commercial du développementd’un jeu vidéo. Loin de la simple programmation, cela peut néanmoins donner deséléments pour comprendre certains aspects du travail à fournir. Par exemple, lorsde mon stage, la société à pris la décision de créer son propre format d’image : AEIpour ‘Atrébates Editions Image’. Si cela peut passer juste pour un travailsupplémentaire dans un premier temps (les formats existants pourraient êtresuffisants), la notion d’image commerciale de la société lui donne une vraieimportance marketing. Par la suite, ce nouveau format trouvera également uneraison technique en permettant de réduire la taille des fichiers des images.

III) Le jeu ‘Rogues Island’‘Rogues Island’ a pour ambition d’être le

premier MMORTS (Massive Multiplayer Online RealTime Strategy), c’est à dire un jeu stratégique entemps réel massivement multi-joueurs en ligne.

1 Interaction entre le joueur et le jeu. Ce terme contient plusieurs notions à la fois comme la jouabilité ou le plaisirde jeu. Un bon gameplay correspond à une bonne alchimie entre toutes ces notions.2 Ainsi, la notion de ‘veille technologique’ est la première que -curieusement- chaque stagiaire comprend et intègreparfaitement et très vite. En effet, il s’agit de tester ce que fait la concurrence et pour cela de… jouer.

5

3.1) MMORTS

Un jeu MMORTS appartient de fait à deux ‘familles’ de jeu : les MMO et lesRTS.

3.1.1) Les MMO (Massive Multiplayer Online)

Un jeu vidéo MMO permet à un très grand nombre de joueurs de se retrouverdans un univers de jeu où chacun peut interagir simultanément avec les autres.Cette ‘rencontre’ à lieu à travers un réseau, qui est généralement Internet.

Il y a plusieurs type de jeux appartenant aux MMO,dont les plus connus sont :

-Les MMORPG (Massive Multiplayer Online RolePlayerGame), c’est à dire : jeux de rôle massivement multi-joueursen ligne, sont les plus courants. On y joue un seulpersonnage qui évolue au cours du temps en fonction de l’expérienceaccumulée de divers manières (en général par équipe, dans desscénarios faisant intervenir des personnages dirigés par ordinateur).Exemple : NeverWinter Nights1 (images à droite).

-Les MMOFPS (Massive Multiplayer Online First-PersonShooter), c’est à dire : jeux de tir en vue subjective massivementmulti-joueurs en ligne. Un nombre plus ou moins important dejoueurs s’affrontent sur le principe du jeu de tir à la premièrepersonne, par équipe ou chacun pour soi. Chaque joueur nedirigeant qu’un seul personnage. Exemple : Battlefield 22, présentécomme un MMOFPS bien qu’il n’autorise qu’au maximum 64joueurs (image à droite : Jedi Knight3 (32 joueurs maximum)).

En règle générale, chaque jeu MMO ne permet au joueur de ne contrôlerqu’une seule unité ou qu’un seul personnage (ou un nombre très restreint).

3.1.2) Les RTS (Real Time Strategy)

Les jeux vidéos RTS sont des jeux de stratégie où lejoueur dirige des troupes ou autres unités, et doit le plussouvent construire les bâtiments permettant de les créer.Ils divergent des jeux de simulation économique parl’utilisation d’un terrain de bataille où les troupes desjoueurs s’affrontent. Ces jeux ont lieu en temps réel, cequi signifie que les ordres des joueurs à leurs unités sontimmédiatement pris en compte, sans possibilité ‘d’arrêterle temps du jeu’. Exemple : Warcraft III4 (image à droite).

1 Edité par Atari2 Edité par Electronic Arts3 Edité par Lucas Arts4 Edité par Blizzard Entertainment

6

3.1.3) Difficultés d’un jeu MMORTS

Tout joueur de RTS se lasse assez vite des réactionsrépétitives et prévisibles d’un joueur géré par une intelligenceartificielle. Il a été très rapidement essayé de faire jouer plusieursjoueurs humains en même temps. Parallèlement, la technologieaidant et l’accès à Internet se multipliant, les MMO deviennent deplus en plus populaires. Le marché actuel des jeux vidéos estinondé de MMORPG, particulièrement à la mode en ce moment. Ilest en fait la seule réponse à l’engouement des MMO, ettechniquement facile à mettre en place. Les jeux MMO à la mode et les RTS ayantun grand succès auprès du public, une technologie pour MMORTS a toujours étérecherchée.

La réponse actuelle à la ‘demande’ du public passe aujourd’hui par desMORTS (Multiplayer Online Real Time Strategy) : des jeux de stratégie multi-joueurs en temps réel en ligne. Le pas vers les MMORTS n’est pas encore franchi. Eneffet, quand les joueurs peuvent diriger une multitude d’unités, la possibilité n’estdonnée de ne pouvoir jouer, en général, qu’à 8 joueurs maximum.

Le pas vers un MMO n’est pas si trivial. Par exemple, il est rare de trouver desMMOFPS. Le plus populaire des FPS multi-joueurs, Counter Strike1, n’est ‘que’ unMOFPS (des équipes de 8 joueurs maximum, ce qui est loin d’être massif). Or lesFPS, dont une partie du jeu repose sur les réflexes des joueurs, partagent avec lesRTS la nécessité de réponse rapide entre les joueurs. En règle générale, les jeux enréseau posent le problème d’une réactualisation des informations puis d’un affichagepour chaque joueur qui puissent être en temps réel. Autrement dit, chaque joueurdoit recevoir sur sa machine les informations provenant de chaque machine desautres joueurs, puis réactualiser son affichage en fonction, sans qu’il n’y ait deflottement de l’affichage (notamment le problème de ‘gel’ de l’image). Si le tempsréel est utilisé pour rendre les FPS ‘nerveux’, il est problématique dans les RTS dufait du contrôle de multitudes d’unités, et donc du traitement de ce lot énormed’informations. D’autant plus si le RTS est en réseau : chaque joueur ayant àtransmettre et à traiter son lot d’informations et celui de tous les autres joueurs.

Et le problème des MMORTS est encore plus flagrant que le nombre dejoueurs devient lui aussi immense.

Dans Rogues Island (image à droite)le joueur contrôlera 100 unités mobiles, et lenombre de joueurs autorisés se comptera encentaines (1000 joueurs par réseau au lieudes 8 dans la plupart des jeux actuels). Or latâche est plus qu’ardue : non seulement lejeu doit répercuter les informations dechacune des unités et des bâtimentsnouvellement construits de chaque joueur àtous les autres, mais il doit également

1 Edité par Sierra Entertainment

« Force me fut de constater quedoter un adversaire virtuel

d’intelligence n’avait rien d’un jeud’enfant… J’essayai alors une

autre approche. Plutôtqu’implémenter un seul adversaire

virtuel intelligent, j’optais pourune armée d’adversaire virtuels

stupides. »Michael Morrison, Programmation

des jeux, Campus Press, 2004.

7

répercuter les informations de toutes les conséquences qu’entraînent ces bâtimentset unités. Ainsi, par exemple, l’impossibilité de construire à une certaine distanced’un bâtiment ennemi ou la gestion de projectiles. On imagine la quantité colossaled’information à transmettre et à traiter lorsque l’on a, par exemple, une centaine dejoueurs sur un même champ de bataille ayant chacun plusieurs dizaines d’unitéstirant chacune un projectile. D’autant plus que les flèches ont une vitesse dedéplacement particulièrement rapide !

3.2) Le jeu

L’univers du jeu, situé en1200 après JC, est d’inspirationmédiévale. L’objectif est d’être leplus réaliste possible. Cette volontétransparaît notamment dans lesarmes et les unités rencontrées ouproduites, dans la volontéd’absence de magie comme dansl’obligation de certainescontingences.

Abandonnés sur une île (deplus de 10 Km de côté, soit près de23000 personnages mis côte àcôte), les joueurs devront interagirentre eux avec pour objectif dedevenir roi de cette île. Intimidation militaire, alliance ou politique, tous les outils del’époque (armes, bâtiments, système social et lois de l’époque) seront à leurdisposition pour arriver à cette fin, tout en devant lutter contre les contraintes degestion de ressources ou de ravitaillement.

IV) Le stage

4.1) Formation (10 premiers jours)…

Tout au long du stage, la programmation s’est effectuée en langage objetC++. Avant de pouvoir toucher le code du jeu, nous1 avons dû faire quelques petitsexercices : conversions décimal – binaire – hexadécimal, connaissance par cœur des20 premières puissances de 2 ou autres calculs de ‘et logiques’ et de ‘ou logiques’.

Ensuite, quelques exercices de programmation avaient pour objectif de nousplonger dans le langage objet - et précisément le C++ -, de nous faire comprendrepar la pratique l’architecture d’un jeu vidéo, ainsi que nous familiariser avec lesnormes de programmation propres à l’entreprise.

1 Nous étions deux stagiaires, arrivés à la même date dans l’entreprise.

8

Il m’est évidemment impossible de révéler la structure du programme du jeuet c’est pourquoi je me baserai sur l’exercice du Tennis dans la suite pour lesexemples concernant la structure.

4.1.1) …à la méthodologie du langage objet

Dans un premier temps, il s’agissait de comprendre la pertinence du langageobjet. Suite à des rappels sur les notions de pointeurs et de langage objet, il nous afallu programmer quelques classes en C++. Nous avons donc pu aborder lesspécificités du langage objet (héritage, encapsulation, etc). Ainsi, nous noussommes chacun vus confier la création d’une liste chaînée en C++, avec classes1 etméthodes adéquates (ajout d’un maillon, retirer un maillon) permettant de traitern’importe quel type d’objet.

Dans un deuxième temps, nous sommes passés à la prise en main d’OpenGl(toujours en C++) avec quelques objectifs simples : ouvrir une fenêtre, y afficherun triangle coloré, puis un nombre n de ce type de triangles. Ces exercices devantêtre effectués avec des contraintes différentes : l’obligation de n’utiliser dans lesclasses que des membres privés avec une seule variable globale, l’utilisationd’OpenGl dans une classe dédiée, chaque ‘callback’2 défini par une méthode declasse… Nous mettions ainsi au point une amorce de moteur graphique.

On appelle ‘moteur’ une partie de code qui permet de traiter entièrement (etindépendamment du reste du code) une partie de programme. Ainsi, un moteurgraphique s’occupera de toute la partie graphique du jeu.

1 Structure informatique de base de la programmation orientée objet contenant des sous forme devariables ou de fonctions (appelés )2 Fonction rappelée à chaque ‘MainLoop’ (boucle sans fin continuellement relancée qui traite les événements enappelant la bonne Callback, selon le fonctionnement d’OpenGl)

9

Enfin, dans un troisième temps,nous devions mettre au point un jeu deping pong, du type ‘Shufflepuck Café’, quenous avons appelé Tennis.

Tout d’abord, nousavons dû mettre au pointun organigramme de typeMerise (ci-contre) afin demettre en place la structuredu jeu. Une fois la structurebien définie, nous noussommes partagés lesclasses à programmer. Ilnous était imposé de créerdeux fichiers par classe,avec l’un des deux réservépour le header1 de la classeconcernée. Très vite,quelques réflexes ontcommencé à apparaître afinde simplifier laprogrammation par deuxpersonnes en parallèle et enéquipe : mettre au point lesheaders en premier puis lesmettre en commun afin deplacer, si nécessaire, lesaccesseurs2 dont chacunavait besoin.

Chaque classe était traitée par étapes3. Dans le développement du Tennis,ces étapes étaient regroupées en ‘paquets’. Ainsi, une fois chaque paquet terminénous passions à une phase de test afin de valider le bon fonctionnement de lestructure mise en place. Ainsi, le premier paquet contenait le Main, la classeOpenGL et la classe Jeu. Nous sommes ensuite passés dans un deuxième paquet,constitué de 4 nouvelles classes et ainsi de suite.

L’objectif était d’appliquer les exercices précédents dans un travail en équipe.En effet, nous réutilisions la structure de la liste chaînée que nous avions mise enplace (après avoir choisi l’une des deux que nous avions construit indépendammentl’un de l’autre) : le décor du Tennis devait utiliser uniquement des listes chaînées de

1 Fichier avec l’extension .h contenant toutes les déclarations de la classe correspondante.2 Méthode d’une classe permettant d’accéder à l’un de ses membres. Cela permet de déclarer un membre privé touten pouvant, par exemple, le lire de l'extérieur de la classe.3 Les 4 étapes de construction du Tennis sont montrées dans l’Annexe n°1.

10

triangles, et nous préparait à un affichage par primitives. L’aspect du décor avaitété défini à l’avance (un terrain rectangulaire, un ‘filet’ symbolique au milieu duterrain et deux raquettes rectangulaires s’envoyant une balle carrée), des angles decaméra (deux) nous étaient imposés, ainsi que le fait qu’ils soient alternablespendant la partie par des touches dédiées. De plus, nous devions pouvoir y jouer àdeux mais aussi à un joueur contre l’ordinateur, même s’il ne nous était pasdemandé une forte intelligence de la machine. Enfin, le déplacement d’une raquettedevait s’effectuer avec des touches dédiées ou la souris dans son propre camp, savitesse devant être ajoutée à celle de la balle lors de la collision entre raquette etballe.

4.1.2) …à la méthodologie de la conception d’un jeu vidéo

Nous avions, au terme de cet exercice, pris connaissance et assimilé laprogrammation objet, les normes d’écriture et de programmation propres àl’entreprise, tout en découvrant la structure d’un jeu vidéo.

En effet, le schéma précédent (organigramme des classes) permet de voir lesmoteurs du jeu ainsi créés : en vert le moteur graphique, en jaune le moteurd’intelligence artificielle, en rouge l’interface, et en bleu et blanc ce que j’appelleraile ‘moteur de jeu’.

L’idéal étantd’arriver à un schémadu type :

Tous les exercices de formation, et en particulier le Tennis, m’ont permis decomprendre les raisons de cette structure d’un jeu avec plusieurs moteurs. Cettefaçon de penser un programme provient de la programmation orienté objet (POO)et m’a permis de prendre réellement conscience de la puissance de ce type deprogrammation. Mais j’ai également pu prendre conscience de ses faiblesse, dumoins dans le cadre de la programmation des jeux vidéos.

L’utilisation du langage objet paraît indispensable dans sonaspect ‘simplificateur’ du code. En effet, il est plus intuitif dedemander au programme de déplacer une voiture ou un personnage,soit un élément du jeu, plutôt que de devoir écrire une multitude delignes de codes absconses. Mais au travers de cet exercice, quelques‘trucs’ se sont imposés, permettant de mettre en garde sur la -parfois- trop grande confiance envers la POO. Par exemple, lesdifférentes initialisations d’une classe doivent être fragmentées. Eneffet, le constructeur1, l’initialisation des membres, l’allocationmémoire de membres, et la mise à 0 de membres doivent être

1 Méthode (fonction) obligatoire appartenant à une classe et qui est lancée automatiquement lors de la déclarationd’un objet (par instanciation d’une classe).

« L’élégance de l’approcheProgrammation OrientéObjet dans le contextedu développement d’unjeu réside dans le faitque le jeu en arrive à

fonctionner plus ou moinsde lui-même une fois

toutes les classes et tousles objets en place. »

Michael Morrison,Programmation des jeux,

Campus Press (2004)

11

séparés là où la POO sous-entend de les réunir dans le constructeur d’une classe. Etsi on ne le fait pas dès le début, la programmation va très probablement nousobliger, à un moment ou un autre, de le faire.

Ainsi, la programmation objet semble inséparable du développement d’un jeuvidéo, tout comme elle est parfaitement adaptée à leur structuration en moteurs dejeu.

Cette structuration en moteurs permetun meilleur développement des jeux vidéos.En effet, ces parties étant indépendantes lesunes des autres, on peut alors utiliser unmême moteur pour plusieurs jeux. Parexemple, le jeu Counter Strike1 (image degauche) a été créé à partir du moteur 3D d’un autre jeu : Half Life2 (image dedroite). Ainsi, chaque jeu ne nécessitera pas de recréer un code complet et unique.Chaque moteur étant alors la base du prochain jeu développé par l’entreprise etpouvant même être amélioré au fur et à mesure, sans pour autant que cetteamélioration soit liée au développement d’un jeu.

Par exemple : lors de laprogrammation de la gestion desrebonds de la balle dans le Tennis, j’aiutilisé le produit vectoriel afin dedétecter les collisions. Il m’a étédemandé de programmer cetteméthode dans une classe à part (d’oùl’apparition de la Classe Segmentdans l’organigramme des classes duTennis) au cas où elle se révéleraitplus intéressante que la méthodeemployée alors dans le moteurgraphique de l’entreprise.

Chaque moteur, comme chaque classe qui y est incluse, représente le savoir-faire d’une entreprise de conception de jeu vidéo. Ces moteurs vont évoluer ets’améliorer tout au long de la vie de cette entreprise.

Enfin, cet exercice nous permettra également par la suite, lorsque nousserons dans le code du jeu Rogues Island, de nous situer dans le jeu et de biencomprendre la portée de chacune de nos actions.

4.1.3) …à la méthodologie de l'entreprise

A travers la programmation du Tennis, j’ai pu observer l’inconvénient d’unemauvaise mise en place des choses à faire. Sans rail sur lequel nous lancer,certaines classes n’étaient pas ou mal définies dans le plan de départ. Des bonnes

1 Edité par Sierra Entertainment2 Edité par Sierra Entertainment

12

idées sur le papier se révèlent souvent moins efficaces que prévu ; et si un‘bricolage’1 fonctionne un moment, il ne fera qu’empirer les choses à la moindremodification ultérieure du code. De plus, cela m’a permis de beaucoup plus prendreconscience de l’écoute de mes impressions : à la moindre alerte d’un « j’ai déjà vuça » ou à l’apparition d’une verrue, je sais désormais qu’il s’agit forcément d’unemauvaise structuration du code. Il faut alors ne pas hésiter à revoir les structuresimmédiatement, quitte à tout reprendre du début, avant qu’il ne soit trop tard.

Jusqu’ici je n’avais jamais participé à un programme de si grande taille. Lorsde ces dix premiers jours de formation, mes directeurs de stage ont appuyé sur lefait que le programme de jeu ne peut être connu dans l’ensemble par chacun desdéveloppeurs2. Il faut donc que chacun des programmeurs aient une base communede réflexion solide. Nous avions déjà été confronté à ce problème lors des projets deces trois dernières années (licence, maîtrise, DESS), mais les schémas étaientbeaucoup plus simples et les programmes étant peu repris par la suite, certains deces programmes en sortaient vérolés afin de ne pas perdre trop de temps àrefondre la structure du programme. Cette expérience, à travers le Tennis comme àtravers mes actions suivantes sur le code du jeu tout au long du stage, m’incitedésormais à tenir compte du fait que la refonte d’une structure qui se révéleraitbancale fait partie intégrante du processus de développement d’un programme. Car,pendant ces 4 mois de stage, la programmation de l’intervention dans le code dujeu a été, pour moi, autant voire plus importante, que le résultat lui-même ; alorsque jusqu’à aujourd’hui je n’avais toujours programmé que dans le but d’obtenir unrésultat pour un moment donné et non pas pour laisser la place à un autre afin qu’ilprenne la suite (ce qui entraîne des réflexes de programmation spécifiques).

Un organigramme de type Merise représentant les classes à créer s’est doncrévélé indispensable et même obligatoire par mes directeurs de stage. L’accent àégalement été mis sur le fait d’utiliser le plus possible de schémas afin de mieuxpouvoir se représenter les problèmes, et de trouver ainsi plus rapidement lessolutions adaptées ou d’en discuter avec d’autres développeurs.

Au niveau de la programmation, une norme d’écriture est mise en place dansl’entreprise. Inspiré de la notation hongroise, il permet de tout connaître sur lavariable sans avoir à aller chercher la moindre information ailleurs. Non seulementle temps de débugage s’en retrouve particulièrement restreint, mais cette notationpermet du même coup d’éviter de faire des erreurs de programmation (enmanipulant les pointeurs par exemple). Si l’utilité d’une telle notation m’était déjàapparu pendant les divers projets informatiques auxquels j’ai participé, l’efficacitéde celle-ci en démontre son caractère indispensable.

Chaque classe du programme devait être définie par un seul fichier plus unsecond pour le header de la classe. A nouveau, la recherche d’une information s’enretrouve bien améliorée.

Ces deux aspects permettent à eux seuls une efficacité accrue de laprogrammation, ainsi qu’un contrôle plus aisé de la part des directeurs de stage.Ainsi, nous étions plus libres dans la programmation. Dans les méthodes derésolution des problèmes ou de mise en place de structures, nous devions dans un

1 Nommé ‘verrue’ dans l’entreprise, et qui témoigne d’une aberration dans le code.2 Sans en connaître le nombre exact, je peux affirmer qu’il possède au minimum plusieurs milliers de lignes decodes.

13

premier temps leur expliquer notre façon de procéder (schéma à l’appui). Maisassez vite ce contrôle s’est restreint, de sorte que nous pouvions programmer sansaucune autre contrainte que de faire de notre mieux.

Il est probable que de toute façon le code d’un aussi gros programme, et à ladurée de développement si longue1, évolue sans cesse et que notre apport soit, àl’avenir, modifié ou remplacé par un autre code. Conscient de cette possibilité, monobjectif était alors de produire du code qui puisse tenir le plus longtemps possible,voire jusqu’au bout si possible. Pour cela, je me suis donc efforcé d’écrire un code leplus robuste et le plus souple possible2. Mais cette liberté n’était possible qu’à partirdu moment où les contraintes méthodologiques de l’entreprise étaient, selon moi,d’une efficacité redoutable.

4.2) Programmation et structure d’un jeu vidéo

Pendant les premiers jours de formation du stage, j’aipu voir l’élaboration de la structure d’un jeu vidéo. Laplanification des classes, leurs liens éventuels entre ellesgrâce à un organigramme, et leur regroupement parmoteurs de jeu ont été évoqués dans la partie 4.1.

Cette structuration est mise en place grâce à uneprogression ‘en spirale’ qui consiste à avancer pas à pasdans l’élaboration du programme. On créé la premièreclasse, on la teste, puis on l’insère dans le programme, quel’on teste pour voir si les relations entre la nouvelle classe etles anciennes fonctionne bien. Chaque classe suivantesubira à son tour ce processus.

Pour le projet du Tennis, l’entreprise nous a d’abord poussé à définir puisconstruire les liaisons de classe, et ensuite mettre en place l’ordre de création desclasses établies. En fait, cette démarche peut même s’inscrire dans une premièreétape de conception des header des fichiers contenant les classes. Ainsi laprogrammation qui suivra sera particulièrement aisée, mais si apparaît le moindresentiment de trop forte complexité, il faut alors réfléchir à nouveau sur la bonneconception des classes et leurs liaisons respectives car quelque chose clocheforcément.

Dans le schéma ci-dessus représentant le cycle d’évolution d’un programmepar ajout de classes, chacune des trois parties ont la même taille pour sous-entendre que leurs importances sont équivalentes. Chaque classe ainsi créée étantle support sur lequel on construira la suivante, la moindre faiblesse que l’onlaisserait passer peut faire s’écrouler tout ce qui a été construit ‘par dessus’.Généralement la partie de programmation ne pose que des problèmes ‘immédiats’,par opposition à un bug caché qui peut traîner et ne se révéler que bien plus tard ou

1 Le jeu Rogues Island est en développement depuis plus de deux ans.2 Par exemple, l’arbre hiérarchique des vassalités que j’ai créé a ensuite servi à tester d’autres codes. Il devait doncêtre capable de tenir malgré des données différentes à celles prévues. De plus, pour aider à débuger une autrepartie il devait afficher de nouvelles informations non prévues lors de sa programmation. Or, le simple ajout d’uneméthode pouvant ensuite être retirée a fonctionné sans avoir besoin de retoucher au reste du code.

14

une mauvaise conception de la classe qui entraîne en plus la reprogrammation et laphase de tests.

4.3) Entrée dans le programme du jeu

4.3.1) Empreinte dans le programme = empreinte dans le jeu

La partie 2.2 montre que la structure de l’entreprise permet au stagiaire deproposer son point de vue dans plusieurs situations. Ainsi il lui est possible de lancerdes idées qui peuvent modifier le gameplay, et même atteindre la partie artistique,voire commerciale, du jeu. Mais cette influence sur le gameplay peut aussi ressortird’une programmation.

Apporter une solution ne fait pas que résoudre un problème. Cela peutégalement bloquer une voie qui aurait pu être exploitée par la suite mais qui, ducoup, ne pourra plus être développée. Par exemple : un premier système d’allianceentre les joueurs avait été mis en place dans le jeu. Or, certaines règles socialesmédiévales supplémentaires nous obligea, à cause de la programmation de cepremier système, à devoir mettre en place un deuxième système d’alliance. Lepremier système étant trop imbriqué dans la programmation du jeu, il n’a pas étépossible de le remplacer (et combiner les deux systèmes) car cela aurait étébeaucoup trop coûteux en temps. Au final, le second système était performant,mais entraînait des situations qui ne pouvaient pas être validées pour des raisons degameplay. La question a même été posée de savoir si l’ajout d’un nouveauparamètre de jeu était envisageable afin de régler tous les problèmes tout en sebasant sur la solution la plus historiquement réaliste possible.

Ainsi, apporter une solution à un problème peut également ouvrir sur denouvelles voies qui n’avaient pas été explorées jusqu’alors. La programmation avaitsystématiquement plus de conséquences qu’une simple résolution de problèmes.

En fait, la plupart du temps j’ai essayé de produire un code le plus‘transparent’ possible : cela doit fonctionner avec les données telles qu’elles le sontquand je reçois le problème à traiter, comme cela doit également fonctionner si cesdonnées se retrouvent être différentes plus tard. Cela n’est pas toujours possible,mais je considérais comme mon rôle le fait d’essayer à chaque fois.

De plus, il m’arrivait parfois de travailler sur une portion de code où mesdirecteurs de stage n’étaient plus allé depuis des mois, voire plus d’une année (!).Cela m’a fait prendre conscience de la responsabilité accrue qu’il m’incombait lorsde toute modification ou ajout de code. Car si je produisais un code qui n’était pasretouché par la suite, la moindre petite erreur pourraitdevenir une source de bug ‘caché’ qui leur demanderaiténormément de temps à retrouver (et d’autant plus sile code est clair ou pas).

Enfin, quand j’ai programmé la mise en place del’objet de jeu qu’est le champ de blé (image ci-contre),il a également fallu que je règle les interactions desautres objets (qui le pouvaient) avec celui-ci. Par

15

exemple, comment doit réagir un paysan qui ne peut plus interagir avec un champde blé ? Doit-il interagir avec un autre champ ? Attendre qu’il puisse à nouveau ? Neplus interagir avec rien ?

Il m’est arrivé d’appliquer mes propres réponses à ce genre de questions. Engénéral, le réalisme, qui est revendiqué par le jeu, nous donne une direction danslaquelle chercher. Mais la conséquence d’un tel choix de programmation I.A. serépercute automatiquement sur le gameplay du jeu, et probablement sur la façonde jouer des futurs joueurs, voire sur leur goût du jeu.

De même, ce qui devait être un simple arbre de situation hiérarchiquedeviendra la matérialisation d’un but à atteindre et un support des stratégies dujoueur. L’information étant vitale dans le jeu Rogues Island (tout comme au Moyen-Age… et même aujourd’hui), la question de ce que peut et/ou doit savoir le joueurse pose alors dans la programmation. Que rendre accessible ? Que rendremodifiable par le joueur ? Que veut-on autoriser au joueur ? Comment représenterl’arbre ? Derrière ces questions de codage informatique se cachent les choixcommerciaux et artistiques lié au jeu. Selon l’implication de la réponse, celle-ci étaitimposée par les membres de la société ou laissée à notre appréciation (une fois quel’on avait la connaissance de toutes les parties impliquées). Ainsi, la solution d’unproblème ne venait pas forcément de sa résolution technique, mais de la volonté derestreindre certains cas d’application1.

4.3.2) Créer l'arbre des vassalités

Le premier gros travail que j’ai eu à effectuer était de construire et afficher unarbre représentant la hiérarchie entre les joueurs, en fonction de leurs titresrespectifs.

La construction de l’arbre m’était simplifiée par le fait que je devais toutcommencer de zéro. Ainsi, je pouvais entrer petit à petit dans le code du jeu plutôtque d’être subitement projeté au cœur du nœud de vipère que peut être un codedont ne connaît rien.

4.3.2.1) Construction d’une fenêtre

Mon premier objectif était toutd’abord de construire une fenêtred’affichage de l’arbre ; fenêtre accessibledepuis la barre de menu du jeu (en basà droite sur l’image ci-contre). Il m’adonc fallu me familiariser avec leprocédé de création et de gestion desfenêtres du jeu.

A travers ce premier travail, j’aicommencé à comprendre lefonctionnement du jeu dans sa partieclient (le joueur). Construire une fenêtredans un programme orienté objet n’est

1 L’exemple le plus représentatif étant la recherche d’une méthode d’inversion de matrice (voir partie 4.3.4).

16

Exemple de problèmelié aux transfertsd’informationclients/serveur

pas difficile si on a bien réussi à repérercomment et où se font les choses. Par contre,gérer le déplacement de visualisation de l’arbreà l’intérieur de la fenêtre à travers tous lesdifférents référentiels peut vite s’avérer péniblequand on ne maîtrise pas encore le programmedu jeu. En effet, l’arbre -plus grand que lafenêtre- est affiché en hors-champ et la fenêtredevient le point de vue d’une portion de l’arbreoù le blason du joueur est au centre de la fenêtre. Ce qui lui implique un référentiellié à l’arbre, un autre lié à la fenêtre et un dernier lié à la position de la fenêtre desvassalités dans le jeu (le jeu fonctionne sur du multi-fenêtré1 et chaque fenêtre dujeu est déplaçable et modulable à volonté).

Ce problème a finalement été résolu en commençant l’affichage de l’arbre parun nœud (ou une feuille) : le blason du joueur. Ainsi, le blason du joueur (affiché aucentre de la fenêtre) devient la racine de l’arbre au lieu du blason du roi. Du coup,chaque joueur doit pouvoir accéder directement à sa position dans l’arbre. Or, seulle serveur connaît toutes les relations entre les joueurs (sans quoi on arriverait viteà du n’importe quoi). Ainsi, le joueur va juste demander une seule fois2 lesinformations des liaisons entre les joueurs à partir du joueur en descendant, puis enremontant. Ensuite, le joueur se créé son propre arbre qu’il pourra triturer et

afficher autant de fois qu’il le désire.Le problème d’une demandesimultanée de tous les joueursconnectés en même temps existeencore sauf que le serveur n’aura, àchaque demande qu’une portion desinformations à transmettre. Ainsi, leproblème de saturation est contrôléet limité.

4.3.2.2) Rechercher desinformations

La vraie difficulté se trouvedans le fait de devoir aller puiser lesinformations pour pouvoir construirel’arbre des vassalités. Pour soulagerle serveur, des questions sontimmédiatement apparues : à partirde quoi construit-on l’arbre ? Prend-on les informations chez le joueur ?Chez tous les joueurs ? Chez leserveur uniquement ?

1 Chaque joueur peut déplacer et gérer la taille de ses fenêtres pour se créer son propre environnement de jeu.2 Au lieu d’une demande à chaque boucle d’affichage d’OpenGl

17

Il est évident que dans un MMORTS on ne peutpas se permettre d’aller demander des informations àtous les autres joueurs (en plus pas forcément tousconnectés à ce moment). Surtout quand leur nombrepeut aller jusqu’à mille ! Et même si le problème desaturation du serveur a été réduite, il est toujours présent.Et enfin, à quelles informations le joueur a-t-il le droitd’avoir accès ? Peut-il être au courant de ce qui se trame dans son dosou de l’autre côté de l’île ?

A nouveau le gameplay arrive à la rescousse et la réponsedevient toute simple : le joueur ne peut pas. Suite à une discussion sur ce quedevait représenter l’arbre, nous étions initialement partis sur l’idée d’un arbrehiérarchique servant de ‘hall of fame’1, et permettant de se situer dans le jeu parrapport aux autres joueurs. Cependant, l’aspect politique du jeu fait que les joueurss’en serviraient comme source d’information pour contrôler les autres joueurs. Or,ce genre d’information n’était pas aussi facile à obtenir, ni aussi complète, àl’époque dont s’inspire le jeu. En effet, un seigneur qui décidait d’augmenter sonnombre de vassaux pour pouvoir renverser son suzerain, ne le criait pas sur tous lestoits. Ce genre d’acte politico-stratégique devenait quasiment impossible à faireavec un arbre ‘trop’ complet.

Cette décision d’autoriser une connaissance d’arbre incomplet devant êtreremis à jour par le joueur entraîna la création d’une nouvelle option aux ‘héraut’(unité mobile) des joueurs : rechercher des informations chez le voisin. Il a mêmeété évoqué la création d’une unité spécialisée pour rechercher ou demander del’information (espion, ambassadeur…). Mais cela entraîna l’apparition de problèmesclients/serveur qui nuisaient au gameplay voire au fonctionnement même du jeu ;problèmes qui ont dû être résolus.

4.3.2.3) Représentation graphique de l’arbre

A côté de ce problème lié à toutpartage d’information sur un réseau, laliberté m’a également été donnée d’étudierla représentation graphique de l’arbre.Niveau le plus basique de laprogrammation, la représentation de l’arbreparticipe entièrement au gameplay etnécessite de pouvoir être modifiée en cas dechangement. Ainsi, plusieurs propositionsont été faites à mes directeurs de stage qui

m’ont finalement donné le feu vert pour un type dereprésentation. Même si, encore une fois, la programmationest toute bête et est aidée par la programmation objet, lavolonté de vouloir rendre un code à la fois souple et robuste

1 Généralement il s’agit d’un classement des joueurs à partir des points obtenus pendant une partie, sous formed’un tableau.

Etudes de formes d’arbres

18

ne simplifie pas forcément les choses.En effet, dans les exemples suivants

certains arbres sont plus faciles à programmerque d’autres. Cependant, j’ai préféré donner lapriorité au gameplay. J’ai donc présentéplusieurs modèles à mes directeurs de stage,qui ont choisi le modèle affiché ci-dessous. Aufinal, la programmation permet de changer detype d’arbre en ne changeant que la méthodeservant à relier les blasons et en ajoutant uneligne ou deux dans le code principal del’affichage.

4.3.2.4) Problème annexe 1 : Trier très vite

A l’intérieur du code, un autre souci consistait à répondre à la demanded’afficher les vassaux d’un seigneur dans l’ordre croissant des titres. Trier des titresne pose pas de problèmes, mais les trier rapidement dans les contraintes desMMORTS si. Un algorithme propre au problème a été mis en place est s’est révélé

19

très efficace. Il est en effet impossiblede récupérer les informations et de lestraiter en même temps que la réceptiondes données (tri par insertion parexemple).

Un joueur ne peut avoir aumaximum que sept vassaux. Cettecontrainte était donnée par legameplay pour augmenter le roleplay1

des joueurs. La quantité de données àtrier est donc très faible et fixe. Sebasant sur ce constat, un algorithme detri reposant sur le parcours incompletd’une table a été mis en place.

Un tableau, de taille égale au nombre de titres du jeu multiplié par le nombremaximal de vassaux, est rempli directement, vassal après vassal, pour rendre plusrapide l’accès aux informations. Ensuite, une simple lecture par un accès ‘dirigé’ auxtitres permet d’obtenir rapidement et sans comparaison l’ordre des vassaux parrapport à leur titre. La lecture est ‘dirigée’ par le nombre de vassaux à trouver pourchaque titre et la position du premier de ces vassaux (le cas échéant) sur la lignecorrespondante.

Dans le pire des cas, nous avons 16 comparaisons à effectuer dont 9 parrapport à 0. Dans le cas générique, nous avions en moyenne 10 comparaisons (dont3 avec 0) sur sept éléments à comparer. Par exemple, le tri à bulle provoque dansle pire des cas 21 comparaisons entre entiers, sans tenir compte des déplacementsdes valeurs dans le tableau par la suite.

J’ai comparé cette méthode de tri spécifique par table à quelques méthodesde tri (bulle, insertion). Malgré la lourdeur de quelques actions supplémentaires, letri par table arrivait systématiquement en tête des résultats (avec un taux desuccès sur les autres proche de 99%). Le déplacement des données lors deséchanges après comparaison était, au vu des résultats, ce qui consommait le plusde temps dans tous les tris. Totalement absent du tri par table, ce dernier allaitdonc beaucoup plus vite dans la récupération des données, et ce malgré le fait quele tri par table était toujours le dernier en rapidité lors de la mise en place desdonnées (à cause de la création de la table).

Au final, le tri par table a le temps de capture des données le plus réduit et letemps total du tri est minimum. Les deux contraintes principales sont vérifiées. Parcontre, le joueur doit alors perdre un petit peu plus de temps lié à la construction dela table (qui n’est construite qu’une seule fois et sert à nouveau à chaque tridemandé, avec une simple remise à zéro des valeurs qui ne sont pas nulles). Ducoup, plus le nombre de tri à faire est important, plus l’algorithme est intéressant :la perte de temps de création de la table est alors divisée par le nombre de fois oùelle est réutilisée.

1 Certaines interactions entre joueurs (ici l’aspect politique) ne sont pas ou sont peu réglementées pour donner plusde liberté à un joueur pour jouer son rôle. Avec un maximum de seulement 7 vassaux, le jeu oblige le joueur àinteragir avec d’autres pour se débarrasser des ‘poids morts’ et ‘vassaliser’ des joueurs mieux titrés.

20

4.3.2.5) Problème annexe 2 : Afficher oui, mais afficher quoi ?

Enfin, en parallèle à l’affichage de l’arbre ilfallait, en lieu et place des nœuds et de feuilles,afficher le blason des joueurs. Quelquesinformations sur les joueurs comme leur nom et leurtitre étaient également à ajouter. Il fallaitéventuellement prévoir l’affichage la devise dujoueur, ce qui était évoqué, et être prêt à devoirafficher d’autres paramètres qui n’étaient pasencore créés. Il a donc fallu créer un ‘super-blason’contenant toutes ces informations, l’arbre ayantainsi à afficher ces ‘super-blasons’ au lieu desblasons habituels. On imagine ici aisément l’aidequ’a pu apporter la programmation orientée objet.

Ces ‘super-blasons’ n’ont pasposé de difficulté de construction, sice n’est qu’il s’agissait de mapremière programmationd’envergure où la programmationorientée objet devait être exploitéele plus possible. Ainsi, les blasonssont devenus des blasonsornementés tels que l’on peut les observer dans leslivres d’héraldique. Au simple blason était ajouté ladevise (une partie en bas qui pouvaient être rempliede texte), un timbre (une partie en haut contenantle nom, le titre du joueur ainsi qu’un éventuel siglereprésentant la couronne liée au titre du joueur), etdeux flancs (droite et gauche, avec généralementdes tenants1 de chaque coté, soit un dessin dechaque côté). Enfin, il existait plusieurs tailles de cesblasons ornementés selon que le personnage est lejoueur, un vassal ou un suzerain.

La création de l’arbre hiérarchique des vassalitésm’a donc permis de plonger dans le code du jeu en yinsérant un nouveau code. Maintenant que j’étais à l’aiseavec la programmation orientée objet et le code du jeu,mes directeurs de stage m’ont fait mettre les mains plusen profondeur dans le jeu avec l’ajout d’un nouvel objetde jeu : les champs de blé.

1 Animal emblématique du personnage (ours, lion, salamandre…), flanqué de chaque côté du blason.

Une tentative de représentation dela structure gérant l’arbre…

21

4.3.2.6) Souplesse du code

Dans le résultat final, les traits joignant les blasons peuvent être remplacés parn’importe quoi (dessin de tige en fer forgé par exemple). Les blasons suivent leséventuelles modifications qui seraient apportées par la suite : l’affichage de l’arbremarche toujours si on utilise d’autres types de blasons. Enfin, avec très peu demodification de code on peut demander au programme d’afficher autre chose avecou dans les blasons (une ligne en plus de la fonction/méthode programmée). Ainsi,l’affichage de l’arbre des vassalité a servi plus tard pour aider à tester et débuggerd’autres parties du code (les alliances notamment) pour lesquelles il a parfois falludemander à afficher d’autres informations non prévues à l’origine.Il fallait donc également que le code soit suffisamment compréhensible et intuitif (etbien commenté !) pour qu’y ajouter une partie de code soit rapide et facile.

4.3.3) Gestion d’un objet : les champs de blé1

Contrairement au travail précédent, j’ai dû cette fois-ci entrer dans uneportion de programme déjà existante afin d’y ajouter un élément de jeu (les champsde blé).

Dans un premier temps, il m’a fallu définir le champ de blé. Tout d’abord,certaines caractéristiques m’avaient été fixées comme la taille ou l’aspect de l’objetqui apparaîtra dans le jeu et les éléments graphiques le constituant.

Je me suis donc d’abord attelé à afficher cet objet dans une partie du jeu quinous sert à tester le programme. Il y avait dans les premiers tests des problèmesde ‘calage’ avec le décor et l’objet avait du mal à être posé correctement sur le sol.Ce qui n’arrangeait pas les choses, à ce moment là, c’est que les bâtiments du jeupeuvent se poser sur des terrains en pente et le champ avait certains problèmes surdes pentes trop raides. De plus, lerendu purement graphique duchamp n’était pas aussi bien quecela aurait dû. Suite à quelquescorrections, et pour avoir unchamp plus ‘joli’, nous avons revuquelques caractéristiques commeleur taille et simplifié et modifié cequi constituait leur élément 3Ddans le jeu.

Une fois que l’on avait unélément sur lequel on pouvaittester les codes et l’aspect final del’objet 3D terminé, je devaism’attaquer au compliqué de latâche : gérer les interactions entrece nouvel élément de jeu et les

1 Je ne pourrai malheureusement pas détailler ici, pour cause de confidentialité du code, les modifications apportéesou expliquer l’état du code avant puis après mon intervention.

22

autres déjà existants.

J’ai ainsi pu découvrir unprogramme asynchrone,fonctionnant par messages. Eneffet, ce sont à travers cesmessages que certaines actionss’entreprennent ou pas. Il m’adonc fallu modifier certainsmessages ou (plus rarement) enajouter d’autres afin de pouvoirintroduire les champs de blé dansle fonctionnement du jeu. Commetous les jeux où le joueur décidelui-même de ce qu’il va faire sansscénario pour le guider, ce sontses actions qui vont, au fur et à

mesure, déclencher ou pas des interactions entre les éléments du jeu. La partiedans laquelle j’officiais logeait l’intelligence artificielle (I.A.) du jeu et je devais doncprogrammer toutes les réactions des divers éléments du jeu qui pouvaient interagiravec les champs de blé (et mine de rien, il y en a plus que l’on ne croit !).

Bien entendu, il m’a fallu ensuite corriger les bugs incompréhensibles dugenre d’un paysan qui s’arrête brutalement de semer, d’un autre qui décide de nepas amener la récolte du champ jusqu’à la ferme, d’un troisième qui, en modeagressif, se met à attaquer un champ, etc.

A travers ces nombreux bugs, j’ai également pu en déceler d’autres liés àl’I.A. qu’il a fallu que je corrige, entraînant même parfois des modificationsd’éléments importants de la programmation du jeu.

Le temps de traitement de cettepartie pourrait se décomposer ainsi : unquart du temps pour programmer leschamps et les insérer dans le programme,un autre quart pour modifier les élémentsinteragissant avec les champs, et enfin lamoitié du temps pour trouver et corrigerles bugs ! Non pas qu’il y en ait eu tantque ça, mais la plupart étaient vraimentspécifiques à certaines actions ayant lieuà certains moments et du coup trèsdifficiles à reproduire. De plus, lamanipulation de certain éléments de jeu(paysans, ferme, …) afin de tester leschamps a révélé des bugs dans leur

programmation que j’ai alors dû corriger.De plus, il me fallait tester toutes les interactions possibles avec le

champ pour être sûr qu’il soit certifié sans bug. Il est bien entendu possible quequelques uns soient passés au travers, mais la plupart de ceux trouvés m’ontpermis de travailler ponctuellement un peu partout dans le programme et de bien le

23

comprendre.Ces bugs m’ont aussi permis de me rendre compte que je n’avais aucune

méthode de débugage, ainsi que ma méconnaissance ou mon incompréhension decertains processus ayant lieu dans le bas niveau de la machine. Mes directeurs destage ayant remarqué la chose, ils me confièrent après les champs de blé un travailà faire en assembleur.

4.3.4) Recherche d’une inversion de matrice optimale

Ayant constaté que je savais manipuler les matrices, mes directeurs de stageme donnèrent comme travail de regarder les fonctions et les méthodes participant àl’inversion d’une matrice. L’objectif était de regarder la méthode utilisée(programmée je crois par un autre stagiaire) et voir si je pouvais améliorer le calcul.L’inversion de matrice intervenant souvent lors du calcul de l’image à afficher, ilserait ainsi possible de gagner un peu de temps de calcul. Pour regarder si la ou lesmodifications apportaient un plus, l’unité de comparaison était les ‘fps’, soit lenombre d’image affichées par secondes (frame per second).

La méthode utilisée était la méthode de Kramer, et était codée de façonoptimale. Cette méthode a l’avantage de calculer l’inverse d’une matrice à partir deses coefficients et des déterminants des sous-matrices qui découlent de la matriceinitiale. Cependant, je fus étonné qu’avant de lancer la méthode il n’était fait aucuntest d’inversibilité de la matrice, car dans le cas contraire cela pourrait poserproblème. Mais le programme ayant toujours tourné sans aucun problème, j’endéduis que les matrices devaient être toujours inversibles. Je me suis alorsintéressé aux matrices qui étaient inversées.

Or, j’ai constaté que la méthode était utilisée en très grande majorité par desmatrices de rotation, indissociables du calcul d’affichage 3D, ou des matricesobtenue à partir d’elles. Toute matrice de rotation est en effet inversible car leurdéterminant est égal à 1 ou –1 (donc toujours différent de zéro). J’ai ensuitedémontré que toute matrice de rotation est orthogonale, ce qui entraîne que leurinverse est égale à leur transposée. Cela m’a alors permis de recréer des méthodesspécifiques de détermination d’inverses de matrices de rotation. J’ai ensuite pumodifier les méthodes afin d’être spécifiques aux autres matrices utilisées dans leprogramme et issues des matrices de rotation, du moins jusqu’à un point où iln’était plus possible d’intervenir.

Au final, le champ d’action de la méthode de Kramer, qui est très efficacemais aussi très lourde, se trouvait beaucoup plus limité. J’ai ainsi fini les premièresmodifications en ayant gagné 2 fps (le jeu tournait alors vers les 60 fps). C’étaittoujours bon à prendre.

Ensuite, une fois les méthodes d’inversion définitivement adoptées, je devaisles transcrire en assembleur, à partir d’un code que fournissait le compilateur(Visual C++). Ma tâche fut de rectifier ce code, obtenu automatiquement. Le butétait encore de gagner du temps de calcul et de manipulation des données enréajustant les manipulations de registres du code.

Enfin, j’ai testé différentes variantes du code afin de rechercher la méthode

24

Editeur de

optimale d’inversion d’une matrice quelconque, basée sur la méthode de Kramer1. Ilest impressionnant qu’une ‘simple’ optimisation de code avec passage enassembleur permet de diviser par 3 fois le temps de calcul.

Il est également à constater que certains résultats de ces tests nous ont poséproblème et ne sont explicables que par une mauvaise structure des processeursIntel utilisés. En effet, deux méthodes strictement identiques mais utilisant desregistres dans autre ordre (xmm1 puis xmm0 au lieu de xmm0 puis xmm1 parexemple) donnaient parfois (sic) des résultats différents !!!2 Les résultats obtenussont très intéressants, et la façon d’y parvenir m’a permis de prendre conscience debeaucoup de points faibles de la machine quand on s’y penche au plus bas niveau.Ils permettraient à eux seuls de rédiger une étude sur l’impact de la gestion de lamémoire cache d’un ordinateur et de sa conséquence (désastreuse) sur les tempsde calcul. Ces tests et les conclusions qui ressortaient de la lecture des résultatsm’ont permis de mieux comprendre certains choix et traitements bas niveau devariables qui étaient utilisés dans le jeu. Ce travail avec l’assembleur m’incitedésormais à faire plus attention à tout ce qu’il se passe au plus bas niveau de lamachine lors de la programmation.

4.3.5) Debugage: Corriger l'éditeur de cartes

Le dernier gros travail que j’ai dû faireconsistait à débuguer l’éditeur des cartes du jeu,ainsi que lui ajouter quelques options.

Au départ, je devais donc corriger quelquespetits bugs. Par exemple, des maillages du terrainsbuggaient dans certaines situations, ou après avoirutilisé certains outils de modélisation du terrain. Ilm’avait été précisé que la programmation étaitmoins vitale dans ce programme et ne nécessitaitpas forcément une programmation fine (l’éditeurne servant qu’à usage interne dans l’entreprise).

Après avoir un peu manipulé le programme afinde découvrir quels étaient les bugs et quand ils sedéclaraient, je me rendais compte que quelques outilssupplémentaires rendraient la manipulation del’éditeur moins pénible. Ainsi, je me suis permis derajouter une variable (deltaschift) permettant derégler, plus ou moins finement, l’outil alors utilisé.Quand par exemple l’utilisateur voulait construire unemontagne, il devait attendre que le maillage monte, àune vitesse unique très basse afin de pouvoir créerdes détails sur le relief du jeu. Grâce à l’option

1Les résultats de tests de différentes méthodes codées avec des variantes sont placés dans les annexes jointes au

rapport de stage.2 Ceci est flagrant dans les résultats montrés en annexe n°2. D’autres jeux avec plusieurs variantes sont disponiblesavec la version informatique du rapport.

25

ajouté, la vitesse devenait enfin variable et entièrement contrôlable (avec optionsde mise à 0, de mise en mémoire d’une vitesse, etc).

Une fois les bugs corrigés, je devais ensuiteprogrammer un assistant de lacune de textures. En effet,le jeu contient quatorze textures de sol différentes(herbe, pelouse, sable, roche, etc) et lorsque l’utilisateurvoulait plaquer des textures sur le sol de la carte, ilarrivait qu’il manquait des textures de transition.L’objectif était donc de créer une fenêtre qui s’ouvrelorsqu’une texture est inexistante, et qui affiche la texturemanquante.

Au début, je devais utiliser une fenêtrewindows pour annoncer la texturemanquante, mais elle apportait plus deproblèmes qu’elle n’en résolvait. Il fut doncdécidé que je n’afficherai pas une fenêtre,mais un simple texte définissant la texturemanquante.

L’assistant de lacune terminé, je devais corriger l’affichage du rendu de reliefsur le radar de l’éditeur de carte. Le but était de ‘colorier’ chaque point de la cartedu radar en fonction de sa hauteur. Si la programmation s’est révélée plutôt simple,la difficulté s’est finalement trouvée dans le choix des niveaux d’altitudes et descouleurs correspondantes. En effet, l’altitude variait sur des valeurs allant jusqu’àplusieurs milliers (elle était codé sur 16 bits) alors qu’il n’y a que 3 couleurs (rouge,vert et bleu) ayant chacune seulement 256 niveaux. Chaque dégradé de couleuravec chaque combinaison entre elles devaient représenter une trop grande variationd’altitude. Les couleurs ont alors été définie afin d’essayer d’obtenir un meilleurrendu possible.

Un premier rendu de base n’était effectué que sur la seuleportion de carte éditée et montrait un mauvais choix des couleurs. Ila ensuite fallu que je modifie les niveaux afin d’avoir des rendus lesplus intéressants possible. Par exemple, j’ai ajouté un dégradé versle bleu clair au niveau des côtes afin de bien les détacher. Celaajouta également un effet de profondeur de l’eau.

Ces niveaux étaient ensuite variables en fonction de paliers que lesprogrammeurs suivants pouvaient modifier si les altitudes venaient à changer.

26

Ces modifications sur le radar de l’éditeur de cartes ont ensuite étérépercutées dans l’écran du radar du jeu.

4.3.6) ‘Petites’ opérations

Entre ces trois ‘grands travaux’ qu’ont été l’élaboration de l’arbre desvassalités, l’ajout du champ de blé et le débugage de l’éditeur de carte, j’ai eu àréaliser de plus ‘petits travaux’ : débugages divers, ajout d’un type d’unité,changement de version de format d’image ou la modification de codage deshauteurs de 8 bits à 16 bits.

Ces travaux étaient ‘petits’ par leur importance (simple débugage ouprogrammation simple) ou par leur durée (ajout d’une unité), mais ils m’ont permisde toucher et de manipuler les principales parties du jeu vidéo. Ainsi, j’ai pu ‘goûter’à tous les aspects d’un jeu vidéo et sortir de ce stage avec encore plus demotivation pour la programmation qu’en y entrant.

V) ConclusionDevoir travailler sur un MMORTS m’attirait car il combinait à la fois la

programmation réseau et la programmation temps réel dans un programme degrande envergure. Au final, j’ai été assez peu confronté à la programmation réseausi ce n’est à travers les problèmes de communication entre clients et serveurs. Parcontre, j’y ai découvert un programme asynchrone mettant en oeuvre toute lapuissance de la programmation orientée objet. Ce type de programmation que jeconnaissais mal m’a passionné.

Je suis également sorti de ce stage avec un autre point de vue sur laprogrammation. Les aspects de lisibilité et de clarté du code avaient pointé leur nezlors des projets à la faculté, mais j’ignorais que cela pouvait être à ce point capitaldans une programmation de grande envergure.

27

En plus de la programmation brute, le stage effectué au sein de la sociétéd’édition de jeux vidéos Atrébates Editions m’a également permis d’entrevoir lesnécessités et processus commerciaux, les volontés et démarches artistiques decréation puis les aspects et les contraintes techniques qui en découlent ensuite dansla programmation. Tout en me formant à la programmation objet et laprogrammation spécifique aux jeux vidéo, j’ai en effet pu assister aux nombreux‘allers-retours’ entre demandes artistiques et contraintes techniques qui ontquotidiennement lieu dans une société de création de jeux vidéo. J’ai ainsi puconstater l’aspect commercial de la programmation en entreprise.

Je tiens également à préciser que la totalité du stage s’est effectué dans uneexcellente ambiance. De plus, je pense avoir été très bien dirigé et avoir pu ainsitoucher à la plupart des aspects de la programmation d’un jeu vidéo, de laprogrammation en entreprise, ainsi qu’une bonne base de programmation orientéeobjet. J’ai également pu prendre conscience de mes points forts (par exemple : lesmatrices ne m’effraient pas) et de mes points faibles (manque de méthode dedébugage, peu de connaissance sur le bas niveau)1. J’ai également eu l’occasion derencontrer des personnes issues de formations différentes de la mienne, qui m’ontpermis d’entrevoir d’autres méthodes de travail et d’autres connaissances.

Ce type de travail d’équipe dans une ‘start-up’ n’est probablement pasreprésentatif du fonctionnement de toutes les entreprises officiant dans le jeu vidéo(et d’informatique en général). Cependant, il est plus probable que les plus grandessociétés de développement de jeux vidéo ne m’auraient pas permis de pouvoir ainsiassister à tout les processus entourant la création d’un jeu vidéo.

VI) RemerciementsJe tiens à remercier chaleureusement monsieur Ingels David et monsieur

Ingels Laurent pour m’avoir accueilli dans leur ‘petite maison’ d’édition et de m’avoirfait découvrir les joies de l’AWM. Je tiens aussi à adresser par la présente messalutations aux deux stagiaires que j’ai rencontré pendant mes quatre mois destages : Ghislain Lucas et ‘lapin’ JC.

1 Comme le démontre une attestation de stage (en documents annexes au rapport) que je me suis permis de faireremplir par mes directeurs de stage.