riftadi / dragonsarena Goto Github PK

The design now is a mess because it is a quick fix for previous simple design. Create better design for the TSSEngine, GameState, GameBoard, Characters, and Bots classes.

Introduce ZeroMQ to make the transfer of the Messages and the Gamestate working over it.

• MSG via ZeroMQ

• Valid Methods to make sure actions of MSG are valid game moves

• Separate Gameboard. Decode it as array of player ids. If a player joins the game the server assigns a position and spreads it.

Make sure that a client can not send too frequent of commands which he could not perform currently.

This means especially validating if the current command is a valid operation.

Flat structure is messy and not scalable, let's make it modular and hierarchical.

Add an interesting readme file.

A masternode should broadcast its inizial timestamps to the others for time synchronisation issues

idea: Send it with the alive topic

create a new file which is only responsible to show the gui

• gui has to run on main thread
• just listens to gamestate and game over topic

a mechanism to see if the other servers are still alive or not
a server sends a message under the alive topic to indicate to the others that is still alive

server who listens to this topics cut the connection if after a threshold (1sec) no new alive message is received.

A server should publish the received command of a client in order that other servers can subscribe to it.

Point of discussion is when this should happen.

• as soon as the message is received
• later when processing the message for the first time

use the provided game trace archive to test the system. See http://gta.st.ewi.tudelft.nl/

As in here http://amturing.acm.org/p558-lamport.pdf

In MacOS the GUI is crashing because it is running on a thread, move the GUI to the main process.

Let's write this in DESIGN.md file in 12-design-document branch and use this issue to record our decisions.

Implement Trailing State Synchronization.

make sure that the client can crash and rejoin the game

• use id which does not change after restart
• before spawning make sure if the current user id is already taken (or let the server ignore the second spawning message)
• log user commands on server for fail rescue

a client submits an spawn command and the server places this character on the gameboard. We have to find a solution in which we can guarantee that the character gets placed on a field which is not occupied by another player in the meantime on another server.

We need to separate the main.py into several files which contain one object each.