We are excited to announce we just launched the sharding system for the Screeps world! The second plane called shard1 already works with faster tick rate and waits for its first settlers! If you wanted to start playing but disliked long 5-second ticks, now is the time! TL;DR World shards are isolated from each other and run your code separately. Your creeps can travel between them using special portals. The original world becomes shard0. Portals will be closed during 60 days grace period, but you are free to (re)spawn on either shard0 or shard1.

Concept

Game performance in all aspects is an important area of our work. It was not left unnoticed by us that game simulation performance (tick rate) noticeably decreased lately due to the increase of the number of objects and growing complexity of players’ scripts. We understand it can lead to negative sentiment on the subscription-based model, and we won’t tolerate this situation. But the Screeps game world has grown to such an extent that the most powerful machine available from our hoster currently runs our database at 100% of its capacity. We can’t merely add runtime servers anymore since the database can’t manage such amount of I/O requests. We experimented with different setups of database sharding and replication, but all of them incur unacceptable overhead. We also tried different database management system (we use MongoDB currently), but it didn’t work out as well. It looks like the most effective way to horizontally scale our world without performance penalty is to review the very architecture of our servers cluster. Currently, our cluster can be represented in a classic “star” layout with the database in the center and runtime servers on edges. The game world is consistent and synchronized as a whole. We have moved from this architecture to a new layout of “multiple loosely coupled stars.” Our consistent game world will be divided into “shards” each with its own database of game objects, own game map, and own set of connected runtime servers. Creeps will be able to move between shards through special portals, but different shards will see time flowing independently without synchronization (i.e. Game.time in different shards will not match and tick rates will differ). Your code is executed in each shard separately. A special API allows you to determine which shard runs your code at the current moment. You will be able to set your CPU limit for each shard on a special page, and their total sum should match your account limit. The new system will lead us to an easily scalable horizontal system allowing for expanding the game world virtually without limitations and without increasing.

Timeline

By now, we’ve generated and opened a new shard1. It already has central sectors open for settlement. We’ll open new sectors around them as the need arises. The portals leading from shard0 to shard1 have already been created and put to place, but walled for 60 days.
No inter-shard interactions will be available during this period. You can settle in shard1 only by complete resettling there. You can think of shard1 as a giant Respawn Area and an opportunity to make a fresh start in the whole new world. During this period, we’ll develop and provide for testing special tools for managing CPU and GCL resources of your account and their distribution between shards. When 60 days are over, the portals will open, and outside invaders will appear to compete with native shard1 inhabitants for new territory!

How it works

• Your script is executed on each shard individually and independently.
• Your GCL and CPU limit should be allocated to each shard using the special section in the Overview UI or via API (still in development; currently you have full GCL and CPU in each shard).
• Console contents is broadcasted from every shard with the corresponding note in the console UI.
• Memory is isolated; you have separate 2 MB of Memory and 10 MB of Memory Segments in each shard.
• There is a special memory segment that can be used for passing messages between shards.
• Markets are separate. However, credits balance and history are shared between shards.
• Creeps can use special inter-shard portals in highway crossroad rooms to travel between shards in the same way as inter-room portals. These portals are permanent and may be regenerated only when the world is expanded. The name and ID of the creep remains the same on cross shard travel, but the creep loses time to live:
  • 800 ticks for creeps without CLAIM parts;
  • 150 ticks for creeps with CLAIM parts.
  This rule eliminates the abuse of inter-shard portals for quick travel in the same shard.

API Changes

• Added new global object Game.shard.
• Added new type of StructurePortal.destination object format with shard property.
• Added new RawMemory.interShardSegment.
• Added new Game.map.getWorldSize() method.
• Constants WORLD_WIDTH and WORLD_HEIGHT are now considered deprecated and should not be used.
• Removed obsolete and undocumented Room.mode property. If you used this property to check for simulation mode, please use this one instead: [noparse]Game.shard.name == 'sim'[/noparse]

These changes are supported in private server v2.8.0.