playerIntel request

[CarsonBurke]

Overview

• Information about enemy players
• replace the previous hate request, sending more data

Properties

• hate?: number - how much the bot thinks its allies should hate the player
• playerName: string
• known GCL?: number
• highestRCL?: number
• offensiveThreat?: number - if your team isn't running the same bot you probably don't want to use this
• defensiveStrength?: number - if your team isn't running the same bot you probably don't want to use this
• lastAttackedBy?: number - allows bots to estimate how aggressive a target is

[V1kingGit]

offensiveThreat and defensiveStrength are ambiguous, and with your reasoning shouldn't be included here imo. lastAttackedBy and hate are ambiguous and need standardization. knownGCL and highestRCL as acronyms should be knownGcl and highestRcl to match naming conventions. I also think they're unnecessary, as they are highly specific computations that can be deducted from roomIntel by the player. Alternatively you can share an array of rooms and deduct it from that.

[CarsonBurke]

Offensive threat, defensive strength and hate are intentionally ambiguous for two reasons. First is to allow teams to come up with their own standards. But still, it's probably too ambigious as is and could benefit from some rules and guidelines

Second is that I intended these values more for communication between bots with the same code. For example, a commie bot talking with a commie bot. However, since this is very much a project for the community, maybe it would be better for me to make special requests that only commie bots use?

[CarsonBurke]

Last attack by should be the tick the bot was last attacked by the player in question. I'll clarify this in the comments

[V1kingGit]

I would assume lastAttackedBy to be when a military creep enters your rooms/remotes. Remotes is a very loose term, either way it could just be them defending. It also doesn't scale well, a single 1R1M would trigger it as much as 25 of them, and therefore doesn't provide a valuable estimate of how aggressive a target is. Overall I'm just not convinced how useful of a metric it is, and would prefer others such as hate, but that may be hard to standardize effectively.

[glitchassassin]

Offensive threat, defensive strength and hate are inte rionally ambiguous for two reasons. First is to allow teams to come up with their own standards. But still, it's probably too ambigious as is and could benefit from some rules and guidelines

It might make sense to narrowly focus the spec on things that are clear and actionable, and allow custom extensions that don't break the spec for things that are ambiguous/codebase-specific

[CarsonBurke]

I agree with both. I think we need some framework to make hate and threat less ambiguous (hate being how much you want to fight someone, threat being how strong they are) but I'm not sure how to do that exactly. Are there any ideas? putting it into a 0-1 doesn't fix the relativity of it.

[glitchassassin]

Well, what's the expected action?

Are we aiming to achieve consensus on targeting of automated attacks? Providing warnings to avoid the rooms of dangerous players? Estimating the cost of an attack? Each of these expected actions needs different mechanisms. Let's start by being more clear about that and then it will be easier to be less ambiguous.

[CarsonBurke]

The idea of this is to give the team an accurate understanding of the enemy. It definitely needs to be more objective and such.

Say player X is attacked a lot by the enemy, so they have a high threat rating. They can communicate this to their team so that team member Y and Z might shift their priorities towards harassing the enemy and helping player X. Automatically, of course