From Screeps Wiki
Revision as of 22:52, 19 September 2020 by Duckymirror (talk | contribs) (Added explanation for CPU limit on private servers)
Jump to navigation Jump to search

In Screeps, every operation requires a certain amount of processing power to be completed. Every player has a limit of how much CPU (measured in milliseconds of thread usage) that can be used in a single tick.


The limit of CPU time depends on multiple factors. A player with a subscription starts with 30 CPU. This is then increased by 10 for every Global Controller Level that the player has. Players who have purchased the Steam version, but who do not pay for a subscription, have 20 CPU regardless of their GCL. On private servers the limit is fixed to 100 by default. There are server modifications that change this (for example screepsmod-admin-utils which allows to mimic the official server's behavior).


For every tick that the limit of CPU is not consumed, the remainder is stored into a bucket. A bucket has a total capacity of 10,000 CPU. Every tick that usage exceeds the CPU limit, it is removed from the bucket. If the bucket reaches 0, and CPU usage is above limits, script execution halts. You may never use more than 500 CPU out of a bucket in a single tick.

Buckets are commonly used to combine multiple, heavier calculations to run intermittently over one or several ticks. This allows for a low average of CPU usage, with spikes to perform calculations that are then stored.


Each API method on the API Reference page lists CPU usage of the method ranging from const to High. const methods always require .2 CPU because they directly modify the game world. It is generally suggested to avoid making repeated calls to methods with High CPU usage. Many employ caching as a mechanism to avoid this.

Managing CPU

There are several easy-to-do CPU optimizations in screeps that may not be easy to catch when you first start playing.

reusePath opt & moveTo

moveTo is the go-to method for getting your creep to any given position and is what most users use when starting out. However, by default this method has an option called 'reusePath' which is set to 5. This means, that moveTo will store a path it creates for five in-game ticks before recalculating the path. Calculating the path to a given object can be quite expensive, depending on the distance and complexity. As the user grows in GCL and rooms, more creeps, means more pathing calculations per tick resulting in more CPU useage.

You can change this option by passing moveTo an object containing reusePath as a property in the object and the value being how often you want it to recalculate the path. Example: creep.moveTo(someRoomPosition,{reusePath:15}) Would cause the path not to be recalculated for fifteen ticks instead of the default five. It is important to note, however, that if a creep encounters an obstruction on its stored path (such as another creep) it will attempt to keep moving on its stored path until the path recalculates. This can result in stuck creeps or blockades, the user needs to account for these situations by resolving the block in the path, moving the other creep, deleting the stored path, or many other ways.

Redundant checks

Each method you use for a creep has a variety of checks it must complete before the action can move forward and can return an error code if the action encounters a problem. If a user is constantly calling a method that will never work, depending on when the action returns the user is paying CPU for these checks, when the action will never be preformed. As such, setting up your own checks to stop this, can save CPU, while this may not be noticeable with one room of creeps, many, many creeps it all adds up.

OK Intents that do nothing

If a user gets an OK returned from an action, that schedules an intent to preform that action which costs the user 0.2 CPU. However, even after the intent is scheduled it is still possible for the action preformed to not happen, thus costing an unnecessary amount of CPU that could have been used elsewhere.

Examples of OK intents that will not cause action:

  • A creep .move()ing into a wall. The move may be valid, and you will get an OK, but the wall will prevent the creep from executing the move when preforming the action.
  • A tower 'over-repairing' a structure. If multiple towers are attempting to repair a road, for example, but the first tower would have sufficed, when the rest of the towers go to preform the action, nothing will be done, however as the OK was given and intent scheduled, it still costs 0.2 CPU + any checks preformed to get the OK.
  • Multiple of the same action being called. If several of the same action are called, only the last one is preformed, however every action that got an OK returned will still be set as an intent, and cost 0.2 CPU.

Path pre-caching

If a user's creeps need to travel the same path repeatedly over and over, recalculating the path with moveTo or other methods every time is unnecessarily costly and only balloons in cost as you get more creeps. By using pathFinder or other methods, you can save paths to memory or global and use them over and over. There are several challenges that come with this, however it can be a very large CPU saver.

Memory & Global

Memory is very useful for carrying information across ticks, however, the cost of JSON.stringifiying() and JSON.parsing() the Memory at the end/start of the tick respectively is charged to the user. Meaning, as you use more memory, the cost for this process increases. Leveraging caching, global and, rawMemory, it is possible to store things without using memory albeit temporarily in the case of global/caching. This article is a stub. You can help Screeps Wiki by editing to add more information.

External Resources

This article is a stub. You can help Screeps Wiki by editing to add more information.