A playtester opens your inventory screen, stares at it for forty seconds, drops three healing herbs on the floor, picks two of them back up, and then says the sentence every designer dreads: "Sorry, what was I doing?"
That is not a UI bug. That is an inventory system doing exactly what you designed it to do: interrupt the game and demand a decision. The question is whether the decision was worth the interruption. Carry capacity touches combat, economy, exploration, pacing and UI at once, yet most small teams pick a number — 20 slots, 150 kilograms — in week one and never revisit it. Then they spend the last month of production patching the consequences.
This post is about choosing that constraint on purpose: what each model does to play, how to pick numbers you can defend, and how to test whether the friction you built is the friction you wanted.
Decide what the limit is for
Before you choose slots or weight, write down the job. There are only four honest answers, and they lead to different systems.
1. Forcing loadout choices. The limit exists so the player cannot bring everything. Survival horror lives here: the whole tension of a grid-based case is that the rocket launcher and the shotgun ammo want the same rectangle. The limit should be tight, visible, and felt before the fight, not after.
2. Pacing exploration. The limit exists to send the player home. Mining and salvage games use capacity as a timer: you dive until you are full, then you walk back. The round trip is the loop. Here the limit sets session length, so it should be tuned against how long you want a sortie to last, not against realism.
3. Protecting the economy. The limit exists to stop the player hauling 400 iron ingots out of a dungeon and flattening your shop prices. This is a faucet problem wearing an inventory costume, and it is often better solved with vendor stock limits or weight-per-value than with slots.
4. Nothing at all. You inherited it from a template. If you cannot name the job, the right limit is "generous enough to be invisible" — a legitimate choice, not a cop-out. Most narrative games play better with no inventory pressure.
Write the job in one sentence in your design docs next to the system itself. In GameDesignerX, the items module is the right place for it, because every item you add later inherits that constraint, and a designer adding a quest item three months from now needs to know whether "takes two slots" is a balance lever or an accident.
The four models, and what each one costs
| Model | Example style | Creates | Costs |
|---|---|---|---|
| Fixed slots | 24 boxes, one stack per box | Fast to read, trivial to UI, easy to tune | Weightless boulders; a feather and an anvil are equal |
| Weight budget | Carry 160 units, overweight = slowed | Plausible, smooth difficulty curve | Constant arithmetic; players hoard to the gram |
| Spatial grid | Shapes packed into a case | Real spatial puzzles, memorable objects | Sorting busywork; brutal on controllers and small screens |
| Category caps | 6 weapons, 20 consumables, unlimited quest items | Protects the fun, hides the bookkeeping | Feels gamey; needs clear category labels |
Hybrids are usually the answer. A common and well-behaved combination is category caps plus stack sizes: unlimited quest and key items, a hard cap on the things that affect combat, and stack limits that keep consumables meaningful. Minecraft's 36-slot inventory with 64-per-stack stacking is this pattern — the limit bites on blocks and bites hard on tools, and nobody computes a kilogram.
If you use a grid, budget for the hidden cost: every irregular shape you add multiplies the sorting load. A case holding twelve 1x1 items is a list with extra steps. A case holding a 2x4 rifle, a 1x3 scope and six 1x1 herbs is a puzzle. Pick deliberately which one you are shipping.
Numbers you can actually defend
Capacity is one of the easiest systems to derive rather than guess. Work backwards from a target session.
Say you want a 12-minute scavenging run that ends because the player is full, not bored. Estimate what a competent player picks up per minute, then solve for capacity:
- Expected pickups: 4 per minute at a 60% keep rate, so roughly 2.4 kept items per minute
- 12 minutes × 2.4 = ~29 items
- Average footprint: 1.4 slots per item
- Target capacity: ~40 slots, minus a reserve for gear the player carries permanently
Then set your upgrade ladder as a percentage, not a feeling. A capacity upgrade below about 15% is not perceptible; above roughly 50% it erases the previous tier's decisions. A four-step ladder of 40 → 50 → 62 → 76 slots (+25% each) gives every upgrade a noticeable effect without voiding the constraint.
The same arithmetic works for weight. Pick the heaviest thing a player should be able to carry three of, call that 25% of the budget, and derive the rest. Put the resulting table in a balance sheet rather than in code — in GameDesignerX, the balance and economy module keeps item footprints next to the capacity tiers, so when you widen the case you can immediately see which items stop mattering.
Two rules that save a lot of grief:
- Keep stack sizes a power-of-two-ish ladder (10 / 20 / 50 / 99). Players estimate fullness visually; irregular stack caps like 37 make the inventory unreadable.
- Never make the tutorial inventory the smallest one. New players hit the limit before they understand it, and a limit you do not understand reads as a bug.
Design the overflow, not just the limit
Most inventory pain is not the cap but the moment it is reached. You have five options, and the difference between a beloved system and a hated one is usually which one you chose:
- Hard refuse — "Inventory full." Clearest, most frustrating. Acceptable only if the item stays in the world.
- Slowdown — overweight is allowed but punished with movement speed. Smooth, forgiving, and it turns a wall into a gradient.
- Auto-send — surplus goes to a stash or home base. Removes friction entirely; use when the limit is about pacing, not loadouts.
- Forced choice — a swap dialogue right there in the world. Great for tight horror and roguelikes, terrible if it opens mid-combat.
- Drop with recall — the item lands at your feet and is marked on the map. The best default for exploration games, because nothing is permanently lost.
Whatever you pick, make the full state predictable before pickup. A highlight on the pickup prompt showing the slot cost, and a count visible on the HUD, removes almost all of the forty-second stare in the opening paragraph.
Playtest checklist for carry capacity
Run this at your next session and write the answers down verbatim. Every line here is a question about the limit, not about the UI art.
- How many seconds did the player spend in the inventory screen per 10 minutes of play? Above ~60 is a warning sign for anything that is not a dedicated inventory game.
- Did they ever drop something and immediately pick it back up? That is a sign the cost of an item is not legible.
- Did they reach the cap before the system was explained?
- Did they carry a full "just in case" set they never used? If yes, your consumables are too cheap or your danger is too predictable.
- When the cap was hit, could they name the rule? "Six weapons" is learnable; "160 units" rarely is.
- Did they upgrade capacity at the first opportunity, or save the currency? Instant upgrades mean the limit is painful, not interesting.
- After an upgrade, did behaviour change? If not, the step was too small.
Log the answers against the build number. Capacity interacts with loot density, so a tweak that felt great in build 142 may be why build 151 feels bloated — and only playtest notes tied to a specific build will tell you that.
The short version
Carry limits are not realism and not housekeeping. They are a tax you charge the player for bringing power into a room. Name the job, pick the model that serves it, derive the numbers from a target session length, and design the overflow with as much care as the cap — then watch a stranger play, because the forty-second stare tells you more than any spreadsheet will.