Knowing how hard it is, I didn’t want to wing it. So this series is less a victory lap than a build log: how I started from a testbed instead of tactics, and how a vague goal, “move the blob in,” turned into a handful of precise, measurable questions. This first post is the map. It’s mostly a tour of the ideas that didn’t work, because that’s where the questions got sharp.

Three goals that won’t sit still

Strip the blob down and there are only three things it’s trying to do, and they pull against each other every tick:

• Survive: don’t let a single creep die to focused fire.
• Advance: close the distance to whatever you came to kill.
• Park: once in range, hold still and keep as many attackers shooting as possible.

Advancing means walking into massed tower fire that only gets worse the closer you get; parking deep is where you do damage and also where you die. And the enemy is a black box: I don’t get to know who they’ll shoot. The first real decision of the project was to stop guessing. I never model the enemy’s mind, only my own worst case. If a creep survives any focus the defense could put on it, I don’t care what it actually does. That one move turns “what will they do,” which is unanswerable, into “what’s the worst they could do,” which is just arithmetic over the towers and defenders in range.

That’s the pattern the whole series is really about: taking a question I can’t answer and beating it into one I can compute and measure.

Physics first, policy second

Before writing a line of tactics I built a deliberately dumb simulator. It knows Screeps combat physics: how damage lands, how heal nets against it, how moves and fatigue resolve, and nothing else. Hand it everyone’s intended moves, attacks, and heals for a tick and it returns the next state. That’s the entire job.

Every actual decision (where to move, who to heal) lives outside it, as a function that reads the world and proposes intents. The simulator only grades. It’s a wind tunnel: the engine is the air, each tactical idea is a shape I drop in and measure, and nothing I’m testing also gets to be the thing doing the measuring.

This is the highest-leverage decision in the project, entirely because the physics is pure and deterministic. Determinism is what lets me run thousands of ticks a second offline, isolate one idea, and replay any battle exactly the same way twice, which is the only reason the A/B numbers further down mean anything. The search layer that sits on this seam (how you pick a joint move for the whole blob each tick without it costing a fortune in CPU) is the most involved engineering in the project, and it gets its own post.

One classifier, shared by both halves

Two layers do the deciding: one moves the creeps, one routes the healing. They have to agree without reaching into each other’s internals, and the thing that lets them is a single classification. For each creep, on each tile it might step to, I weigh the worst damage it could take there against the most healing I could actually route to it, and label the result:

• Safe: survives the worst case on its own HP.
• Rescue: dies on HP alone, but heal can cover the gap.
• Doomed: no reachable amount of heal saves it.

The point of three labels instead of a number is that survival is a gate, not a score. The blob never trades a death for progress at any exchange rate; one Doomed creep vetoes the entire plan.

My first version of that veto was wrong in a way worth keeping. It summed danger over every creep at once. So the creep at the very front, eating the most fire but sitting at full HP and the last one any sane defender would shoot, dumped a huge number into the sum and tripped the veto, freezing the advance for nothing. The fix was to gate on the one creep the defense would actually kill: the thinnest survival margin, not the largest incoming number. “Who’s taking the most fire” and “who can the enemy actually kill” are different questions, and only the second should be allowed to stop the blob. The classifier carries more than this one fix, and I’ll give it its own write-up.

Stock vs. flow

For a while the blob handled big fortresses and then died, embarrassingly, to the cheapest defense on the board: two towers on a chokepoint. The expensive base was the easy one, and the cheap one kept killing it. I stared at that backwards result for a long time.

The bug wasn’t in the code, it was in the question. Every survival check I’d written asked “are we hurt?” That’s a stock question, about how much HP is in the tank right now. Against a slow trickle of tower fire the blob is never visibly hurt; it just loses a sliver more than it heals each tick until somebody quietly crosses zero. The question that actually mattered was a flow one: “is the bleed outrunning the heal?”

Rewriting survival around flow instead of stock was the turning point of the project. On a heavily-walled fortress bed it pulled attack efficiency from 0.146 to 0.719, from flinching at the wall to locking onto the target, and the two-tower case that started the whole thing got its fix one layer up (next section). Almost everything good that came later is some version of this same swap.

Knowing when to leave

A blob that never retreats is just a slower way to lose. But retreating is something the move layer can’t do on its own, and the reason is myopia: the solver only ever optimizes the next tick. Close to a base that’s fatal. Inside a tower’s flat max-damage band every adjacent tile reads the same maximum hit, so a one-tick-greedy policy sees no gradient to follow out; every direction looks equally lethal, it never commits to the run of bad tiles a real escape costs, and it just stands in the fire and dies.

That’s the job of the next layer up: a small state machine, ADVANCE, RETREAT, HOLD, that holds a decision across many ticks no single tick could justify. RETREAT hands the solver a goal to walk toward while the local field is flat, and a flow test decides when to commit to it, the moment the bleed starts outrunning the heal. (The old trigger was stock-based and fired far too late, around 12% HP, while HOLD kept re-parking the blob on the next full-HP creep and feeding one death per cycle.) On the two-tower chokepoint that used to wipe every run, this took the blob from 0 of 8 survivors to 7 of 8 clean, though only once it also stopped scattering on the way out, which is the next section’s problem.

Holding together without clumping to death

Creeps that drift get picked off alone, so I added a gentle pull toward the pack’s center, just enough to keep a straggler from wandering off the edge and dying by itself.

This looked like a genuine no-win trade-off, and I believed it for a while. The pull’s worth turns out to depend entirely on the terrain. On broken, walled maps, where a blob can get cut into pieces it can’t reunite, holding together is the only thing keeping it from being divided and killed a creep at a time. On open ground there’s nothing to divide it: every creep can reach its own best tile, and cohesion does nothing but drag each one off that optimum. Opposite preferences, no single setting serving both, and I almost filed it as a law of the problem.

The conflict came down to one thing: the pull was a single linear knob. One strength, applied to every creep, so anything strong enough to reel in a separating straggler tugged a settled creep off its optimum just as hard, and no value served both terrains at once. The fix wasn’t a compromise number, it was a different shape. I changed the pull from linear to quadratic, the distance to the pack’s center times the distance to where that center is heading, which sits near zero inside the swarm and climbs steeply only at the edge. Now it grips only the creeps actually drifting off and leaves the packed middle alone, which is what each terrain wanted all along.

(I’d tried cleverer pulls first. One tracked each creep’s own heading instead of the group’s; another enforced spacing with no sense of the pack’s shape. Both failed for the same reason: neither carried the only signal that mattered, how far this creep is from everyone else. A post of its own.)

So cohesion kept its place, not as the “hold formation” rule I first imagined but as a light nudge that grips only the creeps slipping off the edge.

The body is the other half, and the half I’m on now

I spent most of this obsessing over movement, but what you spawn is the other half of the problem, and it’s where the work actually is right now. Part order is a live design axis: a TOUGH plate up front, boosted hard enough to buy the formation time without costing firepower, and the heal-to-ranged split set against the focus you expect to eat. I’m trying to fold all of it into a closed-form chooseBody: a body straight from an energy budget and a boost tier, no simulation, so the live bot can call it inline.

It is not settled. The towers-only case works; against real defenders the calibration is still open, and I’ve already thrown out one version I was sure was finished. This is the current frontier of the project, not a closed box. It gets written up when it actually holds, not a post sooner.

How I keep myself honest

The only reason any of the above is trustworthy is the measurement discipline, and it’s the part I’d hand a new builder first. Every change is A/B’d against a frozen baseline on the same seeds, never a fresh batch of battles. I judge on survivors and attack efficiency, over at least 8 seeds and 500 ticks, because tick-to-tick noise is large enough to fake a result on its own. And I sweep the whole ladder of scenarios, not one, because single-point tuning lies: constants I tuned on a fortress died on a chokepoint, and most of my “wins” evaporated the moment I swept across beds. That sweep, the one that tells you you were wrong, is most of what the lab is for.

If you want to build your own

The blob is nowhere near finished, which is most of the appeal. If this makes you want to build one, here’s roughly what I’d tell you.

Build the simulator before any tactics, and make every idea earn its place by beating the last one on the same battles. Spend real effort on the one abstraction your layers share. Mine was Safe / Rescue / Doomed, and one clean concept that lets the layers cooperate beat any number of clever heuristics. Watch flows, not stocks: “are we losing ground faster than we can recover it” is the better question almost everywhere I asked it. When two goals look flatly opposed and no coefficient reconciles them, suspect the quantity before the number: sometimes nothing fits because the term is the wrong shape, not the wrong size. And write the dead ends down: half of this post is failed ideas, and the note on why each one died is the only thing that keeps you from walking back into it.

None of the answers were the satisfying part, though. The satisfying part was almost always the sweep that proved me wrong and pointed at where to look next.

This post introduces an alternative system based on the principle of Return on Investment (ROI). The objective is strictly economic: minimizing the total energy cost inflicted on my colony by external threats, resolved at the lowest possible resource expenditure.

1. Infamy: Quantifying Incoming Damage into Energy

To make rational comparisons between different hostile bots, all forms of harassment must be converted into a single, unified metric: Energy. The system tracks this under a property called infamy.

Direct Calculations

• Remote Harassment: When hostile creeps invade our remote mining rooms, the system estimates the energy cost required to build the invading creeps. For non-combat scouts, this is a flat baseline of 100 energy. For combatants, it uses the exact energy cost of their body parts (e.g., ATTACK, RANGED_ATTACK, HEAL).
• Creep Casualties: When a friendly creep is destroyed by an enemy, the infamy value is scaled by the creep’s size and remaining lifetime:

  Infamy Added = (Body Length * Part Energy Max * Ticks to Live) / Creep Lifetime
  

  This ensures that losing a freshly spawned, expensive creep adds significantly more infamy than losing a creep that was about to die of old age.

Heuristics for Complex Interruptions

Certain hostile actions cannot be easily converted into a precise energy value. For these, consistent heuristics are applied to maintain internal logical consistency:

• Power bank mission disruptions
• Direct attacks on owned rooms (e.g., nuke launches)

Moving Average, Decay, and Locking Mechanics

Because infamy is measured dynamically, the bot accumulates the total damage over a specific tracking period (CREEP_LIFE_TIME ticks) and merges it into the existing historical score using an Exponential Moving Average (EMA). This mathematical structure governs how threat scores persist or decline over time:

• The Decay Mechanism: Past infamy naturally decays as new cycles with zero hostile activity are processed.
• The Baseline Floor: To represent geographical threat, the bot calculates a static baseline infamy score based on proximity. For every room the opponent owns (containing active spawns and towers) that is within a close range of our territory (3 rooms if they are whitelisted, 5 rooms otherwise), a large flat infamy penalty is added to their baseline. This ensures that simply having a fully developed hostile base next door maintains a high, persistent baseline threat profile in the strategic planner, even during periods of peace.
• The Enemy Lock: Once a bot accumulates enough infamy to cross a specific threshold, it is marked as an "enemy". For these players, the infamy score is clamped at the enemy threshold baseline and prevented from decaying further—provided they have successfully breached one of our established rooms (RCL 4 or higher). This guarantees that players who have demonstrated the capability to penetrate our core defenses remain permanently flagged as threats, while minor players or those who only breached a low-level expansion outpost are allowed to decay back to neutral.

2. Durability: Estimation of Elimination Cost

While infamy measures the threat, durability estimates the cost of eliminating that threat. It answers the question: How many resources must my bot expend to completely wipe all known rooms of this player?

To establish a tangible baseline, Durability is defined as the estimated wall hits (where 1.0 durability = 1,000,000 hits) required to clear the target’s rooms.

Hardware Factors

Instead of summing up every single wall and rampart in the room, the bot calculates the minimum path thickness to reach critical infrastructure (spawns, towers, terminal). Using Dijkstra pathfinding on exit positions to target structures, the durability score is derived from:

• Minimum Path Barrier Hits: The total hit points of the thinnest layer of walls/ramparts blocking access to the core room structures.
• Energy-to-Repair Conversion: If the target player has been seen actively repairing structures, the system assumes they will spend their stored energy on defenses. The durability is scaled up by:

  Barrier Hits + (Stored Energy * Repair Power Constant)
  

• Stored Boosts: The estimated defensive capabilities are increased based on the opponent’s stored Tier 1, Tier 2, and Tier 3 combat boosts.

Software Multipliers (Intel System)

Raw defensive structures do not tell the whole story; the opponent’s defensive code matters. The bot maintains an intel object for each player stored in Memory. If the opponent has been seen utilizing advanced defenses, a multiplier scales up their durability score:

• Spawning dedicated rampart defenders (melee or ranged)
• Deploying defensive combat units (especially if utilizing boosts)

3. The Target Selection Algorithm and Score Modifiers

With both threat (infamy) and elimination cost (durability) quantified, the strategic planner selects targets by evaluating the overall return on investment.

The bot calculates an evaluation score for each potential target, taking into account a distance penalty:

Score = (Durability * Distance Penalty) / Infamy

Because the bot uses a Min-Heap to evaluate targets, the candidate with the lowest score is prioritized. This mathematically favors players who are highly hostile (infamy is high), close by (distance is low), and cheap to wipe out (durability is low).

The Distance Penalty

To prevent the bot from launching costly campaigns halfway across the world map, a logarithmic penalty is applied based on the room distance between our nearest spawn and the target’s territory. This penalty heavily prioritizes local hostiles, while scaling down the strategic priority of distant opponents to reflect the high resource costs and travel-time risks of long-range combat operations.

Priority Multipliers

To handle critical tactical situations and manage target stickiness, modifiers are applied directly to the score:

• Invasion Multiplier: If a player has launched an attack against us recently (lastInvasion), their score is halved (doubling their priority in the Min-Heap) to prioritize immediate revenge.
• Target Stickiness (Hysteresis): To prevent the bot from frequently switching war targets due to minor updates in structural data or infamy decay, the active target has its score halved. This introduces stickiness, ensuring the bot commits to a war target until a significant shift in the ROI balance occurs.

Conclusion

This system does not offer perfect mathematical precision. The unpredictable variables of combat code and hidden player assets make strict calculations exceptionally difficult. However, by framing target selection as a resource allocation problem—weighing energy lost against path-based deployment costs—the bot can manage automated long-term conflicts with reasonable efficiency and zero human intervention.

How I structure my bot to handle strategy, warfare, and large-scale decisions without drowning in micro-management.

Why I Rewrote My Bot

Like many Screeps players, my first bot grew organically: creeps made local decisions, special cases piled up, and every new feature felt harder than the last. Combat logic was especially painful—tactical decisions leaked everywhere, and it was difficult to answer simple questions like:

Is this war actually working?

When I rewrote my bot, I committed to two guiding ideas:

1. Top-down control where it matters Creeps shouldn’t decide why they act. Higher-level systems should.
2. Natural task decomposition Large goals should break down into smaller ones without relying on a rigid planner.

The result is a mission-based architecture, where Managers act as the brains of the empire and Missions act as the specialized tools they deploy.

High-Level Structure: Managers as the Highest Level

In this architecture, Managers are the highest-level actors. They are persistent, “always-on” entities that bridge the gap between global state and specific action.

Managers serve two primary functions:

1. Maintenance: They handle repetitive, baseline responsibilities (e.g., the Room Manager ensures the controller doesn’t downgrade).
2. Deployment: They act as the “commanders” who decide when the situation requires a specialized Mission.

Missions: Goal-Oriented Execution

While Managers are the “who,” Missions are the “what.” A mission represents a concrete objective with a clear success or failure condition.

A useful mental model is chess:

• The Manager is the chess player.
• The Mission is the specific opening or strategy being executed.
• Creeps are the pieces.

Recursive Decomposition (The Mission Chain)

Missions are most powerful when they spawn sub-missions. This allows for complex behavior to emerge from simple, nested logic. A high-level mission defines the intent, while its children handle the tactics.

Example Mission Chain: Total War -> Siege -> Quad

1. Total War (deployed by Combat Manager): Tracks the overall economic drain on the enemy and decides which rooms to pressure.
2. Siege: Focuses on a specific room, managing staging points and wall-breaking progress.
3. Quad: A tactical unit mission that spawns and handles four creeps in formation to execute the siege’s goals.

How Missions Communicate

All coordination happens through mission memory. The guiding rule is simple:

A mission may read any mission’s memory, but may only write to its own.

Example Decision Flow

1. A Quad Mission loses a creep and records the loss in its memory.
2. A Siege Mission observes the creep loss flag in its child Quad’s memory and adapts future squad composition.
3. Continued poor results cause the siege to stagnate.
4. The Total War Mission observes the lack of progress across multiple Sieges and decides to pivot the empire’s resources elsewhere.

No explicit reporting or signaling is required—coordination emerges from shared observation of state.

Mission Memory Structure

All missions are stored in a double-layered structure: Memory.missions[type][id]. This allows for fast lookups and easy iteration.

Example

Memory.missions["siege"]["W1N1"] = {
  type: "siege",
  id: "W1N1",
  targetRoomName: "W1N1",
  childMissions: [
    { type: "quad", id: "W1N1_17253400" }
  ],
  status: {
    isEffective: false,
    netDamage: -1500
  }
}

The Execution Loop

The daily life of the bot follows a predictable cycle, moving from high-level observation down to individual action:

1. Analyze: Managers maintain the baseline bot functions and scan the world state to identify strategic needs.
2. Deploy: Based on the analysis, Managers spawn or update Missions. For example, the Combat Manager may deploy a Total War mission if a player is being mean. The Total War mission then recursively deploys several Siege missions toward that player’s rooms.
3. Resolve: High-level missions read the memory of their child missions to evaluate progress. For example, a Siege mission checks its Quad mission’s results to see if the room’s defenses are cracking.
4. Act: Missions update their own state and issue direct orders to their assigned Creeps. In this phase, a Quad mission control creeps and reports how much damage it is dealing, feeding the loop for the next decision making.

This sequence ensures that execution remains local, while evaluation remains strategic.

Boosting is one of the most important steps to becoming a veteran Screeps player. You’ll eventually need boosted creeps to attack high-level rooms or defend against them — and once you can boost efficiently, you can also use those boosted creeps to accelerate your economy.

In this post, I’ll explain how my bot handles boosting from start to finish — including how it requests boosts, prepares resources, and executes the actual boosting process.

1. Boost Request

Whenever my bot requests a creep to be spawned and boosted, it also creates a boost request object in the room’s memory:

room.memory.boostRequests = [
  {
    creepName: "Attacker_123",
    requestedAt: Game.time,
    resources: {
      XKH2O: 660, // Resource type and amount
      XLHO2: 540,
      XZHO2: 300,
    }
  },
  ...
];

Each boostRequest contains:

1. The creep name to be boosted.
2. The Game.time when the request was made.
3. The resource types and required amounts for each boost.

While the creep is being spawned, another creep in the same room starts preparing everything needed for the boost.

2. Boosting Process Overview

My bot processes boost requests from oldest to newest. Each request goes through three phases: Gather → Prepare → Boost.

🧺 Gather Phase

1. Check resources: Make sure all the required minerals and energy are available to perform the boost.

2. Import if missing: If some resources are missing, request them via the room’s terminal from other rooms.

3. Switch to prepare phase: Once all resources are ready, the system transitions to the next step.

⚗️ Prepare Phase

1. Stop lab reactions: If the labs are currently running reactions, stop them first.

2. Courier transfers: Courier creep transport the correct resources to the appropriate labs.

3. Batch preparation: If there are multiple boost requests, try to prepare all of them — again from the oldest to the newest.

4. Ready check: If the target creep has finished spawning and everything is prepared, the bot switches to the boost phase.

⚡ Boost Phase

1. Move the creep: The target creep moves to the prepared labs.

2. Perform boosting: Each lab boosts the creep until the entire process completes.

3. Tips and Safety Checks

Here are a few lessons I learned the hard way:

1. 📌 Create boost request only when spawn returend OK to avoid duplication.
2. ✅ Check if the target creep is alive and waiting before starting the boost phase.
3. ⚗️ Select labs wisely — prefer labs that already contain the required minerals or that are being used as reaction labs.
4. ⚡ Don’t forget energy — labs need energy as well as minerals to perform the boost!
5. 🔄 Handle failures — if something goes wrong, return to the gather or prepare phase instead of getting stuck.
6. 🤝 For duos or quads, make the creeps that spawn first get renewed until all teammates are ready.
7. ⏳ Timeouts matter — if a boost request makes no progress after a certain time, give up and move to the next one.

4. Final Thoughts

So that’s how my bot handles boosting — a full cycle from request to completion, with recovery in case of failure.

Once you’ve built a stable boosting pipeline, you’ll unlock a huge new layer of Screeps gameplay. Try spawning a boosted singleton with tough, ranged attack and heal boosts, and send it to your neighbor — it’s a great way to test your system (and maybe start a small war 😄).

Today, I want to cover logistics. Many players manage logistics using a per-room method: they try to distribute resources equally to all rooms.
While simple, I think this approach creates inefficiencies — unnecessary terminal.send operations, resource ping-pong between rooms, and wasted CPU.

Instead, I chose to treat logistics as an empire-wide (bot-level) system. My guiding principles are:

1. Always think at bot-level if possible.
2. Do not send resources unless necessary.

Here’s how I currently handle logistics.

Managing Surplus and Shortage of Raw Minerals

My bot sets a threshold_per_room for each mineral. For the whole empire, this becomes:

threshold = threshold_per_room * myRooms.length

• Surplus case:
  If a mineral amount is far above this threshold, the bot sells it.
  By the pigeonhole principle, some rooms must be holding more than threshold_per_room. Those rooms are chosen to sell the resource.

• Shortage case:
  If a mineral amount is far below the threshold, the bot buys it.
  By the same logic, some rooms must be holding less than threshold_per_room. Those rooms buy the resource.

This ensures that buy/sell actions naturally balance the empire without constant redistribution.

Choosing Lab Process Targets

When labs are idle and looking for a new objective, my bot selects the boost with the lowest ratio:

(current amount) / (desired amount)

across the entire empire, but only among boosts where the bot has enough ingredients available.

• Empire-wide view:
  The current amount includes both what we already have and what is currently being produced in other rooms.
  This prevents multiple rooms from redundantly producing the same boost.

Handling Resource Overflow

Because my bot doesn’t equalize resources between rooms, some rooms occasionally overflow with resources.
When that happens:

1. If energy stockpile is above a certain threshold, push out energy.
2. Otherwise, push out whichever resource the room has the most of(Other than energy), to the nearest room with enough space.

This keeps rooms from stalling due to full storage.

Handling Resource Requests

There are several situations where a room may require resources it doesn’t currently have.
In such cases, my bot allows targeted terminal.send() operations. The guiding rule is: only send when a room explicitly needs something.

Typical Scenarios

1. Lab ingredient requests:
   • When a room wants to make a boost but lacks ingredients.
   • Other rooms must have the ingredients (since the target was chosen with that assumption).
2. Creep boost preparation:
   • When a room wants to boost a creep but lacks the boosts.
   • It requests them from rooms that have the boosts.
   • Since a full creep spawn takes ~150 ticks, usually there’s plenty of time to prepare.
3. Funneling for RCL growth:
   • Extra energy is sent to the room where I want to raise the RCL as quickly as possible.
4. Low energy recovery:
   • When a room’s energy drops too low to sustain operations, other rooms send emergency energy.
5. Power processing:
   • When the bot wants to process power, usually some rooms hold most of the power (often close to highways where power banks occur).
   • In this case, the bot distributes power to other rooms so that multiple rooms can process it simultaneously, increasing the speed.
6. Nuker preparation:
   • When a room wants to fill a nuker and needs ghodium, it requests it from other rooms.

In all of these scenarios, the system selects the closest suitable room to minimize transfer cost and avoid resource ping-pong.

Closing Thoughts

By shifting logistics to the bot-level, I avoid constant rebalancing and keep resource movement purposeful.
This approach reduces CPU overhead, prevents resource ping-pong, and ensures that logistics always serve empire-wide goals rather than per-room symmetry.

In the last post, we talked about basic quad movement. You’re probably eager to attack an enemy room with your quad—but before that, there are some important things to learn.

Today, we’ll use a Level 1 Stronghold as an example to show how quads can be used in real combat. Strongholds are the bases of NPC Invaders that spawn in the central rooms of each sector. They’re great for testing and improving your attack code: they appear regularly, exist in every sector, and reward you when destroyed.

Once a stronghold is destroyed, Invaders and lesser Invader Cores stop spawning in that sector until the next stronghold spawns (around 75,000 ticks later). So even a low-level stronghold is worth attacking—especially as a beginner practice target.

Let’s dive in!

• This is a tutorial, so I’ll keep things as simple and easy to follow as possible. Once you understand the basics, you can add more features and refine your logic. I’ll post more tips about using quads soon—stay tuned!

🚧 What to Spawn

A Level 1 Stronghold has only one tower and no creeps, but that tower can deal up to 600 damage per tick if you’re close enough. Since each HEAL part can heal 12 hits per tick, you need at least 50 HEAL parts in total just to survive.

To be safe, we’ll use 60 HEAL parts across the quad. That means each creep should have:

• 10 RANGED_ATTACK
• 25 MOVE
• 15 HEAL

That gives your quad enough healing, mobility, and firepower to survive and take down the stronghold.

• Please note: This is not an optimal strategy for destroying a stronghold—I’m simply using it for practice.

Overview of the Logic

Here’s the general structure of our quad attack logic:

1. Each creep attacks nearby structures or enemies.
2. Creeps heal each other effectively.
3. Creeps move as a quad:
   • A. If in danger, retreat.
   • B. If safe, find a target and move toward it.

Sounds simple, right? Let’s go through each part in detail.

🗡️ Attack Logic

To keep it simple for now, I’ll just make each creep attack any enemy or structure within range 3. If you have your own better logic, use that!

for (const creep of creeps) {
    const targets = creep.pos.findInRange(FIND_HOSTILE_CREEPS, 3)
        .concat(creep.pos.findInRange(FIND_HOSTILE_STRUCTURES, 3));

    if (targets.length > 0) {
        creep.rangedAttack(targets[0]);
    }
}

🛡️ Getting Damage

Before handling healing, we need to know how much damage each creep is expected to take.

1. Scan all enemy towers.
2. For each tile, calculate and store the total incoming damage from towers.

function getDamageAt(room, pos) {

    const towers = room.find(FIND_HOSTILE_STRUCTURES, {
        filter: s => s.structureType === STRUCTURE_TOWER
    });

    let damage = 0;

    for (const tower of towers) {
        const dist = tower.pos.getRangeTo(x, y);
        damage += getTowerDamage(dist)
    }

    return damage;
}

function getTowerDamage(range) {
    if (range <= TOWER_OPTIMAL_RANGE) return TOWER_POWER_ATTACK

    if (range > TOWER_FALLOFF_RANGE) {
        range = TOWER_FALLOFF_RANGE
    }

    return TOWER_POWER_ATTACK * TOWER_FALLOFF * (range - TOWER_OPTIMAL_RANGE) / (TOWER_FALLOF_RANGE - TOWER_OPTIMAL_RANGE)
}

❤️ Heal Logic

There are many healing strategies, but I recommend a simple one that maximizes the lowest expected health among your creeps:

1. For each creep, calculate expectedHits = hits - incomingDamage
2. Each creep should heal the friendly creep with the lowest expected hits.
3. After healing, update that creep’s expected hits by adding the heal amount.

function healCreeps(room, creeps) {
    const expectedHits = {};

    for (const creep of creeps) {
        const dmg = getDamageAt(room, creep.pos) || 0;
        expectedHits[creep.name] = creep.hits - dmg;
    }

    for (const healer of creeps) {
        let target = null;
        let minExpected = Infinity;

        for (const other of creeps) {
            if (expectedHits[other.name] < minExpected) {
                minExpected = expectedHits[other.name];
                target = other;
            }
        }

        if (target) {
            healer.heal(target);
            expectedHits[target.name] += creep.getActiveBodyparts(HEAL) * HEAL_POWER;
        }
    }
}

🧭 Movement Logic

1. Danger Detection

Before moving toward your target (usually the invaderCore), check whether the quad is in danger:

• Use the damage map.
• Compare each creep’s expected damage to the total healing your quad can provide.
• If any creep is expected to take more damage than can be healed, retreat.

A simple retreat logic:

• Remember which direction you entered the room from. If in danger, move back to that exit.

function shouldRetreat(room, creeps, totalHealPower) {
    for (const creep of creeps) {
        const damage = getDamageAt(room, creep.pos) || 0;
        if (damage > totalHealPower) {
            return true;
        }
    }
    return false;
}

2. Obstacle Map

To plan movement, we need an obstacle map, which shows how hard it is to destroy the obstacles on each tile.

Here’s how to build it:

1. First, scan all structures in the room to find the maximum hits among them. We’ll call this maxHits.
2. Choose a maximum cost value (e.g. 100) and compute unitHits = Math.ceil(maxHits / 100)
3. For each tile in the room:
   • Use room.lookForAt(LOOK_STRUCTURES, x, y) to get all structures on that tile.
   • Sum up their hit points.
   • Compute cost = Math.min(100, Math.ceil(hitsSum / unitHits))
   • Store that value in a CostMatrix.

Here’s the example code:

function getObstacleMap(room) {
    const costMatrix = new PathFinder.CostMatrix();
    let maxHits = 1;

    // Step 1: Find maxHits
    const allStructures = room.find(FIND_STRUCTURES);
    for (const s of allStructures) {
        if (s.hits && s.hits > maxHits) {
            maxHits = s.hits;
        }
    }

    // Step 2: Compute cost per tile
    const unitHits = Math.ceil(maxHits / 100);

    for (let x = 0; x < 50; x++) {
        for (let y = 0; y < 50; y++) {
            const structs = room.lookForAt(LOOK_STRUCTURES, x, y);
            let hitsSum = 0;

            for (const s of structs) {
                if (s.hits ) {
                    hitsSum += s.hits;
                }
            }

            if (hitsSum > 0) {
                const cost = Math.min(100, Math.ceil(hitsSum / unitHits));
                costMatrix.set(x, y, cost);
            }
        }
    }

    return costMatrix;
}

3. Destruction Cost Matrix

Since your creeps move as a 2x2 quad, convert your CostMatrix:

• For each tile (x, y), take the max cost of the following 2x2 block:
  • (x, y)
  • (x+1, y)
  • (x, y+1)
  • (x+1, y+1)
• Store that value in the new matrix.

4. Move to Target

Now, use the destruction cost matrix to find a path to the invader core.

• Identify the first structure the quad will encounter on this path—that’s your current target.
• Move toward it using quad movement logic from my previous post.

✅ That’s It!

With this setup, you should be able to take down a Level 1 Stronghold using a basic quad. But this is just the beginning. Here are some ideas to take your system further:

1. Boost your creeps for higher damage output and durability.
2. Detect danger more precisely and proactively, considering enemy creeps.
3. Improve retreat logic.
4. Change targets if something goes wrong.
5. Use RMA (Ranged Mass Attack) to destroy enemy structures more effectively.
6. Create smarter healing strategies.
7. Use multiple quads together without them getting stuck.
8. Improve CPU efficiency by caching and reusing previously computed results.

I’ll cover these advanced topics in future posts!

Stay tuned, and happy coding!

Energy is the lifeblood of your Screeps empire. It fuels every action, from spawning creeps and building structures to defending your territory and upgrading your Controller. Hitting an energy income ceiling is one of the most common roadblocks players face. If you feel like your growth has stalled, it’s time to optimize your economy.

This guide covers 8 essential tips, from fundamental principles to advanced strategies, to help you dramatically boost your energy income.

1. Specialize with Static Miners and Haulers

One of the first and most impactful changes you can make is to stop using general-purpose worker creeps. A single creep with WORK, CARRY, and MOVE parts is inherently inefficient. When it’s mining, its CARRY parts are idle. When it’s hauling, its WORK parts are useless. You’re paying for parts that aren’t being used half the time.

The solution is to specialize your creeps into two distinct roles:

• Static Miners: These creeps are designed with WORK parts to harvest source and MOVE parts to get into position. They sit directly on an energy source and do nothing but mine continuously. Some players put one ‘CARRY’ part on them to let them repair its own container.
• Haulers: These are logistics creeps, built with CARRY and MOVE parts. Their only job is to pick up the energy dropped by miners and transport it.

This division of labor is the foundation of a scalable economy.

2. Expand with Remote Mining

Once you’ve optimized harvesting in your home room, you’ll quickly hit a hard cap. A standard room has at most two energy sources, limiting your income to 20 energy per tick. To grow beyond this, you must look to near, neutral rooms.

Remote mining—sending your miners and haulers to harvest sources in nearby rooms—is the single most effective way to boost your early-game energy income. More sources harvested means more energy for your empire.

3. Build Infrastructure: Containers and Roads

To support your specialized creeps, you need infrastructure. Containers and roads are non-negotiable for an efficient operation.

First, build a container next to each energy source. Your static miner can drop energy directly into it, which prevents the energy from decaying on the ground and creates a large buffer for your haulers to draw from.

Next, build roads connecting your sources to your storage. Roads make the fatigue generated by movement by half. This is a critical mechanic, as it allows you to build more efficient haulers. On a road, a creep only needs one MOVE part for every two CARRY parts (2:1) to move effectively, compared to the 1:1 ratio required on plain. This translates into massive savings across all three major resources: energy, spawn time, and CPU.

4. Optimize Your Logistics: Don’t Over-spawn Haulers

A common mistake is to think more haulers is always better. In reality, you should not spawn more haulers than you absolutely need.

Haulers are expensive. They cost a significant amount of energy and spawn time, and they consume CPU for their entire lifetime. An idle hauler waiting for energy is a drain on the very resources you’re trying to accumulate. Precision is key. Calculate the exact number of hauler CARRY parts required to service your sources based on distance and output, and spawn just enough to meet that demand.

5. Choose Remotes Wisely

The single most important factor in choosing which room to harvest is proximity.

Your miners are relatively cheap, but the cost of hauling energy over long distances is significant. The farther your haulers have to travel, the more energy, spawn time, and CPU they consume. Always prioritize harvesting from the closest remote rooms first, expanding outwards until you’re capped by spawn time or CPU.

6. (Advanced) Harvest Source Keeper Rooms

Once one of your rooms reaches Room Controller Level 7 (RCL 7), you can unlock a new tier of energy income: Source Keeper (SK) rooms.

Sources in these hostile rooms are 33% richer, regenerating 4,000 energy every 300 ticks instead of the standard 3,000. As an added bonus, the hostile Source Keeper NPCs that guard these sources drop energy in their tombstones when killed.

To operate here, you’ll need to spawn a dedicated combat creep from your RCL 7 room, typically with ATTACK, MOVE, and HEAL parts, to roam the SK room and keep it clear.

7. (Advanced) Implement a Hauler Pool

As your logistics network grows, assigning dedicated haulers to a single source becomes inefficient. You can’t perfectly match supply and demand (e.g., a source might need 2.5 haulers), and creeps often waste their final ticks when they lack enough TTL for a final round trip.

The solution is a hauler pool. Instead of dedicated assignments, you treat all your haulers as a single, uniform group. A central system dynamically assigns any available hauler to any container that needs servicing. This provides incredible flexibility, reduces the total number of haulers needed, and minimizes waste. While more complex to code, the efficiency gains are enormous.

8. Monitor Everything with Visuals

You can’t optimize what you can’t see. Screeps provides excellent tools for monitoring your economy at a glance.

• RoomVisual: Use this to draw information directly in your rooms. Create a dashboard showing the status of each source, assigned miners and haulers, and more.
• MapVisual: Get a global overview of your remote harvesting operations.
• creep.say(): Have your creeps report their current task or status. This is invaluable for debugging issues with history.

Good monitoring allows you to spot inefficiencies and fix them before they become major problems.

By implementing these strategies, you can transform your economy from a bottleneck into a powerhouse. What are your favorite tips for boosting energy income? Share them in the comments below!

In Screeps, quads play a crucial role, especially when attacking rooms with high RCL. Using only duos can make it really challenging to take on an RCL8 room. Today, I’ll introduce the basics of quad movement.

The rough idea is simple:

1. Get four creeps.
2. Find a wide enough area for them to be packed as a square.
3. Pack them into that area.
4. Adjust the cost matrix for quads.
5. Make sure the quad is packed before finding the path.
6. Find a path to the goal.
7. Make the quad follow the path.

The most tricky part is adjusting the cost matrix, but it’s not as hard as it sounds. Let’s dive into it!

Step 1: Spawn Four Creeps

First, spawn four creeps.

Game.spawns["Spawn1"].spawnCreep([MOVE], "Quad1")
Game.spawns["Spawn1"].spawnCreep([MOVE], "Quad2")
Game.spawns["Spawn1"].spawnCreep([MOVE], "Quad3")
Game.spawns["Spawn1"].spawnCreep([MOVE], "Quad4")

Now you have four creeps!

Step 2: Find a Square Area to Pack Creeps

Next, you need to find some square area to pack those creeps. This can be done by searching RoomPosition objects near your creeps to find a position A such that:

• A
• Right of A
• Bottom of A
• Bottom-right of A

…are all empty.

Important:

You should remember that area until the creeps are all packed together. Searching for a new area every tick could make your quad fall into an infinite loop.

Once you find the area, assign each creep to a specific position and make them go there.

// Example: Assign formation positions relative to the top-left corner
creep1.moveTo(topLeftPos)
creep2.moveTo(new RoomPosition(topLeftPos.x + 1, topLeftPos.y, roomName))
creep3.moveTo(new RoomPosition(topLeftPos.x, topLeftPos.y + 1, roomName))
creep4.moveTo(new RoomPosition(topLeftPos.x + 1, topLeftPos.y + 1, roomName))

Now you have four creeps perfectly packed into a square!

To ensure your creeps are packed, you can create a helper function:

function isQuadPacked(creeps) {
  if (creeps.length !== 4) return false
  for (let i = 0; i < creeps.length; i++) {
    for (let j = i + 1; j < creeps.length; j++) {
      if (!creeps[i].pos.isNearTo(creeps[j].pos)) return false
    }
  }
  return true
}

This function checks that every creep is adjacent to every other creep.

Step 3: Adjust the Cost Matrix

Now, it’s time to adjust the cost matrix for quad movement.

Concept:

• Assume the top-left creep in the formation is your “leader.”
• Create a modified cost matrix that accounts for the fact that the quad occupies a 2x2 area, not a single tile.

See how the cost in the red circle has changed!

Example: Cost Matrix Transformation

Here’s how you can transform your existing room cost matrix for quad movement:

function transformCosts(costs, roomName, swampCost = 5, plainCost = 1) {
  const terrain = Game.map.getRoomTerrain(roomName)
  const result = new PathFinder.CostMatrix()
  const formationVectors = [
    { x: 0, y: 0 }, // top-left
    { x: 1, y: 0 }, // top-right
    { x: 0, y: 1 }, // bottom-left
    { x: 1, y: 1 }, // bottom-right
  ]

  for (let x = 0; x < 50; x++) {
    for (let y = 0; y < 50; y++) {
      let cost = undefined

      for (let vector of formationVectors) {
        const newX = x + vector.x
        const newY = y + vector.y

        if (newX < 0 || newX > 49 || newY < 0 || newY > 49) {
          continue
        }

        let newCost = costs.get(newX, newY)

        if (newCost === 0) {
          const terrainMask = terrain.get(newX, newY)
          if (terrainMask === TERRAIN_MASK_WALL) {
            newCost = 255
          } else if (terrainMask === TERRAIN_MASK_SWAMP) {
            newCost = swampCost
          } else {
            newCost = plainCost
          }
        }

        if (cost === undefined) {
          cost = newCost
        } else {
          cost = Math.max(cost, newCost)
        }
      }

      result.set(x, y, cost)
    }
  }
  return result
}

Step 4: Pathfinding with Quad Formation

Use the transformed cost matrix in your PathFinder.search call, and make sure to use the top-left creep’s position as the startPos.

const costMatrix = transformCosts(existingCostMatrix, roomName)
const path = PathFinder.search(
  topLeftPos,
  { pos: targetPos, range: 1 },
  {
    plainCost: 1,
    swampCost: 5,
    roomCallback: () => costMatrix,
  },
)

Step 5: Move the Quad

Once you have a path, make each creep follow the path, staying in formation. A simple way is to find the direction from the path and move all creeps in that direction:

const direction = topLeftPos.getDirectionTo(path[0])
creeps.forEach((creep) => creep.move(direction))

Pseudocode for Overall Quad Movement

// 1. Spawn four creeps, each with one MOVE part.
spawnCreep([MOVE], 'Quad1')
spawnCreep([MOVE], 'Quad2')
spawnCreep([MOVE], 'Quad3')
spawnCreep([MOVE], 'Quad4')

// 2. Check if the quad is properly packed.
if isQuadPacked(creeps) is false:
    // 2a. Find a square area (topLeftPos) where a 2x2 area is empty.
    topLeftPos = findEmptySquareAreaAroundCreeps(creeps)

    // 2b. Move each creep to its designated position to form a quad.
    creep1.moveTo(topLeftPos)
    creep2.moveTo(position at (topLeftPos.x + 1, topLeftPos.y))
    creep3.moveTo(position at (topLeftPos.x, topLeftPos.y + 1))
    creep4.moveTo(position at (topLeftPos.x + 1, topLeftPos.y + 1))

// 3. Transform the room's cost matrix to account for the quad formation.
transformedCosts = transformCosts(existingCostMatrix, roomName, swampCost=5, plainCost=1)

// 4. Use the top-left position (from the quad formation) as the starting point and search for a path to the target.
path = PathFinder.search(topLeftPos, targetPos, { costMatrix: transformedCosts })

// 5. Determine movement direction from the path.
direction = getDirectionFrom(topLeftPos to next step in path)

// 6. Move all creeps in the determined direction.
for each creep in creeps:
    creep.move(direction)

// 7. Continue pathfinding and moving until the target is reached.

Challenges to Improve Quad Movement

Now that you’ve mastered the basics of quad movement, it’s time to tackle some more advanced challenges. Try these out and feel free to reach out if you encounter any issues or want to share your solutions! You can ping me (Harabi) on the official Screeps Discord.

• Path caching to avoid redundant calculations.
• More efficient methods for packing creeps into formation.
• Avoiding collisions with enemy creeps.
• Temporarily breaking formation to slip through narrow passages.
• Inter-room traveling for entering and retreating.
• Room edge handling to prevent getting stuck at exits.

Happy Screeping!

In the past few posts, I’ve primarily focused on the economy. A robust economy enables rapid growth, but to thrive, you must also defend your rooms effectively. This time, let’s delve into room defense.

Basic room defense comprises three main components: strong enough towers, repairers, and active defenders. Among these, active defenders are the most challenging to manage. Today, I’ll break down the process of implementing active defenders, focusing primarily on melee defenders.

To effectively use active defenders, we need to answer three key questions:

1. How much damage do we need?
2. How should we assign or spawn active defenders?
3. How can we move them smoothly?

Let’s tackle each of these questions one by one.

2. How Much Damage Do We Need?

The first question we need to answer is, “How many active defenders do we need?” To do this, we must first determine how much damage is necessary to deal effective damage to each enemy creep and how to group enemies.

2.1. Estimating Tower Damage

The first step is to understand how much damage we can expect from our towers. I use the minimum tower damage for all the outermost ramparts, as this is the most conservative estimate for enemy creeps.

You can calculate this using floodFill. If you’re unfamiliar with it, refer to the 5th paragraph of the “The Process” section in this post. Start from the room exits, collect the outermost ramparts, and then determine the minimum tower damage among them. This will serve as your tower damage expectation.

2.2. Calculating Required Damage

To calculate the required damage, I wrote a script based on the Screeps engine code, which you can view here. The key point is that you must deal more than 100 damage to destroy one boosted tough part while considering the heal power of enemy creeps. Here’s how you can approach this:

1. Calculate Total Heal: For each enemy creep, calculate the total healing potential (including both regular and ranged heal). Let’s call this the total heal for that creep.

2. Calculate Required Damage: For each enemy creep, determine how much damage is needed to overcome a set amount of damage plus the total heal for that creep. I typically use 100 as the base amount, though this value is somewhat arbitrary.

3. Adjust for Tower Damage: Subtract the expected tower damage from the required damage calculated in step 2.

With this, we have determined the additional damage required beyond what the towers can deliver. We’ll use this information to decide how many active defenders to spawn later.

3. How Should We Assign/Spawn Active Defenders?

Spawning active defenders for each enemy creep is inefficient because enemies usually form groups like duos or quads. To manage this, we need to group them effectively. Here’s how I solved this problem:

3.1. Grouping Enemy Creeps

1. Flow Field Setup: Start by generating a flow field from our outermost ramparts (collected in step 2.1). This involves running a full Dijkstra and caching the results. This method allows us to quickly determine the closest outermost rampart for each enemy without performing costly pathfinding for every enemy.

2. Initialize a Damage Map: Create an empty object to store the expected damage for each outermost rampart position. You can use a two-dimensional object or calculate keys using the formula 50*y+x.

3. Assign Enemies to Ramparts: For each enemy, determine the closest rampart (based on path length) using the flow field. Minimize diagonal moves, as these are less effective for blocking enemies from reaching the ramparts. This is good enough But this is better

4. Collect Adjacent Ramparts: Gather all ramparts adjacent to the closest one (using Manhattan distance). Typically, this involves three ramparts. For each position, add the enemy creep’s attack power to the damage map.

5. Group Enemies: Identify the outermost rampart position with the highest expected damage. Group all the enemy creeps that contributed to this rampart. Repeat steps 3.1.3 through 3.1.4 until no enemy creeps remain ungrouped.

After grouping, you should see something like this:

3.2. Assigning and Spawning Defenders

For each group, find the creep with the highest required damage calculated in step 2.2. Assign active defenders until their combined damage surpasses this requirement. If there aren’t enough defenders, spawn more. This method ensures that you efficiently assign and spawn enough active defenders.

4. How Should We Move Active Defenders Smoothly?

The final challenge is moving and allocating your defenders effectively. Movement is a complex aspect of Screeps, but I’ve found a solution that works well.

Pretty elegant, right?

4.1. Movement Strategy

1. Identify Key Positions: For each enemy group, find the enemy closest to the outermost ramparts. Use the cached rampart positions to determine where your creeps should stand.

2. Move Creeps: The cyan squares in the video represent the positions defenders should occupy. Here’s how to move them:

   a. Approach the Tiles: For each creep more than one tile away from all the desired tiles, move it closer until it’s adjacent to one of the desired tiles.

   b. Pathfinding: For creeps adjacent to one of the desired tiles, find a path to an empty tile using only other defenders.

   c. Chain Movement: If a path is found, move each creep one step forward along the path, ultimately positioning the first creep inside the desired area.

This method allows you to allocate your defender creeps smoothly and effectively.

Conclusion

We’ve covered how to manage active defenders in Screeps, from calculating damage needs to moving them efficiently. With these strategies, your established rooms should be well-defended against most threats. If you have any questions, feel free to ping me on the official Discord or leave a comment on this post.

Thank you for reading!

1. Spawning Creeps

A. Spawn Management System Overview

To manage the spawning of creeps efficiently, I’ve developed a spawn management system that organizes and prioritizes spawn requests. While it may not be the ultimate solution, this system has greatly improved my clarity and coding efficiency.

1. Queue Initialization: At the start of the main loop, I iterate through all the rooms I control and check if there is available spawn and prepare a spawn queue if there is. I use a min-max heap for this queue, which simplifies the sorting process. You can read more about min-max heaps here.

2. Requesting Creeps: During the logic phase for each room, whenever there is available spawn and a new creep is needed, I insert a spawn request into the queue. Each request includes crucial details like the creep’s name, body composition, memory, role, and other necessary information.

3. Processing the Queue: After all the logic has been executed, I iterate through all the rooms I control and review the spawn queue and spawn the creeps with the highest priority.

So, my main loop looks like this.

for room of myRooms
    spawnManager.resetSpawnQueue(room)

for room of myRooms
    roomManager.run(room) // during run, request creep if there is available spawn and a new creep is needed.
    
for room of myRooms
    spawnManager.run(room)

B. Spawning Order for Earning Creeps

When spawning earning creeps like miners, haulers, and reservers (or source keeper killers), it’s important to prioritize sources strategically:

1. Close Sources First: Focus on the closest sources first as they are the most profitable.
2. Energy Production: Within each source, prioritize increasing the energy harvested before spawning the necessary haulers.
3. Sequential Completion: Complete one source before moving on to the next.

Detailed Spawning Logic:

1. Iterate Through Sources: Start with the closest or most profitable source.
2. Check for Special Units: If a reserver or source keeper killer is needed, spawn them and stop iterating.
3. Spawn Miners: If a miner is needed, spawn it and stop iterating.
4. Spawn Haulers: If the current haulers are insufficient, spawn additional haulers and stop iterating.
5. Update Hauler Count: Reduce the remaining hauler count by the number required for the current source.
6. Proceed to the Next Source: Continue to the next source until all are adequately serviced.

(Iterate from source number 1 to source number 9)

2. Balancing Earning vs. Using Creeps

Balancing the spawning of earning creeps (miners and haulers) with using creeps (upgraders and builders) is critical, but the strategy differs depending on whether you have storage.

A. With Storage

When storage is available, the strategy is straightforward:

• Energy-Based Decision: The priority between earning and using creeps is based on the energy amount in storage. If the energy in storage exceeds a certain threshold, prioritize spawning using creeps. If it falls below that threshold, focus on earning creeps.

B. Without Storage

Without storage, the balance requires more delicate management:

• Adaptive Metric: I use a metric that adjusts the priority dynamically. This metric ranges from -1 to 1 and naturally decays to zero over time.
  • Priority Shift: If haulers are unable to find a place to deposit energy (indicating an overflow), the metric increases, shifting the priority to using creeps.
  • Energy Shortage: Conversely, if using creeps are running out of energy, the metric decreases, and the focus shifts back to earning creeps.

This adaptive strategy helps maintain a balance between energy production and consumption when storage is not available.

(I visualized this metric using in-game methods.)

3. Hauler Pool Management

Once haulers are spawned, the challenge is to manage them efficiently. The goal is to ensure that every hauler’s capacity is utilized without wasting travel time or energy.

A. Strategy Overview

• Maximize Carry Capacity: Avoid sending haulers to sources where there won’t be enough energy to fill their capacity.
• Prioritize Proximity: Favor closer sources since they yield the same amount of energy with less travel time.

B. Calculating Expected Energy

To decide where a hauler should go, we need to estimate the energy available at each source, considering other haulers that might be heading there.

1. Energy Piled Up: Calculate the sum of energy in containers and any dropped energy near the source.
2. Expected Energy Gain: Determine the expected energy gain based on travel distance:

   • If the distance is less than or equal to the ticks left for regeneration:

     Expected Energy Gain = min(energy piled, harvest power * distance)

   • If the distance is greater than the ticks left for regeneration:

     Expected Energy Gain = min(energy piled, harvest power * distance) + (harvest power) * (distance – ticks to regeneration)

3. Adjust for Hauler Traffic: Reduce the expected energy by the amount likely to be taken by other haulers heading to the source.
4. Select the Optimal Source: Choose the closest source with enough expected energy.

(While monitoring, visualized table can be really helpful)

Conclusion:

In this article, we’ve covered the essentials of spawn management and hauler pool optimization. By strategically managing the spawning process and ensuring your haulers are efficiently assigned, you can significantly boost your early game economy. Stay tuned for the next part of this series, where we’ll dive into defense techniques!