But we can start with a couple basic units.
We’re a ways out from real combat code we don’t even have functioning labs yet. In some cases, we might want to overprovision Engineers to get things built more quickly if the FacilitiesManager is operating at PRIORITY level, it will multiply the work remaining by 1.5, increasing the number of provisioned Engineers. Now we can easily add up the outstanding construction sites and repair sites to calculate the work remaining.
Each WORK part equates to 3,750 units of useful construction work. I don’t have a good guess for what the actual efficiency will be, so let’s assume 50% for now. Practically, the Engineer will spend some of that lifetime moving from one site to another, or waiting for a request. Barring renewals, each WORK part is good for 1500 ticks, so we have an upper limit of 7500 construction energy per WORK part over the lifetime of the Engineer. The Engineer’s WORK parts can build for 5 energy/tick. Instead, we should build enough Engineers to handle the work that’s outstanding. My first instinct was to scale up Engineers to build as quickly as possible with the available energy, but I realized this is typically ineffecient: we’ll end up with a surplus of idle Engineers once the work is done. We need to scale up our force of Engineers. Scaling Up ConstructionĪfter fixing our logistics system, we now have more energy flowing: time to put it to good use. But my Office in Shard3 is being encroached upon, first by Invaders and then by another player settling right next door.
There are still some areas that could use help - creating an efficient route from one request to another is fairly slow - but it’s at least functional for now. We’ve spent a while rehashing this logistics system, rewriting it and then tuning and optimizing some parts of it. Here’s the GitHub repo if you’d like to follow along.
The article below describes the AI in its current state: I’m still expanding and refining my codebase.
0 kommentar(er)
