When the Backpack Is Full, How Do You Preserve the Delivery Commitment and Still Give Players Choices?

When the backpack fills up in a delivery story, first determine whether an item can be freely disposed of, then determine where it should go. A crucial package can take up space or temporarily leave the character's possession; as long as the delivery obligation remains unresolved, an ordinary “discard” action must not make it disappear. Players should be able to choose between storing items, changing equipment, giving up ordinary belongings, or changing routes.

Classification depends on the current commitment, not appearance or rarity. A beautiful stone can be set down without a second thought, while an ordinary letter may be part of a delivery request the character has already accepted. The author needs to answer four separate questions: who owns the item, who currently holds it, what must be done with it next, and what counts as fulfilling the obligation?

The following “Fog Harbor Delivery” scenario is a fictional teaching example. It is not a real user case or a tested result, and it does not represent any product feature. All capacities and conditions are design assumptions for this example.

A courier named Ahe must deliver a sealed costume case to the theater manager. Her backpack has six slots. The costume case takes up three, while a rain cape, tool kit, and souvenir jar each take up one, filling it completely. Before stepping onto the slippery pier, she must also obtain a pair of slip-resistant boots that takes up two slots. The design question is: how can she free up two slots while preserving a delivery commitment she can still fulfill?

Use the following table as a reusable template. Give each item a separate unique ID and retain that ID when its location changes, so storing and retrieving an item does not turn it into two items.

“Current obligation” also needs an accompanying location record, such as “Costume case: harbor storage locker; delivery responsibility: Ahe; status: awaiting retrieval.” Storage changes where the item is held; it does not mark the request as completed. Only a handoff confirmed by the recipient resolves the obligation. An item being absent from the backpack is not enough to count it as delivered.

“Permitted actions” in the table are not permanent attributes either. If someone later asks Ahe to pass the souvenir jar on to another person, first present a choice to accept that commitment, then update the disposal rules. Do not wait until the player tries to discard it to announce that it has suddenly become a crucial item.

Discarding ordinary items also requires a clear account of what happens to them. In this example, discarded items cannot be retrieved. If the author wants to allow recovery, the drop location and conditions for returning must be recorded. Either rule can work, but they must not be switched on the fly to rescue a situation.

This example places a staffed storage service before the pier, open only until the ferry departs. Ahe can check the costume case into storage, reducing backpack usage from six slots to three; collecting the slip-resistant boots brings it to five. The registration details go into a quest log the player can consult, rather than generating a separate, discardable claim ticket as the sole proof needed for retrieval.

The storage prompt can use this sample wording directly: “The costume case will remain at the harbor storage service. You are still responsible for delivering it. You cannot return after the ferry departs. You can retrieve it before departure.” This explains the location, responsibility, and deadline together, so players do not have to infer the consequences from the word “Saved.”

If the costume case is still in the locker, choosing to board should display the outstanding task and allow the player to return to storage. This example does not allow departure while the item remains uncollected, because the author has not written the story that follows a failed delivery. The block should occur before the irreversible departure; players should not discover at the theater entrance that the main storyline has already been broken.

The storage service closing, the locker being moved, or proof of storage being lost can all become story events, but each requires a separately written, reachable branch for dealing with it. Temporary storage rules should not quietly introduce those risks. If the work does make storage come at a cost, show the conditions before storage and provide a route for declining it.

Storage only eases the immediate space problem; capacity must be recalculated when the costume case is retrieved. For this reason, the example provides one clothing slot and one footwear slot. Worn items take up no backpack slots, and both equipment slots start empty. The slip-resistant boots satisfy the pier's access condition only when worn; having them in the backpack does not count.

The complete calculation is as follows: six slots used initially; three after storing the costume case; five after collecting the slip-resistant boots; two after putting on the rain cape and boots; five after retrieving the costume case. The backpack now contains the costume case, tool kit, and souvenir jar. Ahe is wearing the rain cape and boots and can board with the delivery.

This solution works because both equipment slots are empty. If the footwear slot already holds old boots, the change must also account for the space needed to pack them. A sample rule could read: “First list every item's location after the change and the total backpack slots used. Only if capacity permits, complete removal, packing, and equipping together. Otherwise, leave everything unchanged and list the items that could be moved to make room.”

Do not put on the new boots first, discover that the old ones will not fit, and then arbitrarily delete an item. If the player cancels the equipment change, the location records should also return to their state before the action, without leaving a partial equipment change or duplicate items.

Players have other options too. Putting on the rain cape first frees only one slot, still insufficient to put the two-slot new boots in the backpack. Discarding the souvenir jar as well makes collection possible. If “Collect and wear immediately” is offered, the empty footwear slot can be used directly, but that action must be clearly shown rather than existing only in the author's intended solution.

During acceptance checks, do more than follow the correct route once. Check whether three conditions still hold after each action: every item has exactly one location; the backpack is within capacity; and every unresolved delivery obligation still has a path forward.

These are checks to be performed, not a report of passed tests. If any case can only be handled by narration claiming “the package is actually still there,” the corresponding location and action rules need to be completed.

There is also a simpler alternative: place all delivery items in a quest inventory that does not count toward capacity. This suits a design in which inventory management plays a secondary role, but weakens the trade-offs around delivery items taking up space in this problem. Another approach allows players to deliberately break the commitment. That requires a separate option, advance notice that the delivery will fail, and a connection to an already written branch. An ordinary inventory-clearing action must not make that decision for the player.

The minimum reusable record is: item ID, space required, location, responsible party, permitted actions, retrieval deadline, handoff recipient, and resolution condition. Once these are filled in, work through the sequence from the most crowded point to receipt. These safeguards should prevent accidental actions from erasing an outstanding obligation. They should also make clear to players what they are holding and which choices cost them backpack space and additional travel.