D is a new language, although it's roots go back to 2005 for D1; It's just about getting the compiler and library up to full production level; Although you can build full code right now there's some missing features or bugs requiring workarounds until they are fixed.

Rust is an offshoot of D; not against it but some of it's syntax hurts my head.

Go, never touched it, and it doesn't really interest me.


to note, 14k of sourcecode and probably 2/3rd of the way done.

Already? :-O

Well I don't plan things heavily in advance, so I work on the things I can work on.

The grid/board has 8x8, so I start with that. Then I determine setting up the moves for each piece (or threatened areas) so I write those in as offset values, then I wrote in checks to see if a piece could reach the target square without anything in between, etc.

One thing I did later was writing a score determining function, which adds value to another piece when they are guarded (although the king doesn't count because backing up the king after he is taken... doesn't make sense). Pawns further up towards getting queened have more value so there's a multiplier there. etc etc.

The ending portion is mostly writing the bulk/brute forced individual piece movements, special movements (pawns, castling), and ending on the other player's turn. I realize threatening the king will give one of the highest point boosts, but if you don't check if your Queen sitting next to the opponent king won't instantly be captured, then it's pointless.

I'm also missing unittests but oh well...

Still, it is a lot of work you have accomplished already.
What are you using for board representation?

That chess board is wrong. The rows are numbered from bottom to top. White is on the bottom covering the rows 1 and 2, black is on top covering rows 7 and 8.

If your board is supposed to show the black player's view then 8 on the bottom would be correct but then the letters would go from right to left and therefore the King and the Queen arem't standing at the right place.

Actually, I meant the internal data structures you use to store the board position.
When reading about the Crafty engine, and learning about the bitboard representation, I was really surprised. Once CPUs would move to 64-bit, it would provide a big jump in processing speed when using this method.

You seem to be using and array of 8 arrays, right?

Been a while, although inverting the numbers is easily enough.


[code]
enum Pieces { NA=0, Pole=0, Pawn, Knight, Bishop, Rook, Queen, King};
enum Side { White, Black, Green, Red };

struct Piece {
mixin(bitfields!(
Pieces,"piece" ,3,
Side,"player" ,2, //i've seen 4way chess before, so this opens that up.
uint,"x" ,3,
uint,"y" ,3,
uint,"z" ,2, //potentially 3D chess
bool,"moved" ,1, //for castling, and first pawn move options
uint, "", 2 //unused
));
}

struct Board {
alias Grid = Piece[8][8];
Grid grid;

Piece playerPieces[2][16] = [
[
Piece(Pieces.Rook, Side.White, 0, 7), Piece(Pieces.Rook, Side.White, 7, 7),
Piece(Pieces.Knight, Side.White, 1, 7), Piece(Pieces.Knight, Side.White, 6, 7),
Piece(Pieces.Bishop, Side.White, 2, 7), Piece(Pieces.Bishop, Side.White, 5, 7),
Piece(Pieces.Queen, Side.White, 3, 7), Piece(Pieces.King, Side.White, 4, 7),
// ... etc
[/code]

This gives each piece all it's information while fitting in 16bits. This means i can store the entire board in 32 entries rather than 64.

However for checking if a spot is used, using an 8x8 grid is easier, and calculating the score is easier that way too...

Wow, actual code for 4-players, 3D Chess. :-D

D does not seem too ugly. Have you used it outside of hobby projects?

Not really. Haven't needed to complete anything. A lot of my skills are still also tied to the cold C/C++ code from so long ago, add to that I'm not fully familiar with what the libraries support yet. This means that I might end up writing a complex solution to a very simple problem.

I'm reminded of in C I had a complex solution for speedups & memory management, while in D there's a template called Memoize which took my huge code down to minimal code, since the returned values are saved and simply recalled when they are asked for again. Other things with searching sorting and array/storage uses I've not had the most experience with.

Some code examples I've seen are calling 7 commands on a single line that would probably take me 20 lines or more to do the same thing. So a huge amount of my problem is just not knowing what's there.

D needs to mature still. However if you aren't making a public library or trying to get around the odd rules, then the language is strong enough to use in production code. So there's that.

That is handy! But memoization should only be applied to "pure functions", typical of functional programming. Does the D compiler complain if I try to memoize a function that depends on the program's state or some external factor (like readline())? Or am I responsible for ensuring that I don't do stupid things?

Let's find the page. Hmmm interesting. Although I agree pure functions are perfect for that, and my example did involve pure functions. But often the result relies on other results of the function to build later results, hence how Memoize was so useful.

Oh well.

Maybe something a bit different, Majestic Chess is almost a RPG, and it teaches you to play chess as you go.

http://www.mobygames.com/game/windows/hoyle-majestic-chess