Catégories
Tower Defense Pixel Unity

Tower Defense Pixel /log3

image

Voici le résultat de ce week-end, productif cette fois-ci. Pas de détails sur le processus, j’ai beaucoup de mal à faire les deux, ce sera juste un résumé.

J’ai donc travaillé sur l’éditeur de carte. Après avoir créé des belles cases sur MagicaVoxel, j’ai mis en place la gestion d’une carte. Le manager stock les données de la carte bien sûr, instancie les Prefabs qu’il faut au bon endroit. Il est aussi possible de modifier une case.

Autour de ça, le premier outils d’édition, une sorte de crayon à terrain. Et également la possibilité de sauvegarder et de charger une carte. On va donc pouvoir commencer à mieux tester le gameplay.

Après tout ça un coup de re-factorisation sera peut-être de mise. Aussi il faut maintenant ajouter les bâtiments dans l’edition et la gestion des cases adjacentes.

Voici quelques preview des différentes case, réalisées avec MagicaVoxel. Bonne semaine, et j’espère au week-end prochain !

image
image
image
Catégories
Tower Defense Pixel Unity

Tower Defense Pixel /log2

Aujourd’hui, comme dit dans le précédent billet, je m’attaque au terrain. Les joueurs vont avoir besoin de placer leurs tours, murs et autres bâtiments pendant la partie. Il faut donc que le NavMesh se mette à jour en temps réel. Heureusement Unity Technologies propose maintenant des NavMeshComponents qui permettent cela. L’ayant déjà testé je sais que j’aurais à faire face à un petit détail non-bloquant au début. Lorsqu’un build est fait durant le jeu, tout les agents marquent un court arrêt. Cela se comprend mais si à chaque fois qu’un joueur pose un bâtiment les unités s’arrêtent, le gameplay risque d’être frustrant.

Avant de partir dans le développement, un petit rappel de l’objectif :

  • La carte est une grille de cases carrées
  • Il y a plusieurs types de terrain. Par dessus desquels il sera possible ou non de construire un bâtiment. La terraformation n’est pas prévue, mais les cases type forêt on des chances de ce voir transformée en plaine lors d’une construction. A voir donc…
  • Le terrain et les bâtiments affectent le path finding

Pour les différents types de terrain j’ai en tête un jeu de mon enfance orienté stratégie. Il s’agit de Advance Wars. Comme j’ai besoin de murs je vais chercher les sprite du second opus qui en possédait. Ci dessous donc tout les types dont nous allons avoir besoins, et même plus.

image

Pour commencer simplement je vais m’occuper des types principaux :

  1. Plaine (Case neutre)
  2. Forêt (Déplacement plus lent)
  3. Montagne (Déplacement très lent, pour l’instant)
  4. Mer (Déplacement impossible, pour l’instant)
  5. Route (Déplacement plus rapide)

Je vais partir sur une solution simple, mais peut-être pas la plus optimisée dans un premier temps. Je vais faire une série de prefabs qui représenteront chaque case, et qui comporteront un component NavMeshModifier.

image

Lors de la configuration, il est apparu que le système de NavMesh proposé risque de ne pas être complètement adapté à ce cas. En effet il y aura plusieurs types d’unités, qui réagiront différemment selon le terrain. Il faudra donc certainement dupliquer les Areas pour chaque type d’unité, mais pour l’instant ça ne gène pas.

Il est temps de créer une petite carte pour tester les réactions des unités. Sans éditeur de carte c’est un peu laborieux, il faudra rapidement en créer un. Mais les modificateurs fonctionnent comme prévu pour le terrain. Simplement il y a donc un modificateur de poids par case, et plus tard chaque type d’unité aura son NavMesh, cela risque d’être lourd. Aussi les montagnes sont finalement “Not Walkable” pour l’instant pour éviter que les unités se faufilent en diagonale entre deux montagnes. Je reverrais le comportement souhaité plus tard.

image

Pour faciliter la suite du développement, l’éditeur de carte sera la prochaine étape du développement. Pour simplifier les tests je reviendrais peut-être sur un format de tower defense plus classique avec d’un côté une vague ennemie, et de l’autre le joueur qui se défend en plaçant des tours.

Pour aujourd’hui ça sera malheureusement tout, je n’aurais pas plus de temps à accorder à ce développement. To be continue…

PS: Si vous avez connaissance des performances des NavMeshComponents dans ce cas, n’hésitez pas à commenter 😉

Catégories
Tower Defense Pixel Unity

Tower Defense Pixel /log1

Afin de refaire un tour dans les fonctions d’Unity et avec l’espoir de finir un prototype conséquent de gameplay, je m’attaque cette fois à une logique relativement simple, le tower defense. Parce que j’ai toujours du mal à rester simple, ce dernier contiendra du PvP, et un peu de gestion.

Le gameplay rapidement:

  • Au moins deux équipes qui s’affrontent
  • Un cycle jour/nuit. Les vagues partent à l’aube. Une vague de monstre peu démarrer durant la nuit. Durant la nuit les unités n’avancent plus (ou peut-être dans des zones particulières) et ne font que se défendre
  • Les unités ont une sorte de mana qui limite leurs actions chaque jour, et est régénéré durant la phase de sommeil nocturne. Si durant la nuit ils sont attaqués alors ils sont plus faible le lendemain. Ils peuvent se défendre sans mana mais sont moins efficace et/ou peut-être perdraient-ils de la vie.
  • Les joueurs placent leurs bâtiments et configurent leur vagues
  • Le premier à détruire le QG ennemi gagne

C’est donc parti pour ce nouveau prototype de gameplay ! Et cette fois, pour la première fois, je vous raconte comment je procède. 

Il faut bien commencer par quelque chose, c’est donc la base du gameplay qui est attaquée. On va faire un petit brouillon de la logique de base, nous aurons donc une unité simple et un quartier général (QG). Pour la logique, l’unité à sa création ( Start() ) cherchera le QG ennemi le plus proche, et cherchera à l’atteindre.

image

Ok maintenant que nous avons cette unité simple qui cherche à atteindre le quartier général ennemi, nous allons faire en sorte que chaque QG fasse apparaître des unités.

Pour travailler avec des composants de façon à séparer et réutiliser facilement les scripts, nous allons sortir dès maintenant le script de spawn du Headquarter. Ceci car nous avons prévu la possibilité de placer plusieurs points de création d’unité sur la carte. Cependant la vague sera gérée à un seul endroit, les spawn n’étant que des “slots” disponibles à chaque tick.

Le générateur d’unité va donc gérer le type d’unité qu’il peut instancier, le nombre en un tick, et la position des apparitions. On l’appellera de la façon suivante UnitSpawner.Spawn(GameObject[] unitPrefabs), et il se chargera de faire apparaître les unités correctement.

image

Maintenant que les unités cherchent et atteignent le QG ennemi, il est temps que chacun attaque et se défende. Nous allons commencer par ajouter la notion de PV aux unités et bâtiments, puis la notion d’attaque. On peut dès maintenant observer qu’il y a des propriétés communes sur les unités et les bâtiments, et tout de suite créer une class abstraite d’où les objets d’équipe hériterons.

La notion de PV est très simple pour l’instant, des points de vie maximum et courant, ainsi qu’une fonction AddDamage(float power) avec laquelle les ennemis pourront frapper.

Ensuite, je commence par l’attaque du QG. Elle est très sommaire pour l’instant. Le QG a une puissance, une cadence, une distance et un mask de tir, ainsi qu’une cible. Si il n’y a pas de cible, on en cherche une. Une fois une cible trouvée on commence une coroutine d’attaque qui cessera à la destruction de l’ennemi ou lorsque la cible sortira du rayon de tir.

image

Par simple héritage, l’attaque étant la même pour l’instant, il va être possible en déplaçant le script de coroutine dans la classe commune de rendre ces pauvres petites unités agressives. Ensuite il suffit de gérer l’arrêt des unités lorsqu’elles attaquent, et le redémarrage de leur marche une fois la cible vaincue.

image

Il s’agit bien d’un tower defense à la base. Il est donc temps de créer des tours ! Le code est déjà là avec les QG, il n’y a qu’a factoriser tout ça et nous aurons un début de tour rapidement.

Avec les paramètres de puissance de tir, de distance et de cadence il est déjà possible d’avoir plusieurs types de tours. Ci dessous par exemple je paramètre 3 tours : 

  1. (Cylindre) Classique / Mitrailleuse, elle tir avec une bonne cadence et fait des dégâts moyens
  2. (Cube) Laser, elle a une très grosse cadence pour une puissance et portée plus faible
  3. (Sphere) Sniper, elle a une cadence très faible mais tue presque du premier coup une unité et a une portée très large
image

Voilà qui pose une base sympatique pour ce tower defense. Dans la prochaine partie je m’attaquerais à la carte, à l’influence du terrain sur le pathfinding et au placement de tours et bâtiments par le joueur. Pour cela les NavMeshComponents feront gagner du temps avec le nouveau baking à la volée.

To be continue…