Create internal board representation

[lightvector]

@mattj256: Pushed a bunch of implementations of basic board data types to an "iss9" branch. Still could use some more work (and is untested), but would you mind taking a look? It's probably close to the point where I should hand back it back to you for implementing the board logic.

Learning Scala along the way, it's become faster to code as I write more. Yay!

Some points for discussion or review or thought:

• I'm not sure I'm entirely consistent on style as I'm writing. Let me know if you think we should prefer different style conventions for things here and there.
• Using the "trait + case object" for all the enum-related stuff. I think the pattern-matching and typefulness is worth having to repeat things again for constructing the "values" list.
• Currently writing the board data type as immutable. Maybe mutable would be better, but I thought that given that we will eventually want to be copying the board on every move to store for a correct implementation of 3x rep checking, we might as well have it like this. But if it makes the later code (making moves) difficult for you to write, we can change it.
• Definitely not paying attention to performance right now. I don't imagine this will be a big deal though, unless Arimaa gets a lot more popular than it is now.

[lightvector]

Another design decision:

• Locations are NOT restricted to the "a1-h8" variety - offboard locations are also constructable. Instead making it so that all instances of Location are legal, off-boardness is a property of a location that is checkable via a method call, and also the Board will return a value signifying off-board-ness if you ask for the piece on any location not on the board.

[mattj256]

@lightvector I won't have time to look at the pull request until tonight. My off-the-cuff thoughts.

trait + case object

Sounds fine. You know Scala better than I do, and we definitely don't want to be creating new objects for things like horses and dogs.

I'm not sure I'm entirely consistent on style as I'm writing.

Funny you should mention that - There's a plugin called ScalaStyle that checks for consistent style and I was thinking of adding it, but I thought I was spending too much time on libraries and not enough time on actual coding. I definitely want to have a consistent style, even if it's not always the way I would write things.

Currently writing the board data type as immutable.

I think this is a bad idea because it seems very inefficient. Meanwhile, efficiency isn't our primary concern right now. Also we're going to be using bitboards at some point anyway, so it isn't worth getting too excited about this.

Definitely not paying attention to performance right now.

I think it's good to pay some attention to performance up front. If we suddenly get a traffic spike, I wouldn't want to have to scramble to recode anything. But that's more of a philosophic difference. The most important thing is to get it up and running, and have a solid architecture that can handle the speed and performance needs of a "real" server, even if the lower-level implementation is slow. I definitely want to do Zobrist at some point.

offboard locations are also constructable.

I disagree with this - you should be able to make a board with three elephants and five camels. The board is just a container that holds the pieces, and it doesn't "know" that there is only supposed to be one elephant. If this were Shogi it would be different. Once a piece is captured it's gone, as if it never existed.

[lightvector]

Performance:

I honestly can't see how even doing something like copying the board is going to be a problem. In my Arimaa bot, I used to copy the board (that is, I used copy/makeMove rather than makeMove/unmakeMove) for every node in the search tree. I still got hundreds of thousands of nodes per second, and it wasn't even a bottleneck - it would have been millions of nodes per second if that was all that the code was doing. And we're not writing a bot here - we only need to do work when a user submits a move.

We can use zobrist hashing, yes, but might as well for the sake of correctness (and other benefits) just keep the whole board history.

Board design:

I don't think I said anything about restricting quantities of different kinds of pieces...? Merely about what locations are valid on the board. If we're going to choose a more optimized implementation later, then we're going to switch from a Map to an Array later anyways, which means we'll need to do something about indices requested that are out of bounds of the array.

From writing my bot, I've found the cleanest way is to accept off-board locations when querying the board and just have the contents at that location be "off board" rather than "empty" or "piece X" - that is, use a mailbox-like behavior (https://chessprogramming.wikispaces.com/Mailbox). Then, in the rules implementation, you don't always have to constantly be saying things like "is the destination square within the bounds of the board and empty", instead you always just say "is the destination square empty", and if it's not on the board, then then it doesn't have the "empty" value because it has the "off board" value.

On Wed, May 20, 2015 at 10:00 AM, mattj256 notifications@github.com wrote:

@lightvector https://github.com/lightvector I won't have time to look at the pull request until tonight. My off-the-cuff thoughts.

trait + case object

Sounds fine. You know Scala better than I do, and we definitely don't want to be creating new objects for things like horses and dogs.

I'm not sure I'm entirely consistent on style as I'm writing.

Funny you should mention that - There's a plugin called ScalaStyle that checks for consistent style and I was thinking of adding it, but I thought I was spending too much time on libraries and not enough time on actual coding. I definitely want to have a consistent style, even if it's not always the way I would write things.

Currently writing the board data type as immutable.

I think this is a bad idea because it seems very inefficient. Meanwhile, efficiency isn't our primary concern right now. Also we're going to be using bitboards at some point anyway, so it isn't worth getting too excited about this.

Definitely not paying attention to performance right now.

I think it's good to pay some attention to performance up front. If we suddenly get a traffic spike, I wouldn't want to have to scramble to recode anything. But that's more of a philosophic difference. The most important thing is to get it up and running, and have a solid architecture that can handle the speed and performance needs of a "real" server, even if the lower-level implementation is slow. I definitely want to do Zobrist at some point.

offboard locations are also constructable.

I disagree with this - you should be able to make a board with three elephants and five camels. The board is just a container that holds the pieces, and it doesn't "know" that there is only supposed to be one elephant. If this were Shogi it would be different. Once a piece is captured it's gone, as if it never existed.

— Reply to this email directly or view it on GitHub https://github.com/lightvector/arimaa-server/issues/9#issuecomment-103897285 .

[mattj256]

I honestly can't see how even doing something like copying the board is going to be a problem.

I keep forgetting that you're written a bot and I haven't..

I've found the cleanest way is to accept off-board locations when querying the board and just have the contents at that location be "off board" rather than "empty" or "piece X"

Ok. I'm not going to worry about this - I have my work cut out for me writing the rules implementation!