| name | using-origingame-assets |
| description | Finds, previews, and pulls OriginGame's production CC0 game assets (Poly Haven HDRIs/PBR materials/models, Kenney, KayKit, Quaternius, and icons) when they match a game's approved art direction. Prefer the remote asset MCP; a REST helper (assets.sh) is available as a fallback. |
Using OriginGame Assets
Use the built-in CC0 asset library for assets whose silhouette, material response, detail density,
scale, and semantic role fit the approved art direction. The curated production corpus includes
self-hosted HDR environments, complete web PBR material bundles, and web-ready glTF/GLB models in
addition to broad game packs. Pull assets into the project and reference them by relative path;
never hotlink asset API URLs from a deployed game.
Preferred: the asset MCP
Connect an MCP-capable agent to the remote HTTP MCP and authenticate with an OriginGame sk- key:
endpoint: https://asset-mcp.origingame.dev/mcp
header: Authorization: Bearer sk-...
Tools:
assets_search — query + facets (resource_type, material_type, time_of_day, weather, kind, theme, visual_style, role, format, game_genre, source). Returns each logical asset's primary and tags.assets_show — full detail for a group: variant files, formats, target paths, download-only flags.assets_bundle — a fetch-plan (no zip): direct per-file URLs + target paths under assets/origingame/, plus attribution and a manifest. Download each file to its targetPath (glTF primary + its .bin/textures are included as resources).assets_recommend — role-bucketed picks (characters / enemies / props / environment / tiles / ui / audio) for a short game brief.assets_facets — the available facets and values for building filters.
Anonymous browsing (search / show / static thumbnails) is allowed; downloads, glTF resources, and the
interactive 3D viewer require an sk- key. Create one at $OG_HOST/dashboard. Never print or commit it.
Fallback: assets.sh (REST)
When MCP is unavailable, use the bundled helper:
../origingame-deploy/scripts/assets.sh search "weathered medieval knight" --kind 3d --format glb
../origingame-deploy/scripts/assets.sh show <group-id>
../origingame-deploy/scripts/assets.sh bundle --group <group-id> --format glb --out ./assets/origingame
bundle consumes the same fetch-plan and writes files under --out (default ./assets/origingame)
plus ATTRIBUTION.txt. search/show work without a key; bundle/get may require OG_API_KEY (sk-...).
Deploy attribution
deploy.sh auto-detects asset-manifest.json under assets/ and sends the used asset group ids as
assets_used. If assets live elsewhere, pass them explicitly:
../origingame-deploy/scripts/deploy.sh ./dist --title "My Game" --assets "groupid1,groupid2"
Selection guidance
- Start from the project's approved Asset Bill of Materials when one exists. It
identifies only this game's required roles, art-direction compatibility, source
strategy, and runtime consumers; it is not a quantity template or approval gate.
- Prefer one cohesive material/silhouette/detail language per scene. The catalog's
canonical production asset is the selection; do not choose source tiers,
resolutions, polygon classes, or prospective optimization variants.
- Pull only the groups/files the game actually uses.
- Preserve
ATTRIBUTION.txt in the project, even though CC0 attribution is optional.
- Install groups, not isolated files: a PBR material needs its map siblings and glTF needs its
.bin/texture resources. The bundle fetch-plan preserves those runtime relationships; catalog previews remain browse evidence rather than project payload. In og-engine projects, load every texture with an explicit semantic (color/emissive = sRGB; normal/arm/height/opacity/data = linear), consume packed ARM once through game.assets.pbrMaterial(), and keep sampled terrain choices in the project terrain config rather than project-local shader rewrites.
- A catalog HDRI or the engine neutral light rig is not a default final look. Select environment, time/weather, materials, and light composition for the approved game, or explicitly author a procedural/unlit alternative.
- Catalog availability does not make an asset final. Reject mismatched low-poly,
preview, or generic kit content rather than weakening an identity-bearing role.
Asset production order (with Studio / agents)
- Read the bill and define the world kit — name the required terrain, structural, prop, dressing, and actor roles plus their shared silhouette/material/detail language.
- Inspect, then accept or reject catalog families — use search/show/bundle for reusable physical components when a cohesive family meets that bar; do not let catalog availability redefine the art direction.
- Generate identity-bearing gaps — in Studio use its provider-neutral image, 3D, and audio Workbench tools for characters/creatures, hero props, signature architecture, key VFX/UI art, music, and semantic SFX when catalog content would weaken the game. Keep every result local. Outside Studio, use the platform capability documented by the active host rather than embedding a provider call in game code.
- Use matching catalog support and dressing around the primary kit, and author or use procedural treatment only for bill entries assigned that strategy.
- Use procedural geometry for systems such as particles, tiny fillers, and collision helpers—not as a substitute for authored visible forms.
Resolve every applicable bill entry to a local runtime consumer or to an explicit
authored absence such as a procedural sky/unlit treatment. Preview defaults never
count. Start with the canonical production asset and make no multi-resolution or
source-tier decision. Optimize a project-local result only after completed
representative active play exposes a measured bottleneck. Every installed or generated file must
be loaded by the game (relative path). Download URLs expire; never hotlink Gateway
or asset API URLs from a deployed game.
