Building a Cast, Not a Character
A cast is a system of relationships. Six properties held constant, four varied on purpose, and how to add a character later without it looking added later.
You have one character and it looks right. Then the second arrives and something is off. Side by side the problem names itself: one has a heavier outline, one sits lower on the floor, one is shaded a step further. Individually both are fine. Together they look like two games.
Your pipeline sets this up, because every stage of it treats a character as a single asset. The canvas, the animation set, the sheet contract: all specified per character. Nothing asks whether character four belongs with character one.
It is not a style problem. A cast is a system of relationships, and the relationships are specifiable: what every character holds identical, what varies, and how to check both without drawing.
The short version. Whether characters belong together is decided by six properties held constant: canvas and scale contract, line weight, rendering level, palette core, light direction, proportion system. Whether the player can tell them apart is decided by four varied on purpose: silhouette, palette accent, costume shape language, posture. Belonging and distinctness stop competing once each property has one job. Write the split down before the second character exists, since the first becomes the standard either way.
A cast is a system of relationships, not a collection of individuals
A character brief describes a person: a tired mechanic, a teenage pilot, a cook who never leaves the galley. Complete for one asset, useless for six.
Cohesion is not an average of six good characters. It is a set of properties identical across all six, and the player reads those as "same world" before learning who anyone is. Distinctness runs in reverse: a few properties that differ hard, not every property differing a little.
The failure lives between those. Six characters where everything differs slightly are neither cohesive nor distinct, and two of them still blur at play size. Decide per property: constant or varied, no third option.
The six properties you hold constant
Identical across every character. Not similar. Identical, to the pixel where a pixel is involved.
- Canvas and scale contract. Canvas height, the ground line inside it, and how many pixels one game meter occupies. Carries more cohesion than anything else here, and it is arithmetic.
- Line weight. If characters are outlined, the outline is the same thickness on all of them at the same zoom. Two pixels on one and three on the next reads as two art budgets.
- Rendering level. How far shading is taken: flat fills, cel shading with one shadow step, or soft painted form. One member rendered further makes the rest look unfinished.
- Palette core. The shared set every character draws from: skins, neutrals, metals, and above all the shadow color. Shadows tinted toward different hues break a cast faster than costume colors will.
- Light direction. One direction for the whole cast, stated in the brief. Characters lit from opposite sides cannot stand in the same room.
- Proportion system. Head count for an adult, plus size rules for hands, eyes and feet. Proportion still varies, but inside a system: a stocky character and a tall one agree about how a head relates to a body.
None of the six describes a personality. All six are checkable by someone who cannot draw.
The four properties you vary on purpose
Those six removed what makes characters look alike and none of what makes them recognizable. Distinctness comes from four levers, pushed hard.
- Silhouette. The outer shape filled solid black: headgear, hair mass, shoulder line, hem, carried equipment. The primary lever. Two similar silhouettes get confused at play size no matter how different the faces are.
- Palette accent. One color per character, drawn from the shared palette but owned exclusively. The mechanic owns rust orange, the pilot owns teal, and nobody else uses either as a dominant area. Accent ownership identifies a character at twenty percent of screen height.
- Costume shape language. Whether the clothing is built from rounded forms, angular ones, or rectangles. It reads as personality with no facial detail involved, and survives scaling down better than detail does.
- Posture. The default standing attitude: where the weight sits, shoulders forward or back, whether the head leads. Free distinctness, since you specify it in words.
Four levers covers a cast of six or eight. Varying line weight or rendering level to make someone stand out means you have run out of the right levers and started spending constants.
The canvas contract: lock the dimension that controls scale
The split made concrete. In one measured Makko cast, a crew of six, canvas height is locked at 560 px on every character. Width floats between 295 and 311 px, set by the character's build and pose.
Read as a consistency rule, that looks like a defect: six files, six widths. It is the opposite. Height controls scale and the ground line, so locking it puts every character at a known size relative to every other, with feet on the same row of pixels. Width controls nothing. A broad character in a wide stance needs lateral room a narrow one does not, and one shared width either crops the first or pads the second with dead transparency.
The pattern repeats inside that character's animation sheets, where cell height is constant while cell width changes per animation, from a narrow idle to a much wider celebrate. Lateral reach varies by action. Standing height does not. The animation pillar covers what it costs when the bottom gap drifts between sheets.
The rule generalizes: lock the dimension your game measures things by, and let the other follow the art. Pick it from your camera and your collision, not from a taste for tidy numbers.
One more size to fix. Concept art for that cast is authored square at 1024 x 1024, around 500 to 600 KB each, then cut down to the game canvas. Authoring size and shipping size differ on purpose: the square source resolves the design before the game's aspect ratio constrains the pose, and the cut to canvas applies the scale contract. The rooms cluster says the same about backgrounds authored at 2048 x 2048 and shipped at 1920 x 1080. Sources stay out of the build.
The first character you build becomes the standard for the rest
Whatever you make first is the reference. Every later character gets matched to it, because matching an existing asset is easier than matching a document. That happens whether you chose it or not, so choose it.
Make it the character with the most screen time and the highest quality bar, usually the player character. In an ensemble, pick whoever the player looks at longest, and break a tie with the most complex, since matching simple to complex beats the reverse. Spend disproportionately on it, concept stage included, and finish it before starting anyone else.
This is the argument swapping placeholder art for real art makes about swap order: replace the highest screen time asset first, because that is where quality returns most. Build order and swap order are the same problem.
How many characters, and when a variant will do
Small games need fewer distinct characters than their design documents claim. The measured cast above is a crew of six, and most solo projects ship four to eight. The count that matters is distinct characters, not appearances.
The line to hold: a character has its own silhouette and its own animation set. A variant is a recolor or a small parts swap on an existing character. A guard and a captain in the same armor in different colors is one character and one variant. A guard and a scuttling drone is two characters. The cost difference is an animation set, near 47 frames, against a palette edit.
So budget in characters and get population from variants. Three characters with two variants each fills a station with nine bodies that read as a crew. Eight one-offs on the same budget gives each less attention.
The cast contract, in one block
Copy this and fill it in before the second character exists. It belongs with your room and interface rules in the art bible template, not in a document nobody opens.
# [GAME] - cast contract
REFERENCE CHARACTER = [ name ] (most screen time)
--- HELD CONSTANT ON EVERY CHARACTER ---
canvas height = [ ] px LOCKED
canvas width = [ ] to [ ] px, floats
art-to-bottom gap = [ ] px, tolerance +/- [ ]
authoring size = [ ] x [ ], square, not shipped
pixels per meter = [ ]
line weight = [ ] px at 100%
rendering level = flat / cel, 1 step / soft
palette core = [ list, including shadow hue ]
light direction = [ e.g. upper left, all characters ]
proportion system = [ ] heads, hand/eye rules
--- VARIED ON PURPOSE, ONE PER CHARACTER ---
name | silhouette cue | accent color | shape lang | posture
-----|----------------|--------------|------------|--------
| | | |
| | | |
--- VARIANTS (recolor / parts swap, no new anim set) ---
base character -> [ variant names ]
--- ACCEPTANCE ---
line-up test / silhouette test / palette audit
Fill the accent column first and defend it hardest. A cast with two teal characters is a cast the player cannot parse.
Adding a character later without it looking added later
Every project adds a character after the cast is done, and it looks newer. The reason is rarely style: it is a list of small contract violations, each invisible alone.
Start from the reference character's file, not a fresh brief. Then check these:
- Canvas height. Exactly the cast number, 560 px in the measured example. Not close. Exact. Width inside the cast's range.
- Ground line. Measure the gap from the bottom of the drawn art to the bottom of the canvas and compare it to the cast's figure. A few pixels of drift is invisible standing still and obvious once the character walks beside another.
- Line weight. Zoom both characters to the same percentage and count outline pixels. The most frequently broken constant on the list.
- Rendering level. Count shadow steps on a simple form, an upper arm or a boot. The newcomer is usually rendered further, because it was made when you knew more. Push it back down.
- Shadow hue. Sample the darkest shadow on the newcomer and on the reference and compare hue, not just value. Drifted shadow hue is the most common reason a character reads as foreign.
- Light direction. Find the lit side of the head and of the chest. Both must agree with the cast.
- Proportion. Measure head height against total height and compare to the system, not to one other character.
- Accent color. Confirm nobody owns it already. If the cast has run out of free accents, the newcomer may need to be a variant instead.
- Silhouette. Fill it black and place it in the middle of the line-up, never at the end, since the end position flatters a newcomer.
Nine checks, most of them measurements rather than judgments. Run them before any animation is produced: fixing a canvas contract after the sheets are baked means rebaking them.
Three ways to judge cast cohesion without drawing
The line-up test. Put every character on one canvas, on the same floor line, at shipping scale, evenly spaced. The highest-return image in character production, and almost nobody makes it. Scale mismatches, ground line drift, rendering differences and light conflicts all surface in a composite that takes ten minutes. Look at it small, then at full zoom, and remake it whenever the cast changes.
The silhouette test. Fill every character solid black, run the same line-up, and name each one. Someone who has not stared at the art for a week should manage it. If two read the same, the fix belongs in the outer shape: headgear, hair mass, carried equipment, hem length. Interior detail will not rescue a silhouette, and the player sees the silhouette first.
The palette audit. Reduce each character to five or six dominant colors and lay the swatches out as rows, one per character. Core colors should repeat across rows, which is what cohesion looks like as data. Accents should appear exactly once each. A grid where every row shares a shadow tone and owns one unique hue holds together in any room, and it feeds straight into making the interface belong with the world.
Two pieces later this week go further on the last two: designing silhouettes rather than checking them, and building a cast palette that survives new characters. Systems that bake a cast as a collection, as Makko does, settle the six constants once for the set.
Frequently asked questions
My cast looks inconsistent but I cannot say why. Where do I start?
Build the line-up image, then check the six constants in order: canvas height and ground line, line weight, rendering level, shadow hue, light direction, proportion. The cause is nearly always in the first four. Costume and personality choices rarely break cohesion on their own, and they are where developers look.
Can I mix characters from different sources?
Only if you re-author the constants, and that is closer to redrawing than editing. Canvas height you fix by resizing. Line weight, rendering level and light direction you cannot fix without repainting, and mixed sources fail on those three in that order of frequency.
How different should two characters be?
Different enough that a player names each correctly from a black silhouette at shipping size, and no more than that. Variation past the silhouette threshold buys nothing and costs cohesion. That threshold is a test, so run it rather than estimating.
Should enemies follow the same cast contract as the player character?
Yes for the six constants, and deliberately not for parts of the varied four. Enemies live in the same light at the same rendering level or they look pasted into the world. Their accents come from a reserved range, so a threat never shares a hue with an ally.
What if my game only has one character?
Write the contract anyway and keep it to one page. A single-character game still has a canvas contract, a rendering level and a light direction. The first time you add a boss, a vendor or a second playable option, the standard is already written instead of reverse-engineered.