The base is full, the ore is not being mined, something is on fire — and catching a better Pal will not fix any of it.
Every Palworld player hits the same wall around the twenty-hour mark. The base is full, the ore is not being mined, something is on fire, and the instinctive fix — catch a better Pal — does not work. The constraint was never the Pals you own. It is the slots you have to put them in.
Why a full base stops working
A base has a fixed number of Pal slots, and every job you want done needs a Pal with the right work suitability at a high enough level to do it at a useful rate. Kindling, watering, planting, generating electricity, handiwork, gathering, lumbering, mining, extracting, medicine production, cooling, transporting, farming: thirteen jobs, and far fewer slots than jobs.
The naive approach is one Pal per job. That fills your base before you have covered half of what a mid-game base needs, and it leaves you with a lot of specialists standing around while the one thing you actually need is unattended.
The efficient approach is coverage. Most Pals do several jobs, and the right question is not "who is best at mining" but "which small set of Pals covers everything this base needs, at the levels it needs".
Set cover, not tier lists
That question has a name in computer science. Choosing the smallest group that covers a list of requirements is a set-cover problem, and it is NP-hard — meaning that for any interesting number of Pals there is no fast method that guarantees the best answer.
PalDB's base planner takes the practical route: you set what the base has to do and it works out which Pals cover it in the fewest slots, using the game's own work suitability levels. It picks greedily, taking at each slot the Pal that closes the most of what is still missing, and it says explicitly that this is an approximation rather than a proof — for a tight slot budget, a better combination may exist.
That honesty is the useful part. A tool that hands you a five-Pal team and calls it optimal is overclaiming; one that hands you a team, shows the coverage it achieves against what you asked for, and tells you the method, lets you check it and adjust.
What good coverage looks like in practice
Two patterns come out of doing this properly.
Generalists beat specialists at low slot counts. A Pal with level 3 in three jobs frequently earns its slot over a Pal with level 4 in one, because the slot is the scarce resource. Anubis is the standard example: high handiwork, mining and transporting in a single body, which is why it appears in almost every efficient base regardless of what the base is for.
Over-coverage is waste you can see. If you need mining at level 8 and your team provides 9, that extra level is a slot you could have spent elsewhere. Planning against explicit requirements rather than vibes makes that visible immediately.
Build for the base, not for the game
The other realisation that saves hours is that "a good base team" is not a single thing. An ore farm, a berry farm, an ingot forge, a ranch, a cake kitchen and a power plant want genuinely different teams, and trying to make one base do all of them is what produces the clogged, on-fire base everyone recognises.
Specialising bases and planning each one against its actual job list is more effective than any individual Pal upgrade. It also makes the endgame Pals matter less than people expect — a legendary in a base slot is often doing a job a common Pal does equally well.
The bit nobody plans for
Transporting is the job that quietly breaks bases. Production without enough transport produces piles of material sitting where they were made, and the symptom — nothing seems to be happening — looks like a production problem rather than a logistics one.
Cooling is the same story in cold biomes, and both are easy to leave out of a plan built around the visible jobs like mining and handiwork.
Planning a base around its requirement list rather than around its headline job catches both, which is the entire argument for doing it on paper before you do it in game.
Leave a Comment