kelly-ry4n / chessers Goto Github PK

we should also make this into an Android app and maybe even a Windows phone app for the lulz but not iOS because Apple can bite us

also we should make tshirts because we can

Do we want to have a login (enter your name?) This would allow filtering replays/old games by name, and if we want to expand to having accounts/password this is the correct basework.

I propose the following routes over a JSON API for communication

• /, /index -> Homepage. Button to create new game. List of existing games (click to join/spectate).
• /chessers -> actual game html
• /api/v1/board_state/:id -> API endpoint for serialized board to be parsed from clients.
• /api/v1/game_id -> API endpoint for getting the gameid for a session. Could also inline this into /chessers
• /api/v1/change_board_state/:id -> Send updated gamestates after a move here before displaying to user. It will respond OK if the moves is permitted, and then client can update display.
• /api/v1/my_turn -> responds T or F, in case a client loses its place it can get it back. Could be combined with board_state
• /api/v1/board_state/:id/:movenum -> List of gamestates... could be used for replays, etc.

Clients can poll these say every second, or we can use a longlife connection which the server writes to when it has data, or some combination of the two.

Can you think of any other functionality we need to expose in the API in order to play between clients, or any connivence endpoints you'd like as the frontend guy?

@kelly-ry4n Dylan and I discussed the implementation of en passant and if it's technically a valid move in Chessers. we agreed that it isn't, because it's technically a chess move that you perform with a piece that has crossed the board, so it's a checkers piece at that point. if you agree, then we'll have a majority ruling to abolish it.

cons:

• Chess people will get mad

pros:

• makes sense in terms of Chessers
• don't need to implement the code, which would probably be awful.
• makes Chess people mad

lemme know what you think.

@kelly-ry4n so if you take a look in main.js, under the function game.checkLegalPawn,

if (pieceID[0] === 'w') {
    // standard movement
    if ((locTile - locPiece) === -8 && !occupied)
        return true;
    // first move can be two spaces forward
    else if ((locTile - locPiece) === -16 && !occupied && !hasMoved)
        return true;
    // attacking
    else if (((locTile - locPiece) === -7 || (locTile - locPiece) === -9) && occupied)
        return true;
} else {
    if ((locTile - locPiece) === 8 && !occupied)
        return true;
    else if ((locTile - locPiece) === 16 && !occupied && !hasMoved)
        return true;
    else if (((locTile - locPiece) === 7 || (locTile - locPiece) === 9) && occupied)
        return true;
}

I'm thinking this should be restructured but I'm not sure how. maybe I could make distinct functions for moving versus killing pieces. this function currently handles both using the occupied flag. lemme know what you think. I'll probably keep this structure for now and write the next functions for other legality shit.

I've built it in a framework and language that doesn't suck nutz

Do we use websockets or an http API. The endpoints remain almost the same.

One way, we have a persistent connection and can send stuff instantly (think we can 'push' from the server).

The other is easier, and we don't need to deal with sockets. Thoughts?

you can tell that we take this soopr srsly from our issue names and what not. I think we should write about socket shit here, in terms of what should be sent.

the first thing that should be done via sockets is determining which player is what colour. we can do this easily enough by having the first person to connect to the network be white, while the second person is black. then, send that information back to each client.

each time someone makes a move or takes a piece, we should have an "end of turn" event which changes the boolean on the client side saying that it's no longer their turn, and also emits the following info:

• new location of piece
• remove other piece if it was taken

kinda obvious I know but I'm just saying it for the sake of clarification. however, this event SHOULDN'T be emitted if the piece that just moved was a checkers piece and is able to jump again. we should be able to give the user the option of jumping again or ending their turn. this will probably be quite easy to check for.

I'm unsure of how often we should emit this, but we should check frequently if anything has been changed on the client side. maybe every time a click event is fired, regardless of where it is? we should check to see if it's their turn, what colour they are, other stuff.