“Keep textures small,” “follow naming conventions,” and “remove unused assets” are easy requirements to write down. As the asset count grows, relying on everyone to remember every requirement makes consistent results harder to achieve.
One job of an asset-checking tool is to turn those descriptions into repeatable evaluations. When designing rules, I care about whether people can understand and maintain them and trace their findings, beyond simply displaying a red error.
Break the requirement into parts
Take a fictional requirement: “For 2D textures in the demo directory, the largest dimension must not exceed 2,048 pixels.” At least three parts need to be expressed independently.
| Part | Question to answer | Example |
|---|---|---|
| Scope | Which objects are checked? | 2D textures in the demo directory |
| Condition | What counts as a pass? | The larger of width and height ≤ 2,048 |
| Response | What happens when an issue is found? | Record the object, actual value, and expected value |
There is another easily missed question: does “dimension” refer to the source image or the size used for a particular platform and configuration? The same sentence can describe different checks. The rule must define the measurement source, and the report should state it too.
scope: DemoTextures / Texture2D
measure: max(SourceWidth, SourceHeight)
expect: value <= 2048
report: asset + measuredValue + expectedValue
action: reviewInclude enough evidence in each result
“Texture does not meet the standard” gives the user too little to act on. A more useful result is: “T_DemoStone_BC has a maximum source-image dimension of 4,096; this rule allows up to 2,048.” It identifies the object, actual value, and expected value without making the user infer the checking logic.
Results should also distinguish pass, fail, and unable to check. If an object could not be read or required information is unavailable, the absence of a result cannot count as a pass. Skipped checks need a reason so that a clean-looking report does not hide missing coverage.
Design checks and changes separately
Finding an issue does not mean the tool knows a single correct fix. An oversized texture might need a different usage strategy or a revised source image. Automatic changes should cover only cases with a clear purpose and understandable effects.
A maintainable workflow can show the target object and proposed change, perform the action, and then check again. Only a passing recheck demonstrates that the issue is resolved under the current criteria. An action completing and a check passing are distinct pieces of information.
For issues that do not suit automatic handling, clear location information and an explanation are valuable on their own. A fix button on every rule should not conceal decisions that need a content creator's judgment.
Treat rules as content that needs maintenance
Standards, directories, and asset categories change. Rules need stable identifiers, explicit scope, and records explaining exceptions. After changing a threshold, rechecking a small set of passing, failing, and missing-information examples tells us more than the error count alone.
This is the design direction I want to establish when introducing ResourceToolkit: express standards clearly, make findings traceable, and verify the state after an action. Rules can accumulate over time; trust in their results starts with the first one.
The homepage's interactive example shows how thresholds, evaluation, and rechecking relate. It changes only fictional data in the browser and does not represent real asset processing in UE.