-
Notifications
You must be signed in to change notification settings - Fork 3
maps
This article shows you a possible implementation for maps. Feel free to use it and modify it to suit your needs. We'll try to keep it simple yet highly scalable.
- zoomable map, with world/region/city detail levels
- scalable: support millions of players
- performance: ensure the fastest response time possible
- secure: prevent hackability
- KVStore
Clan of the Cloud offers many types of storage with different attributes. To implement our maps, we'll use the very general KV Store. It's very flexible and fits our use case perfectly.
The ACLs (access control list) of KVStore will help secure our data.
- Batches
To make sure our implementation is not hacked, we'll use batches to write to our maps. Batches are very hard to hack, because they can implement any kind of security checks.
The world is made of many regions, made of many countries, and countries contain many cities. (x,y) coordinates are used to point to a region withing the world or to a country within a region, or to a city within a region.
Thus the coordinates of a city are (Xregion, Yregion, Xcountry, Ycountry, Xcity, Ycity)
.
We'll use a 10x10 grid for the world (100 regions), a 10x10 grid for countries (100 countries per region) and a 20x20 grid for cities (400 cities per country). That's enough for 4 million players.
With this 3 levels map, each map will be lightweight enough and fast to load. You could also use only 2 levels, depending on your game design, or implement sparse maps.
Players will choose a free spot wherever they want to put their city. We'll show them a world map with every region with it's available space. We'll also show the available space in each country within a region.
To achieve the best scalability we'll use the KVStore to write/read a single key at a time. Our goal is O(1) performance characteristics, where performance does not depend on the size of the map or the number of players.
We'll use one key to store the first map level, the world. Its value will contain information about r
regions.
Then we'll use r
keys, one for the map of each region. Each will contain information about c
countries.
Then we'll then use r*c
keys, one for the map of each country. Each will contain n
cities.
Then we'll the use up to r*c*n
keys, one for the map of each city.
With this system:
- To read any map, we'll need only one read, and the game can probably cache the coarser level maps
- To place a new city on a map (or remove it), we'll need to write to 3 keys
- To modify a city, we'll need to write to only one key
We need to make sure players can read maps, but only write to their own city. We also want to ensure new players choose a free spot for their city.
ACLs will provide all we need, and more. For instance, you could allow write access to the players' buddies or to his clan with ACLs.
We should adopt a naming schama where each key is easy to recreate...
-
Map
-> the world map -
Map_{x},{y}
-> the region at (x,y) -
Map_{xr},{yr}_{xc},{yc}
-> the country at (xr,yr,xc,yc) -
Map_{xr},{yr}_{xc},{yc}_{x},{y}
-> the country at (xr,yr, xc,yc, x,y)
This way, we have a clear naming for all our maps.