Author: Russell Reagan
Date: 19:37:27 07/02/02
Go up one level in this thread
On July 02, 2002 at 21:15:07, Brian Kostick wrote: >I use the term piece loosely, meaning all movable playing pieces, not 'pieces' >and pawns as traditional chess terms. Maybe I take 'object' too literally but I >offer: > >Board, knows where pieces are, their type and color. > >Piece, a base to build up pawn, Queen, King objects, ect... > >Brain, thinks about moves, evaluates, however you want to say it. > > >Ok, so I didn't give this excessive consideration. However I would like to here >peoples thoughts on what the objects should be. Clue me in to your design ideas, >I think that would be really interesting. Cheers, BK I'm beginning to see that there are a plethera of different ways you can classify everything when using an OOP approach. Basically you need a way to keep track of the current position, and the history of the game. Some people use a Position class and a Game class which contains a Position. Some people use a Board class and a Game class, but their Game class is essentially the same thing as the other person's Position class. I think our wording is the first thing that makes it hard. For example, to one person the word "position" is what describes the current arrangement of the pieces AND side to move, castling rights, ep square, etc. To another person, they call that same thing the "board", and another person thinks that the "board" is ONLY the pieces. Yet another person thinks that the "position" should include the game history, since there might be a 3 fold repitition coming up, and if you only have the position and not the move history, you would be dealing with a different position entirely since the outcome of the game is different. Or the short version, it's confusing. I like Sven's statement that an object should serve one purpose, and one only. That is at least a start to start weeding out some of the possibilities. Using this view, what is the purpose of a piece? I can't really think of it having a purpose in programming terms, other than hold a value for it's type and color, and then it's just data without any real operations that need to be done to it, so I'm leaning towards it not really being an object. A square is the same I think. What is the purpose of a square? To hold data about a piece. So it's just data. What is the purpose of a move? I think that's data too. Now we reach a position. I think that's an object. It's purpose is to keep track of the state of the game, and there are certainly some things that you can "do" to a position, such as make a move on it, take back a move, reset it, set it to a fen string, and maybe others. A game seems to me very closely linked to the position object. In a game, you can make a move, reset the game, undo a move, and so on. I think a game is really just a position with the move history of the game, and some other data about the players names and ratings for PGN stuff. This might be better handled by making a PGN object that takes a position, a list of moves, players names, etc. But maybe it would be good to have a game object too. I think it might be better to eliminate the position object and just have a game object, which will contain all of the "position" data and operations that we need. For example, if you have BOTH a position and a game object, then when you do a MakeMove() on a game object, that game object is just going to call position's MakeMove(), and that only slows things down. I like Sven's idea about having just data for a move, and then for output he has a SAN class and (I would guess) a coordinate notation class, and he can pass the constructor either a string with that kind of move, or a move and get a string. Russell
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.