Open seivan opened 1 month ago
Not sure what the curve is supposed to do exactly. Scores are computed "from scratch" on every frame (with the exception of the consistency_bonus
) , but a curve implies some kind of continuity - some other parameter that affects the curve.
How will these curves affect how Yoetz chooses the strategy?
Also - Bevy has some builtin curve types - CubicCurve
and RationalCurve
. Any reason not to use one of them?
Not sure what the curve is supposed to do exactly. Scores are computed "from scratch" on every frame (with the exception of the
consistency_bonus
) , but a curve implies some kind of continuity - some other parameter that affects the curve.
No continuity, just logic to alter strengths of suggestions based on data.
How will these curves affect how Yoetz chooses the strategy?
It's wont. Yoetz
work with the numbers it gets. That's why I am wondering if it should be included.
This could very much be outside, but it would make help to make Yeotz
a little more batteries included.
The reasoning for it is simple:
How much health should an NPC lose before it goes for retreat
or medpack
?
These are two different suggestions
but they might both use the same values, e.g health
, number of enemies
etc.
Obviously you can write the code yourself but again, that's boiler plate, especially for a utility AI scoring library.
Say we're using health %
.
Meaning the lower the number is the more critical it is.
So we want it to be Decreasing
.
But not all numbers are the same, that's where curve comes in.
Having 80% health is not so bad, but having 20% health is critical.
So we want something like. SlowAtFirstFastLater
This mean the lower the health gets, the more critical the suggestion becomes.
Also - Bevy has some builtin curve types -
CubicCurve
andRationalCurve
. Any reason not to use one of them?
Naming. I didn't name them Polynomial
or other therms. Should be in plain English.
Could use the Bevy ones internally for the actual calculation. I wrote my own for now, I suspected Bevy had them which is why I didn't add them.
fn curved_score(&self) -> f32 {
let normalized = self.normalized_value();
//... here, as long as we get a number out.
}
The API should really be Increasing(SlowAtEitherEndFastInMiddle)::score(f32)
or something like that and not the monstrosity I showed here.
So basically it's utility types/functions that spits regular numbers? And they could have been in a separate, non-Bevy crate - but you think they should be included in Yoetz anyway as helpers for calculating the scores?
So basically it's utility types/functions that spits regular numbers? And they could have been in a separate, non-Bevy crate - but you think they should be included in Yoetz anyway as helpers for calculating the scores?
That's your call. I'm a bit peeved that rust libraries split their crates. I rather have one crate doing the related field rather than have it be split up. If it's a build time concept, I feel like that's a problem upstream with the compiler.
Slightly off topic tangent.
I think if you're making a Utility AI library then you should include fuzzy logic as they are related. https://www.youtube.com/watch?v=TCf1GdRrerw
They go hand in hand.
However, if not I'll make the crate myself, that's not an issue. As long as Yoetz
keeps accepting f32
input scores.
I was thinking of normalizing scores so I can start using Curves. I started of with this. I was wondering if it should be included. I am not saying to change the
suggestion
score argument, but this could be useful. Missing some curves, but the idea was to have plain english naming convention.Reading