Chess Pieces as Objects?

[Fguy64]

In the context of Object Oriented Programming, my intuition tells me there probably isn't a situation where having a piece as an object would be necessary. because...

1. In chess, one doesn't really care where a piece has been, only where it is.

2. The properties of pieces are pretty static, it is the properties of positions and moves that are dynamic, it would make more sense to objectify these things.

agreed or not? I am admittedly basing my statement on limited knowledge of position representations.

[Aleks Peshkov]

Objects in OOP not necessary correlate with real world objects.

For example, my chess engine have two objects: properties of all pieces of side to move and opposite to side to move. This sides are colorless unlike real wooden pieces. Piece properties are vectors of size 16, so ordinal piece properties (square, move type, mobility) are scattered in several vectors.

I am not sure that my representation is worse copiing, just a thought about the role of piece objects. Most objects in chess program should have value semantic and fit in a register. Even my vectors do in fact fit in XMM register.

[Fguy64]

OK Aleks, I guess there are many ways of doing things. I suppose it depends on your position representation. You can use piece objects or some other way. In my program, for side to move, I just use a boolean variable that corresponds to the "side to move" field of a fen string.

regards.

[Aleks Peshkov]

What I said about small objects with value semantic is true for C++ (and pure C).

Java chess programs I know sacrificed OOP and used a poor subset of C (integers, low-level arrays) for low-level representation. I did not discover the topic deeply, but I doubt that Java programmers found a good Java-style chess representation.

Please tell me if I am wrong, I am very interested in any original high level design of low level chess things.

[ilari]

I tried a fully OOP solution with Cute Chess. I had an abstract class ChessPiece with virtual methods for moving and generating moves, and I subclassed it for every type of chess piece. It seemed like a good design at first, but it was just too slow and over-engineered. Eventually I ended up writing a basic Board class and used an array of integers to represent chess pieces. The latter solution wasn't just faster - it also took fewer lines of code and was easier to debug.

[Fguy64]

I'm not sure what you mean by 'java style'. but my simple java chess program uses what you call an array of type char[][], if that's what you mean by low level, then I cannot say yu are wrong. . I have been told by experts that my representation is not optimal for a high quality chess program, and that if you want the best possible program, you don't use java.

My project is a way for me to learn more about java, not just to write a better chess program.

[Fguy64]

I tried a fully OOP solution with Cute Chess. I had an abstract class ChessPiece with virtual methods for moving and generating moves, and I subclassed it for every type of chess piece. It seemed like a good design at first, but it was just too slow and over-engineered. Eventually I ended up writing a basic Board class and used an array of integers to represent chess pieces. The latter solution wasn't just faster - it also took fewer lines of code and was easier to debug.

I like what you say, particularly the use of the word over-engineered. You have used integers, I have used characters that mimic the characters used in a fen string. Otherwise our designs sound similar in a few respects, maybe not all.

[Aleks Peshkov]

Abstract ChessPiece is an obvious first look on the problem. But as most chess engine questions need sets (lists) of pieces, moves, squares. Separate pieces is not a good solution.

BitBoard-centered representation represent natively only sets of squares. Better then nothing, but is not sufficient.

[mathmoi]

I tried a fully OOP solution with Cute Chess. I had an abstract class ChessPiece with virtual methods for moving and generating moves, and I subclassed it for every type of chess piece. It seemed like a good design at first, but it was just too slow and over-engineered. Eventually I ended up writing a basic Board class and used an array of integers to represent chess pieces. The latter solution wasn't just faster - it also took fewer lines of code and was easier to debug.

In my current engine I did something just inbetween theses two extrem. I have a class CPiece wich is just a wrapper around a unsigned int. Using operator overloading it can be use as an integer.

Example :

Code: Select all

CPiece p(WHITE, PAWN);
eval = piece_square[p][E4];

This way, I can use it as an integer as all other programmers do and I can had methods like theses :

Code: Select all

CPiece p(WHITE, PAWN);
p.CanSlide();
p.CanSlideLikeRook(); // true for rook and queen.
p.CanSlideLikeBishop(); // true for bishop and queen.
p.Color();
p.Type();
cout <<p <<endl; // outputs 'P' in this case.

And when coded correctly it's no slower than using an integer.

[Bill Rogers]

Fred your opening statement about chess pieces not caring about where they have been is not entire true. Pawns always must know where they have been as they can not move backwards and a king at times must also remember where he has been as in the case where he moved out of check?
If this seems like nit-picking, then I applogise it was only meant it the to point out a small but missed fact.
Bill