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

Breeding passives on a specific step doesn't take into account future passives #95

Open
ayellowlizard opened this issue Jan 10, 2025 · 11 comments

Comments

@ayellowlizard
Copy link

ayellowlizard commented Jan 10, 2025

image
(very badly drawn red circles but you can probably see the problem here)

A Ryu-F with Vampiric (not a part of the final product) is used, despite a Ryu-F with Demon God also being available.

The Demon God Ryu can be substituted into the Vampiric Ryu, which would save time (since Demon God is one of the desired passives)

@ayellowlizard ayellowlizard changed the title Small time-waster I noticed: Breeding passives on a specific step doesn't take into account future passives Breeding passives on a specific step doesn't take into account future passives Jan 10, 2025
@tylercamp
Copy link
Owner

Interesting, nice catch, I presume Pal Calc would’ve considered both options and (for some reason) considered this to be more optimal than what you expected

I’ll need to properly debug/investigate when I have time

@tylercamp tylercamp added the bug Something isn't working label Jan 10, 2025
@tylercamp
Copy link
Owner

tylercamp commented Jan 11, 2025

Looking at the raw data in the debugger, I see that:

  • The estimate for the suggested, 1-step path takes ~04:10:00
  • The top part of the displayed path has an actual estimate of 04:00:00, but it gets an extra 50 minutes because of the "specific gender" requirement

This explains why the selected path is chosen over the expected one, it just has a shorter base estimation.

BUT there's more to it than that - the gender requirement would've had a much larger impact if the simpler approach was used. Gender probabilities for this pal are 50/50, and would double the time estimate of the required-gender step. The simpler, 1-step path would become 08:20:00 instead of 04:10:00

This graph looks weird at first, but it's actually more efficient because the part which gets a specific gender has fewer overall requirements. It minimizes the impact of requiring a specific gender by doing part of the "breeding selection" in an earlier step

So this is behaving as intended and is, counterintuitively, the optimal path

@tylercamp tylercamp added not a bug and removed bug Something isn't working labels Jan 11, 2025
@tylercamp
Copy link
Owner

The behavior shown here is working as intended but it does expose another potential optimization method. While Pal Calc does apply the required-gender effort calc when building a new child, it doesn't take that into account when deciding which pals to keep + discard.

(This whole process could potentially generate billions/trillions of intermediate pals, the only way to make this manageable is to throw out suboptimal pals before adding anything to the next step. This is why there aren't any other tools that can solve for full passive trees - pruning is needed to make it work, and making a good pruning system is very hard to do right)

I'll try including self-breeding-effort as a discriminator (pals are grouped by discriminator properties and duplicates are removed within these groups), and as part of the actual "optimal pal" pruning process

@tylercamp
Copy link
Owner

Re: placing in discriminator - my testing suggests this check is either unnecessary or rarely useful. On average this increases breeding pairs by ~10x (in one case going from 50.9m total checked to 1.6b total checked) and in my limited testing I didn't find any cases where the result was any better

If placing in a discriminator isn't useful, then adding it to the sorting process wouldn't be useful either, but I tried it anyway and the only effect was a preference for longer breeding paths (though they'd have the same final time estimate)

Overall this is interesting to note, but apparently not something we need to account for in the breeding solver

@tylercamp
Copy link
Owner

I'll leave this open in case you have any other questions/comments

@ayellowlizard
Copy link
Author

ayellowlizard commented Jan 12, 2025

Untitled1576_20250112165133

I'm a little confused. Wouldn't this be better as there are two options to choose from? (versus the one offered by the other solution) One can skip a part and the other is what's already pathed out in the tree. Sorry if that's a stupid question haha.

@tylercamp
Copy link
Owner

tylercamp commented Jan 12, 2025

The issue is the chance of getting exactly two passives, those being the ones we want, and being the correct gender

All of that in a single step is very unlikely so it gets a high effort estimation and ends up being sub-optimal

Typing from bed atm but can type out the exact probabilities tomorrow

One big piece impacting probabilities is that we want exactly 2 passives, and the parents having 2 vs 3 to pick from makes a big difference. If there’s 3 available then we need to roll exactly 2 inherited. (30% chance IIRC). If there’s only 2 available then we could roll for 2, 3, or 4 passives, and those would all work since there’s only 2 to pick from anyway (60% chance)

So the decision to add in an extra passive there becomes much bigger than expected, and then the gender requirement multiplies the overall estimate for that step

@tylercamp
Copy link
Owner

tylercamp commented Jan 12, 2025

(I went into the full probability calc involved, which may be useful, but I missed OP's larger point, click this to expand and see those details anyway)

(I'm also a bit confused by your above picture, not sure what "Breedject" means? Anyway..)

In your comment you suggest that, when producing a Blazamut Ryu with [Impatient, Demon God], the suggested single-step path will be optimal. It's important to note that Pal Calc determines an "optimal" path based on probabilities and time estimates, not on the number of steps. A 5-step path taking 3 hours will be more optimal than a 1-step path taking 5 hours.

(tl;dr in next comment)

Your Suggested Path

To make this Blazamut Ryu using [Demon God] + [Impatient, Heated Body], we require:

  • Zero random passives - 40% chance
  • Exactly 2 direct passives, - 30% chance
  • The 2 direct passives, out of 3 available parent passives, are correct - 33% chance
    • There are 3 possible ways to choose 2 passives - [Demon God, Impatient, [Demon God, Heated Body], [Impatient, Heated Body]
    • We only want one of those three possible results, i.e. 1 in 3 chance

The estimate for this single step becomes 0.4 * 0.3 * 0.33 = ~0.04, or 4% total chance for this result, or 1 in 25 chance with 25 attempts on average. At 10 minutes per attempt, that gives a 04:10:00 estimate for this single step.

Solved Path

For the first part of the solved path with [Vampiric] + [Impatient, Heated Body] -> [Impatient], we require:

  • Zero random passives - 40% chance
  • Exactly 1 direct passive - 40% chance
  • The 1 direct passive, out of 3 available parent passives, is correct - 33% chance

The estimate for this first part is then 0.4 * 0.4 * 0.33 = ~0.053, or 5.3% total chance for this result, or 1 in 19 chance with 19 attempts on average. At 10 minutes per attempt, that gives a 03:10:00 estimate for this part.

The next part, involving [Impatient] + [Demon God] -> [Impatient, Demon God], requires:

  • Zero random passives - 40% chance
  • At least 2 direct passives - 60% chance
    • With only 2 parent passives to pick from, we can roll 2, 3, or 4 directly-inherited passives and we'd still end up with just the two parent passives
    • We couldn't do this with the suggested path since there was an irrelevant passive that could've been included
  • The only available passives are all desired, so there's no additional probability of selecting the "right" passives

The estimate for this second part is then 0.4 * 0.6 = 0.24, or 24% total chance for this result, or 1 in 5 chance with 5 attempts on average. At 10 minutes per attempt, that gives a 00:50:00 estimate for this part.

The 2nd part depends on the first part, so we need to add these together. 03:10:00 + 00:50:00 = 04:00:00 for the solved path.

The probabilities for the suggested path involve ~04:10:00. The solved path takes 04:00:00 instead. Even though the solved path involves more steps, it is more efficient.

(Pal Calc shows an estimate of 04:50:00 for the solved path, rather than the 04:00:00 I calculated here. This is because the next step, using this pal, requires to pals of opposite genders, which further modifies the effort. The probabilities I calculated are just the "base probability" of getting a Blazamut Ryu with any gender with [Impatient, Demon God]

Use in Later Steps

The Blazamut Ryu with [Impatient, Demon God] is then bred with the other to produce the final result. We'll try this with your suggestion and Pal Calc's solved path to see how the final result is affected.

Since both pals in the final step are "wildcard", i.e. they don't have a definite gender, Pal Calc needs to force one of the pals to have "the opposite gender" of the other. Pal Calc will consider setting each parent to the opposite gender of the other, and take the faster pairing, if any. If there isn't a particular "optimal" way to assign genders, Pal Calc will pick one randomly.

This doesn't affect the time estimate for the final step, which just requires that appropriate parents are available, but it affects the total estimate of the overall path. Therefore I'll just explain how both approaches are affected by the gender probability calc.

Required Gender - Your Suggested Path

As calculated above, the suggested path requires ~04:10:00 to produce in general, without imposing a specific gender. The other parent, with [Serenity, Musclehead], has the same estimate of 04:10:00.

Since both of these pals are bred in a single step and have the same time estimate, Pal Calc will assign just one of them with opposite gender. Since the graph shows this top part of the graph having a specific gender, we'll include it on this pal.

Blazamut Ryu has a 50/50 chance of male/female pairing. Therefore, to get a specific gender is a 50% chance, and will require twice as many breeding attempts. The suggested path takes 04:10:00 for a pal with any gender, and this required gender constraint brings it up to 08:20:00.

If the suggested path was used, getting an opposite-gender Blazamut Ryu would take 08:20:00.

Required Gender - Solved Path

The same 50/50 probability for a specific gender is required here. However, this is being applied on the 2nd half of this part which, as calculated before, has a base estimate of 0:50:00. A specific-gender requirement doubles this, bringing it to 01:40:00. Combined with the prior step, requiring 03:10:00, brings us to 04:50:00.

The solved path provided by Pal Calc takes just 04:50:00 instead.

@tylercamp
Copy link
Owner

tylercamp commented Jan 12, 2025

^ Comprehensive wall of text, highlighting the important bits:

In your comment you suggest that, when producing a Blazamut Ryu with [Impatient, Demon God], the suggested single-step path will be optimal. It's important to note that Pal Calc determines an "optimal" path based on probabilities and time estimates, not on the number of steps. A 5-step path taking 3 hours will be more optimal than a 1-step path taking 5 hours.

The probabilities for the suggested path involve ~04:10:00. The solved path takes 04:00:00 instead. Even though the solved path involves more steps, it takes slightly less time and is therefore more efficient.

Since both pals in the final step are "wildcard", i.e. they don't have a definite gender, Pal Calc needs to force one of the pals to have "the opposite gender" of the other.

If the suggested path was used, getting an opposite-gender Blazamut Ryu would take 08:20:00.

The solved path provided by Pal Calc takes just 04:50:00 instead with the opposite-gender requirement.

And to emphasize again:

Pal Calc determines an "optimal" path based on probabilities and time estimates, not on the number of steps. A 5-step path taking 3 hours will be more optimal than a 1-step path taking 5 hours.

The described result seems inefficient because it involves more steps. But the suggested path of directly breeding [Impatient, Heated Body] + [Demon God] -> [Impatient, Demon God] is, in fact, slower than what Pal Calc suggests because of the underlying probabilities involved.

@tylercamp
Copy link
Owner

tylercamp commented Jan 12, 2025

Another way of looking at this is that it's worth the extra time to "breed out" the irrelevant passive to just get a pal which only has the desired passives...

OH - your point is that this could be done by breeding with the Demon God pal, and there'd be a chance of getting a pal which just has both in the interim...

@tylercamp
Copy link
Owner

tylercamp commented Jan 12, 2025

I missed that since I'm explaining Pal Calc's approach and am (of course) biased towards how it reasons about things

So this relates to an intentional quirk of Pal Calc - if a parent has a passive we want, it will only consider children which inherit that passive. This means it never considers the case where Demon God is used in that "breeding out the passive" step, even though it could be used instead with a small chance of having a passive we want. If the parents have [Desired A, Desired B], Pal Calc will never consider a case where the child only gets [Desired A] but not [Desired B].

It is potentially more efficient to update with your suggested breeding path, but I'm actually conflicted about this, and am currently thinking "no". There are a few reasons:

  1. More complicated graph display - The new "lucky" case of inheriting both passives makes the rendered graph a lot more complex. The Impatient step would need to split into a graph where it happens to get Demon God too
  2. Confusing intent - A reader who sees a parent with Demon God might expect that they should pass it down at that step, even though they should take a pal which just has Impatient on its own if available
  3. In this case, this confusion would lead to a lot more effort in producing the child pal, since they might try to include the "specific gender" in the same step
  4. Reliability - Though it looks weird, by ignoring "lucky" cases Pal Calc is only producing reliable paths

--

(Continuing to reason about this, but am slowly convincing myself that this should be supported...)

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

No branches or pull requests

2 participants