Dears,
I need your insight on an early design thinking concept for my next project.
After years thinking of it, I thought now would be the time to finally start with this.
Goal is to create a TD (tower defense) game using our favorite tool/toy.
My first challenge is finding the right/best approach and logic for pathfinding.
It’s gonna be a (half-)traditional TD. The traditional part is that it will be based on a grid/cells. On the grid, You can build towers in any free cell (or destroy them) except of course, in the cells from the static map(s) that are obviously (static) obstacles.
Obviously, the path for enemies will have to update dynamically (and seamlessly) when you place remove new dynamic obstacles (towers).
But then, of course (or I wouldn’t ask) there’s more to it:
Here are some of the identified requirements:
-
There will be more than just one instance of pathfinding. The first one is the one for the enemy (and enemy waves). It should take the shortest path at all time, both from the static and dynamically added or removed obstacles. The second is to handle the player units on the map/cells. Some towers can spawn a crowd (2 or 3) melee units that can be placed on the enemy path within a certain range from the tower/barrack.
-
Obviously, when the enemy comes in range of an allied melee unit, the melee unit will attack the enemy. The correct behavior is that (while still attemting to move towards its goal/end point) the enemy will be cought in battle. If by any chance the enemy manages to clear the allied unit (that can be seen as an obstacle I believe), it needs to resume its path towards reaching the end point.
-
Both allied and enemy units of course, need to be able to collide with obstacles when either resuming their path (in the case of enemies) or when setting a new origin spawn point (for allied units).
So, I visited a fair a number of links and solutions and it looks like they really all have their pros and cons. Reason why I’m seeking your expertise. Any thoughts, advise, example, PG or tutorial would be welcomed and highly appreciated.
Some other aspects to consider:
-
despite the fact that it is based on a grid/cells and will most likely use a static view camera (isometric-like), the map will still be 3D (with some heights like bridges or small hillsides). Means the path will in fine be 3D. In fine, because to move on the grid/cells, the height coordinates might not be absolutely necessary (so I thought, correct?). May be using a 2D version and handling just the animations from the ground/height map/collision would be an option?
-
last but not least, although I’m just working on a pilot (and at a very early stage), the goal is indeed to have a number of maps. Means the solution (or mix of solutions) needs to be kinda easy to manage. I will likely want to actually create a map editor and will want to be able to test and visualize the different scenarios.
So, yes, given all the above… what should I do? use the provided with BJS? use external? 2D or 3D? use webworkers? what type of grid? use the 2D GUI texture or use coordinates?
Here are some of the references I found in my research:
From the crowd navmesh of BJS:
From external, suggested by @codingcrusader (seems interesting to me, but how to implement?)
https://qiao.github.io/PathFinding.js/visual/
Lots of doubts and questions at this very early stage. I’m also a total noob for this thingy. I need your help and invaluable knowledge to orientate me and guide me towards the first steps (or this game thingy will never see the daylight of the public Internet). In particular if you Guys have a minute, I’m thinking of @cedric, @Joe_Kerr and of course as always when it comes to complex things and a creative mind @CodingCrusader
EDIT: Forgot to mention (if it’s not yet already clear from the text above ): It’s really just if you have time and feel like it There’s no urgency. I’m gonna continue my research and also have tons of other aspects to figure at this very early stage