Back to Blog
charactersnarrativeworldbuilding

The Cast Grid: Design Characters From Relationships, Not Backstories

Character bios never tell you what happens when two people are alone in a room. Build the relationship grid first - want, obstacle and a concrete ledger for every live pair - and derive the cast from the pressures your story actually needs.

GameDesignerX TeamSeptember 17, 20267 min read

Your writer hands you six character bios. Each one is 800 words long, each one opens with a childhood, and after reading all six you still cannot answer the only question that matters in a scene: if these two are alone in a room, what goes wrong?

Backstory-first casts fail this test constantly. You end up with six well-documented people who have no reason to press on each other, and the story limps forward on plot coincidence instead of friction. The fix is to invert the order. Define the relationships first, derive the characters from what those relationships demand, and write the backstory last — as justification for a tension you already know you need.

This is the cast grid: a small, boring matrix that does more narrative work than any character sheet you will write this year.

Start with pressure, not people

Before naming anyone, list the pressures your story needs to apply to the player character. Not themes — pressures. Concrete forces that make a decision cost something.

For a small survival-drama game, that list might read:

  • Someone who makes the safe choice look cowardly
  • Someone who makes the risky choice look selfish
  • Someone who knows a thing the player needs and won't give it up cheaply
  • Someone the player is responsible for and cannot fully protect
  • Someone who was right about the player once, and hasn't let it go

Five pressures, five roles. Cast size falls out of this list rather than being guessed. If you cannot name the pressure a character applies, you have found a character to cut — and cutting one at this stage costs you a bullet point, not three weeks of voice-directed dialogue.

A useful ceiling for a team of under ten: six named characters with real arcs, plus as many functional NPCs (vendors, radio voices, quest-givers) as you like. Six is not arbitrary. It is roughly the largest cast where every important pair can still meet on screen at least once.

The grid itself

Lay the cast on both axes. Each cell is directed — what A wants from B is rarely what B wants from A — so a cast of six produces 6 × 5 = 30 directed cells. You will not fill all thirty, and you should not try.

Fill each live cell with three things and nothing else:

  1. Want — what this character wants from the other, in one verb phrase.
  2. Obstacle — the concrete reason they can't just ask.
  3. Ledger — one specific debt, secret, or shared event. Specific means it has a noun in it.

Here is a slice of a grid for a fictional coastal salvage game, Harbour Line:

From → To Want Obstacle Ledger
Vela → Otho Access to the harbour logs He blames her for the Kestrel sinking She was on watch that night and left early
Otho → Vela An admission of fault Saying it out loud makes it official He never filed the incident report
Juno → Vela To be taken on a dive Vela promised her mother she wouldn't The promise was made at a funeral
Vela → Juno To keep her on shore Juno is the better diver and both know it Juno found the wreck marker first
Otho → Juno Someone to run the harbour after him She wants to leave the island He has been quietly training her for a year

Five cells. Notice how much plot is already sitting there: an unfiled report, a deathbed promise, a succession nobody has discussed. None of it required a backstory document. The ledger column is doing the heavy lifting, because a specific object — a report, a marker, a promise — can be found, shown, or destroyed in a scene. An adjective like "resentful" cannot.

How many cells to fill

Give each character two or three live relationships. Under two and they float free of the cast; over three and their screen time fragments into scenes too short to land. For six characters, that lands you at roughly 12–16 filled cells out of 30. The empty cells are a design statement, not a gap: they tell you which characters have never really dealt with each other, which is exactly where a mid-game forced pairing will generate free drama.

Give every live cell a shape

A relationship that ends where it started is scenery. For each filled cell, write three beats:

  • Open — the state at first contact
  • Pivot — the scene where it changes, and what the player does in it
  • Close — one of: repaired, broken, transformed, or deliberately unresolved

Vela → Otho, for instance: opens as cold professionalism, pivots when the player finds the missing incident report and chooses whether to show it to him, closes as either a confession or a permanent freeze-out. That is a three-line spec, and it tells the level designer they need a room where the report can be found, the systems designer that a document can be carried and given, and the writer which two versions of the endgame conversation to draft.

If you track your narrative in GameDesignerX, this is where the pieces connect cleanly: the relationship map holds the grid, each character's pivot links to the story chapter where it fires, and the ledger items — the report, the marker, the promise — become entries in the lore bible so that three months later nobody quietly invents a second version of that night.

Three tests before you write a single line of dialogue

The swap test. Exchange two characters' lines in a scene. If it still reads fine, they aren't distinct yet — their difference is cosmetic. Fix it in the want column, not with an accent or a verbal tic.

The cut test. Delete a character from the grid and follow the broken cells. If fewer than two live relationships break, that character is decoration. Merge them into someone else; a merged character is almost always stronger, because they inherit two pressures instead of one.

The room test. Put any two characters with a live cell alone in a room with no plot to advance. You should be able to write 200 words of them avoiding the actual subject. If you can't, the ledger isn't specific enough.

A checklist you can run in an afternoon

  • Pressure list written before any names
  • Cast capped — six arc characters for a small team
  • Grid built with directed cells
  • Every character has 2–3 live relationships
  • Every live cell has want / obstacle / ledger
  • Every ledger entry contains a concrete noun
  • Every live cell has open / pivot / close
  • Every pivot is attached to a named scene or chapter
  • Swap test, cut test and room test run on the whole grid
  • Ledger objects registered as lore entries so the facts stay fixed

Why this holds up in production

The grid survives scope cuts better than prose bios do. When a chapter gets cut in month eight — and it will — a bio tells you nothing about what you just lost. The grid tells you precisely: you cut the Vela → Otho pivot, which means the report never surfaces, which means the endgame has two versions that no longer differ. That is a five-minute diagnosis instead of a week of confusion, and it usually points at the cheapest repair: move the pivot into a scene you already have.

Write the backstories afterwards, if you write them at all. By then they are easy, because you already know what each person is protecting.