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