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.

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 @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.

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