Build a science-fiction settlement around one constraint

Imagine a remote settlement whose supply ship arrives only once each season. This is a fictional scheduling rule, not a claim about a real planet or propulsion system. What matters first is what people do because of it: who orders replacement parts, who decides what travels, and who must wait when something is missing.

One constraint can generate a useful setting if you follow its consequences. It does not need to explain the entire universe before it gives your characters a difficult day.

State the premise and its boundary#

Write the rule in a sentence: the settlement can receive cargo only at the seasonal arrival. Then list what the rule does not yet establish. It says nothing about gravity, radiation, communication speed, or whether the settlement produces its own food.

Decide those details only when they matter, and distinguish researched science from invented capability in your planning notes. If your plot depends on a real physical process, research that process before assigning numerical limits. This exercise supplies no engineering specification or survival calculation.

Follow one replacement part#

Choose an ordinary system that needs maintenance. In this example, a food-storage unit uses a specialized controller the settlement cannot manufacture. The shipment contains one replacement, but two units fail.

Write down who notices the fault, who diagnoses it, who holds the spare, and who can authorize its use. Those roles may belong to different people. A technician can know the answer without having permission to act; an official can control the decision without understanding the machinery.

Let the constraint shape institutions#

The spare could go to a public storehouse or a private supplier. Decide what rule governs the allocation and whether residents consider it fair. Is there a reserve policy? Can anyone appeal? Who records the decision?

Avoid giving every resident the same attitude toward the system. Someone who survived an earlier shortage may favor strict reserves. Someone whose livelihood depends on today’s delivery may accept more risk. Build the disagreement from their circumstances rather than labeling one side rational and the other foolish.

Test an ordinary scene before a catastrophe#

Write the scene where a worker requests the part. What form, conversation, queue, or favor stands between noticing a problem and repairing it? The exchange can reveal the settlement more clearly than a page listing its technologies.

Then introduce a change: the next ship is delayed. Follow the existing rule rather than inventing a perfect replacement technology to escape it. If an alternative is possible, establish its cost and limits early enough that using it feels earned.

Follow the shortage through one season#

Here is the replacement-part example carried forward. It is one possible version, not the correct one.

One failed unit sits in the public storehouse, which feeds most households; the other belongs to a private supplier who sells to whoever can pay. The roles divide like this:

The officer sends the spare to the public storehouse, because the written rule favors the unit that feeds more people. The technician patches the supplier’s controller as a paid side job. The supplier raises prices and calls it a risk charge. So far, every choice is defensible.

Then the ship is delayed. The reserve is empty and the patched unit is now the settlement’s only backup, so the supplier, not the council, holds the margin of safety. Households start asking the technician for favors directly. Families who cannot afford the new prices appeal the officer’s decision, and the depot keeper must defend a reserve rule that no longer protects anyone.

By the next arrival the settlement has changed without any new technology. The reserve rule may now demand two spares, the technician has become someone people owe, and the supplier has learned what scarcity is worth.

Decide how much the story must specify#

The detail you need depends on what the story asks the reader to track. Treat this table as an editorial starting point, not a rule.

Length matters too. A short story can live inside one failure and one decision. A novel has room for the whole season, delay included. A series can show institutions hardening or loosening across several arrivals. With more than one viewpoint, the technician’s chapters can carry repair detail that would stall the officer’s.

Track what changes and what remains unknown#

Put the shipment, failure, and allocation decision on a timeline. Sketch the relevant stores and routes using a working map. Keep uncertain technical details separate from facts already used in the manuscript.

Your first useful setting document can be short: one premise, one system, the people responsible for it, and the decision it forces. Expand the culture through the habits that grow around those responsibilities. A calendar marking cargo arrivals, a family that saves every spare fastener, and an argument over a repair can all arise from the same starting rule.

Common mistakes and how to fix them#

A loophole in the premise. If help can arrive by message or a spare shuttle, the seasonal rule stops binding. Decide what the settlement can and cannot request between arrivals, and check each new capability against the premise.

Everyone understands the machine. A settlement where every resident can diagnose the controller has no gatekeepers and no misunderstandings. Give the system users who depend on it without knowing how it works: cooks, teachers, and the households queuing at the storehouse.

Carry the constraint into Yazar.io#

Yazar.io has sections that map neatly onto this settlement: the depot in Locations, the spare part in Items, the seasonal cargo rule in Lore, and the people who allocate the part in Characters. Mention the cargo rule in their entries and the rule’s backlink panel shows everyone it constrains (features).

Keep technical assumptions apart from established story facts with notes and their statuses: an assumption stays an Idea or In Progress until a scene commits to it, then becomes Used. When the ship is delayed, the links show which people and places the delay touches, so the new scene follows the same premise.

Update, 10 October 2026: Added a worked example, guidance on detail by genre and length, and common mistakes, and expanded the Yazar.io section with specific features from Yazar.io’s public pages. On 8 October 2026, a topic-specific Yazar.io suggestion had been added.