Chapter 4: Documentation That Downstream Teams Love

Created by Sarah Choi (prompt writer using ChatGPT)

Documentation That Downstream Teams Love

Why documentation is a design tool

Great documentation is not a clerical afterthought; it is a continuation of design. For vehicle concept artists, the way you explain reuse, trims, variants, and LOD intent determines whether downstream teams can deliver at quality, on time, and within memory budgets. Documentation transforms a single hero image into a system: a modular kit that supports families of vehicles across game modes and performance targets. When your docs are clear, production teams can make good decisions without guessing. When they are ambiguous, every unanswered question becomes a risk to schedule, readability, and fun.

Who you are writing for (and what they need)

Concept and production artists often write to themselves. Instead, write for receivers. Modelers want dimensional truth, hardpoint standards, and UV/material intent. Tech art needs pivot conventions, LOD policy, and mask packing. Animators need ranges of motion, collision and clearance. VFX needs hook locations and naming. Design needs gameplay silhouettes and upgrade maps. QA needs verification criteria. Outsourcing needs a self-explanatory package that stands even without a meeting. If your page answers, “What is this part? Where does it go? How does it connect? What are the invariants?”—your documentation is doing its job.

Single source of truth (SSOT) mindset

A production-friendly package is a single, versioned folder that answers everything to the degree of fidelity appropriate for its milestone. Treat it as an asset with owners, a change log, and a stability promise. Inside, include a readme that explains the structure, the latest date, the responsible person, and the intended production branch. Keep the hero art and the measurable, modular system in the same place so nothing diverges.

Naming, versioning, and stability windows

Use predictable names. Prefer VehicleFamily_Variant_Module_v###. Put the stability window at the top of the readme: what is frozen (overall length, wheelbase, hardpoints), what is soft (surface language), and what is exploratory (livery). Communicate when soft becomes frozen. Downstream teams love knowing exactly when they can bank work without rework risk.

From pretty picture to producible kit

A beautiful render becomes production-ready when it reveals its grammar. Document:

The kit vocabulary. Identify repeatable modules (nose, canopy, mid-hull, tail, wheel pods, intake set, sensor bar, turret ring, cargo rack). For each, show size classes and compatible neighbors. Explain what is visually swappable versus philosophically swappable—the latter preserves faction DNA and metrics.

Hardpoint standards. Describe universal attachment geometry: bolt circle, slot spacing, datum planes, and alignment axes. Define naming and orientation (HP_TOP_AFT_01, X forward/Y right/Z up or your studio standard). Hardpoints are the language of reuse; without standards, every variant becomes bespoke.

Interface tolerances. Specify allowable overhangs, gasket gaps, and shim ranges so modelers know what can be adjusted without design escalation. Tolerances protect the silhouette while giving production room to breathe.

Trim sheets and material IDs. Show the trim sheet groups each module expects, with texel density targets and UV notes. Include a materials legend with consistent IDs across the family (e.g., MTL_01=paint, 02=raw alloy, 03=polycarbonate, 04=rubber). Clarify what must share UVs for batching.

Variants, trims, and the family tree

Variants are not new vehicles; they are combinations of the same kit with new constraints. Document your family tree as prose paragraphs and a compact diagram.

Role variants. Civil, police, military, racing—explain the gameplay purpose and how each role modifies the kit: sensor suite density, armor pack presence, utility racks, lighting language, color blocking. Give a short paragraph per role describing silhouette deltas, cost impact, and readability wins.

Trim levels. Within a role, trims scale budget and complexity. A paragraph for each trim: Base (minimal modules, single-material simplifications), Plus (comfort or tech add-ons), Pro (specialized loadouts), Elite (hero content). State the target draw call budget, shader complexity, and any restricted modules per trim.

Upgrade paths. Players and designers need consistent ladders. Document which modules upgrade linearly (battery pack sizes, brake disk diameters) versus which swap laterally (weapon pod A ↔ B). This keeps balancing changes safe because the physical kit already supports them.

LOD thinking at the concept stage

LOD is not a decimation step; it is a design promise. Write LOD intent paragraphs that describe what survives at distance, what collapses, and what disappears.

Silhouette invariants. Declare the three reads that must hold at every LOD (e.g., delta wing + dorsal intake + tail boom). Give permission to simplify all else. Animators and modelers can then remove clutter guilt-free.

Edge and material simplification. Explain how edges become radii and how trim breaks collapse into baked normals. Provide a sentence on baked lighting or AO expectations per LOD—does LOD1 keep cavity detail? Do screws become decals?

Functional fakes. At low LODs, you may fake suspension compression or intake depth with texture scrolling or vertex animation. Say so. Without this note, tech art may chase unnecessary rigging.

Readability rules that survive reuse

Modularity risks visual noise. Counter it with documentation about hierarchy and rhythm.

Panel cadence. State your preferred panel size rhythm (long/medium/short ratios) and what patterns to avoid (checkerboarding, equal spacing). Explain which seams are structural (keep) and which are cosmetic (merge at LOD).

Break-up kit without breaking the brand. When swapping modules, keep faction markers—the characteristic nose curvature, the headlight eyebrow angle, the vent language. Describe these as sentences, not just images, so outsourcing teams can reason about them.

Color and livery anchoring. Provide two anchoring zones that rarely change (e.g., roof and rocker) and two play zones (doors, hood). This ensures visual variety without family drift.

Dimensional truth and metrics

Provide key dimensions in a measured orthographic sheet with a written explanation.

Scale and units. Declare units and export scale once, in words. “All CAD and DCC exports are meters; scale = 1.0; Z up.” Restate in each package header.

Gameplay metrics. Door width, sill height, ramp angle, ground clearance, turret traverse clearance, prop/rotor diameters, wheelbase, track width, step height. Explain how these map to player navigation and collision volumes.

Animation clearances. Give minimum radii for door arcs, suspension travel ranges, steering lock angles, turret elevation limits. Provide statements like, “The gullwing door clears a 1.8m character at 0.2m lateral offset.”

Connection logic: how parts meet and move

Downstream teams must understand mechanical intent to avoid surface-only modeling.

Kinematic intent. In prose, describe how each moving part works: “Trailing-arm rear suspension; shock axis pitched 15° forward; 150mm travel from neutral; bump stop at +120mm.” Pure text here is powerful for searchability.

Pivot conventions. Define pivot placement rules: hinges at physical hinge center, turrets at ring center, wheels at hub center with forward axis reference. Add a line explaining negative rotations for left-hand parts if mirrored.

Serviceability. State which panels must be removable, which fasteners are dummy, and what the service path looks like. This informs destruction states and gameplay repair beats.

Materials, shaders, and mask packing

Write short, unambiguous paragraphs on material behavior.

IDs and blending. “MTL_01 Paint supports color, roughness, edge wear mask; accepts decals via RGBA-packed mask (R=color, G=roughness trim, B=metalness toggle, A=wear).”

Trim sheet reuse. Describe which modules share a trim and why. “Wheel pod and intake share TS_MECH_A to enable batching across police/military trims.”

Damage and dirt. Explain accumulation logic: where mud sticks, which edges chip first, which zones stay clean. Connect to gameplay if dirt has stealth or cooling implications.

VFX hooks, audio, and interaction points

Good docs make effects predictable.

Named sockets. Provide a dictionary of sockets with purpose statements: SFX_EXHAUST_01 (thruster flame at idle; scales with throttle), SFX_SPARK_02 (skid contact), SFX_DUST_TRAIL_AFT (off-road only). Describe trigger conditions in a sentence.

Lighting policy. Clarify emissive use by variant (civil vs police lightbars), blink patterns, and shader parameters that drive them. State HDR intent so exposure doesn’t blow out UI.

Audio surrogates. If you imply audio with design (whistles, turbine whine), say which materials and geometries cause it. This helps sound design align timbre with the form.

Collision, physics, and destruction

Speak to gameplay volumes as much as visual meshes.

Collision hierarchy. Describe the primitive-first approach (capsules for doors, convex hulls for pods) and where precise per-poly is justified. Outline the number of expected colliders per LOD tier.

Mass distribution. Give a sentence on center-of-mass intent: “Battery pack low and central, COM at 48% wheelbase, 0.55m above ground.” Physics will feel more ‘designed’ when intent is declared.

Destruction beats. State which modules detach, which deform, and which are persistent. Tie this to hardpoint logic so break-offs are physically believable.

Outsourcing and cross-studio handoff

Assume your recipient does not have you on speed dial. Make the package readable without meetings.

Self-explanatory pages. Begin each section with a paragraph explaining why this information matters, not just what it is. A modeler in another time zone should understand choices without cultural context.

Reference density. Include a curated set of 8–12 reference images with a paragraph explaining the design takeaways. Avoid dumping moodboards that lack annotation.

Feedback loop. Define the review cadence: “Greybox check for metrics; alpha check for LOD compliance; beta check for polish only.” State what a ‘pass’ looks like for each.

A doc writing style that travels well

Documentation that survives translation and toolchains shares traits.

Short, concrete paragraphs. Avoid long lists of bullets as your only structure. Prose travels better across PDFs, wikis, and emails and preserves nuance. Use consistent terms to aid search.

Every page has a decision. Each spread should help someone decide: attach A or B; keep seam or merge; upgrade or leave. If a page doesn’t enable a decision, it likely belongs in an appendix.

Caption like a scientist. Captions should state cause and effect: “We increase fin root depth to keep silhouette at LOD2.” Cause/effect captions save the project when a texture or poly budget shifts later.

The reusable page set (what most teams adopt happily)

While every studio differs, these pages tend to earn love from downstream teams:

1) Family Overview. One-page prose summary of the vehicle family vision, roles, trims, silhouettes, and brand markers. Include a date, owner, and stability window.

2) Metrics & Orthos. Measured orthographic with gameplay metrics and collider guide. A paragraph explains scale, units, and any deliberate exaggerations.

3) Kit & Hardpoints. Exploded view with hardpoint dictionary and interface tolerances, plus prose on allowable swaps.

4) Materials & Trim Sheets. Material ID legend, shader expectations, UV density, and mask packing policy. Include a written explanation of batching goals.

5) LOD Policy. Side-by-side callouts of LOD0/1/2 with a paragraph per LOD describing collapses and invariants.

6) Animation & Service. Motion ranges, pivot conventions, maintenance access, and a sentence on rig complexity expectations.

7) VFX & Audio Hooks. Socket map with behavior notes and trigger cues. Short text beats for lighting behavior.

8) Variant Matrix. A compact matrix of role × trim with text notes for silhouette deltas, banned modules, and budget notes.

9) QA Acceptance. Plain-language criteria: “Pass if: door arc clears player capsule by ≥10cm; LOD1 retains dorsal intake read; material IDs match legend; police lightbar emissive ≤ target nit value.”

10) Change Log. Date-stamped changes with impacts: “2025‑09‑28: Nose module shortened 80mm to meet ramp metric; re-bake required; collider update.”

Balancing concept freedom with production clarity

You do not need to lock the painting to unlock production. You need to lock the rules. Declare which parts of the design create the fantasy and which deliver the function. Write paragraphs that encode those choices: “The fantasy lives in the prow silhouette and drone bay doors; the function lives in wheel track and ramp angle. We will protect function first at low LOD.” This gives teams permission to adjust surface details without harming the experience.

Common failure modes (and how your docs prevent them)

Projects suffer when the doc misses these, and each has a fix in prose.

Ambiguous scale. Fix by restating units everywhere and anchoring against human props in orthos.

Over-specified noise. Fix by documenting hierarchy and rhythms so downstreams know what can be merged.

Variant drift. Fix by listing family anchors and banned changes at each trim level.

Hidden constraints. Fix by stating tolerances and service paths so ‘invisible’ decisions are explicit.

Late LOD thinking. Fix by writing LOD survival rules during concept so reductions feel designed.

A short example: Police vs. Racing from a shared kit

Imagine a mid-engine roadster family. The police variant adds a lightbar at HP_ROOF_A, a sensor bar at HP_NOSE_B, and reinforced bumpers at HP_FRONT_C and HP_REAR_C. The racing variant trades the bumpers for a splitter and diffuser at the same hardpoints and swaps brake modules from size M to L. Silhouette anchors remain: wedge nose, canopy bubble, flying buttress intakes. LOD policy states that at LOD2 only the wedge, canopy, and buttresses remain; lightbar collapses to emissive strip; splitter merges into a single plane. Material IDs are identical across both so batching holds. This paragraph alone lets modeling, tech art, and design act without meetings.

Checklists that speed handoff without bloating docs

A concise checklist lives at the end of your readme:

— Readme with owner, version, and stability window — Family overview page present and up to date — Orthos include all gameplay metrics and units — Hardpoint dictionary and interface tolerances — Materials legend + trim sheets + UV/TD targets — LOD policy paragraphs and side-by-side callouts — Animation ranges, pivots, service access notes — VFX/Audio sockets and behavior cues — Variant matrix with banned changes per trim — QA acceptance criteria and change log

Use the checklist to police yourself; keep the prose for teaching.

Writing for people, not only for pipelines

Even the best pipeline fails if the humans feel lost. Use plain language. Prefer verbs like attach, align, compress, clear, collide, detach. Avoid jargon unless your studio standardizes it. Add a one-paragraph ‘Why this matters’ at the start of each page. When deadlines squeeze, that paragraph is what survives screenshots and Slack messages.

Closing: documentation as a promise

When you document optimization, modularity, and families well, you are promising the team that every variant remains shippable, readable, and tunable. Your words carry the kit across time zones, tools, and patches. The result is not just fewer meetings and less rework; it is a vehicle family that stays coherent from whitebox to live service because you designed the rules and wrote them down.

Appendix A — Suggested file structure (described)

Create a single root folder per family with subfolders: 01_Readme, 02_Overview, 03_Metrics_Orthos, 04_Kit_Hardpoints, 05_Materials_Trims, 06_LOD, 07_Animation_Service, 08_VFX_Audio, 09_Variants, 10_QA, 99_Archive. In each, keep a Latest subfolder and archive dated deliveries. The readme contains links to ‘Latest’ so recipients don’t dig.

Appendix B — Sentence templates you can copy

“Hardpoint HP_TURRET_RING_A is a 600mm bolt circle (8x), datum at hull centerline, Z-up; compatible modules: TURRET_A/B, SENSOR_DOME_C.”

“LOD1 collapses tertiary vents to normals; LOD2 removes brake caliper geo; silhouette anchors preserved: prow beak, canopy bubble, dorsal ridge.”

“Police trim adds lightbar emissive with 1.5s pulse; racing trim replaces bumper modules with splitter/diffuser; both keep Material IDs 01–06.”

“Door arc clears 1.8m capsule by 0.1m at 30° incline; hinge pivot at local Y+, 0.02m inset; damping fake at low LOD via vertex animation.”

“QA pass if collider set ≤ 12 primitives at LOD0; door arc passes clearance; variant matrix matches banned-change list; materials IDs consistent with legend.”