I want to try and get an AI to find a sequence of moves that wins in Marble Solitaire. I've completed the system which moves a random cylinder and also the system which undoes the previous move. All I need to do now is to work out how and when the AI undoes moves. I had no idea what to do so I sort of randomly tried things, and I had enough so I decided to ask here.
Here's the code I think you need to help me solve it - feel free to ask me for more snippets, I don't just want to overload you with meaningless code:
private int index; Increases when a move has been tried my the AI, and said move didn't work. I use it to stop the program from looping over the same move without checking others.
Below is the current code I use to determine whether the AI should undo a move or not, but it doesn't seem to work as I want:
if (possibleMove.Count < index)
{
index = 0;
undoMove();
}
else if (possibleMove.Count == 0)
{
undoMove();
} //possibleMove is a list of all possible Moves the AI has found
The code snippet above activates at the very end of findMove()
The general format of the code goes like this:
private void findEmpty()
{
findMove();
}
private void findMove()
{
makeMove();
}
private void makeMove()
{
}
private void undoMove()
{
}
Rules of Marble Solitaire
The player makes successive capturing moves, removing a single piece each turn until is it impossible to make any more capturing moves.
Each turn, the player captures a piece by jumping over that piece in any direction (not diagonally) from two spaces away a vacant point, making sure that there is a piece you can jump over.
Therefore, the first turn can be made only by jumping a piece into the middle hole from one of 4 possible points.
Image of marble solitaire:
You can do this with the BFS method of graph searching. What you can do is find a way to represent the board, it can be an array of booleans to represent marbles or gaps or anything you can think of, so long as it's easy for you to understand and manipulate.
Then you would have a queue that so far only holds the initial state of the board. You then set your current state to the first state in the queue and then remove it from the queue. You can now use findMoves(currentState) to return a list of states that you can access from this current move. Add each of those states to the end of the queue, and then once again set your current state to the first state in the queue and remove it and use findMoves repeatedly until your current state matches some sort of goal state. In your particular problem you can just run this until findMoves(currentState) returns an empty array since that would mean there are no more moves for you to be able to do.
That would get you to a solution, however it wouldn't keep track of the path for you. You can keep track of the path itself in any number of ways, for example instead of adding just the next state to the queue you can add an array of all of the states so far in that path and just use the last value when calculating the next states you can go to. But that's just an example.
Related
I am a beginner in Unity and I'm trying to make something pretty simple. However, I don't know where to start. I have a number of 'knots' in the scene, that the player will be able to select. They will then be able to connect two knots. I managed to find all knots in a range of 40 from the player's position and put them in an array. The next step would be to 'navigate' through the knots. I want the player to use the left analogue stick for that, but I don't know how to go about it. When they hold the stick at 120°, the knot closest to that position would be able to be selected by pressing another button. I looked at some UI navigation scripts, but this situation is pretty different as it's a two dimensional space. Does anyone have any suggestion on how to go about this? Thank you.
screenshot
It sounds to me like you're going to have to do some trigonometry to be able to find the nearest "knot." Each of these--at least if you're programming well--should each be an object whose x and y location variables can be accessed from your script.
You could iterate through the list of collected objects and compare them to your current location and store the object in a temporary variable if it is a shorter distance than the last object in the array.
Here's some pseudocode that should help illustrate my point:
for item in array {
Object closestKnotDist = Null
Float currentKnotDist = math.sqrt((player.x-item.x)**2 + (player.y-item.y)**2)
if currentKnotDist < closestKnotDist {
closestKnotDist = currentKnotDist
}
}
Thus, closestKnotDist will be the closest object to the player. Manipulate it how you will.
Not sure if this answered your question, but feel free to add some more explanation if not!
In one of my university courses (in Data-structures and Algorithmics), we are given a bonus assignment based on the game Sokoban:
With one Major exception: We only have one crate to push to our goal.
Example input
8 8
MMMMMMMM
M.....?M
M....TTM
M....TTM
M..!...M
M....+.M
M......M
MMMMMMMM
Here the first line gives the dimensions (b x h) of the board (8 by 8 in this case). This is followed up by h lines oh b characters. The meaning of these characters is as follows: . A walkable space, ? the goal (red point in the gif), ! the crate, and + is our position.
We are asked to output the shortest solution to the puzzle. (Note that a puzzle might be unsolveable.) We output this in 2 lines, the first tells us how many moves, and the second tells us the correct path. For the example, this would be:
Example Output
10
WWNNNWNEEE
Now, finding an algorithm that works isn't really an issue. Seeing as we're looking for the shortest path, and the nodes on this specific graph are in essence unweighted, I've implemented a breadth first search. In broad strokes, my current implementation looks like this:
0. Since the maze doesn't change, describe each state as a whole number based on the coordinates
of the crate and the player. - This defines a state uniquely and reduces memory costs.
1. Create a dictionary of visited states.
2. Get the input positions of the goal, crate and player.
3. Set up a Queue of move sequences.
4. Pop a move sequence from the Queue.
5. If this move sequence wins the game, go to step 8.
6. Make new move sequences which are copies of the original, each with a different legal move appended.
7. Append these new move sequences to the Queue.
8. Go to step 4
9. Print the output.
This is, of course a relatively simple algorithm. The problem is that it isn't fast enough. In one of the final test cases, we're thrown a 196 x 22 maze like "level" which has a solution that takes 2300 steps. We're asked to solve this level within 10 seconds, but it takes my algorithm more than 10 minutes.
Because of that, I'm kinda at a loss. I've already managed to increase the algorithm's speed 10 fold, and I still have 2 orders of magnitude to go...
Hence why I'm asking here: What makes this algorithm so slow, and how can I speed it up?
Yes, your comprehensive BFS search will be slow. You spend a large amount of your tree search in moves that are utterly wasted, your player thrashing around the maze area to no avail.
Change the focus of your goal: first, solve the maze for the crate rather than sending the player every which way. Include a heuristic for moving the crate closer to the goal spot. Make sure that the crate moves are possible: that there is a "push from " spot available for each move.
One initial heuristic is to make a maze fill by raw distance to the goal start at either the goal (what I've done here) and increment the steps through the maze, or start at the box and increment from there.
MMMMMMMM
M54321?M
M6543TTM
M7654TTM
M876567M <== crate is on the farther 6
M987678M <== player is on the nearer 7
Ma98789M
MMMMMMMM
Here, you would first try to find legal pushes to move the box along the path 654321?. You can also update this by making a penalty (moving the player without pushing) for any direction change.
These heuristics will give you a very good upper bound for a solution; you can then retrace decision points to try other paths, always keeping your "shortest solution" for any position.
Also keep track of where you've been, so that you don't waste time in position loops: never repeat a move (position and direction).
Does that help you get going?
Instead of using a pure dfs search of the player's movements, consider only the crate moves available to you at the time. For instance, in the very first frame of your gif, at the beginning of the simulation, the only crate move possible is the top one to the right one square.
An analogy would be for a game of chess on the first move, you would not consider any queen or bishop moves since they are all blocked by pawns.
After you've successfully found the sequence of crate moves leading to the solution, come back and trace the player moves necessary to construct the sequence of crate moves.
This improves time complexity because the time complexity will be based on the number of crates present in the map instead of total squares.
I made a tic tac toe A.I. Given each board state, my A.I. will return 1 exact place to move.
I also made a function that loops though all possible plays made with the A.I.
So it's a recursive function that lets the A.I. make a move for a given board, then lets the other play make all possible moves and calls the recursive function in it self with a new board for each possible move.
I do this for when the A.I goes first, and when the other one goes first... and add these together. I end up with 418 possible wins and 115 possible ties, and 0 possible loses.
But now my problem is, how do I maximize the amount of wins? I need to compare this statistic to something, but I can't figure out what to compare it to.
My feeling is that the stats you're quoting are already pretty good. Two expert Tic-Tac-Toe players will always end in a tie, and there is no way to force a win if your opponent knows how to play the game.
Update
There's probably a more elegant wayt o prove the correctness of your A.I., but the most straightforward approach would be the brute force one. Just enumerate all possible board positions as a game tree, and prune the branches that lead directly to a loss. Then for each branch in the tree you can work out the probability of win resulting from following that branch. Then you just need to test your A.I. on each board position and make sure it's picking the branch with the highest probability of a win.
You should start by observing that move 9 is always forced: there is only one empty square on the board. Move can be considered 8 forced as well, because after seven moves there could be exactly three situations:
O can win on the next move, in which case it takes the win
Placing an X in either one of the two remaining squares wins the game for X, in which case O has lost regardless of its next move
X has zero or one path to victory, in which case O blocks to force a draw
This means that the game is over after at most seven moves.
Also observe that there are only three opening moves: the center, a corner, or a side. It does not matter which of the four corners or sides you take, because the board can be rotated to match a "canonical" opening (the upper-left corner or the middle of the top side).
You can now build your state analysis code. Starting with each of the three possible openings, search with backtracking up to six additional moves using all squares that are open by the time you make the move. After each move, analyze the position to see if X or O has already won; mark wins by X as Wx, and wins by O as Wo. The remaining positions are undecided.
Do not explore positions after Wx or Wo: simply return to the prior step, reporting the win by the corresponding side.
When you reach the seventh move, statically analyze the position to decide if it is one of the three situations described above is applicable, marking the position a Wx, Wo, or a Draw.
Now to the most important step: when you backtrack to the move N-1 by the player p,
If one of the moves that you try is such that all position at the next level becomes Wp, declare the current position a Wp as well.
If all of the moves that you try lead to the win of the opponent, declare the current position a win for the opponent
Otherwise, declare the current position a Draw, and return to the prior level.
If you do this right, all three opening positions will be classified as a Draw. You should see some forcible wins after three moves.
Running this procedure classifies each position as a Wx, Wo, or a Draw. If your AI gets you a win for the player p in a position classified as Wp, or gets you a draw in a position classified as a Draw, then your AI is perfect. If, on the other hand, there are positions that are statically classified as Wp in which the AI gets p only a draw, then your AI engine needs an improvement.
Additional reading: you can find additional insights into the game in this article describing methods of counting possible games of Tic-Tac-Toe.
What you're doing is more linear optimisation than A.I... I'll not describe all the linear algebra of the Tic-Tac-Toe here, there's plenty of examples on the net.
So using linear algebra, you don't have to prove anything about your results (searching for magic statistics, etc), because your results can be validated by a simple solution-injection in the original equation.
In conclusion, there is two cases :
You're using simple "deduction" logic (which is in reality non-formal linear algebra formulation) : we can't found a ready-to-use method for checking your results without look at your code. EDIT : as Andrew Cooper suggests, brute force can be a ready to use method without seeing at your code.
You're using formal linear algebra formulation : your results can be validated by a simple solution-injection in the original equation.
The only thing you can compare is one potential move against another. Whenever it's the computer's turn to make a move, have it play out all possible games from that point on, and choose the move that leads to the highest possible amount of wins. You can't always win, but you can give the opponent more chances to make a bad move.
Or, you can always try the tic tac toe algorithm in the link below:
Tic Tac Toe perfect AI algorithm: deeper in "create fork" step
given that we know
one cannot force a win
with optimal strategy one cannot lose
your AI has already proven to be optimal if
you did search the full tree when playing against it
and your AI is deterministic (if it were rolling the dice at certain stages you would have had to play against all combinations)
It did not lose, you cannot demand it to win. the wins it did do not count, as your full tree search included bad moves as well. that's all, you are done.
just for fun:
if you had no a priori knowledge about the chances to win/draw/lose a game a common strategy would be to persistently save lost positions. on the next game you would try to avoid them. if you can't avoid a move to a lost position you found another one. this way you can learn not to lose against a certain strategy (if possible) or to avoid an error in your strategy.
In order for your tic-tac-toe AI to be proven correct, it needs to satisfy two conditions:
It must never lose.
When the opponent deviates from optimal play, it must win.
Both conditions derive from the fact that if both players play optimally, the tic-tac-toe always ends in a draw.
One automatic method of determining whether your program fulfills these two conditions is to construct what is called a "minimax tree" of every possible tic-tac-toe game. The minimax tree completely characterizes the optimal move for each player, so you can use it to see if your program always selects the optimal move. This means that my answer essentially boils down to, "Write a perfect AI, and then see if it plays the same way as your own AI." However, the minimax algorithm is useful to know, and to my knowledge, this is the only way to test if your AI actually plays optimally.
Here is how the minimax algorithm works (For a gif explanation, see Wikipedia. There's also some pseudocode in the Wikipedia article on minimax.):
Beginning with the tic-tac-toe setup under consideration, construct a tree of all possible subsequent moves. The initial position at the root node. At the lowest level in the tree, you have all of the possible final positions.
Assign a value of +1 to all final positions in which the first player wins, a value of -1 to all moves in which the second player wins, and a value of 0 to all ties.
Now we propagate these values up the tree to the root node. Assume that each player plays optimally. In the last move, Player One will select any move that has a value of +1, i.e. a move that wins the game. If no move has a value of +1, Player One will select a move with value 0, tying the game. Thus, nodes where it is player Player One's move are assigned the maximum value of any of their child nodes. Conversely, when it is Player Two's move, they prefer to select moves with a value of -1, which win them the game. If no winning moves are available, they prefer to tie the game. Thus, nodes where it is Player Two's turn are assigned a value equal to the minimum of their child nodes. Using this rule, you can propagate values from the deepest level in the tree all the way up to the root node.
If the root node has a value of +1, the first player should win with optimal play. If it has a value of -1, the second player should win. If it has a value of 0, optimal play leads to a draw.
You can now determine, in each situation, whether your algorithm selects the optimal move. Construct a tree of all possible moves in tic-tac-toe, and use the minimax algorithm to assign +1, 0 or -1 to each move. If your program is Player One, it is optimal if it always selects the move with the maximum value. If it plays as Player Two, it is optimal if it always selects the move with the minimum value.
You can then loop through every move in the tree, and ask your AI to select a move. The above tells you how to determine if the move it selects is optimal.
I would use a decision tree to solve this problem.
Putting it in simple words, decision trees are a method to recursively calculate the expectancy (and chance) of the end result. each "branch" in the tree is a decision who's expectancy is calculated from the sum of (value * chance) possible for this decision.
in a limited options scenario (like tic-tac-toe) you can have the entire tree pre-calculated and therefore after each move of the human player (chance) you can make choose (decision) the next branch witch has the highest expectancy to win.
In a chess game the solution is similar but the tree is not pre-built: after each move the computer calculates the value for every possible move on the board for n depth forward. choosing the best, second best or n-th best expectancy depending on the difficulty of the game selected by the player.
I started work on a dungeon crawler in C# and I've already coded the level generation.
However, I've run into a problem. My level map is stored in a 32x32 multidimensional array, and each tile is stored as a string. All the tiles except for the following (all of these names are the variable names that represent that tile) (mongroveplant, tree, hjalaplant, vnosplant, barraplant, weedplant, naroplant, deathweedplant, venustrap, strangulator, statue, emptiness and stonewall) cannot be walked over.
These tiles (which can be walked over), which constitute a much longer list, are found here: Walkable Tiles. In each entry in the 32x32 multidimensional array, every entry is a string.
How do I create a pathfinding algorithm that avoids all the tiles listed above, but can go through all the tiles listed in the link? I am trying to go from the "start" tile to the "exitlevel" tile.
The first thing I would remove is the notion of string. Parsing string isn't quick in term of a video game. What you want, is to have flags for each tiles (bitfields). In the end, you will love flags because you can combine them!
[Flags]
public enum TileDescription
{
Walkable,
Trap,
Altar,
Door
}
They can also be stored at a int, which take far less space. Speed and space, two amazing notions.
As for the path-finding algo, there's plenty of them out-there. But basically, you have a start point, a end point, and you must find the quickest way between both. The idea is to check the nearest "nodes" and see if you get closer or not of your goal. Each time, you repeat the check with the new node. If you get trapped, you rewind to the nodes that still had available paths.
You have some nice basic algo :
http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm
http://en.wikipedia.org/wiki/A*_search_algorithm
However, long range pathfinding is ALWAYS extremely costly. You will have to limit the pathfinding to a specific range around the origin. Parsing a whole 32x32 maze could take a lot of time to find the quickest route. In most case, when you are beyond a specific range, you move your NPC up to the closest point, then repeat the pathfinding when it reaches it, or while reaching it. The trick to pathfinding is to do it over many frames and never to try to process it all at once.
So my partner and I need some help; we are working on a final project which is for an electrical engineering degree. Our problem, no one really knows much programming in the class. We need help or some general ideas on how to program this.
The project:
We have a monster truck with two IR (infra red) sensors detecting it's path via voltage. with this we are using a free scale circuit board as the "brains" along with this we have a nerf "missle turret" to shoot through open doors (we need to do programming to note a voltage drop from the IR sensors.
The programming:
We are trying and struggling very, very hard to create the code for this we
need a delay function in the start of the program to set the monster truck on the ground, after we need it to follow a straight line from a set standard of voltage that the IR sensors are reading on the ground.
while it is going it will have a large V drop reading while it passes an open door, we need it to stop shoot and then follow it's path.
I know it is a lot to ask but we are in a large need for help, our teacher while wise beyond his years in everything electrical (reminds me of doc from back to the future) the c programming is lacking and not too many here have the massive knowledge to use the C programming skills.
finally, once we get this working (mid may) i will post video if able too and show you all. I appreciate any input and any ideas for this, thank you all for your time!!
Your code will probably look like:
// Give yourself some time to set the robot down
<sleep_for_some_interval>;
// Keep reading the sensors and reacting until
// some amount of time passes, or a button is pressed, etc.
while(<keep_running_condition>)
{
// Update sensor readings
int leftDist = <ConvertToDistance>(<read_left_voltage>);
int rightDist = <ConvertToDistance(<read_right_voltage>);
// React to sensor readings
if(leftDist > <door_threshold> &&
rightDist > <door_threshold>)
{
// A door has been detected.
<stop>
<shoot>
<move_forward_fixed_amount>
}
else if(leftDist > <turn_threshold>)
{
// Left distance is beyond the threshold,
// need to turn left
<turnLeft>;
}
else if(rightDist > <turn_threshold>)
{
// Right distance is beyond the threshold,
// need to turn right
<turnRight>
}
else (<terminate_condition>)
{
// Something happened (a sensor condition, etc)
// that tells us that we need to end
// the program
break; // This will exit the while loop
}
else (...)
{
// Other conditions...
}
else
{
// Default reaction (happens if none of the previous
// conditions are met)
<goForward>
}
}
// Shutdown the robot
<stop>
// ...
Obviously the comparisons may need to be different, but the basic idea will be to continually read your sensors, and then have a list of conditions to check and actions to take when conditions are met.
Notes/Hints:
To "delay ... in the start of the program" you will call something like sleep/usleep
Make sure that you check your conditions in the right order (check the most restrictive conditions first) In the above example, if I moved the "turnLeft" check to the top, I might end up turning left instead of reacting to the door.
The way the above code is written, only one reaction will happen on each pass through the loop. (This will prevent you from accidentally trying to do two things when you should only be doing one, e.g. turning left and firing)
It may be helpful to write a function that can convert a voltage to a distance
Your code will be cleaner and easier to maintain if you take complicated actions (like the reaction after you detect a door) and move them into their own function.
Make sure to use some form of revision control, even if you do nothing more than periodically zip up your development directory. It will be very helpful when you find that you've introduced a bug into your code.
Out of curiosity, is there a reason you can't do all this in hardware? I'm assuming a lot about your project, but I'd think at least #1 might even be easier to do in hardware if that's your area of expertise. Unless, of course, you have instructions to do this in software that you must obey.
If the IR sensors are already outputting variable voltage, couldn't you just scale the voltage output from the sensors to drive the motors? I'm assuming the wheels are driven by motors and you're spinning one faster than the other to get it to turn. Then you might even get a smoother driving pattern (turning/adjusting as you go), as opposed to the standard software solution, which is go-or-turn.
For #2, you could implement a state machine. This could take care of the delay as well, just throw a timer between state 0 (waiting) and state 1 (normal). Then use the voltage output from the door sensor to trigger state 2 (firing). If you need, you can split it into two states, 2 (arming) and 3 (firing), with another timer between the two. The wheel motors are only active in state 1, and release the missile trigger when state 3 occurs.
Most universities have a programming club (i know mine did) - why not hang around there, see if anyone wants to help?
Or even put something on the noticeboard around the computer rooms at uni, i'm sure most good programmers would find it a fun project to lend a bit of time to.
Being that it is a physical project you've got there, you really want someone there 'on the ground' with you, so to speak.