Write the acceptance test before browsing
Game-ready is a relationship between an asset and a particular project, not a badge that settles every technical question. A background lantern in a browser puzzle has different requirements from a destructible gate in a networked action game. Begin with the camera distance, target hardware, interaction and expected number of instances. Decide what you need to measure before falling in love with a silhouette. That turns browsing into a small production decision instead of a speculative download session.
For a courtyard test, choose the real Foundry yard kit and inspect its parts individually. Quench barrel, Workshop lantern and Arch gatehouse provide different roles without requiring invented IDs. Read their current triangle counts, dimensions, palette, rig flags and release information. A record tells you what is advertised for that piece; it is not evidence that your entire scene meets a frame budget. Set explicit acceptance conditions, such as readable props at the game camera and no visible ground penetration.
Count what is drawn, not just what is listed
The triangle budget belongs to the assembled scene. Sum each placed instance, including repeated decorative objects. Then measure the actual export after knob changes and hidden-part choices. In existing browser export proof, one barrel snapshot had 424 triangles and one lantern snapshot had 300. Those samples were reloaded with GLTFLoader and their counts matched the live export. The figures are useful examples of a check, not permanent promises for all versions, settings or catalogue objects.
Triangles are only one cost. Materials, separate meshes, transparent surfaces, shadow passes and texture memory can matter more than a modest difference in geometry. Test with the same renderer settings and camera your game will use. Duplicate a prop until the intended density is represented; a single item rotating in an empty viewer does not approximate a busy level. Write down the target device and the test conditions so the result can be repeated rather than remembered as a vague impression.
Treat the kit as an assembly contract
The shared scene contract uses metres, Y-up and positive Z forward. Model footprints are centred in X and Z and rest on Y zero. The Foundry yard structural grid is four metres. Use that value when placing its modules, and read the usage record before carrying an arrangement into another kit. Keep scene-wide wear consistent where the pieces expose it. Colourways may vary locally, but an accidental mixture of pristine and derelict structures can undermine an otherwise coherent scene.
Inspect the imported bounding box against a metre reference and your player capsule. A correct catalogue dimension does not prove that a doorway suits your game's movement or collision rules. Add project-owned colliders deliberately and test them with the real controller. Do not infer collision meshes, navigation surfaces, LOD chains, IK or texture maps unless the detail record supplies them. Ground uneven props using terrain samples. A neat preview is not a substitute for testing slope contact and player clearance in your level.
Make version and format part of the gate
Check entitlement, provenance, available formats and delivery status before scheduling an asset into production. A catalogue entry can be visible while a particular release is withheld or a download is unavailable. The same distinction applies to paid access: paying for access does not magically publish every listed format. Record the exact version that was delivered and preserve its licence findings. If a format cannot be obtained, stop that acceptance test and report the limitation instead of inventing a path or a successful receipt.
The Use it panel captures the current preview as a static ES module or a binary GLB. It does not turn a kit into a promise of editor tooling, animated rigs or a hosted factory. A snapshot can be valuable for an import check, but its settings are baked and its provenance still matters. Save the manifest beside the local file: IDs, knob values, placement transforms, measured triangles and the selected version. Keep project-specific changes separate so you can identify which part of a later failure came from your integration.
Finish with a small engine-specific test
Existing evidence verifies particular GLB samples through three.js GLTFLoader and a browser export round trip. That establishes that those binaries could be parsed in that environment. It does not establish Unity compatibility, Godot collision, animation fidelity or performance on your shipping device. Unity tooling is untested here. The Godot snippet is an import recipe, not a checked engine result. Treat both as starting points for your own test scene, then document engine version, importer version and observed output.
Ask an assistant to read prompt.txt before helping with discovery. The preview_scene tool reports catalogue compatibility and summary information; it does not render or export an assembled scene. Require a final report containing actual selected IDs, all placements, budgets, access findings and unresolved gaps. Your production gate should be equally concrete: a saved file opens, scale looks correct, required interactions work and the measured scene meets its target. Anything not exercised remains an open question, not an implied success.
Real records used in this guide
- Quench barrel
quench-barrel - Workshop lantern
workshop-lantern - Arch gatehouse
arch-gatehouse - Foundry yard
foundry-yard
Check the selected version’s release, rights and access before using any file.