Salade, Tomate, Caddy! · 2020-03-25 · Salade,Tomate,Caddy Mai2019 TheObviousCorp. Finalement, nous avons opté pour le choix qui paraissait le plus évident et le plussobre. Figure

Salade, Tomate, Caddy !Rapport de soutenance 3

Axel BarréAlexis VanhalleThomas BarrauMaxime Caylar

1

Table des matières

1 Remerciements 5

2 Introduction 62.1 La naissance du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 The Obvious Corporation . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Membres du groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Répartition générale des taches . . . . . . . . . . . . . . . . . . . . . 8

3 Retour sur le cahier des charges 93.1 Inspirations et place du jeu . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Principes de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4 Déroulement d’une partie . . . . . . . . . . . . . . . . . . . . . . . . . 103.5 Véhicules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.6 Objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.7 Cartes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.8 Style graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.9 Communication du jeu . . . . . . . . . . . . . . . . . . . . . . . . . . 133.10 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.11 Tableau de planification des tâches . . . . . . . . . . . . . . . . . . . 15

4 Rappel Premier Cycle 164.1 Graphisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.3 Mécaniques de jeu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3.1 Physique du jeu . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3.2 Intelligence artificielle . . . . . . . . . . . . . . . . . . . . . . . 184.3.3 Caméra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4 Réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.5 Avances et retards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.6 Conclusion premier Cycle . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Rappel Deuxième Cycle 215.1 Graphisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 Site Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.3 Musique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.4 Menus et Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2

5.5 Mécaniques de jeu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.5.1 Physique du jeu . . . . . . . . . . . . . . . . . . . . . . . . . . 235.5.2 Intelligence artificielle . . . . . . . . . . . . . . . . . . . . . . . 245.5.3 Caméra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.6 Réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.7 Gestion des cartes de jeu . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.7.1 L’échec de l’enregistrement via le Json . . . . . . . . . . . . . 255.7.2 Enregistrement de carte . . . . . . . . . . . . . . . . . . . . . 265.7.3 Chargement de carte . . . . . . . . . . . . . . . . . . . . . . . 265.7.4 Éditeur de niveau . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.8 Avances et retards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.9 Conclusion deuxième Cycle . . . . . . . . . . . . . . . . . . . . . . . . 27

6 Dernier Cycle 286.1 Menus pour le logiciel d’installation et le jeu . . . . . . . . . . . . . . 286.2 Mécaniques de jeu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.2.1 Physique du jeu . . . . . . . . . . . . . . . . . . . . . . . . . . 306.2.2 Intelligence artificielle . . . . . . . . . . . . . . . . . . . . . . . 316.2.3 Caméra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.3 Graphismes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.3.1 Modèle 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.4 Multijoueur / réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.4.1 Génération des objets légers . . . . . . . . . . . . . . . . . . . 346.4.2 Salle d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.4.3 Tableau des scores . . . . . . . . . . . . . . . . . . . . . . . . 376.4.4 Particules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.4.5 Mode hors-ligne . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.5 Musiques et sons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.6 Éditeur de niveau et gestion de cartes . . . . . . . . . . . . . . . . . . 40

6.6.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.6.2 Panneau latéral gauche . . . . . . . . . . . . . . . . . . . . . . 416.6.3 Inspecteur d’objet . . . . . . . . . . . . . . . . . . . . . . . . . 426.6.4 Gestion des objets parents . . . . . . . . . . . . . . . . . . . . 426.6.5 Gestion de carte . . . . . . . . . . . . . . . . . . . . . . . . . . 436.6.6 Corrections de problèmes et optimisations . . . . . . . . . . . 43

3

Salade, Tomate, Caddy Mai 2019 The Obvious Corp.

7 Bilan du projet 457.1 Bilan général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2 Ressentis personnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2.1 Alexis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2.2 Axel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2.3 Maxime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.2.4 Thomas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8 Conclusion 48

4


1 Remerciements

Nous somme The Obvious Corp et voici une liste non-exhaustive de ceux qui nousont permis d’en arriver là :

— Nos mères, reines de ce monde, qui nous ont fait naître et élever.— Nos pères, souverains spirituels, qui eux aussi nous ont donné la vie et nous

ont fait nous élever— La France, patrie souveraine, dont la liberté inaltérable nous a permis de

créer ce jeu, dont la fraternité immuable lie ce groupe à travers Epita et dontl’égalité impartiale est appliquée à tous les projets de ce cursus.

— Suprême leader des algorithmes, prophète des antiques axiomes, prêcheur dela récursion, évêques de la complexité, défenseur de l’optimisation, protecteurdu jardin sacré des arbres binaires, alpha et oméga de la prépa, BoullayChristophe.

— Gardienne des arcanes de la conjugaison, ultime rempart du bon goût, der-nière prêtresse de la grammaire, incarnation du concept de l’objectivité, jugeintemporelle orthographique, mère de la culture et des arts, Le Collen Klervi.

5


2 Introduction

2.1 La naissance du projet

Laissez-moi vous poser une question : N’avez-vous jamais rêvé, enfant, de faireune course de caddy avec des amis dans un supermarché ? Eh bien, c’est ce que veutréaliser notre projet. Durant l’un des nombreux repas du midi de S1, Axel et Thomasn’ont eu de cesse d’inventer et d’innover pour trouver le projet parfait, et soudaince fut l’illumination, sur la mention d’un caddy et d’une course le projet était né.Notre projet, aussi humble soit-il, est un jeu vidéo en 3D, multijoueur, mettant enscène des courses de caddy de folie, dans un univers enfantin.

2.2 The Obvious Corporation

L’idée du projet et les personnes ont été présentées. Il ne manque plus qu’unechose, le nom du groupe !

The Obvious Corporation est un groupe né en décembre 2018 ayant pour butd’apporter un vent de fraîcheur dans le monde vidéoludique. Nous partons d’unconstat : À part Mario Kart et quelques jeux en 2D, les jeux vidéos de course sonttrop nombreux à se prendre au sérieux. L’idée de notre jeu est donc d’avoir ungameplay où les joueurs sont sous pression car ils doivent gagner la course, maisaussi d’avoir des blagues et un thème général mis sous les traits de l’humour. Ainsi,notre jeu saura générer une tension entre les joueurs tout en les divertissant entrechaque affrontement.Concernant le design du nom de groupe, Axel a tenté de nombreuses ébauches.

Figure 1 – Ébauches pour le design de The Obvious Corporation

6


Finalement, nous avons opté pour le choix qui paraissait le plus évident et leplus sobre.

Figure 2 – Résultat final du design

2.3 Membres du groupe

Je suis Thomas Barrau, mon objectif est de créer un jeu amusant, beau de parle visuel et par son gameplay, j’ai vraiment envie de travailler sur la partie visuelleet graphique du jeu. En matière d’expérience j’ai déjà codé un jeu de plateforme enterminale ISN.

Je suis Alexis Vanhalle, originaire de Nouvelle-Calédonie, mon expérience serésume à de l’autodidacte en Python et à la réalisation de quelques jeux rétro 2D.Je pense que la création d’un jeu en 3D serait une suite logique à mon expérience etj’aimerais m’occuper en priorité de la partie réseau du projet ainsi que la réalisationdes différents scripts.

Je suis Axel Barré, j’ai déjà fait un jeu vidéo Pac-Man en ISN mais je n’aiaucune expérience sur Unity. En compétence complémentaire, j’ai déjà créé des sitesweb et j’ai également fait du montage vidéo pour le trailer de mon jeu Pac-Man. Jesuis très intéressé par la création d’un vrai jeu en 3D qui serait à la fois intéressantet amusant pour les joueurs. Mon objectif est aussi que le jeu puisse se démarquerpar son aspect graphique travaillé.

Je suisMaxime Caylar, je possède quelques bases en C# acquises en autodidactepour le projet de SI en terminale, mon objectif est de concevoir un jeu en mefocalisant sur la réalisation de ses algorithmes et mécaniques.

7


2.4 Répartition générale des taches

Thomas Axel Alexis MaximeSite webHTML/CSS/JS XGraphismeMap design XObjets 3D XCaddy XMenus (visuel) XParticules XSonMusiques et Bruitages X XMenuAccueil XEn jeu XRéseauMultijoueur XIAVigile XMécanique de jeuPhysique du caddy X X XBoosts XPoints d’apparition et de passage XCaméra XGestion des cartes de jeuL’enregistrement/chargement de carte XÉditeur de niveau X

Table 1 – Répartition des tâches

8


3 Retour sur le cahier des charges

3.1 Inspirations et place du jeu

Quel est le premier jeu de ce type ?En 1973, le premier jeu vidéo de course a vu le jour dans une salle d’arcade. Astro

Race était un jeu de course futuriste jouable à deux simultanément, dans lequel lejoueur dirigeait un vaisseau en vue du dessus, tout en devant éviter les astéroïdesprésents sur le parcours. En effet, à cette époque, il était plus intéressant et plusdrôle de jouer avec un vrai joueur, que de jouer contre l’intelligence artificielle, quinécessitait davantage de puissance de calcul.

Mario Kart est le jeu le plus connu grâce à sa sortie sur chaque console de la firmeNintendo. Le principe est que le joueur doit parcourir le plus rapidement possibledes circuits dans l’optique de franchir la ligne d’arrivée en premier. Généralement,les adversaires sont contrôlés soit par l’ordinateur ou soit par d’autres joueurs. Pourgagner, il a la possibilité d’utiliser de nombreux objets. Ils peuvent être offensifs,défensifs ou donner une accélération au joueur. Le jeu est intéressant car il a desmécaniques de jeu dont on peut s’inspirer tels que les bonus ou la conception desniveaux.

Les Lapins Crétins : La Grosse Aventure n’est pas un jeu de course. Mais unjeu où deux lapins partent dans le monde des humains avec un caddy, pour chercherdes objets pour atteindre leur objectif : la Lune. Ils passeront par les canalisationsdes égouts pour entrer en ville et découvrir une société ultra-capitaliste, véritablecaricature de notre société de consommation. Ce jeu complète parfaitement MarioKart car on y retrouve les thématiques liées aux supermarchés et à la surconsom-mation. De plus, le caddy a une physique, notamment avec ses objets, dont on peuts’inspirer. Les décors sont également sources d’inspiration.

Figure 3 – Les Lapins Crétins : La Grosse Aventure

9


3.2 Principes de base

STC est un jeu de course, qui se joue en versus à deux joueurs, mêlant rapidité etadresse dans une ambiance de supermarché où tous les coups sont permis. Bonus etmalus seront vos seuls allier afin d’arracher la victoire à vos ennemies. Voici quelquesprincipes de base :

— Les personnages peuvent entrer en collision avec les autres ainsi qu’avec tousles objets lourds et médians qui provoquent un rebond et une perte de vitesse

— Tous les objets sont soumis à la gravité— Certains objets sont des consommables permettant de donner un effet spécial

aux joueurs— Des zones spéciales sur la carte (flaque d’eau , raccourcis) affectent les dépla-

cements des joueurs.

3.3 Réseau

Nous avons choisi d’utiliser l’asset (outil) "Photon Unity Network" (PUN) pourgérer la partie multijoueur du jeu qui permet, avec la version gratuite, d’avoir jusqu’à20 joueurs en même temps.

3.4 Déroulement d’une partie

Voici le déroulement de partie imaginé dans le cahier des charges :— Cinématique montrant le niveau— Décompte— Les joueurs débutent avec un boost— Les joueurs parcourent le "circuit" tout en récupérant des bonus— Dès que le premier joueur est arrivé, un décompte se lance indiquant aux

autres joueurs le temps restant pour finir la course.

3.5 Véhicules

Toute course nécessite un moyen de locomotion, le nôtre est le caddy. Étant cegrâce à quoi les personnages se meuvent, il est crucial d’y attribuer une physiqueadéquate. Notre but est de reproduire, aussi fidèlement que possible, les mouvementsd’un caddy : un caddy est un objet de la forme d’un prisme droit à base trapézoïdalequi est placé sur quatre roues. Nous supposons donc que le caddy ne peut qu’êtrepoussé vers l’avant et qu’il peut garder son inertie tout en tournant jusqu’à la pro-chaine impulsion à l’arrière du caddy. Cependant, la physique des caddys dans la

10


réalité ne favorise pas les virages, on suppose donc que quelques ajustements serontapportés à cette physique afin que le déplacement ne soit pas une contrainte maissoit intuitif.

Figure 4 – Croquis de caddy

3.6 Objets

Des personnages et des véhicules, c’est bien, mais c’est quand même plus sympaavec tout plein d’objets interagissant avec de la physique. Nous appellerons “objets”tout ce qui constitue la carte et qui peut être bougé d’un niveau à l’autre, autrementdit, ce seront les briques qui permettront de faire les niveaux.

Les objets massifs seront des éléments qui seront difficiles, voire impossibles,à déplacer. Ils permettront de structurer le niveau. Les objets massifs sont parexemple :

— Des murs— Des rayons normaux, réfrigérants, de légumes. . .— Diverses zones d’entreposage

Les objets médians seront des objets de taille moyenne qui seront complètementdéplaçables et qui permettront d’habiller un peu plus le décor. Ça pourrait être :

— Des paniers— Des caddies— Des portillons— Des stands, tables. . .— Des pancartes

11


Les objets légers seront les plus marrants pour les joueurs car ils seront nombreuxet auront de la physique dès qu’il y aura un contact avec le joueur. Par exemple siun joueur entre en collision avec un rayon, les objets tomberont de ce rayon pourrebondir un peu partout. Voici quelques exemples d’objets légers :

— Boites de conserve— Pack de bouteilles— Canettes— Boîtes rectangulaires— Boîtes cylindriques— Légumes— Poulet rôti, etc.

3.7 Cartes

Nous avons vu les personnages, les véhicules et les objets. Voyons maintenantl’environnement où ils évolueront. Notre premier choix à propos de la carte de courseest celui d’une carte créée manuellement, en effet, les avantages de cette méthodesont que, d’une, elle sera ajustable afin de mettre en valeur les fonctionnalités de lacourse et de deux, qu’il y ait un minimum de cohérence concernant la répartitiondes éléments et objets la constituant. Les éléments composant une carte seront :

— La zone où le niveau sera placé (le sol du magasin)— Les zones de caisses enregistreuses.— Les murs du magasin— Les étagères du magasin

Figure 5 – Croquis de mobilier de supermarché

12


3.8 Style graphique

Comme nous l’avons dit dans la partie 3.1, nous avons comme inspiration : MarioKart et Les Lapins Crétins : La grosse aventure. Ces deux jeux nous apportentdes mécaniques de jeu mais aussi des inspirations graphiques. Est-ce qu’on peut secontenter de 2 références pour faire ce jeu ? Oui mais est-ce que c’est malin ? Pasvraiment. . .C’est pourquoi nous nous sommes inspirés d’un autre jeu vidéo qui sedémarque par son style graphique.

Anarcute est un jeu d’émeute (français), avec un style visuel cartoonesque detype "Beat’em all-foule" unique. Les spécifications graphiques sont :

— Des modèles 3D simplifiés au maximum (low-poly), les formes cylin-driques ou arrondies laissent place à quelque chose de plus abrupt avec lemoins de polygone.

— Des couleurs et des textures unies. Encore une fois, il s’agit de simplifierl’apparence à l’essentiel.

— Des animations et des mouvements très accentués, à la même manièreque dans un dessin-animé.

3.9 Communication du jeu

Nous avons détaillé toutes les caractéristiques de notre jeu mais tout cela ne sertà rien s’il n’y a pas de joueur pour y jouer. C’est là que la communication entre enjeu. L’idée est d’accrocher la curiosité du futur joueur. En effet, peu importe à quelpoint un jeu est bien, il peut facilement être noyé dans une masse d’autres diver-tissements. Commençons par la première chose qu’une personne verra : le nom dujeu. "Salade, Tomate, Caddy" est en français, ce qui inclut donc davantage les gensfrancophones que lorsque le nom est en anglais. De plus, il est inspiré de l’expressionconnue "Salade, Tomates, Oignons". Même si les gens ne connaissent pas le jeu, ilsconnaissent pratiquement tous l’expression.

Une fois que l’on a captivé l’attention du joueur, il faut lui donner envie de télé-charger et de jouer au jeu. Le moyen le plus agréable, le moins fatiguant et le plusattractif est de faire un excellent trailer qui, sur une montagne rythmé, fera vibrer lejoueur selon les différentes sensations/émotions que l’on peut ressentir dans le jeu.Pour ceux qui ne souhaitent pas voir la vidéo, ils pourront lire la description quirésumera, en quelques lignes, tout l’intérêt du jeu.

13


3.10 Outils utilisés

— Programmation :Dans un premier temps pour pouvoir développer notre jeu, nous aurons be-soin d’ordinateurs équipés de certains logiciels de développement que se soitau niveau algorithmique ou artistique ( Ide C#, Unity, Krita, Blender . . .)

— Graphisme :Afin de parfaire la conception de nos graphismes nous utiliserons aussi dumatériel de dessin (Tablette graphique, crayon, papier dessin . . .)

— Organisation :Pour assurer une bonne communication des tâches et requêtes entre les membresnous avons mis en place divers moyens de transmission de l’information (Dis-cord, Zenkit, Gantt, Gdrive, Mails Epita . . .)

— Divers :De plus, comme tout bon projet de groupe nous aurons besoin de matériauxque nous pourrions classifier de divers afin de schématiser, de partager nosidées au sein du groupe mais aussi de nous restaurer (matériel bureautique,tupperware, couverts. . .)

14


3.11 Tableau de planification des tâches

Tâche / Soutenance Soutenance 1 Soutenance 2 Soutenance 3

Graphisme 30 60 100

Son 20 70 100

Menu 60 80 100

Réseau 10 70 100

IA 20 60 100

Mécanique de jeu 40 70 100

Table 2 – Tableau de la planification des tâches selon les soutenances

15


4 Rappel Premier Cycle

4.1 Graphisme

Pour les graphismes, nous nous étions donné pour objectif de faire un maximumde modèles par nos propres moyens. Cependant, dans certains cas, il est nécessaire detélécharger des modèles 3D en ligne quand nous sommes en manque de compétencesou de temps. Mais ce ne fut pas le cas pour ce premier cycle. Le premier objet 3Dqui paraissait le plus évident à modéliser est bien évidemment le caddy, élémentcentral de notre jeu Salade, Tomate, Caddy. L’affaire n’était pas gagnée d’avancecar des complications apparaissaient lors de l’implémentation du caddy dans Unity.Notamment, les faces qui n’avaient soit pas de texture intérieure, soit pas de textureextérieure. Ce problème a été résolu en mettant deux cages confondues, l’une avecla texture intérieure et l’autre avec la texture extérieure.

Puis, il a fallu imaginer quel serait l’environnement dans lequel le joueur allaitévoluer. C’est ainsi que Thomas se mit à travailler sur les premières ébauches quiallaient entourer notre caddy. Il fallait tout d’abord effectuer un travail de recherche,car en effet si le supermarché est un endroit familier à tous, il parut vite évidentqu’il fallait se renseigner sur tous les types de présentoirs présents dans ces derniers.Le but ultime de la partie graphique était de représenter tous les éléments d’unsupermarché dans une représentation simplifiée, mais aussi de rendre le jeu vivantde par les couleurs, les formes, en somme la diversité des éléments.

Une fois tout ce travail achevé, l’aspect visuel des modèles était plutôt satisfaisant.

Figure 6 – Modèles premier cycle

16


4.2 Menus

Pour les menus, nous avions utilisé les éléments d’interface utilisateurs proposéspar Unity. La première version représentant plus l’allure générale qu’il devrait avoirau final qu’autre chose. Concernant l’aspect visuel des menus, nous voulions fairedes menus avec des couleurs unies et une police d’écriture de type "cartoon" pourcoller à l’univers du jeu qui se veut volontairement décalé.

Figure 7 – Menus d’accueil et de connexion multijoueur

4.3 Mécaniques de jeu

Le jeu possédait les mécaniques suivantes lors de la première soutenance :— Mouvement du caddy— Mouvement de la caméra— Collision entre le caddy est les différents objets provoquant leur chute— Un personnage non-joueur surveille la zone

17


4.3.1 Physique du jeu

Un simple composant "rigidobody" auquel nous appliquions des forces ainsi que lagravité constituait la physique du caddy, le "rigidbody" permettait aussi de gérer lescollisions. Cependant, nos systèmes avaient leurs limites car plusieurs incohérencessont apparus. Si le caddy était orienté dans la mauvaise direction il avait de légèrestendances à s’envoler ou à foncer dans le sol. De plus, lors d’une chute libre si lejoueur appuyait sur la touche assimiler à l’action "reculée" alors que le caddy étaitorienté vers le bas celui-ci avait tendance à remonter alors qu’il n’était en contactavec aucune surface, et lors de contacts avec un plan incliné avec un angle aigu, lecaddy se retrouvait propulsé sous le terrain ou dans les airs.

4.3.2 Intelligence artificielle

Dans l’optique de débuter les tests concernant les mécaniques de jeu, nous avionscommencé à implémenter une IA minimaliste, elle se contentait de vérifier sa distanceavec un joueur placé en paramètre de son script et de le prendre en chasse si celui-cirentrait dans son périmètre.

Ainsi, le travail effectué sur l’IA pour la première soutenance permettait au per-sonnage non-joueur de :

— Suivre le joueur placé en paramètre du regard quand celui-ci pénètre dansson périmètre d’action.

— Poursuivre le joueur jusqu’à ce que celui-ci sorte du-dis périmètre.— Stopper sa course quand elle perd le joueur.

4.3.3 Caméra

Nous avions créé une caméra orbitale à deux états, fixe en temps normal et librequand un bouton de la souris est enfoncé, avec aussi la possibilité de zoomer pourpasser en vue à la première personne (comme si nous étions dans le caddy).

4.4 Réseau

Pour que les joueurs puissent se voir dans la salle, il fallait tout d’abord instancierle joueur. Pour ce faire, la première étape consistait à ajouter le composant "PhotonView" 1 à l’objet correspondant au joueur (dans notre cas l’objet "Caddy").

1. permet d’indiquer à Photon que l’objet doit être vu par les autres joueurs

18


Puis, un prefab 2 du caddy devait être placé dans un répertoire spécifique de Pho-ton (répertoire où Photon regarde lorsqu’on lui demande d’instancier un objet) etenfin il ne suffisait plus que de désactiver l’objet "caddy" de la scène qui ne seraitplus utilisé car Photon n’utiliserais que le prefab désormais.

Le caddy étant bien instancié et fonctionnant correctement, il fallait maintenants’occuper de la caméra qui, devant suivre le caddy avec une vue à la troisièmepersonne, ne marchait plus du tout. En effet, placée en dehors de l’objet "Caddy"dans la scène, elle avait pour instruction de le suivre. Cependant, comme vu précé-demment le Caddy de la scène est désactivé donc la caméra ne bougeait plus. Unesolution plutôt évidente mais qui a mis du temps à germer, a été d’intégrer la caméraà l’objet "Caddy".

Pour la partie réseau, un utilisateur pouvait donc lors du premier cycle :— Se connecter au serveur photon— Rejoindre le Hall permettant d’accéder à plusieurs salles où se déroulent des

parties.— Entrer dans une salle pour rejoindre d’autres joueurs dans une partie

Figure 8 – Exemples de plusieurs instances du jeu

2. préfabriqué, objet servant de modèle pour les futures instanciations

19


4.5 Avances et retards

Tâche / État Prévu Actuel

Graphisme 30 30Son 20 20Menu 60 60Réseau 10 20IA 20 20Mécanique de jeu 40 20

Table 3 – Tableau des avances et retards premier cycle

4.6 Conclusion premier Cycle

Le début de projet nous a permis d’apprendre beaucoup de choses allant de lagestion globale de notre projet, aux compétences spécifiques développées par chacun.La cohésion au sein du groupe étant bonne, nous avons bien pu avancer notre jeu.Cette première partie nous a permis de poser les bases de notre jeu.

20


5 Rappel Deuxième Cycle

5.1 Graphisme

Durant le deuxième cycle, d’importantes modifications ont eu lieu au niveau desgraphismes. En effet, nous avons premièrement conçu le logo du jeu. Puis, avonsappliqué un correctif sur les textures et les ombres du caddy, le rendant plus esthé-tique.Par la suite commença le fastidieux travail de numérisation, ou plutôt de modéli-sation des différents éléments composant un supermarché, qui nous permettrait deremplir les rayons.

Figure 9 – Rayonnage deuxième cycle

5.2 Site Web

Pour cette soutenance, il fallait faire un site web du projet. Ayant des compétencesen création de pages web, Axel a décidé de se lancer dans la création du site. Toutesles pages web ont été créées à partir de rien, c’est-à-dire sans modèle ou framework 3.

Pour publier le site, nous avons dû nous poser la question du nom de domaine.Au début, nous nous sommes demandés si un nom de domaine finissant en .teamou .studio pourrait être bien. Mais il s’avère que quand les gens pensent au nom dusite, ils vont le mettre naturellement en .com. Donc, le plus logique a été de choisirle nom de domaine : https ://theobviouscorp.com

3. Outils facilitant le développement

21


A savoir, que le jeu est une sous-page du site à l’adresse suivante :theobviouscorp.com/stc.htmlPour héberger le site, nous avons utilisé GitHub Pages et après quelques manipula-tions pour lier OVH et GitHub le site web était enfin visible par tous.

Figure 10 – Page d’accueil de The Obvious Corp. et STC

5.3 Musique

Concernant, la musique nous avions décidé de prendre l’une des des musiquesprésentées dans le rapport précédent. La musique en question est "Ceremony" deBob Bradley. Nous avions fait ce choix car cette musique pouvait être téléchargéeet utilisée gratuitement dans le cadre des 10 premières pistes audio offertes sur lesiteaudionetwork.com.

Cependant ce système n’était pas compatible avec le multijoueur (plusieurs aver-tissements se produisaient) et n’a donc pas été retenu pour la suite.

5.4 Menus et Interfaces

Dans une optique de rendre le jeu le plus cohérent avec son univers, nous avionschangé le menu principal pour le rendre plus beau, plus épuré et plus attractif pourles nouveaux joueurs. Ceci est aussi dû au logo du jeu qui donnait tout de suitel’allure du jeu avant même d’y avoir joué.

22


Figure 11 – Menu principal deuxième cycle


Concernant les mécaniques de jeu, la plupart était présente lors du premier cycle.Cependant, chacune de ces parties a été grandement améliorée pour accroître d’unemanière significative l’aisance de la prise en main du jeu ainsi que la jouabilité entermes généraux.

Nous retrouvons donc en éléments de mécaniques de jeu :— Mouvement du caddy— Mouvement de la caméra— Collision entre le caddy est les différents objets provocant leur chute— Surveillance de la zone par un personnage non-joueur— Interaction avec le personnage non-joueur


En vue des derniers exploits de la physique du caddy (extrêmement médiocres),il a été nécessaire de modifier le déplacement de notre caddy, nous avons donc aban-donné le composant "rigidbody" au profit de composants "wheel collider" permettantla simulation de vrais moteurs et roues. cependant cela demandait de nombreux testsdans sa mise en place car un freinage trop important ou une accélération trop forteprovoquait le chaos dans les déplacements du caddy. Tout devait être réglé minu-tieusement afin d’obtenir un mouvement fluide et agréable. Alexis et Thomas s’ensont chargé.

23



Depuis la première soutenance quelques modifications ont été apportées au person-nage non-joueur, dorénavant, celui-ci est capable de changer de cible en pleine coursepour poursuivre la plus proche, de plus lorsqu’il entre en contact avec un joueur ill’expédie au point d’apparition. En d’autres termes, l’intelligence artificielle prenaitdésormais en compte l’aspect multijoueur de notre jeu.

5.5.3 Caméra

Fixe en temps normal et libre quand un bouton de la souris est enfoncé, la nouvellecaméra a aussi la possibilité de zoomer, de manière à rendre la prise en main plusagréable, lorsque le bouton de la souris permettant la rotation de la caméra estrelâché, celle-ci revient se placer à sa position initiale. Et le plus important, lastabilité a été grandement améliorée de manière à limiter les désagréments lors demouvements rapides ou chaotiques.

5.6 Réseau

La partie réseau du deuxième cycle était principalement centrée sur la synchro-nisation des actions du joueur avec les autres instances en cours avec l’ajout denombreux composants sur l’objet du joueur, notamment :

— La synchronisation des déplacements par le nouveau scriptSmoothSyncMovement.cs

— La synchronisation des animations par le composant PhotonAnimatorView— La synchronisation des chutes et collisions grâce au composant

PhotonRigidBodyView.

Cependant, d’autres fonctionnalités ont été implémentées comme le retour au halldepuis une salle qui permet au joueur de se déconnecter d’une partie en cours afin depouvoir : soit quitter le programme, soit relancer une nouvelle partie ou en rejoindreune nouvelle. Et finalement, ont été aussi ajoutés le listage des joueurs d’une salleet la gestion des points d’apparitions permettant respectivement à chaque joueurd’une salle de connaître les joueurs présents dans la salle (leur nombre ainsi que leurnom) et de faire revenir le caddy à un ancien point dans l’espace.

24


5.7 Gestion des cartes de jeu

Lors de la création d’un jeu, il y a deux manières de construire un niveau. Pre-mièrement, faire le niveau dans Unity en ajoutant des éléments divers et variés. Parexemple, un jeu comme Mario Kart 8 à tout intérêt à avoir des niveaux fixes qui nese répètent pas si il veut constamment dépayser le joueur. Deuxièmement, le niveauest constitué de briques, des éléments qui se répètent. Par exemple, Minecraft etMario Maker sont des jeux basés sur ce système bac à sable. Dans le monde dujeu vidéo, il n’y a pas de bonne ou de mauvaise façon de constituer son niveau carcela reviendrait à dire qu’il y a des bonnes et des mauvaises mécaniques de jeu. Cessystèmes sont différents et n’ont pas les mêmes objectifs, le changement de l’un àl’autre modifie radicalement l’expérience du joueur.

Le mode de fonctionnement que nous utilisons est le deuxième. Tout d’abord,parce que notre jeu se passe dans un supermarché, il ne s’agit pas de terrains com-plexes mais de surfaces très géométriquehttps ://www.overleaf.com/download/project/5bb336ae051ceb07efc78341/build/16ac5b784ab-c9f718242a6dc7df/output/output.pdf ?compileGroup=standardclsiserverid=clsi-pre-emp-1965popupDownload=trues. Ensuite, cela rend les cartes de jeu plus faciles àmodifier si la structure des objets changent. Et enfin, c’est une toute nouvelle expé-rience de jeu qui est offerte. Minecraft est un très bon exemple de jeu qui a eu dusuccès grâce au mode bac à sable. Les gens aiment créer des choses, exprimer leurcréativité, transformer des idées en créations concrètes. Ce mode est très puissantcar il permet d’adapter le jeu à chaque personne, élargissant sa portée auprès d’unlarge public. Et le jeu Hytale (48 millions de vues sur Youtube alors que le jeu n’estpas sortie) montre que la communauté est toujours sensible à ce type de jeu.

5.7.1 L’échec de l’enregistrement via le Json

Unity propose trois systèmes d’enregistrements : l’enregistrement via dictionnaire,via Json 4 ou par la binarisation (plus difficile à modifier). Pour un souci d’accessibi-lité, notre choix s’est porté sur le Json. Tout semblait bien aller dans le meilleur desmondes mais au fur et à mesure que nous avancions, des problèmes commençaient àse montrer comme la limitation a la sauvegarde d’entiers et de flottants et le manqued’optimisation sur des cartes de jeu de grande envergure. Il a fallu rebrousser cheminpour trouver une autre solution...

4. Une façon de structurer les données

25


5.7.2 Enregistrement de carte

Axel a donc créé un système d’enregistrement unique pour le jeu. En effet, tousles objets de la map ont une classe : STC_GameObjectClass. Elle permet de savoirce qui doit être enregistré, et quelles sont ses données. Une fois que la liste des objetsest sauvegardée, chaque objet va être enregistré dans le fichier en une ligne sous laforme :

Figure 12 – Forme de la sauvegarde d’un objet

Figure 13 – Exemple de fichier de sauvegarde

5.7.3 Chargement de carte

Maintenant que la map pouvait être sauvegardée, il fallait la charger dans le jeu.Pour cela, une méthode s’occupait de décomposer le fichier en catégories. Puis elleregardait le nom de chaque catégorie pour traiter ces données en adéquation. Pourl’exemple ci-dessus, MAP_SETTINGS n’a aucune donnée donc le programme nefait rien. Puis MAP_OBJECTS possède des données donc une liste de toutes leslignes va être créée avec comme séparation le point-virgule ou le retour à la ligne.Ensuite, la première ligne était décomposée (encore) en une liste de chaînes de carac-tères. Chaque donnée était interprétée selon sa position et les paramètres précédents.Par exemple, l’élément à l’index 1 est l’id tandis que l’index 5 est la position en xde l’élément. L’objet était ensuite instancié dans la scène et le programme passait àla ligne suivante pour construire le reste du niveau.

5.7.4 Éditeur de niveau

Nous avions les outils pour enregistrer et charger des niveaux mais pas de cadrepour les utiliser. Ainsi, l’éditeur de niveau fut là pour ça. Une ligne de texte informait

26


l’utilisateur de l’objet qu’il sélectionnait : la gomme, une étagère, un frigo, etc. Ily avait également une prévisualisation de l’objet que l’on allait placer. Et enfin, lemenu des paramètres qui permettait de changer le nom du fichier de la carte de jeu.C’est le plus important car c’est ce qui permet aux joueurs d’échanger leurs mapset de faire les leurs.

5.8 Avances et retards

Tâche / État Prévu Actuel

Graphisme 60 70Son 70 40Menu 80 80Réseau 70 80IA 60 85Mécanique de jeu 70 65

Table 4 – Tableau des avances et retards deuxième cycle

5.9 Conclusion deuxième Cycle

Même si des difficultés ont été rencontrées, nous avons, durant cette deuxièmesession, réalisé un grand bond en avant. En effet que ce soit au niveau de la jouabilitéou simplement de l’aspect visuel.

27


6 Dernier Cycle

6.1 Menus pour le logiciel d’installation et le jeu

Quand un joueur veut jouer à notre jeu, sa première réaction est de vouloir té-lécharger le jeu. Il faut donc le moins d’obstacles sur son chemin si on ne veutpas le lasser avant même qu’il joue au jeu. Pour ce faire, le joueur doit d’abord letélécharger sur notre site : TheObviousCorp.com. Une fois que le logiciel d’instal-lation "SetupSTC.exe" est téléchargé, le joueur clique dessus pour afficher le menud’installation. Le logiciel d’installation est fait avec Inno Setup Compiler qui est unoutil pour créer des installeurs personnalisés. Une fois toutes les étapes effectuées,le jeu est installé sur l’ordinateur du joueur. Il lui suffit de double-cliquer sur l’icôneSTC présent sur le bureau de son ordinateur pour démarrer le jeu. (Des instructionsd’installation sont également présentes sur la page de téléchargement 5)

Figure 14 – Menu d’installation

Concernant les menus du jeu, Alexis a créé des menus basiques pour la créationde partie multijoueur (partie technique sans style graphique). Puis, Axel a changél’agencement, les couleurs, les polices d’écritures des éléments pour que cela cor-responde plus à l’univers du jeu. Vous pouvez voir un exemple ci-dessous avec,notamment, du flou d’arrière-plan qui donne un côté plus beau à l’interface.

5. Présent à l’adresse suivante : TheObviousCorp.com/stc.download.html

28


Figure 15 – Menu de création de partie

Nous avons également ajouté les menus manquants, à savoir le menu pour jouertout seul. Et aussi les crédits qui affichent tous les gens de The Obvious Corp. quiont participé au projet, ainsi que les personnes que nous remercions.

29




Il aurait été assez ironique si les caddies dans notre jeu ne pouvaient pas contenird’objets. C’est pourquoi, Axel a ajouté des collisions plus détaillées pour le caddy.Ainsi, à chaque fois que le caddy d’un adversaire sera poussé dans les rayons, lesobjets tomberont dans son caddy et y resteront.

En complément du système de réapparition, des points de passage ont été implé-mentés, il s’agit d’un modèle empaqueté de telle sorte à former un objet prefab 6,celui-ci contient le modèle 3D du point de réapparition. Dans notre cas nous avonschoisi une arche qui peut rappeler d’autres jeux ou même des courses réelles, ce quirend le fait de devoir passer dessous intuitif pour le joueur.De plus, il contient un tag 7 spécifique qui permet de l’identifier rapidement à traversles différents programmes du jeu, ainsi que deux objets « collision » qui représententle corps de l’objet, l’un étant les collisions engendrées par la matière de l’arche etl’autre est en fait intangible et sert uniquement à détecter le franchissement del’arche. Il s’agit là donc seulement d’une boîte de collision qui envoie une informa-tion lorsqu’elle est traversée par un objet assimilé au joueur, au moment où cetteinformation atteint ledit joueur celui-ci enregistre le point de sauvegarde commeétant le dernier point de sauvegarde traversé.

Ce système d’actualisation du point de sauvegarde en fonction de la progression dujoueur est couplé avec un système de stockage chronologique des points de passagece qui prévient tout possible retour en arrière de la part du joueur, cela n’écraseraitdonc pas le dernier point obtenu.Il permet donc au joueur de s’assurer une progression linéaire dans la course et encas de blocage de pouvoir reprendre depuis un point stratégique.

Dans un second temps, des bonus disponibles en course pour aider les joueurs ontété rajoutés.Ceux-ci prennent différentes formes, et peuvent avoir des effets variés, comme unsupplément de vitesse, la possibilité de propulser un joueur adverse au contact, etc.Ces bonus fonctionnent de manière quasiment similaire aux points de passage, c’est-à-dire qu’ils sont empaquetés dans un objet de type prefab, et se compose du modèle3D (leur apparence), de leur tag, ainsi que de deux objets collisions, un premier de

6. préfabriqué, objet servant de modèle pour les futures instanciations7. étiquette

30


matière pour pouvoir donner une pesanteur à l’objet et le second qui sert de déclen-cheur pour envoyer une information au joueur lorsque celui-ci le traverse.L’information contenant le type de bonus ainsi que ses attributs sont stockés par lejoueur afin de pouvoir les déclencher au moment voulu.Le bonus en lui-même est stocké dans le caddy et n’est utilisable qu’à cet empla-cement ce qui signifie que renverser un joueur adverse pour lui faire perdre sonbonus devient une des mécaniques de jeux disponibles lors d’une course, les bonusapparaîtront sur la carte à des emplacements prédéfinis, et disposeront d’un délaide réapparition automatique en cas de cueillette.


Le personnage non-joueur s’est vu apporté quelques modifications concernant sadétection des joueurs proches, car nous nous étions rendu compte que le calcul dela distance s’effectuait sur un seul axe et qu’il ne prenait pas en compte les valeursnégatives ce qui résultait a une détection de distance infinie, sur les valeurs négativesde l’axe, en d’autres termes, tout joueur qui passait dans le dos du personnage sevoyait détecté.

6.2.3 Caméra

En ce qui concerne la caméra, après les modifications apportées lors du deuxièmecycle nous nous sommes convenu, que le but que nous étions fixé la concernant avaitété atteint. Nous avons donc réfléchi à des propriétés bonus qu’elle pourrait adoptercomme des effets de vitesse provoqué par des flous ou zooms cinétiques.

31


6.3 Graphismes

Notre projet dispose de beaucoup de points forts et l’un d’entre eux et la créationintégrale de son esthétique visuelle. STC 8 est un jeu dont tous les éléments et toutesles ambiances ont été créés grâce à notre imagination. Nous apportons une grandeimportance au graphisme : si le programme de notre jeu s’apparente aux organesinternes d’un être humain, alors le graphisme s’apparente à sa peau, les graphismessont la représentation directe du jeu.

6.3.1 Modèle 3D

Les modèles 3D représentent la base de l’environnement du jeu. Ils sont créésprincipalement par Thomas sur le logiciel Blender. Les objets réalisés visibles dansSTC sont tous dans le style "low poly" ce qui pourrait se traduire par des formespolygonales simples. Le jeu étant destiné à avoir un design cartoon l’utilisation du"low poly" est justifiée : Il permet d’avoir des objets reconnaissables et très coloréssans qu’ils soient très détaillés.

La méthode de confection des objets part toujours de la même base, une forme3D simple qui servira de base pour la suite :

— Un cube— Une sphère— Un cylindre— ...

Une fois la base la plus pertinente choisit il ne reste plus qu’à rendre l’objet re-connaissable sans trop le détailler. Pour cela les faces de la forme 3D de base sontétendues, étirées, translatées et tournées grâce au logiciel Blender.

Figure 16 – Transformation

8. Salade, Tomate, Caddy

32


Le supermarché est l’environnement dans lequel évolue notre course, il parut viteévident qu’il fallait se renseigner sur tous les types de présentoirs présents dans cedernier. Le but ultime de la partie graphique étant de représenter tous les élémentsd’un supermarché dans une représentation simplifiée, mais aussi de rendre le jeuvivant de par les couleurs, les formes, en somme la diversité des éléments. C’estainsi que de nouveaux modèles furent créer pour chaque différentes catégories :

— Des nouveaux objets lourds (étagère, rayon, rack, ...)— Des nouveaux objets médians (sacs de patates, piles de conserves, caisse en

bois, ...)— Et des nouveaux objets légers (grappes de bananes, pack de boite, ...)

Au final voici la liste de tout les objets réalisés à la main de ce projet :

Les objets lourds :— des caisses (supermarché)— des points de passage (course)— une arrivée— des étagères— des étagères réfrigérantes— des plantes— des panneaux directionnels

Les objets médians :— des caddys— des caisses en bois— des sacs de patates— des piles de conserves

Et enfin, les objets légers :— des bananes— des tomates— des salades— des conserves— des patates— des boites colorées— des packs de bouteilles— des liasses de billets

33


— des bouteilles de vins— des accélérateurs (mécanique de course)

6.4 Multijoueur / réseau

6.4.1 Génération des objets légers

Pour ajouter du dynamisme à notre jeu et, d’une manière générale, d’y apporterplus de réalisme, Alexis a pris la décision de générer des objets légers lors d’unecollision avec les objets qui les contiennent tels que :

— Les armoires— Les rayons— Les caisses enregistreuses— . . .

Différentes contraintes se sont alors présentées :— Il fallait que les objets légers générés soient en accord avec ceux du conteneur.— Ils devaient être visibles par les autres joueurs.— Sous peine de ralentissements importants, de tels objets devaient être tem-

poraires, la gestion de leur destruction devait donc être prise en compte lorsde leur instanciation.

— Leur simple génération ne pouvait pas être adéquate car, soumis uniquement àleur poids, les objets effectueraient une simple chute verticale peu esthétique.

Pour pouvoir respecter la première contrainte, l’idée a été de placer les objetslégers directement en tant que fils de leur conteneur. Ainsi, lors d’une collision, unsimple parcours des composants de celui-ci permettait de récupérer ces objets légersassociés et, lors de leur génération, de choisir aléatoirement les objets à instancierparmi ceux récupérés.

La deuxième contrainte impliquait une gestion multijoueur des objets. Comme vuprécédemment (dans les parties réseau précédentes) la première idée a été de placerle composant "Photon View" sur les objets, composant qui permet d’indiquer àPhoton que l’objet doit être vu par les autres joueurs de la salle. Cependant, unefaiblesse de Photon réside dans sa manière de gérer les forces. En effet, lorsqu’uneforce est appliquée à un objet et que celui-ci est visible par les autres joueurs lerendu est impeccable en local mais ne l’est absolument pas sur les autres sessionsqui voient entre autres les objets se téléporter. De ce fait, les objets seraient plutôt

34


générés uniquement localement dans toutes les sessions. Pour ce faire, l’utilisationd’un RPC (Remote Procedure Call 9) c’est vu obligatoire. Suite à cet appel qui sedéclencherait lors d’une collision avec un conteneur, chaque joueur lancerait leurpropre génération d’objets conformément aux informations de position et de typesd’objets à générer qu’enverrait le joueur qui a déclenché l’appel.

Concernant la troisième contrainte, il a été retenu de placer une liste contenanttous les objets légers instanciés qui posséderaient une taille limite. En d’autrestermes, lorsque le nombre d’éléments de cette liste dépasserait un certain seuil, ondétruirait les éléments générés les plus anciens, à savoir, ceux qui se situent le plusproche du début de la liste. De ce fait, chaque session ne posséderait qu’un nombrelimité d’objets légers évitant ainsi de grosses pertes de performance.

Pour la dernière contrainte, il a fallu trouver un moyen esthétique de faire appa-raître les objets. La première idée a été de leur appliquer des forces de sens et denorme aléatoire dans les trois directions possibles. Un problème de cohérence s’estalors posé lorsque la force était dirigée vers le bas, en effet l’objet avait alors unetrop grande vélocité (car cette force s’additionnait avec le poids de l’objet). Doncne pas orienter la force vers le sol s’est vu être nécessaire. Par ailleurs l’instancia-tion d’un seul et unique objet n’étant pas très impressionnant visuellement, il a étédécidé d’en générer cinq d’un coup. De plus, afin de donner plus de réalisme, on aajouté un seuil minimal de vitesse à avoir avec le caddy pour déclencher l’appel quicorrespondait à la moitié de la vitesse maximale.

6.4.2 Salle d’attente

Un problème se posait quant à la gestion des cartes et des joueurs dans une partie.En effet, jusqu’à présent on pouvait certes rejoindre une partie, mais cela sans mêmeavoir l’accord du créateur de la partie. De plus, le créateur d’une partie n’avait aucunmoyen de choisir sa carte de jeu malgré le fait que l’éditeur de niveau avait été misen place. Ainsi, il fallait donc créer une salle d’attente entre la création d’une partieet son lancement et c’est Alexis qui s’en est chargé.

Concernant les différentes fonctionnalités de cette salle d’attente on y retrouvenotamment :

— La modification du nombre maximal de joueurs

9. appel de procédure à distance

35


— Le choix de la scène à lancer par rapport aux scènes locales que dispose lecréateur

— La liste des joueurs présents dans cette salle (avec leurs noms)— La possibilité pour le créateur de virer des joueurs— L’abandon de la salle (bouton Quitter)— Le lancement de la partie

De nombreuses difficultés sont alors apparues lors de la mise en place des dif-férentes fonctionnalités. Premièrement, il fallait que les joueurs puissent interagirentre eux. Puis, que seul le créateur de la partie ait accès à toutes les fonctionnalités(il aurait par exemple été gênant de voir le créateur se faire expulser de sa proprepartie par un joueur lambda).

Donc, afin de pallier à ces difficultés, il a fallu premièrement créer des objetspossédant un composant "Photon View" qui serait par la suite associé à tout joueurentrant dans la salle d’attente. A été placé sur cet objet la page des différentesfonctionnalités de la salle d’attente, car chaque éléments de cette page interagit avecles autres joueurs et est différent selon le joueur associé.

Concernant la fonctionnalité qui permet de choisir une scène, Axel a créé unefonction récupérant toutes les scènes que dispose un joueur localement et les retour-nant dans une liste. Grâce à cette fonction, Alexis a pu les afficher sur une listedéroulante qui permet au joueur de choisir celle désirée.

Outre la mise en place des différents boutons plutôt simple, il a fallu leur asso-cier différentes fonctions qui la plupart, devaient être des RPC car communiquantdirectement avec les autres joueurs. C’est par exemple le cas des fonctionnalités quipermettent de virer un joueur et de lancer la partie.

Ainsi, lorsque le premier appel se déclenchait quand on choisissait de virer unautre joueur, l’appel se contentait uniquement d’envoyer au joueur cible un ordre dedéconnexion de la salle, le faisant retourner alors dans le hall de sélection de salles.Par ailleurs, cela mettait à jour par la même occasion la liste des joueurs présentsdans la salle. De plus, si jamais le créateur de la partie choisissait de quitter la salle,ses droits seraient transférés au second joueur à avoir rejoint la salle, il deviendraitalors le nouveau créateur de la partie.

36


Concernant le deuxième appel, un problème est apparu lors du lancement dela partie. En effet, comme dit précédemment, la scène choisie par le créateur estlocale (car provenant de son éditeur de niveau), par conséquent, les autres joueursne disposant pas de ces informations, ne pouvaient par aucun moyen instancier lesdifférents objets de la scène. De ce fait, Axel ayant déjà fait une fonction permettantde convertir les données d’un fichier .map 10 en réels objets générés dans une scène,il fallait simplement trouver un moyen de stocker ces informations (qui se présententsous forme de chaînes de caractères) et de les communiquer aux nouveaux joueurs.On a donc créé une liste de chaînes de caractères qui regroupe ces informations. Àsavoir que chaque joueur possède une telle liste et que lors de son arrivée dans lasalle, le créateur de la partie envoie via un RPC les différentes informations qu’ellecontient. Cela a permis lors de l’appel au lancement du jeu que chaque joueur puisseà partir des informations reçues du créateur, générer leur propre scène localement.

6.4.3 Tableau des scores

Afin que chaque joueur puisse suivre la progression des autres au sein d’une partie,Alexis a créé un tableau récapitulatif des scores qui est accessible depuis le jeu enappuyant sur la touche de tabulation.

Ce tableau constitue une simple page, où figurent les noms des différents joueurs dela partie ainsi que leur score qui se compose du nombre de points de passage traversésur le nombre de points restants ainsi qu’un temps correspondant à la traversée dudernier point de passage.

Le tableau des scores permet donc d’avoir un aperçu quant à l’éventuel retard ouavance que possède un joueur sur ses concurrents et permet à la fin de la partie desavoir ceux qui ont été les plus performants.

6.4.4 Particules

Tout le monde aime les particules, elles rendent un jeu plus dynamique et ontun effet visuel sans précèdent. C’est pourquoi la dernière tâche d’Alexis a été deles mettre en place. On discerne avant tout deux types de particules. Les particulesseulement visibles en local, qui ne doivent pas être vues par les autres joueurs etles particules qui doivent être, elles, visibles sur toutes les sessions. Ces dernièresimpliquent évidemment une gestion en multijoueur.

10. Extension qui signale que le fichier contient les informations sur une scène générée dansl’éditeur de niveau

37


Pour faire cette gestion, il faut en premier lieu placer la particule dans le dossierressource de Photon car tout objet qui se voit instancié en multijoueur par Photondoit se situer dans ce répertoire. Puis lui ajouter un script pour détruire la par-ticule une fois qu’elle a été jouée. En effet, si on ne le faisait pas, au bout d’unmoment la scène serait surchargée de ces particules et provoquerait d’importantsralentissements (comme pour la génération des objets légers vus plus tôt).

Puis, l’idée générale est plutôt simple. Lors d’un évènement particulier (par exempleune collision), on instanciera la particule avec photon qui la jouera et qui sera dé-truite une fois jouée.

6.4.5 Mode hors-ligne

Pour le mode hors ligne de notre jeu, ou tout simplement le mode "solo", Photonpropose par avance une fonction permettant de gérer à partir du programme en mul-tijoueur un mode hors-ligne. Un simple booléen passé en argument de la connexionau serveur Photon et la désactivation de certaines fonctionnalités ont donc permisde générer ce mode très facilement.

6.5 Musiques et sons

Par rapport à la dernière soutenance où la mise en place du son ne respectaitpas les contraintes imposées par le multijoueur, Alexis s’est chargé de l’implémentercorrectement. En effet, précédemment, le composant permettant de récupérer lessons et bruitages ("Audio Listener") et celui permettant de générer la musique("Audio Source") étaient placés directement sur le joueur qui lors d’une instanciationmultiple (lorsqu’il y a au moins deux joueurs) générait des erreurs car d’une, il yavait deux "Audio Listener", or il ne peut n’y en avoir qu’un par scène, et de deux,la musique provenait de deux entités distinctes (ou plus selon le nombre de joueursdans la scène). Ainsi, pour pallier ces problèmes on a désactivé ces composantspar défaut et lors de l’instanciation d’un joueur dans une scène seule ses proprescomposants se réactivent, ceux des autres joueurs restant "éteints".

Axel a par la suite changé le volume de la musique qui était trop fort. En effet, enchangeant le système, le volume n’était plus le même. Il a donc directement modifiéle volume du fichier. Ainsi le son n’est pas trop fort pour les joueurs.

En plus de ça, il a mis une musique dans l’éditeur de niveau pour que le joueurpuisse pleinement exprimer sa créativité. Cette nouvelle musique d’ambiance de

38


l’éditeur de niveau subit des effets de distorsions semblables a ce que peut faire lejeu Mario Maker. Quand un joueur place un objet, la musique change légèrement.Cela peut paraître insignifiant mais ce sont des détails de ce genre qui permettentde mettre le joueur en immersion totale.

Enfin, des sons d’ambiances ont été ajoutés dans un soucis d’immersion du joueur.Les sons sont divers et variés, allant du bruit des caddies a une voix off en fond.

39


6.6 Éditeur de niveau et gestion de cartes

Nous avons détaillé tout notre jeu : ses mécaniques, ses graphismes, son ambiancesonore. Tous ces éléments sont présents mais n’ont pas de sens tant qu’ils ne sont pasassemblés de manière réfléchie et étudiée pour constituer un niveau. C’est un peucomme avec la construction d’une maison. Nous avons les briques mais il manqueles outils pour construire la maison. Cette partie va donc décrire le fonctionnementde l’éditeur de niveau, l’outil qui va permettre de créer les niveaux de notre jeu maispas seulement. Il va aussi être accessible aux joueurs et à tous les créateurs dansl’âme car nous pensons que notre jeu peut permettre de créer une véritable vocationpour certaines personnes. Il suffit de voir le succès qu’a eu Minecraft, Mario Makeret tout jeu possédant un éditeur de niveau. Le marché potentiel est énorme et peutlaisser présager un petit succès du notre jeu auprès de ce public.

6.6.1 Interface

Commençons par une vue d’ensemble de l’interface de l’éditeur de niveau fait parAxel. On peut déjà constater que le choix des couleurs, des formes, des images seveut attrayant pour le joueur. Sur le panneau latéral à gauche, nous avons le boutonpour jouer le niveau, les outils globaux sur la map, les outils d’édition et l’inventairedes objets disponibles. Au milieu, c’est la vue de la map à l’emplacement du joueur.Et enfin, sur la barre latérale droite, il s’agit de l’inspecteur. Un outil qui permetd’afficher et de modifier des données sur l’objet sélectionné par le joueur. Regardonsmaintenant plus en détail chaque élément.

Figure 17 – Interface finale de l’éditeur de niveau

40


6.6.2 Panneau latéral gauche

Bouton jouerLe bouton Jouer permet au joueur de tester le niveau qu’il a fait sans à devoir

sortir de l’éditeur de niveau.

Les outils globauxLes outils globaux sont constitués de quatre boutons :— Sauvegarder— Charger— Actualiser— Paramètres

Les boutons Sauvegarder et Charger permettent comme leurs noms indiquent,de sauvegarder la carte que le joueur construit et de charger une carte située surl’ordinateur en local.

Le bouton Actualiser permet de recharger la carte en mémoire en cas de problèmed’affichage.

Le bouton Paramètres, une fois pressé, ouvre une fenêtre pour changer différentsparamètres dans la carte de jeu, comme son nom de ficher qui finit en .map commepar exemple : "supermarché.map".

Les outils d’éditionsCes outils sont importants car ils permettent de véritablement construire le niveau,

ils sont au nombre de trois, à savoir :— Sélection— Construction— Suppression

Pour le premier, l’outil de sélection permet de sélectionner un ou des objetsen cliquant dessus, ou même de tout sélectionner d’un coup 11. On peut ensuitecopier puis coller 12 l’objet en question pour le dupliquer autant de fois que possible.

11. Pour tout sélectionner, le raccourci est Ctrl+A12. Le raccourci pour copier est Ctrl+C et pour coller est Ctrl+V

41


Si besoin, il est également possible de supprimer 13 les objets sélectionnés. Enfin,si l’utilisateur n’en a plus besoin, il peut dé-sélectionner les objets 14.

Concernant l’outil de construction, il permet de placer des objets sur la carte.En effet, quand le joueur clique sur un objet de l’inventaire, il bascule sur cet outilautomatiquement. Selon l’objet sélectionné, son placement ne sera pas fait de lamême manière. Par exemple, une étagère va prendre forcément appuis sur le solmais une canette va pouvoir être placée en tant qu’objet fils dans une étagère oud’autres objets massifs.

L’outil de suppression va permettre de supprimer l’objet pointé par la souris. Ilest plus rapide pour supprimer des objets et en plus, il ne supprime pas les objetsrelatifs au magasin comme le sol ou les murs.

6.6.3 Inspecteur d’objet

L’inspecteur d’objet permet de voir et modifier les données sur l’objet sélectionné.Par exemple, imaginons que l’utilisateur veuille déplacer ou tourner un objet déjàposé sur la carte. Il lui suffit simplement de cliquer dessus et de modifier les va-leurs de translation et de rotation en cliquant sur les petites flèches à droite dechaque case. L’objet prendra en compte les nouvelles données automatiquement, àchaque changement des valeurs dans l’inspecteur. De plus, d’autres métadonnéessont visibles juste en dessous. Par exemple :

— Id : permet d’avoir une référence absolue de l’objet. Par exemple, quand unobjet possède un parent, il utilise l’id comme référence.

— Classe : La catégorie de l’objet : lourd, médian, léger, groupé, construction,événement, etc.

— Type : De quel objet s’agit-il ? Une étagère, un frigo, une plante, une canette ?— Id parent : L’id du parent (0 si il n’en a pas)

6.6.4 Gestion des objets parents

Une fois que l’éditeur de niveau fut mis en place, l’équipe se rendit compte d’unproblème. Le système d’objets qui tombent créés par Alexis ne fonctionnait pas avecles étagères de l’éditeur de niveau car son système reposait sur la récupération desobjets fils de l’étagère. Axel a donc dû s’atteler à la tâche de permettre aux ob-jets légers placés de détecter l’étagère proche comme parent. Pour cela, il a ajouté

13. Pour supprimer les objets sélectionnés, le raccourci est Del ou Suppr en français14. Pour dé-sélectionner les objets sélectionnés, le raccourci est Esc ou Echap en français

42


un système qui fait que quand un objet apparaît, une boîte de collision, volontai-rement trop grande, est créée autour de l’objet en question. Ainsi, si l’étagère estdétectée dans la boîte de collision de l’objet léger, elle sera mise en tant que parentpour l’objet léger. D’où l’intérêt d’avoir un id (identifiant unique) attribué a chaqueobjet. L’objet léger peut ainsi enregistrer la référence de de son parent dans sesmétadonnées.

6.6.5 Gestion de carte

La gestion de carte est gérée par un script qui s’occupe de charger, enregistrer, ins-tantié les objets de la carte. Il a fallu modifier des fonctions et ajouter des nouveauxoutils pour qu’il s’adapte aux autres parties du jeu. Par exemple, Alexis avait besoinque le script renvoie une liste de toutes les maps présente sur l’ordinateur, ce qui aété fait par la suite. Mais c’est également sur d’autres sujets, comme la générationdu niveau sur le serveur, qu’un travail de collaboration a dû être fait pour que Axelpuisse comprendre ce qu’avait besoin Alexis et qu’il puisse comprendre comment lacarte était gérée.

De plus, il a fallu "normalisé" les objets créés par Thomas. En effet, s’il s’occupaitde créer les modèles mais il n’adaptait pas les objets au fonctionnement du jeu. Axelchangeait donc la hiérarchie des objets pour que le modèle se retrouve enfant d’unobjet vide, dans le but que l’origine de l’objet soit située au bon endroit. Il fallaitensuite ajouter le script "STC_GameObjectClass" qui s’occupait de gérer l’objetmais aussi de renseigner de quel type d’objet s’agit-il ? quelle est sa classe ? est-ilactif ? Tout ceci est très important pour que le jeu puisse interpréter correctementl’objet. On ajoute les collisions de l’objet de la façon voulue, s’il s’agit d’une canette,il est préférable d’utiliser une boîte de collision avec des courbes pour que l’objetpuisse rouler par terre. Et enfin, on utilise un script pour faite la distinction entrel’éditeur de niveau et le jeu. En effet, la zone de départ est représentée par uneboîte verte transparente, elle ne sert qu’à titre d’indication dans l’éditeur. Il fautdonc ajouter le script "OnlyInLvlEdit" qui va supprimer automatiquement l’objets’il apparaît en jeu mais pas dans l’éditeur de niveau.

6.6.6 Corrections de problèmes et optimisations

À la suite de la deuxième soutenance, quelques bugs et soucis d’optimisations ontété découverts. Par exemple, comme le bouton pour quitter l’éditeur de niveau étaitEchap et qu’il n’y avait pas d’avertissement, cela pouvait arriver que l’utilisateurquitte et perde la carte qu’il venait de créer. En solution à ce problème, Axel a

43


ajouté une carte "_recovery.map" qui est la dernière sauvegarde quand l’utilisateurquitte l’éditeur. Ainsi, en cas de mauvaise manipulation, il peut toujours retrouversa carte dans le dossier de sauvegarde.

Un autre problème fut la rotation de la caméra dans l’éditeur. En effet, quand lejoueur montait la caméra vers le haut à 180 degrés, il était tourné dans l’autre sens(comme s’il tournait sur lui-même). Pour comprendre ce problème, il faut étudier lafaçon dont est représentée la rotation de la caméra. Quand la caméra tourne autourdes 2 axes de rotation, elle va de zéro à trois cent soixante degrés. Sauf que commela caméra est limitée dans sa rotation vers le haut, elle s’arrête à cent quatre-vingtsdegrés. De plus, il y a plusieurs états où la caméra se retrouve tournée vers le hautpuisqu’elle tourne sur elle-même. Comme la caméra ne peut être qu’à 180 degrés d’uncôté, la caméra tourne automatiquement en atteignant cette valeur. La solution adonc été de limiter la rotation à 179.99 degrés pour que les valeurs ne se mélangentpas.

Le dernier problème majeur fut l’optimisation des objets. En effet, quand l’onconçoit un jeu avec possiblement des centaines voir des milliers d’objets, il faut biensavoir gérer la manière dont les objets utilisent les ressources de l’ordinateur. Car, àraison de 500 objets qui effectuent tous leurs calculs pendant 0,03 seconde, le moindresouci d’optimisations peut véritablement gâcher l’expérience du jeu. Ainsi, pourrégler ce problème d’optimisation, Axel a réservé certaines méthodes à l’éditeur deniveau qui ne sont pas nécessaires pendant le jeu. De plus, les fonctions demandeusesen puissance de calcul comme le listage de tous les objets de la map a été externaliséet regroupé vers une fonction extérieure qui s’en occupe et qui le fait une seule fois.

44


7 Bilan du projet

7.1 Bilan général

Dans les éléments positifs de notre projet, il faut tout d’abord mentionner la co-hésion du groupe. Personne n’est resté en retrait, les tâches ont été équitablementréparties (non seulement au niveau de la quantité de travail qu’au niveau des com-pétences de chacun). Les grandes lignes ont été approuvées par tous les membres dugroupe et aucune altercation n’est survenue tout au long de l’année. Le travail enéquipe a donc été très fructueux. Bien sûr, nos avis n’ont pas toujours été communsmais des compromis ont été trouvés pour contenter tout le monde.

7.2 Ressentis personnels

7.2.1 Alexis

Tout d’abord, je pense que la demande de réalisation d’un projet aux premièresannées est une très bonne chose car cela permet de nous donner un premier contactentre les études et le monde réel du travail. Partant avec cet état d’esprit, ce projetm’a permis d’acquérir de l’expérience. Je sais par exemple, que la gestion du tempsest un critère déterminant.

Outre les compétences de travail de groupe et de gestion de projet, la réalisationde ce jeu m’a permis de m’initier au réseau et d’une manière générale, d’améliorermes connaissances en programmation.

7.2.2 Axel

Pas mal de chemin a été fait jusqu’à maintenant. Ce ne fut pas toujours facile,notamment avec les cours et les autres projets à assurer à côté mais ce fut uneexpérience enrichissante. J’ai pu trouver ce que je recherchais dans ce projet. Toutd’abord, j’ai commencé ce projet en n’ayant aucune expérience dans Unity. Quelquesmois après, j’ai appris beaucoup de choses sur Unity, et si je devais créer un nouveaujeu, je serais sûrement capable de le faire bien plus facilement qu’au début de ceprojet.

J’ai pu également approfondir mes connaissances en réalisation de site web. Eneffet, je possédais déjà des compétences en création de site web mais faire le site aété un peu un moyen de passer à un niveau supérieur dans ce que dégage le site

45


pour un nouveau visiteur. Par exemple, le site web est bien plus sobre et organiquedans ses animations que ce que j’avais pu faire avant.

Et enfin, j’avais précisé au début de ce rapport que j’avais déjà eu une expériencedans la création d’éditeur de niveau.Car, étant un grand admirateur du jeu Minecraftet des jeux de création en général, il était impensable pour moi de ne pas développerdes outils de création pour notre équipe et la communauté. Je suis ainsi passé de la2D avec un jeu Pac-Man à la 3D avec une gestion de la carte de jeu complète.

Mais ce n’est n’est pas fini, il reste énormément de choses à apprendre dans lacréation de jeu-vidéo et je vois ce projet comme le début d’une grande aventure dansla création artistique via l’informatique et l’audiovisuel.

7.2.3 Maxime

Il est de mon avis que le projet libre du S2 a été quelque chose de très bénéfique,en effet il permet la mise en pratique des cours de programmation et d’algorithmeslors de la conception des programmes fondant les bases du jeu. De ce fait, j’ai puconstater lors de la réalisation des Mécaniques de jeu que pour plusieurs algorithmesthéoriques, tous ne sont pas applicables en pratique, car il faut éviter les conflits entreceux-ci. De plus ayant des difficultés en ce qui concerne les exercices d’expressionorale, cela fut un bon entraînement au travail de groupe et aux rendus de progression.

Au cours des différents cycles, l’évolution du projet pouvait être ressentie. Lorsdu premier cycle s’agissant d’un exercice jusqu’alors inconnu, il était plutôt difficilede savoir si les prévisions de rendu seraient respectées, mais après un temps d’adap-tation, il fut possible de savoir combien de temps prendraient chaque tâche à êtreréalisé. D’autant plus qu’il y avait une très bonne ambiance au sein du groupe ce quiamène à une bonne cohésion avec malgré la répartition des tâches de l’entraide entreles membres. De plus lors des deux premières soutenances, il a été très appréciablede recevoir des conseils à appliquer pour la suivante, de manière à pouvoir essayerde s’améliorer. Pour finir, je suis content de pouvoir dire que travailler sur ce projetfut une expérience enrichissante et plutôt plaisante, à ce titre, j’espère de tout cœurque notre projet puisse combler les attentes ou tout du moins plaire.

7.2.4 Thomas

Je suis en quelque sorte l’artiste du groupe. Je suis le graphiste principal. AvecAxel nous accordions beaucoup d’importance à l’esthétique du jeu. Cependant, j’ai

46


aussi participé activement aux prémisses du réseau et à la physique du caddy.

Durant le premier cycle, j’étais très enthousiaste à l’idée de créer un jeu avec mongroupe, nous avions tous à peu près la même vision du projet et étions motivés,pour ma part il fallut vite apprendre à utiliser le logiciel Blender qui est très difficileà prendre en main. J’ai aussi naturellement pris en main le logiciel Unity à force depasser du temps dessus. Mes premiers modèles 3Ds n’avaient pas très fière allure,mais maintenant j’arrive à entreprendre tout ce que j’imagine. Blender est devenupour moi un réel outil de création. J’ai aussi pris du plaisir à comprendre commentfonctionnait notre jeu en réseau que cela soit par les explications d’Alexis ou parmes propres moyens.

Durant le deuxième cycle j’ai aussi beaucoup aimé revoir entièrement la physiquedu caddy avec Alexis, transformant les déplacements rigides du caddy en un réelmoyen de locomotion ajoutant dynamisme et vitesse au jeu. J’ai continué d’avancersur les modèles 3D, la création d’un modèle étant chronophage.

Ce dernier cycle est passé très rapidement et beaucoup de stress s’est accumulé,j’ai envie que ce projet plaise autant qu’il me plaît. Ce travail de groupe m’a permisd’apprendre à travailler en équipe sur un projet informatique et m’a permis d’enapprendre beaucoup sur la manière dont peut se dérouler un projet long et complexe.J’étais perdu, je sais maintenant où je suis.

47


8 Conclusion

Salade, Tomate, Caddy est un projet qui porte en lui les espoirs et les effortsde notre groupe. Il est la chose qui nous a fait nous réunir, travailler et débattre.STC est l’aboutissement d’une demi-année de labeur de quatre personnes dont lavolonté et la persévérance leur on permit de surmonter les obstacles. STC, c’estl’envie profonde de provoquer l’amusement des joueurs.

Il y a 6 mois de cela notre projet n’était qu’une idée farfelue, maintenant il repré-sente notre détermination à réussir et tout notre travail. Notre fierté ne peut êtrecachée, car partant d’une idée relevant de l’enfantillage ce projet est né.

Notre projet est complet, tous nos objectifs primaires sont remplis. Pour ce quiest du secondaire certaines parties sont très bien développées, certaines auraientsûrement mérité plus d’approfondissement, cependant, la globalité finale de STCsatisfait notre groupe.

Tout notre groupe vous remercie d’avoir lu ce rapport.

48


Table des figures

1 Ébauches pour le design de The Obvious Corporation . . . . . . . . . 62 Résultat final du design . . . . . . . . . . . . . . . . . . . . . . . . . 73 Les Lapins Crétins : La Grosse Aventure . . . . . . . . . . . . . . . . 94 Croquis de caddy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Croquis de mobilier de supermarché . . . . . . . . . . . . . . . . . . . 126 Modèles premier cycle . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Menus d’accueil et de connexion multijoueur . . . . . . . . . . . . . . 178 Exemples de plusieurs instances du jeu . . . . . . . . . . . . . . . . . 199 Rayonnage deuxième cycle . . . . . . . . . . . . . . . . . . . . . . . . 2110 Page d’accueil de The Obvious Corp. et STC . . . . . . . . . . . . . . 2211 Menu principal deuxième cycle . . . . . . . . . . . . . . . . . . . . . . 2312 Forme de la sauvegarde d’un objet . . . . . . . . . . . . . . . . . . . 2613 Exemple de fichier de sauvegarde . . . . . . . . . . . . . . . . . . . . 2614 Menu d’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2815 Menu de création de partie . . . . . . . . . . . . . . . . . . . . . . . . 2916 Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3217 Interface finale de l’éditeur de niveau . . . . . . . . . . . . . . . . . . 40

Liste des tableaux

1 Répartition des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Tableau de la planification des tâches selon les soutenances . . . . . . 153 Tableau des avances et retards premier cycle . . . . . . . . . . . . . . 204 Tableau des avances et retards deuxième cycle . . . . . . . . . . . . . 27

49

Documents

Salade, Tomate, Caddy! · 2020-03-25 · Salade,Tomate,Caddy Mai2019 TheObviousCorp. Finalement, nous avons opté pour le choix qui paraissait le plus évident et le plussobre. Figure