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.
The game world is consistent and synchronized as a whole. 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.Ĭurrently, our cluster can be represented in a classic “star” layout with the database in the center and runtime servers on edges. We also tried different database management system (we use MongoDB currently), but it didn’t work out as well. We experimented with different setups of database sharding and replication, but all of them incur unacceptable overhead. We can’t merely add runtime servers anymore since the database can’t manage such amount of I/O requests. We understand it can lead to negative sentiment on the subscription-based model, and we won’t tolerate this situation.īut 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. 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. Game performance in all aspects is an important area of our work. Portals will be closed during 60 days grace period, but you are free to (re)spawn on either shard0 or shard1. Your creeps can travel between them using special portals. TL DR World shards are isolated from each other and run your code separately. 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!
0 kommentar(er)
