Quote:Original post by InnocuousFox OK... now we're getting somewhere! Yes, you can use A*, but some of the edges are special. For example, the edge that runs between a platform and the floor would be defined as being "jump up" or "jump down". Some enemies might be able to jump up or down (or only down). Also, you designate it as different heights of jumps so that perhaps different enemies can only jump to some places, but not others. You can also do this with two platforms where you jump over a gap. Also, some edges may be 1-way only (for example, down but not up).
By creating these nodes and edges, you are providing a framework that your enemies can use to determine how to get from one place to another via A*.
Cool, I do not have the book yet, but I saw in your index (on amazon) "Chapter 5 The Secret Life of Graphs" or "Chapter 8 Practical Path Planning" In this chapter I'll learn to do what you said? to implement and create a 2D grid on my map?
Just to make sure my thinking is not wrong when you said to create a 2D grid for my level, was similar to that? (I did a piece in photoshop just to demonstrate)
Way too much. For platforms, you would only need to have 2-3 nodes at the walkable level. Don't bother putting nodes in the air unless things are going to be flying (not jumping).
Quote:Original post by InnocuousFox Way too much. For platforms, you would only need to have 2-3 nodes at the walkable level. Don't bother putting nodes in the air unless things are going to be flying (not jumping).
Is that prent use jetpacks to enemies, so they can jump or just use the jetpack :)
Steering is nifty, but tends to be difficult to tune and can be prone to problems like getting stuck in corners. It also works best with characters that can freely accelerate in any direction (i.e. aren't constrained by walking animations). It also can't handle problems like local minima - it's more a solution for local obstacle avoidance than for path planning.
A hand-built navigation graph is probably the simplest and quickest to get up and running. If it meets your needs, it might be the way to go. With that said, it can result in funny looking paths.
A navmesh is by far the most robust solution, but generating the graph can be tricky to code.
A simple tile-based (i.e. laying a grid of tiles over your map) approach has many of the advantages of a navgraph, but is much simpler to implement. The downside is that if you need too many tiles it can be too expensive in terms of memory usage. Depends a bit on how big your map is, and how big your tiles can be and still adequately represent the space.
I thought to create waypoints and thereby create a 2D graph of the entire map for the bots will / can use jetpacks.
What about the dynamic objects that prent put on the map (such as crates and barrels) I thought about doing checks the mesh of the object with the graph, ie, if the waypoint between A and B is a box will cause the algorithm bot who choose another point (in case C), so instead of going from A to B, going from A to C.
But my doubt is whether the checking of objects will hinder performance
