The concept of a Great Filter is similar to stages of a user's bot development as, there are several steps most users go though in development that allow their bot to thrive on a server. Though you could think of these as 'goals' to complete, Screeps is ultimately a sandbox game, meaning you can do as much or as little, as you want. However, if your talking in terms of survival of a colony of creeps there are repeatable patterns that emerge in development that almost all bots follow or have some aspect of.
Creep Management - Roles, States & Tasks/Goals
The first step is to have one creep take an action, however, a user inputting multiple actions one a creep manually is not effective as a colony grows even a little. A user and subsequently their bot, needs to beable to have creeps do tasks automatically based on the conditions of their environment. There are several methods for this, and the ones listed here are by no means 'the only way'. It is up to the user, how to structure their bot.
The tutorial for Screeps presents a solution in roles, where each creep is assigned a role and based on that role they have logic to do actions based on their environment. Roles can be made to fit almost any situation, but the creeps who do them often are 'locked' into their specific role unless logic specifies elsewise, meaning at base, if a creep has completed its task and there are no more tasks for it to do, unless the user specifics something more/new for it to do, it will sit until conditions change in that it can act again.
Another type of of creep management is generic creeps, in where a creep's body is formatted to be useful for several tasks and the creep is assigned a task/goal based on a colony's needs, stresses or environmental conditions. In this way, an individual creep only needs to worry about the task/goal it was assigned and take actions accordingly, but can also when done be assigned a new task/goal. This does make creeps more dynamic, however, as their bodies are often suited for multiple tasks, the tend to be bigger/more energy expensive depending on user setup, then a specific role creep who does one thing.
As creeps only have a limited life-span, the next filter is making sure a colony is maintained with new creeps, when the old ones die of old age or other factors without direct user intervention. And if the worse happens and a colony is wiped out, the spawning system needs to be able to re-start itself.
The tutorial sets up a way to do this in the form of a 'headcount', every tick creeps are tallied up and check against hard-set values in a flowing else/if condition setup. If during the execution of the else/ifs a condition is met and/or fails (depending on setup) then the spawn is told to spawn a creep to replace the deficit. This can be evolved upon to be more dynamic as a user refactors their code.
Another method of spawning creeps is with a queue, meaning that a user's code looks at conditions as they are in a colony and pushes an element to a 'queue' for the spawner to take care of in order of importance/receiving. Then, as it gets entries, the spawner handles the queue as needed.
Even with the best extension filling or spawning, an unexpected cost or cause can cause all your creeps to die necessitating in new ones to need to be spawned. Best-case, your queue/spawning system sends out a creep to handle getting energy to the extensions first but if this creep is not flexible enough it is quite possible for it to fail to spawn or fail to find/gain energy. If you come across a situation where your reserves are drained, or you can only spawn a small creep(s) it's best to have a handler to get some creeps out to start rebuilding/restarting the room so bigger/more specific creeps can take over.
Automatic Room Defense
If it is a invader or another user, at some point a colony will be attacked and need to defend itself. Invaders will show up eventually in almost every case for a room and will only get more frequent as a user gets more efficient at mining energy. While they do not kill spawns directly, they can easily break pre-set spawning code by killing off the total creeps of a colony. This makes defending from them in a timely matter not only a time-saver in respawning lost creeps, but vital for survival. Users will rarely stop at killing creeps however and, if your spawn is undefended and they go uncontested, it could easily end up in you needing to respawn. Invaders are the first stage to get you going on defense, but ultimately you will require more to keep other creep colonies from wiping you out.
You can read more about defense here in Screep's official docs.
Proxy Harvesting & Excess Energy
While one room can provide sufficient energy to get started, effectively going to nearby rooms, harvesting their energy and bringing it back for the colony enables faster development as you can pump more energy into upgrading your controller, spawn more creeps/spawn them faster, and keep energy stored for times when you need it. This is known as proxy harvesting or remote mining.
Getting a creep to their designated room, then to the source and mining the energy is the first step.
Getting a creep to return with their harvested energy, or assigning creeps to bring that energy back is the next step.
While not strictly required, reserving a room allows more energy to be harvested from the room and to keep other's from harvesting it.
Claiming new rooms
Once a user hit's GCL two, they can claim another room to build a spawn and continue doing so for each GCL they gain thereafter. The easiest way to pick a room is of course, to let the user themselves evaluate the importance/need for a room then dispatch builders, however getting your bot to do it automatically can be a huge step towards a colony expanding on its own.
A creep with claim parts needs to travel to an adjacent roomPosition to the target room's controller and execute a
claimController() call. If the user has spare GCL, the room will be claimed, the controller will need energy to upgrade/stay claimed, and a spawn construction site can be placed. As a creep with claim parts only has 600 ticks-to-live, a room needs to be ~599 tiles (roomPositions) away from where it was spawned. As rooms are 50 by 50 tiles, you can claim a room ~10-12 rooms away from your spawn (depending on terrain generating more fatigue via swamps for the creep or blocking/longer paths around walls, obstacles like other players, ect).
Unlike a first-spawn room, when claimed subsequent rooms require a construction site to be placed to build the spawn. As such, the original room that sent the claimer needs to provide workers/builders to build up the construction site and maintain the controller before the room can be self sufficient. Even when the spawn is built, the original room can send larger sized creeps to build up the lower RCL room faster than it would be able to with its normal sized creeps for its level.
Two or more rooms comes with its own challenges. Many methods/code relied on to work for only one room, can fail without taking multiple rooms into account. Creeps need a way to distinguish which room is 'their home' to take tasks/goals/roles, use data for their given room, ect. As well, any room-level operations can be standardized so each 'owned' room can be iterated over and actions taken based on need instead of hard-coding solutions to the room's properties.
A colony needs rooms to grow and harvest from, occasionally those rooms are occupied by other users' colonies. Mounting an offense to take/capture rooms from other users helps a colony expand further.
Scouting & Storing information
While a user can see everything and anything in the game and add it manually to their bot/memory a user's code can not due to vision. Scouting is the process of using a creep or observer to get information from a room, parse it, then store it for use by other parts of the bot.
A creep grants vision in a room that it is in and of course, given it has at least one move part, can travel almost anywhere within its 1500 tick life-time. As such, creep scouts are cheap and need to do little more than move to new rooms while recording information. This information of course, can be anything from enemy colony locations, new sources of energy, strongholds, deposits, powerBanks ect. The main two components are 'how do I decide where to send this creep and when?' and 'how/what information do I store and for how long?'. Though you could store everything in memory, the larger memory gets, the more expensive it is to process each tick. Global lets you store more, but isn't persistent forever, and raw memory you need to parse yourself.
An observer will let you scan up to 10 rooms away from it, or unlimited using a power creep's power (for the effects tick duration). An observer will only grant vision in the room targeted by
observeRoom() for the next tick after it is called. As such, you need to have a queue or system set up to target a room and then on the next tick know that the room was scanned to gather the information. Observers are late-game structures but can help save CPU as observing a room only takes one intent while moving a creep to a room takes many move intents. They are great for rooms that do highway harvesting, as you can scan over a set of highway rooms for targets (like deposits & powerBanks) and when one is detected, save the information for your harvesting part of your bot to take care of. You could also 'lock' an observer to a room by constantly calling it to observe a room every tick granting you vision every tick, however it is a rare use case as most of the time you can get all the info you need on one tick.
Storing the information effectively and in a consistent scheme is important so that multiple parts of your script can access and use it without causing conflicts or redundant information leading to increased costs. For example, if you have a scout store information in memory in one large dump, but then take that memory and store it locally for a spawning system off a spawn structure or in a creep's memory, that duplicate information comes at a cost when the memory gets parse/stringified each tick. Similarly if you have information that is named/sorted one way, but break it down/use different systems for other parts of your script alot of conversion has to happen to get it to work vs just using one consistent method/scheme.
Using the Screep's market enables players to not only sell excess resources they have acquired, but purchase from other users as well. This enables more energy to be brought into a colony in a very short time, or resources that help boost other things that a colony may not be able to make/farm on its own, such as power, deposits, or boosts. Making this automatic, is a great step in being able to bring in more items to help the colony thrive.
Lab logic & Boosts
Another filter that tends to happen late in a colony's development is the implementation of labs to create compounds and boosts, and then in turn use those boosts to enhance creep's abilities. While not strictly 'required', another user can easily overpower a user's creeps / defense using boost and the only real counter is to use boosts in-turn to make up the gap in power. Lab logic can get complex/expensive and, boost logic can be challenging, but automating and/or mostly automating the process goes a long way in boosting a colony's defensive/offensive/harvesting power.
While this can be some-what circumvented with the use of the market, being able to find and then subsequently harvest valuable resources on the highways such as power and deposits helps a colony gain power and credits.
If you have active-scouting reports from creeps, you can store highway information, ticks to decay, and location of highway objects then just scan the list (object) for opportunities to harvest in the highway, at RCL 8, once you get an observer you can use the observer to scan highway rooms at w/e interval you desire to generate a mission/set a target/ect to harvest
For powerBanks or deposits generally you have creeps work in a 'team' to harvest from them. You need to spawn the creeps, get them to their mission location and co-ordinate the harvesting/attacking of the object.
Once a powerbank is destroyed or a deposit harvested, you need to haul these resources back to your closest room. In the case of powerbanks, it makes little sense to actually spawn these haulers until they are needed (it takes some time to work down a powerbank) and deposits, depending on how you configure them, the creeps themselves can haul back resources, or need to take resources from the miners to haul back.
Source-keepers guard very valuable rooms that can help boost a colony's energy and mineral input. There are several tasks to overcome when Source Keeper Mining, such as dealing with the source-keepers and the powerful raid invasions that happen when an invasion is triggered.
Suppressing the Keepers
Source-keepers will move within 1 tile of their closest resource (source/mineral) to their lair when spawned (and a creep is in the room, elsewise they stay near the lair) and not move until killed or dying from old-age. They will attack anything that comes into range, but not chase. Once below a % of their maximum hits or when death occurs from old age, their associated lair will start spawning a new keeper. Generally, using one or more creeps to patrol around the lairs and kill off the keepers is the preferred method. There will be a time while the keeper is respawning that the source/mineral will be accessible.
Harvesting & hauling the resources
Generally harvesting and hauling is done while the current keeper of the source/mineral is dead, when they are about to respawn or respawned the associated miner/gather to the resource can move out of range of the keeper, as it will not chase they can stay nearby waiting for them to be dealt with
Invaders & raids
Source-keeper rooms still have invader attacks every ~100,000 energy mined, however they will always be raids (larger groups of normally boosted creeps). Depending on your setup, you either have to deal with these invaders, or wait for them to despawn. The choice is yours.
Power Creeps are powerful units created from processing power, they enable a room and colony to do many things ranging from increasing energy/mineral gains to more offensive/defense power for a room. Getting enough power processed to create one, and the logic for it is a big step for most users.
Getting the power
Before you can have power creeps, you need GPL(Global Power Level)s. You spend these levels to create or upgrade power creeps. Power naturally spawns in 'power banks' along highways (see highway harvesting above). Once returned to the base a user needs to process it with a powerSpawn to add the power to their account and progress towards their next level.
Creating the PowerCreeps
Once you have power levels, you need to use either the GUI or code to create them. Once created they are assigned/stored in your account and need to be spawned onto the map from a powerSpawn that you own. If they die, they will maintained on the account, but with a cooldown before they can spawn again.
Using the powers
Depending on your setup, really depends on how you want to use the powerCreep. Mainly, you need to have conditions set up for the power creep to react to to use its powers (much like any creep) and 'rebuff' the structures/objects when desired. A power creep for economy for example, needs to know when and where to use its powers, how often to refresh and when to renew (via powerSpawn or powerbank) to keep itself alive. Important to note, is you do have to also 'activate' power in the room using the powerCreep. Also, that regardless of their 'spawned' status in the world, they will show up in
Game.powerCreeps meaning you must make sure not to run code for a creep that does not 'exist' in the world.
Using a factory it is possible to create many different kinds of commodities, which are useful for selling on the market for credits which allows a user to gain credits much quicker than selling raw minerals alone. This allows for more input of resources into a colony via buy orders on the market. It does require powerCreeps to work.
Inter-sharding (when shards exist)
Intersharding can be a big step in enabling multi-shard buying/selling of resources, and allows for a user's colony to find more rooms available to them if they run into neighbors they can't/do not want to remove.
Insuring a Memory backup
The first challenge to overcome when intersharding is when a creep moves to a new shard, they only keep their
name their ID is changed, and their memory is set to blank when they are down traveling to the new shard. They will also emerge out into an area around the portal (meaning you don't choose where they come out, it will be the same room, but its an area). You need to determine a method of getting these creeps memory, either hard-coded based on context of the creep, or more dynamically with inter-shard memory. Important to note as well, that if a creep travels to a shard where there is a creep already with its exact name, the creep will instantly die on reaching the new shard.
Claiming in range
Much like claiming a room on the same shard, you need to get a creep with claim parts to a controller and have available GCL. Once claimed, you need to send creeps to build a spawn and then get the room up and running.
Code runs on all shards
The users (your) code will run on every shard you have a owned object on. As such, if you have dependencies in your code that will not be accessible / will cause errors on this new shard, you need to prepare for that. You can use
Game.shard.name to determine what shard is running the code, and when logging to the console, the console will have a pre-fix of which shard is sending the message.
A stronghold automatically spawns in a sector in one of the Source-Keeper rooms routinely, with lots of loot in the form of resources. Being able to attack and eventually, automatically attack and loot these fortresses is a large task, but if you have some combat code set up already it can be easier.
Strongholds will always spawn in a source-keeper room towards the center of a sector, and will have a 'deploying' phase before they are active. They can be detected during this phase so you know when they are arriving to adjust your logic accordingly.
Small strongholds can normally be tanked with boosted creeps and their invaderCore destroyed at-range. Larger strongholds however, require much more coordination between multiple attacking creeps. And while nukes can be effective against these strongholds, they can also destroy the valuable loot inside.