# AI image prompting for game developers

**AIGameDev community guide | October 2026 | Version 1.0**

How to write useful image-generation prompts, choose a model for the job, and turn generated artwork into assets that actually work in a game.

> **Not a sponsored recommendation.** This guide covers proprietary, hosted and downloadable/open-weight models. The 20-model order and scores below are the **ranking snapshot supplied for this guide**, not a fresh, independently reproduced benchmark. An overall text-to-image preference score is *not* a measure of sprite-sheet correctness, edit precision, licensing freedom, game-engine compatibility or value for money.
>
> **Terminology:** *Open-weight* means weights can be downloaded under some licence. It does **not** necessarily mean open-source, unrestricted or commercially usable. Check the exact model, deployment and terms for your intended game release.

## Contents

1. [Start with the asset, not the model](#1-start-with-the-asset-not-the-model)
2. [The reusable prompt framework](#2-the-reusable-prompt-framework)
3. [All 20 models: prompt structures and examples](#3-all-20-models-prompt-structures-and-examples)
4. [Copy-ready game-development prompt templates](#4-copy-ready-game-development-prompt-templates)
5. [From generated image to usable asset](#5-from-generated-image-to-usable-asset)
6. [How to compare models fairly](#6-how-to-compare-models-fairly)
7. [Licensing, IP and community sharing](#7-licensing-ip-and-community-sharing)
8. [Sources and further reading](#8-sources-and-further-reading)

---

## 1. Start with the asset, not the model

Before prompting, decide what you are actually producing.

| Needed output | What to specify up front | Common failure |
|---|---|---|
| **Concept art / mood board** | Setting, art direction, composition, mood, materials | Looks great, but is hard to reproduce |
| **Game background** | View, safe areas for UI, aspect ratio, layering needs | Interesting details occupy HUD space |
| **Character design** | Silhouette, costume, recognisable features, reference hierarchy | Character changes between images |
| **Sprite / prop** | Orthographic or isometric view, outline, target size, transparency | Perspective drift or painted background |
| **Sprite sheet / turnaround** | Exact views, poses, equal scale, registration | Frame-to-frame shape and alignment changes |
| **Tile / terrain** | Grid dimensions, edge rules, neighbours, camera angle | Visible seams or incompatible geometry |
| **UI icon** | Pixel size, visual weight, background/alpha, contrast | Too much detail at gameplay size |
| **Texture / material reference** | Tiling, PBR intent, scale, lighting neutrality | Baked shadows; not truly seamless |
| **Store capsule / key art** | Platform crop, focal point, text-safe area, exact text or no text | Cropping removes important content |
| **Infographic / game UI mock-up** | Exact copy, hierarchy, dimensions, layout | Fabricated labels or broken interface logic |

**The essential rule:** Asking for a *picture of* an asset is not the same as asking for a technically valid asset. Models can approximate a sprite sheet, a tileable material or a vector drawing without satisfying the production requirements.

### A small vocabulary that helps

- **Top-down / orthographic:** Camera directly overhead, no visible side faces. Useful for 2D maps and some tile games.
- **Isometric:** A projected view showing the top and sides; not interchangeable with top-down.
- **Three-quarter:** A subject seen diagonally, with visible front and side.
- **Silhouette readability:** The object or character is identifiable when reduced to its final on-screen size.
- **Alpha / RGBA:** Genuine transparency stored in the image, not a painted checkerboard.
- **Seamless / tileable:** Opposite texture edges join without a visible boundary. Must be tested in a repeated grid.
- **Reference lock:** Specific features, proportions or palette that should remain consistent across generations.
- **Registration:** Character or prop remains aligned relative to the same anchor across animation frames.

---

## 2. The reusable prompt framework

There is no universal secret keyword language. For most generators, a clear brief outperforms piles of vague quality tags.

### The eight-part prompt

```text
PURPOSE: What the asset is for (e.g. 2D strategy-game building icon).
SUBJECT: Exact subject and distinguishing features.
CAMERA: Top-down, isometric, orthographic front, side, etc.
COMPOSITION: Object placement, scale, safe areas and cropping.
ART DIRECTION: Medium, palette, materials, outlines and detail density.
REFERENCES: Image 1 = character; Image 2 = style; Image 3 = pose.
CONSTRAINTS: What must remain unchanged; what must not appear.
DELIVERY: Aspect ratio, target pixels, output format, alpha, number of variants.
```

**Practical example:**

```text
PURPOSE: Static prop for a 2D survival game.
SUBJECT: One dented red steel toolbox with two drawers and a black handle.
CAMERA: Fixed front three-quarter view; no perspective exaggeration.
COMPOSITION: Entire object visible with 8% padding on every side.
ART DIRECTION: Painted 2D game illustration; muted reds, deliberate edge highlights,
readable at 96 × 96 pixels; no photographic grain.
REFERENCES: Image 1 defines proportions and damage; do not copy its background.
CONSTRAINTS: One object only; no tools sticking out; no lettering; no cast shadow plate.
DELIVERY: Square image. Transparent RGBA output if supported.
```

**Separate text from settings:** Aspect ratio, resolution, model version, reference weights, masks, seed and background format are often **interface/API controls**, not magic words. Set them in the tool when available, then describe the desired appearance in the prompt.

### Two different ways to test a model

1. **Fair comparison:** Give every model the *same* brief, reference inputs, aspect ratio and comparable quality settings. This tests model behaviour.
2. **Optimised workflow:** Adapt structure to the model's editing, reference or layout capabilities. This tests what you can accomplish in real production.

Do not compare outputs from radically different prompts and declare the model with the prettier image the objective winner.

---

## 3. All 20 models: prompt structures and examples

The order and scores below reproduce the supplied **overall preference snapshot**, only as a locator for the model entries.

| # | Model | Supplied score | Prompting emphasis |
|---:|---|---:|---|
| 1 | GPT Image 2.5 Sunburst | 1425 | Detailed production specification |
| 2 | GPT Image 2.5 Flare | 1398 | Focused brief and rapid revisions |
| 3 | GPT Image 2 Medium | 1383 | Structured scene with clear priorities |
| 4 | Grok Imagine Image 2 Canvas | 1334 | Edit selection + preserve instructions |
| 5 | Microsoft MAI-Image-2.6 | 1332 | Named reference roles and precise revisions |
| 6 | Google Nano Banana 2.1 | 1328 | Named references and conversational edits |
| 7 | Reve 2.1 | 1302 | Layout and element relationships |
| 8 | Grok Imagine Image 2 | 1294 | Direct visual description |
| 9 | Meta Muse Image | 1274 | Conversation-based generation and editing |
| 10 | Reve 2.0 | 1269 | Layout-first composition |
| 11 | Google Nano Banana 2 + web search | 1262 | Grounded facts + visual brief |
| 12 | ByteDance Seedream 5.0 Pro | 1255 | Structured design and annotated regions |
| 13 | Alibaba Qwen-Image-3.0-Pro | 1255 | Hierarchy, exact labels, optional negatives |
| 14 | Microsoft MAI-Image-2.5 | 1254 | Simple scene/lighting/control brief |
| 15 | Google Nano Banana 2 Lite | 1250 | One contained task per generation |
| 16 | Google Nano Banana Pro | 1248 | Complex multi-reference compositions |
| 17 | GPT Image 1.5 High Fidelity | 1237 | Detailed edit + preservation rules |
| 18 | Google Nano Banana Pro Preview | 1234 | Same brief as Pro for version testing |
| 19 | Alibaba Qwen-Image-2.1 | 1223 | Explicit RGBA, references, masks |
| 20 | Ideogram 4 Quality | 1205 | Structured JSON layouts in direct-weight workflows |

**These are suggested prompt patterns, not proven unique strengths.** Many sibling models respond to essentially the same prompt. Entries with labels such as *Canvas*, *Preview*, *High Fidelity* or *web search* may refer to a product mode or configuration rather than a separate prompt language. Check the actual endpoint before implementing automation.

The 20 examples below use game-development tasks rather than advertising photography. Copy them directly or replace the game specifics with your own.

### 1 — GPT Image 2.5 Sunburst

**Best prompt form to try:** A detailed, labelled specification with explicit non-negotiables. For complex environments, give the model a checklist of visible features. This is also a useful pattern for other strong general-purpose models.

```text
TASK: Create environmental concept art for a grounded driving game.
SCENE: A small independent vehicle garage on a wet northern English street.
SUBJECT: One faded red 1990s hatchback with believable dimensions.
CAMERA: Eye-level front three-quarter view, landscape 16:9.
COMPOSITION: Car lower right; garage entrance clearly visible to the left.
ART DIRECTION: Stylised early-2000s console-era environment with restrained
modern material detail; overcast natural light; red brick and weathered concrete.
NON-NEGOTIABLE: Recognisable car silhouette, consistent perspective,
workmanlike building details; no futuristic parts, fake labels or logos.
```

*Why this pattern:* OpenAI documents labelled sections, reference roles and preserve-vs-change instructions for GPT Image 2.5. Configure output quality and transparency in the application/API where supported.

### 2 — GPT Image 2.5 Flare

**Best prompt form to try:** Keep the same requirements but focus on the essentials when exploring several compositions quickly.

```text
Create three separate concept variations, one per generation, for a small
workshop environment in a grounded driving game. The main features are a
faded red hatchback, red-brick garage, damp tarmac and overcast northern
English daylight. Wide three-quarter view, 16:9, restrained stylised 3D.
Keep the vehicle proportions believable. No text or logos.
```

*Why:* Flare is the speed-oriented GPT Image 2.5 version. Concision is a workflow convenience, not a different command syntax. Generate variants as separate outputs when the interface cannot guarantee a specific count.

### 3 — GPT Image 2 Medium

**Best prompt form to try:** One scene, clear hierarchy, and a few production constraints.

```text
Generate concept art for a 2D adventure game's abandoned rail platform.
Hero element: small rusted station clock on the left.
Background: overgrown track, distant low hills and fog.
Camera: level side-on environment composition, no extreme lens distortion.
Art: illustrated realism, desaturated green and brown palette.
Keep the central 40% relatively quiet for the player character and HUD.
16:9, no writing or logos.
```

*Note:* “Medium” describes a generation quality configuration, not a special prompting grammar.

### 4 — Grok Imagine Image 2 Canvas

**Best prompt form to try:** Work in an editor with an explicitly selected area and an instruction that describes only the local change.

```text
INPUT: Existing hand-painted village background.
SELECTED AREA: Empty space beside the leftmost building.
CHANGE: Add a small wooden market stall with a green canvas roof.
MATCH: Existing paint texture, scale, perspective and shadow direction.
PRESERVE: Every other building, the path layout, sky, colours and camera.
Do not change pixels outside the intended region.
```

*Note:* Actually select or mask the area using the editor. Writing “selected area” alone does not perform region selection. The Canvas leaderboard name does not establish a separate public API syntax.

### 5 — Microsoft MAI-Image-2.6

**Best prompt form to try:** Assign roles to reference images for precise composition and revision.

```text
REF 1 — CHARACTER: Keep the armour silhouette and facial design.
REF 2 — LOCATION: Use the ruined stone courtyard and its fixed perspective.
REF 3 — STYLE: Apply its painterly materials and muted colour palette only.

Create a wide key-art composition showing the character entering the courtyard.
The character must remain recognisable; do not import objects from Ref 3.
Natural overcast light, coherent scale, believable contact shadow, no text.
```

*Why:* Microsoft documents multi-image reference editing, precise edits, web grounding and aspect-ratio controls for 2.6. Set these capabilities in the actual interface/API; do not assume they activate because the prompt mentions them.

### 6 — Google Nano Banana 2.1

**Best prompt form to try:** Name references, lock identities, and change one thing per follow-up.

```text
Image A is HERO: use the same coat, hairstyle, proportions and facial features.
Image B is VILLAGE: use its buildings and landscape, not its characters.
Create a medium-wide story scene where HERO talks to a merchant outside the
village inn. Midday, soft daylight, hand-painted fantasy-adventure style.
Both characters fully visible. 16:9. No text.
```

**Follow-up:** `Keep HERO, the buildings, camera and composition the same. Change only the weather to light snow.`

*Why:* Google recommends named reference subjects and iterative prompting. Use supported multi-reference input facilities instead of embedding image URLs in ordinary text when a dedicated attachment interface exists.

### 7 — Reve 2.1

**Best prompt form to try:** Give a precise spatial layout, with relationships between individual elements.

```text
Create a 16:9 village hub scene for a 2D adventure game.
BACKGROUND: Wooded hills beneath an overcast sky.
UPPER LEFT: Tavern with a broad roof and one exterior sign mount (blank).
UPPER RIGHT: Small stone bridge across a stream.
CENTRE: Clear walkable plaza, unobstructed.
FOREGROUND: Cobbled path entering from the bottom edge.
Keep building scale coherent; no character sprites and no invented lettering.
Muted, hand-painted 2D game background.
```

*Why:* Reve describes hierarchical, editable layouts as part of its workflow. Actual layout-object controls depend on the Reve editor/API; this plain-text structure is a good starting brief, not a fabricated layout API schema.

### 8 — Grok Imagine Image 2

**Best prompt form to try:** One natural-language art brief with concrete camera, environment and subject details.

```text
A painterly loading-screen illustration for a survival game: a lone traveller
approaches a shuttered roadside service station at dusk, surrounded by empty
fields and telephone poles. Wide eye-level framing, grounded everyday details,
subtle cold daylight, restrained colours, strong atmosphere without heavy bloom.
Keep space clear in the top-left for UI added later. No text.
```

*Why:* xAI officially documents plain-language generation and editing with reference images. No special weighting syntax is required.

### 9 — Meta Muse Image

**Best prompt form to try:** Treat generation and refinement as one conversation, using the previous output as the next input.

```text
Using the attached rough character sketch, design a game-ready character
concept with the same silhouette: short raincoat, oversized backpack, round
spectacles and sturdy boots. Front three-quarter view, full body, neutral pose,
plain backdrop. Clean stylised illustration, no text.
```

**Follow-up:** `Keep the same identity and proportions. Change only the coat from blue to olive green; keep the backpack and glasses identical.`

*Why:* Muse Image supports conversation-state generation, editing and multiple image references; it is not simply a one-shot prompt box.

### 10 — Reve 2.0

**Best prompt form to try:** Simple layout-first instructions before visual polish.

```text
Make a landscape game menu background.
LEFT THIRD: Ancient watchtower on a rocky hillside.
MIDDLE THIRD: Open landscape with a distant road.
RIGHT THIRD: Sparse forest and mountain silhouettes.
BOTTOM QUARTER: Quiet foreground for menu controls.
Hand-painted, low-contrast fantasy landscape, natural colours.
No text, buttons, character portraits or UI elements.
```

*Why:* Its layout-and-object approach is similar to 2.1; the version difference does not warrant invented prompt keywords.

### 11 — Google Nano Banana 2 with web search

**Best prompt form to try:** Make the real-world research and visual brief distinct.

```text
GROUNDING TASK: With search grounding enabled, identify the main architectural
features of a real historical railway station in 1900s northern England.
VISUAL TASK: Create a historically informed illustrated station environment
for a narrative game. Side-on wide view with space for characters.
ACCURACY: Do not invent factual plaques, company names or dates.
STYLE: Restrained hand-painted 2D background, 16:9, no rendered text.
```

*Important:* Enable search grounding in the supported product/API. Model output is still not a verified historical record: check source material before shipping.

### 12 — ByteDance Seedream 5.0 Pro

**Best prompt form to try:** Describe design regions, exact information and any physical annotations in a supplied sketch.

```text
Create a clean equipment-selection screen concept for a survival game.
TOP: Blank region reserved for title and navigation, not rendered text.
LEFT: Large illustration of a worn climbing axe.
RIGHT: Three separate inventory-stat areas with clear spacing, no numbers.
BOTTOM: A wide blank panel for a future description.
Palette: muted charcoal, off-white and desaturated orange.
Use strong grouping, legible silhouette and practical game-UI proportions.
No fake button labels or decorative copy.
```

*For edits:* Draw boxes/arrows on the actual source image, then describe what each annotation means. ByteDance documents interactive annotated editing, structured layouts and layer workflows; validate whether layers are actually delivered by your chosen interface.

### 13 — Alibaba Qwen-Image-3.0-Pro

**Best prompt form to try:** Exact copy and hierarchical text layout when readable in-image text is needed.

```text
Create a fictional in-world warning notice for a survival-horror game.
EXACT HEADING: "RESTRICTED ACCESS"
EXACT SUBHEADING: "MAINTENANCE LEVEL B"
EXACT FOOTER: "AUTHORIZED STAFF ONLY"
Layout: large heading at top, bold central warning icon, smaller subheading
below, footer at the bottom. Ageing industrial print on stained cream paper.
No additional words, dates, symbols or logos.
```

*Technical note:* Qwen-Image-3.0 API documentation supports a separate `negative_prompt` parameter. If available, put unwanted content there instead of treating it as special inline syntax. Check small text by eye, and prefer native game UI text for information that must be exact or translated.

### 14 — Microsoft MAI-Image-2.5

**Best prompt form to try:** Subject + camera + material + lighting, without relying on unverified 2.6-specific features.

```text
Create an illustrated adventure-game prop: a worn brass telescope with
leather-wrapped grip and folding wooden tripod. Entire prop in frame, front
three-quarter angle, neutral light, clearly readable materials and silhouette.
Plain uncluttered background, no labels, no extra objects.
```

*Why:* MAI 2.5 supports ordinary text-to-image generation and editing. Confirm whether a particular 2.5 deployment has the reference or grounding features you need.

### 15 — Google Nano Banana 2 Lite

**Best prompt form to try:** One isolated asset request, with fewer moving parts.

```text
One hand-painted potion bottle icon for a fantasy RPG inventory.
Square composition; violet glass with cork stopper, subtle highlights,
strong outline and readable silhouette at 64 × 64 pixels.
No label, no decorative frame, no additional objects.
```

*Why:* A compact brief is effective for repeatable icon ideation. Batch size and image quality still depend on the model and service settings, not on prompt length alone.

### 16 — Google Nano Banana Pro

**Best prompt form to try:** Complex reference relationships or multiple consistent story scenes.

```text
Create three separate concept scenes featuring the same character from
Reference A: a short-haired courier wearing a tan jacket and carrying a
square messenger bag. Ref B defines the game's hand-painted art style.
Scene 1: courier outside a town post office.
Scene 2: courier cycling along a riverside road.
Scene 3: courier sheltering from rain at a bus stop.
Keep the character's face, outfit, proportions and bag consistent.
Landscape framing, no text.
```

*Why:* The Pro workflow supports detailed, reference-rich prompts. Request separate outputs where you need consistent production frames, rather than expecting a three-panel montage to give exportable game assets automatically.

### 17 — GPT Image 1.5 High Fidelity

**Best prompt form to try:** An edit-only instruction with a hard preserve list.

```text
EDIT IMAGE: Change the character's red cloak to dark green.
PRESERVE: Face, hair, body proportions, pose, equipment, outlines, background,
framing, lighting and every other colour.
DO NOT: Add accessories, reframe the image or redesign the character.
```

*Technical note:* GPT Image 1.5 accepts `input_fidelity="high"` in relevant API editing workflows. That is an API parameter, not something the text prompt enables. **OpenAI schedules `gpt-image-1.5` for shutdown on 1 December 2026**; avoid building a new permanent pipeline around it.

### 18 — Google Nano Banana Pro Preview

**Best prompt form to try:** Identical prompts and references to stable Pro for controlled comparison.

```text
Use the attached character-sheet reference to illustrate the same character
standing at a wooden village gate, facing forward, full body visible.
Preserve head shape, clothing details, proportions and palette.
Soft daylight, hand-painted adventure-game aesthetic, no text.
```

*Why:* There is no credible universal preview-only prompt language. Use the same inputs as Pro, record the actual preview model version and assess output differences. Old preview entries may disappear from providers.

### 19 — Alibaba Qwen-Image-2.1

**Best prompt form to try:** Explicit transparent-image wording, per the published model card.

```text
This is an RGBA image with transparency. A worn iron lantern for a 2D
fantasy game: square steel frame, one glass door, unlit candle and leather
carrying loop. Entire object visible, three-quarter view, clean readable
illustration with consistent outlines. No floor, wall, lettering or other
objects. The image has alpha channel and the background is transparent.
```

*Why:* The Qwen-Image-2.1 repository specifically documents this RGBA phrasing, reference images and local masks. **Its Qwen Research weight licence is non-commercial unless separately licensed.** Do not assume that downloadable weights are safe to use for an unrestricted commercial generation service. Separate weight-use permissions from the rights governing outputs.

### 20 — Ideogram 4 Quality

**Best prompt form to try:** Structured JSON caption for direct inference with the released Ideogram 4 model weights. The hosted application can handle ordinary text prompts through its own prompting system.

```json
{
  "high_level_description": "A clean item-selection concept illustration for a fantasy RPG.",
  "style_description": {
    "aesthetics": "restrained, readable, game-UI friendly",
    "medium": "digital illustration",
    "color_palette": ["#22262C", "#D5C7A4", "#806A50"]
  },
  "compositional_deconstruction": {
    "background": "Plain, neutral off-white background.",
    "elements": [
      {
        "type": "obj",
        "bbox": [150, 200, 850, 800],
        "desc": "One iron lantern, isolated, centred, full object visible, consistent silhouette."
      }
    ]
  }
}
```

*Why:* Ideogram's direct model documentation specifies JSON captions, including `compositional_deconstruction`; box coordinates use a normalised 0–1000 scheme and the documented `[y_min, x_min, y_max, x_max]` order. The example is an illustrative caption; validate it against the installed caption verifier before direct inference. **The released Ideogram 4 weights carry a non-commercial licence.** That does not automatically describe the terms of Ideogram's hosted commercial product.

---

## 4. Copy-ready game-development prompt templates

These templates are intentionally **provider-neutral**. First test the same template across models; only then optimise per provider.

### A. Character design sheet (concept, not animation-ready)

```text
Design an original playable character for a [genre] game.
Character: [age/role/silhouette].
Fixed identity: [hair, face shape, outfit, colours, defining accessories].
Show separate front, side and back views at the same apparent scale.
Neutral standing pose, arms slightly away from torso, entire body visible.
Consistent anatomy, costume placement and palette across views.
Flat neutral background, even lighting, no captions or extra characters.
Style: [specified art bible/style references].
```

**Check:** Do the same seams, pockets, hairline, weapon and character proportions persist between views? A multi-view sheet is a *design reference*, not a rigged/animatable 3D model.

### B. Transparent prop for a 2D game

```text
One [object] intended as a standalone 2D game prop.
Exact view: [front / side / three-quarter / direct overhead].
Full object visible with consistent padding around every edge.
Material details: [three or four defining features].
Art direction: [palette, outline, rendering].
Strong silhouette at [target in-game dimensions] pixels.
True transparent RGBA output where supported; no painted checkerboard.
No text, watermark, environment, floor or shadow plate.
```

**Check:** Open the exported image in an editor and inspect its alpha channel. A picture of transparency is not transparency.

### C. Orthographic top-down tile / building

```text
Asset for a top-down 2D building game.
Camera is exactly 90 degrees overhead, orthographic, not isometric.
No visible building facades, no tilted camera, no vanishing points.
Subject: [building/terrain/road].
Footprint: [tile width × tile height]; alignment: [centre or edge anchors].
Use a consistent palette and simplify small decorative detail.
Road/path edges must connect according to the supplied geometry reference.
No labels, UI glow or unsupported decorative objects.
Output is an art-direction reference; final connection geometry is defined by code.
```

**Check:** Image models often fake exact tile geometry. Do not treat generated road joins or walkable boundaries as mathematically authoritative. Build those from your game's geometry rules or a vector master.

### D. Pixel-art sprite concept

```text
Create a single [enemy/object/character] for a pixel-art [genre] game.
View: [side-facing / front / direct top-down].
Visual target: [e.g. 32 × 32] native pixel art with a deliberately limited palette.
Clustered pixel shapes, controlled edge stepping, readable silhouette.
No antialiasing, gradients, faux pixel mosaic, lettering or background scene.
One pose only, entire sprite visible, centered.
```

**Check:** Models may generate *pixel-art-looking* raster images at larger resolutions. Rebuild, reduce or clean the result on the actual game pixel grid; inspect the exported sprite at 100% scale and nearest-neighbour enlargement.

### E. Environmental background with gameplay space

```text
Create a [16:9 / 21:9 / vertical] illustrated background for a [genre] game.
Scene: [place and visual story].
Camera: [fixed side-on / top-down / three-quarter].
Left region: [landmarks]. Centre: [clear gameplay area]. Right: [landmarks].
Foreground, midground and background should be separable in a future paint-over.
Art style: [references, palette, lighting and material treatment].
Keep the HUD safe area [describe region] uncluttered.
No lettering, fake game UI, unsupported objects or logos.
```

**Check:** Composition may imply layers, but the output will generally still be a flat image. Create actual parallax layers manually or through a supported layered-edit workflow.

### F. Game UI item icon set

```text
Create the first icon in a coordinated set of fantasy survival-game items.
Item: [object]. Icon shape language: [outline weight, material shading, palette].
Visual angle: fixed three-quarter view from upper left.
Square frame, centered subject, 12% safe padding.
Readable at 48 × 48 pixels, no labels or border.
Use the supplied approved icon as a style-only reference.
```

**Check:** Generate and review each icon individually. A model-generated multi-icon sheet may have inconsistent dimensions, cut-offs and styles.

### G. Seamless material / terrain reference

```text
Create a straight-down neutral-light material reference of [surface].
Surface area should be uniform and natural with no focal object.
No directional lighting, cast shadows, perspective or text.
Even texel detail and plausible material scale.
Intended for later conversion into a seamless tileable game texture.
```

**Check:** Repeat the image in a 3 × 3 grid and look for seams. A text instruction saying *seamless* is not a technical guarantee. Normal, roughness and metallic maps require separate correct generation or authoring and validation; a colour image is not automatically a PBR material.

### H. Store-page capsule / key art

```text
Create promotional key art for a [genre] indie game.
Core visual hook: [one striking subject or action].
Primary focal point: [location in image].
Art direction matches [game's actual visual identity].
Composition must remain legible when reduced to thumbnail size.
Reserve [defined region] as clear space for title and platform labels
which will be added manually afterwards.
Output ratio: [specific platform requirement].
No text, logos or fictitious gameplay UI.
```

**Check:** Export several crops at actual storefront dimensions. Marketing key art should not promise visual features or mechanics the game does not deliver.

---

## 5. From generated image to usable asset

A practical workflow for game teams:

1. **Define the art bible.** Include camera system, palette, material handling, outline thickness, proportions, resolution and a small set of approved references.
2. **Generate concepts.** Try two or three distinct model families before committing to a visual direction. Save the precise model/version and settings.
3. **Lock a reference.** Pick an approved design. Do not let later generations casually redesign it.
4. **Generate narrow outputs.** Ask for one prop, one pose or one scene change at a time. Complex sheets are good for ideation but unreliable as final asset packs.
5. **Clean and construct.** Repaint anatomy and details; rebuild geometry, sprites and vectors in an appropriate editor. Separate layers if needed.
6. **Validate technically.** Check pixel dimensions, transparency, seams, registration, colours and output file formats.
7. **Import into the engine.** Test in real gameplay conditions: native viewport scale, lighting, camera zoom, UI density and device size.
8. **Review rights and ship.** Record the provider/model, reference sources and relevant licences. Keep original assets and edited finals linked for traceability.

### Minimum acceptance checklist

- [ ] Recognisable at actual in-game size, not just zoomed in
- [ ] Correct camera and perspective
- [ ] Consistent with the project's established art direction
- [ ] No unintended text, logos or extra objects
- [ ] Correct canvas dimensions and no accidental cropping
- [ ] Transparent assets genuinely have an alpha channel
- [ ] Tile borders, sprite anchors and animation frames are technically valid
- [ ] Consistent outline thickness, light direction and palette
- [ ] Text, if present, is correct and accessible
- [ ] Licensing permits this use and all third-party references are authorised

### Useful production file naming

```text
assets/
  concepts/
    town_hub_v03__model-version__prompt-id.png
  source/
    town_hub_layers.ora
    inventory_lantern_master.svg
  exported/
    environment_town_hub_bg.webp
    icon_lantern_064.png
  prompts/
    town_hub_v03.md
  metadata/
    asset_manifest.json
```

Record at least the brief, model and version, date, seed (if provided), reference names, licence notes, source output and final exported asset. That prevents teams from losing the recipe once an asset looks good.

---

## 6. How to compare models fairly

Run this small benchmark using the **same prompts** and **same approved reference inputs** on each available model:

1. A **character consistency** test: same character across two different locations.
2. A **top-down tile** test: direct overhead, simple building with fixed footprint.
3. An **isolated prop** test: one object, transparent background where supported.
4. A **precise edit** test: change one colour without moving or redesigning the subject.
5. A **UI / typography** test: reproduce three exact labels without invented copy.

Use a 0–5 rubric for each criterion:

| Metric | What the score measures |
|---|---|
| Prompt adherence | Did it fulfil explicit instructions? |
| Identity consistency | Does the character/prop stay the same? |
| Technical usefulness | Can the file be adapted for the engine without major rebuilding? |
| Editing precision | Did it avoid modifying unrelated content? |
| Small-size readability | Does it work at its intended gameplay size? |
| Art-direction fit | Does it match the project's chosen visual system? |
| Rights/deployment fit | Is the intended use permitted and operationally practical? |
| Cost per accepted output | Total spend / count of usable outputs, **not** cost per click |

For fairness, note when a model **cannot** perform the test in the available product: `N/A (unsupported)` is more informative than forcing a low quality score. Record number of retries and total elapsed time; do not cherry-pick only the best image.

**Community-sharing format:** Model/version | Prompt | References (if permitted) | Settings | Raw output | Edited output | Time | Cost | What failed | What worked. Encourage members to show their workflow, not just a single attractive render.

---

## 7. Licensing, IP and community sharing

AI image generators have materially different licences and product terms. Keep these distinctions separate:

- **Model-weight licence:** Can you download, run, modify or commercially deploy the weights?
- **Hosted-service terms:** Can you use outputs commercially? Are there plan, attribution, content, training or redistribution restrictions?
- **Reference ownership:** Do you have permission to upload and modify the source art, character, logo or photograph?
- **Output IP risk:** A generated image can still resemble a protected character, brand, artwork or real person. A service's commercial-output permission is not a blanket non-infringement warranty.
- **Store/platform rules:** Check the disclosure and submission requirements of the store or publisher where you plan to distribute.

**Specific high-priority licence checks as of October 2026:**

- **Ideogram 4 released weights:** non-commercial model licence. The hosted product is a different access route with its own terms.
- **Qwen-Image-2.1 released weights:** Qwen Research License restricts commercial use of the materials without a separate licence. The agreement addresses output ownership separately; read both parts carefully.
- **Other hosted or downloadable models:** Never infer commercial permission from a leaderboard placement or from the word "open". Verify the precise version and service terms before shipping.

For sharing on AIGameDev, a clear, useful post typically includes the tool/model used for the **art asset**, a short process explanation and honest notes about manual editing. Credit reference artists when appropriate. Do not present a generated image as finished gameplay or a technically validated sprite sheet when it is only a concept.

---

## 8. Sources and further reading

Manufacturer/model documentation was used to select the prompting patterns. These are **capability references**, not proof of comparative superiority:

- [OpenAI — GPT Image prompting guide](https://developers.openai.com/api/docs/guides/image-prompting)
- [Google DeepMind — Nano Banana image prompting](https://deepmind.google/models/gemini-image/prompt-guide/)
- [Google — Gemini image generation API](https://ai.google.dev/gemini-api/docs/image-generation)
- [xAI — Grok Imagine capabilities](https://docs.x.ai/developers/model-capabilities/imagine)
- [Microsoft AI — MAI-Image-2.6](https://microsoft.ai/models/mai-image-2-6/)
- [Microsoft Learn — MAI Image models in Foundry](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/use-foundry-models-mai)
- [Reve — API and layout model](https://blog.reve.com/posts/the-reve-api/)
- [Meta — Muse Image API documentation](https://dev.meta.ai/docs/image-generation)
- [ByteDance — Seedream 5.0 Pro](https://seed.bytedance.com/en/seedream5_0_pro)
- [Alibaba Cloud — Qwen Image generation API](https://www.alibabacloud.com/help/en/model-studio/qwen-image-api)
- [Qwen-Image-2.1 — model card](https://github.com/QwenLM/Qwen-Image-2.1)
- [Qwen-Image-2.1 — licence](https://github.com/QwenLM/Qwen-Image-2.1/blob/main/LICENSE)
- [Ideogram 4 — released weights and licence](https://github.com/ideogram-oss/ideogram4)
- [Ideogram 4 — direct-inference prompting specification](https://github.com/ideogram-oss/ideogram4/blob/main/docs/prompting.md)
- [Arena — text-to-image preference leaderboard](https://arena.ai/leaderboard/image/text-to-image)
- [Artificial Analysis — image leaderboard](https://artificialanalysis.ai/image/leaderboard/text-to-image)

**Editorial note:** This guide deliberately avoids claiming that any single provider is “best for game development”. Model capabilities, hosted product modes, prompt reliability, API access and licences change quickly. Independent, repeatable tests with the assets you actually need are more useful than universal rankings.

*Prepared for the AIGameDev community. Share and adapt this guide with attribution to the community; check any linked external terms before commercial use.*