Palworld Breeding Support Pals: A Facility Compatibility Test

Do not rebuild your breeding setup around an unverified lineup. Test one facility and one support change under your current version first.

Define the facility question

Turn a broad request for breeding-support Pals into one testable compatibility question.

• Record the current game version and the exact facility being evaluated.
• Write the claimed benefit as an unverified hypothesis.
• Choose one observable comparison without assuming a specific mechanic or rate.
• Keep standard and ancient facilities as separate test contexts.

Build a clean baseline

Capture the current facility behavior before introducing a candidate support Pal.

• Record the Pals currently assigned or placed around the facility.
• Note relevant placement, available inputs, and other visible setup conditions.
• Observe the same process under conditions you can reasonably repeat.
• Describe what happened without converting one observation into a universal rule.

Test one candidate change

Make the comparison interpretable by changing a single setup variable.

• Select one candidate from the community-suggested list.
• Add, remove, or replace only that candidate for the next comparison.
• Keep the facility and remaining setup unchanged where practical.
• Record the result beside the baseline rather than replacing the baseline entry.

Check facility compatibility separately

Prevent a result from one facility type from being applied to another without evidence.

• Repeat the baseline on the second facility before adding support candidates.
• Use the same candidate-change procedure for that facility.
• Label results by facility instead of combining them into one conclusion.
• Leave compatibility unresolved when the observations are inconsistent.

Interpret the comparison

Choose the next action without overstating limited observations.

• Keep the setup when the same useful difference appears under comparable conditions.
• Retest when several conditions changed or the observation is ambiguous.
• Restore the baseline when the candidate change provides no clear reason to keep it.
• Treat the result as specific to the recorded version and facility.

Know when to recheck

Keep the conclusion patch-aware without claiming that an unrelated update changed breeding.

• Retest after an official notice that specifically affects breeding, the candidate Pals, or the facility.
• Do not infer a breeding-support change from unrelated balance or bug-fix notes.
• Preserve earlier observations with their version labels.
• Review the setup again when current behavior no longer matches the recorded result.

Decision checklist

• Record the current game version.
• Name the exact breeding facility being tested.
• List the current Pals and their placement.
• Write one observable baseline result.
• Choose one candidate support Pal.
• Change only that candidate-related variable.
• Record the comparison by version and facility.
• Restore the baseline if the result is unclear.

Worked example

Suppose a player uses an ancient breeding facility and has heard that Grintale, Broncherry, Broncherry Aqua, and Braloha form a useful support setup. The player first records the version, facility, existing placement, and a repeatable baseline observation. They then add only Grintale while leaving the other recorded conditions unchanged where practical. The next observation is logged separately. If a difference appears, the player repeats the same comparison before keeping the change. The result remains labeled as an observation for that version and ancient facility; it does not establish how another facility or the full suggested lineup behaves.

Common mistakes

• Treating a community-suggested lineup as a confirmed current mechanic.
• Changing several support Pals and the facility at the same time.
• Applying a result from one facility type to every breeding facility.
• Recording only the changed setup and losing the baseline.
• Turning one observation into a precise bonus or universal recommendation.

Related guides