For the Player object I said we'd need a rollDice() method.
But then I got to thinking about dice games. I've played a lot in the past and was a keen war gamer in high school, and the physical act of rolling the dice was definitely part of the fun. Even knowing that it won't really affect the randomness, there's still an aspect of blowing on the dice, talking to them, "oh yeah, c'mon 6, 6, c'mon!" and trying to throw them with a different wrist movement because you know you want a different result than the previous roll...
But with war games on computers, it's not as much fun to simply click a "roll" button on the screen. Even if the program makes a noise like dice banging together and shows the roll results like a pair of dice, it's just not the same.
So, then I realized, computerizing dice games would be great on Microsoft Surface. The game, board, pieces, etc. could be in the software, but with its cameras under the surface, you could do the physical rolling of the dice on top and it could determine what you rolled. This would work because nearly all six sided dice are standard with opposite paired faces:
1 : 6
2 : 5
3 : 4
That way, the cameras in Surface could read the the side that faces down and as long as you're not using weird, hand-made or nonstandard dice, it would know what came up on top.
As for the cardboard counters, sometimes they're fun to move, but not as much as hand rolling the dice, that's where the real action is. With Surface able to detect where you're pointing, having the counters computerized would still be fun because you'd still be able to use your finger to move them around between hexes. The computer, too, would be able to validate the moves and make sure you're not moving them too far or into the wrong hexes (my friends and I were friendly players and didn't cheat that way, but that isn't to say we never made honest mistakes).