jackbenn / gengo Goto Github PK

The server sometimes crashes. I'm not sure why. Update with details from next crash (restarted 6/6/21)

Options in how to do it:

1. Calculate when called, by iterating over all spaces and checking for stones
2. As above, but keep a list of stone in the Board or Game object to make it easier
3. Add and subtract from score as stones are played and captured

There's a bug in the web app where the players switch under some undo/pass situations.

It should be fixed, but ultimately a client should know which player it is.

Based on #17, the player should be able to choose which side is black. This will be passed to the server.

Right now it's confusing if it's your turn and which side you're playing.

Right not the lines are between the squares, not at the intersections, and the stones are squares, rather than circles.

This will involve a change of how data is sent from the server.

As per https://brython.info/static_doc/en/install.html we can just download brython from somewhere else. This should be faster and less confusing.

There should be a way to observe existing games in the web app, and maybe load old ones.

For performance reasons, and to learn javascript.

Require the game name to exist before starting.

Maybe also check it isn't being used, or something.

Right now people go to the same page to start and join a game, and if two happen to start a game with the same name, the first one is black.

How it should work:

One player creates a game. They enter various options including

• game name
• rule options
  * board size,
  * scoring type?
  * suicide legal? (not yet implemented)
  * overlap options?
• whether they will play black
• handicap? (not yet implemented)

The second player goes to the join page, where they see the games waiting to start. They can choose one to join.

Right not it's not that obvious if stones are neighbors. This would involve sending additional data from the server.

The alternative is to have the overlap regions pulled back a bit, or draw a border around a group, but those are a lot harder and require sending more data from the server.

The index page should be an intro, with a brief description, and leading to other pages on starting a new game, joining an existing one, and observing.

Although playing on two computers is generally more useful, there should be a way to run it on a single computer. This should generally be as if was before I got both boards working. This would be easier to demonstrate, easier to play with someone in the same room, and easier to generate boards for documentation.

This might be from the new page in the web app, but it might be hidden from that, and instead have a single command that will start the web server and game server and open a window to the correct location.

I updated brython version and changed it to download it from the cloud in commit b44144f

One of those caused it to no longer list games (I've confirmed it works at the prior commit).

The workflow currently is players alternate moves. Instead of moving, a player can undo an opponent's last move.

This should be changed to one where after a player moves they have to click a "commit" button to show it to the opponent and let them play. If they click the "cancel" button instead it will be undone and the player can move elsewhere.

So the flow is:
Client: on_click,
send move to server
activate commit/cancel buttons
on_click commit/cancel:
send commit/cancel to server, deactivate buttons
on_message:
draw board, set my_move as appropriate

Server: await recv move:
make move,
send to current player, my_move=False
await commit or cancel
if commit:
send to other player, my_move=True
if cancel:
undo move, send to current player, my_move=True

It should send the board before the first move

the performances of the web app is pretty bad, so that one has to wait several seconds between clicks. It could be in the logging, or in the score counting, or just using python, or in the websockets.

The game should allow free-move handicaps, where one player can play several moves at the beginning.

In the future, this should be in the web app as well.

This would be easiest with an alert box but maybe better with a separate area in which it's printed.

This should be as command-line options.

1. Make array of ownership (0, 1, -1 for not yet, 2 for ambiguous)
2. Assign 0 for black based on overlap
3. Assign 1 for white based on overlap, or 2 if assigned to 1 already
4. Go through all spaces. If unassigned,
   Set tentative ownership to -1, Do breadth-first search through all unassigned points and change tentative ownership to 0, 1, 2 if those are seen (or 2 if both are).
   Set all spaces visited to final tentative ownership.
5. Count numbers in each group.

The current rules say a player can't play in one's own stone's overlap. That might not be the best approach; an alternate ruleset would allow playing in the overlap of one's own stones (but not one's opponents).

This might be a better ruleset; if it were an option I could investigate.

This has a few parts:

1. add an option to the rules
2. have it display the overlaps it separate colors (light grey for white only, dark grey for black only, medium grey for both). I'm not sure how this might affect the command-line version.
3. actually change the rules

Probably use the logging library

The join page should only list games that haven't been joined, and that have an active connection on the other end (not sure how to check this yet). Ideally it should also list the rules of the game in table form. It might also list games in progress separately.

Save game state on completion; eventually load game from db

Based on #17 add an option to choose the overlap in the startup screen. For this issue, the player gets a three hard-coded choices and these are passed to the server. In the future the player can specify them.

The web app does not finish a game. The server should check is_done. If it is, it should display the scores (both types?), stop accepting new requests, and remove the connections from the list.

Right now we're parsing with eval which is pretty unsafe.