happy0 / ssb-chess Goto Github PK

It should be possible to request a rematch when a game ends.

The invite message should link back to the original game that the rematch was derived from so that a client can follow a game they're looking at forward.

Perhaps add an optional 'rematchFrom': field to the chess_invite type message.

it might be nice to have "confirm" button before commiting to a move

Hey @Happy0!

I'm running into ssbc/patchbay#211 and it looks like it may be resolved by [email protected]. It looks like the release appears on GitHub, but I don't see it on NPM. Would you mind publishing the latest version to NPM if you have some time?

Thanks! Let me know if there's anything I can help with.

A player profile should make it possible to navigate:

• A player's past games.
• A player's current games.
• Games the player has won.
• Games the player has lost.
• Games the player has drawn.
• Games the player has played against a specified player.

It should aggregate:

• Number of visible wins.
• Number of visible losses.
• Number of draws.

It should be possible to export the PGN (https://en.wikipedia.org/wiki/Portable_Game_Notation) from a game so that it can be imported into other chess software / websites for analysis with the support of an engine, etc.

I assume there must be an ssb library for querying directly.

The approach used at the moment is fine because there aren't many games in progress.

It makes installation a pain, since electron doesn't like it being a dependency for some reason.

Update the situation object with win / draw / status information and add ability to filter by 'ended games' and only include games in progress in 'getGamesInProgress' functions

When opening a game / a games miniboard page, live pull streams are created (watching for incoming replies to the underlying game threads) that never get cleared up. This can be fixed in patchcore's backlinks.obs.filter module: ssbc/patchcore#67

Chess messages should have a 'branch' field that points back to the previous message.

At the moment, sometimes a user's follow graph is such that they may only be able to see 'one half' of a game (one player's moves), but the other player might be outside their follow graph. ssb-chess-db deals with this at the moment by just ignoring games where the full game isn't visible to spectate.

ssb-ooo makes it possible to request messages that are not visible to you from peers (there are some threads on this on scuttlebutt.)

Note: this is not an issue for your own games, as you can only invite direct friends (who are always visible in the follow graph.)

For the following moves this previous message should be:

• chess_move : The previous chess move or if it is the first move, the invitation acceptance message (chess_invite_accept).
• chess_invite_accept: The chess game invitation message (chess_invite.)
• chess_game_end: The previous game move if a move was played in the game, otherwise the game acceptance message (on immediate resign, without any moves being played.)
• chess_chat: The previous chat message that was seen. This will allow people to see who someone is responding to in the chat for public spectator chats.

Make the chat box next to games a 'spectator room' for people who are spectating the game. This won't be visible to the 2 players on the ssb-chess app. It will be visible in the scuttlebutt feed / underlying database.

However, we trust people to play on good faith because:

• 'Chess club amoungst friends' is a more appropriate metaphor for ssb-chess
• You can only challenge your friends to games.
• There is no rating system, so motivation to cheap is social. If people want to cheat for ~ social capital ~ they'll do it anyway :P.

bebot managed to move twice, somehow...

sbot links --dest "%rRPFDrNIGcg6BOgvza4S3pzdYqHUg0kxVorvdD15F10=.sha256" --values

I suspect because the m.redraw (on hiding confirmation) is in a setTimeout, the 'on confirm' click can rarely fire twice, or something... Tricky times.

Need to:

• Disable the 'confirm move' button after the first click. Make sure it's re-enabled on the next move, after a redraw.
• Gracefully recover from a user moving twice on their move by choosing the first move (due to a buggy client implementing the protocol.) Eh, I hope that's the right philosophical approach, anyway :P.

There should be an 'offer draw' button that offers the opponent a draw that they can then reject (chess_draw_reject) or accept (chess_game_end draw).

In a threefold repetition situation, a 'claim draw' button should appear to allow the player to claim a draw.

Need to think about how this would work at a protocol level. Just putting this issue here as a reminder.

occasionally while playing chess patchbay will crash. here is the error message that seem relevant to this:

TypeError: this.removeWatches is not a function
    at Object.onremove (/Users/frankie/apps-from-others/patchbay/node_modules/ssb-chess/ui/game/gameView.js:268:12)
    at onremove (/Users/frankie/apps-from-others/patchbay/node_modules/mithril/mithril.js:807:107)
    at continuation (/Users/frankie/apps-from-others/patchbay/node_modules/mithril/mithril.js:783:5)
    at removeNode (/Users/frankie/apps-from-others/patchbay/node_modules/mithril/mithril.js:780:3)
    at updateNode (/Users/frankie/apps-from-others/patchbay/node_modules/mithril/mithril.js:618:4)
    at updateNodes (/Users/frankie/apps-from-others/patchbay/node_modules/mithril/mithril.js:520:12)
    at Object.render (/Users/frankie/apps-from-others/patchbay/node_modules/mithril/mithril.js:958:3)
    at run1 (/Users/frankie/apps-from-others/patchbay/node_modules/mithril/mithril.js:1160:40)
    at lastUpdate (/Users/frankie/apps-from-others/patchbay/node_modules/mithril/mithril.js:1172:5)
    at /Users/frankie/apps-from-others/patchbay/node_modules/mithril/mithril.js:1174:55

I'ma list stuff 😅

• arrow keys still trigger history when in chat box
• the whole: (i couldnt reproduce it so might have been lying)

  heres a bug tfw... oh learning new things all the time i didnt hit enter on that message i just moved away from this view

• chat sometimes reorders its self
  feature requests (feel free to ignore):
• put the history in a table and label the columns based on the user with the moves under neath

React looks like a pain to get set up with electron... Maybe use mithriljs instead? :o

The observables created by ctrl/game.js and their subscribes don't get cleaned up properly, resulting in lots of instances of the pull-stream (and observable) made by user_game_updates_watcher.js.

Over time, ssb-chess gets more sluggish because of this (as routes are changed.)

I should

• Tidy up ctrl/game.js so that it doesn't require intermediate observables that need to be removed by making a utility function to turn a promise into an observable. This should hopefully mean the removal of the listeners cascades down (eh, I think.)
• Remove the subscribers when mithril onRemove lifecyle method is called for components using observables.

At the moment the low level stuff that builds the games from move messages trusts clients to not try to break things :P.

Something should be added to make sure that the user's client agrees that the move another client made is legal and that the origin / destination square match up with the FEN for the move / the person who claimed to win the game did so, etc.

I'd be happy to help with this if you think it's trivial (or not!), but I'd personally love a confirm dialog after clicking "Resign". Thanks for all your work on this project, it's a ton of fun!

is this how you want it too look?

If we want to get ssb-chess into the browser eventually, we should get rid of the patchcore dependency which I think is only used to wrap the call through to ssb-backlinks at the moment.

Patchcore brings in dependencies which assume a nodejs environment (such as ssb-client, secret-handshake, etc.)

A good way to do this might be to 'abstract' the things we expect / need from the ssb-client sbot object that is passed as a parameter to this module into functions that can be implemented in different ways depending on what environment it is in rather than requiring ssb-client itself.

E.g. expect an object that has the following functions:

backlinks,
messagesByType,
publish,
get,
// Social graph functions to find friends / followees
...

The game should make sounds when you or your opponent moves (should be able to be optionally disabled)

It would be good to have a quick way to go to your next active game (where it's your move). Two arrow keys at the bottom off the 'game view' page when there are games where it is your move would be good.

Should also add keyboard shortcuts for this.

Hi

I was going through the tons of security bugs in patchbay and in that process fixed ssb-backlinks. Could you update it to latest version? Thanks :)

Cannot read property 'role' of undefined
TypeError: Cannot read property 'role' of undefined
    at isPromotionMove (/home/bencevans/Code/patchbay/node_modules/ssb-chess/ui/game/gameView.js:52:37)
    at after (/home/bencevans/Code/patchbay/node_modules/ssb-chess/ui/game/gameView.js:127:17)
    at /home/bencevans/Code/patchbay/node_modules/chessground/board.js:11:43

This is happening on the most recent version of patchbay master ssbc/patchbay@c6d3917

Steps to reproduce:

1. King and Rook in a position to castle
2. Click King ... Green dots appear
3. Click Rook... 💥 ... error page shows with above stacktrace

Sometimes, if you've not looked at one of your games for a while, it can be difficult to remember what your strategy was (or things you noticed about your opponent's strategy.)

A note tab should be added near the chat box. It should allow the user to write notes to themselves. We could post these to the user's feed, but as a private message so that only they can see it.

Perhaps a new message type could be added to the protocol for this

{
  "type": "chess_note",
  "note": "Oh noes, they might be able to do a discovered attack if I move my bishop from in front of my king."
  "ply": 10
}

(ply is the move number the note was made on - it might be useful to clients to display.)

Someone in the mithril.js gitter suggested it might be because

I'll try removing the redraw in https://github.com/Happy0/ssb-chess/blob/master/ui/game/gameActions.js#L102 when I get home :)

@frankiebee there is hope! :P

It's a pawn on the board until you hit 'confirm'

would be supper nice if you could see the pieces you've taken and visa versa

There's an insert phase (for game invites), and 2 update phases (for game invite accepts and game ends). These 3 steps should be serialized, but the queries within these stages can be parallelised.

This is so we don't run an UPDATE statement on a row before it has been inserted.

The games listed in the application tabs should be sorted by those games with the most recent activity.

Note:

• The observables with the list of games underlying these tabs should be updated when a game finishes / starts. However, the list should not be re-ordered when a game in progress that is in the list has an update.

At the moment, I believe the ordering is rather in ascending order of recency, or random. Not sure.

Can observe a given game ID for update messages then map it to a 'situation' observable. The game view / summary can listen for updates on this observable then update the UI accordingly.

Should simply things a lot :)

Move handing in game.js controller is hacky at the moment (for testing.)

This could be improved by just having one event listener for the scalachessjs event listener and emitting the new situation as an event upon a successful move with the gameid as the reqId (maybe using the PubSub library.)

At the moment, you have to find the game yourself...

When I loaded patchbay + ssb-chess without the internet (after not being online for a day or two) and then going online again I noticed the following:

• It was my turn to play on 4/5 boards but this wasn't reflected in the 'moves' count (which was 0.)
• On redraw, the miniboard states moved briefly to the latest move (from the last one in the database before being caught up and going online.)
• After moving on one of the boards, the 'moves' count still wasn't updated.

Theory:

• The 'date.now()' timestamp given to the 'user_game_watcher.js' pull-stream that feeds into the observable that is used is using the asserted timestamp of the scuttlebutt message (the time the other client claimed to send it at), rather than the time received so when connected to the internet and catching up with missed messages, these don't get put into the stream.

The miniboards have an observable that is in conflict with the outer view's default that comes from the observables that aren't updated due to the above.

the miniboard for %o/GxGQ/dlCNi+monDfrFJl8MAPWGLMdP0XWnqFBr4XA=.sha256 is displayed as though happy0 is playing as white (but in the model he is playing is black.)

It would be nice if the UI only allowed you to create on game invitation per user