# Rapport Bad day for Dav

## Les lumières

URP propose quelques lumières 2d de base. Dans la direction artistique du projet, l'idée d'afficher des ombres très marquées dans un univers très sombre est primordiale. Pour ceci, ce "package" convient parfaitement.

Le problème principal rencontré dans la gestion des ombres est que pour qu'un élément puisse "bloquer" une lumière, il doit avoir comme composant le script "ShadowCaster2D". Ce dernier se sert alors d'une shape que le développeur doit définir pour chaque objet. Dans le cas du joueur ou des ennemis, cela ne pause pas de problème particulier car cela ne se fait qu'une fois avec des éléments simples. Mais lorsque des éléments sont plus complexes comme la map, "détourer" chaque batiment prendrait un temps beaucoup trop important. De plus, cette shape ne fait pas partie des attributs publiques du script.

Pour résoudre ce problème, un script nommé "ShadowCaster2DController" fait le lien entre les colliders des objets pour définir la shape du ShadowCaster. Ce dernier permet de convertir un EdgeCollider2D, un PolygonCollider2D ou un TileMapCollider2D. Le fonctionnement n'est pas compliqué, les deux premiers sont uniquement constitués d'une liste de points ils suffit donc de les copier dans la shape du shadow caster. Comme dit plus haut, cette liste n'est pas publique il faut donc ruser.

// Set the shadow path
_shapePathField.SetValue(shadowCaster, Vector2ToVector3(points));

unchecked
{
    // I have no idea what im doing with hashcodes but other examples are done like this
    int hashCode = (int)2166136261 ^ _shapePathField.GetHashCode();
    hashCode = hashCode * 16777619 ^ (points.GetHashCode());

    // Set the shapes hash to a random value which forces it to update the mesh in the next frame
    _shapeHash.SetValue(shadowCaster, hashCode);
}

Pour ce qui est de la TileMapCollider, elle constituée d'une liste de liste de points. Autrement dit une liste de "paths". On crée alors un shadow caster par path aquel on redéfinit la shape comme expliqué plus haut.

Le second problème rencontré fut le manque d'optimisation des lumières. Il n'existe pas d'option "baked" comme en 3D. Pour palier à ce problème, la plupart des lumières se voient ajouter d'un CircleCollider2D et d'un script (LightOptimizer) qui permet de les désactiver et réactiver lorsque le jouer s'en approche ou s'en éloigne. Ainsi, elle ne sont calculées que lorsque c'est nécessaire.

## Tilemap

La création de *tilemaps* est une technique fondamentale dans le développement de jeux 2D, consistant à construire le monde du jeu ou la carte des niveaux à partir d'images de forme régulières. Ces images sont nommées *tiles* et constitue la *tilemap*.

> Note: Le projet ainsi que l'éditeur est défini sur le mode 2D par défaut afin que les nouvelles textures soient importées en tant que *Sprites*. L'illumination globale en temps réel est désactivée. L'installation de packages 2D ainsi que les dépendances nécessaires, y compris **2D Animation**, **2D Pixel Perfect**, **2D PSD Importer** et **2D SpriteShape**, est déjà faite par l'utilisation de ce mode.

### Les sprites

Les *sprites*, donc les images constituant chaque *tile*, sont fournies une à une dans des dossiers séparés par le **Ceruleum**. Pour plus de lisibilité sur leur ensemble, une *spritesheet* est créée:

|Spritesheet|
|:-:|
||

Une fois la *spritesheet* créée, l'importation est faite par un *drag and drop* dans le dossier choisi, soit *Assets/Tile* dans le cas présent.

Le mode de projet est défini en 2D, l'image importée est alors automatiquement définie comme *sprite*.

|Sprite sheet in inspector|
|:-:|
||

Elle n'est pas utilisable en l'état, car le découpage de chaque *sprite* n'est pas réalisé. Il suffit de définir le nombre de pixels par unité en fonction de la dimension des sprites, soit `64 pixels` dans le cas présent, puis d'appuyer sur le bouton `Sprite Editor` en bas à droite de l'image.

|Sprite editor|
|:-:|
||

Ainsi, il est possible de découper l'image pour obtenir chacune des *sprites*. Une fois le nombre de pixels par unité défini, Unity s'occupe de paramétré `width` et `height`. En cliquant sur l'onglet `Slice`, l'option de découpage apparaît.

### Tile palette

Pour créer une *Tile palette*, `Window > 2D > Tile Palette`, puis de clicker sur l'onglet `new palette`. Les options sont à définir en fonction des *sprites*. En l'occurence, `64x64 pixels` et `Rectangle`. Une fois les paramètres définis, il suffit de *drag and drop* la *spritesheet* dans l'espace de la *Tile palette*.

Le résultat est le suivant:

|Tile palette|
|:-:|
||

Après avoir effectué ces actions, il est enfin possible de créer une *map*.

### Création de la map

La méthodologie appliquée pour la création de map est la suivante:

- Création d'un `GameObject` Tilemap composée d'une `Grid` comme parent et d'une `Tilemap` comme enfant: `Right Click > 2D Object > Tilemap > Rectangular`.
- Création de plusieurs `Tilemap` qui constitue les *layers* du jeu.
- 
- Dessin de la map par l'utilisation de la palette créée préalablement.

Résultat:

|Première map|
|:-:|
||

Un object `Tilemap Collider 2D` est ajouté sur le *layer* **Walls**. Il est représenté par les traits vert sur l'image. De cette manière, l'information sur les objets avec lesquels les entités vont faire des collisions est regroupé sur un même objet et généré en fonction des *sprites*.

La création de la *Tilemap* est faite à la main, et cela implique un certain coût en temps.

C'est pourquoi une map basique est créée rapidement au début du projet, afin d'être utilisable par les autres membres du groupe.

Puis le travail sur la map finale est commencée pour avoir de nouveau un résultat final rapidement. Ainsi, il est possible d'avoir un matériel abouti et utilisable pour la version final du jeu.

Résultat de la map finale:

|Map finale|
|:-:|
||

Des *layers* pour le rendu et la position des *lights* sont ajoutés. En tout, 15 *layers* sont créés.

## Audio

L'utilisation des musiques dans `Unity` passe par le biais de composants tel que `AudioSource` et `AudioMixer`.

Les sons de l'école de musique qui travaille en collaboration avec le **Ceruleum** sont utilisés pour l'ambiance principale du jeu.

Le fonctionnement principal dont les musiques sont jouées s'appuie sur le `GameState Manager` (ref. section `GameManager`). Lorsque l'état du jeu est en `Playing`, les musiques d'ambiance se lance. Dans le cas où l'état est `NextWave`, `FinishWave`, d'autre sons sont ajoutés et joués.

Lors du lancement du jeu, la création de chaque `AudioSource` est fait par l'instantiation d'une prefab.

Un `AudioMixer` est créé pour pouvoir modifier le volume et autres paramètres de sons directement depuis l'UI.

### Création des sons

Les sons autres que les musiques du jeu sont créés en utilisant [Logic Pro X](https://en.wikipedia.org/wiki/Logic_Pro), puis importés dans les `Assets` du projet.

## Ennemis

Pour les ennemis, nous voulions réaliser un système de vague où les ennemis apparaissent à de points précis. Ils doivent donc ensuite se diriger vers le joueur. En Unity 3D, on utiliserait quelque chose comme un NavMesh. Cependant, ce système n’est pas (encore) disponible en Unity 2D.

La méthode la plus commune pour réaliser le pathfinding en 2D est alors d’utiliser un package gratuit appelé A* Pathfinding Project. La version sur l’Asset Store est payante, mais la version gratuite est disponible sur le (site internet)[https://arongranberg.com/astar/].

Pour commencer l’utilisation d’A* avec les ennemis, il faut d’abord préparer la grille des obstacles. Après avoir importé le paquet, on peut créer un GameObject vide contentant le script Pathfinder. Ce dernier va analyser la scène et générer une grille contenant les obstacles. Le paramètre important est la taille des cellules qui doivent être pareil à notre grille actuelle. Il est d’ailleurs plus simple de mettre les obstacles sur une couche spécifique, sinon tous les éléments sont considérés comme tels.

Maintenant, on peut s’occuper des ennemis. Pour leur ajouter le pathfinding, on utilise le script AIPath. Ce script contient plusieurs options, comme la vitesse de déplacement. Son orientation doit cependant être fixée à 2D. Pour définir la destination de l’ennemi, on utilise le AIDestinationSetter. Il suffit alors de définir la cible comme étant le joueur, et notre ennemi suit maintenant ce dernier.

Pour le tir des ennemis, ils doivent tirer uniquement s’ils voient le joueur. Ils vont donc s’approcher de sa position jusqu’à le voir et commencer à tirer. Pour vérifier qu’un ennemi peut tirer, on utilise un Raycast en lui passant la couche d’obstacles. Ainsi, si le Raycast touche le joueur directement, l’ennemi peut tirer.

Nous utilisons aussi cette notion de vision pour la direction que l’ennemi regarde. Si l’ennemi voit le joueur, il lui fait face, donc regarde dans sa direction. Sinon, il suit simplement sa trajectoire.

Enfin, pour créer les différents ennemis, nous avons un Prefab avec le script principal et plusieurs Prefab qui hérite de ce dernier afin de changer certains paramètres. Le paramètre le plus important est l’arme utilisée par l’ennemi. Pour gérer les différentes armes, nous avons créé un ScriptableObject abstrait Gun, contenant la méthode Shoot. Il est donc facile de changer l’arme d’un ennemi.

Les boss eux ont un paterne différent des ennemis de base. Ils héritent donc du Prefab de base, mais en plus, utilisent un script héritant du script des ennemis. Ce script redéfinit cependant uniquement les méthodes Start, Update et Attack. Cela évite donc la répétition de code. Une autre solution aurait été l’utilisation d’un ScriptableObject.

## Joueur

Pour le joueur, nous utilisons le nouveau système d’entrée d’Unity, Input System. Il permet d’unifier les contrôles clavier-souris et manettes. Ainsi, il suffit de définir une action et d’assigner le bouton correspondant pour chaque type de contrôle.

Dans notre cas, nous voulons pouvoir utiliser la manette ou le clavier et la souris. Dans le premier cas, on vise simplement avec le joystick gauche et on se déplace avec le droit. Avec la souris et le clavier, le pointeur à l’écran sert de cible et les mouvements sont faits avec WASD.

Ce système est le plus logique pour l’utilisateur, mais est un peu compliqué à mettre en place avec l’Input System d’Unity. En effet, dans ce cas, on ne peut pas simplement définir une action de visée. Dans notre cas, nous avons été obligés de vérifier si une manette était disponible ou non et utiliser les entrées en conséquence. Il y a probablement une meilleure façon de faire, mais celle-ci marche. De même, le mouvement du joueur au clavier n’est possible que dans 8 directions, contrairement à la manette.

Le système de tir du joueur utilise les mêmes armes que celles des ennemis. La seule différence est que les balles tirées ne sont pas sur la même couche. On pourrait de ce fait imaginer un système où un ennemi pourrait faire tomber son arme en mourant, mais nous n’avions pas d’images d’arme. Un système de bonus a cependant été créé, utilisant les ScriptableObject.

Enfin, les animations des ennemis et du joueur sont réalisées de la même manière. Pour cela, on utilise le système d’animation d’Unity, mais en 2D. Le GameObject du joueur possède donc un Animator qui utilise un Animator Controller. Ce contrôleur est constitué de plusieurs animations et de transitions entre elles. Les transitions sont déclenchées depuis le script du joueur ou de l’ennemi. Il est important de noter que les images des personnages utilisent la transformation du plus proche voisin, afin de garder l’aspect pixelisé du jeu.

## GameManager

Le GameManager est la classe qui correspond au chef d'orchestre. Il donne la mesure au programme en indiquant dans quel état se trouve ce dernier. C'est pourquoi cette classe suit le DP Singelton.

Il possède une enum qui correspond à tous les états possibles du jeu et une autre qui correspond au choix fait par le joueur durant le jeu.

Il fonctionne donc comme une machine à état, il possède un event auquel les autres classes, qui ont besoin d'être mises au courant de tous les changements d'états, peuvent s'abonner et donc être notifiées du changement d'état et du nouvel état.

## Cinématique

Les cinématiques sont gérées par le CinematicManager. Chaque cinématique est faitede la façon suivante: un fichier MP4 est passé au videoClip d'un VideoPlayer, ensuite un RenderTexture est passé à la target du VideoPlayer. Pour afficher la vidéo, il suffit de passer le RenderTexture en tant qu'une Texture d'une RawImage.

Le CinematicManager possède une enum qui permet de suivre l'avancer du scénario du jeu. C'est grâce à cette enum qu'il est possible de savoir qu'elle est la cinématique suivante à afficher.