Live data from Hacker News

A* tricks for videogame path finding

timmastny.com

91–100 of 108 posts

Re: A* tricks for videogame path finding

#91
post #87

Earlier quoted context omitted.

A tuple vector with row and column offset, your third option here, which happen to have symbol names of N, S, E, and W.

Thanks for replying. Maybe I just have a dumb bug in my logic and should take another crack at it.

I know I had issues keeping track of how many steps I’d taken, but making sure I was generating a good set of neighbours helped with that.

Otherwise it was just making sure I got the rules right, like all AoC problems, and testing different cases to make sure my solution did the right thing.

Re: A* tricks for videogame path finding

#92
post #62
post #29

Earlier quoted context omitted.

This is one of the main issues in attempting to build a game like the Total War series. When you start getting into 10,000 unit formations that need to pivot or strafe, while moving around or through other unit groups and obstacles, A* starts being rather challenging. Trying to get 100,000 horses to ford a river reasonably when there's only a relatively small zone of safety can be tough to program. Also, mipmaps towa…

Isn’t the standard solution there to pick one of the horses to do the full path while telling the others “try to move along this path, if not possible then as close as possible, otherwise in the average direction of this group of horses” or something similar?

Yeah, I'd imagine you'd always split this into two separate problems of pathfinding and crowd simulation. Making thousands of separate calls to a pathfinding algorithm that returns the same path (or very close to it) would be mayhem for a game like Total War. Would be super interesting to read through some of the original source for that from Total War.

Short video on a basic sort of crowd simulation would work in Unity: https://learn.unity.com/tutorial/moving-as-one

Re: A* tricks for videogame path finding

#93
post #64

Some tricks I used for A* in a production MMO: 1. Hierarchical graphs: city-level, inter-room in building, intra-room. Allows for navigation from any point in any room in any building in any city to any other point in a fraction of a millisecond. 2. Store metadata about the current a* search in the graph nodes themselves so you don't have to maintain in a separate associative array. 3. Don't follow the resulting path…

Im working on a city builder[0] where you can see inside homes. Expanding on point 1... 1. The streets have their own graph, as does each individual building. There's an address book; each building stores the driveway tile connecting to the street graph here. 2. Pathing inside homes uses A*. In order to make this extra fast, I bake the 8-directional egress weights for each tile in the building/yard. 2b. This gets con…

Just wanted to say, love the art style and the mechanics. Will be following!

Re: A* tricks for videogame path finding

#94
One "simple" trick here also is to consider putting at least some of your pathfinder calculations outside of the core game thread.

If you take some time to snapshot the map state (ideally a nearly static grid like this) and throw it into another thread, you can free up your core game loop to work on other things. Once the path is done, deliver it to what asked for it asynchronously for use on the next update.

Alternately, limit the number of nodes explored per tick at a time. The path will eventually be found without hurting your frame rate as much.

Re: A* tricks for videogame path finding

#95
post #64

Some tricks I used for A* in a production MMO: 1. Hierarchical graphs: city-level, inter-room in building, intra-room. Allows for navigation from any point in any room in any building in any city to any other point in a fraction of a millisecond. 2. Store metadata about the current a* search in the graph nodes themselves so you don't have to maintain in a separate associative array. 3. Don't follow the resulting path…

Im working on a city builder[0] where you can see inside homes. Expanding on point 1... 1. The streets have their own graph, as does each individual building. There's an address book; each building stores the driveway tile connecting to the street graph here. 2. Pathing inside homes uses A*. In order to make this extra fast, I bake the 8-directional egress weights for each tile in the building/yard. 2b. This gets con…

Have you considered making video dev logs? That’s very well thought out, and I love the art style!

Re: A* tricks for videogame path finding

#96

Some tricks I used for A* in a production MMO: 1. Hierarchical graphs: city-level, inter-room in building, intra-room. Allows for navigation from any point in any room in any building in any city to any other point in a fraction of a millisecond. 2. Store metadata about the current a* search in the graph nodes themselves so you don't have to maintain in a separate associative array. 3. Don't follow the resulting path…

3. Also allows for "characters" one driving extremely risqué, or completely over the top, other steering safe and boring. Univwrsal Optimal behavior is boring..

Re: A* tricks for videogame path finding

#97
post #20

Earlier quoted context omitted.

> Hierarchical graphs: city-level, inter-room in building, intra-room. Handmade? It's always annoying to me when you have a small NP-hard problem (graph partitioning is definitely a recurring one for me) and you want to just throw some box algorithm at it without having to shop around for a library that you have to learn. I remember there was a while in college where I didn't understand why A* in an RTS would be such…

I don’t know about C&C but in StarCraft units are constantly walking into each other, getting temporarily hung up and stuck a bit. If they were constantly re-pathing around each other though you would certainly also run into issues too. Why shouldn’t the units use the information they have about the current destination and path of the other allied units instead of just constantly seeing them as moving obstacles.

It would be also mercilessly exploited if the patching would reveal defense buildings blocking a way..

Re: A* tricks for videogame path finding

#98
post #20

Earlier quoted context omitted.

> Hierarchical graphs: city-level, inter-room in building, intra-room. Handmade? It's always annoying to me when you have a small NP-hard problem (graph partitioning is definitely a recurring one for me) and you want to just throw some box algorithm at it without having to shop around for a library that you have to learn. I remember there was a while in college where I didn't understand why A* in an RTS would be such…

Handmade, but trivial to build - I made a tool so the guys in the world editor could just click anywhere to drop a path node and the tool would automatically link path nodes and prune redundant edges from the graph. Took a few minutes to do a whole city. Building graphs were mostly autogenerated from the navigation mesh and labeled "door" objects, with optional manually placed nodes when the room geometry was weird.

I once hacked in an A* implementation into Jedi Knight: Dark Force II. The in built AI in the game was very primitive (as most AI was at the time) but cog language provided me a way to work around it.

I initially used hand placed objects for the path nodes but I was experimenting with having the game rain down falling objects and keeping track of where they hit the ground to create a set of path nodes automatically. At first I was just going to look for negative space with a cog verb and set the nodes just above, but this doesn't catch walkable surfaces that are 3D objects instead of level surfaces. I then had to rain a node down from the stop point to get walkable areas beneath them.

There were still entity specific concerns that were not fully worked out. Entities had different sizes so could fit in different spaces. I had accounted for crouching and set the nodes to be more expensive when that was required as the entity moved slower. I had max jump distance somehow factored in and just had enemies detect a pit dynamically and jump when needed, although this made it easy for me as a player to block their landing site and force them into a pit.

Doors were interesting too, I never really solved that. My idea was to have a second metadata factor beyond node distance that would make paths through doors very expensive when they were closed so the entities would find away around if possible but hang out at the door if they weren't. You'd still need the door to manually communicate with the nodes since some doors are lockable but many just open automatically so are not an obstacle. That required a bunch of manual work for the level designer which I didn't like.

It was a very fun set of problems to work through since the base problem is simple (in that it is solved) but there were lots of interesting edge cases that weren't. And trying to make it work in a dynamic changing environment really changes the whole problem.

Re: A* tricks for videogame path finding

#99
Aappleby's deep dive into A* pathfinding is like opening a treasure chest of game dev secrets, from using hierarchical graphs for smooth sailing across different game scales to dropping 'breadcrumbs' for dynamic path adjustments. YesBox builds on that, painting a picture of their city builder's intricate street and building pathing system, showing us how every bit (or 16-bit bitmask) counts in game design. And gkedzierski? They're soaking up these nuggets of wisdom and already dreaming up video dev logs to spread the word. It's like a masterclass in making virtual worlds come alive!

Re: A* tricks for videogame path finding

#100

I've spent a lot of time thinking about fast pathfinding in order to speed up my Scala Quoridor AI*[0], and here are some tips/tricks I've learned: - MPAA (multipath adaptive A*) is great if you need to re-search the same area multiple times as obstacles are introduced. It allows you to feed in the results of previous searches in order to speed up pathfinding. - JPS (jump point search) looks very appealing in theory…

JPS is fun; though I struggled to interpret the suggested performance gains by the authors indeed due to the calculation of the jump nodes.

Many years ago I added a visualisation to the JPS implementation of PathFinding.js to visualise this recursive search to find jump nodes - here's an online demo: https://qiao.github.io/PathFinding.js/visual/

Post reply on HN