1 Network brainstorming
- We propose that the representation for the state of the game at a given time be stored on the server side. Access to the model would be managed by the server, who ensures consistency of the data, especially since we expect that the operations to the model are going to be numerous. To this end, we propose that all the operations that change the state of the game will be provided by an API.
- In our opinion, it would be best that a decision upon the language all the modules are going to communicate in is made as soon as possible. At the moment, the first possibility is to just use low-level sockets for the net- working part - it does not matter what language do we use. Otherwise, we propose to use a socket implementation that provides wrappers for the languages which are going to be used in the project.
- We think we should use map preloading when players go to another room.
- Debate on whether to use a TCP based protocol or UDP - it depends on the size of the game state- if it is too big, better use TCP on just the modifications to the game state 1. TCP is not necessarily slower if we find an option something like HTTP pipelining.
- maybe use another protocol for file transfer...
- providing a REST API for WEB will make our lives better!
- Create a big peer to peer network and only a web server.
- Maybe include a copy of the server locally, this brings two benefits: 1. transparent testing if the server and the client are coded in the same language. 2. the ability to play alone or on a local network.
- Need to decide what will we do when the game disconnects?