Technical Implementation: Difference between revisions
(→DB) |
(→DB) |
||
Line 48: | Line 48: | ||
* nest - about nests and the potentially colony living there | * nest - about nests and the potentially colony living there | ||
* nest_distance - actual distance between nearby nests | * nest_distance - actual distance between nearby nests | ||
* country - move the strings here and store a pointer in the nest-table | |||
* sub country location - move the strings here and store a pointer in the nest-table | |||
* items on the map | * items on the map | ||
** animals - location | ** animals - location | ||
** animals_log/history - what they did... some how. Needed? | ** animals_log/history - what they did... some how. Needed? | ||
** food | |||
* food | |||
* user - basic user data | * user - basic user data | ||
Line 62: | Line 63: | ||
* log - what happened and when. (id ref to types of actions) | * log - what happened and when. (id ref to types of actions) | ||
* log_user - what event are useful for what user | * log_user - what event are useful for what user | ||
* statistics, log of scores... or something... | |||
* chat - todo | * chat - todo |
Revision as of 20:51, 29 January 2016
Just some comments to myself:
- Server controls what is on the map (the client shall not assume anything)
Internal actions
- Show Map
- Show Map at pos x,y
- Show Map at nest n
- Help about n (predefined constants in app) - or use the wiki pages?
- Show spieces chat with prepared message/location x,y
etc
Determine water vs land
http://stackoverflow.com/questions/3645649/i-need-to-know-the-predefined-point-is-in-the-sea-or-on-the-land That pixel or one next to it just to bu sure?
Client
- Will have a service (or similar) run once per hour, or so, sending position (web or gcm). The pos is passivly get. I.e. if there is one, read it.
Client <-> Server
- All actions are asynchronous
- Send all waiting actions (in client) to one server script using a background thread.
- The client application holds a list of actions waiting to be performed (with a generated serial id)
- 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)
- The client updates data and remove confirmed actions from the list of waiting actions
- The client sends a new request with waiting actions (including those who where not confirmed)
- Notification from server if nearby actions take place, the notifications shall contain enough data to update the info in the client (typically attacks)
Animals
- Amout of animals: Linear to the number of active players.
- Have a an (average) lifetime and disappears after that time (no matter if in inventory or on ground)
- Show up nearby users, or on locations where users have been.
- Notifications to nearby users (with setting)
Food
- Pretty evenly distibuted on earth
- Only visible on zoomed in.
- TODO Decrease and disappear after some time? New show up. How?
- When looking at area x1,x1 -> x2,y2, maybe it "scans the lines" and the distance to the next food occurrence is relative to the latitude to get it evenly distibuted. (instead of checking a square pattern)
- TODO But how to figure out where to spawn more food and where has it already been done?
- Math pattern having a fixed amount of food and a table with the removed ones (and dropped) and let the patters slowly slide/change in some way...
DB
- nest - about nests and the potentially colony living there
- nest_distance - actual distance between nearby nests
- country - move the strings here and store a pointer in the nest-table
- sub country location - move the strings here and store a pointer in the nest-table
- items on the map
- animals - location
- animals_log/history - what they did... some how. Needed?
- food
- user - basic user data
- user_unit - about each unit connected foor each player (needed for notifications)
- user_location - track user location, once per hour or so to be able to spawn creatures at resonable locations, and prevent cheating.
- user_inventory - in some way....
- log - what happened and when. (id ref to types of actions)
- log_user - what event are useful for what user
- statistics, log of scores... or something...
- chat - todo