Move pre-calculation mess

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Henk
Posts: 7210
Joined: Mon May 27, 2013 10:31 am

Move pre-calculation mess

Post by Henk »

Because I want to remove my ChessPiece classes I started to rewrite the code that pre-calculates all possible moves in each direction. This code was spread over ChessPiece, WhitePawn, BlackPawn, King.

Also there was a BuildMove method which did nothing but calling new MoveBase. Unfortunately I did not see it was virtual. Took some time to find out that castling moves were missing.

If I look at the final result it is a total mess now. But looks like it still works.

Perhaps calculating pawn moves is most complex. Code for white and black pawns is similar but I did not make it generic.
zd3nik
Posts: 193
Joined: Wed Mar 11, 2015 3:34 am
Location: United States

Re: Move pre-calculation mess

Post by zd3nik »

Are you making a statement or asking a question?

In my opinion, using an object oriented approach to writing a chess program is fun, educational, and can result in an easy to understand program. But it often adds a lot of overhead resulting in a slower engine (which is not meant to imply that it can't be fast enough to play at a high level).

It sounds like you're in the process of "trimming the fat" of excessive object oriented-ness in your engine, which is a step in the right direction if you're trying to optimize. And it sounds like the approach you've taken isn't as clean and simple as you'd like it to be.

With the info you've given I can only answer after making assumptions about what you're doing in code. Perhaps you're overloading too much - e.g. trying to share code/logic across multiple object types? Keep it simple: pawns do pawn things, knights do knight things, etc. I can see a case for shared code in bishops, rooks, and queens. But even devising a way for those types to derive from a base class seems unnecessary to me. If you're going for speed, it's probably best to have little or no dynamic methods (e.g. virtual/overridden methods).
Sven
Posts: 4052
Joined: Thu May 15, 2008 9:57 pm
Location: Berlin, Germany
Full name: Sven Schüle

Re: Move pre-calculation mess

Post by Sven »

In my opinion an OO design of a chess program can become a mess very quickly when using too many very small objects like pawns, knights, etc. or even squares. For me a simple OO approach has core classes like

Game
Board
Move
MoveList
PV
SearchStack
HashTable

and some classes for the protocol part. Of course my own chess programs that are based on OO modelling have some more classes but many of them are not part of the "chess core". I also have classes like MoveGenerator, Evaluator, Searcher that represent "machines" doing work on demand.

When making my OO design of chess programs an important point for me was not to have too many small objects containing zero state information that changes during a chess game. A piece would be one of that kind.
Henk
Posts: 7210
Joined: Mon May 27, 2013 10:31 am

Re: Move pre-calculation mess

Post by Henk »

I don't like OO if classes have state variables. For these variables are nothing more then global variables but local to that class. Global variables is a source for bugs. Getting worse if classes get larger. So I prefer small classes and each method should actually be dependent on (or use) all state variables or properties.

Not to talk about virtual methods that are overridden somewhere but you forgot. Or you use an interface in your code and wonder with which concrete object it was instantiated.
Sven
Posts: 4052
Joined: Thu May 15, 2008 9:57 pm
Location: Berlin, Germany
Full name: Sven Schüle

Re: Move pre-calculation mess

Post by Sven »

Henk wrote:I don't like OO if classes have state variables. For these variables are nothing more then global variables but local to that class. Global variables is a source for bugs. Getting worse if classes get larger. So I prefer small classes and each method should actually be dependent on (or use) all state variables or properties.
Are you talking about OO or about some free-style programming paradigma that you invented? ;-)

Objects have a state which can change during their lifetime. All instance members of a class form the state of instances (objects) of that class. I am not sure whether this is the same as the term "state variables" you were using above.
Henk wrote:Not to talk about virtual methods that are overridden somewhere but you forgot. Or you use an interface in your code and wonder with which concrete object it was instantiated.
Are you editing your program with a hex editor, or are you using a normal IDE? As you are using C# I'd suspect the latter. But even if I only use "bash", "grep" and "vi" for programming I can find out that type of information easily ...