However, things get hairy when you add multiple possible dropoff locations, such as when you build several dropoff links in a room. In the simplest case, the dropoff structure is only ever colony.storage, and this approach actually works decently well. Supplier.task = obtain energy from store structure Supplier.task = transfer energy to target Let target = closest high-priority unhandled request Hauler.task = withdraw energy from target Let target = highest priority unhandled request Hauler.task = transfer energy to dropoff structure (There are also mineralSuppliers and queens which have slightly-modified supplier logic.) This is basically how they worked in pseudocode: function haulerLogic(hauler): Haulers bring in energy from remote sources and put them in a dropoff structure and suppliers take energy from storage and distribute it throughout a room. My old transport system took a greedy approach which was simple but inflexible, needlessly separating creep roles which could be combined. Isolating requests to separate boxes makes it difficult to handle more complex requests which need require multiple transportation “legs”, such as moving minerals to a terminal, sending them to another terminal, then transferring them from the terminal to a lab. However, this system did not provide much in the way of flexibility. This way of compartmentalizing requests proved to be quite useful in some cases, giving the convenience of “throw it all in a box” while still allowing me to specify which creeps do what. At early levels, the hatchery puts requests into that group, but at RCL4+, the hatchery gets its own dedicated attendant (the queen) and its own request group. For example, each colony has a request group which suppliers attend to. TransportRequestGroups (which existed in my old AI, but which I cleaned up in the Overlord Overload rewrite) act as a “box” to group prioritized resource requests. Finally, in Part 3, I’ll give a detailed explanation of how my new logistics system works.In Part 2, I present a generalization of the “creep routing problem”, discuss why finding an exact solution is infeasible and motivate my approach in finding an approximate solution to the problem.In Part 1, I’ll talk about the advantages and disadvantages of my old system and why it motivated an overhauled logistics system.Since this post is really long (but I hope it’s worth the read!), I’ve divided it up into three parts: In this post, I’m going to talk about the overhauled logistics system I’ve spent the last few months working on. (And it’s probably the single part of the game I’ve spent the most time thinking about.) Members This is the total number of members in the alliance.Logistics – the problem of efficiently transporting resources – is one of the most interesting and deepest problems in Screeps. Unlike the GCL based metrics this score will go up and down based off of the state of world at the time. In other words, RCL8 rooms are worth three, RCL7 rooms two, and all remaining claimed rooms one. Max Spawns Each claimed room in an alliance is scored by the number of spawns it can support. This number should correspond to the number of power creep levels the alliance can currently spawn. Combined Power This combines the Power Creep levels for all players in an alliance. Alliance Power This metric combines the raw power points of all members of an alliance and calculates the Power Creep level the alliance would be able to spawn if they were a single player. With this metric a new user, regardless of skill level, will always add at least one to the score. Combined GCL This metric adds all of the individual GCL levels together to get one number. This method gives the best understanding of the alliance experience level. Ranking Types Alliance GCL This metric combines the raw control points of all members of an alliance and calculates the GCL as if they were a single user.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |