DEV Community: GameArtForge

AI Character Design: Prompt Engineering That Actually Works

GameArtForge — Fri, 21 Aug 2026 07:42:53 +0000

AI Character Design: Prompt Engineering That Actually Works

You generated a gorgeous elven warrior on your first try. Then you tried to get her in a different pose — and got a completely different person. Sound familiar?

Consistency is the core challenge in AI game art. The same character must stay recognizable across poses, expressions, outfits and scenes — or your animation flickers, your UI looks off, and your art director starts twitching.

This is the 9-step framework we use to get consistent, production-ready game characters out of Midjourney, Stable Diffusion and ComfyUI — not lucky one-offs.

Step 1: Prompt Engineering Fundamentals

AI generation is probabilistic. Your prompt is the "remote control" for that probability distribution — the more precise your description, the closer you get to what you want.

Why game characters need consistency

Reason	What happens without it
Brand identity	Players can't recognize the protagonist between scenes
Animation coherence	Sprite frames "flicker" when the character shifts shape
Asset reuse	UI icons, portraits and cutscenes all disagree
Team collaboration	Multiple artists produce five different versions of the same hero

Tool overview: pick the right tool per phase

Tool	Type	Best for
Midjourney	Paid · Cloud	Highest art quality, `--cref` character ref, `--sref` style ref — concept phase
Stable Diffusion	Open source · Local	LoRA/ControlNet, scriptable batch generation — production phase
DALL-E 3	Paid · API	Prompt understanding, accurate text rendering — rapid prototyping
ComfyUI	Open source · Node	Visual workflows, automated pipelines — engineered mass production

Tip: Explore styles fast in Midjourney during concept. Then move to Stable Diffusion + ComfyUI for batch production. DALL-E 3 is great for UI elements that need precise text.

Step 2: Prompt Architecture

Great prompts aren't random keyword dumps — they have a clear hierarchical structure. Four layers, from core to detail:

Layer	What it defines	Example
1. Subject	Who — identity, race, gender, body type	"a young elven female warrior, athletic build, silver hair"
2. Style	How it looks — art style, rendering, palette	"anime cel-shading, bold outlines, vibrant colors"
3. Detail	What they wear — equipment, clothing, hair, props	"ornate silver plate armor with blue gem inlays, crystal longsword"
4. Technical	How it's presented — resolution, angle, background	"full body, front view, white background, 2D game sprite"

Core prompt template

# Layer 1: Subject
a young elven female warrior, athletic build, silver hair, pointed ears,

# Layer 2: Style
anime cel-shading style, bold outlines, vibrant colors, game character art,

# Layer 3: Detail
wearing ornate silver plate armor with blue gem inlays,
holding a crystal longsword, flowing white cape,

# Layer 4: Technical
full body, front view, white background, high detail,
2D game sprite, transparent background

Weight syntax per tool

Tool	Weight syntax	Notes
Stable Diffusion	`(silver hair:1.3)`	Range 0.5-2.0
Midjourney	`silver hair::2`	Default weight is 1
DALL-E 3	"prominently silver hair"	Natural-language emphasis, no explicit weights
ComfyUI	CLIP Text Encode nodes	Visual weight adjustment

⚠️ Pitfall: weights above 1.8 cause artifacts and oversaturation. Keep core features at 1.2-1.5, secondary descriptions at default.

Step 3: Style Control & Consistency

Style consistency is the biggest challenge in AI game art. Lock your art direction with style anchors:

Style keyword lock — repeat the same style descriptors in every prompt
Reference image anchoring — MJ --sref, SD IP-Adapter, ComfyUI StyleModel
LoRA model lock — train a style-specific LoRA, use it everywhere
Color anchoring — fix palette descriptions or use color reference images

Style-specific prompt differences

# Lineart / Anime
clean lineart, anime cel shading, bold black outlines, flat colors, game UI art

# Cel-shaded / Flat
flat color, cel-shaded, 2-3 tone shading, sharp edges, vibrant palette, sticker art

# Painterly / Semi-realistic
painterly style, soft brush strokes, rich gradients, semi-realistic, concept art quality

# Pixel Art
pixel art, 32x32 sprite, limited palette, no anti-aliasing, retro game style

Consistency secret: build a Style Board — collect 5-10 reference images of your target style, extract the shared keywords, and include them in every single prompt. Midjourney's --sref accepts style reference URLs directly.

Step 4: Character Variation & Iteration

Games need variants: different angles, expressions, outfits, body types. The key is changing only what needs to change.

Multi-angle generation — what actually works

✅ Recommended	❌ Avoid
Midjourney `--cref` character reference	Random generation + cherry-picking
SD + ControlNet OpenPose	Relying on text descriptions alone
IP-Adapter FaceID	Mixing different tools mid-project
LoRA character training (15-30 images)	Not locking seed values
ComfyUI workflow reuse	Manual post-production stitching

Expression variation matrix

Expression	Prompt keywords
Happy	smiling, bright eyes, relaxed expression
Angry	frowning, furrowed brows, intense gaze
Sad	downturned mouth, teary eyes, drooping shoulders
Surprised	wide eyes, raised brows, open mouth
Determined	clenched jaw, focused eyes, confident stance
Fearful	wide scared eyes, tense body, defensive posture

Outfit / age / body type variations

# Base character (LOCKED — never change this part)
a young elven warrior, silver hair, athletic build,

# Outfit variation - Battle
wearing heavy battle armor, scarred metal, war paint,

# Outfit variation - Casual
wearing casual tavern clothes, linen shirt, leather vest,

# Age variation - Veteran
older version, battle scars, weathered face, grey streaks in hair,

# Body type variation
[slim / athletic / muscular / heavy] build, adjust proportions accordingly

Key rule: only modify the part that changes. Keep every other descriptor byte-identical. Seed lock + inpainting is the most efficient combo.

Step 5: Batch Generation Workflow

A real game needs dozens to hundreds of character assets. Manual one-by-one generation isn't feasible.

Seed control

Seed is the random-number starting point of generation. Fixed seed + fixed prompt = reproducible result.

Parameter	Recommended
Seed	Fixed for reproducibility
CFG scale	7-12
Steps	20-50
Batch size	4-8 per batch, pick the best

Prompt templating with variable substitution

Split prompts into fixed and variable parts, then batch-replace with a script:

# Template with variables
template = """
{base_character}, {action_pose},
{outfit}, {expression},
{style_keywords},
full body, front view, game sprite, transparent background
"""

# Variables
characters = ["elven warrior", "dwarf smith", "human mage"]
actions = ["idle stance", "attack pose", "walk cycle", "cast spell"]
outfits = ["battle armor", "casual clothes", "ceremonial robes"]
expressions = ["neutral", "happy", "angry", "determined"]

# Generate all combinations
total = len(characters) * len(actions) * len(outfits) * len(expressions)
print(f"Total: {total} images")

Automated batch pipeline

Character Definition → Template Assembly → Batch Generation
(JSON/YAML tables)     (script substitution)   (API or ComfyUI queue)

→ Quality Filtering → Post-Processing → Delivery Export
  (auto-score + review)  (bg removal, crop, name)  (sprite pack, metadata)

Efficiency tip: ComfyUI's batch nodes can chain generate → remove bg → crop → name into one automated pipeline. Feed it a CSV and generate hundreds of assets in one click.

Step 6: Game Asset Spec Compliance

AI output must conform to your engine's technical specs. Doing this at prompt time saves you hours of post-processing.

Character size specs by game type

Game type	Frame size	Format / notes
Pixel game	32x32 / 16x16	Integer scaling, Point filter, no anti-aliasing
Mobile 2D	256x256 / 512x512	ASTC/ETC2 compression
HD 2D	512x512+	Alpha channel, 2x scaling
PC HD	1024x1024	Mipmaps optional
Console / 4K	2048x2048	High precision

Size control in prompts

# Pixel art — exact size in prompt
"pixel art, 32x32 sprite, limited 16-color palette, clean pixels, no anti-aliasing"

# HD 2D — specify resolution
"2D game character, 512x512, high detail, transparent PNG background"

# Midjourney — aspect ratio
"--ar 1:1 --quality 2 --stylize 100"

# Stable Diffusion — explicit resolution
"--width 512 --height 512 --sampler dpm++2m_karras --steps 30"

Sprite-sheet-friendly generation

Unified canvas — every frame, same canvas size
Centered composition — prompt centered, full body
Bottom alignment — consistent feet position for animation
Spacing buffer — account for 2-4px to prevent color bleeding

Step 7: Post-Processing & Corrections

AI generation is rarely perfect first try. Here's the fix table we actually use:

❌ Issue	✅ Fix
Wrong finger count (6 fingers)	Inpaint hands + add `extra fingers` to negative prompt
Dirty background, leftover objects	`rembg` / RMBG model + check edge artifacts
Inconsistent character sizing	Unified crop to fixed canvas + ControlNet pose skeleton
Blurry or lost equipment detail	Upscale + local inpainting for detail sharpening
Color drift from palette	Post-process color grading + fixed-palette LoRA
White/black edges on transparency	Matting (MODNet) + 1px inner expansion

Inpainting workflow

# 1. Mask the problem area (hands, accessories, etc.)
# 2. Set denoising strength: 0.4-0.7 (lower = preserve more original)
# 3. Write a focused prompt for the masked region only
# 4. Use "Only masked" mode for precision

# ControlNet modes for character control:
# - OpenPose: exact body pose
# - Canny/Lineart: preserve outline structure
# - Depth: spatial relationships
# - IP-Adapter: transfer style from reference
# - Reference: maintain character identity

Workflow advice: check in this order after every generation — fingers → edges → symmetry → colors → details. Fix by priority, never redo from scratch.

Step 8: Advanced Prompt Techniques

Negative prompting

Negative prompts tell the model what not to generate — the cheapest quality lever you have:

# Universal negative for game characters
extra fingers, missing fingers, deformed hands, bad anatomy, mutated,
extra limbs, floating limbs, disconnected limbs,
blurry, low quality, low resolution, jpeg artifacts, watermark, text,
signature, cropped, out of frame, duplicate,

# Style conflicts (when doing clean 2D)
3D render, photorealistic, realistic, watercolor, oil painting,

# Game asset specific
background elements, scenery, props, shadow on ground,
multiple characters, frame border, UI elements

Regional prompting

Specify different prompts for different image regions:

SD Regional Prompter — split image into regions, independent prompts each
ComfyUI Area Conditioning — node-based region control
MJ --cref + --cw — control which parts of the character reference apply (face vs full body)

LoRA vs Textual Inversion

	LoRA	Textual Inversion
Training data	15-50 images	3-5 images
Quality	High	Medium
Flexibility	High	Medium

Best practice combo: Character LoRA (locks appearance) + Style LoRA (locks art style) + ControlNet (locks pose). Three layers = precise control.

Step 9: QA & Delivery Checklist

Before any asset ships, it passes professional QA. Here's ours:

Consistency QA standards

Visual	Technical	Naming
Face consistent across frames	All frames same size	`character_action_variant_frame.png`
Palette matches spec	Clean alpha, no edge artifacts	Clear folder structure
Line weight unified	File size within budget	JSON metadata per batch
Light direction consistent	Resolution meets platform spec	—

Naming convention

# Pattern: {character}_{action}_{variant}_{frame}.png
hero_knight_idle_front_001.png
hero_knight_attack_sword_001.png
npc_mage_cast_fire_001.png
enemy_goblin_idle_001.png

# Folder structure:
# /assets/characters/
#   /hero_knight/  →  /idle/  /walk/  /attack/
#   /npc_mage/     →  /idle/  /cast/
#   /enemy_goblin/ →  /idle/

QA item checklist

Check	Method	Pass criteria
Face consistency	Frame-by-frame compare in sprite sheet	No visible difference
Size spec	Batch detection	100% match target size
Alpha channel	Edge inspection	No white/black edges
File size	Batch statistics	Within budget
Naming	Regex validation	100% match rules
Animation smoothness	Preview in Unity/Cocos	No jitter or flicker

Key Takeaways

Prompt architecture beats prompt length. Four layers: Subject → Style → Detail → Technical.
Lock what must not change. Style keywords, seeds, and the base-character line stay byte-identical across variants.
Change only what changes. One variable per generation; everything else frozen.
Engineer for batch, not for singles. Templates + variable substitution + ComfyUI pipelines turn one good prompt into 500 assets.
QA is part of the pipeline. Consistency checklist before delivery is what separates "AI slop" from shippable art.

The framework is a loop: build templates → lock style → batch generate → strict QA. Master it, and AI stops being a lucky-dip generator and becomes your art team.

This guide is part of the GameArtForge tutorial library. You'll find the full illustrated version with more examples at gameartforge.com/tutorials/ai-character-design-prompt-engineering.html. We also build free game-art tools that automate parts of this pipeline.

Got a prompt trick that saves you hours? Drop it in the comments — I read every one.

A Performance-First Art Pipeline for HTML5 Games: Textures, Atlases & Lazy Loading

GameArtForge — Fri, 21 Aug 2026 07:00:32 +0000

A Performance-First Art Pipeline for HTML5 Games

You shipped your HTML5 game. It looks gorgeous on your desktop — then a player opens it on a mid-range Android phone and it stutters, loads for 20 seconds, and eats 600MB of RAM. Sound familiar?

The difference between a game that runs everywhere and one that only runs on your machine is usually not the code — it's the art pipeline. Textures, atlases and loading order are where 80% of web-game performance problems live.

Here's the pipeline we use to ship mobile-friendly HTML5 games without sacrificing art quality.

Why Web Games Need a Performance-First Approach

Unlike desktop builds, web games face three hard constraints at once:

Constraint	Reality
Bandwidth	Players abandon loading screens after ~3s on mobile networks
Memory	Browsers often cap out around 1-2GB; old phones are far tighter
Draw calls	Mobile GPUs are more sensitive to overdraw and small draw calls

A single 2048×2048 RGBA texture is 16MB in memory. Three of those plus mipmaps and your art budget is blown before a single scene loads. Texture compression isn't optional — it's the difference between playable and unplayable.

Step 1: Texture Compression Basics

Why compression is a game-changer

A 1024×1024 RGBA texture:

Uncompressed: 4MB (16MB with mipmaps)
WebP / AVIF: ~200-500KB on disk, but browsers must decompress it at runtime into full RGBA in memory
GPU-compressed (ETC2/ASTC/S3TC): ~1-2MB in memory, decompressed by the GPU itself on the fly

The key insight: disk size is not memory size. You need both sides — small download and GPU-native formats so memory stays low.

What format to pick

Format	Support	Best for
ASTC	Modern mobile (ARM Mali, Adreno 8xx+)	Best quality-per-bit, iOS + Android
ETC2	All Android, iOS 8+, WebGL2	Default fallback
S3TC/DXT	Desktop, older iOS Safari	Desktop fallback
WebP/AVIF	Universal via browsers	Loading screens, UI, non-GPU textures

The pragmatic rule

For any texture that appears in a 3D scene or is GPU-sampled at scale, use GPU compression. Reserve WebP for UI, icons and preload screens.

Step 2: Texture Compression Workflow (Practical)

Compression happens at build time, not runtime. Here's the pipeline we use:

1. Keep your source art lossless

Store PSD/TIFF/PNG masters at max quality. Compression is a delivery step, never applied to source files.

2. Compress per-target with a build script

# Using basisu (Basis Universal) — one tool, all formats
basisu -file hero.png -output_format basis -mipmap -multithreading

# Or texture-encoder for explicit per-format output
texture-encoder -f input.png --target astc --quality high --output output.astc

3. Detect GPU support at runtime

function getSupportedTextureFormat() {
  const gl = canvas.getContext('webgl2');
  const ext = gl.getExtension('WEBGL_compressed_texture_astc');
  if (ext) return 'astc';
  const etc2 = gl.getExtension('WEBGL_compressed_texture_etc1') ||
               gl.getExtension('WEBGL_compressed_texture_etc');
  if (etc2) return 'etc2';
  return 's3tc'; // desktop fallback
}

4. Load the right variant

const format = getSupportedTextureFormat();
const url = `textures/hero.${format}`;

The 10% rule

If a texture compresses by less than 10% in GPU format, it's probably not worth compressing — it's already simple enough to store as WebP and skip GPU memory entirely. Apply this rule and you'll naturally keep the pipeline lean.

Step 3: Sprite Atlas Design

Hundreds of individual sprite images = hundreds of draw calls + hundreds of file requests. An atlas turns that into one texture + one draw call.

Atlas design rules that actually matter

Power-of-two sizes — 1024, 2048, 4096. Non-POT breaks mipmap generation and some mobile GPUs.
2px padding around each sprite — prevents bleeding artifacts with linear filtering.
1px extrude (duplicate edge pixels) — kills edge halos completely. Even with padding, extrude is what makes filtered edges look clean.
Split by usage, not by scene — one atlas for UI, one for characters, one for effects. Effects atlases change often; UI never does. Split them so updates don't invalidate everything.

Typical result

250 loose sprites → 4 atlases
250 draw calls → ~20-40
250 HTTP requests → 4

That's the single biggest win available on the art side.

Step 4: Atlas Build Toolchain

Manual atlas editing is a trap — one image added and the whole layout breaks. Automate it:

Free tools that work

Tool	Why we like it
TexturePacker	Gold standard, CLI + GUI, all formats
Free Texture Packer	Open source, cross-platform
Shoebox	Fast, scriptable
Leshy SpriteSheet Tool	Great browser-based free option

Headless build in CI

TexturePacker --sheet output/heroes.png \
  --data output/heroes.json \
  --format json-hash \
  --trim \
  --size-constraints POT \
  --extrude 1 \
  --padding 2 \
  --opt RGBA8888 \
  --max-size 2048 \
  --enable-rotation \
  assets/characters/

Your engine then loads the JSON, not hardcoded coordinates — add art, rebuild, done.

Step 5: Lazy Loading Strategy

Nobody needs every texture at game start. Loading everything up-front is how you get 20-second load screens.

Three tiers of assets

Tier	What	When
Critical	Loading screen, main menu, first scene	Preload at boot
Near	Assets for the next 1-2 scenes	Preload during current scene
Far	Bosses, later levels, cosmetics	Lazy-load on demand

Priority queue, not a flat list

const loader = new PriorityLoader();

// Critical path first
loader.add('menu.png', { priority: 10 });
loader.add('scene1-bg.png', { priority: 9 });

// Everything else, low priority
loader.add('boss.png', { priority: 1 });
loader.add('cutscene-fx.png', { priority: 1 });

// Load as bandwidth frees up
loader.process();

Trigger lazy loads by proximity

player.onEnterZone('level3', () => {
  loader.add('level3-bg.png', { priority: 8 });
  loader.add('level3-enemies.png', { priority: 8 });
});

This keeps the initial bundle small and the game feels instant, because loading happens while the player is already playing.

Step 6: Dynamic Quality Adaptation

The best optimization is the one that adapts to the device. A desktop RTX GPU and a 2019 Android phone should not receive the same texture set.

Detect device capability once

function detectDeviceProfile() {
  const cores = navigator.hardwareConcurrency || 4;
  const deviceMemory = navigator.deviceMemory || 4;
  const isMobile = /Mobi|Android/i.test(navigator.userAgent);

  if (isMobile && (cores <= 4 || deviceMemory <= 4)) return 'low';
  if (deviceMemory <= 8 || cores <= 8) return 'medium';
  return 'high';
}

Fall back dynamically

const profile = detectDeviceProfile();
const qualityMap = {
  low:    { textureScale: 0.5, maxAnisotropy: 1,  shadows: false },
  medium: { textureScale: 0.75, maxAnisotropy: 4, shadows: true  },
  high:   { textureScale: 1,    maxAnisotropy: 8, shadows: true  }
};
applyQuality(qualityMap[profile]);

Monitor FPS, drop quality if needed

let fps = 0, frames = 0;
setInterval(() => {
  fps = frames; frames = 0;
  if (fps < 40 && profile === 'high') {
    applyQuality(qualityMap.medium); // graceful degradation
  }
}, 1000);

Players would rather see a slightly softer texture than a stuttering game. Quality adaptation is a UX feature, not a compromise.

Step 7: The Results (Real Benchmarks)

Applied to a mobile RPG prototype with 3 scenes, 260 sprites and heavy effects:

Metric	Before	After	Change
First paint	8.2s	2.1s	-74%
Full load	22s	4.2s	-81%
Peak memory	612MB	152MB	-75%
Draw calls (battle)	240	38	-84%
Avg FPS (mid-range Android)	31	60	+93%

The same art, same scenes — only the delivery pipeline changed.

Step 8: Checklist — Apply This to Your Game

Before writing more optimization code, verify all of these:

[ ] All scene textures use GPU-native compression (ASTC/ETC2/S3TC)
[ ] Format detection + per-device fallback is implemented
[ ] Sprites are packed into POT atlases with 2px padding + 1px extrude
[ ] Atlas build is scripted (CI or npm script), not manual
[ ] Assets split into critical / near / far loading tiers
[ ] Lazy loading triggered by scene or proximity, not a flat list
[ ] Device profile detected once at boot
[ ] FPS monitor with graceful quality fallback
[ ] WebP reserved for UI + preload screens, not scene textures

Common mistakes that undo all of this:

Compressing only the download size (WebP) while ignoring GPU memory
Atlas with padding but no extrude → edge halos appear anyway
One giant atlas for everything → every tiny change invalidates the whole cache
Loading everything up-front "just in case" → destroys the entire point of lazy loading

Toolchain Summary

Job	Tool
Texture compression	Basis Universal (`basisu`), texture-encoder
Sprite atlasing	TexturePacker, Free Texture Packer
Priority loading	Custom loader (or engine's built-in)
Quality detection	`navigator.deviceMemory` + `hardwareConcurrency`
Bundle analysis	webpack-bundle-analyzer / rollup visualizer

Key Takeaways

Compress for GPU, not just for download. WebP saves bandwidth; ASTC/ETC2 saves memory.
Atlas everything that's sampled at scale. Draw calls are the #1 mobile killer.
Load lazily by priority. The loading screen should never wait for content the player can't see yet.
Adapt quality to the device. One art set for every device is a 2015 mindset.
Automate the build. Manual compression and atlas edits don't survive a real release cycle.

The art you already made is fine — it just needs the right pipeline around it.

This guide is part of the GameArtForge tutorial library. You'll find the full illustrated version with more code examples and the complete toolchain setup at gameartforge.com/tutorials/web-game-performance-art-pipeline.html. We also build free game-art tools that automate parts of this pipeline.

Have a tip that saved your HTML5 game? Drop it in the comments — I read every one.