chessers's People
Forkers
brucejohnjennerlawsochessers's Issues
ideas
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
Login?
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.
Overall Application Design/Routes
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?
en passant
@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.
code formatting
@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.
u can archive this
I've built it in a framework and language that doesn't suck nutz
Sockets or http API
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?
socket SHIET
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.