Technical Implementation: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
Just some comments to myself: | Just some comments to myself: | ||
* Server controls what is on the map (the client shall not assume anything) | * Server controls what is on the map (the client shall not assume anything) | ||
| Line 8: | Line 7: | ||
* Map at nest n | * Map at nest n | ||
etc | etc | ||
== Client <-> Server == | |||
* All actions are asynchronous | |||
* Send all waiting actions (in client) to one server script using a background thread. | |||
** A json-list with actions | |||
** All actions have a serial number (unique to user and say 5 min?) and info on what to perform | |||
** If the action already took place (serial number) just send the updated info (for that action) | |||
** The server responds with apropriate data on all actions or error messages and also a part with new data (that might have been changed) | |||
* Notification from server if nearby actions take place, the notifications shall contain enough data to update the info in the client (typically attacks) | |||
Revision as of 10:16, 27 January 2016
Just some comments to myself:
- Server controls what is on the map (the client shall not assume anything)
Internal actions
- Map
- Map at pos x,y
- Map at nest n
etc
Client <-> Server
- All actions are asynchronous
- Send all waiting actions (in client) to one server script using a background thread.
- A json-list with actions
- All actions have a serial number (unique to user and say 5 min?) and info on what to perform
- If the action already took place (serial number) just send the updated info (for that action)
- The server responds with apropriate data on all actions or error messages and also a part with new data (that might have been changed)
- Notification from server if nearby actions take place, the notifications shall contain enough data to update the info in the client (typically attacks)