I am working on Unity, using C# for a project that should be quite simple.
I am stuck to pathFinding .
I have Looked at Dikjstra's and A* for reference, but for some reason I still can't adopt them to work in my case. I guess my brain :=while(1);
Here is the Idea:
From a textfile I import a "map" where each "*" means Wall, and each " " walkarea. In the map there area randomly placed 2 objects: a bomb and an agent.
The agent must investigate the map (which forms a maze) and discover the bomb. The agent may move to his 8 neighbour tiles if they are NOT Wall. In my code , the agent class hold his own map. for every tile that he visits, he asks the "world map" for info, about his 8 neighbour tiles.
On his own map then he takes a note of the known tiles type(wall / walkpath) , and if it is a walkpath, he also notes, how many times he has visited it. The agent also has a "Prefered direction " list. This tells which tile to choose next to move to, if more than 1 have not been visited.
Up to this point, I have set it up all good and running, and if I let it run, he eventually finds the bomb. The Issue is that because he only runs on a Prefered direction according to the least visited tile , he has to re-visit some tiles too many times like a moron. So what
I must do is this:
If the agent reaches a tile for which, every nighbour is either wall or already visited, then he should investigate his own map, and the notes from the past to find an unvisited tile , and walk to there. Every walk direction has the same weight/cost, so we don't need to consider cost of path.
In my opinion, Dijkstra's is the closest to apply , but I still can't get it right .
Any Ideas or help would be much appreciated.
Thank You
Alex
Part of the issue is how much information you want to allow your agent. If you're willing to let him know where the target is, or at least its general direction in relation to himself, then you can use that to help influence the agent's decisions. This would allow you him to always favor moving in the direction that gets him closest to the goal while taking the least visited path.
Otherwise I'd keep track of each place he visited in a separate map, as well as the 8 neighboring tiles since he has "seen" them, with something like -1 indicating a wall that has been seen, -2 indicating an unseen location, and 0 indicating seen but unvisited. I'd then use A* or a variant on it that would move him to the closest unvisited point based on number of tiles traversed, breaking ties randomly. This would lead to a more trial and error rat in a maze approach.
Related
I want to find a way to check if points(vectors) in my scene are contained within a SCNBox I have displayed on screen. Currently I have an array of about 83000 SCNVector3's. So far, I do this by simply running a for loop on each point and checking against the SCNBox bounding box. If it falls within that bounding box I save the point to a separate array. My goal however is not 1 bounding box. I further subdivide the bounding box into equal sections. For each of those I then have to check each individual point again to see if they fall into each one of those individual bounding boxes. If they do, I save those boxes so that when I go to subdivide them again, I am not subdividing boxes that contain no points. This helps performance a little bit as large sections of boxes that don't have points are not needlessly checked. This works okay for a small amount of boxes however I need to subdivide the boxes into much larger amounts, sometimes in the hundreds to thousands of boxes. As you can imagine, it takes a long time to check all the boxes. Currently I am having to iterate through all the points every time for each box. Is there a faster approach to this?
Your question says is there a better way, so using the physics engine would be a more 'standard' approach IMO, but performance wise I wouldn't know without trying it myself. It seems you either check manually, or let the physics engine check it for you.
Try this post - it's similar and there are some examples. [67575481].
The physics engine checks nodes for nodes and it may have changed since I did this, but I had to generate node names for my nodes and check it that way. There may be other options now.
My example is a moving 'missile' that collides with a moving node containing 'some monster', so I wasn't dealing with the size you are.
83000 vectors, dunno, that seems like a lot. You'll still have to do the checks you do now, just differently.
Hope that helps...
I'm trying to make a simplified version of crazy taxi . For the first step i need to make an infinite ground . I'VE searched online but couldn't find any examples .
Can i find any example of how to do this ?
https://www.youtube.com/watch?v=rhTPxrJICVg&list=PLLH3mUGkfFCXQcNBz_FZDpqJfQlupTznd
N3K makes an infinite runner in Subway Surfers style, meaning ground coming from the back and going towards the camera.
The above link is to his tutorial series.
This is a very broad question I try to give a very simplified answer to get you going.
To create endless road you need some sort of procedural function that generates corners for your track. If you do not need to backtrack you can cook something up yourself like (in X distance turn X degrees to the right). If you do need to backtrack you need something like perlin/simplex noise that always generates the same value based on 1 or more other values. You could use total distance to get the curve in the road.
You simply keep generating the world on the fly and unload pieces of the world you don't need any more. If the player can alter the world like destroying street furniture or leaving skitmarks you need to implement a chunk system. When you backtrack and generate a cerain part of the world with your procedural function you can have permanent changes the player made in that specific part by saving and loading to the chunk. Much like Minecraft does it actually.
I am developing (or atleast trying to develop)
a decently big real time tactics game (something similar to RTS) using SpriteKit.
I am using GamePlay kit for pathfinding.
Initially I used SKActions to move the sprites within the Path but fast enough I realized that it was a big mistake.
Then I tried to implement it with GKAgents (this is my current state)
I feel that GKAgents are very raw and premature also they are following some strange Newton Law #1 that makes them to move forever (I can't think of any scenario where it would be useful - maybe for presentations at WWDC)
as well as I see that they have some Angular speed to perform rotations
which I don't need at all and can't really find how to disable it...
As well as GKBehaviors given a GKGoals seems to make some weird thing...
Setting behavior to avoid obstacles makes my units to joggle around them...
Setting behavior with follow path goal completely ignores everything unless the maxPredictionTime is low enough...
I am not even willing to tell what happens when I combine both them.
I feel broken...
I feel like I have 2 options now:
1) to struggle more with those agents and trying to make them behave as I wish
2) To roll all the movement on my own with help by GKObstacleGraph and a path Finding (which is buggy as well I have to say at some points the path to the point will generate the most awful path like "go touch that obstacle then reverse touch that one then go to the actual point (which from the beginning could be achieved by a straight line)").
Question is:
What would be the best out of those options ?
One of the best ways (in SpriteKit/GameplayKit) to get the kind of behavior you're after is to recognize that path planning and path following need not be the same operation. GameplayKit provides tools for both — GKObstacleGraph is good for planning and GKAgent is good for following a planned path — and they work best when you combine the strengths of each.
(It can be a bit misleading that GKAgent provides obstacle avoidance; don't think of this in the same way as finding a route around obstacles, more like reacting to sudden obstacles in your way.)
To put it another way, GKObstacleGraph and GKAgent are like the difference between navigating with a map and safely driving a car. The former is where you decide to take CA-85 and US-101 instead of I-280. (And maybe reevaluate your decision once in awhile — say, to pick a different set of roads around a traffic jam.) The latter is where you, continuously moment-to-moment, change lanes, avoid potholes, pass slower vehicles, slow down for heavy traffic, etc.
In Apple's DemoBots sample code, they break this out into two steps:
Use GKObstacleGraph to do high level path planning. That is, when the bad guys are "here" and the hero is "way over there", and there are some walls in between, select a series of waypoints that roughly approximates a route from here to there.
Use GKAgent behaviors to make the character roughly follow that path while also reacting to other factors (like making the bad guys not step on each other and giving them vaguely realistic movement curves instead of simply following the lines between waypoints).
You can find most of the relevant stuff behind this in TaskBotBehavior.swift in that sample code — start from addGoalsToFollowPath and look at both the places that gets called and the calls it makes.
As for the "moving forever" and "angular speed" issues...
The agent simulation is a weird mix of a motivation analogy (i.e. the agent does what's needed to move it toward where it "wants" within constraints) and a physics system (i.e. those movements are modeled like forces/impulses). If you take away an agent's goals, it doesn't know that it needs to stop — instead, you need to give it a goal of stopping. (That is, a movement speed goal of zero.) There might be a better model than what Apple's chosen here — file bugs if you have suggestions for design improvements.
Angular speed is trickier. The notion of agents' intrinsic physical constraints being sort of analogous to, say, vehicles on land or boats at sea is pretty well baked into the system. It can't really handle things like space fighters that have to reorient to vector their thrust, or walking creatures that can just as happily walk sideways or backwards as forward — at least, not on its own. You can get some mileage toward changing the "feel" of agent movement with the maxAcceleration property, but you're limited by the fact that said property covers both linear and angular acceleration.
Remember, though, that the interface between what the agent system "wants" and what "actually happens" in your game world is under your control. The easiest way to implement GKAgentDelegate is to just sync the velocity and position properties of the agent and the sprite that it represents. However, you don't have to do it that way — you could calculate a different force/impulse and apply it to your sprite.
I can't comment yet so I post as an answer. I faced the same problem recently: agent wiggling around the target or the agent that keeps moving even if you remove the behavior. Then I realized that the behavior is just the algorithm controling the movement, but you can still access and set the agent's speed, position and angle by hand.
In my case, I have a critter entity that chases for food in the scene. When it makes contact with the food agent, the food entity is removed. I tried many things to make the critter stop after eating the food (it would keep going in a straight line). And all I had to do was to set its speed to 0. That is because the behavior will influence not the position directly, but the speed/angle combination instead (from what I understand). When there is no goal for the entity, it doesn't "want" to change it's state, so whatever speed and direction it reached, it will keep. It will simply not update/change it. So unless you create a goal to make it want to stop, it will wiggle/keep going. The easy way is to set the behavior to nil and set the speed to 0 yourself.
If the behavior/goal system doesn't do it for the type of animation you are looking for, you can still use the Agent system and customize the movement with the AgenDelegate protocol and the update method and make it interact with other agents later on. You can even synchronize the agent with a node that is moved with the physics engine or with actions (or any other way).
I think the agent system is nice to keep around since you can use it later, even if it's only for special effects. But just as mixing actions and physics can give some weird results, mixing goal/behaviors and any other "automated" tool will probably result in an erratic behavior.
You can also use the agent system for other stuff than moving an actual sprite around. For example, you could use an agent to act as a "target seeker" to simulate reaction time for your enemies. The agent moves around the scene and finds other agents, when it makes contact with a suitable target, the enemy entity would attack it (random idea).
It's not a "one size fits all" solution, but it's a very nice tool to have.
I have the following problem and I am a bit clueless how to tackle it as my programming skills are very elementary ( I am an engineer, so please dont bite my head off).
Problem
I have a point cloud, the picture above displaying one level off it. Every point is a centroid off a block (x =5, y=1, z=5) and is specefied by carteisian coordinates.
The centroids further have two values: one called "access" and one "product". If the product value is positive and pays for the access to the point I want to include it in my outcome. The red marker in the picture represents a possible starting point.
Starting Idea
As a start I am trying to set up an algorithm, that starts at the red marker, runs through the blocks left and right (along the x-axis), checks until where it would be feasible to access (so sum "product" > sum "access") and then goes to the next point (in y direction from marker) and does the same until the end of the level.
Final Goal
My final goal is that I can Flag points as accessed and the algorithm connects profitable "products" (so products that would pay for their access) on the shortest way to the access point (by setting blocks/points on the way to accessed).
I know this is a very open question and I apologize for that. I am just lacking a good starting point programming wise. I was thinking of knnsearch, but I am not sure if this is the right way to go as the blocks have different sizes and i technically want the nearest neighbour in every direction but also only one per direction.
Another idea I had was using shortestpath or creating a travel salesman problem out of it, but I am not sure how to properly implement it.
If you have any ideas or you could offer any help I would very much appreciate it. If any more information is needed I gladly provide it.
I am trying to create a Pacman AI for the iPhone, not the Ghost AI, but Pacman himself. I am using A* for pathfinding and I have a very simple app up and running which calculates the shortest path between 2 tiles on the game board avoiding walls.
So running 1 function to calculate a path between 2 points is easy. Once the function reaches the goalNode I can traverse the path backwards via each tiles 'parentNode' property and create the animations needed. But in the actual game, the state is constantly changing and thus the path and animations will have to too. I am new to game programming so I'm not really sure the best way to implement this.
Should I create a NSOperation that runs in the background and constantly calculates a goalNode and the best path to it given the current state of the game? This thread will also have to notify the main thread at certain points and give it information. The question is what?
At what points should I notify the main thread?
What data should I notify the main thread with?
...or am I way off all together?
Any guidance is much appreciated.
What I would suggest for a pacman AI is that you use a flood fill algorithm to calculate the shortest path and total distance to EVERY tile on the grid. This is a much simpler algorithm than A*, and actually has a better worst case than A* anyway, meaning that if you can afford A* every frame, you can afford a flood fill.
To explain the performance comparison in a in a little bit more detail, imagine the worst case in A*: due to dead ends you end up having to explore every tile on the grid before you reach your final destination. This theoretical case is possible if you have a lot of dead ends on the board, but unlikely in most real world pacman boards. The worst case for a flood fill is the same as the best case, you visit every tile on the map exactly once. The difference is that the iterative step is simpler for a flood fill than it is for an A* iteration (no heuristic, no node heap, etc), so visiting every node is faster with flood fill than with A*.
The implementation is pretty simple. If you imagine the grid as a graph, with each tile being a node and each edge with no wall between neighboring tiles as being an edge in the graph, you simply do a breadth first traversal of the graph, keeping track of which node you came from and how many nodes you've explored to get there. You mark a node as visited when you visit it, and never visit a node twice.
Here's some pseudo code to get you started:
openlist = [ start_node ]
do
node = openlist.remove_first()
for each edge in node.edges
child = node.follow_edge(edge)
if not child.has_been_visited
child.has_been_visited = true
child.cost = node.cost + 1
child.previous = node
openlist.add(child)
while openlist is not empty
To figure out how to get pacman to move somewhere, you start with the node you want and follow the .previous pointers all the way back to the start, and then reverse the list.
The nice thing about this is that you can make constant time queries about the cost to reach any tile on the map. For example, you can loop over each of the power pellets and calculate which one is closest, and how to get there.
You can even use this for the ghosts to know the fastest way to get back to pacman when they're in "attack" mode!
You might also consider flood fills from each of the ghosts, storing in each tile how far away the nearest ghost is. You could limit the maximum distance you explore, not adding nodes to the open list if they are greater than some maximum cost (8 squares?). Then, if you DID do A* later, you could bias the costs for each tile based on how close the ghosts are. But that's getting a little beyond what you were asking in the question.
It should be fast enough that you can do it inline every frame, or multithread it if you wish. I would recommend just doing it in your main game simulation thread (note, not the UI thread) for simplicity's sake, since it really should be pretty fast when all is said and done.
One performance tip: Rather than going through and clearing the "has_been_visited" flag every frame, you can simply have a search counter that you increment each frame. Something like so:
openlist = [ start_node ]
do
node = openlist.remove_first()
for each edge in node.edges
child = node.follow_edge(edge)
if child.last_search_visit != FRAME_NUMBER
child.last_search_visit = FRAME_NUMBER
child.cost = node.cost + 1
child.previous = node
openlist.add(child)
while openlist is not empty
And then you just increment FRAME_NUMBER every frame.
Good luck!
Slightly unrelated, but have you seen the ASIPathFinder framework? Might help if you have more advanced pathfinding needs.
I would recommend just pre-computing the distance between all pairs of points in the map. This takes n^2/2 space where there are n traversable points in the map. According to this link there are 240 pellets on the board which means there are about 57k combinations of points that you could query distances between. This is pretty small, and can be compressed (see here) to take less space.
Then, at run time you don't have to do any real computation except look at your possible moves and the distance to reach that location.