koobas.hobune.stream
A* Simple AI help !
Hi everyone i work on a game , on this a lot of people walk from waypoint to waypoint randomly , but some time this people Collision together that is sound too bad , how can i fix it !?
Your question makes very little sense and seriously lacks more elaborate explanation.
Not that I can help with your problem really, but I think I understand the question. He has characters walking from one point to another choosing a random path and because there is no path finding as such, there is no way to detect if they will collide so they just walk through each other/into each other sometimes. What he wants to do is (I'm guessing from the title) use an A* path finding algorithm so that if a character were to be on a path to collide with another character, it would realise and change it's path.
I've not used an A* path finding algorithm myself but have seen examples and would to see how you do it if you work it out. One problem I see with this though is that A* path finding, whilst a fairly efficient way of finding a path for one object around a static map, I imagine would struggle seriously if you had "a lot of people" walking around. Because then, each character would have to recalculate it's path each frame to be certain of no collisions. You could only do it every few frames, but you may get collisions, or you could have a larger collider than the character so that it would only recalculate paths when a collision occurs.
Have you done any research into A* path finding algorithms yet? That would definitely be my recommendation of where to start (http://www.policyalmanac.org/games/aStarTutorial.htm). Which scripting language are you using? It would be very helpful if you edited you original question to include more information on what you want to do and in which language, what background you have, what research you have done and what functionality you already have in place in your project.
$$anonymous$$att
A common solution is to do a quick raycast -- maybe look 8 feet ahead of each walker, twice a second. If you see another walker, scoot sideways. If you want to get fancy, check if the other guy is to your left or right and which way they are moving, and scoot the best way (a lot more work, but short once you get it and looks really nice.)
But, yeah, confusing Q. Why is A* in the title?
I always find it a little sad when more effort is put into helping somebody than the original poster put in to asking the question.. :\
====( http://www.clothes6.us )=====
online store wholesale sneakers,Jerseys, jewelry, glasses, shirt, sports,handbags,clothes ,news, vogue,jeryse at ugg boots,luxury fashion ysl women boots, christian louboutin boots,ed hardy clothes, jordan shoes,nike shoes,hoodies,t-shirts,nfl jerseys,mlb jerseys,nhl jerseys,coach handbags,handbags,wholesale, retail, sunglasses,belts, caps, ed hardy caps,suit,fashion good,newest style goods All the products are free shipping,
====( http://www.clothes6.us )=====
free shipping
competitive price
any size available
accept the paypal
jordan shoes $32
nike shox $32
$$anonymous$$BT shoes 48
NFL jersys 24
NBA jersys 24
Timberland boots 45
Christan Audigier bikini $20
Ed Hardy Bikini $23
Smful short_t-shirt_woman $14
ed hardy short_tank_woman $15
Sandal $26
christian louboutin $60
Sunglass $14
COACH_Necklace $18
handbag $33
AF tank woman $16
====( http://www.clothes6.us )=====
I am using A* in our RPG which is tile based. Players and enemies have two gameobjects with box colliders attached. One for the current and another I use to reserve the next tile while the controller moves the player or enemy from tile to tile. When not moving this 2nd collider is hidden.
My A* implementation raycasts tile centre to tile centre at head height above the tile's floor and therefore sees these box colliders as impassible. Granted this does mean that the paths fail where two enemies walk in opposing directions but it is sufficient for m purposes and seems to scale well enough so far.
You could of course, upon collision with these box colliders during pathing attempt to negotiate with the owning enemy and naturally there may actually be a path by the time the enemy gets there, but it's reasonable to just repath later, if potentially computationally more expensive.
Hope that helps Ian H
Obviously I'd you find your entities would collide moving from tile to tile, you can halt following the path and repath from there, presu$$anonymous$$g your blockage will go eventually.
You might want to consider using behavior trees to make some of the decisions about where to path to and what waypoints to pick. Check out AngryAnt's free unity implementation at www.AngryAnt.com. And follow his links to read and watch videos about BTs on www.aigamedev.com
Generally tile-based path-finding is done entirely through your 2D array. Ins$$anonymous$$d of using a collider to claim a "move to" space, mark it as used in the array. Ins$$anonymous$$d of raycasting to check whether a path is open, use math to directly check the used variable of the squares you will move through.
@Owen Reynolds we did not use an array because our movement is tile based but our world is fully 3D so we would really need a 3D array. Players and Enemies can walk along each level but that level is not necessarily flat and indeed there could be levels above or below where the player/enemy currently stands that are largely freeform.
You could however avoid the raycasting and tile reservation colliders if you used Owen's suggested approach for a tile based game. If however your world is 3D you could still consider my tile reservation approach, but consider that your are reserving a node.
Efficient use of layers reduces the cost of raycasting and tile reservation.
It's worth noting that as @Owen Reynolds says, with a grid raycasting can be avoided. We are considering restructuring our level collision models so that we can precompute a grid for a given level. This is not trivially, but I think I have a way. For a tile based implementation, I can then precompute things like tile heights, whether a tile is open or closed, whether it is possible to pass from one tile to the next, all things I am currently computing on the fly. Naturally this also means that logic needs updating for when doors and barriers are opened/closed to make changes to the relevant map tile, or perhaps the edge. We'll then need a way for the player (or enemy) to pass from one grid to another without issue.
So if I do all of the above, there's some work to do in the editor to create these maps and some work to do allowing player's and enemies to transition from map to map and we know longer need a 3D array, more we accept that players are bound to a tile and nothing can pass above or below them unless it does so within a separate map, which would only be an issue for flying creatures, so unlikely to be an issue at all in this first pass.
This fairly considerable amount of setup means that path finding and movement will be more efficient and indeed, I wouldn't even need the player or enemies to move via a CharacterController.
It looks like there may be a masterclass on collision avoidance (which was the original topic) on aigamedev.com but you'll need a premium account to view it. I would check but I have issue logging in sometimes...
http://aigamedev.com/premium/event/session-collision-avoidance/
