Hey there, I am wondering how non-assessable nodes are identified using A* in a non-tiled game.
I plan to blit the sprite and hitTest her against a single bitmapData image in the background to keep her from going out of bounds.
I thought about removing the mouse listener when the mouse is over the blocked area but how to let the A* system know there is something in the way and it can't test a node?
I'd really appreciate knowing what you think if you know about this!
A* in a non-tiled game ( AS3 )
Do you already have a data structure and A* implementation, or are you starting from scratch?
Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]
Right now my A* implementation is adapted from Keith Peters' Advanced ActionScript 3.0 Animation . His walkable tiles are randomly distributed. I want to keep trying at getting an A* class that is consolidated. He has classes for AStar, Node, and Grid plus the main class. I just want AStar and the main class like other people have it, but I don't have the understanding of how to consolidate these classes. I tried.
By data structure do you mean something like this to designate walkable nodes? (from Advanced Game Design with Flash by Rex Van Der Spuy:
No, I do not have this. And this scares me because my 640 x 480 stage isn't neatly sectioned into 32 pixel squares so my squares must be smaller, like half that, which is still too big for precision! but any smaller and processing time will be dreadful... can you imagine the grids? and for the areas in the game that are really huge maps that move while the player is centered in the stage... oh man
I would keep data like this in a separate class for just resources but if there was a way to generate that data with wondrous application somebody wrote that would be good. I'm still super intimidated.
By data structure do you mean something like this to designate walkable nodes? (from Advanced Game Design with Flash by Rex Van Der Spuy:
private const FLOOR:uint = 10;
private const FAIRY:uint = 01;
private var _mazeMap:Array
= [
[00,00,00,00,00,00,00,00,00,00,00,00,00],
[00,10,10,10,10,10,10,10,10,00,00,10,00],
[00,10,00,10,00,00,10,00,10,10,10,10,00],
[00,10,00,10,10,10,10,10,00,00,10,00,00],
[00,10,10,10,00,10,00,10,10,10,10,10,00],
[00,10,00,10,00,10,00,10,00,10,00,10,00],
[00,10,10,10,00,10,00,00,00,10,00,10,00],
[00,10,00,00,00,10,10,10,10,10,00,10,00],
[00,10,10,10,10,10,00,00,10,00,10,10,00],
[00,10,00,10,00,10,10,00,10,10,10,00,00],
[00,10,10,10,00,00,10,10,10,00,10,10,00],
[00,00,00,00,00,00,00,00,00,00,00,00,00]
];
No, I do not have this. And this scares me because my 640 x 480 stage isn't neatly sectioned into 32 pixel squares so my squares must be smaller, like half that, which is still too big for precision! but any smaller and processing time will be dreadful... can you imagine the grids? and for the areas in the game that are really huge maps that move while the player is centered in the stage... oh man
I would keep data like this in a separate class for just resources but if there was a way to generate that data with wondrous application somebody wrote that would be good. I'm still super intimidated.
Alright, maybe we need to back up a bit.
Can you describe your game and what purpose you will be using A* for? Is your map mostly open with relatively few blocked spaces, or is it more like a maze with a lot of blocked areas and relatively few pathable regions? Are blocked regions likely to be large and interconnected, as in maze walls, or more like randomly scattered obstacles? The more detail you can provide the better.
Can you describe your game and what purpose you will be using A* for? Is your map mostly open with relatively few blocked spaces, or is it more like a maze with a lot of blocked areas and relatively few pathable regions? Are blocked regions likely to be large and interconnected, as in maze walls, or more like randomly scattered obstacles? The more detail you can provide the better.
Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]
Hey ApochPiQ, I'm gonna get back to you with more detailed information and some pictures that show the kind of areas I'm working with. I also am going to try to distill the example of A* that is in Van Der Spuy's book... I pulled the classes from the reverse domain folder and so now I have his example working in Flash. Give me some time and check back, that would be awesome. Big huge thanks, BlueGrouse :-)
. . . might take a little while . . . trying to detach the fundamentals which are intertwined in a model-view-controller pattern.
. . . might take a little while . . . trying to detach the fundamentals which are intertwined in a model-view-controller pattern.
i don't think you know what nodes are(at least i had that problem when i first looked at a*). A* isn't primarilly for traversing a grid, but a graph(Something a bit like waypoints, i think this is a nice explanation). So the question how to make a node notwalkable may sound strange to some because the node just wouldn't exist. But to make a tile/node in a grid notwalkable you just make the cost to travel through it very high, in your example 10.
"I would keep data like this in a separate class for just resources but if there was a way to generate that data with wondrous application somebody wrote that would be good."
There really isn't. You have to adapt to the method you're using, if you use a grid make the levels fit your grid.
But another question is if you really need A*, if your enemies aren't too complex and don't have much range and your levels aren't that complex(are not mazelike) you could get away with a much simpler solution, e.g. go in a straight line, if you hit something walk along the border until you can go straight again. Pathfinding is of course much nicer but some of the times it's really not that important.
"I would keep data like this in a separate class for just resources but if there was a way to generate that data with wondrous application somebody wrote that would be good."
There really isn't. You have to adapt to the method you're using, if you use a grid make the levels fit your grid.
But another question is if you really need A*, if your enemies aren't too complex and don't have much range and your levels aren't that complex(are not mazelike) you could get away with a much simpler solution, e.g. go in a straight line, if you hit something walk along the border until you can go straight again. Pathfinding is of course much nicer but some of the times it's really not that important.
There are plenty of sources available for how to automatically create a waypoint map (or grid for that matter) based on a map.
As has been said, though, if your map is sparse and the movement doesn't need long, complex pathing, then local steering might be your best bet.
As has been said, though, if your map is sparse and the movement doesn't need long, complex pathing, then local steering might be your best bet.
Dave Mark - President and Lead Designer of Intrinsic Algorithm LLC
Professional consultant on game AI, mathematical modeling, simulation modeling
Co-founder and 10 year advisor of the GDC AI Summit
Author of the book, Behavioral Mathematics for Game AI
Blogs I write:
IA News - What's happening at IA | IA on AI - AI news and notes | Post-Play'em - Observations on AI of games I play
"Reducing the world to mathematical equations!"
Hey, Thank you for the further explanation. I'm going to read the information at that link and I'm also going to read up local steering.
I was going to reply here because I said I would but I haven't got my A* example properly simplified to fit my situation even.
I'm really glad to have some clues because things have gotten pretty depressing for the blueGrouse.
I was going to reply here because I said I would but I haven't got my A* example properly simplified to fit my situation even.
I'm really glad to have some clues because things have gotten pretty depressing for the blueGrouse.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement