Asset Review：毋須逐一開啟檔案，找出合適的遊戲素材

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

Asset Review is a small browser-local tool for a tedious part of preparing a game release: finding the asset you mean and checking the folder for avoidable mistakes.

Instead of remembering whether a restorative item is called potion, vial, or item_04, describe what you need. A real local MiniLM model compares your question with filenames and supplied descriptions. Separately, an ordinary deterministic checklist flags identical file bytes, missing provenance fields, empty or temporary files, case collisions, missing indexed assets and missing declared references.

The intended payoff is less folder archaeology and fewer repetitive checks. This is a new prototype, not a claim of measured time savings or real-world adoption.

AI development disclosure: An AI coding assistant autonomously implemented and tested the app and drafted this write-up under the project owner's direction. No human learning journey or manually authored implementation is being claimed. The project was created on October 23, 2026; it does not reuse an existing private game's code or assets.

Demo

Open Asset Review.

Start with Explore the sample folder, then try Restore health. The sample contains an asset described as a glass vial of red restorative liquid. Its deliberately unhelpful filename is sprites/item_04.svg.

The sample graphics are original numbered geometric SVG fixtures, not pictures of the objects in their illustrative descriptions. Search reads the text metadata, not image pixels or audio.

You can also select your own folder and supply an asset-index.json. The app limits imports to 250 files and 25 MB combined. It reads selected files in memory and does not modify the originals. The model and runtime load from the app's origin; selected asset contents are not uploaded to a remote inference service. Exported reports contain filenames and supplied metadata, so review them before sharing.

Code

EITC-Games/asset-review

The original application source is MIT-licensed. Third-party model and runtime licenses remain separate. Setup uses a pinned npm dependency lockfile, a fixed model revision and artifact hashes; generated model weights and vendor bundles are downloaded rather than committed.

How I Built It

The semantic path uses Xenova/all-MiniLM-L6-v2, an Apache-2.0 model, through Transformers.js. Each query and asset description becomes a 384-dimensional, mean-pooled, normalized embedding. Cosine similarity determines the order of results. Browser inference uses WebAssembly; the Node tests use local CPU inference.

The important design boundary is between suggestions and facts. A language model can suggest which description is closest to a request. It should not decide whether a file has a valid license or pretend to know which dependencies a game engine needs. Those checks stay explicit and limited: compare hashes, inspect recorded fields and check declared paths.

The assistant reran the aggregate test suite on October 23: 11 tests passed. These cover deterministic checks, real-model retrieval, normalized 384-dimensional vectors, validation and a deliberately missing local model. One retrieval test asks for “sound of the ocean” and ranks a description of waves crashing on a beach above unrelated assets. The sample-specific test ranks the restorative vial first for “Something to help a wounded player.”

Live browser checks also verified MiniLM inference: Restore health ranked sprites/item_04.svg first at 0.356 similarity, and a sea-related query ranked sprites/prop_09.svg first at 0.475. The sample produced nine files, three warnings and four review notes; the warnings filter showed three results. The exported JSON was downloaded and parsed with nine files, and reset and reload checks succeeded. These are similarity scores, not confidence percentages. A folder-import attempt did not produce an observable change and is not counted as passed. Mobile behavior remains untested.

If local model loading fails, the UI reports the failure. It does not quietly substitute keyword results and label them AI. The independent release checklist can still work.

Why Does Open Innovation Matter?

An open model makes the retrieval step inspectable and locally runnable. There is no inference API key to obtain and no per-query inference service bill. After downloading the dependencies and weights, a local copy can perform inference without contacting an external model provider.

This matters for unreleased assets: finding a file should not require sending its description or contents to someone else's inference API. Keeping the model and runtime beside the application also makes the dependency boundary visible. The model revision and artifact hashes are recorded rather than hidden behind a changing service endpoint.

There are tradeoffs. The initial model and WASM downloads are substantial, CPU speed varies, and text metadata still needs to be useful. The model can return an irrelevant nearest match, and a high similarity score is not a probability. Asset Review does not inspect visual content, verify ownership, give legal clearance or perform a complete game-engine dependency scan.

The scope is deliberately small: describe what you need, get a ranked shortlist, then review a few concrete folder issues without changing the files.