Lifetime value gives a clear prioritization value: filling an extension has a maximum lifetime value of 50 (its energ圜apacity), while the upgradeController job's maximum lifetime value is limited only by the creep's MOVE and WORK parts.
Lifetime value is defined as the total amount of energy a creep could deliver to the goal over its lifetime. All idle creeps are ranked against each unworked job according to their "lifetime value" and the best candidate is assigned to the job. Each goal creates a list of jobs that it needs accomplished every turn: mine this source, fill this structure. My current implementation if job-based: each room has a list of goals: harvest energy, upgrade controller, fill structures. The second two could probably have been worked around, but the first obstacle seemed insurmountable, so I decided to try a different approach. I could probably have driven this down, but the startlingly high CPU usage for the small number of creeps worried me.
Running max flow on my entire room graph every tick turned out to the expensive on the order of 10 CPU for about 10 creeps. I didn't have a good way of saying that upgrading a constructor for 10 energy per tick is somehow worth less than filling an extension for 3 energy per tick. The system had no idea of the relative value of jobs. By only looking at a single improvement at a time, I will never choose to fill up a container over carrying resources directly to the construction site, even though the team of carrier + constructor would have higher total flow. A single creep may not be the right choice to maximize flow through the room. That creep was assigned to that task for its lifetime. In order to decide what to spawn next, I chose the single creep that would individually increase the total flow through the room the most. The goal of the room is simply to maximize the flow of energy from sources to structures (this is a well-understood problem). A constructor with 2 work parts consumes 10 energy per tick (the rate is actually lower, because I factored in movement time as well). So for example, a harvester with 5 work parts produces 10 energy per tick. My first attempt was flow-based: I measured all energy gain and use in terms of energy per tick, and connected them using creeps. My first two attempts at deciding when and what to spawn have been failures.
0 kommentar(er)
