There is a particular kind of frustration that only appears late in development.
You package your Unreal project. You look at the output folder. And something feels wrong.
The build is bigger than you expected. Not dramatically. Not catastrophically. Just… suspiciously large.
You know you didn’t intentionally ship 20 gigabytes of content. But Unreal’s packaging output does not give you a clean, actionable breakdown of what is actually consuming space. It gives you a list. A very long list. And technically, that list contains all the information you need.
Practically speaking, it’s unusable.
The Illusion of Data
Running:
UnrealPak.exe <container>.utoc -List -IncludeSizes
Code language: CSS (css)produces thousands of lines that look like this:
LogIoStore: Display: "../../../Polly/Content/Prototype/UI_Assets/Icons/Currency/T_currency-gem.uasset" ...
size: 2033 bytes, compression: Oodle.
Code language: HTTP (http)The path is there.
The size is there.
The compression format is there.
Everything is there — except clarity.
There is no hierarchy. No aggregation. No sense of scale beyond raw numbers scrolling past your terminal. You cannot see that one folder quietly accounts for 40% of your build. You cannot immediately identify whether your texture folder has grown out of proportion. You cannot meaningfully reason about trade-offs.
This is a recurring pattern in development: having information is not the same thing as having insight.
Development Is Systems, Not Just Features
Indie developers often think of their work in terms of mechanics, rendering pipelines, AI behaviours, networking, and input systems. The visible parts of the game.
But the invisible systems are just as important:
- Build size.
- Asset growth.
- Compression efficiency.
- Content organisation.
- Tooling feedback loops.
If you do not have visibility into these systems, you are operating on intuition. And intuition degrades under complexity.
As projects grow, entropy accumulates. Assets creep in. Temporary content becomes permanent. Experimental folders survive far longer than intended. Without tooling, the project quietly drifts.
This is where internal tools stop being a luxury and become infrastructure.
Building the Missing Layer
The problem was simple in theory:
Take UnrealPak’s flat output and turn it into something intelligible.
The solution, however, required several layers:
- Parse the UnrealPak output.
- Reconstruct the folder hierarchy from raw paths.
- Aggregate file sizes upward into folders.
- Render a navigable tree.
- Add meaningful sorting.
- Surface compression visually.
- Make it usable at scale.
The end result became a single-page HTML tool built with Bootstrap 5 and Tabulator. It loads the UnrealPak listing from disk, reconstructs the directory tree, calculates cumulative folder sizes, groups folders before files, sorts case-insensitively, and allows expansion and collapse at any depth.
Folders are marked with a subtle yellow icon. Compressed assets (such as Oodle-compressed files) are marked in blue. Exact byte counts appear on hover. The entire structure becomes legible in seconds.
What was once a wall of text becomes a map.
The Iteration Is the Story
The interesting part, however, was not the final tool. It was the process of refining it.
The first version technically worked — but visually it was flawed. Indentation drifted at deeper levels of the tree. Expand/collapse controls caused layout “popping.” Sorting behaviour unintentionally reshuffled folder grouping. Regex logic failed to correctly detect compression on certain lines. A stray brace broke file loading entirely.
Each issue required investigation.
Why does indentation break after two levels?
Why is Tabulator re-sorting the tree structure?
Why are some compressed files not flagged correctly?
Why does Bootstrap styling not apply as expected?
None of these were large problems individually. But together they illustrate something fundamental: development is rarely about writing the first version. It is about eliminating friction until the system behaves predictably.
This is where AI-assisted workflows become powerful.
AI as a Development Multiplier
What happened here was not “AI writes the tool.”
It was:
- Rapid scaffolding of the initial parser.
- Fast iteration on tree reconstruction logic.
- Quick isolation of layout conflicts.
- Regex refinement against real data.
- Style adjustments without fighting CSS for hours.
- Immediate debugging of runtime errors.
Instead of spending half a day navigating documentation and edge cases, iteration cycles collapsed into minutes. The mental overhead shifted from syntax and boilerplate to decision-making and validation.
The AI did not replace engineering judgment. It removed friction from the mechanical parts of engineering.
That difference matters.
Why This Matters for Indie Developers
Indie teams rarely have dedicated build engineers or internal tools departments. The same person building gameplay systems is also responsible for packaging, optimisation, distribution, and infrastructure.
When the build size increases, the cost is not just disk space. It affects:
- Patch sizes.
- Download times.
- Platform constraints.
- Player perception.
- Hosting costs.
And without tooling, you cannot manage what you cannot see.
A simple visualisation tool can prevent weeks of silent bloat. It can reveal disproportionate asset growth early. It can expose compression inefficiencies. It can highlight organisational drift.
In other words, it gives you leverage.
Leverage is what allows small teams to compete.
The Broader Pattern
Every game project eventually becomes a complex system of systems. Content, code, art, build pipelines, data, packaging, compression — all interacting.
If you do not invest in internal visibility tools, complexity will compound faster than your ability to reason about it.
This tool will never be player-facing. No one will download it from Steam. It will not appear in a trailer.
And yet, it might save more development time than a minor gameplay feature ever could.
That is the paradox of tooling.
Closing Thought
Indie development is often romanticised as creativity under constraint.
In reality, it is structured problem-solving under constraint.
Sometimes the most valuable feature you can build is not for your players, but for yourself.
Because clarity scales.
And flying blind does not.
