Seeking chess engine to modify

[rtr]

I am seeking a chess engine to modify. I want to use it for a chess training program, for the end user to perform drills. It might be playing out a K+P vs K ending, or finding candidate moves with the best mobility or squares controlled (teaching the player about space), and so on. Preferably bitboard based and C++, but that can be flexible. Frankly it can be nothing more than a perft calculator and FEN loader. As long as it's a good base to start from. Any recommendations?

[User923005]

You can find at least one hundred open source engines from:
github
sourceforge
google code
codeplex

For this list: http://www.computerchess.org.uk/ccrl/40 ... _pure.html
Anything that is orange is open source. Click on the engine, and there is a link to the engine's page.

If you just want a move generator, a web search for perft will find some.
There is a GPU version that does about twenty billion NPS:
http://www.talkchess.com/forum/viewtopic.php?t=48387

You can find info about move generators here:
http://chessprogramming.wikispaces.com/Perft

[rtr]

Thanks, I will plow through these as I have time. Do any open source engines stick out as being more usable as a chess library, or any that you consider particularly well written or otherwise beautiful regardless of playing ability?

[User923005]

Beauty is in the eye of the beholder.
I think that in order to advise which is best, I would have to understand your project better.

I guess that you don't want to start with some titanic finished engine with hundreds of thousands of lines of code.

Actually, I would recommend that you read the articles on the Chess Programming Wiki before doing anything else.
https://chessprogramming.wikispaces.com/

Because writing a chess engine is surprisingly arduous, I suggest that reading the entire site (yes, really) will save you time in the long run.

[rtr]

I have written a number of chess engines over the years. Tell me, is it better to write code that reads like English, or code that is well separated and structured (into components/modules, a la Large Scale C++ Software Design)? I've tried both, and readable doesn't seem to jive with scalable. I'm not sure readable jives with testable too well either. Is a chess engine small enough that scalable is not important? I'm guessing as long as you separate out the game-state structure, in case you want to do a multithreaded version, then that's enough?

I started writing C++ years ago, and it was readable, but I knew nothing of things like unit testing and had many bugs. I started writing Python (not for chess), and later came back to C++ chess engines, and it felt weird not having modules, so everything was wrapped in namespaces or structs, but the calling code is verbose and filled with something::similar_to(that::value,other::thing) when just_do(it,plz) would have been fine.

Still miss you on the other forum BTW

[User923005]

I am a big fan of readable.
Make the code as clear as possible.
Debugging is the hardest part, so anything to reduce that effort is a good idea.
I am also a big fan of assert() {see Fabian's code}.

I think that C code is fine, and C++ code is fine, and there is not a whole lot to recommend one over the other. There are studies that show that the supposed advantages of C++ do not really come to pass in real life, where all the coders are competent.

From:
Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment
Thomas E. Potok, Mladen Vouk, and Andy Rindos

"Summary
Our results indicate that in a commercial environment there may not be a consistent statistically
significant difference in the productivity of object-oriented and procedural software development,
at least not for the first couple of generations of an object-oriented product. The reason may be
low reuse level, but it could also be the underlying business model. Investigation of 19
commercial products has shown an unusual economy of scale for both object-oriented and
procedural software that is difficult to explain with traditional productivity drivers. However, a
review of the underlying business workflows has suggested that business deadlines may strongly
influence the overall productivity. In an environment where a typical delivery cycle for product
versions or release is on the order of 12-24 months it may be more economical to preserve
development team skills and expertise by keeping them together whether they operate under the
new release or maintenance schedules. This may produce aggressive schedules for new releases,
and lax schedules for maintenance releases. Our data appears to indicate that business workflows
can play a key role in realizing the potential productivity benefits from a new technology such as
object-orientation. For example, funding, staffing, and scheduling an object-oriented project in the
same way that is done for a procedural project appears to dictate the productivity of the team,
regardless of the potential benefit of a given methodology. The adoption of an object-oriented
methodology may necessitate changes beyond merely the new technology. The estimation of
project effort, the scheduling of project tasks, and the tracking of task completions should all be
examined based on the characteristics of a new technology. Otherwise, investments in technology
that has the potential to increase productivity may be lost unless the underlying business work
flows are adjusted to take advantage of the improved software development capabilities."

From:
An Empirical Comparison of Modularity of Procedural and Object-oriented Software
Lisa K. Ferrett
Jeff Offutt

"An unexpected and potentially significant result was that, in this study at least, the C++ applications were no more modular than the C applications. This suggests that the programmers who created the C++ applications that were investigated in this study did not, in fact, use an object-oriented approach."

And from:
The Effects of Object-Oriented Programming on Hours Spent in Software Maintenance
Kelly M. Turner

"We investigated the maintenance costs of supporting object-oriented and non-object-oriented source
code. This cost is factored in terms of personnel hours spent debugging a problem. The findings provide support to the original hypothesis that object-oriented design increases the hours spent debugging problems found in the maintenance cycle. Further research and data encapsulation is expected to support these initial findings."

Personally, I like OOP, since I do more C++ coding than C coding. However, it is a lie the C++ reduces software complexity. C++ HIDES software complexity, but the underlying software has about the same complexity. I find that C++ is easier to reuse, but studies show that empirically it is a push.

[lucasart]

I am seeking a chess engine to modify. I want to use it for a chess training program, for the end user to perform drills. It might be playing out a K+P vs K ending, or finding candidate moves with the best mobility or squares controlled (teaching the player about space), and so on. Preferably bitboard based and C++, but that can be flexible. Frankly it can be nothing more than a perft calculator and FEN loader. As long as it's a good base to start from. Any recommendations?

That one is a good base to start from:
https://github.com/lucasart/DiscoCheck
It has everything except a search basically. It's my current project to rewrite DiscoCheck with a cleaner design and SMP

• bitboards
• magic bitboards
• board: FEN read/write, play moves, display board, dynamic Zobrist + PST.
• move generators (flexible easy to do various things needed by advanced search like quiet checks etc.)
• SEE (iterative very fast)
• eval: PST + Mobility only (uses SIMD vector arithmetic).

It's a really clean and easy to understand codebase. It may get more complex later, obviously. But it's a good time to fork it if you want to do an engine of your own without having to do all the boring stuff from scratch.