Select and integrate assets, not just generate them

2270. Lesson identity

Module

5.10 — AI art pipeline

Lesson

Select and integrate assets, not just generate them

Academic type

Guided Build

Schema type

practical

Order

Lesson 2 in the module

Estimated time

40–50 minutes, including review and integration

This lesson evaluates candidates in the game context. The output is not a large image collection; it is a documented selection decision and either one accepted asset integrated for production judgment or a documented rejection/revision path with a safe provisional or placeholder integration.

2271. Learning objective

After this lesson, you can accept, reject, or revise an AI-generated asset by applying documented criteria for fitness, consistency, provenance, and runtime integration, while distinguishing diagnostic integration from production acceptance.

2272. Why this matters

An asset can look attractive in isolation and still fail when placed in the game. Its scale, silhouette, contrast, file properties, visual language, or role may conflict with the surrounding experience. AI generation produces candidates; development still requires selection and verification. A documented review process also makes revision faster because the reason for a decision remains visible. When no candidate is ready, a safe provisional integration lets you test the game context without falsely treating an uncleared asset as production-ready.

2273. Prior knowledge

You should have completed 5.10 L1 — Brief a coherent AI art pass. You should have a visual brief containing the asset's in-game function, visual direction, consistency constraints, and acceptance criteria. You should also be able to inspect the project context and make a controlled asset change using the established AI-assisted workflow.

2274. Core concept

The production value of an AI-generated asset is determined by fitness in context, not by image quality alone.

Evaluate each candidate across four dimensions:

1. Fitness: Does it serve the intended gameplay or communication function? Is its shape, scale, contrast, and readability appropriate?
2. Consistency: Does it belong to the visual system established by the brief and neighboring assets?
3. Provenance: Can you record where it came from, what process produced it, what modifications were made, and whether its license or usage rights permit the intended use?
4. Runtime integration: Does it meet the technical conditions required by the game, such as dimensions, format, transparency, naming, import behavior, and performance expectations?

A candidate that fails one of these dimensions is not automatically useless. It must be rejected, revised, or accepted with a documented exception. The decision is part of the asset's production record. The provenance record must also identify the applicable license or rights basis, any attribution or usage conditions, and unresolved rights questions; if those cannot be verified, the asset is not cleared for production acceptance. It may still be used as a clearly labeled diagnostic-only candidate or replaced by a safe placeholder for testing.

2275. Mental model

Use REVIEW → INTEGRATE → PLAYTEST → LOG as the review cycle:

Integration has two possible statuses: diagnostic integration tests placement, scale, import, or readability and does not authorize production use; production acceptance means the candidate passed the review and its rights basis has been verified. Do not treat a diagnostic result as an acceptance decision.

2276. Concrete example

Suppose the brief requests a small environmental sign that distinguishes a restricted route from an ordinary route. Three candidates are available:

• Candidate A has polished detail but a narrow silhouette and low contrast at the intended viewing distance.
• Candidate B has a simpler silhouette, matches the established color and edge treatment, and remains readable at the game camera's scale. Its source, editing steps, and rights information are recorded.
• Candidate C is visually consistent but includes a background and dimensions that create unnecessary runtime work.

Candidate B is the strongest initial choice because it satisfies the function, consistency, provenance, rights-review, and integration criteria together. Candidate A should be revised if its role requires distant recognition. Candidate C may be revised by removing the background and normalizing its dimensions. If none of the candidates has verifiable rights information, do not accept one for production. Use a labeled diagnostic copy only if the test is safe, or use a neutral placeholder while documenting the rejection or revision path.

2277. AI-native workflow

Use AI as a comparison and documentation partner, not as the authority that decides what belongs in the game.

1. Provide the brief and the four evaluation dimensions to the AI tool.
2. Ask it to produce a candidate comparison table with evidence and unresolved questions.
3. Perform a desk review and give each candidate a provisional disposition: shortlist for diagnostic integration, reject, or revise. This is the first gate, not production acceptance.
4. Integrate shortlisted candidates diagnostically, inspect them in the game context, and playtest them at the intended scale and viewing conditions. Correct any criteria that the tool inferred incorrectly.
5. Use the resulting evidence to make the second-gate decision: accept for production, reject, or revise. Record the source, generation or edit method, relevant prompt or reference, the applicable license or rights basis, required attribution or usage conditions, unresolved rights questions, test observations, and changes applied.

The human decision must remain explicit. If the AI recommends acceptance but the asset fails at gameplay scale or its rights cannot be verified, reject or revise it and record the observed failure. If you integrate it only to diagnose placement or readability, label that integration as provisional and diagnostic; it is not production acceptance.

2278. Common mistake

A common mistake is accepting an asset because it looks impressive in a large preview. This confuses local image quality with production fitness. Another mistake is recording only the generation prompt while omitting the candidate identifier, edits, source references, license or rights basis, usage conditions, or reason for acceptance. A prompt is not a review record and does not prove that the asset works in the game or may be used as intended. A further mistake is treating a provisional test copy as an approved production asset.

2279. Guided practice

Complete the following review and integration exercise using the asset brief from the previous lesson.

1. Define the decision surface

Create a small review table with one row per candidate and these columns:

• Candidate identifier
• Intended in-game role
• Fitness evidence
• Accessibility evidence when the asset communicates gameplay state or direction: meaning does not depend on color alone, text and symbols remain legible, motion or flashing is safe, and an equivalent cue or fallback exists where appropriate
• Consistency evidence
• Provenance record, including source or generation process
• License or rights basis
• Attribution or other usage conditions
• Unresolved rights questions, if any
• Runtime integration result
• Integration status: diagnostic, production, or not integrated
• Decision: accept, reject, or revise
• One-sentence rationale

Use observable statements. For example, write “the silhouette remains distinct at the intended camera distance,” not “this feels readable.” Do not mark a candidate accepted for production until its license or rights basis and any required conditions have been reviewed and recorded. If rights are unverified, the candidate may only be marked rejected or revise; any test integration must be labeled diagnostic.

2. Compare candidates in context

Inspect at least three candidates, or three materially different versions of one candidate. First review them at a useful preview size, then place the leading candidates in the relevant game context. Check their scale, contrast, silhouette, relationship to nearby elements, and visual hierarchy.

Make at least one non-trivial decision. You must reject or request revision for at least one candidate unless every candidate genuinely satisfies the brief. Do not create a rejection merely to complete the checklist.

3. Choose an integration path

Use one of these two valid paths:

• Accepted-asset path: Select a candidate that passed the initial desk review and has a verified rights basis. Integrate it first as a diagnostic candidate, playtest it in the intended location or presentation context, and verify its fitness, consistency, and runtime behavior. Mark it accepted for production only after that evidence passes the second gate.
• Fallback path: If no candidate can be accepted, document the rejection or revision decision and integrate either a clearly labeled provisional candidate for diagnostic testing or a safe placeholder. The provisional or placeholder integration must not be presented as production-ready, and the rejected or unresolved candidate must remain visible in the review record.

For either path, verify and record the file type, dimensions, transparency behavior where applicable, naming, import result, and visible placement. Inspect only the import settings relevant to the selected asset type, such as color space, compression, filtering, mipmaps, wrapping, or pivot. Compare the asset against the concrete limits in the brief, such as texture dimensions, file size, estimated memory use, or download impact. Keep the change narrow so that the review remains attributable to the selected asset, provisional candidate, or placeholder.

4. Test and document

View the integrated asset, provisional candidate, or placeholder at the intended gameplay scale and during the relevant interaction or traversal context. Record one observation that supports production acceptance or identifies a required revision. Update the review table with:

• What changed during integration
• What the game-context test showed
• What provenance information is available
• The license or rights basis reviewed
• Any attribution, permission, or usage conditions that must be preserved
• Any unresolved rights question and its effect on the decision
• Whether the final status is accepted, rejected, revised, diagnostic-only, or placeholder

If the asset fails, or if its rights cannot be verified, do not conceal the problem by replacing it silently. Either revise it and record the revision, resolve and document the rights basis before accepting it, or keep the rejection visible and use the safe fallback path. A diagnostic integration may provide evidence about runtime behavior, but it cannot by itself establish production acceptance.

2280. Validation / evidence

You have completed the lesson when you can point to all of the following:

• A review table covering fitness, consistency, provenance, and runtime integration
• For any asset that communicates gameplay state or direction, evidence that meaning does not depend on color alone, text and symbols remain legible, motion or flashing is safe, and an equivalent cue or fallback exists where appropriate
• A documented accept, reject, or revise decision for each candidate
• Either one rights-cleared asset integrated for production judgment, or a documented rejection/revision path with a safe provisional or placeholder integration
• An explicit distinction between any diagnostic integration and production acceptance
• Evidence that the integrated asset, provisional candidate, or placeholder was checked at the intended scale and viewing condition
• A record of the applicable import settings and comparison against the asset budget defined in the brief; only checks relevant to the selected asset type are required
• A provenance note identifying the candidate source or generation process and subsequent edits
• A documented licensing or rights review identifying the applicable rights basis, attribution or usage conditions, and any unresolved rights question
• Evidence that no asset was accepted for production while required rights information remained unverified
• A short rationale that another developer could use to reproduce or challenge the decision

The work passes when the decision is justified by observable evidence, the asset status is unambiguous, and either the intended production use is supported by a recorded rights basis or the fallback status is clearly documented. Visual polish alone is not sufficient evidence.

2281. Key takeaways

• Asset selection is a production decision, not a contest for the most attractive generated image.
• Fitness, consistency, provenance, and runtime integration must be evaluated together.
• Provenance includes the source or generation process, edits, licensing or rights basis, and conditions of use.
• A diagnostic integration can test the game context but is not production acceptance.
• When no candidate is ready, a documented rejection or revision path plus a safe provisional or placeholder integration is valid completion evidence.
• AI can organize comparisons and records, but the developer owns the acceptance decision and rights review.

2282. Next lesson

Next: 5.11 — AI voice and audio pipeline, where you will transfer constrained briefing and in-context evaluation to audio feedback and tone by writing an audio brief and cue sheet for a bounded game moment.

2283. Knowledge check