The Nak3d Project

The Nak3d Project
Rapport de projet
Nak3d Team
Jayat Maxime
Failly Pierre-Antoine
Chiche Michaël
18 juin 2008
Table des matières
1
Introduction
2
Présentation de l'équipe
3
Reprise du cahier des charges
4
EpiKartMania
5
La réalisation du projet de A à Z
2.1
2.2
2.3
2.4
2.5
3
Formation de l'équipe . . . . . . .
Maxime Afsgang Jayat . . . .
Pierre-Antoine PaF` Failly . .
Michael Chiche-a-pwal Chiche
Charles newbie Colombier . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.1 Les diérentes parties à traiter . . . . . . . . . . . . . . . . . .
3.2 Répartition des tâches . . . . . . . . . . . . . . . . . . . . . .
3.3 Organisation du travail sur l'année . . . . . . . . . . . . . . .
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
5.1
5.2
5.3
5.4
5.5
Introduction . . . . . . .
Principe du jeu . . . . .
Détail d'une partie . . .
Les bonus . . . . . . . .
Le menu principal . . . .
Le menu dit in game Le multijoueur en réseau
L'éditeur de circuit . . .
Le site web . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Introduction . . . . . . . . . . . . .
Le concept du jeu : Tous ensembles
Les débuts en Delphi : Maxime . .
Passage à GLFW : Michaël . . . .
La gestion de la map : Maxime . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
5
5
6
6
8
9
10
10
10
12
12
13
13
15
15
15
17
17
17
18
18
19
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
6
Le moteur physique : Maxime . . . . . . . . . . . . . . . . .
Le menu : Pierre-Antoine . . . . . . . . . . . . . . . . . . . .
Le son : Michaël . . . . . . . . . . . . . . . . . . . . . . . . .
L'éditeur de circuit : Maxime . . . . . . . . . . . . . . . . .
La gestion interne du jeu : Checkpoints et multiples véhicules :
Maxime . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le mode deux joueurs : Maxime . . . . . . . . . . . . . . . .
Les adversaires (IA) : Maxime . . . . . . . . . . . . . . . . .
Les bonus : Maxime . . . . . . . . . . . . . . . . . . . . . . .
Le réseau : Pierre-Antoine puis Maxime . . . . . . . . . . . .
Conclusion
.
.
.
.
20
21
21
22
.
.
.
.
.
23
23
23
24
24
26
2
Chapitre 1
Introduction
Dès notre arrivée en InfoSUP à EPITA, nous avons appris que nous aurions un projet à rendre pour la n de l'année. Il consistait à nous faire
comprendre comment il fallait traiter un projet sur du long terme, et savoir se projeter dans l'avenir, et savoir prévoir quel serait notre avancé pour
chacune des 4 diérentes soutenances, chaque estimation étant crucial à une
bonne avancée du projet.
Ce projet était soumis à quelques contraintes, en eet, nous devions coder ce
jeu en Delphi, en utilisant OpenGL ou DirectX, ensuite nous étions restreint
en nombre, 4 élèves au maximum par groupe, ce qui nous pousserait à travailler plus que si l'on était 5 ou 6.
Mais la plus grande de toutes, était sans doute celle du temps, en eet, notre
rythme devait être soutenu, car il fallait montrer une réelle avancée à chaque
soutenance.
Ce projet a eu pour but de nous apprendre à travailler en groupe, de se
répartir les tâches, en connaissant les diérents niveaux de connaissances en
programmation de chacun, an de pouvoir avancer correctement tout au long
de l'année. Il fallut de nombreuses recherches sur internet, pour arriver à nos
ns, nous découvrîmes le vrai potentiel d'internet, et de Google, ainsi que
Wikipédia, qui se révélèrent être de véritables encyclopédies, bien fournies,
et très utiles pour l'avancement du jeu.
Il nous a aussi fait voir des aspects de la programmation que nous ne connaissions, pour la plupart, pas du tout.
Nous sommes heureux de ce qu'est devenu notre jeu, et espérons qu'il
vous plaira.
N'oubliez pas, l'adresse du site web : http ://nak3d.free.fr
3
Chapitre 2
Présentation de l'équipe
2.1 Formation de l'équipe
La Nak3d team a commencé à se former dès le début de l'année lorsque
nous nous sommes rencontrés. Mais la formation de groupes de quatre personnes a vite posé problème car il y a seulement une chance sur quatre que le
groupe de connaissance qui se forme soit un groupe dont le reste de la division par quatre est zéro, c'est mathématique (enn presque) . Donc Maxime,
Michaël et Pierre-Antoine se sont retrouvés après plusieurs changements de
groupes à trois, et Charles s'en ensuite intégré au naturellement restant seul,
victime de la loi du groupe de quatre. . .Finalement, ce n'est pas la loi des
quatre groupes, mais belle et bien celle de l'EPITA, qui fera abandonner
Charles, et le poussera donc à abandonner le groupe. Il ne reste donc à ce
jour que les 3 premières personnes citées. Le nom de l'équipe a été choisi
suite au célèbre Chiche ? - A poiiiiil ! ! . Un 3 a ensuite remplacé le e pour l'unique raison que ça fait plus geek, ce que nous deviendrons tôt
ou tard à l'EPITA. Pour ce qui est du logo, un beau Interstate 42 a été
trouvé an de rester dans la dynamique geek attitude .
2.2 Maxime Afsgang Jayat
El Maestro, notre codeur préféré, celui qui peut faire des miracles et même
plus encore si anité... Il est sérieux, travail sans se plaindre l et quand il a
ni, au lieu de s'arrêté la, il vérie que tout est propre, pas non seulement dans
son travail, mais aussi dans celui des autres. C'est lui qui fait le plus avancé
le projet, il aura fait seul, un moteur physique, l'application des textures, les
eets de lumières et d'ombres, je le répète, El Maestro. . .
4
2.3 Pierre-Antoine PaF` Failly
Ne pas y arriver, c'était la blague du jour, mais je me suis décidé de la
laisser. . . Notre Super Chef de Groupe (NSCG), qui à tout fais pour que le
Charles travaille, en vain. NSCG est celui qui fait le site internet, et le menu
qui est trop beau ;). Même s'il nous soule avec sa copine toute la journée. Il
sait faire son travail en temps et en heure, et surtout le plus important, il le
fait bien, certes il y a souvent de faute d' " aurteaugrafe ", mais on l'aime
bien quand même.
2.4 Michael Chiche-a-pwal Chiche
Mr Blague (pas drôle parfois, pour les intimes. . .). Pas le plus travailleur
du groupe, mais son imagination débordante, a permis au groupe d'avancé
dans des domaines anodins, comme la décision du nom du jeu, ou du type
de jeu que nous allons faire mais aussi dans des domaines plus important tel
que le futur moteur physique qui sera fait pour la 3eme soutenance. Il est
aussi chargé de faire des personnages pour le jeu.
2.5 Charles newbie Colombier
Inconnu au bataillon, touriste, que s'il existait un statut au dessus de 1ere
classe, et bah il serait sans doute dedans, non seulement il fout rien, qu'en
plus il arrive à se plaindre, bref, Il met plus de bâtons dans les roues qu'il ne
pédale pour nous faire avancer. . .
He left EPITA.
5
Chapitre 3
Reprise du cahier des charges
La partie qui suit rappelle ce que nous avions prévu lors de l'écriture de
notre cahier des charges.
3.1 Les diérentes parties à traiter
Les éléments que nous avions prévu de traiter étaient :
Moteur 3D : Le moteur 3D correspond à une des plus grosses parties du
projet et correspond à ce que nous achons à l'écran. Un jeu en mode
console, c'est marrant mais après 2 minutes, on a mal aux yeux et on
s'ennuie. C'est pourquoi l'aspect graphique du jeu est très important
et même primordial au sein de notre projet. Un jeu bien pensé mais
laid, est sûrement moins bien apprécié que le même jeu en beau. Mais
de l'aspect graphique résulte aussi la qualité du divertissement, car le
moteur 3D ne fait pas que rendre des modèles ou des textures plus
nes, il permet également d'optimiser la jouabilité et permettre ainsi
un jeu plus poussé. Une des parties les plus diciles de la réalisation
de l'achage du jeu a été l'optimisation et plusieurs prises de tête
(et de becs aussi) ont été nécessaires pour arriver à un jeu à la fois
beau et uide. Techniquement, le moteur graphique a été codé à l'aide
d'OpenGL.
Moteur physique : Le moteur physique du jeu englobe en réalité plusieurs
choses : on peut d'abord parler de la simulation des lois de la physique
du monde réel dans le monde. Malgré tout, une simulation la plus
réaliste possible est inutile car ce que nous avons réalisé n'est pas un
jeu de simulation tel que Flight Simulator, mais un jeu d'arcade dans
lequel, le fun est privilégié. Cependant, un véhicule qui freine, même
6
dans les jeux d'arcade, s'arrète, c'est inévitable. Et ça, nous l'avons
codé. Ensuite, le moteur physique comprend aussi les collisions entre
les diérents objets, chose plus que nécessaire, car traverser les murs,
ce n'est pas très réaliste. Nous avons réalisé ce moteur physique de A
à Z (ou plutôt de begin à end) en nous inspirant de ce que nous avons
trouvé sur internet dans ce domaine.
Jouabilité : Ce que nous appelons jouabilité a un lien très fort avec le
moteur physique. C'est ce qui nous permet de jouer, c'est-à-dire, ce qui
permet au programme d'interpréter les entrées du programmes et ainsi
modier la sortie : Par exemple, en appuyant sur la èche du bas, le
véhicule freine, en appuyant sur la èche du haut, il accélère, etc. Cette
catégorie comprend également la gestion des événements extérieurs au
joueur : autres concurrents, bonus, etc.
Son : Une bonne gestion du son est ce qui permet une immersion plus profonde dans le jeu et permet de se sentir vraiment aux commandes du
véhicule que nous contrôlons. La partie sonore se divise en plusieurs
parties : D'abord la musique du menu, des crédits. Puis les eets sonores, ce qui était plus dicile car un son mauvais ou trop répétitif peut
vite énerver et gâcher complètement le jeu ; pour cela, nous avons fait
simple, et avons simplement mis un eet lors du démarrage de la course
(Ces eets sont nos voix modiées). Finalement, nous voulions mettre
quelques sons correspondants aux diérents personnages présents dans
le jeu, mais nous avons vite laissé tomber cette idée, dans la mesure où
aucun d'entre nous n'était capable de créer des modèles 3D adéquates.
S'ensuit ensuite l'implantation du système sonore dans le jeu, ce qui
s'est fait assez facilement grâce à des bibliothèques sonores disponibles
sur internet telles que FMOD, dans lequel nous avons un peu modié
le code an de le rendre plus simple d'utilisation.
Éditeur de circuit : An de pouvoir prolonger la découverte de nouveaux
circuits nous avons programmé un éditeur de circuit qui permet à chacun de créer ses propres circuits et à l'équipe de réaliser les circuits de
base du jeu. Ainsi les fans du monde entier du futur jeu " EpiKartMania
" pourront exprimer leur créativité au travers de l'éditeur et pourront
publier leurs créations sur les énormes sites de fans qui seront créés à
l'occasion de la sortie mondiale du jeu. D'un point de vue pratique,
l'éditeur a été grâce aux outils fournis par Delphi.
Réseau : Un des points-clés du jeu. En eet, le jeu sera le plus apprécié lors
du jeu en ligne ou en réseau local. Même si le jeu en solo est génial, rien
ne remplace la erté d'humilier (ou pwner selon les termes en vogue) ses
amis à un jeu ! C'est pourquoi " EpiKartMania " s'appuie au maximum
7
Et
sur la gestion du jeu en réseau.
nous avons tout mis ensemble ! Eh oui, travailler chacun de son coté sur
sa partie n'est pas possible et le jeu n'est pas une juxtaposition d'éléments
divers mais un ensemble dans lequel il est impossible de dissocier les éléments les uns des autres, il n'est par exemple pas possible de gérer le jeu en
réseau, s'il n'ache pas la moindre fenêtre, ainsi que son contenu (je ne parle
pas d'une fenêtre d'un immeuble, mais bien d'une fenêtre Windows) ! Bon,
d'accord, cet exemple est un peu extrême. . .
3.2 Répartition des tâches
Moteur 3D
Moteur physique
Gameplay général
Éditeur de circuit
Menu, options
Son
Réseau
Site Web et extras
Rapport/LaTeX
Maxime Pierre-Antoine Michaël Charles
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Nous nous sommes répartis les tâches, en prenant en compte les capacités
des diérents membres du groupe. Le pilier de notre projet est sans aucun
doute Maxime, à qui notre projet doit beaucoup. Il a donc été chargé de faire
les taches que nous jugions les plus compliqué, c'est dire le moteur physique,
graphique, ainsi que l'IA, mais il n'était tout de même pas seul, car les autres
membres du groupe étaient aussi présents, pour parvenir aux solutions des
diérents problèmes rencontrés lors du développement du projet. Ensuite,
Pierre Antoine, notre chef de projet, a été vitale pour la bonne organisation
et la cohérence de notre groupe, mis a part Charles, qui est parti d'EPITA
sans nous prévenir. C'est à notre chef que nous devons notre resplendissant
site Internet http ://nak3d.free.fr/, ainsi qu'une partie du réseau, le chat.
Michael, tout en détendant l'atmosphère, grâce a ses vannes, drôle de temps
en temps, avait une imagination très grande qui permettait de résoudre des
problèmes grâce a ses " illuminations ", certes elles ne fonctionnaient pas tout
le temps, mais on tout de même servies. Il a aussi été chargé de s'occuper du
son du jeu, une partie du moteur physique, ainsi que le moteur graphique.
Il sera aussi entièrement charger de s'occuper de la jaquette du jeu qui est
plutôt réussi.
8
Charles n'a rien fait et est parti d'epita sans crier gare, donc, rien d'intéressant a dire, à part que l'on avait remarqué son manque de motivation,
ce qui allait impliquer son manque d'investissement dans le jeu, donc ne fut
donner que tâches " faciles ", que les autre membres du groupe pourrait faire
facilement
3.3 Organisation du travail sur l'année
Voici le planning que nous nous étions xés lors de l'écriture du cahier
des charges. Il a à peu près été respectée tout au long de l'année et nous a
servi de base de rythme de travail pendant toute la période de travail :
Soutenances
re
1
2e
3e
nale
Moteur 3D
ébauche avancé nalisé nalisé
Moteur physique ébauche avancé avancé nalisé
Gameplay
ébauche avancé avancé nalisé
Éditeur de circuit
sans
avancé nalisé nalisé
Son
sans
sans ébauche nalisé
Réseau
sans
sans ébauche nalisé
Site Web
avancé nalisé nalisé nalisé
9
Chapitre 4
EpiKartMania
4.1 Introduction
Dans cette partie, nous allons regarder ensemble le résultat de notre travail de toute l'année. Si vous ni lisez que cette partie, vous devriez avoir déjà
une bonne idée de ce qu'est le jeu, sans même l'avoir vu.
4.2 Principe du jeu
EpiKartMania est un jeu de course de kart. Il peut se jouer contre des
adversaires pilotés par l'ordinateur mais aussi et surtout contre un adversaire
réel, sur le même PC ou par réseau (local ou internet). Comme dans tout
jeu de course le joueur doit arriver en premier au bout d'un circuit après un
ou plusieurs tours. Mais ce qui dière le jeu d'un jeu banal, est la présence
de quelques bonus permettant de décupler ses capacités et ainsi de coier
tous ses adversaires au poteau. Le dé est bien entendu de gagner la course,
mais aussi de réaliser le meilleur temps au tour qui est sauvegardé entre les
parties.
10
Fig.
4.1 Le jeu
11
Fig.
4.2 Un bonus à ramasser
4.3 Détail d'une partie
Les touches pour déplacer son kart sont par défaut ZQSD pour le joueur 1.
La touche E permet d'activer les bonus ramassés et la barre d'espace permet
de freiner le kart. Pour parcourir l'intégralité du circuit, il faut d'abord passer
par tous les checkpoints, symbolisé au sol par des rectangles indiquant leur
positionnement. Il n'est pas nécessaire de passer sur le checkpoint, mais à
proximité de celui-ci. Le checkpoint vers le quel il faut se diriger est indiqué
sur l'écran par une èche bleue et également dans le jeu par un cristal vert
rappelant celui des Sims. Après avoir ni un tour, le temps s'ache et est
enregistré s'il s'agit du meilleur temps jusqu'à là. Après avoir parcouru le
nombre de tour déni (habituellement trois), la partie est nie et le score
s'ache.
4.4 Les bonus
Tout au long des circuits se trouvent des bonus qui permettent de multiples choses et qui sont activés par la touche E par défaut. Voici la liste des
diérents bonus :
Accélération : eet 7 secondes, permet d'avoir une accélération et une
vitesse max doublée.
Vitesse : eet instantanée, multiplie la vitesse du kart instantanément
par 2, 3 ou 4. Il s'agit du bonus le plus dicile à utiliser.
Pilote semi-auto : eet 10 secondes, le kart du joueur utilise l'IA pour
se déplacer mais le joueur continue à inuer dessus ce qui permet d'aller
plus vite.
12
Fig.
4.3 Le menu principal
Temps : eet instantané, réduit le temps au tour du joueur de 1 à 3
secondes.
Le bonus temps a l'air de fausser les records de temps au tour mais ils font
partie du jeu et il faut jouer avec.
4.5 Le menu principal
Le menu permet de lancer la partie, de modier les options, de voir les
crédits et de quitter le jeu. La plus grande partie des graphismes du menu a
été pompée sur Mario Kart et sur Bomberman.
4.6 Le menu dit in game Un second menu est présent mais celui-ci n'est pas présent au lancement
du jeu mais pendant la partie en pressant la touche Échap. Il permet de
relancer rapidement la partie, de basculer vers le mode deux joueurs, de
13
Fig.
4.4 Le menu des options
14
changer de map, de résolution et rappelle la conguration des touches en cas
d'oubli. Celui-ci n'est pas très joli, mais laisse la possibilité de voir la partie
en cours. Ouvrir le menu pendant la partie permet aussi de mettre celle-ci
en pause.
4.7 Le multijoueur en réseau
Le jeu permet de jouer à deux joueurs (seulement) en réseau LAN ou
internet. Pour se faire il faut lancer le lanceur EpiKartLauncher qui permet
de démarrer le jeu en mode serveur et en mode client. Le jeu ne comprenant
aucun chat, il est conseillé d'avoir un moyen de conversation avec l'adversaire
à part. Le serveur doit lancer en premier le jeu et lancer la partie une fois dans
le menu. Quand le message " En attente de connexion " s'ache, le client doit
entrer l'adresse IP du serveur ainsi que le port choisi par le serveur. Lorsque
le client aura rejoint le serveur la partie commencera. En mode réseau, il
n'y a pas d'IA, il s'agit d'un un-contre-un. Si le menu est ouvert une fois la
partie lancée, le jeu sera en pause mais pas celui de l'adversaire. Par contre
" recommencer la map " la refait commencer pour les deux joueurs. En cas
d'échec de connexion du client, le jeu plante. Si l'autre joueur se déconnecte,
il n'y a aucun message aché, si ce n'est dans la console.
4.8 L'éditeur de circuit
L'éditeur de circuit est l'outil utilisé par l'équipe pour créer les map et
est mis à disposition des joueurs. Celui-ci permet de former le terrain du
circuit et de le lisser pour le rendre plus agréable à ÷il puis de placer le point
de départ et les diérents checkpoints dans l'ordre. La touche nale étant le
positionnement des bonus. L'éditeur est capable d'enregistrer les circuits au
format .m4p mais aussi de les ouvrir pour modier ceux déjà fait.
4.9 Le site web
En complément du jeu, un site web a été créé pour informer sur l'évolution
du projet et pour pouvoir proposer le téléchargement du projet. Celui-ci est
disponible à l'adresse http ://nak3d.free.fr
15
Fig.
4.5 L'éditeur de circuit
16
Chapitre 5
La réalisation du projet de A à Z
5.1 Introduction
Dans cette partie, nous allons détailler la manière dans le projet à évolué
depuis ses débuts jusqu'à aujourd'hui où il est ni et tout à fait jouable.
Cette partie est organisée de manière plus ou moins chronologique de manière
globale pour le projet. Ainsi la succession des sous-parties suivantes sera un
résumé de notre travail sur le projet tout au long de l'année pas forcément
dans l'ordre dans lequel nous avons travaillé dessus.
5.2 Le concept du jeu : Tous ensembles
La toute première étape lors de la conception du jeu a été de choisir le type
de jeu que nous voulions réaliser. Après un brainstorming nous nous sommes
mis d'accord sur un jeu de course d'avion en version fun (en s'inspirant
de Mario Kart). Nous devions alors rédiger le cahier des charges et ainsi
dénir plus précisément ce que nous recherchions comme objectif nal. En
s'inspirant des projets des années précédentes et de ce que nous nous sentions
capables de faire nous nous sommes déni une liste d'objectifs à atteindre
pour chaque soutenance et pour la soutenance nale. Après avoir appris les
bases du LaTeX, nous avons rédigé le cahier des charges et nous l'avons rendu
bien qu'il nous aura fallu travailler très vite les derniers jours pour être dans
les temps. À notre demi-surprise, il a été validé du premier coup, ce à quoi
nous ne nous attendions pas avec certitude. En eet, le cahier des charges
a été rédigé un peu dans l'urgence et presque sans l'aide de Charles qui
marquait déjà son détachement du groupe. Mais le contenu était bon alors,
c'est parti pour le projet.
17
5.3 Les débuts en Delphi : Maxime
Lors de la rédaction du cahier des charges nous nous sommes mis d'accord pour réaliser le jeu avec OpenGL pour les raisons suivantes : D'abord
parce que ça avait l'air plus simple comme nous avons pu le constater sur
internet pour nos premières recherches et de plus cet avis avait été plus
ou moins conrmé par les spés. De plus Maxime connaissait déjà un peu
OpenGL grâce à quelques expérimentations en C avant EPITA, et comme
il allait être sans doute le codeur principal du projet les autres membres
l'ont laissé choisir sans diculté. Les autres éléments nous ayant poussé à
OpenGL sont : OpenGL est libre et multiplateforme (Le jeu en version nale
fonctionne parfaitement sur Ubuntu grâce à Wine), et OpenGL n'oblige pas
à installer une usine à gaz telles que les dernières versions de Delphi avec .Net
et tout un tas d'autres éléments qui nous dépassent de loin. Nous devions
donc nous mettre à OpenGL en Delphi. La première diculté n'a pas été en
réalité d'utiliser OpenGL en Delphi mais plutôt d'utiliser Delphi tout court.
En eet, au moment du début du projet, nous n'avions vu Delphi que depuis peu de temps et nous n'en avions pas toutes les subtilités voire même le
plus basique (diérence entre .dpr et .pas, méconnaissance des types, etc.).
Nous avons alors débuté en Delphi grâce à cette adresse : http ://delphipage.free.fr/opengl.html. Maxime qui avait déjà utilisé OpenGL s'est donc
lancé dans la réalisation d'un départ de projet sur le modèle donné par ce
site, c'est-à-dire la création de la surface OpenGL par les outils de Delphi et
la gestion des événements par Delphi également. À partir de cette base il a été
assez facile de créer une scène, pour le moment immobile, achant un cube
posé sur un plan. Grâce au gestionnaire d'événement de Delphi, Maxime a
rajouté des touches an de pouvoir tourner le cube. Notre premier cube qui
tourne ! Youhou !
5.4 Passage à GLFW : Michaël
Nous nous sommes assez vite rendu compte qu'utiliser uniquement Delphi
pour gérer un jeu en OpenGL serait vite insusant. En eet, OpenGL se
contente de recevoir des instructions de dessin et de les exécuter, mais un
contexte de dessin doit déjà être déni et le reste de la gestion du programme
n'a rien à voir avec OpenGL. Delphi a été créé pour réaliser des applications
Windows, ainsi les outils mis à disposition par Delphi sont adaptés à cet
usage mais pas à celui des jeux vidéo, sur plusieurs points : Tout d'abord
la création d'un contexte de rendu OpenGL en Delphi s'approche plus d'un
bidouillage que d'autre chose mais ce n'est pas le plus grave ; la gestion des
18
événements clavier et souris est prévu pour Windows et se déclenche par
événement dans le code, ce que nous maîtrisons mal et pour terminer, le
timer de Delphi est très peu précis et complètement inadapté (Nous avons
par la suite appris qu'un meilleur timer était disponible dans l'API Windows).
Nous avons donc voulu nous tourner vers une bibliothèque vraiment orientée
vers OpenGL qui ferait tout ce dont nous avons besoin du coté contexte,
événement et timer. Ainsi Maxime a trouvé glfw dont les headers étaient
disponibles en Delphi. An d'utiliser glfw à partir de maintenant, le code a
du être réécrit complètement. C'est ce qu'à fait Michaël avec Brio.
5.5 La gestion de la map : Maxime
À partir de maintenant, la description de ce que nous avons réalisé pour
le projet n'est plus chronologique mais plutôt par thème ce qui permet de ne
pas se perdre dans les diérents éléments mis en place petit à petit dans le
jeu chacun de leur coté. Ainsi le premier élément capital pour le jeu est le
terrain. Le rendu de celui-ci devait être assez lisse et assez agréable à l'÷il.
Tout ce qui suit dans cette partie a été réalisé par Maxime. Une map a été
déni ainsi : Un réseau de points espacés régulièrement ayant chacun une
hauteur propre. Donc pour dénir la forme du terrain il faut dénir la hauteur de chaque point constituant le terrain. La première version du format de
map était en texte mais la limitation de ce format nous a assez vite poussés
à changer de format pour un format binaire généré par un éditeur de map
(dont nous parlerons plus tard). Le rendu du terrain dans le jeu a été une
des choses les plus complexes à mettre en place.
Ce que Maxime a réalisé est donc un achage de terrain plus ou moins
réaliste, texturé (avec malheureusement une unique texture), avec un eet
d'éclairage qui donne la touche réaliste en plus. La map est constitué d'un
réseau de points de taille maximum d'environ 200 * 200 avec chacun une hauteur donné. L'eet d'éclairage est réalisé grâce au calcul des vecteurs normaux
de chaque triangle de la map et par l'envoi de ces données à OpenGL.
La lecture des données dans un chier .m4p et le calcul des normales ont posé
quelques dicultés mais elles ne furent pas insurmontables, il a sut d'une
bonne étude sur papier au niveau algorithmique et mathématique ainsi que
de l'aide de Wikipédia pour venir à bout de ces calculs.
Un gros nombre de polygones étant présents dans cet achage il a fallu immédiatement penser à une optimisation pour le réaliser. Le moyen le plus
simple d'optimisation en OpenGL est la génération de vertex arrays.
Toute cette procédure se répète à chaque chargement d'une map mais ne
prends pas beaucoup de temps (au plus une demi-seconde), pré-calculer la
19
Fig.
5.1 Un exemple du moteur physique
lumière ne servait alors à rien.
5.6 Le moteur physique : Maxime
Le moteur physique est ce qui a, avec le moteur graphique pris le plus
de réexion et de recherche sur internet. Notre idée première se faire une
course d'avion s'est plus ou moins envolée à cause de la diculté du moteur
physique, il est en eet beaucoup plus simple de gérer un moteur physique
sur terre qu'en l'air.
La solution retenue par Maxime pour exécuter les instructions du moteur
physique est un moteur physique qui s'exécute régulièrement (toutes les 0.005
secondes soit à 200 Hz) et donc qui ne dépend pas du temps passé entre deux
20
frames.
Dans le jeu ni, le moteur physique du jeu permet à un véhicule de se déplacer librement sur le circuit, pouvant monter sur les montagnes (en prenant
l'inclinaison de la pente et en subissant les eets de la pente : le véhicule
descend). La partie la plus dicile à gérer a été les frottements. En eet lors
des deux premières soutenances, le véhicule avait des frottements mal gérés
qui font que le véhicule frotte (et ralentit) autant en avançant de face que de
coté. En réalité, les frottements doivent être beaucoup plus élevées en glissant
latéralement qu'en avançant (les roues tournant dans le sens de la marche).
Grâce à de multiples changements de repère (merci les matrices) le problème
a pu être résolu encore une fois par Maxime.
L'absence de collision entre les véhicules est bien dommage mais nous pouvons mettre cela sur le compte d'un choix de l'équipe de ne pas avoir à s'en
occuper, au moins il n'y aura pas de problème du à des bugs de collision. Et
puis pas d'excuse pour ne pas arriver à battre le record au tour. Ce choix est
en eet le même que dans Trackmania Nations qui a été une de nos références
pour le jeu.
5.7 Le menu : Pierre-Antoine
Le menu a intégralement été créé par Pierre-Antoine avec l'aide ponctuelle de Maxime. Il permet de lancer le jeu avec la map choisie, de changer
les options et de lire les crédits. Il a été créé grâce à une armée de textures
représentant chacune chaque état diérent du menu. Ce système mis en place
par Pierre-Antoine pour les soutenances avait la qualité de fonctionner mais
avait comme défaut d'être très lent à charger (car de nombreuses images très
grandes étaient chargées au démarrage du menu). Pour la quatrième soutenance, le menu a été complètement réécrit pour l'optimiser mais le problème
de chargement, bien que moins important est toujours présent, le temps de
chargement allant de 5 à 20 secondes selon les PC alors que le jeu lui-même
est beaucoup moins long à charger (2 à 4 secondes en général). De plus les
diérentes textures ont du être refaites à cause du changement de nom du
jeu.
5.8 Le son : Michaël
La partie sonore n'a été implémentée qu'en partie à la soutenance 3 et
nalisée pour la dernière soutenance. La partie code utilise FmodEx comme
bibliothèque. Fmod est une bibliothèque très complète mais très simple, ce
21
qui nous a poussés à la choisir. Michaël a créé un objet dans le code qui
permet de simplier encore l'utilisation du son. Il sut alors d'une méthode
pour lire un son et une autre pour jouer une musique. En fait cette méthode
prend en paramètre le nom du son à jouer, s'il est déjà chargé il joue ce
son, sinon il le charge et ensuite le joue. La seconde partie de la gestion
sonore a été de créer les sons. Comme prévu dans le cahier des charges, une
partie de ceux-ci a été créé à la bouche puis modiée avec Audacity. Le reste
des sons a été capturé dans des vidéos depuis Youtube. La partie sonore est
certainement celle qui aura retenu le moins de soin de notre part. Cependant
elle est existante ce qui est déjà ça.
5.9 L'éditeur de circuit : Maxime
Parallèlement à l'élaboration dans le projet de ce qui pouvait lire un chier map, il a aussi fallu créer un programme capable de les créer. C'est
ce qui a été fait par Maxime. Il a créé un programme séparé du projet en
TForm qui permet assez facilement de créer des circuits. La base de cet éditeur se trouve être un TDrawGrid qui permet d'avoir une grille représentant
le circuit vu de dessus. Divers outils activés par des boutons permettent d'intégrer diérents éléments dans la map. Ceux-ci peuvent être réglés par des
curseurs permettent d'ajuster divers paramètres tels que la hauteur du terrain où l'orientation des checkpoints. Le format de la map lu et exporté par
l'éditeur est le suivant :
Deux entiers indiquant la largeur et la longueur de la map puis
longueur x largeur entiers représentant la hauteur de chaque point du circuit
puis
un entier nombre_objet indiquant le nombre d'objets présent dans la map
un succession de nombre_objet d'enregistrement contenant le type d'objet,
sa position x, y, et z ainsi que son orientation, tous des integer. Ce format de
map ayant évolué au l du temps (par exemple pour rajouter l'orientation des
checkpoints), certaines map créées au début du projet ne fonctionnent plus
dans le jeu nal et le font même planter. En eet, si la map n'est pas précisément au format indiqué, le jeu plante. Heureusement, l'éditeur ne génère pas
de chier faussé, donc ce cas de gure ne devrait pas arriver. Cependant il y a
un problème avec l'éditeur dont la source est inconnue, c'est que le rendu de
la map créée dans l'éditeur dans le jeu n'est pas la même mais son symétrique
par rapport à un axe x. Ce qui fait que les courbes à droites deviennent des
courbes à gauches dans le jeu. Le problème n'étant pas primordial (puisqu'il
ne change pas fondamentalement quelque chose), nous n'avons pas essayé de
le régler, sans doute aussi par manque de temps.
22
5.10 La gestion interne du jeu : Checkpoints et
multiples véhicules : Maxime
Alors que nous avions une bonne base d'achage et de déplacement grâce
aux moteurs graphique et physique, il a fallu commencer à coder ce qui
changerait ce grand paysage vide en jeu de course. Grâce à l'éditeur, il nous
est possible de rajouter des checkpoints (ou point de contrôle en français)
qui détermine le parcours à eectuer.
Lorsque nous eectuions des tests pour le moteur physique et graphique, nous
avons (ou plutôt Maxime a) conçu le jeu pour un unique véhicule. Sachant que
le jeu avait pour nalité de devenir multijoueur, il a fallu rapidement rajouter
la possibilité d'avoir plusieurs véhicules. La première étape vers cet objectif
a été de concevoir une classe Tjoueur qui contient tout ce qui appartient à
chaque véhicule puis une classe TlisteJoueur qui est comme son nom l'indique
une classe contenant une liste de joueur et qui permet d'en rajouter et d'en
supprimer facilement.
Pour la mise en place des checkpoints, une fois disponibles dans l'éditeur,
il a été facile de les lire dans le projet et de les enregistrer quelque part en
mémoire. La gestion des checkpoints à franchir, le nombre de tour à eectuer,
est gérée par la classe Tjoueur grâce à la liste ordonnée des checkpoints.
5.11 Le mode deux joueurs : Maxime
À vrai dire, cette partie a été assez facile. La seule vraie diculté a
été de trouver la fonction OpenGL qui permettait d'avoir un écran splitté
(glViewport) et encore. En eet, le système permettant plusieurs véhicules
étant déjà implémenté, il sut d'eectuer deux fois l'achage, une fois avec
la caméra suivant le joueur 1, une fois avec l'achage suivant le joueur 2. Il a
aussi fallu modier la gestion des entrées clavier pour permettre des touches
diérentes pour les deux joueurs mais cela n'a pas posé de problème et a été
fait rapidement. En deux heures (et encore c'est large), tout a été fait.
5.12 Les adversaires (IA) : Maxime
De la même manière que le mode deux joueurs, l'élaboration des adversaires s'appuie fortement sur la mise en place antérieure du système permettant la multiplicité des véhicules. Les joueurs dirigés par l'IA sont aussi des
Tjoueur mais sont identiés en tant que IA à leur création. En tant que tel
ils ne se déplacent pas en fonction des entrées clavier mais en fonction des
23
checkpoints à atteindre. La manière la plus simple de créer l'IA fut de diriger
automatiquement les adversaires vers le checkpoint suivant à atteindre. La
fonction qui dirige les véhicules n'est pas très évolué mais donne des résultats très corrects : Les véhicules s'orientent vers le checkpoint à atteindre et
accélèrent jusqu'à ce qu'ils l'atteignent et ainsi de suite pour chaque checkpoint. D'autres conditions un peu plus précises permettent de régler certains
problèmes engendrés par une telle IA, par exemple, si la distance entre le
checkpoint et le véhicule est faible et que le véhicule n'est pas correctement
dirigé (par exemple à cause d'une faible distance entre deux checkpoints), le
véhicule ralentit jusqu'à être sûr d'atteindre le checkpoint. Après la mise en
place de ce système, le problème a été que tous les adversaires eectuaient
exactement le même parcours (comme dans Gran Tourismo). Pour remédier
à ce problème, Maxime a implémenté des capacités aléatoires (pour l'accéleration par exemple) pour chacun des véhicules contrôlé par l'IA ce qui a
permis de les séparer pendant la course.
5.13 Les bonus : Maxime
Alors dans l'optique d'un Mario-kart-like, il a fallu ajouter des bonus
comme il y en a dans Mario Kart. Une fois rajoutés dans l'éditeur et donc
enregistrés dans le cher map, Maxime a du stocker la liste de bonus dans
la classe Tmap. Une texture rapide avec un point d'interrogation a été créée
puis appliquée sur un cube nalement enregistré dans une display list. Un
bonus est représenté par ce cube en rotation. À chaque frame, la liste des
bonus est achée à sa place. Lorsqu'un joueur passe sur le bonus, il disparaît
pour cinq secondes et le joueur se voit ajouter un bonus en attente. Lorsque le
joueur active le bonus, des eets se ressentent sur le joueur, instantanément
ou pendant une durée limitée. Maxime a également prévu l'utilisation des
bonus pour les IA, en les activant automatiquement lorsqu'ils en ramassent.
Les diérents bonus n'ont pas posé de diculté à programmer car nous avons
choisi des bonus simples, pas de projectiles par exemple.
5.14 Le réseau : Pierre-Antoine puis Maxime
Le jeu en réseau a été prévu depuis le début dans le cahier des charges
mais n'a été commencé que pour la troisième soutenance (comme prévu en
fait). La première étape a été de choisir quelle librairie utiliser pour les communications réseau. Nos choix se limitaient à Indy, ICS et aux composants
intégrés à Delphi 6. Notre premier test en réseau fut celui d'un chat réalisé
24
par Pierre-Antoine avec Indy. L'élaboration de ce chat n'a pas été trop difcile, le réseau consistant seulement à envoyer des chaînes de caractères à
intervalles assez grande. Pour la troisième soutenance, le chat était fonctionnel et a été présenté malgré de nombreux bugs qui auraient pu être résolus
mais qui n'étaient pas du tout notre priorité.
Pour la dernière soutenance, il a fallu mettre en place un réseau au niveau
du projet. Maxime, après avoir étudié les diérentes bibliothèques a préféré
utiliser ICS qui lui plaisait plus dans le style de programmation, orienté événement.
Après avoir compris le système de connexion entre deux PC en TCP avec
ICS, il a fallu commencer à envoyer des données. Ici, le transfert de données
ne se fait pas par chaîne de caractères mais par paquet d'octet. Les diérents
types de paquets transportés par le jeu sont :
Le paquet contenant le nom de la map.
Le paquet contenant les propriétés du joueur.
Le paquet contenant la vitesse et la position du joueur.
Le paquet contenant des messages comme redémarrer la course.
Le premier paquet est envoyé par le serveur au début de la partie. Le second
est envoyé par les deux joueurs au début également. Le troisième paquet est
le plus important car il permet de voir l'autre joueur. L'adversaire est vu
localement comme un Tjoueur inerte dont les coordonnées position et vitesse
sont mises à jour par le réseau.
Le paquet position est envoyé à chaque frame à l'autre joueur par le réseau.
Si celui-ci ne reçoit pas le paquet immédiatement (si par exemple le jeu est
gé car on déplace la fenêtre, glfw inside), il est mis en attente par ICS.
Lorsqu'on veut récupérer les paquets, il se peut que le buer de réception
soit trop petit, et qu'on ait des morceaux de paquet dans tous les sens. Au
départ, la plupart des problèmes de transport de paquets n'étaient pas gérés
et au moindre problème, les deux jeux plantaient. Des mécanismes de sécurité
de buer trop plein ou de paquet à moitié manquant ont du être mis en place
pour contrer ces bugs. Finalement, des octets de contrôles ont été ajoutés à la
n de chaque paquet par symboliser la n du paquet (ils contiennent la valeur
arbitraire $2A) an de vérier la longueur de chaque paquet. Finalement il
n'y a pas de bugs majeurs dans le réseau, si ce n'est le manque d'information
et la gestion d'une connexion à un serveur inexistant. Le jeu a été testé en
local (deux jeux lancés sur le même PC), en LAN et même sur internet. Si la
connexion est correcte, le jeu est tout à fait jouable. Si le lag est trop grand, il
se peut par contre qu'il y ait des problèmes car les passages au checkpoints ne
sont pas communiqués mais uniquement calculés en fonctions de la position
donnée.
25
Chapitre 6
Conclusion
La réalisation du projet tout au long de l'année nous aura enseigné une
grande quantité de chose. D'un coté au niveau programmation où nous avons
eu notre première application pratique de la programmation, notre futur métier si tout ce passe bien. Mais aussi du coté gestion, qui n'a pas toujours été
facile au sein de l'équipe. Les niveaux et les motivations sont très hétérogènes
au niveau de l'équipe, Maxime surpassant tout le monde de l'aveu du reste
de l'équipe. Le départ de Charles ne nous a laissé qu'à trois ce qui a aussi
réduit notre capacité de travail. Mais le résultat est là et est jouable. Certes
il pourrait y avoir de très nombreuses améliorations mais nous avons fait ce
que nous avons pu face au autres priorités de l'année.
Quoi qu'il en soit, nous sommes ers de ce qu'il ressort de notre travail et
nous espérons que chacun l'appréciera à sa juste mesure.
26