Game-asset generation: sprites, tiles, and items at scale

Every solo dev hits the same wall around month three: the code works, the loop is fun, but the game looks like programmer art. Hiring a pixel artist is out of budget, and generic image APIs spit out four "fantasy knights" that look like four different games glued together. We built this endpoint for exactly that gap.

What it does

POST /v1/game/generate is a purpose-built generator for game art. You hand it a description, tell it what kind of asset you want, and it returns either a single image or a style-locked batch of up to 12 variants in one call.

The five asset_type values cover the meat of what an indie 2D game actually needs:

• sprite — characters, enemies, animated entities
• tile — terrain tiles, dungeon walls, floors, ceilings
• item — pickups, inventory icons, loot, consumables
• character — fuller character portraits and full-body designs
• background — backdrops and parallax layers

You pick a style from pixel, 2d-cartoon, isometric, or hand-drawn. Pixel is the default because that's where most indie shipping actually happens. Resolution is 32, 64, 128, or 256 — sized for sprite sheets, not for billboards. Default is 64.

The field that matters most is count. Set it to anything from 1 to 12, and the generator runs a batched pass where every output shares the same colour palette, lighting, and rendering treatment. That single parameter is what separates "I have a knight" from "I have a knight, an archer, a mage, and a thief that all look like they belong in the same game."

Required fields are asset_type and prompt. Everything else has sensible defaults.

Each call costs 12 credits — we'll get to the rupee and dollar amounts further down.

Why we built it

Indie devs are the loudest user segment we have, and they kept asking the same thing in different words: "Why does your image API give me four different art styles when I ask for four sprites?"

Fair question. Most general-purpose image APIs are tuned for marketing renders, stock photography, social posts. You ask for a knight, you get a knight — but ask twice and you get two knights from two completely different fantasy universes. For a marketing render, that's fine; you only need one. For a game where the knight, the goblin, and the chest icon all need to look like they live in the same world, it's useless.

Our angle is narrow on purpose. This endpoint isn't a general image API with a "game" toggle bolted on. It's tuned, end-to-end, for the constraints of game art:

• Style locking across a batch. When count > 1, the generator preserves palette, line weight, shading conventions, and pixel density across every output. Most general image APIs drift between calls — even calls one second apart — because they have no notion of "these N images belong together." Batch mode is the whole reason to use this endpoint over a generic one.
• Resolutions that match sprite-sheet reality. No one is shipping a 1792×1024 sprite. The 32/64/128/256 choices are the ones you actually drop into Aseprite, Godot, Unity, or LÖVE.
• Asset types instead of free-form prompts. Telling the model "this is a tile" gives it different behaviour than "this is a character" — edge handling, transparency assumptions, framing, all of it. You shouldn't have to engineer that into your prompt.

We're not trying to replace a great pixel artist. We're trying to get you from blank canvas to prototype that doesn't embarrass you in front of playtesters in an afternoon.

Quickstart

The smallest useful call — give it a prompt, ask for four style-consistent variants of a knight sprite:

curl -X POST https://api.pixelapi.dev/v1/game/generate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"asset_type": "sprite", "prompt": "fantasy knight", "style": "pixel", "count": 4}'

Same call in Python with requests:

import requests

resp = requests.post(
    "https://api.pixelapi.dev/v1/game/generate",
    headers={
        "Authorization": "Bearer YOUR_API_KEY",
        "Content-Type": "application/json",
    },
    json={
        "asset_type": "sprite",
        "prompt": "fantasy knight",
        "style": "pixel",
        "count": 4,
    },
)

resp.raise_for_status()
data = resp.json()

for i, asset in enumerate(data["assets"]):
    print(f"Asset {i}: {asset['url']}")

That's it. Drop your key in, run it, you've got four knights. Bump count to 12 and you've got a small NPC roster. Swap asset_type to tile and the same prompt syntax gives you ground tiles. Swap style to isometric and you're suddenly building something that looks a lot like a 90s strategy game.

A few practical notes for production use:

• Keep your prompts specific about the subject but loose about the style. The style parameter is doing that work for you. "Fantasy knight with greatsword" beats "pixel-art fantasy knight with greatsword in 16-bit SNES style" — the second one fights the style parameter.
• For tile sets, mention the biome or theme in the prompt and let count handle the variations. A prompt of "lava cavern floor" with count: 16 and asset_type: tile will give you a tile pack that tiles cleanly with itself.
• For character batches, give the role in the prompt and let the batch generate the variants. "Roguelike adventurer" with count: 12 returns 12 distinct adventurers, not 12 copies of the same one.

Use cases

Generate a 32-tile dungeon set in one call, all sharing the same palette

You're building a dungeon crawler. You need floor tiles, wall tiles, corner pieces, doorways, stairs, decorations — and they all need to look like they were drawn by the same hand on the same afternoon. Doing this with a general image API is a special kind of pain: you generate 32 tiles, half of them are slightly off-hue, three of them look like they came from a different game entirely, and you spend the next two hours in Photoshop trying to colour-match them.

With batch mode, you send one call with asset_type: tile, count: 12 (run it twice or three times for a 32-tile set if you need more than one batch), and a prompt like "stone dungeon, torchlit, mossy" — and the whole batch comes back palette-locked. The mossy stones in tile 1 are the same green as the mossy stones in tile 11. The torch glow falls at the same angle. You can drop them into your tilemap and they read as a single set, not a collage. For a genre that lives or dies on coherent environment art, that's the difference between "prototype" and "playable demo."

Spin up 12 NPC sprite variants for a roguelike

Roguelikes need a lot of characters. A single run might surface fifty different enemy types, and each one needs to be visually distinct enough that players can read it at a glance, but consistent enough with the rest of the cast that the game doesn't feel like a clip-art collage. This is exactly the problem count: 12 solves: one prompt — "goblin warrior", "skeletal mage", "shrouded cultist" — comes back as a dozen variants that read as members of the same faction.

The workflow we keep hearing about from indie teams: they spend an hour generating six or seven batches by faction (goblin tribe, undead, cultists, bandits, beasts, elementals), end up with seventy-odd enemy sprites that all sit in the same visual universe, and ship a content-rich roguelike demo in a week instead of a quarter. The style consistency inside each faction matters more than overall realism — you're building a cast, not a single hero render.

Produce item icons (potions, swords, scrolls) for a loot drop

Inventory icons are the part of the game art pipeline that nobody wants to draw. There are dozens of them, they're tiny, they need to read clearly at 32×32 or 64×64, and they all need to share a frame style so the inventory grid doesn't look like a yard sale. It's the most thankless asset class in indie dev, and it's the one where batch mode pays the biggest dividend.

A single call with asset_type: item, resolution: 64, count: 12, and a prompt of "fantasy RPG loot — potions, swords, scrolls, rings" returns a dozen icons that share rendering style, lighting direction, and border treatment. Run two or three batches for different loot categories — consumables, equipment, key items — and you have a complete loot table's worth of icons in under an hour. They won't replace a hand-illustrated icon pack from a senior artist, but for an alpha, a jam game, or a vertical slice you're showing publishers, they're more than good enough.

Pricing

Each call to POST /v1/game/generate costs 12 credits, regardless of count. That means a count: 12 batch costs the same as a single asset — we want you using batch mode, because that's where the style-locking value lives.

In money:

• ₹0.008 per call (INR)
• $0.00010 per call (USD)

That's per API call, not per asset. A 12-sprite roguelike NPC batch costs the same ₹0.008 / $0.00010 as a single sprite. Generate a full 32-tile dungeon set across three calls and you've spent ₹0.024 — less than a rupee for a complete tile pack. Spend ₹10 and you've made over a thousand calls; spend a dollar and you've made several thousand. Indie budgets aren't broken by this line item, which is the whole point.

Credits are bought in bundles on the dashboard. There's no monthly minimum, no seat fee, and no per-asset surcharge for higher resolution or larger batch size. If 12 credits leaves your wallet, you got an answer back.

Try it

• Dashboard, key provisioning, and credit top-up: pixelapi.dev/dashboard
• Full request/response schema, error codes, and rate limits: pixelapi.dev/docs

Generate something, drop it in your engine, see how it reads in-game. That's the only benchmark that matters for game art, and it's the one we built this endpoint to clear. Ship the prototype this weekend.