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.
Move pre-calculation mess
Moderators: hgm, Dann Corbit, Harvey Williamson
-
zd3nik
- Posts: 193
- Joined: Wed Mar 11, 2015 3:34 am
- Location: United States
Re: Move pre-calculation mess
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).
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
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.
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
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.
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
Are you talking about OO or about some free-style programming paradigma that you invented?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.
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.
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 ...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.