4. Workflow tips and prioritization for new players?

Workflow tips and prioritization for new players?


  • Hi,

    After a couple of false starts with Screeps in the past, I’d like to get stuck in and write an automated bot (even if it’s not a very good one).

    Clearly it would not be fully automated for a long time. But I’d rather have some horrendous base building logic than have to check in and make decisions about the best place to put my roads and extensions, for example.

    • What problems did you focus on early?

    • Or looking back what do you wish you had planned ahead for?

    • The amount of things to consider is substantial and I’m not even totally clear about what’s most important at each RCL ?

    • Is it better to just have poor code up on the main server asap to chip away at GCL or are there a few bare minimum things you recommend before heading into the wilderness?

    • Are there particular design patterns or concepts that you’ve found work well for you?

    At some point I’ll have to spend some time studying the source of popular bots and see how certain problems have been solved there, but interested to hear your thoughts.

    In short: Please tell me what you know!

    Thanks


  • @axis said in Workflow tips and prioritization for new players?:

    What problems did you focus on early?

    Static mining, road, rampart, and wall repairs, multiple rooms

    Or looking back what do you wish you had planned ahead for?

    Remotes, should've not waited till GCL7 with them 🙂 Was a big game changer.

    The amount of things to consider is substantial and I’m not even totally clear about what’s most important at each RCL ?

    Below RCL 8 -- getting to RCL8. At RCL8 -- getting more rooms to RCL8.

    Is it better to just have poor code up on the main server asap to chip away at GCL or are there a few bare minimum things you recommend before heading into the wilderness?

    Bare minimum. I develop my code on Live, makes it more fun. Dropped in immediately with just tutorial code.

    Are there particular design patterns or concepts that you’ve found work well for you?

    Early returns. Also, lodash is love, lodash is life.

    At some point I’ll have to spend some time studying the source of popular bots and see how certain problems have been solved there, but interested to hear your thoughts.

    Personally, I try not to study the code of others too much. Instead, I normally talk to the people on the slack (highly recommend joining if you haven't yet) to get higher end concepts and ideas on how they do things, then adapting and implementing them myself as appropriate. Also observing other's code out in the wild. Some interesting observations can be made that way.

    1 Reply

  • Hi @orlet thanks for your response, it's really helpful.

    Below RCL 8 -- getting to RCL8. At RCL8 -- getting more rooms to RCL8.

    Nice and simple! Perhaps it's best just to take this attitude and work through each obstacle as it presents itself rather than over thinking it without much experience. And I could definitely see myself pushing remotes way way down the list, so thanks for the insight there.

    Personally, I try not to study the code of others too much. Instead, I normally talk to the people on the slack (highly recommend joining if you haven't yet) to get higher end concepts and ideas on how they do things, then adapting and implementing them myself as appropriate. Also observing other's code out in the wild. Some interesting observations can be made that way.

    Reading codebases is not really my first preference either. Partly because in the case of screeps it kinda kills my ambition to see the level that those bots are at. And also it's just more fun to mess around, experiment and come to a solution I can take ownership of. I also much prefer working from more higher level concepts. But I have found reading/understanding other peoples code to be a great way to level up quickly with something new (in all work, not just screeps). Great point about observing peoples bases in the wild.


  • Clearly it would not be fully automated for a long time. But I’d rather have some horrendous base building logic than have to check in and make decisions about the best place to put my roads and extensions, for example.

    You can do basic build automation in a light version. For example: set a flag you use for the center of a standard blueprint of main buildings. And just place extensions every second tile in a chess pattern around it.

    • Or looking back what do you wish you had planned ahead for?

    It took me a long time until I mined minerals. But mining minerals and selling them is quite easy to get working. You can just save the credits you earn and be happy later on.

    • The amount of things to consider is substantial and I’m not even totally clear about what’s most important at each RCL ?

    In the beginning you can focus on energy handling. Increase the amount of energy harvested. Try to put all excess energy into the controller. And then try to optimize that process in term of energy lost for creeps and stuff.

    • Are there particular design patterns or concepts that you’ve found work well for you?

    State machines. If you use remembered states for your creeps, you will avoid running in a ton of silly bugs. Try to use states for all roles, even the simpler ones. Even basic stuff like 'getting energy from the storage' works best if the task is remembered.

    1 Reply

  • I didn't implement states so much as target lock. My run logic for my creeps looks for an existing target lock and jumps to that code otherwise it just executes the creeps role logic. When role logic decides it needs energy it calls the getEnergy method which records "getEnergy" as the method and the id of the target. Then each tick my creep repeats that method until it succeeds or something else in the getEnergy method decides it can't succeed (target no longer has energy, creep is full etc). This is not a full state machine my creeps either run their role function or their target lock. This pattern naturally allows me to switch to a new target easily but switching back was very hacky and I never really had a need.

    There are extreme optimizations where this pattern gets awkward. Like when filling extension moving towards the next extension after you issue the transfer intent. But I'd bet very few players have this implemented and stuff like this should be done very late game (like after you've got boosted offensive combat up).

    I wrote helpers early on so all of my creep methods like getEnergy accepted either the object of an id string then just did the right thing. This was a huge boon early on when I way trying out new behaviors. I could manually force a creep to take a particular target on the command console as easily as I could from code. Stuff like why is that creep continually transfering then withdrawing from the same container? Fine just go get energy from the storage while I add some print statements to figure what you're doing. Game.creeps.jerk.getEnergy("id of the storage copied from the ui");. Then once I was ready I forced it back into the situation that I thought was the cause.

    As others have said and I cannot stress enough remote mining should be very high on your list. I waited until I had multiple rooms up and running well before I started remote mining. My thought was that I needed to be able to handle the energy constraints before I could afford remote mining. All of that effort tuning my rooms was wasted as soon as I got remote mining up. Even the sloppiest implementation of remote mining will be energy positive. Just build a creep every 1500 ticks that walks to an adjacent remote room harvests till its full then comes back and drops off the energy. Sloppy, easy, and energy positive.

    I might even rank remote miners above static claimed room mining, I'm not confident that is the way to go, but if I were starting over that's how I'd proceed.

    I spent too much time optimizing RCL1,2 and 3 rooms. Now I just rush building the first tower, then getting the storage up (remote mining will help a lot here). I had carefully tuned how to mine into containers while building my storage, keeping energy around for extensions, and upgrading my controller. Just be sloppy and count on your remotes to make up the difference. Once you have a storage up then you can start applying (or implementing) energy tuning logic.

    I didn't have a way to run different versions of my room logic for a long time. It hurt a lot and now that I have I love it. I don't mean claimed vs remote, I mean remote v1 vs remote v2. I'm on like my 4th version of remote mining and I'm thinking revising it yet again to have shared on demand haulers. But this way I can try it out and debug it on a few rooms then once I'm ready switch all more remotes to the new system.

    Once you have a few RCL6 rooms and before you invest heavily in defense code I'd suggest you get energy sharing via terminals working. The easiest and most reliable attack against new and small players is to tower drain the room then sweep in once their room stops working right due to lack of energy. Energy sharing via terminals is an easy fix and something you'll want long term anyway to help balance your empire. A determined player could in theory still drain your entire empire, but at that point you have bigger problems. And honestly if someone tries it just spend a few days on your remote harvesting add in reservation logic, invader defense, dedicated haulers, etc. Each one will increase your energy income and you can just out produce the attacker.

    Lastly, ignore SourceKeepers as long as possible. I'd suggest they're lower on the list than power harvesting which is very late game.

    1 Reply

  • Hi @eiskalt, thanks for your response.

    Using flags sounds like a great way to get started quickly with basic automation. Thanks for the tip about using a flag as the centre/reference point. I could see how this would develop quite naturally into placing the flag prgrammtically based on certain conditions. I'll keep your words in mind regarding mineral mining too.

    I'm going to have to figure out something along the lines of a state machine or similar. At the moment, my creeps are pretty basic. I've just been writing a ton of short creep methods and composing various roles with them. The roles mostly just have a couple of states in creep memory - similar to the tutorial.

    Hopefully I can avoid loading my creeps up with too much state. Can see myself writing a lot of bugs if my creeps get too ‘clever’. But the state will have to be managed somewhere...will see.


  • Hi @deft-code thanks a lot for your in-depth response. I appreciate it.

    In short, I’m thinking much differently about my little codebase now. The amount of detail you’ve gone into is helpful and makes a lot of sense. Your comments especially around remote mining are a bit of a game changer for me right now. I’ve been spending a lot of time optimizing from RCL 1-3 so I’m glad to have this pointed out to me early on.

    All of that effort tuning my rooms was wasted as soon as I got remote mining up. Even the sloppiest implementation of remote mining will be energy positive.

    It seems so obvious when you put it that way!

    Thanks again. There are a ton of tips in your post (will certainly be refactoring my creep methods to take an ID) and lot to think about moving forward.


  • My bot was always fully automated and I never saw any use for flags, I just use Memory. Its first version only built 5 extensions close to the spawn, mined and upgraded the controller. I'm GCL 35 now and I never did remote mining, nor I intend to. This reduces complexity a lot and you never need to worry about CPU. I highly recommend that you join the next edition of the bot arena. It doesn't matter if your bot doesn't do much and doesn't last long. It's a nice way to benchmark it against other automated bots and get a lot of insights in a short amount of time. Also, you'll see how much headache and inefficiency fighting for remotes adds. One thing I regret is spending too much time with only one owned room, because I had no subscription and didn't want to run into CPU problems. I ended up with some code that was hard to adapt to multiple rooms. One last recommendation is to use sim room to test what you can (speciality auto layout) and a local private server for the rest. In the sim room, you can easily edit the terrain and instantly see how your layout adapts, using room visuals. The private server is not as convenient, but you can directly change the database to create the scenarios you want to test and save a snapshot, by simply copying a file. I don't see a benefit in having it running at all times, so I start it, test what I want, stop it, debug my code, restore snapshot, and repeat.

    2 Replies

  • @eduter your rooms are really simple. How much CPU does it take to run all 35 rooms like that?

    1 Reply

  • @deft-code I don't track CPU usage, but watching the CPU indicator in the UI for a while, I think my average must be between 80 and 90.


  • @eduter said in Workflow tips and prioritization for new players?:

    I'm GCL 35 now and I never did remote mining, nor I intend to.

    I did not have remotes until GCL7-ish. But adding remotes has significantly improved my economy. The difference was night-and-day, even considering my remote logic is not that fancy -- just a miner+hauler per every source, having hauler shuttle back and forth between its designated source and storage. In all honesty, I wouldn't want to go back to remote-less logic.

    1 Reply

  • @orlet looking at your stats for the last 7 days, you've been making ~334K Control Points / GCL / day, while I'm making ~371K. So, I'm making ~11% more than you per GCL, without remotes. Maybe you're focusing on things other than GCL, I don't know. I like to pick one metric and optimize for it. The metric I picked is control points / room used. This way, my bot has a relatively low footprint, so it doesn't become a bad neighbor. Conflicts are expensive.

    1 Reply

  • @eduter It doesn't make sense to limit yourself by not using surrounding resources, especially if you have cpu to spare. I think bot arena is valuable advice. However I think processing as many resources as your cpu will allow is the best route to growth. I would be interested if your solution improves as your GCL goes up. It may be that having as many rooms as possible is the most efficient solution so at some point neglecting remotes may be a suitable sacrifice.

    1 Reply

  • @eduter I only have 12 rooms, and 11 out of those are at RCL8, so effectively capped at 15e/tick. There's no much way to get past that outside of boosting, and I don't boost RCL8 rooms, it's too expensive. But compare the energy harvested numbers, and how much I spend on repairs.

    2 Replies

  • @orlet said in Workflow tips and prioritization for new players?:

    @eduter I only have 12 rooms, and 11 out of those are at RCL8, so effectively capped at 15e/tick. There's no much way to get past that outside of boosting, and I don't boost RCL8 rooms, it's too expensive.

    33 of my rooms are RCL 8 and I don't use boosting either, I just transfer energy to an RCL 6-7 room. I get an average of 16 CP/ tick / room.

    But compare the energy harvested numbers, and how much I spend on repairs.

    You're using more rooms than I am and harvesting more energy than me and yet, you only get around 1/3 of the control points I get. From my perspective (from how I decided to play Screeps), that's just inefficient. But we're clearly playing in very different ways and with different goals.

    My point was only that, for someone creating a fully automated bot, starting from scratch, I wouldn't recommend prioritizing remote mining. They may complicate things and you can do well without them for a long time. Harvesting and hauling is trivial, but automating the defense of remotes and, more specifically, the decision of when to give up on a remote, is a complex problem. The best fully automated bots I've seen, struggle with that.


  • @slowmotionghost said in Workflow tips and prioritization for new players?:

    I think processing as many resources as your cpu will allow is the best route to growth.

    To grow as fast as possible, absolutely. I went for simplicity and low maintenance.

    I would be interested if your solution improves as your GCL goes up. It may be that having as many rooms as possible is the most efficient solution so at some point neglecting remotes may be a suitable sacrifice.

    Based on my current CPU usage and the assumption that it would scale linearly on the number of rooms, if I had GCL 115 and managed to claim 115 2-sourced rooms, I would be the 1st in the expansion rank. It would take ages for that to happen, though.

    1 Reply

  • @eduter Good things come to those who wait


  • @orlet

    @orlet said in Workflow tips and prioritization for new players?:

    so effectively capped at 15e/tick. There's no much way to get past that outside of boosting

    Why don't you make a prayer room?

    1 Reply

  • I have only 18 rooms w/ remotes. I boost my upgraders as much as possible and I'm generally overloaded with energy. I think my rooms are more GCL / room efficient than either orlet or eduter. But I don't know if my CPU can scale up to my full GCL.

    I think eduter might be on to something: at huge GCL numbers remotes are less cpu efficient than claimed rooms. However, I'd wager that Temple Rooms are far more efficient than self sufficient claimed rooms.

    Which means I need to do 1 of 4 things to be a good citizen (e.g. don't hog rooms I don't need).

    • build a temple room
    • start processing power
    • drop some remotes
    • become a warlord and use the extra energy and CPU to cut YP in half from west to east(1).

    (1) OK, not really. Overlords has a NAP with YP. Someday I'll get bored and either leave the alliance or get the NAP dissolved.

    1 Reply

  • @deft-code said in Workflow tips and prioritization for new players?:

    I think eduter might be on to something: at huge GCL numbers remotes are less cpu efficient than claimed rooms. However, I'd wager that Temple Rooms are far more efficient than self sufficient claimed rooms.

    Eduter is only focusing on a single aspect of the game, increasing their GCL. I've looked at his rooms and they have almost no defense. I would also wager their military code is extremely lacking. I'm sure their praising code is probably pretty good though.

    Remotes are needed to increase the capabilities of a room, be that praising, defending/attacking, and processing power or minerals. They are a vital part to experience everything the game has to offer. Focusing on one aspect and eschewing the rest is not usually a good thing in a sandbox style game.


  • @slowmotionghost it's on the todo list, but right now I don't have the GCL to throw around willy-nilly. I'd rather have a full-fledged proper room. Right now my priorities are more at developing my code functionality rather than farming GCL.