Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable Priority Target attribute #81

Open
ScorchedEarther opened this issue May 23, 2018 · 2 comments
Open

Configurable Priority Target attribute #81

ScorchedEarther opened this issue May 23, 2018 · 2 comments

Comments

@ScorchedEarther
Copy link

Circuit needs some way of picking out priority targets and attacking them first. Priority targets could be defined in the config file.

Suggestions for the logic behind selecting a priority target. Perhaps when cycling through available targets. for each group, it could begin by checking the priority targets first always. The priority targets could be considered a configurable x% closer than they actually are for the purposes of target selection.

Example targets:

Commanders
Singularity
Moho Geothermal
Superweapons
Anti
Penetrator
Sniper
Catapult
Ultimatum

@rlcevg
Copy link
Owner

rlcevg commented May 23, 2018

I'd prefer to have "example targets" in "isBuilder, resource cost, threat and other descriptive params of a unit" terms.
It already attacks builders first, than enemies with highest threat weighted by distance to own base and by distance from attack group to enemy target, etc. So there's priority picking.
I'll consider configurable config lists, but i think those may simply make configs less readable.

Also use only ZK's Brutal configs for Circuit's performance testing, all other difficulties are handicapped.

@ScorchedEarther
Copy link
Author

It already attacks builders first, than enemies with highest threat weighted by distance to own base and by distance from attack group to enemy target, etc.

Unfortunately most of the targets I'd want to select for priority destruction are not necessarily those with the highest threat or cost on the field. I don't think the configs would be that much more difficult to read by having one more attribute, and its a fairly self explanatory tag. It could be a fixed flag, it doesn't need to a variable, although that would be useful.

eg. The priority targets could be considered a configurable x% closer than they actually are for the purposes of target selection, where x is high (4.0 or 5.0!) for a singularity, middling for a commander (1.25) and low for a target that is actually best avoided (0.1 for a solar). This would make groups willing to travel longer distances and still choose the Singu as the best target, and might make the group ignore a solar even if it is really close. Perfect!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants