A have a maze and character that's controlled by the player and a drone who has to find him (by itself). Does anyone know an (efficient) AI algorithm for doing something like this?
P.S. I know there are several path finding algorithms(e.g. A*), but as far as I know these only work for finding the path between two nodes that "don't move" (this would work if my character was standing still, but that's obviously not the case).
If the "start point" is where the drone is, and the "end point" is to run into the player, about the best you can do using just a "standard" algorithm is to use A* periodically and from that determine where the drone needs to move.
As you get closer to the player, you will be calculating faster and faster since the search space is, in theory, smaller.
Using this, it would be possible for the player to find a set of positions that, when moving between them causes the drone to get "stuck" just moving back and forth, but those sorts of optimizations are situation-specific and a general algorithm won't include them.
Essentially, you do have a fixed search space each "frame", but you just have to run it each frame to decide what to do.
There are likely tweaks to A* that cover minor perturbations between runs, but I don't know any off the top of my head.
Related
I'm a relatively inexperienced programmer, and recently I've been getting interested in making a Checkers game app for a school project. I'm not sure where I can start (or if I should even attempt) at creating this. The project I have in mind probably wouldn't involve much more than a simple AI & a multiplayer player mode.
Can anyone give some hints / guidance for me to start learning?
To some extent I agree with some of the comments on the question that suggest 'try something simpler first', but checkers is simple enough that you may be able to get a working program - and you will certainly learn useful things as you go.
My suggestion would be to divide the problem into sections and solve each one in turn. For example:
1) Board representation - perhaps use an 8x8 array to represent the board. You need to be able to fill a square with empty, white piece, black piece, white king, black king. A more efficient solution might be to have a look at 'bit-boards' in which the occupancy of the board is described by a set of 64-bit integers. You probably want to end up with functions that can load or save a board state, print or display the board, and determine what (if anything ) is at some position.
2) Move representation - find a way to calculate legal moves. Which pieces can move and where they can move to. You will need to take into account - moving off the edges of the board, blocked moves, jumps, multiple jumps, kings moving 'backwards' etc. You probably want to end up with functions that can calculate all legal moves for a piece, determine if a suggested move is legal, record a game as a series of moves, maybe interface with the end user so by mousing or entering text commands you can 'play' a game on your board. So even if you only get that far then you have a 'product' you can demonstrate and people can interact with.
3) Computer play - this is the harder part - You will need to learn about minimax, alpha-beta pruning, iterative deepening and all the associated guff that goes into computer game AI - some of it sounds harder than it actually is. You also need to develop a position evaluation algorithm that measures the value of a position so the computer can decide which is the 'best' move to make. This can be as simple as the naive assumption that taking an opponents piece is always better than not taking one, that making a king is better than not making one, or that a move that leaves you with more future moves is better than one that leaves you with less choices for your next move. In practice, even a very simple 'greedy' board evaluation can work quite well if you can look 2-3 moves ahead.
All in all though, it may be simpler to look at something a little less ambitious than checkers - Othello is possibly a good choice and it is not hard to write an Othello player that can thrash a human who hasn't played a lot of the game. 3D tic-tac-toe, or a small dots-and-boxes game might be suitable too. Games like these are simpler as there are no kings or boundaries to complicate things, all (well most) moves are legal and they are sufficiently 'fun' to play to be a worthwhile software demonstration.
First let me state, the task you are talking about is a lot larger then you think it is.
How you should do it is break it down into very small manageable pieces.
The reasons are
Smaller steps are easier to understand
Getting fast feed back will help inspire you to continue and will help you fix things as they go wrong.
As you start think of the smallest step possible of something to do. Here are some ideas of parts to start:
Make a simple title screen- Just the title and to hit a key for it to
go away.
make the UI for an empty checkerboard grid.
I know those sound like not much but those will probably take much ore time than you think.
then add thing like adding the checkers, keeping the the gameboard data etc.,
Don't even think about AI until you have a game that two players can play with no UI.
What you should do is think about: what is the smallest increment I can do and add that, add that and then think about what the next small piece is.
Trust me this is the best way about going about it. If you try to write everything at once it will never happen.
I am developing a painting application for the iOS and to get smooth lines i apply the Ramer–Douglas–Peucker algorithm of the samples points.
The algorithm works on the whole vector of points and the result changes as points are added. It causes the result curve to "jump" while user paints.
Is there a known solution to this problem?
I've never implemented or used this algorithm, but I can think of two possible solutions:
Apply the algorithm to discrete sections of the line. That is, wait until the user has drawn 10 points, then run the algorithm on points 0..9. Then wait until the user has drawn the next 10 points and run the algorithm on points 10..19, and so on. One possible caveat is that it could create side-effects at points 10, 20, etc., but I really don't know if it would be noticeable to the user.
Wait until the user is done drawing, then run the algorithm once on the whole line. I've seen this approach used in apps before.
Both of these have the advantage that you're running the algorithm on each point no more than twice (and exactly once in the latter case), whereas if you run the algorithm every time a point is added you end up running it on every previous point every time you add a point, which could have a performance penalty.
Like I said, this isn't an area of expertise for me, but I hope it gives you some ideas.
I doubt this can be avoided at all, for a simple reason: the algorithm cannot guess the future points.
Imagine that you draw the first two points; obviously you will keep them. Now move to a third point. If R-D-P tells you to discard the middle point, you may not because that would cause a jump. And so on. Disallowing the jumps implies that you disallow any deletion !
Maybe you can lessen the psychological effect by drawing both the raw curve, which remains stable, and the smoothed one.
This said, R-D-P maybe not be the best approach for smoothing.
I'm having trouble writing the pathfinding routine for the AI in a simple Elite-esque game I'm writing.
The world in this game is a handful of "systems" connected by "wormholes", and a ship can jump from the system it's in to any system it's linked to once per turn. The AI is limited to only knowing things that it should know; it doesn't know what links come from a system it hasn't been to (though it can work it out from the systems it has seen, since links are two-way). Other parts of the AI decide which system the ship needs to get to based on what goods it has in its inventory and how much it remembers things being worth on systems it has passed through.
The problem is, I don't know how to approach the problem of finding a path to the target system. I can't use A*; there's no way to determine the 'distance' to another system without pathing to it. I also need this algorithm to be efficient, since it'll need to run about 100 times every time the player takes his turn.
Does anyone know of a suitable algorithm?
I ended up implementing a bidirectional, greedy version of breadth-first search, which suits the purpose well enough. To put it simply, I just had the program look through each node its starting node connected through, then each node those nodes connected to, then each node those connected to... until the destination node was found.
Normally one would build a list of appropriate paths and pick the shortest one, but I tried a different method; I had the program run two searches in parallel, one from the starting point, and one from the end point. When the 'from' search found the last node of the 'to' search, the path was considered found.
It then optimizes the path by checking if each node on the path connects to a node further up in the path, and deleting each node in between them.
Whether or not this funky algorithm is actually any better than a straight BFS remains to be seen.
When it comess to unknown environments, I usually use an evolutionary algorithm approach. It doesn't guarantee that you'll find the best solution in the small timeframe you have, but is a way to approach such a problem.
Have a look at Partially Observable Markov Decision Problems (POMDP). You should be able to express your problem with this model.
Then you can use an algorithm that solves these problems to try to find a good solution. Note that solving POMDPs is usually very expensive and you probably have to resort to approximate methods.
Easiest way to cheat this would be o go through, or at least attempt to access as many systems as possible, then implement the distance heuristic as the sum of all the systems you've been to.
Alternatively, and way cooler:
I've implemented something similar using ACO (Ant colony optimization) and worked pretty well combined with PSO(particle swarm optimization), however, the additional constraints your system is imposing means that you'll have to spend a few (at least one) sessions figuring out the environment layout, and if it's dynamic... well... though.
The good thing is that this algorithm completely bypasses the need for heuristic generation which is what you need since you are flying blind. Be advised though, that this is a bad idea if your search space (number of runs) is small. (100 may be acceptable, but 10 or 5 ... not so much).
This scales up quite nicely when dealing with large numbers of nodes (systems) and it bypasses the heuristic distance computational need for every node-to-node relationship, thereby making it more efficient.
Good luck.
I'm trying to devise an algorithm for a robot trying to find the flag(positioned at unknown location), which is located in a world containing obstacles. Robot's mission is to capture the flag and bring it to his home base(which represents his starting position). Robot, at each step, sees only a limited neighbourhood (he does not know how the world looks in advance), but he has an unlimited memory to store already visited cells.
I'm looking for any suggestions about how to do this in an efficient manner. Especially the first part; namely getting to the flag.
A simple Breadth First Search/Depth First Search will work, albeit slowly. Be sure to prevent the bot from checking paths that have the same square multiple times, as this will cause these algorithms to run much longer in standard cases, and indefinitely in the case of the flag being unable to be reached.
A* is the more elegant approach, especially if you know the location of the flag relative to yourself. Wikipedia, as per usual, does a decent job with explaining it. The classic heuristic to use is the manning distance (number of moves assuming no obstacles) to the destination.
These algorithms are useful for the return trip - not so much the "finding the flag" part.
Edit:
These approaches involve creating objects that represents squares on your map, and creating "paths" or series of square to hit (or steps to take). Once you build a framework for representing your square, the problem of what kind of search to use becomes a much less daunting task.
This class will need to be able to get a list of adjacent squares and know if it is traversable.
Considering that you don't have all information, try just treating unexplored tiles as traversable, and recomputing if you find they aren't.
Edit:
As for seaching an unknown area for an unknown object...
You can use something like Pledge's algorithm until you've found the boundaries of your space, recording all information as you go. Then go have a look at all unseen squares using your favorite drift/pathfinding algorithm. If, at any point long the way, you see the flag, stop what you're doing and use your favorite pathfinding algorithm to go home.
Part of it will be pathfinding, for example with the A* algorithm.
Part of it will be exploring. Any cell with an unknown neighbour is worth exploring. The best cells to explore are those closest to the robot and with the largest unexplored neighbourhood.
If the robot sees through walls some exploration candidates might be inaccessible and exploration might be required even if the flag is already visible.
It may be worthwhile to reevaluate the current target every time a new cell is revealed. As long as this is only done when new cells are revealed, progress will always be made.
With a simple DFS search at least you will find the flag:)
Well, there are two parts to this.
1) Searching for the Flag
2) Returning Home
For the searching part, I would circle the home point moving outward every time I made a complete loop. This way, you can search every square and idtentify if it is a clear spot, an obstacle, map boundary or the flag. This way, you can create a map of your environment.
Once the Flag is found, you could either go back the same way, or find a more direct route. If it is more direct route, then you would have to use the map which you have created to find a direct route.
What you want is to find all minimal-spanning-tree in the viewport of the robot and then let the robot game which mst he wants to travel.
If you met an obstacle, you can go around to determine its precise dimensions, and after measuring it return to the previous course.
With no obstacles in the range of sight you can try to just head in the direction of the nearest unchecked area.
It maybe doesn't seem the fastest way but, I think, it is the good point to start.
I think the approach would be to construct the graph as the robot travels. There will be a function that will return to the robot the particular state of a grid. This is needed since the robot will not know in advance the state of the grid.
You can apply heuristics in the search so the probability of reaching the flag is increased.
As many have mentioned, A* is good for global planning if you know where you are and where your goal is. But if you don't have this global knowledge, there is a class of algorithms call "bug" algorithms that you should look into.
As for exploration, if you want to find the flag the fastest, depending on how much of the local neighborhood your bot can see, you should try to not have this neighborhood overlap. For example if your bot can see one cell around it in every direction, you should explore every third column. (columns 1, 4, 7, etc.). But if the bot can only see the cell it is currently occupying, then the most optimal thing you can do is to not go back over what you already visited.
I want to develop a ludo game which will be played by at most 4 players and at least two. One of the players will be an AI. As there is so many conditions I am not able to decide what pawn to move for the computer. I am trying my best but still to develop an efficient algorithm that can compete with human. If anybody knows the answers of any algorithm implemented in any language please let me know. Thanks.
Also if you want you can try general game playing AI algorithm, such as monte carlo tree search. Basically idea is this - you need to simulate many random games from current move and after that choose such action which guarantees best outcome statistically.
Basically, AI depends upon the type of environment.
For the LUDO, environment is stochastic.
There are multiple algorithms to decide what pawn should move next.
for these types of environment, you need to learn algorithms like, "expectimax" , "MDP" or if you wanna make it more professionally you should go for "reinforcement learning".
I think that in most computer card/board games, getting a reasonably good strategy for your AI player is better than trying to get an always-winning-top-notch algorithm. The AI player should be fun to play with.
Pretty reasonable way to do it is to collect a set of empirical rules which your AI should follow. Like 'If I got 6 on the dices I should move a pawn from Home before considering any other moves', 'If I have a chance to "eat" another player's pawn, do it', etc. Then range these rules from the most important to less important and implement them in the code. You can combine a set of rules into different strategies and try to switch them to see if AI plays better or worse.
Start with a simple heuristic - what's the total number of squares each player has to move to get all their pieces home? Now you can make a few adjustments to that heuristic - for instance, what's the additional cost of a piece in the home square? (Hint - what's the expected total of the dice rolls before the player gets a six?). Now you can further adjust the 'expected distance' of pieces from home based on how likely they are to be hit. For instance, if a piece has a 1 in 6 chance of getting hit before the player's next move, then its heuristic distance is 5/6*(current distance)+1/6*(home distance).
You should then be able to choose a move that maximizes your player's advantage (difference in heuristic) over all the opponents.