Screeps: World News

We have always put little attention to graphics in Screeps, since this is a rather niche game for programming nerds. In terms of technology, the game engine has been a simple set of SVG objects moving across the web page. It allowed for rapid development without distracting on complex visual components, but it ruled out any appealing visual effects (like lightning). Besides, this approach suffered from subpar performance when a lot of objects were on screen. So it's time to change that!

In this update, we are excited to reveal a full-blown graphic engine for Screeps based on WebGL and PixiJS. It will allow you to:

• Leverage your machine's GPU even in the browser to significantly boost performance without any lags when scrolling.
  
• Save your laptop's battery juice since GPU is much more energy-efficient for this task than CPU.
  
• Add new visual effects to enrich the game atmosphere and yet retain our usual relaxing, abstract style.
  

In the picture above, you can see some samples of how the new renderer transforms the game when activated. The new feature is beta so far, so to activate it, opt in using the checkbox in the Display Options section of the right panel. Not all features have been 100% migrated to the new renderer yet, and bugs are possible, but you can get a whole new impression of the game right away!

Please inform us about any issues you encounter in comments.

It’s big time! 2 months after its creation, shard1 is available for settlement from outside. The portals leading from shard0 to shard1 and back open their doors for all the settlers, traders, and highway bandits out there.

But aside from the evident feature of transferring players’ creeps between worlds, these portals will leverage another interesting game mechanics, NPC Events.

We won’t delve deep into all the details but leave it for you to discover, especially since the events content and mechanics will change with time. But one thing is sure: it’s worth keeping your eyes on what comes out of these portals (including with your Observers), it could be something tasty!

By the way, a little hint for you: when an NPC creep that took part in an event like this dies, its resources don’t drop on the ground but are placed in a container created automatically so that you can conveniently grab them in time.

Good luck hunting!

• All credits amounts now work with 0.001 precision, including order prices, credits balance and transactions history. User credits balance and order prices are stored in the database as thousandths in integer format which prevents rounding errors. In order to update your private server data, an automatic database upgrade will be performed, see this commit .
• Added new StructureSpawn.spawnCreep method. createCreep and canCreateCreep are now considered deprecated, but still will be available for backwards compatibility. See discussion in this pull request for details.
• When you click “Respawn”, all structures now don’t vanish, but change their owner to SYSTEM_USERNAME, so that other players are able to withdraw resources from them.

These changes are supported in private server v2.10.0.

• Added new global property Game.cpu.shardLimits.
• Added new global method Game.cpu.setShardLimits.
• Added UI for assigning CPU to the shards menu.

GCL is shared between shards and doesn’t need to be assigned to a specific shard.

• attackController applies 1000 ticks of upgradeBlocked and decreases the ticksToDowngrade by 300 * ticks. The claimer creep will only need 1 tick to do this amount of damage. The creep will not be able to do another attack until upgradeBlocked is back to 0.
• upgradeController restores 100 ticks of ticksToDowngrade rather then resets it immediately.
• While the controller is downgrading, new level cannot be triggered even when the controller has enough progress (progress is not lost but accumulated).
• Safe mode activation is not possible when the controller is downgraded for 5000 or more ticks.

These changes are supported in private server v2.9.0.

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.



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.



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!

• 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.
  

• 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.