Add Assimilation checks to Colonization

[Coolfeather2]

Pull request summary

Description:

I have added assimilation checks to the three colonization directives and the strategist This is an attempt to getting Overmind to play better when neighboring other Overmind users.

I am open to additional things you want me to try and get this implemented on - I have only thought about the colonization directives - or if there is better ways for my code.

Added:

• Assimilation checks to the following directives which checks if they are in a room owned or reserved by another assimilated user:
  • colonize.ts
  • incubate.ts
  • outpost.ts
• Added Assimilation check in strategist.ts to penalize the expansion room score if its owned or reserved by another assimilated user.

Changed:

• Modified the following directives:
  • colonize.ts
  • incubate.ts
  • outpost.ts
• Modified the strategist.ts

Removed:

• None

Fixed:

• None

Testing checklist:

• [ ] Changes are backward-compatible OR version migration code is included Not sure how to check this?
• [x] Codebase compiles with current tsconfig configuration
• [x] Tested changes on PUBLIC server OR changes are trivial (e.g. typos) Still currently testing strategist.ts, will update once done - looking for feedback currently

[ahmedcharles]

It might be better to not reformat all of the imports?

[Coolfeather2]

IDE formatted it when adding new imports automatically I'll roll back those chunks

[MatthewARoy]

Might as well add a low conflict mode where it plays nice with non-overminds too. A setting for growing empires to avoid pissing people off

[Coolfeather2]

Something like the mode discussed here?

106

[MatthewARoy]

Not really. Basically a mode where invading other players space is prevented. Low-conflict mode where you don't try and expand/mine from other players territory. So basically this mode, but for all players not just assimilated. Should be flag check of "if assimilated or in lowConflict mode"

[Coolfeather2]

This type of feature you're suggesting would need it's own PR, I do not intend to add a blacklist/whitelist for the player, I don't think it suits this codebase? It's ultimately Muons decision so we'll have to wait for him to have enough free time to review

[MatthewARoy]

Sure, happy to add it after your merge. I'm saying a setting to treat all other players reasonably well is a good stealth mode during a colony growing phase. Don't want your level 4 rooms picking fights over remotes with a level 8 room nearby.

[canberranet]

I agree @MatthewARoy, it probably have to be turned off for SWC, but attacking freely might be painting a target on your back.

[MatthewARoy]

Also it's just not very effective. A lower level room is going to be wasting precious resources trying to fight an RCL 8 room that just spawns a single 50 part creep to defend it's remote. You'll lose that fight every time and drain your room. Much better to try and claim uncontested resources.

I'd propose having a new bot setting definition that describes it's behavior (not in this PR, but in general going forward) 1) ExpansionPolicy: How aggressively it expands, does it attempt to settle near enemy rooms etc.

• Least aggressive is maintains a couple room buffer, only expands out of existing RCL 7 rooms that can defend.
• Most aggressive is that it'll attempt to expand to best possible spots, including into enemy remotes and from low RCL rooms. Tigga-esq 2) MiningPolicy: where it attempts to mine. 3) HarassmentPolicy: Will it actively attempt to damage enemies around it? 4) DefensePolicy: What level of response to harassment. Too high and rooms will starve themselves responding to small threats. Too low and you'll get harassed to death. Blacklist is a great example of how we could differentiate threats (eg policy of level 5 response for blacklist, level 2 for normal, level 0 for whitelist).

Universal whitelist/blacklist helps define behavior for all of these, where assimilation is considered whitelist. End-level behavior for whitelist could be as far as assisting in ally roombuilding/defending.