lordsentox / othello Goto Github PK

Detect when a game is over and who has won, once the game is over.

At the moment, if someone changes their local config files, the changes are always getting pushed. This is of course not desirable. It should already be okey, if the config files are added to the .gitignore and then the ones that are synced are the example config files, which you can copy and rename. Then everyone can customise their config files without worrying if it
upsets the repo state.
However, a finanl solution is open to debate.

The player should be able to choose how big the game should be, so that it works on all screen sizes.

A player can request a game of othello from another player on the server.
The other player should be able to accept or deny this game and relay that to the other player.
The server creates a new instance for them and sets the game up.

It should be something along the lines of your client.toml configurations are wrong and suck

instead of Could not find configuration file 'client.toml'

It is tedious to always provide everything on the command line.
A config file would be much nicer and is already kind of underway in form of the server.toml
which is currently unused.

Once two players have started a game and have been assigned their colour, they can place stones on the board at places that are allowed by the rules of othello.

Everything the Score does could be much better placed into the board implementation.
The DrawableScore can then require to have a board reference to draw.

If implemented, this would be a configurable option in a menu that can be turned on or off and can be seen as a 'learning tool' for players new to othello.

Should there be a fullscreen mode for the game? What exactly would it look like? How would the elements scale, the background be filled, etc?

The technicalities of how this project should handle animation should be decided on. Should the game load image sequences of externally created graphics/animations, or should all the animations be interpolated by the game itself? Or must both techniques, by necessity, be used depending on the complexity of any given animation?

Or is the game perhaps better off without animations altogether? (development-resource-wise, but perhaps also from a visual design perspective -> the minimalism could suit the project better)

If 'in-software' animation is used, there should be a more-or-less friendly way for interpolated animations to be written/modified by graphic artists and programmers.

I don't know what to do to start the game.

This issue includes suggestions for a better terminal interface in the final version of the game:

• coloured output (potentially using this package)
• a more useful welcome message
• tab-completion?

Currently, two general visual design approaches exist that are diametrically at odds, and the question is which of the two to use for the final game to strike a good balance between good game feel and avoiding unnecessary complexity and effort in regards to developing graphics, which is not the main focus of this project.

When players disconnect from or connect to a server, the updated client list should be relayed to all other clients as a status report.

The board is currently drawn to emulate a lamp pointed down at the centre of the board. This is baked into the board.png texture as a coloured gradient. Should I try to have shadows be cast over the pieces and the board as a seperate texture?

This problem is especially obvious with pieces on the boards edges and it also results in the game board looking very repetitive when there are many pieces on the board.

This could potentially be alleviated if a texture for the 'lights/shadows' is used separately and drawn above all the elements as an overlay or multiply.

However, this might also make the board less visually readable, if done poorly …

When a client attempts to login with a name that had already been taken, instead of gracefully declining the client the server just crashes.

Once the graphical style of the game baord is more or less fixed, the desired interface elements should be determined, created and set.

Furthermore, to visualise the appropriate UX flow of these interface elements, mockups showing possible or final solutions to these problems, could be helpful.

First, the UX and look of the GUI should be thought about (e.g. on paper) and drawn.

Mockups will only be created if they are necessary to communicate certain design ideas. Therefor, this goal is marked as optional.

One player may want to play against multiple opponents at a time, so it should be possible to
have multiple games running, and not just one.

Once the players can place stones on the board, the server needs to manage the turns of the players to avoid mayhem and let the players play to the actual rules of othello.

Players can see all other players on a server if they request to see the list.

Currently, the packets do not have much access to the server context.
That should change, but also the packets should be kept simple and slim.