What Is Screeps? How the Programming Strategy Game Works

What is Screeps?

Screeps: World is a persistent multiplayer real-time strategy game controlled primarily through JavaScript. Instead of directing every unit with repeated clicks, you write rules that inspect the current game state and decide what your colony should do next.

This introduction explains the game’s basic control model, the five objects a new player should recognize, and the first Energy loop that keeps a room developing. You do not need to write code or memorize any API methods yet.

Screeps combines a shared strategy world with programmable automation. Players establish colonies, gather resources, create units, develop rooms, claim territory, and interact with other players. The defining difference is how those colonies are controlled: your units and structures follow JavaScript decisions that you write.

In a conventional strategy game, you normally select a unit and issue its next command yourself. In Screeps, you describe the conditions under which a unit should act. A worker might harvest when it has free capacity, deliver Energy when full, and choose another task when its original target disappears.

Your script is evaluated once during each game tick. It reads the current world state and submits actions for your Creeps and structures. Those commands are not completed instantly while the script is running; the game processes them after player scripts have finished for that tick.

How code changes the way you play

Programming does not replace strategy. It moves strategic decisions into a system that can keep making them without constant manual input.

You decide where Energy should go, which jobs matter most, when a new Creep is worth its cost, and how the room should respond when conditions change. A successful colony therefore depends on more than valid JavaScript syntax. It also needs sensible priorities, observable state, and recovery behavior.

In Screeps: World, deployed scripts continue to run while you are offline. The Simulation Room is an exception. Persistent execution also does not guarantee that a colony will remain healthy: code can still fail to replace a dead Creep, lose a target, send units into traffic, or spend Energy on the wrong task.

Five objects to recognize first

Screeps contains many objects and systems, but a new player can understand the first room by starting with five.

Names such as Harvester, Builder, and Upgrader are conventions created by players. They are not automatic classes assigned by the game. A Creep called Builder will build only when your code gives it a suitable body, target, and build() action.

How the first room Energy loop works

The earliest room economy can be understood as a repeating flow:

Source → Creep → room tasks → more Creeps and room progress.

1. A Creep reaches a Source and harvests Energy.
2. The Creep transfers that Energy to a Spawn or Extension, or spends the Energy it carries on actions such as building and upgrading.
3. The Spawn uses available room Energy to create additional Creeps.
4. Other Creeps can upgrade the Controller, build structures, repair damage, or support the room’s resource flow.
5. As the Room Controller Level increases, the room gains access to more structure capacity and more advanced systems.

None of this happens simply because the objects exist. Your code must choose a Creep, inspect its state, select a target, submit an action, and make another decision on a later tick.

What do you actually do as the player?

At the beginning, your job is to turn a few visible objects into a small system that can repeat useful work.

• Observe what exists in the current room.
• Write one small rule for one Creep.
• Watch what happens over several ticks.
• Read return values, logs, and changing object state.
• Adjust priorities when the room needs Energy, workers, construction, or Controller progress.
• Add recovery behavior when a Creep dies, a target disappears, or the room lacks enough resources.

You are not expected to design a complete artificial intelligence on the first day. A readable room that can harvest, deliver Energy, replace a basic worker, and continue across ticks is already a meaningful first system.

What you do not need to learn yet

This first lesson deliberately stops before the code editor, Console commands, body design, movement, return codes, Memory, markets, combat, and multi-room architecture. Each of those topics becomes easier after the basic game model is clear.

Beginner boundary: start with one visible room and one observable task. An elaborate role framework or multi-room architecture may look impressive, but it makes early mistakes harder to understand.

Persistent world does not make Game persistent state

Screeps keeps the game world running while you are offline, and your deployed script is executed on game ticks. The official scripting model also says that the global Game object is created from scratch and filled with current data on every tick. Those are two different kinds of persistence.

The official Memory guidance is especially useful here: do not put live game objects into Memory. Store a stable identifier when you need one, then resolve a fresh current object with Game.getObjectById() or another current Game lookup. The Memory guide covers durable state; the global-cache guide covers rebuildable runtime data.

Automation is a repeated decision cycle, not one long command

A useful first mental model is not “tell the Creep to harvest forever.” It is “on each tick, inspect current state and choose the next valid request.” For a simple worker, the control idea can be written before you learn the exact action APIs:

if (creep.store.getFreeCapacity() > 0) {
  // Choose a current Source and request the next
  // valid harvest or movement step.
} else {
  // Choose a current delivery target and request
  // the next valid transfer or movement step.
}

The exact movement ranges, return codes, target policies, and Energy mechanics belong in their dedicated lessons. The important architecture is:

current Game snapshot
→ read durable Memory only when needed
→ choose one bounded decision
→ submit a game-object method
→ later tick: inspect the new snapshot
→ persist only the durable state you actually need

Commands are processed after player scripts for the tick, so a same-tick method result is not the same thing as later world-state evidence. The tick and game-loop guide develops that boundary in detail.

Where to go next

1. Open the first-room guide to find the room view, code editor, Console, Spawn, Source, Controller, and owned Creeps.
2. Read the tick and game-loop guide to understand why your script runs again and why actions often require several ticks.
3. Continue to the first harvesting tutorial when you are ready to control a Creep with working JavaScript.

The English beginner roadmap keeps all twelve lessons in order. Use the Screeps glossary when you need a short definition of Creep, Spawn, Controller, tick, Store, or another core term.

The key idea to remember

Screeps is a persistent strategy game in which JavaScript replaces repeated manual commands. Rooms provide the space, Sources provide Energy, Creeps perform work, Spawns create new Creeps, and Controllers drive room development.

Once your code can connect those objects into a loop that survives changing conditions, you are no longer controlling a single unit. You are operating an automated colony.

Official sources

• Screeps Documentation: Introduction
• Screeps Documentation: Scripting Basics
• Screeps Documentation: Control