|
|
|
1 Network brainstorming
|
|
|
|
1. 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.
|
|
|
|
2. 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.
|
|
|
|
3. We think we should use map preloading when players go to another room.
|
|
|
|
4. 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
|
|
|
|
5. maybe use another protocol for file transfer...
|
|
|
|
6. providing a REST API for WEB will make our lives better!
|
|
|
|
7. Create a big peer to peer network and only a web server.
|
|
|
|
8. 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.
|
|
|
|
9. Need to decide what will we do when the game disconnects? |
|
|
\ No newline at end of file |
