4 hours ago, Zakwayda said:
- A 'game logic' component (and associated container entity) that does the bulk of the work (AI, movement, etc.). This would include a grid representation of the board (separate from any world-space visual representation) that's used to track game state.
I don't think you need an entity for the game logic. Also, game logic doesn't have to be a component. You can put the game logic into main(). Process the input, update the placement of units according to game rules, and then render them at their positions.
Also, a bit of a rant and personal opinion here, i think ECS is overkill for something like a checkers game. The ECS style architecture would be better suited when you have so many entities it becomes unwieldy to handle each of their behaviours individually (because you either duplicate a lot of code, or make large inheritance hierarchies where you can't reason about the code quickly anymore), so you split them into a smaller subset of pieces which you can easily [reason about it's] process/update, and compose the higher concept entities from those pieces, relying on standardized piece-wise functionality. And you can even continue the process further, and split any of those pieces (L1 pieces?) into another subset of pieces (L2 pieces) with their own update procedures, in order to compose the higher level piece, out of which you compose the entities. This is what you'd be doing anyway when you're coding for the first time, or not following ECS rules: embedding structs into structs into structs until you have a good data organization scheme that you can easily follow.
Anyway, to follow the thread question, what i would do is something like the following (pseudo code):
EMPTY = 0
RED = 1
BLACK = 2
board {
Tiles[8][8] = {EMPTY}
sprite BoardSprite
sprite RedPiece
sprite BlackPiece
}
int main() {
// .. initialization of the window, device, state, whatever
board Board
GameRunning = true
while(GameRunning) {
Input = grabInput(InputDevice)
GameRunning = gameLogic(Input, Board)
render(GraphicDevice, Board)
}
}
"grabInput" returns a struct with the inputs you want to handle (either raw device input you're interested in, or remapped logical commands, whatever suits your needs or framework).
"gameLogic" receives the board and the input, and internally, checks if it's the red or black player turn, and either processes the user input into board actions, or lets the AI produce board actions, then executes the generated board actions for the active player (which at this point, the logic doesn't care if they were produced by the user or AI, you could use this to pit two AIs against each other).
"render" just draw the board and the pieces, taking the visuals from the board.
Since this is a very simple game, an ECS (as i said above) is overkill and too rigid in it's traditional definition. Chess expanded to 4 times the board size and piece count, with several new piece types, and done in real time, could maybe be a better candidate 
