I'm making a chess game, rendered with OpenGL.
I'm not looking for somebody to tell me all of the answers, I would like to figure the code out on my own, but pointing me to the right concepts is what I really need. At this point, I'm not sure where to start. Here is what I've figured out:
An enumeration, TurnState, with the following values:
playerOneTurn
playerTwoTurn
Stopped
An enumeration, GameState, with the following values:
playerOneCheck
playerTwoCheck
playerOnecCheckMate
PlayerTwoCheckMate
InitializingGame
Tie
NormalPlay
An abstract class, Player, and a subclass, Computer.
A class, ChessGame, with the following fields:
Player p1, p2
TurnState turnState
GameState gameState
A class, Move, with the following fields:
*Piece
Location origin
Location destination
A class, Location, with the following fields:
row
col
*ChessBoard
A class, ChessBoard, with one method, isValid, which takes a Move and checks if the move is valid or not.
An abstract class, ChessPieces, with the following methods:
GetValue() // returns an int value of the piece (for scoring)
GetPosition() // returns the current position of a piece
getIsSelected() // returns a boolean, true if selected, false if unselected
move() // moves the piece in a way dependent upon what piece
And the following subclasses:
Pawn
Rook
Queen
King
Knight
As to the AI part of the chess game:
To get a chess AI, or any sort of turn based game AI, you will need to calculate the "value" of the game in a given turn (that's important) (i.e. you assign each piece a value and sum the values for player1 and player2 and then you do score = player1score - player2score, so negative values will benefit player 2 and positive ones, player 1, that's just a basic example and not a very efficient one, but it's the most basic way to explain what the "value" of the game would be).
After you can calculate that you need to be able to calculate every possible move of a player given a certain configuration of the board.
With that you will be able to build a decision tree in which you will have as the root node the current state of the game. The next "level" of the tree will represent every possible state you can get to from the current state (and so forth). It's important to notice that if you consider player1 possible moves in on level of the tree you will consider player two possible moves in the next.
Next thing to do would be:
suppose player1 is gonna make a move, he will look into in the tree until depth 5 (for a chess game you'll never look in the whole tree). So he will choose a move that will be optimized for him, that would mean: at each level he'll consider HIS best move or player2's best move (so he will work on the worst case scenario), so he'll move the the highest valued node in the next level of the tree.
To calculate a value of a node you do the following:
NOTE: considering root node is of depth 0, every odd depth node need to be maxValue for player1 and every even depth node minValue for player2.
You'll expand the tree to the max depth you define, for the node in the maxDepth you'll just calculate the value of the board (which I mentioned in the beginning of my answer), for upper nodes you'll do:
even node's value : minValue between all child nodes
odd node's value : maxValue between all child nodes
So basically you'll do the regression to find the value of a node based on the value of deeper nodes.
Well, that's the basic idea, from it you can research some other stuff, if you want you can PM me, I've done some work on this kind of search, and I just described the most basic idea here, for an efficient code you'll need lots of optimization techniques.
Hope it helped a little
First of all: Separate the two: AI and GUI/OpenGL. In chess it is normal to have the GUI and the AI (the "Engine" in computer chess lingo) in two different processes that's communicating with a predefined protocol. The two most popular protocols for this are UCI and WinBoard.
For the chess engine part, you basically need three thing:
A board/position representation
A leaf node evaluation function
A search algorithm
I suggest you read:
Chess Programming WIKI
TalkChess forum for computer chess
Study a open source computer chess engine, like Stockfish, Crafty or Fruit.
This may not be directly answering your question (actually what is your question?), but you mentioned you wanted pointers to the right concepts.
oysteijo is right, one of the concepts that is very important is separating parts of a program from each other.
For something like chess there exist many efficient and elegant representations of the state of a chess game. I would say that the MVC (model, view, controller) design pattern works quite well for a chess game.
Hopefully this will make some sense, if not I suggest you read up on MVC some more.
Your model is going to primarily involve the datastructure which stores the representation of state of the game, this is the chessboard. A piece can only be on one of 64 spots, and there are limitations on the types of pieces and how many there are and what each of them do. The model will be responsible for dealing with this stuff. It would also make sense to give the model the logic for determining the legality of any given move (i.e. the properties of the game which don't necessarily involve the state of any given instance of a game).
The view is where all of your presentation related code goes. All that OpenGL is going in here, as would a "debug" routine which might (for instance) print an ASCII representation of the chessboard to the console.
The controller might have some functions which interface with the user to process input. The controller is the part of code which manipulates the model ("move E5 to D3": a function in your controller might call model.moveKnight('D3')) and the view ("draw the board in glorious 3D": the controller might do something like calling openGLView.draw(model))
One of the primary goals that MVC helps achieve is the independence of parts of code that perform different tasks. If some change in your AI causes problems with a rendering algorithm, it is a frustrating and difficult position to be in. An experienced programmer would go to some great lengths to ensure that this couldn't happen.
You might be wondering at this point where your AI code fits into the picture. Well, it's really up to you. Use your best judgement. It could be a part of the controller. Personally I'd have it be a whole nother controller (chessAIController) which implements the AI algorithms, but it is just as easy to have all of it contained within the main controller.
The point is, it doesn't really matter how you actually organize the code so long as it is done in some kind of logical way. The reason that MVC is so widespread is that those 3 components are usually present in most software and it usually makes sense to separate them. Note they're not actually really separated... the controller often directly manipulates both the view and model. Restrictions such as not allowing the view to manipulate anything helps code to stay clean and intelligible.
When you have no structure or organization in a programming project it can be nearly impossible to avoid having huge routines which do a little bit of everything because there is really only one place in the code in which to build functionality upon. What this generates invariably is a tangled mass of spaghetti code that no language, no matter how high-level, can save you from. This creates code that just plain sucks because nobody else can understand it, and even you will be unable to understand it two weeks from the time it is written.
Related
I have seen some MCTS implementation online and how they are used in a game.
A best move is calculated each move based on the state at that moment.
If you have a sequence of moves in a game between human and computer like:
turn_h1,turn_c1,turn_h2,turn_c2,turn_h3,turn_c3,....turn_hn,turn_cn
turn_h(i)=human, turn_c(i)=computer and i the i-th move of a player (human/computer).
And for each computer's turn i there is a corresponding state that is used to determine the i-th best move with MCTS.
Question: Should the tree built in the (i-1)-th turn(bestmove) be used for the i-th turn(MCTS bestmove)?
I mean, should the tree which was the result of the best move in state (n-1) be used as input for determining the best move at the i-th state?
Other words can I re-use already constructed tree-nodes from previous turns/bestmoves calculations, so that I do not need to build the whole tree again?
I have created a sequence of turns in pseudo-code just to make clear what what I mean with using the (i-1)th state(tree) to feed the next MCST bestmove. (of course in real world the logic below would be implemented as an iteration/loop construct):
#start game
initial_game_state.board= initialize_board()
#turn 1
#human play
new_game_state_1 = initial_game_state.board.make_move(move_1)
#computer play
move_1 = MCTS.determine_bestmove(new_game_state_1)
new_game_state_2 = game_state_1.board.make_move(move_1)
#turn 2
#human play
new_game_state_3 = new_game_state_2.board.make_move(move_2)
#computer play
move_3 = MCTS.determine_bestmove(new_game_state_3)
new_game_state_4 = new_game_state_4.board.makeMove(move_3)
#turn 3
# ....
Yes you can do this. This is commonly referred to as "tree reuse" (at least, that's how I usually call it).
You would start out your MCTS call (except for the very first one, in which there is no "previous tree" yet) by navigating from the root node to the node that corresponds to the one you have actually reached in the "real" game.
Note that, in a two-player alternating-move game, this does not only involve a move that your MCTS agent made, but also a move made by the opponent. Due to how MCTS work, if the opponent "surprised" your MCTS agent by selecting a move that MCTS didn't predict, it is likely that this leads to a subtree of the previous tree that had relatively few visits. In this case, tree reuse won't have much effect. But in cases where the opponent doesn't surprise you, and plays exactly what MCTS already predicted during the previous search, you may end up getting a relatively large subtree to initialise your new search with.
As for if you "should" do this, as is the literal wording in your question... you don't have to. There are many MCTS implementations out there which don't do this. I'd generally recommend it anyway. It's not too difficult to implement. It generally won't give a big boost in performance (because the playing strength of MCTS tends to scale sub-linearly with increases in "thinking time"), but it definitely shouldn't hurt either, and may give a small boost in playing strength.
Note that, in nondeterministic games, if you implement an "open-loop" variant of MCTS (without explicit chance nodes), the part of the subtree that you're "re-using" will be partially based on outdated information. In such games, it may be beneficial to discount all the statistics gathered in your previous search (i.e. multiply all your visit counts and accumulated scores by a number between 0 and 1) before starting the new search process.
Important implementation detail: when re-using the previous tree, if your new root node (which used to be a node in the middle of your previous tree) has a reference/pointer back to its parent node, make sure to set it to null. If you forget about this, all search trees of all your previous searches will fully persist in memory throughout an entire game, and you'll likely run out of memory quickly.
I'm trying to wrap my mind around property-based testing and chess. Currently I represent my chess game as a 2d-array and the only pieces I have implemented are pawns and knights for grokking this.
The pawn and knight represent their moves as the set of allMoves(x,y) \ invalidMoves(board,x,y). So one property I can think of is to test that allMoves(x,y) ∪ invalidMoves(board,x,y) === allMoves. But beyond that I'm not sure what else to test. I assume that I need to set up a simplified oracle model for the chess board but I'm not sure what such a model would be.
Start by just saying some obvious things that are true about real-life chess boards, no matter how dumb they sound. Many of those will be reasonable properties to test. Here are some ideas:
When you move a piece, it moves from the place where it was to the place where the move puts it.
No legal knight move is ever a legal pawn move.
A pawn never moves more than two squares at once.
A knight never moves adjacent to its starting position.
A move should only involve positions actually on the board.
Moving onto another piece decreases the number of pieces on the board.
Many more ideas like this exist. They seem simple, but I guarantee your early implementations will miss some of them. Figure out how to write these invariants as properties, and grow your test suite from there.
I am trying to build a system that on providing an image of a car can assess the damage percentage of it and also find out which parts are damaged in the car.
Is there any possible way to do this using Python and open-cv or tensorflow ?
The GitHub repositories I found that were relevant to my work are these
https://github.com/VakhoQ/damage-car-detector/tree/master/DamageCarDetector
https://github.com/neokt/car-damage-detective
But what they provide is a qualitative output( like they say the car damage is high or low), I wanted to print out a quantitative output( percentage of damage ) along with the individual part names which are damaged
Is this possible ?
If so please help me out.
Thank you.
To extend the good answers given by #yves-daoust: It is not a trivial task and you should not try to do it at once with one single approach.
You should question yourself how a human with a comparable task, i.e. say an expert who reviews these cars after a leasing contract, proceeds with this. Then you have to formulate requirements and also restrictions for your system.
For instance, an expert first checks for any visual occurences and rates these, then they may check technical issues which may well be hidden from optical sensors (i.e. if the car is drivable, driving a round and estimate if the engine is running smoothly, the steering geometry is aligned (i.e. if the car manages to stay in line), if there are any minor vibrations which should not be there and so on) and they may also apply force (trying to manually shake the wheels to check if the bearings are ok).
If you define your measurement system as restricted to just a normal camera sensor, you are somewhat limited within to what extend your system is able to deliver.
If you just want to spot cosmetic damages, i.e. classification of scratches in paint and rims, I'd say a state of the art machine vision application should be able to help you to some extent:
First you'd need to detect the scratches. Bear in mind that visibility of scratches, especially in the field with changing conditions (sunlight) may be a very hard to impossible task for a cheap sensor. I.e. to cope with reflections a system might need to make use of polarizing filters, special effect paints may interfere with your optical system in a way you are not able to spot anything.
Secondly, after you detect the position and dimension of these scratches in the camera coordinates, you need to transform them into real world coordinates for getting to know the real dimensions of these scratches. It would also be of great use to know the exact location of the scratch on the car (which would require a digital twin of the car - which is not to be trivially done anymore).
After determining the extent of the scratch and its position on the car, you need to apply a cost model. Because some car parts are easily fixable, say a scratch in the bumper, just respray the bumper, but scratch in the C-Pillar easily is a repaint for the whole back quarter if it should not be noticeable anymore.
Same goes with bigger scratches / cracks: The optical detection model needs to be able to distinguish between scratches and cracks (which is very hard to do, just by looking at it) and then the cost model can infer the cost i.e. if a bumper needs just respray or needs complete replacement (because it is cracked and not just scratched). This cost model may seem to be easy but bear in mind this needs to be adopted to every car you "scan". Because one cheap damage for the one car body might be a very hard to fix damage for a different car body. I'd say this might even be harder than to spot the inital scratches because you'd need to obtain the construction plans/repair part lists (the repair handbooks / repair part lists are mostly accessible if you are a registered mechanic but they might cost licensing fees) of any vehicle you want to quote.
You see, this is a very complex problem which is composed of multiple hard sub-problems. The easiest or probably the best way to do this would be to do a bottom up approach, i.e. starting with a simple "scratch detector" which just spots scratches in paint. Then go from there and you easily see what is possible and what is not
I'm taking an introductory graphics course, and while I intuitively understand that converting a click or touch into object coordinates will make the math much cleaner, reduce the chances for human error, and potentially make debugging easier, none of these are actually a very good explanation, conceptually, of why object coordinate spaces are used in selection tests, as opposed to simply using world coordinates for the test - rather, they're just observations of what tends to happen when object coordinates are used. So I ask: why?
A selection test involves comparing the click coordinates, which you get in window coordinates, against lots and lots of object features, which are represented in object coordinates.
You need to transform them into the same coordinate system in order to do the checks, so you can EITHER transform the one simple click point OR you can transform all the various object features.
Transforming one point or line is just a lot easier that transforming a whole bunch of object features of various types.
There are cases where the location of a specific object or point may not be known within a world coordinate system, but is known relative to some other coordinate system.
To summarize an example from my course text, consider the idea of two different towns, one using a grid system for its layout, and the other using what I can only describe as the New England we-made-cow-trails-into-roads method. A government employee is tasked with creating a layout of the area which includes them, and in doing so has to convert the two coordinate systems into a third, which encompasses the other two.
Sometimes, using a world atlas just isn't practical to get across the street, and so something much more local (and relevant) is used instead, as it provides much more detail over a much smaller area.
The text also explains that it may be more than simply impractical to use a given coordinate system - it may yield results that are improbable or just plain wrong. This is evidenced in the evolution of the geocentric and heliocentric models of the universe - the distance of the stars from us was calculated with very different results using the two models.
Thinking of my own example, the best that comes to mind would be something like your own internal organs - from the outside, you don't know for sure exactly the shape, size, and structure of each of them, but your own body does. In order to be able to access that information, you need to look inside the body (ideally in a way that doesn't kill you). It's not something that is plainly observable from outside.
I decided to write a small program that solves TicTacToe in order to try out the effect of some pruning techniques on a trivial game. The full game tree using minimax to solve it only ends up with 549,946 possible games. With alpha-beta pruning, the number of states required to evaluate was reduced to 18,297. Then I applied a transposition table that brings the number down to 2,592. Now I want to see how low that number can go.
The next enhancement I want to apply is a strategic reduction. The basic idea is to combine states that have equivalent strategic value. For instance, on the first move, if X plays first, there is nothing strategically different (assuming your opponent plays optimally) about choosing one corner instead of another. In the same situation, the same is true of the center of the walls of the board, and the center is also significant. By reducing to significant states only, you end up with only 3 states for evaluation on the first move instead of 9. This technique should be very useful since it prunes states near the top of the game tree. This idea came from the GameShrink method created by a group at CMU, only I am trying to avoid writing the general form, and just doing what is needed to apply the technique to TicTacToe.
In order to achieve this, I modified my hash function (for the transposition table) to enumerate all strategically equivalent positions (using rotation and flipping functions), and to only return the lowest of the values for each board. Unfortunately now my program thinks X can force a win in 5 moves from an empty board when going first. After a long debugging session, it became apparent to me the program was always returning the move for the lowest strategically significant move (I store the last move in the transposition table as part of my state). Is there a better way I can go about adding this feature, or a simple method for determining the correct move applicable to the current situation with what I have already done?
My gut feeling is that you are using too big of a hammer to attack this problem. Each of the 9 spots can only have one of two labels: X or O or empty. You have then at most 3^9 = 19,683 unique boards. Since there are 3 equivalent reflections for every board, you really only have 3^9 / 4 ~ 5k boards. You can reduce this by throwing out invalid boards (if they have a row of X's AND a row of O's simultaneously).
So with a compact representation, you would need less than 10kb of memory to enumerate everything. I would evaluate and store the entire game graph in memory.
We can label every single board with its true minimax value, by computing the minimax values bottom up instead of top down (as in your tree search method). Here's a general outline: We compute the minimax values for all unique boards and label them all first, before the game starts. To make the minimax move, you simply look at the boards succeeding your current state, and pick the move with the best minimax value.
Here's how to perform the initial labeling. Generate all valid unique boards, throwing out reflections. Now we start labeling the boards with the most moves (9), and iterating down to the boards with least moves (0). Label any endgame boards with wins, losses, and draws. For any non-endgame boards where it's X's turn to move: 1) if there exists a successor board that's a win for X, label this board a win; 2) if in successor boards there are no wins but there exists a draw, then label this board a draw; 3) if in successor boards there are no wins and no draws then label this board a loss. The logic is similar when labeling for O's turn.
As far as implementation goes, because of the small size of the state space I would code the "if there exists" logic just as a simple loop over all 5k states. But if you really wanted to tweak this for asymptotic running time, you would construct a directed graph of which board states lead to which other board states, and perform the minimax labeling by traversing in the reverse direction of the edges.
Out of curiosity, I wrote a program to build a full transposition table to play the game without any additional logic. Taking the 8 symmetries into account, and assuming computer (X) starts and plays deterministic, then only 49 table entries are needed!
1 entry for empty board
5 entries for 2 pieces
21 entries for 4 pieces
18 entries for 6 pieces
4 entries for 8 pieces
You're on the right track when you're thinking about reflections and rotations. However, you're applying it to the wrong place. Don't add it to your transposition table or your transposition table code -- put it inside the move generation function, to eliminate logically equivalent states from the get-go.
Keep your transposition table and associated code as small and as efficient as possible.
You need to return the (reverse) transposition along with the lowest value position. That way you can apply the reverse transposition to the prospective moves in order to get the next position.
Why do you need to make the transposition table mutable? The best move does not depend on the history.
There is a lot that can be said about this, but I will just give one tip here which will reduce your tree size: Matt Ginsberg developed a method called Partition Search which does equivalency reductions on the board. It worked well in Bridge, and he uses tic-tac-toe as an example.
You may want to try to solve tic-tac-toe using monte-carlo simulation. If one (or both) of the players is a machine player, it could simply use the following steps (this idea comes from one of the mini-projects in the coursera course Principles of Computing 1 which is a part of the Specialization Fundamentals of Computing, taught by RICE university.):
Each of the machine players should use a Monte Carlo simulation to choose the next move from a given TicTacToe board position. The general idea is to play a collection of games with random moves starting from the position, and then use the results of these games to compute a good move.
When a paritular machine player wins one of these random games, it wants to favor the squares in which it played (in hope of choosing a winning move) and avoid the squares in which the opponent played. Conversely, when it loses one of these random games, it wants to favor the squares in which the opponent played (to block its opponent) and avoid the squares in which it played.
In short, squares in which the winning player played in these random games should be favored over squares in which the losing player played. Both the players in this case will be the machine players.
The following animation shows a game played between 2 machine players (that ended in a tie), using 10 MC trials at each board state to determine the next move.
It shows how each of the machine players learns to play the game just by using Monte-Carlo Simulation with 10 trials (a small number of trials) at every state of the board, the scores shown at the right bottom of each grid square are used by each of the players at their corresponding turns, to choose its next move (the brighter cells represent better moves for the current player, as per the simulation results).
Here is my blog on this for more details.