Author: Sven Reichard
Date: 01:57:05 07/03/02
Go up one level in this thread
Russell, I admit that have taken the OO approach a bit to the extreme, so I have classes for all sorts of silly things. Not the most effective thing to do, but it works so far - worked until last night when I ran into a nasty bug that had slipped my test suite. guess it's debugging time... Detailed comments below. Again, this is just a description of what I do, without any claim that is useful or reasonable. On July 02, 2002 at 22:37:27, Russell Reagan wrote: >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. The names of the classes are important, and you don't see how silly they are until you show them to somebody else. I like the name Board, since the board contains the pieces, and that's it. Have to rethink "Game". I just recall that at some point it was called DynamicPosition, since it contains the board position(the static part) and some "dynamic" part, i.e., side to move etc., however I thought that name was ugly. Also, SanNotation is silly since SAN stands for short algebraic notation... >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. The Piece class represents a real world object. A piece knows how it can move. Hence it should be responsible for generating its moves. I'm still debating whether or not to put part of the evaluation code in the Piece classes as well. > 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. The first purpose of a Square is to serve as an address into the Board. So, maybe my understanding of "square" is different from yours. You can think of a Square in my terms as a set of coordinates, e.g., f7. So, I use it in the sense of Board b; Square f7; const Piece* p = b[f7]; Where this class becomes more than just data is when dealing with the geometry of the board (together with a couple of Direction classes - actually to many :)). > What is the purpose of a move? I think that's data too. A move has the purpose of changing the position, and updating all the related data. How these data are updated depends quite a bit on the type of the move (capturing, promotion, castling,...), so I have subclasses for them. > 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. You're right about the speed issue, but that is not my greatest concern at the moment. It's searching about 50knodes/sec in the middle game, and that's enough for my purposes. I'm more concerned about why it searches so *many* moves :) (for a given ply, that is). By itself, the Game class doesn't know much more about the position than the Board class. By the "one purpose" rule, different classes are used to keep track of castling rights, e.p. squares, 3-fold repetition, etc. They accomplish that by following what's going on in the game (if you're familiar with the Gang of Four, that's a classical Observer pattern). I've seen some "EngineListener" class in Remi's library, but I'm not sure if it serves the same purpose. So, the main purpose of the Game class is to broadcast the moves to all observers, and to collect their findings. >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. As I stated above, that's not entirely correct. I also don't have a coordinate notation class (good idea, though), but for debugging purposes, each move knows how to print itself in coordinate notation (don't need the position for that). Now, this is what the design has developed into over time. It is a bit complex, and I don't think I would have come up with some of the decisions had I tried to write it down up front. >Russell Sven.
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.