-
Notifications
You must be signed in to change notification settings - Fork 41
Getting Started (deprecated)
The following document describes how to get started using FortOperation, which is what I used to run my rooms before I started working on auto-layout. Since then I've been focusing on ControllerOperation and its extending classes QuadOperation and FlexOperation, so a lot of this stuff is no longer necessary. For anyone who wanted to use the codebase without the autolayout by using FortOperation, it should still be possible.
The missions included in the basic framework make some assumptions about how you've set up your structures. It might be easier to make these modifications before you transition.
- Roads - Each source should have a road that connects it to the destination storage (both in remote harvest rooms and owned rooms). Each extension, spawn, lab, and terminal should also have a road. Except for combat creeps, almost all creep builds assume a road will be available. Not using roads will greatly diminish your efficiency (e.g., energy harvested will be reduced to half the normal rate).
-
Storage - Storages are used for holding your reserve energy and minerals. For best CPU and spawn efficiency, it is advisable to place your storage wherever creeps would have the shortest distance to travel to/from all the sources that you will use (including those in remote harvest rooms). This usually means on the edge of the room adjacent to a keeper room, if there is one nearby. The rest of your structures should be located as close to your storage as possible. Having extensions that are very far from the storage will mean that an extension-refiller will be much less efficient.
- StorageLink - There is a mission that uses links to send/receive energy around your room, and this requires a link near your storage. For best results, position the link so that it is a true-diagonal direction from your storage, at a linear distance of 2. Here is an example.
- Additional StorageLinks - Before RCL8, it might be useful to add additional StorageLinks near your storage, this will increase the energy bandwidth that gets moved to your ControllerLink. Additional links should all be reachable from the same position, so that the conduit doesn't have to move. Here is an example.
- ControllerLink - This is one of the links that the StorageLink interacts with, and is used to send energy to your controller. It can be positioned anywhere within a linear distance of 4 from your controller. One common issue is the wrong structure getting assigned as a "controllerBattery". See [here] for more details.
- SourceLinks - At RCL8 your rooms will use special miners that interface with a link, this reduces congestion in your base and is preferable CPU-wise. It only activates at RCL8 because prior to this, you are probably using your links to send energy to your controller. They just need to be within a linear distance of 2 from each source, so that a miner can access the link and the source without needing to move.
- Terminals and labs - TerminalNetworkMission heavily leverages your terminals to make sure each of your rooms has the resources that it needs to function. For best results, have your terminal be a linear distance of 2 from your storage. Minerals are loaded into labs from the terminal, so they should be very close to it. Here is an example.
- Walls and Ramparts - For best results, use compact walls that follow a bubblewrap-pattern (alternating walls and ramparts). Your defense creeps will use these ramparts to supplement the damage done by towers, which results in a very effective strategy that is difficult for an attacker to overcome. In addition, having walls closer to your storage will allow them to be built faster.
This framework will initialize your memory, so from a fresh game state there should be no setup required. However, if you have already been playing screeps you probably have a few things that you'll want to do before you start.
- Removing existing creeps:
_.forEach(Game.creeps, creep => creep.suicide()) - Remove existing flags:
_.forEach(Game.flags, flag => flag.remove()) - Wipe memory:
_.forEach(Object.keys(Memory), key => delete Memory[key]) - Rebuild Memory:
Memory.playerConfig = {}
The aim for bonzAI is to be entirely automated, but there is always a frontier of decisions that haven't yet been delegated to the AI. One of these is which rooms you want to operate. To engage own roomed behavior, you will place an operation flag in the room, specifically FortOperation. The convention for operation flags is operationType_operationName, where operationName a unique identifier to help you remember. I recommend geographical names of cities or countries, as this is a more useful mnemonic than simply using the roomName, and it is less likely to get confused (opName is a distinct variable from roomName, so having them be the same might interfere with debugging).
For example, you could use the following flag to initialize a FortOperation: fort_denver0
This would result in an instance of FortOperation with the opName denver0 that functions relative to the room in which you placed it. It will spawn creeps using the spawns in that room, fill extensions, mine sources, upgrade the controller, operate labs, defend against invaders, and trade energy/resources with other rooms.
To access the operations memory or missions through the console, you could do something like the following:
denver0.memory.powerMining = true; // activate power mining for that owned-room
denver0.missions.upgrade.setMax(3); // override the computed number of upgraders and have it spawn only up to 3
denver0.missions.builder.setBoost(true); // boost the builder with XLH2O
Since all operations are exposed to the global object, it is important not to use an identifier that is likely to be used as a variable name (like simple letter names);
Similarly, remote harvest rooms can be initialized by placing a flag: mining_opName To help me remember which rooms are working together, I usually base this name off of the FortOperation that will serve as a host. For example: mining_denver1
MiningOperation and FortOperation require no further setup to function using default parameters, but there are ways to fine-tune their behavior to meet your needs/layout. See the Operation articles for more details (coming soon).
KeeperOperation is really where bonzAI starts to shine. These are hosted by rooms RCL7 or greater that are situated near a Source Keeper room. They work very similarly to a MiningOperation, but will also spawn a "trapper" to eradicate Source Keepers that are guarding the resources. An instance of KeeperOperation will bootstrap using the following flag name: keeper_opName.
Although KeeperOperation can function without further setup, it is possible that you will want to specify the order that the trapper visits the lairs. This can be done by constructing an ordered array using flag names. The flagnames will use the following convention: opName_lair:0, opName_lair:1, opName_lair:2, opName_lair:3. (The use of the colon is actually a convention that we are deprecating, other flagNames that serve this purpose will just use an additional underscore like with waypoints: opName_waypoints_0). When these flags are used, the trapper will visit only the designated lairs in the designated order. This can be used to exclude lairs from the rotation, by only using 1-3 lair flags.
Sources/Minerals can be excluded by placing a flag with any name on top (example: exclude1).
Some of the first console messages you will probably see will be about "emergency spawnCarts". SpawnCarts are creeps that refill your spawning energy. Under normal conditions, there will always be one present in each owned-room. Not detecting one is what sets off this "emergency" condition, which is one of the functions a room uses to stabilize itself (the other is emergency miner, which will spawn if you have no energy available in your storage). If you have enough energy already in your extensions, these will get spawned right away and you'll stop seeing those messages. If your layout fits the spec and there are no other issues, your game will take roughly an hour to bring itself back to a stable state.
If you have adequate mining/keeper operations, your storages will gradually fill up and you will start to meet energy demands within a relatively short period (24-hours). Rooms that are struggling to meet energy demands will start to get contributions from more established rooms, and wall-builders and upgraders will start to spawn with more work parts to take advantage of the influx of energy.