You're three hours into building a level. You need a barrel. You know you own at least four barrel packs, because you bought them in three different bundle sales and one of them was "a steal". Finding them means leaving the editor, opening a file browser, and digging through folders called Downloads (2).

Meanwhile there's an AI assistant sitting in your editor that can write a state machine in eight seconds but has no idea what's on your hard drive.

AssetHoard is a local-first desktop asset manager for indie game developers and digital artists, and version 0.2.3 fixes that with a built-in MCP server. This post covers how we built it, why it's locked down the way it is, and the things we've found it genuinely useful for.

What MCP is, briefly

The Model Context Protocol is an open standard for letting AI tools call other programs. A program exposes a set of named tools with typed arguments ("search", "export", "create_bundle"), and any MCP client (Claude Code, Cursor, VS Code, Windsurf, Claude Desktop) can discover and call them.

For an asset manager that's a natural fit. AssetHoard already knows every model, texture, sprite and sound you own, what's in which bundle, what it's tagged, and what each file depends on. MCP lets your assistant ask it.

The decisions that shaped it

Built into the app, not a separate program

The obvious shortcut would have been a little standalone server that opens AssetHoard's SQLite database and reads it directly. We didn't do that, for two reasons.

First, two programs writing to one SQLite file is how you end up with a corrupted library and a very bad afternoon. Second, the app would never find out about changes. You'd ask your assistant to tag forty rocks and the open window would keep showing them untagged until you restarted.

So the server runs inside AssetHoard itself, and the app has to be open for it to answer. That turned out to be a feature: every change the assistant makes shows up in the window straight away.

Living inside the app also means you stay in charge of it from the app:

• Turn it on and off. One switch in Settings > MCP Server. It's off until you flip it, and a plug icon sits in the toolbar whenever it's running, so you're never guessing.
• See what changed. When an assistant exports files or edits your library, AssetHoard shows a notification in the app saying what it did, and the settings page keeps a list of recent calls.
• Decide how much the assistant can do. Out of the box it can only search, look and export. Changing your library needs "Allow write tools" switched on, and importing files pops up a prompt you have to approve. If you'd rather keep it read-only forever, just leave the write switch off.

One rule: MCP never touches the database directly

The MCP code lives in its own module, and it isn't allowed to call app commands or SQL. Everything goes through a small internal library API that sits underneath both the UI and the MCP server.

That sounds like bureaucracy, but it's what makes the write tools trustworthy. When an assistant moves an asset into a bundle, it runs exactly the same function as when you drag it there yourself. Same validation, same audit log, same undo entry. There's no second, slightly different code path quietly drifting out of sync with the real one.

It also makes adding a tool cheap. A new tool is a typed argument struct (whose doc comments become the descriptions the model reads) and a thin method that calls the library API. The interesting logic stays in one place and gets tested once.

Rust, rmcp and streamable HTTP

AssetHoard's backend is Rust, so we used rmcp, the official Rust SDK for MCP, with its streamable HTTP transport mounted on axum. Database work runs on blocking worker threads so a big search never stalls the app's async runtime, and each call is recorded in a recent-activity list you can watch in Settings.

We picked HTTP over stdio because the server lives inside a desktop app that's already running. Claude Code, Cursor, VS Code and Windsurf all connect to a local HTTP endpoint with a header, which is a one-line setup. Claude Desktop is the odd one out: it only launches stdio servers, so for now it connects through the mcp-remote bridge.

A fixed port, on purpose

The server listens on port 47823 by default. You can change it, but AssetHoard will never pick a different one on its own if that port is busy. Auto-switching sounds helpful until every client config you've written silently stops matching. Instead, a taken port shows up as an error with a readable message, and you choose what to do.

Making it safe to leave on

A local server that can read your files and write to your library deserves some paranoia. Here's what's in place:

• Off by default. You turn it on in Settings > MCP Server.
• Local only. It binds to 127.0.0.1, so nothing on your network or the internet can reach it.
• Token required. Every request needs a bearer token: 48 random hex characters, compared in constant time. Regenerating it disconnects every client.
• Browsers are refused. Any request with an Origin header is rejected, and the Host header must be a loopback address. Browsers always send Origin; CLI and IDE clients don't. This blocks DNS rebinding, where a malicious web page tries to talk to a server on your machine, and it's what the MCP spec asks local servers to do.
• Write tools are a second opt-in. "Allow write tools" is a separate toggle, and it's checked on every call, so switching it off takes effect immediately, even for clients that are already connected.
• No deleting your stuff. There are no tools for deleting assets or bundles. The only deletes are for categories nothing uses and projects that are already empty.
• Exports never overwrite. If a file already exists at the destination, it's skipped and reported.
• Imports ask first. When an assistant wants to import a folder, AssetHoard pops up a prompt with the path, file count, size and target bundle, and flashes the window. No answer within 60 seconds counts as no. If you trust your setup, "Import without asking" turns this off.
• Everything is undoable. Writes go on the normal undo stack with an MCP: label, like MCP: Moved 1 asset into 'Rocks', and a toast tells you what changed. Ctrl+Z (Cmd+Z on a Mac) works exactly as it does for your own edits.

A plug icon appears in the toolbar whenever the server is running, so you always know it's on.

Small things that made a big difference

Search returns text, thumbnails are separate. Search results are ids, names, types, paths and tags, which keeps them small. If the assistant wants to actually look at something, it calls get_thumbnail and gets a preview image of at most 256 pixels. That means it can check that the "mossy rock" really is mossy before suggesting it, without flooding its context with every result's picture.

Dependencies come along. Exporting a model brings its textures. Exporting a Godot .tres brings the files it references, and Unreal assets bring theirs. Exporting a whole bundle keeps its folder layout. Assets inside zip archives or .unitypackage files are pulled out first.

Clickable links. Every asset, bundle and project the server returns includes an assethoard:// link. The assistant can hand you a link, you click it, and AssetHoard jumps to that item. We added the link scheme to the app specifically for this.

Errors the model can read. An unknown id, a bundle inside a package, or write tools being switched off all come back as plain error messages rather than protocol failures, so the assistant can explain what happened or try something else.

What you can do with it

Here's what this looks like in practice. These are the kinds of things you'd type into Claude Code, Cursor or similar with AssetHoard running.

Set dressing without leaving the editor

"Find three different barrel models and a wood texture that matches, and copy them into Assets/Props."

The assistant searches your library, looks at the thumbnails of the best few, picks a set and exports them, textures included. You keep building the level. This was the main use case we designed for, and it's the one in the demo video.

Search by what it looks like, not what it's called

"Do I have any mossy stone wall textures?"

Search works the same way as AssetHoard's search bar: by name with typo tolerance, and by meaning when semantic search is turned on. Since 0.2.3 that includes embedded audio metadata too, so "glass shatter" can find SFX_0472_FINAL.wav if that's what its description says.

Narrow it down like you would in the app

"Show me Godot UI sprites from my Kenney bundle."

Results can be filtered by file type, asset class, engine, tag, category or bundle. The assistant works out the bundle id itself and filters inside it.

Drop a whole tileset into a project

"Copy my 'Dungeon Tileset' bundle into the Godot project at C:/dev/crawler."

The bundle's sub-bundles become folders in the destination, so the structure you set up in AssetHoard carries over.

Tidy up the library (write tools on)

"Make a bundle called 'Rocks' under 'Environment', move every rock model into it and tag them 'nature'."

The assistant creates the bundle, searches, moves and tags. Each step appears live in the app and is its own undo entry. If it gets carried away and moves a boulder that was actually a potato, Ctrl+Z.

A slower but satisfying variation: "Find the untagged textures in my Downloads bundle, look at each one and suggest tags." Review the suggestions, say yes, and let it apply them.

Keep track of what a game uses

"Start a project called 'Crawler' and add the dungeon tileset and the footstep sounds to it."

Projects in AssetHoard only record references. Nothing moves, and an item can belong to several projects. Once a project is set up, you can ask questions like "list everything in Crawler and tell me which assets have no licence recorded", which is a much nicer way to find out before release than after.

Onboard a new pack

"Import C:/Users/me/Downloads/kenney_platformer-pack into my Kenney bundle, then categorise the new assets by type."

AssetHoard asks you to allow the import, runs it through the normal import queue with the usual progress notification, then the assistant categorises what came in. The whole import is one undo entry.

What's next

The main gap right now is Claude Desktop needing the mcp-remote bridge. A small native shim that lets it connect directly is on the list. We'd also like to hear what you end up using the server for, because the tool list was shaped by our own workflow and yours is probably weirder.

Try it

The MCP server is in AssetHoard 0.2.3 and later. Open Settings > MCP Server, switch it on, and paste the setup command into your client. The MCP docs cover each client, and the tool reference lists every tool and its arguments. AssetHoard is free to download during the open beta, so the only thing it'll cost you is finally finding out how many barrel packs you own.

The AssetHoard Team

Every solo dev I know has hit the same wall. The first few weeks of a project are electric. You can see the whole thing in your head, the ideas won't stop coming, and you'd happily skip meals to keep building. Then, somewhere around week six or month three, the electricity goes out. The work is still there. The excitement isn't.

This isn't a character flaw and it isn't a sign you picked the wrong project. It's the shape of every long piece of solo work. You will not feel motivated all the time, because nobody does. What you can do is build something that keeps you moving when the motivation is gone.

The short version

If you only take a few things away, take these. The rest of the post unpacks each one.

• Stop waiting to feel motivated. Build habits that still produce something on a flat day.
• Shrink the next task until it's almost embarrassingly small, then start there.
• Set a daily minimum you can hit even on your worst day, and protect the streak.
• Keep a visible record of what you've finished, on screen or on paper.
• Beat isolation on purpose: find other devs, post devlogs, get one person to hold you to it.
• Compare yourself to last month's you, never to someone else's finished game.
• Treat rest, food, exercise and people as part of the schedule, not a reward you earn.

Motivation is a bad thing to depend on

Motivation is a feeling, and feelings come and go for reasons you don't control. You slept badly. The bug you spent all day on wasn't the real bug. Someone posted a screenshot of their game that made yours look like a student project. Any of those can flatten your drive for a day, and if your ability to work depends on feeling driven, you've just lost a day.

The developers who finish things have arranged their work so that a flat day still produces something. They've quietly stopped asking "do I feel like working" and started asking "what's the next small thing I said I'd do".

Shrink the task until it's stupidly small

When you can't face the work, the task in your head is almost always too big. "Build the inventory system" is not a task, it's a project, and staring at it does nothing but make you tired.

The fix is to shrink the next step until it's almost embarrassingly small. Not "build the inventory system" but "add one slot to the inventory grid". Not "do the audio pass" but "wire up the sound for the door opening". A task you can picture finishing in twenty minutes is a task you can start, and starting is the whole problem. Momentum almost always shows up once you're moving, it just refuses to show up beforehand.

On genuinely bad days, shrink it further. Open the project. Read the code you wrote yesterday. That's allowed to be the whole session. More often than not, once the file is open you'll fix one small thing, and one small thing is infinitely more than zero.

Set a daily minimum you can hit on your worst day

Pick a floor. Something so small that you'd feel silly not doing it even when you're exhausted or fed up. Fifteen minutes. One commit. One asset placed. One line of design doc.

The output barely matters. What the minimum protects is the streak. A chain of tiny days keeps the project alive in your head and stops the restart cost from piling up. If you skip a project for a fortnight, coming back costs you an afternoon just remembering where you were. If you touched it yesterday, you're already warm.

Some days you'll hit the minimum and stop, and that's fine. Plenty of days you'll hit the minimum and then keep going for two hours because you were never really tired, you were just staring at something too big. The minimum only has to get you to the desk. Most of the time, once you're there, you keep going.

Make progress visible, because your brain won't do it for you

The cruel thing about the middle of a project is that progress stops feeling like progress. The exciting, visible milestones are behind you and ahead of you, and the middle is a thousand small tasks that don't individually look like much. Left alone, your brain will happily conclude you've done nothing for a month.

So don't leave it alone. Keep a record it can't argue with. A "done" list you actually add to, a devlog you post every week whether or not anyone reads it, a folder of dated screenshots you can scroll back through. When the doubt shows up, you want evidence sitting right there. The version of your game from three months ago is the proof, and if you never captured it, the doubt wins by default.

None of this has to happen in front of a computer either. Grab a notebook and sketch the inventory system you've been putting off. Scribble down a world-building idea before it evaporates. Draw the level on graph paper. A page of notes from a walk is still a record of a day you moved the project forward, and some days it's the easiest kind to make.

This is one place a bit of tooling earns its keep. Being able to scroll back through what you've built, the sprites you've drawn, the models you've made, the packs you've assembled, is a quiet antidote to the feeling that you're standing still. Half the time you're much further along than it feels. (It's a big part of why I organise my asset library so I can actually see it.)

Isolation is the real enemy, not the work

The work is rarely what breaks people. Working entirely alone for months is what breaks people. No colleague to tell you the idea's good. Nobody to notice you shipped the thing. No standup where you say out loud what you did yesterday and quietly realise it was quite a lot.

You have to manufacture what a team gives you for free. Find a Discord of other solo devs (the AssetHoard Discord is one) and actually turn up in it. Post your devlog even to an audience of nine. Tell one friend what you're shipping this week so there's a human who'll ask how it went. Pair up with another dev and trade weekly check-ins. None of this is marketing. It keeps the work real to someone other than you. Externalising your progress to even one other person changes how the work feels, because suddenly you're not the only one who knows it exists.

If in-person is an option, take it. A monthly indie meetup or a game jam can reset your whole outlook in an afternoon, mostly by reminding you that everyone else is also stuck on something and doubting themselves too.

Stop comparing your middle to someone else's end

The screenshot that ruined your afternoon was a finished, polished, cherry-picked frame of someone else's months of unglamorous work. You compared it to your actual Tuesday, bugs and placeholder art and all. Of course you lost.

Everything you see online is a highlight. The trailer, the launch post, the "we hit a thousand wishlists" thread. You don't see the fortnight they spent fighting the same engine bug you're fighting, or the three redesigns they binned, or the week they didn't open the project at all. Comparison isn't just unkind to yourself, it's inaccurate, because you're missing most of the data.

The only honest comparison is you against you. Are you further along than last month? Then it's working.

Protect your life, not just your rest

A lot of solo devs treat rest as a reward they have to unlock by working hard enough, which means they never quite unlock it, which means they run flat out until they crash. Then they lose two weeks to burnout and call themselves lazy for it.

Rest isn't earned, it's part of the schedule. So is eating well, exercising, and spending time with friends and family. None of that is what you do once the real work is finished, it's the space that lets you recharge between sessions of the real work. Build it in on purpose. Take one full day off a week and don't touch the project. Stop at a set time most evenings. Go outside. The ideas that untangle your worst problems almost never arrive while you're grinding at the desk, they turn up in the shower, on a walk, doing the washing up. A rested brain is a faster brain, and a burned-out one ships nothing at all.

Burnout is not a badge. It's a project risk, and it's your job to manage it like any other.

What it actually takes

Staying motivated as a solo dev is mostly a matter of not needing to be motivated. You build small habits, you make your progress visible, you find a few humans to be accountable to, you rest before you're wrecked, and you keep comparing yourself only to yesterday's version of yourself.

Do that, and the flat days stop being a threat. They become just another Tuesday where you hit your minimum, close the laptop, and come back tomorrow. The people who finish games aren't superhuman. They just kept turning up through the boring middle, one small task at a time, until the finish line quietly showed up.

Keep turning up.

The AssetHoard Team

Hero photo by JC Gellidon on Unsplash.

Welcome back to our Artist Spotlight series, where we chat with creators in the game dev space about their work, their process, and what they've learned along the way.

This time we're talking to James Rommel G. Lobaton, a 2D and 3D game animator from the Philippines with ten years in the industry, a Unity Asset Store shop, and a portfolio that swings happily between Dota 2, fighting games, horror icons and anime.

For readers who haven't come across your work yet, what do you do?

How did you end up working across both 2D and 3D, and was game development always the goal?

I started late on this path. Before animation I was a delivery guy, delivering special welding rods to industrial companies. Animation is my second chance.

I studied a vocational 3D animation course, and from there I threw myself into learning everything about 3D, trying to be a one-man army. While I kept studying 3D, I was also learning Photoshop and basic 2D drawing.

Then I got the opportunity to work at a game dev studio as a 3D animator. As the project went on we ran into trouble: they couldn't integrate 3D characters into a 2D environment. That's where the switch happened. I needed to learn Spine, and that's how I became a 2D/3D animator.

My teacher in the industry was into games, so all of my practice was for games. Dota 2 inspired me a lot too. So yes, I love game dev.

Your portfolio mixes Dota 2, fighting games, horror icons and anime. What shaped your style?

I've loved comics since I was a kid. I love the sharp black lines and big buckets of black against vibrant colours. Since starting on this path, I've always practised my drawing, starting with chibi characters. The style has stayed the same: black line art and cool, vibrant colours.

Games that influenced me are Hades, Borderlands, Skullgirls and Darkest Dungeon. For artists, it's Mike Mignola, Ludo Lullabi and Todd McFarlane. They're brilliant artists, and I love how unique their work is. There's so much energy in their drawings. It keeps my fire going.

And what are you drawn to right now?

I still practise and develop my style digitally, but right now I'm also doing traditional painting and drawing on the side. I love going back to watercolour, gouache and acrylic, with some oil pastels too. It's my way of not burning out, because I'm always doing something different.

On projects like Into the Crypt you animated characters drawn by another artist. How do you approach that?

Before I take a commission, I always check whether I can do cutouts in the other artist's style. I use Spine, so I need to cut the art into parts. That's why I don't take on realistic art: it's hard for me to fill in the missing parts of the drawing.

Take us through a typical commission, like the Bone Dragon boss. What happens between the brief and the final files?

First, the client sends all the details about the boss monster. Then I create different silhouettes, pick the ones I like and add detail. At this stage it's all sketches.

I send those to the art director so they can choose one and ask for adjustments. Then it comes back to me to polish. When everything is signed off, I start doing the cutouts for the Spine animation. The final files are delivered in a folder at the end.

What does your toolkit look like for 2D and 3D work?

I use Photoshop and Procreate for 2D, and Maya or 3ds Max for 3D, though I'm practising Blender now.

A rough animation test: the figure is drawn frame by frame in red line, with the frame numbers pencilled in.

Why Spine for game animation?

It's a very strong piece of software for quick 2D animation. It's built for games, it keeps getting better with every update, and it's a one-time payment. Spine is probably the tool I couldn't work without. It's a big part of my commission work.

Between client work, fan art and challenges like Inktober and Swordtember, how do you keep your files organised?

Staying organised is a pain. You have to name things correctly or you'll waste time looking for your files. I keep my files on Google Drive and my PC, and I name them after the game or the customer.

My biggest pain point is not having enough space on my PC's drive.

(We may know a thing or two about that one. Here's how we keep 100,000 game assets findable.)

What do you wish indie developers knew before commissioning an animator?

Know what you want first: what type of game, what animation style, what art style. Always have references. And always communicate. The faster the reply, the better.

James's character process: silhouettes first, then colour roughs, then the final character animated.

See more of James's work, or get in touch about new projects:

• ArtStation
• Instagram
• LinkedIn

This is part of our Artist Spotlight series. If you're a game asset creator and want to be featured, get in touch at mark@assethoard.com.

Free 2D game assets are everywhere, but the ones you can actually ship are harder to find. Half the packs you come across are free to download and not free to use, and the licence is usually buried three clicks deep or missing entirely. This is our running roundup of the free 2D game asset sources we keep coming back to, updated through 2026 (last refreshed September 2026).

A quick word before the list: free does not mean unrestricted. Most of these allow commercial use, but the exact terms vary by site and sometimes by individual asset, so treat every link below as a starting point and confirm the licence before you put anything in a build you intend to sell.

If you'd rather skip the hunt, we keep a curated directory of free CC0 assets, filterable by type, style, and engine, with every licence checked so you can grab something and get back to building.

Start with the classics

If you have never gone hunting for free assets before, start with the names every game developer already has bookmarked. These are the obvious, always-recommended ones, and they cover an enormous amount of ground on their own.

• Kenney - thousands of assets covering 2D sprites, tiles, and UI, plus 3D and audio, all released as CC0. Public domain, no attribution, commercial use fine. If you only ever use one source, make it this one.
• itch.io game assets - the biggest indie marketplace has a deep free section full of sprite packs, tilesets, and UI kits. Licences are set by each creator, so read the terms on the page before downloading.
• OpenGameArt - a long-running community library of free 2D and 3D art under a mix of open licences. Quality varies, but there are gems, and the licence is always stated on the asset page.

The rest of this list covers the more specialist and less obvious sources worth knowing.

What we looked for

• Genuinely free, not a paywalled "free" teaser for a paid pack
• A licence you can actually read and live with, ideally allowing commercial use
• Quality that holds up next to paid work
• Formats you can drop straight into a 2D project (PNG sprites, SVG, tilesets)

At a glance

A quick comparison to help you filter. "Commercial" is whether you can use the assets in a paid or ad-supported game, and the licence column is a summary only, so always confirm the terms on the specific asset before you ship.

The picks

Pixabay 2D games

A broad stock library that can fill gaps for backgrounds, textures, and reference art. The Pixabay Content Licence is generous: no attribution required and commercial use allowed, though you cannot sell unmodified content on its own, and anything featuring recognisable brands or people is off limits for commercial work. Pixabay has also had issues with copyright and AI-generated content slipping into the library, so double-check the source of anything before you use it.

Link: Pixabay 2D games

GameDev Market free 2D backgrounds

GameDev Market is a paid marketplace with a rotating free section, and its background packs are a good source of parallax layers and scene art. Licensing is set per asset rather than site-wide, and some free downloads sit behind a Pro membership, so open the asset page and read its licence panel before you commit to using it in a project.

Link: GameDev Market free 2D backgrounds

Super Game Asset free assets

Best known for its polished RPG item and skill icons. The free section is mostly sample sets offered as a taste of the paid collections, downloaded through a free account. The art quality is high, but because these are samples, read the site's licensing FAQ so you are clear on where the free tier ends and a purchase begins.

Link: Super Game Asset free assets

Unlucky Studio free game art

A well-organised stash of 2D art covering character sprites with animation, UI kits, backgrounds, weapon packs, RPG item icons, fantasy monsters, and vehicles. The studio states its free downloads can be used commercially, though attribution expectations can differ from one pack to the next, so check the individual post you are downloading from.

Link: Unlucky Studio free game art

SVG Repo

A huge searchable library of vector icons and illustrations, useful well beyond games for menus, tools, and marketing. The catch worth knowing is that assets come under a mix of licences (CC0, MIT, CC BY, and others), and each entry is tagged individually. Filter by licence and check the one on the asset you want, because "free to download" here does not automatically mean attribution-free.

Link: SVG Repo

Game-icons.net

The first place to look for UI and ability icons. It hosts over 4,000 game icons covering weapons, creatures, buildings, status effects, and abstract symbols, all available as both SVG and PNG with colour variations bundled in. The whole collection is CC BY 3.0, so commercial use is fine as long as you credit the authors. The vector format means you can recolour and scale everything to match your HUD without quality loss.

Link: Game-icons.net

Reiner's Tilesets

A veteran resource that has been giving away game art for decades. You will find 2D sprites (animals, monsters, buildings, vehicles), a large set of 3D models, and close to 300 tiling textures for walls, ground, wood, and stone. Reiner has long offered these on generous free-to-use terms including commercial projects, but the exact conditions live on the site's licence page, so read them before shipping.

Link: Reiner's Tilesets

Clip Studio Assets

The asset marketplace built into Clip Studio Paint, full of brushes, textures, tones, 3D props, and pose references. It is the right place to look if you create your art in Clip Studio, since much of it is designed to be used inside the app. If you plan to use assets elsewhere, check the individual asset's terms, as usability outside Clip Studio Paint is not guaranteed.

Link: Clip Studio Assets

Square Assets free collection

A small game-art store with a free collection sitting alongside its paid packs. Worth a look for clean, consistent 2D sets, but because it is a storefront, the free items each carry their own terms. Read the licence on the item page before downloading.

Link: Square Assets free collection

Pngtree 2D assets

An enormous general-purpose library of PNGs and graphics with a deep 2D search. Treat it with caution: the free tier typically requires attribution and has daily download limits, full commercial rights are often gated behind a paid plan, and like any large stock site, the occasional mislabelled or AI-generated item slips through. Verify the source and licence of anything you pull from here.

Link: Pngtree 2D assets

GameArt2D freebies

A tidy set of ready-to-use 2D game art: character sprites (a platformer plumber, ninjas, zombies, a knight, and more), themed tilesets covering platformer, winter, desert, sci-fi, and graveyard, and a range of GUI packs. The free assets are released as CC0, so there are no restrictions and no attribution, and they are fine for prototyping, game jams, and commercial projects alike.

Link: GameArt2D freebies

CraftPix freebies

One of the largest free 2D libraries around, with sprites, tilesets, GUI, icons, backgrounds, and full game kits added regularly. A free account is needed to download. Commercial use is allowed with no attribution required, but you cannot redistribute or resell the raw art files, and the licence forbids using the assets to train AI or machine-learning systems.

Link: CraftPix freebies

A note on licences

This is the part that trips people up. Free does not always mean unrestricted, and the difference between "CC BY" and "free for personal use only" is the difference between a safe launch and a takedown notice. Before you ship, confirm three things for every asset: is commercial use allowed, is attribution required, and can you modify it. Write the answer down somewhere that stays attached to the file, not in a browser tab you will lose by next week.

This is exactly the problem AssetHoard is built to solve. Every asset carries its own licence field, and when you import, AssetHoard will try to detect a bundled licence file and fill it in for you, with a manual override when it gets it wrong. The terms travel with the asset instead of living in your memory, so six months from now you still know whether that icon pack needs a credit line.

Wrapping up

That is the current list. We keep this page updated as sources come and go, so bookmark it and check back. When you have pulled a few packs together, download AssetHoard to keep them organised and their licences on record before the collection gets away from you.

A bundle turns up on Humble for twelve dollars: forty asset packs, a couple of hundred thousand files between them. You buy it without thinking twice, because a single character pack at full price would cost more than the whole thing. That maths holds up. I've never met anyone who regretted the purchase.

What people regret is the Tuesday six weeks later, when they need one stylised tree for a forest scene and know for a fact they own about nine hundred of them, somewhere.

What actually lands on your drive

When the bundle unlocks you get forty or fifty zip files, named however each creator felt like naming them. LowPolyNature_v2_FINAL.zip. pack3.zip. Kenney_Assets.zip, which is 140,000 files on its own. One has a .unitypackage in it and nothing else. Another is raw .fbx and .png. A third has a Godot addon folder, a set of .uasset files, and a readme explaining which is which. Two of them are the same assets from the same artist, uploaded twice under different version numbers.

Nothing shares a structure. One creator sorts by biome, another by polygon count, a third tips everything into an Assets/ folder and leaves it there. Forty packs, forty ideas about how a library should be laid out, and none of them match yours.

Why folders don't cut it here

For your own project files, a folder structure works fine. For a bundle haul it doesn't, and the reason is simple: you can't see into a zip without opening it.

To find out whether pack3.zip has the tree you want, you unzip it and look. Do that fifty times and you've lost an afternoon. So most people open two or three, take whatever is close enough, and leave the rest sealed. The bundle becomes a folder you feel slightly guilty about every time you scroll past it.

The packs you do unzip cause the opposite problem. Now there are 200,000 loose files, your file explorer stalls trying to draw thumbnails, and searching by name only helps if you already remember what the artist called the thing. tree_04_var_b.fbx isn't much of a search term.

A better default is to index the archives without extracting them: read the manifest, pull out the previews, leave the zip where it is. The haul stays compressed on disk and still becomes searchable.

The engine problem

This is the bit that trips people up, and most advice skips it because most advice assumes you only work in Unity.

Plenty of us don't. You might prototype in Godot, take a contract in Unreal, still have a GameMaker project from last year, and get Blender files from an artist friend. So the same tree can sit in your library as a bare .fbx in one pack, wrapped in a .unitypackage in another, as a .tres resource in a Godot addon, and as a .uasset you can't open outside the editor that made it.

Four formats, one tree, and most search tools understand none of them. Unity-only tools read the .unitypackage and ignore the rest. Generic file browsers treat the four as unrelated blobs. So you end up buying assets you already own, because you had no way to tell you owned them.

What helps is a catalogue that reads the formats properly: it opens a .unitypackage, walks a Godot .tres resource graph, handles .yymps and .uasset, and files all of them as the same kind of thing. The engine that wrapped the tree stops mattering.

What "findable" actually means

Once you're a few thousand assets in, "organised" isn't really the goal any more. Findable is, and it comes down to four things.

Seeing it. A cached thumbnail, generated once. Most asset hunting is visual anyway; you rarely remember the name, but you remember what it looked like.

Describing it. Name search fails because you're searching your memory of the asset, not the artist's naming scheme. Semantic search over the previews lets you type "gnarled dead tree" and find it even when the file is called T_04b.

Narrowing it. Tags you picked, rather than the folder someone else picked. The same asset can sit under "trees", "stylised", "mobile-safe" and "that Humble bundle" at once.

Shipping it. The licence travelling with the asset, instead of sitting in a readme inside a zip you've since deleted. CC0, CC-BY with attribution, the Asset Store standard licence. It's easy to ignore until the day you ship commercially, and then it matters a great deal.

A quick pass for a new bundle

Before you open a project, try this.

1. Download the lot into one folder. Don't unzip, don't sort.
2. Point your catalogue at the folder and let it index, overnight if it needs to. Fifty opaque zips become a set of previews you can actually look through.
3. Skim the results once, quickly. You're not organising, just getting a rough sense of what came in.
4. Tag the standouts and nothing else. Twenty minutes, maybe thirty assets. The rest stay findable by search, which is enough.
5. Flag anything with an unusual licence. It's the one step that gets expensive if you skip it.

No folder hierarchy, no naming convention, no promise to sort it properly at the weekend. A bundle is cheap and broad, and that only pays off if you can search it.

The real cost

The bundle cost twelve dollars, so it feels like it cost twelve dollars. It didn't. It also cost the twenty minutes at the start of a session spent hunting for something you own, the asset you bought a second time at full price because you'd forgotten, and the scene you built with a placeholder cube because finding the real prop was more hassle than shipping the cube.

An asset you can't find isn't doing much for you. It's just disk space.

AssetHoard is a local-first desktop asset manager built for exactly this pile. It indexes archives without unpacking them, reads Unity, Godot, Unreal and GameMaker formats as first-class citizens, generates previews, and lets you search by what things look like rather than what they were named. It runs entirely on your machine, and it's a one-time purchase, not a subscription.

The next bundle you buy is only cheap if you can find what's in it. Download AssetHoard and point it at the pile.

Hero photo by Kadarius Seegars on Unsplash.

Where Godot vs Unity is a fight about lightness and ownership, Unreal vs Unity is a fight about ambition and scale. These are the two engines most likely to power something with a big 3D world, and they pull in noticeably different directions.

If you are still deciding whether either belongs on your list at all, the first-engine guide is the better starting point. If it's these two on the table, here is how they actually compare.

The short version

Unreal is the fidelity powerhouse, the engine studios reach for when they want photoreal lighting, vast detailed worlds, and visuals that make players ask whether they are watching a game or a film. Unity is the versatile all-rounder, lighter to run, faster to iterate in, and dominant on mobile and in 2D.

Pick Unreal for cutting-edge 3D and cinematic ambition. Pick Unity for mobile, 2D, rapid iteration, and a gentler road in. Now the detail.

Visual fidelity

This is Unreal's headline act. Its modern rendering feature set, including its dynamic global illumination and virtualised geometry systems, lets small teams produce visuals that used to require a large studio. Out of the box, for high-end 3D, it looks stunning.

Unity is very capable in 3D and its render pipelines have matured a great deal, but matching Unreal's top-end fidelity takes more manual effort. For photoreal or graphically ambitious work, Unreal starts you closer to the finish line.

Edge: Unreal.

Iteration speed and footprint

Unity is lighter. It installs smaller, opens faster, and its edit-play loop tends to feel snappier, which matters enormously when you are testing an idea for the hundredth time in an afternoon. That responsiveness is a real, daily productivity advantage, especially on modest hardware.

Unreal is a large engine with a heavier footprint, and its power comes with weight. On a capable machine it's fine; on an older laptop it can feel sluggish.

Edge: Unity.

Scripting

Unreal offers two routes: Blueprints, a powerful visual scripting system you can build entire games in without writing code, and C++ for performance-critical or lower-level work. Blueprints are a real strength and lower the barrier for non-programmers, though C++ is a demanding language once you drop into it.

Unity uses C#, which sits in a comfortable middle ground: more approachable than C++, more transferable than a visual system, and backed by a huge body of learning material. For most solo developers, C# is the more forgiving day-to-day language.

Edge: Unity for approachability, Unreal for the visual-scripting on-ramp and raw ceiling. Depends on how you like to work.

2D and mobile

Unity is the clear choice here. It has mature 2D packages, the deepest mobile toolchain of any major engine, and by far the widest third-party support for the ads, analytics and monetisation that mobile games live on.

Unreal can do 2D and mobile, but it is swimming against its own current. Its whole design centre of gravity is high-fidelity 3D, and smaller or mobile projects usually ship leaner in Unity.

Edge: Unity, decisively.

Ecosystem and assets

Both have substantial marketplaces and large communities. Unity's Asset Store is broader and especially strong for 2D, mobile and mid-scale 3D. Unreal's marketplace skews toward high-end 3D content, and Epic has a history of giving away large quantities of professional assets to Unreal developers.

Call this one close, weighted by what you are making: Unity for breadth, Unreal for high-fidelity 3D content.

Edge: Draw, project-dependent.

Pricing and royalties

The models differ in shape. Unreal is free to use and takes a royalty on gross game revenue above a threshold. Unity is free on its Personal tier and moves to paid subscriptions above revenue and funding limits.

Neither model is strictly cheaper; it depends on your revenue profile. And both companies have adjusted terms in recent years, so treat any specific figure you read, including here, as a prompt to check the current terms yourself before you commit.

Edge: Depends on your numbers. Read the current terms.

So which one?

• Choose Unreal if: you are building ambitious 3D, you want the best-looking visuals with the least manual effort, you like Blueprints, or you are aiming at the kind of fidelity studios ship.
• Choose Unity if: you are targeting mobile, you are doing 2D, you want faster iteration on lighter hardware, or you want a gentler entry into 3D.

For a first project, be honest about scope. Unreal's ceiling is glorious, but a small game rarely needs it, and the weight can slow you down more than the fidelity helps. Many developers are better served starting lighter and reaching for Unreal when a project truly demands it.

What both engines have in common

Whichever way you lean, the project will fill up with assets: models, textures, materials, audio, the professional packs both marketplaces hand out. That library is the part of your work that outlives the engine decision, because art and audio are just files while your Blueprints and C# are not.

AssetHoard is a local-first asset manager that keeps that library previewable and organised in one place, sitting beside whichever engine you choose. It handles the models, materials and textures these 3D-heavy workflows generate, and reads native project formats from engines like Unity, so your collection stays tidy no matter which tool you build in.

More in this series: Godot vs Unity and GameMaker vs Godot.

Mark

Hero photo by Javier Allegue Barros on Unsplash.

The other comparisons in this series are 3D heavyweight bouts. This one is different. GameMaker and Godot are both superb 2D engines, and choosing between them is less about raw power and more about philosophy: pure specialism versus free-and-flexible.

If you are not yet sure a 2D-focused engine is what you want, the first-engine guide zooms out. If you have narrowed it to these two, let's settle it.

The short version

GameMaker has spent decades doing one thing extremely well: 2D games. Its track record is absurd for its size, with Undertale, Hyper Light Drifter, Katana ZERO, Nuclear Throne and Hotline Miami all built in it. Godot is the free, open-source all-rounder with a first-class 2D pipeline that also happens to do 3D.

Pick GameMaker for focused 2D with the smoothest no-code-to-code ramp. Pick Godot for a free, open tool that won't box you into 2D forever. Now the detail.

Licensing and cost

Godot is free and open source under the MIT licence. No tiers, no fees, no revenue share, no catch. You own it outright.

GameMaker offers a free tier to learn and build with, and paid options for commercial release and console export. Its pricing model has shifted more than once over the years, moving between subscription and other structures, so check the current terms before you plan a commercial launch.

Edge: Godot for simplicity and permanence.

2D workflow

This is the heart of the matchup, and it's a close one.

GameMaker's entire being is 2D. Its room editor, sprite tools and 2D-specific conveniences are refined by decades of focus, and the result is a workflow that just feels made for the job. For a lot of 2D developers, that specialism is exactly the appeal.

Godot's 2D is also first-class, built on a dedicated 2D renderer and node system rather than a 3D engine wearing a flat hat. It is flexible, clean, and extremely capable. There is no 2D game GameMaker can make that Godot cannot.

Edge: Too close to call. GameMaker for refined 2D-specific polish, Godot for flexible 2D power.

Scripting

GameMaker gives you a drag-and-drop action system and its own language, GML. The pairing is one of the best beginner ramps anywhere: build logic visually to get moving, then graduate into GML when you want more control, all without switching tools.

Godot uses GDScript, a game-focused language that reads almost like plain English and is tightly woven into the engine. It skips the visual layer but is itself a very gentle first language, and Godot also supports C#.

Edge: GameMaker for the visual-to-code ramp, Godot for a clean scripting-first experience. Your preference decides it.

3D

Not really a contest, because they are aimed at different things. GameMaker is 2D by design; it has some limited 3D capability, but nobody chooses it to make a 3D game.

Godot is a full 3D engine as well, and its 3D took a major leap in the 4.x releases. If there is any chance your ambitions drift into three dimensions, Godot means you will not have to change tools to follow them.

Edge: Godot, if 3D is ever on your horizon.

Track record and community

GameMaker's hall of fame is remarkable, and it is proof that a focused 2D tool can produce genre-defining hits in the hands of small teams. Its community and learning resources are mature and 2D-centric.

Godot's community is large, fast-growing and famously welcoming, its documentation is strong, and being open source it has an unusually engaged contributor base. Both are well supported; they simply attract slightly different crowds.

Edge: Draw.

So which one?

• Choose GameMaker if: you are certain you want 2D, you like the idea of starting with visual actions and easing into code, or you want a tool with a proven hit-making pedigree in your exact genre.
• Choose Godot if: you want a free and open toolchain, you might one day want 3D, or you prefer a clean scripting-first workflow with no licensing tiers to track.

You can't go far wrong with either. Both are beginner-friendly, both ship real commercial games, and both respect a solo developer's time. If you want to hedge toward flexibility, lean Godot. If you want to commit fully to 2D craft, lean GameMaker.

The library outlives the engine

Whichever you choose, you will gather a pile of assets: sprites, tilesets, sound effects, fonts, the packs you download and mean to use one day. That collection is the part of your work that survives any future engine change, because your art and audio are just files while your GML or GDScript is not.

AssetHoard keeps that library previewable, searchable and organised in one place, sitting beside whichever engine you pick. It reads native project formats from both GameMaker and Godot, previewing sprites, tilesets, sounds and fonts straight from your projects, so the same tidy library follows you whichever way this decision goes.

The rest of the series: Godot vs Unity and Unreal vs Unity.

Mark

Hero photo by Jacob Culp on Unsplash.

This is the matchup that launches a thousand forum threads, and most of them generate more heat than light. So let's do it properly: no tribalism, no "Unity bad" or "Godot cope", just a clear look at where each engine actually earns its place.

If you haven't yet decided whether you even want these two on the shortlist, start with the broader guide to picking a first engine. If Godot and Unity are already your two finalists, read on.

The short version

Godot is the lightweight, free, open-source challenger that has spent the last few years turning from "promising" into "actually good". Unity is the established heavyweight with the biggest ecosystem in the business and a decade of industry adoption behind it.

Pick Godot if you value owning your tools, you want the simplest 2D workflow, or you want the friendliest possible on-ramp. Pick Unity if you need its enormous asset and tutorial ecosystem, you are building anything ambitious in 3D, you are targeting mobile at scale, or you want skills for a studio job. Now the detail.

Licensing and cost

This is the cleanest difference, so we'll get it out of the way first.

Godot is free and open source under the MIT licence. There is no revenue share, no per-seat fee, no runtime charge, and no threshold at which it starts costing you money. You own your copy of the engine outright, source included.

Unity has a free Personal tier for developers under a revenue and funding threshold, and paid subscription tiers above it. The technology is excellent, but it is worth remembering that Unity spent 2023 announcing a per-install runtime fee that it later walked back after significant backlash. The fee is gone, but the episode is a fair reminder that a company-owned engine can change its terms in ways an open-source one cannot.

Edge: Godot, comfortably, if predictable licensing matters to you.

2D

Godot's 2D is not a 3D engine with a flat camera bolted on. It has a dedicated 2D renderer and node system, pixel-perfect tooling, and a workflow that feels purpose-built, so you can be productive on a straightforward 2D game very quickly.

Unity's 2D is stronger than its old reputation suggests. It has a mature 2D toolset, a real 2D lighting system with normal maps and shadows, and it can bring lit 3D meshes into a 2D scene for depth and dynamic lighting that flat sprites cannot easily fake. That opens up looks Godot makes you work harder for.

Edge: Narrow, and it depends on the game. Godot for the simplest, most direct 2D workflow; Unity if you want advanced 2D lighting or to blend 2D and 3D. You make a call on what you're after.

3D

Unity wins 3D outright, and it's not close. It has built-in terrain sculpting, mature mesh handling and in-editor modelling with ProBuilder, a deep animation stack with Timeline and Cinemachine for cinematics, face and motion capture through Live Capture, and high-fidelity rendering with HDRP. On top of all that sits the largest library of ready-made 3D assets and tutorials of any engine. For anything ambitious in three dimensions, that toolset is a real head start.

Godot's 3D took a big step forward in the 4.x releases, with a rebuilt renderer, global illumination and better tooling, and it can comfortably ship a commercial 3D game, especially a stylised or smaller-scope one. But the depth is not there yet: several of those Unity systems are plugins, manual work, or simply absent in Godot.

Edge: Unity, decisively.

Lighting, post-processing and shaders

If visual polish matters to you, this is worth a closer look, and it mostly favours Unity.

On lighting and post-processing Unity is well ahead, especially through its High Definition Render Pipeline. You get volumetric lighting and fog, screen-space reflections, ray-traced options, and a Volume-based post-processing stack (bloom, colour grading, depth of field, motion blur, ambient occlusion and more) that artists can tune without touching code. Godot 4 is no slouch, with real-time global illumination through SDFGI, baked lightmaps, volumetric fog, glow and tonemapping in its Environment settings, but the range of effects and the polish of the controls do not match Unity's.

Shaders are the closer contest. Both engines let you hand-write shaders, and both ship a visual, node-based shader editor, so the core capability is comparable. Godot's shading language is clean and well documented, and plenty of people prefer it. Unity pulls ahead on the maturity of its Shader Graph and, again, the sheer volume of ready-made shaders and effects on the Asset Store.

Edge: Unity for lighting and post-processing, clearly. Shaders are closer to a draw, with Unity ahead on tooling and the asset library.

Scripting

Godot's built-in language, GDScript, is designed for game development and reads almost like plain English. It's a forgiving first language, and its tight integration with the engine makes iteration fast. You can also use C# in Godot if you prefer, with one notable catch: C# projects cannot export to the web yet, whereas GDScript can.

Unity uses C#, a mainstream, general-purpose language that looks good on a CV and transfers directly to other software work. It is more verbose than GDScript and has a slightly steeper learning curve, but the payoff is broader applicability.

Edge: Godot for approachability, Unity for transferable career skills. Call it a draw that depends on your goals.

Editor extensibility

Both engines let you script the editor itself, not just the game, and this is one of Unity's quieter strengths. Its editor scripting API is deep: you can build custom windows, inspectors, property drawers and full in-editor tools, with two UI frameworks to build them in, the older IMGUI and the newer UI Toolkit. The Asset Store is then full of editor extensions built exactly this way, so a lot of the tooling you might want already exists off the shelf.

Godot has a proper plugin system too, and it is often underrated. Scripts marked with @tool run inside the editor, and EditorPlugin lets you add custom docks, bottom panels, inspectors and gizmos. Because the whole editor is open source, you can even fork and recompile it, which is a kind of editability Unity does not offer at all. What Godot lacks is the sheer API surface and the marketplace of ready-made editor tools that Unity has spent a decade building.

Edge: Unity, for the depth of its editor API and the ecosystem of existing extensions. Godot's plugin system is capable and its open editor is uniquely moddable, but the tooling ecosystem is far smaller.

The ecosystem

Here Unity wins decisively, and it is the single strongest reason to choose it. The Unity Asset Store is deep and battle-tested, almost any "how do I do X" already has a YouTube answer, and studios list Unity by name in job adverts more than any other engine. When you hit a wall, the odds that someone has already documented the way through it are simply higher.

Godot's community is smaller but famously friendly, its documentation is solid, and its asset library grows every year. For a beginner it rarely bites, but on a complex project the ecosystem gap is real.

Edge: Unity.

Mobile

Both engines export to iOS and Android. Unity has the deeper mobile story: more mature build tooling, better-trodden performance-optimisation paths, and far more third-party support for ads, analytics and monetisation. If mobile at commercial scale is your target, Unity is the safer bet today.

Edge: Unity.

So which one?

• Choose Godot if: you want the simplest 2D workflow, you are learning to code, you want a small fast tool, or you want a toolchain nobody can change the price of.
• Choose Unity if: you need its ecosystem, you are targeting mobile seriously, you want job-transferable C# skills, or you are building an ambitious 3D project and want the most assets and tutorials to lean on.

And if you truly can't decide, download Godot this afternoon. It costs nothing, installs in seconds, and you'll learn more from an hour of building than from a week of comparison tables like this one.

The part that survives whichever you pick

Whichever engine wins your shortlist, one thing is identical in both: you will accumulate assets. Sprites, models, audio, fonts, texture packs, the free bundles you grab and mean to use later. That pile grows fast, and it is the one part of your project that carries across unchanged if you ever switch engines, because assets are just files while code is not.

AssetHoard is a local-first asset manager that sits beside either engine and keeps that library previewable, searchable and organised in one place. It reads native project formats from both Godot and Unity, so the same library works no matter which side of this debate you land on, or if you change your mind later.

Next in the series: Unreal vs Unity and GameMaker vs Godot.

Mark

Hero photo by Jens Lelie on Unsplash.

It is the first question almost everyone asks, and it arrives loaded with more anxiety than it deserves. Choosing a game engine feels like choosing a tattoo. Permanent, public, and destined to be judged by strangers on the internet.

But it's not a tattoo. It's a pair of boots. You want ones that fit the terrain you're walking, they'll wear in over time, and if you truly hate them you can swap them for another pair without starting your life over. Every engine below has shipped games you've heard of. None of them will stop you making something good.

So instead of asking "which engine is best", ask three smaller questions that actually have answers: what am I making, where will it run, and how do I like to work. Everything else follows from those.

The three questions that matter

What am I making? A cosy 2D farming game and a first-person 3D horror game pull toward very different tools. 2D and 3D are the first fork in the road, and picking the engine built for your dimension will save you months of fighting the grain.

Where will it run? A game aimed at phones, consoles or the browser leans on very different tooling from a desktop-only one. If you already know you want to ship to mobile or the web, weight that heavily, because export support and performance on your target platform vary a lot from one engine to the next.

How do I like to work? Some people are happy in a code editor and want a real scripting language from day one. Some people think in flowcharts and want to wire up logic visually. Some people want to write as little code as humanly possible and just ship. There's no wrong answer here. It's about matching how you think to what the tool asks of you.

Hold those three answers in your head as you read the rundown below.

The engines, one by one

Godot

The one I recommend to most people starting out. Godot is free and open source, with no account, no revenue share, no runtime fee, no strings. It's a small download, it opens in seconds, and its scene-and-node model is one of the cleanest mental models in the business.

Its 2D support is first-class rather than an afterthought bolted onto a 3D engine, and its 3D has come on enormously in the 4.x releases. GDScript, its built-in language, reads almost like plain English and is a kind first programming language. You can also use C# if you want something more career-transferable.

The trade-off is ecosystem size. There are fewer paid plugins, fewer ready-made asset packs, and a smaller (though very friendly) tutorial pile than Unity has. For a beginner, that gap rarely bites. If you are weighing the two head to head, my Godot vs Unity comparison goes deeper.

Best for: 2D games, first-time coders, anyone who values owning their tools outright

GameMaker

If your first game is 2D and you want to ship it quickly, GameMaker is a superb choice, and its track record embarrasses engines ten times its size. Undertale, Hyper Light Drifter, Katana ZERO, Nuclear Throne and Hotline Miami all came out of it.

It is built entirely around 2D, which is its whole strength. You can start with drag-and-drop actions and graduate to GML, its scripting language, when you are ready for more control. That gentle ramp from no-code to real-code is exactly what a lot of beginners need.

The catch is that it is 2D only, so the day you want to make a 3D game you will be reaching for something else. For the 2D-versus-2D call against Godot, see GameMaker vs Godot.

Best for: 2D-only projects, fast iteration, a smooth path from visual logic into code

Unity

The default of the last decade, and still an enormous, capable engine. Unity uses C#, a proper mainstream language that looks good on a CV, and it has the largest third-party ecosystem of the lot. If a specific asset pack, tutorial series or plugin exists for exactly your game, there is a strong chance it exists for Unity first.

That ecosystem is the real reason to pick it. The Asset Store is deep, the answer to almost any "how do I" is already on YouTube, and studio job listings ask for it by name more than any other engine.

Two caveats. It's heavier and more complex to get started with than Godot or GameMaker, so the beginner on-ramp is a little steeper. And Unity spent 2023 torching a lot of goodwill with a since-reversed runtime-fee announcement, which is worth knowing about even though the policy itself is gone. The tech is still excellent; just go in with clear eyes.

Best for: 3D and 2D alike, building job-ready skills, leaning on a huge asset and tutorial ecosystem

Unreal Engine

Unreal is the powerhouse. If you are chasing high-fidelity 3D, photoreal lighting, or the kind of visuals that make people ask "that is a game?", this is the tool the biggest studios reach for, and it is free until you are earning serious money.

Its Blueprints visual scripting system is powerful, so you can build a surprising amount without writing C++. But Unreal is a large, heavy, professional-grade engine all the same. For a solo beginner making their first small game, it's often more engine than the project needs, and the learning curve is the steepest here. It also assumes a fairly modern machine, so on an older or low-spec laptop it will feel sluggish in a way Godot and Unity will not. If you are choosing between the two big 3D engines, my Unreal vs Unity breakdown weighs them up.

Best for: ambitious 3D, cutting-edge visuals, developers who know they want the AAA toolset

The no-code tools: Construct and GDevelop

If the word "scripting" makes you want to close the tab, start here. Construct and GDevelop let you build complete, shippable games out of visual event sheets, no traditional programming required. They run in the browser, they are quick to learn, and they are brilliant for getting a real, playable thing in front of people fast.

You will eventually hit a ceiling that code-based engines do not have, but "eventually" might be several finished games away, and finishing games is the whole point.

Best for: absolute beginners, non-programmers, rapid prototyping, small 2D projects

A quick cheat sheet

• I want 2D and I am new to code: Godot or GameMaker.
• I want 2D and I do not want to code at all: GDevelop or Construct.
• I want 3D and I am new: Godot first, Unity if you need its ecosystem.
• I want the most job-transferable skills: Unity (C#).
• I want the best-looking 3D and I am ambitious: Unreal.
• I can't decide: Godot. Download it today, you'll lose nothing.

The thing nobody wants to hear

The engine isn't what's standing between you and a finished game. Scope is.

The most common failure in game development has nothing to do with the engine. It's starting a sprawling dream project, burning out on it, and quietly shelving it six weeks later with nothing to show. The engine you agonised over for a week barely registers next to that.

So whatever you pick, make something tiny first. A game that fits in one screen. Something you can finish in a weekend and then actually release, warts and all. You will learn more from shipping one embarrassing little game than from a month of comparison videos, and you will find out whether the boots fit by walking in them, not by reading the box.

Whatever you pick, your assets will pile up

The moment you start, you begin collecting stuff. Sprite packs, sound effects, models, fonts, that free tileset bundle you grabbed at 2am and will absolutely use one day. It happens in every engine, and it happens fast.

That collection is the one thing that outlives your engine choice. Your art, audio and models are just files, and they carry across unchanged if you ever switch. The code does not, but the assets do. Which is exactly why it pays to keep them organised and engine-agnostic from the very beginning, rather than as a folder called assets_final_v3_USE_THIS_ONE.

That is the job AssetHoard does. It sits beside whichever engine you land on, previewing and organising your whole library in one place, and it reads native project formats from Godot, Unity and GameMaker so the same library follows you wherever you go.

Pick an engine. Make something small. Keep your assets tidy. The rest is just practice.

Mark

Hero photo by Enrique Guzmán Egas on Unsplash.

Sound is the half of game feel that nobody notices until it is missing. A jump without a jump sound is just a sprite moving up. Add a short, punchy bloop and suddenly the thing has weight.

The good news is that in 2026 you do not need a field recorder, a foley pit, or a subscription to make your game sound good. There are enormous libraries of free, royalty-free, and public-domain audio out there, plus a small clutch of generators that will synthesise a laser or a coin pickup for you in about four seconds.

Here are 22 places worth bookmarking, grouped by what they are best at. A licence note at the end covers the one thing you must check before you ship.

The big all-rounder libraries

Start here. These cover the widest range of sounds and are where most searches begin.

Freesound

Freesound.org is the granddaddy, a collaborative database with well over half a million samples uploaded by people all over the world. The depth is unmatched. If you need the specific sound of a rusty gate, a Geiger counter, or a very particular type of splash, it is probably in here somewhere.

The trade-off is that quality and licensing vary wildly from one upload to the next. Filter by CC0 if you want no-strings usage, and audition before you commit. The search has quietly improved over the years and now handles similarity search, so you can find "more sounds like this one".

Best for: Specific and unusual sound effects, foley, ambience, sheer variety

Pixabay

Yes, the stock photo site. Pixabay has grown a genuinely large royalty-free sound effect and music library, all under a permissive Pixabay licence that behaves like CC0 for practical purposes. No attribution, commercial use fine.

The filtering and preview experience is nicer than most dedicated audio sites, which makes it a great first stop for common sounds.

Best for: Quick searches, common effects, background music, zero attribution

Zapsplat

Zapsplat hosts hundreds of thousands of sound effects and production music tracks. The free tier is generous and covers commercial use, on the condition that you credit Zapsplat somewhere (a Gold subscription removes the attribution requirement and the download limits).

The library is well tagged and professionally curated, so you spend less time wading through duds.

Best for: Well-organised, professional effects when you can accommodate a credit

Mixkit

Mixkit (part of Envato) gives away a curated set of free sound effects and music under its own licence, free for commercial use with no attribution. The library is smaller and more hand-picked than the giants above, which is a feature rather than a bug when you just want something clean and usable fast.

Best for: Curated, ready-to-use effects and music, no attribution

Uppbeat

Uppbeat started as a music platform and now carries a solid sound effect library too. The free tier is clean and modern, aimed squarely at content creators, with a credit required on the free plan.

Best for: Modern UI sounds, whooshes, transitions, background music

OpenGameArt

OpenGameArt.org is best known for sprites and models, but its audio section is a hidden gem for game-specific sounds and chiptune music. Everything is under an open licence (CC0, CC-BY, GPL), it is built by and for game developers, and the search lets you filter by licence up front.

Best for: Game-specific SFX, chiptune and orchestral music, open licences

Sound effect specialists

When you need higher-end or more specific effects, these dedicated libraries earn their place.

Sonniss GDC Game Audio bundle

Every year for GDC, Sonniss releases a free bundle of professional game audio. The back catalogue now runs to hundreds of gigabytes of royalty-free sound effects, usable commercially with no attribution required. These are not amateur phone recordings, they come from professional sound libraries and they are genuinely excellent. Download a couple of years' worth and you have a career's supply of foley.

Best for: Professional-grade effects in bulk, one enormous free download

99Sounds

99Sounds publishes free, curated sound effect and sample packs put together by working sound designers. Cinematic hits, foley, ambiences, glitch, and the occasional oddball themed pack. Quality is consistently high because each release is a deliberate collection rather than a dumping ground.

Best for: Themed professional packs, cinematic and impact sounds

A Sound Effect

A Sound Effect is primarily a marketplace for boutique commercial libraries, but it runs a regularly updated free section and gives away high-quality packs from independent sound designers. Well worth checking periodically, and a good way to sample the work of pro libraries before buying.

Best for: Boutique free packs, discovering professional sound designers

BBC Sound Effects

The BBC Sound Effects archive put over 33,000 effects online, drawn from decades of the BBC's radio and television work. Vintage machinery, wildlife, crowds, historical ambiences, the lot.

The catch is the licence. These are released under the RemArc licence, which covers personal, educational, and research use, not commercial games. Superb for prototyping, reference, and learning, but read the terms carefully before anything ships. Treat it as inspiration, not shipping stock.

Best for: Reference, prototyping, historical and unusual recordings (non-commercial)

Adobe free sound effects

Adobe quietly maintains a free download of around 10,000 sound effects originally assembled for Audition. Ambiences, foley, sci-fi, cartoon, and more, cleanly organised into themed folders. No Creative Cloud subscription required to grab them, and they are royalty-free.

Best for: A solid, well-organised starter pack across every category

GameSounds.xyz

GameSounds.xyz is a no-frills aggregator that pulls together public-domain and permissively licensed audio in a directory you can browse straight in the page. Not pretty, but fast, and everything is oriented towards game use.

Best for: Quick browsing of public-domain game audio

Free SFX and Orange Free Sounds

Two smaller British libraries worth a mention. Freesfx.co.uk offers a broad catalogue free with attribution, and Orange Free Sounds mixes SFX, loops, and music under Creative Commons licences. Neither is huge, but both surface things the big sites miss.

Best for: Filling gaps the majors leave, Creative Commons audio

SoundBible and Fesliyan Studios

SoundBible is an old-school library of individual clips, largely CC0 or attribution, handy for one-off common sounds. Fesliyan Studios leans towards game and cartoon effects plus royalty-free music, free with attribution for most uses.

Best for: One-off common sounds, cartoon and game effects

FindSounds

FindSounds is not a library but a search engine that crawls audio across the web. When a sound is oddly specific and nowhere obvious has it, this is the tool that turns it up. Verify the licence on wherever it actually lives before you use anything you find.

Best for: Hunting down a very specific sound that hides from normal search

Make your own: retro sound effect generators

Sometimes the fastest route to the exact bleep you want is to generate it. These tools synthesise classic game sounds from a handful of sliders, and because you made the output, there are no licensing questions at all.

Bfxr

Bfxr is the browser-based descendant of the legendary sfxr. Hit "Randomise", mash the preset buttons (Pickup, Laser, Explosion, Power-up, Jump, Hurt), tweak the waveform and envelope, and export to .wav. It is the single fastest way to fill a whole game with coherent 8-bit sound effects in an afternoon. Runs entirely in the browser, nothing to install.

Best for: 8-bit and chiptune SFX, rapid prototyping, jam games

ChipTone

ChipTone by SFB Games is a more powerful free synth in the same spirit. Richer control over the waveform, envelope, arpeggios, and effects than Bfxr, with a friendlier interface. If Bfxr feels too coarse, this is the step up.

Best for: More detailed retro SFX with finer control

jsfxr and rFXGen

jsfxr is a clean web port of the original sfxr, minimal and instant. rFXGen by the raylib author is a small downloadable tool that does the same job as a native app, with wave visualisation and batch export. Both are free.

Best for: Purists who want the original sfxr feel, offline generation

LabChirp

LabChirp is a free Windows tool for building more complex layered sound effects than the sfxr family allows. Multiple channels, more waveform types, and enough depth to make sounds that do not obviously scream "generated". Free and worth the download.

Best for: Layered, less obviously synthetic generated effects

Bonus: ambience and music

Not strictly sound effects, but you will want these soon enough.

• Tabletop Audio builds looping ambiences and soundscapes (forests, taverns, spaceships) that make great background beds. Free to stream and download.
• Incompetech is Kevin MacLeod's vast library of royalty-free music, free with attribution under CC-BY.
• Free Music Archive and the YouTube Audio Library both offer large collections of free tracks, licences varying per item.
• ccMixter hosts remixable Creative Commons music if you want stems to chop up.

A note on licences

"Free to download" and "free to ship" are not the same sentence. Before anything goes into a build you sell, check the licence on every individual clip. The main ones you will meet:

• CC0 / public domain: use however you like, no attribution, commercial use fine. The gold standard.
• CC-BY: free to use, but you must credit the creator. Keep a running credits list as you go, not the night before launch.
• CC-BY-SA: attribution plus derivatives must carry the same licence. Fine for audio you use as-is, awkward if you build on it.
• Site-specific licences (Pixabay, Mixkit, Zapsplat): usually permissive, but each has its own wording on attribution and redistribution. Read it once.
• Non-commercial licences (the BBC's RemArc): great for prototyping and learning, not for a game you sell.

When in doubt, read the licence. It takes thirty seconds and saves the kind of headache that arrives by email months after launch. Keeping the licence noted against each sound as you download it is the cheapest insurance in game development.

Keeping it all organised

Here is what happens in practice. You grab a Sonniss bundle "for later", generate forty variations in Bfxr during a jam, download three themed packs from 99Sounds, and pull one perfect gate creak off Freesound. Within a month you have thousands of .wav and .ogg files scattered across your downloads folder, a couple of unzipped bundles, and an external drive, and you cannot remember which of them holds that footstep you liked.

Finding one sound you downloaded six months ago becomes an archaeological dig.

AssetHoard is a local-first asset manager for game developers built for exactly this. Point it at your audio folders and it indexes the lot, waveform previews and all, so you can audition a sound in place without opening another app, search across everything at once, and drag the clip straight into Unity or Godot. It reads inside .zip and other archives without unpacking them, so those Sonniss bundles stay exactly as you downloaded them while still being fully searchable. You can even record the licence against each file so future-you knows what is safe to ship.

One-time purchase, offline, no subscription. Your library stays on your machine.

The bottom line

You can make a game sound professional in 2026 without spending a cent. Between the big libraries, the professional bundles, the BBC's archive, and a generator or two, the raw material is all there and mostly free to ship.

The hard part was never finding sounds. It is finding the right one, twice, when you need it. Sort that out early and the audio stops being a chore.

Now go make something that goes bloop.

The AssetHoard Team

Every game developer has the same graveyard: a folder full of .zip, .unitypackage, and .tar.gz files you downloaded from a bundle sale two years ago. You know there is a great rock texture in one of them. You have no idea which. So you unzip all forty of them onto your SSD, poke around, and then have two copies of everything forever.

AssetHoard is a local-first asset manager for indie game developers and digital artists, and it takes a different approach to archives. It reads them where they sit, builds a searchable index of what is inside, and shows you previews of the contents, all without extracting a single file. The feature announcement covered what that looks like day to day; this post is how it works under the hood, and why it is faster than it has any right to be.

Nothing gets extracted: indexing archives in place

There was a single goal, and no obvious way to reach it: the original archive is referenced in place and never copied. When AssetHoard imports a .zip or .unitypackage, it does not unpack it into a working directory. It opens the file, walks its table of contents, and records every member (each model, texture, and audio clip inside) as a logical entry in your library. The archive on disk is left exactly as it was.

That means importing a 4 GB asset pack costs you close to zero extra disk space. Your library shows the contents, your searches and filters cover the contents, but the bytes stay compressed inside the one file you already have.

Supported archive formats today:

• Unity packages (.unitypackage), with a dedicated indexer that understands Unity's GUID-and-pathname layout
• Zip (.zip)
• Tarballs: .tar, .tar.gz, .tgz, and bare .gz
• RAR (.rar)

Each format gets its own adapter behind a shared contract, so the rest of the app never has to care whether a preview came out of a zip central directory or a gzip stream.

Reaching one file in the middle of a compressed stream

Listing an archive's contents is straightforward. The awkward bit is pulling one file out of the middle of a compressed stream when you want to preview it, without decompressing everything before it.

For a zip this is tractable: zip keeps a central directory and each entry is independently compressed, so AssetHoard can seek straight to the member it wants. A tarball is a single walk. But a .tar.gz is one long gzip stream with no seek points at all. Naively, to read the last file you would have to decompress the entire archive first.

AssetHoard solves this with a checkpoint index (the "zran" technique). During indexing it drops an access point roughly every 1 MB of decompressed data and writes those checkpoints into a small sidecar file next to the index. When you later ask to preview a member, it jumps to the nearest checkpoint and decompresses forwards only from there. The sidecar costs about 1.6% of the archive size, and in exchange a file buried deep in a gzip stream opens in a fraction of a second instead of after a full-archive decompress.

When a member does get read, it is streamed, never buffered. A single mesh inside a package can be hundreds of megabytes, so AssetHoard opens a reader over the member's uncompressed bytes and pipes them straight to a cache file on disk. It never holds a whole member in memory.

Previewing files inside an archive

Browsing a package should feel like browsing a folder. In AssetHoard it does, and the trick is doing the least possible work per item.

• Images and textures get thumbnailed and shown in the grid.
• 3D models show a poster-frame thumbnail by default. The full interactive viewer only mounts, and only plucks the model's bytes out of the archive, when you actually click "View in 3D". You can scroll past a hundred models without decompressing a single one.
• Audio clips play in place.
• Engine resources are understood natively. Godot packages, for example, surface their embedded preview.png instead of falling back to a generic icon.

There is a nice bit of restraint in the indexer here too. For a "solid" archive, where every read has to re-decompress from a block boundary, an eager pass that thumbnailed every member up front would be quadratic. AssetHoard detects that case and skips the eager pass, falling back to generating previews lazily on first view. You get thumbnails either way; the app just refuses to melt your CPU to get them a few seconds sooner.

Thumbnails, once generated, are cached as PNGs and served to the interface over a local asset protocol. Image bytes never cross the boundary between the Rust core and the UI, which keeps browsing snappy even in packages with thousands of members.

Keeping the index correct when the archive changes

Referencing files in place instead of copying them raises an obvious question: what happens when the archive changes, or the index and the file drift apart? AssetHoard treats this as a first-class concern.

• Fingerprinting and a freshness ladder. Cached previews are stamped with a fingerprint of their source archive. If the cache file is present, it is provably current, so it is served without even touching the database or reopening the archive. If the archive changed underneath, the index is rebuilt.
• Drift detection. Before yielding bytes from a seek into a tarball, the adapter re-checks the 512-byte tar header at the recorded offset against the member it expected. If they do not match, it drops the stale cache, rebuilds the index once, and retries. A corrupted or silently-shifted index can never hand you the wrong file's bytes.
• Per-archive locks. Two previews of the same archive will not both pay for an expensive rebuild. The costly index build serialises on a per-archive lock while everything else stays concurrent.
• A security gate. Virtual member pointers only resolve to archives AssetHoard actually imported. You cannot smuggle an arbitrary path off disk through a crafted pointer.
• Graceful degradation. If the source archive is moved or deleted, that is an expected outcome (the original was never copied), and the app says so rather than crashing. Password-protected archives are refused cleanly at index time instead of half-importing members that could never preview.

Why it matters

Put together, this means you can point AssetHoard at a directory of untouched archives and immediately treat their contents as first-class library items: searchable, filterable, taggable, and previewable, with no extraction step, no duplicated storage, and no waiting for a 4 GB unzip to finish before you can find your rock texture.

The archives stay exactly as you downloaded them. AssetHoard just gives you x-ray vision into them.

Have a browse through the archives documentation for the full picture, or download AssetHoard and point it at that graveyard folder you have been avoiding.

Mark

You know how it goes. There's a Humble Bundle with forty Unity assets for $12. You grab it. Then the Asset Store has a 50% off sale and you pick up a few character packs you've been eyeing. A forum post recommends a great procedural terrain tool. It's on sale, why not. Six months later you have 300 .unitypackage files and absolutely no idea what most of them contain.

This is the Unity Asset Store backlog problem, and it affects almost every developer who uses the store seriously.

The problem with the Unity Asset Store

The Asset Store itself is part of the issue. When you're browsing it inside Unity, you see nice screenshots and read the description. But once something is in your library, that context mostly disappears. There's no tagging, no personal notes, no way to filter your own library by style or category. You can see a list of things you've purchased, and that's about it.

Outside of Unity it's worse. Your downloaded packages sit in a cache folder somewhere on your machine, just a pile of files named things like FantasyRPGCharacterPack_v3.unitypackage. No thumbnails. No way to know if that's a set of 2D sprites or fully rigged 3D models without importing it.

So what do most developers do? They import packages into a throwaway Unity project just to jog their memory, then delete it and forget again. If they're lucky, they remember to check the Asset Store listing first. If they're not, they spend twenty minutes importing and exploring something they bought two years ago and never used.

Multiply that across 200+ purchases and you've lost serious time.

Where Unity stores downloaded packages

Before you can organise anything, you need to know where the files actually live.

On Windows, Unity caches downloaded packages here:

C:\Users\{username}\AppData\Roaming\Unity\Asset Store-5.x\

On macOS it's:

~/Library/Unity/Asset Store-5.x/

And on Linux:

~/.local/share/unity3d/Asset Store-5.x/

Inside that folder, packages are organised by publisher name, then package name. So a Synty Studios package might live at something like Unity\Asset Store-5.x\Synty Studios\POLYGON - Fantasy Kingdom\.

A .unitypackage file is essentially a tar.gz archive. Crack one open and you'll find the asset files themselves, .meta files, and a folder structure that mirrors how things will be imported into your project. Unity uses this to reconstruct where everything goes. It's not a mystery format, it's just not visible in any useful way without tooling.

A lot of developers have no idea this cache folder exists. They assume packages live "in Unity" somehow, and are surprised to discover there are gigabytes of files sitting in AppData.

How to set up a sane folder structure

The first practical step is to stop relying on Unity's cache folder as your long-term storage. Create a dedicated folder somewhere sensible, outside any individual Unity project, and treat it as your personal asset library.

Something like D:\GameAssets\ on Windows, or ~/GameAssets/ on macOS and Linux. The location matters less than the habit of putting everything there consistently.

From there, pick an organisational scheme and stick with it. Two approaches that work well:

By publisher. If you buy a lot from the same studios (Synty, Kay Lousberg, Kenney), organise by publisher name: GameAssets/Synty/, GameAssets/Kenney/, etc. This mirrors how the Asset Store cache is already structured, which makes copying files over straightforward.

By category. If you buy from lots of different publishers, category-first often makes more sense: GameAssets/3D Models/, GameAssets/Audio/, GameAssets/UI/, GameAssets/Shaders/. When you're hunting for audio assets, you look in one place regardless of who made them.

You can combine the two: publisher folders within categories, or sub-folders by style within publisher folders. Whatever matches how you actually search for things.

Alongside the folder structure, keep a simple reference document. A spreadsheet or even a plain text file. For each package, note:

• What the package actually contains (a brief description in your own words)
• The licence type (some Asset Store licences restrict redistribution or use in certain contexts)
• Which projects you've used it in

That last one is more useful than it sounds. When you're upgrading a project or changing an asset, knowing exactly what you've used and where means you're not hunting through old project folders.

One more thing: back up your packages. The Asset Store doesn't guarantee lifetime access to everything. Publishers remove packages, the store has had downtime, and there have been cases where purchased assets became unavailable. Once you've downloaded something you paid for, treat it like it might not be there tomorrow, because occasionally it won't be.

Why folder structure alone isn't enough

Folders get you a long way. They're better than nothing by a significant margin. But they break down once your library gets serious.

The fundamental limitation is that a folder tells you what something is called and where it lives. It doesn't tell you what's inside. You can rename your file to synty_polygon_fantasy_kingdom_v1.2.unitypackage and that's still just a name. You don't know whether it has NPCs, whether the textures are 1K or 4K, whether it includes animations or just static meshes.

Tags are the thing folders can't do. A package might be "low-poly" and "fantasy" and "Synty" and "characters" all at once. In a folder structure, it lives in exactly one place. If you organise by publisher, you can't find it when you're browsing by style. If you organise by style, you lose the publisher grouping. Any folder scheme is a single taxonomy, and your brain uses multiple taxonomies simultaneously.

Spreadsheets help with this. You can add multiple columns for different attributes. But they don't scale pleasantly once you're past about fifty entries, and they're completely disconnected from the actual files.

The deeper problem is that to even fill in a spreadsheet accurately, you need to know what's in each package. And the only way to find out what's in a .unitypackage without tooling is to import it into Unity. Which brings you back to the throwaway project workflow, just with more paperwork involved.

Using AssetHoard to manage your Unity library

This is where a dedicated game asset manager earns its keep.

AssetHoard is built specifically for this problem. You point it at your Asset Store download folder, or wherever you've moved your packages, and it indexes everything. No importing into Unity, no throwaway projects.

From there you get actual previews: thumbnails for textures, sprites, and models pulled directly from inside the .unitypackage archives. You can browse what's in a package before you've touched it in Unity. That alone saves a significant amount of time if you're regularly evaluating what you own before starting a project.

Tagging is the other big feature. You can tag packages however makes sense to you: by style, category, project, quality level, whatever. A Synty pack can be tagged "low-poly", "fantasy", "characters", and "Synty" simultaneously. When you're starting a fantasy game and want to see every low-poly character asset you own, you search for those tags and everything shows up regardless of where the files are stored.

When you've found what you want, you can drag assets directly into an open Unity project. You're not manually digging through AppData or remembering which subfolder you put things in.

AssetHoard is a one-time purchase, local-first, no subscription. There's no cloud sync, no account required, nothing phoning home. Your files stay on your machine and so does your library data. If you want more detail on the Unity-specific workflow, there's a dedicated Unity asset manager page worth reading.

Summary

The real cost of your Asset Store library isn't the money you spent buying things. It's the time you lose not being able to find them when you need them, or re-discovering the same packages over and over because you have no system.

Any system is better than no system. Folders and a spreadsheet are a perfectly reasonable starting point and will serve you well until your library grows past a point where manual upkeep becomes its own overhead.

But if you're buying assets regularly, building multiple projects, or just feel like you own a lot of stuff you can't actually use effectively, a game asset manager will return the time investment many times over. The goal is a library you can actually search, not just a pile of files you vaguely remember paying for.

The Asset Hoard Team

So what's a DAM?

Think about all your files. Every sprite, every 3D model, every sound effect you downloaded at 2am and swore you'd use one day. If you're not totally sure where all of them are right now, that's the thing a DAM is for.

DAM stands for digital asset management. It's a system that keeps your files in one place, tags them, shows you previews, and lets you find things by what they are instead of where you saved them. That distinction doesn't matter much at ten files. At a few thousand it matters a lot.

The whole idea started in marketing. Big teams needed somewhere to keep logos and campaign images so nobody accidentally shipped last year's brand colours. Handy, but not built with game devs in mind.

Why folders stop working

Folders make you pick one home for each file, and most assets don't have one home. A single pixel sword might belong in your weapons pile, your player kit, that game jam project, and your medieval stuff, all at the same time. You can only file it once, so you end up copying it around, and then you've got four swords and can't remember which one you actually finished.

You've probably also opened a folder called assets_final and found final_v2 inside it, and final_ACTUAL_use_this inside that. It happens to everyone eventually.

And folders can't show you anything. A filename like char_03_b.png tells you nothing on its own, so you end up opening files one at a time just to see what they are.

Why a regular DAM won't fix it

You might figure you can grab an off-the-shelf DAM and call it done. Usually not.

Most of them are built for marketing assets. They're fine with logos and photos, but hand them a Godot .tres file or an Aseprite animation and they don't really know what to do with it.

They also tend to be cloud-first and locked behind a login, so your whole library lives on someone else's server and you're paying every month to reach your own work. And the pricing usually assumes you're a team with an approvals process, not one person shipping a game on the side.

What actually matters for game devs

If you're weighing up a DAM for game work, these are the parts worth caring about:

• Handles your file types. Not just images. 3D models, sprites, animation, audio, fonts, and engine-specific formats too.
• Shows thumbnails. You think visually, so finding an asset by sight is faster than reading filenames.
• Tags things for you. Manual tagging is a second job. The good ones automate most of it.
• Tracks variants. Three versions of the same character should sit together, not scatter across your drive.
• Works offline and stays yours. Local-first means the library lives on your machine and doesn't need a connection to open.
• Talks to your engine. Dragging an asset straight into Unity or Godot beats exporting and re-importing.
• Holds up at scale. Ten files is nothing. A hundred thousand is the real test.

If you're weighing actual tools against that list, we've done a round-up of offline asset managers for indie developers that covers the main options.

Where AssetHoard fits

AssetHoard is a local-first desktop asset manager for game developers and digital artists. One place for everything, sitting on your own machine.

That list above was more or less the design brief. It reads 80+ file types, so your models, sprites, Aseprite files, audio, fonts, and engine packages all land in one library. It generates thumbnails so you can browse by sight, and search works semantically and visually, so you can look for what something resembles rather than only what you named it. Variant groups keep the "which one's the final one" problem contained. You can drag assets straight into Unity or Godot. And it's built in Rust, so it stays responsive when your library gets big.

It runs on Windows, macOS, and Linux. No accounts, no cloud, no monthly bill. It's a one-time purchase, $29 USD, and the library stays yours.

If your assets are already scattered across half a dozen drives, it's a decent place to bring them together. And if you want to see how a real library holds up at scale, here's how I organise 100,000 game assets with it.

Download AssetHoard

Be honest: how many .zip files are sitting in your Downloads folder right now, unopened, because you're not sure which one holds the texture you actually want?

Almost everything you grab arrives compressed. Asset packs, sprite sheets, model bundles, the odd font collection. They land as archives, and unpacking each one just to peek inside means loose files scattered across your drive, duplicated copies you forget to delete, and a Downloads folder that slowly turns into a landfill. So you don't unpack them. You leave them there, promising to sort it out later. Later never comes.

Open the box without unpacking it

The next release of AssetHoard fixes the whole ritual. Import a .zip, .rar, or .tgz and it reads the contents on import, then shows the files and folders inside as if they were already sitting in your library. The folder tree is intact, names and sizes are right there, and you can dig through the whole thing like any other asset.

Nothing gets extracted. The archive stays as one tidy item in your library with its contents indexed underneath, so a pack holding hundreds of files doesn't flood your grid with clutter. Your drive stays clean, and there are no stray copies to chase down.

Preview what's actually in there

Browsing a file list is useful. Seeing the files is better.

Click any file inside an archive and AssetHoard previews it live, exactly as if you'd pulled it out. Images and sprites at full resolution, audio you can play in place, 3D models you can orbit and spin. Whatever the format, if AssetHoard can preview it loose, it can preview it inside an archive. It only reaches for the one file you clicked, and only when you click it. Everything else stays compressed until you go looking.

That means you can finally answer the question that started all this. Which pack has the texture? Open them, look, done. No unzip, no temp folders, no cleanup.

One less chore

You didn't get into game development to be a file archaeologist. Archives are one more pile of admin between you and the work, and this quietly removes it. Your downloads stay downloads, your library stays tidy, and the thing you're hunting for is finally something you can just look at.

Have a browse through the archives documentation for the full picture.

If your hoard of assets needs taming, download AssetHoard.

The AssetHoard Team

There's a myth that sits on top of game development like a wet blanket: that you have to be an artist to make a game worth playing. It stops a lot of people before they start. They can code, or they can design, or they just have a good idea and the patience to build it, but they can't draw a convincing tree, so they decide the whole thing is off the table.

It isn't. Some of the best-looking games on your shelf were built by people who never drew a single asset. They didn't cheat, and they didn't hire out everything. They did something more useful: they got good at assembling rather than creating, and they picked projects that didn't need them to be an artist in the first place.

Here's how you do the same.

Separate "making art" from "having good art"

The first thing to untangle is that these are two different skills, and only one of them is optional.

Making art is drawing, sculpting, animating, painting textures by hand. That takes years, and if it's not where your interest lies, that's fine. Having good art in your game is a different job. It's about consistency, mood, and direction. It's curation. And curation is a skill you can learn in an afternoon and get genuinely good at in a month.

A game that pulls fifty assets from one coherent source and lights them well will look better than a game with brilliant, hand-made assets that don't agree with each other. Players don't grade your art on how it was made. They react to whether it feels like one world. That feeling comes from consistency, not craftsmanship, and consistency is something you can engineer without drawing anything.

Start with a pile of good assets

The raw material is out there, most of it free. Sites like Kenney, Poly Haven, OpenGameArt and itch.io publish enormous libraries of models, textures, sprites and audio, a lot of it under CC0, which means you can use it, modify it, and ship it commercially with no strings attached.

Before you download half the internet, a word on the thing that trips people up: licences. "Free" covers a range of terms. CC0 is do-what-you-like. CC-BY wants a credit. Some packs are non-commercial only, some marketplace assets can go in a game but not be resold, and a few have oddly specific rules buried in a readme. None of this is hard, but it does need tracking, because the day you decide to sell your game is the wrong day to discover one texture was never cleared for it. Note the licence on every asset as it comes in, not later.

The goal at this stage isn't to find the asset. It's to build a working palette: a handful of sources whose style you can live with, that share enough of a look to sit together, or that you're willing to push into agreement. Which brings us to the actual work.

Modify, don't just drop in

The reason asset-pack games get a bad reputation is that people use them raw. They grab the popular free pack, drop it in untouched, and ship a game that looks exactly like the other four hundred games built from the same pack. The pack isn't the problem. Using it unchanged is.

You don't need to be an artist to modify assets. You need to be willing to change a few knobs:

• Recolour and re-texture. A model is just a shape until you decide what it's made of. Take a plain crate, a rock, a wall, and swap the material or texture for a different one, and it becomes a new object. Do this consistently across a scene, pulling everything toward one palette, and a dozen mismatched packs start to look like they were made for each other. This is the single highest-leverage thing a non-artist can do.
• Rescale and recombine. Kitbashing, in the trade. Take parts from different models and assemble them into something that isn't in any pack. A building from three modular kits. A creature from two. Nobody can point at the source because the source is four sources.
• Retone the whole thing. Even leaving geometry alone, shifting the colour balance of an entire set of assets toward warm, or cold, or desaturated, immediately makes them feel authored rather than borrowed.

The point of all this is deniability, in the good sense. You want the finished thing to look like your game, not like a shopping list. A modest amount of modification gets you most of the way there.

Let lighting and post-processing do the heavy lifting

If curation is the cheapest way to look like you have art direction, lighting is the cheapest way to have it.

The same grey untextured scene can look like a horror game, a sunny platformer, or a moody puzzle box depending entirely on how it's lit. Lighting is not drawing. It's placing a few lights, choosing a colour temperature, and deciding where the shadows fall. Modern engines hand you global illumination, soft shadows and physically based lighting essentially for free. Spend an afternoon learning your engine's lighting system and you'll get more visual return than a week of trying to learn to paint.

Then stack post-processing on top. A colour-grading pass to lock in a mood. A little bloom so lights feel like lights. A vignette to pull the eye inward. A touch of grain or a subtle chromatic aberration if it suits the tone. Individually these are sliders. Together they're the difference between "some assets in a scene" and "a look". Most of what people call style in a modern game is a lighting choice and a post-processing stack sitting on top of assets the developer bought.

None of this asks you to draw. It asks you to make decisions and be consistent about them, which is exactly the kind of thing a systems-minded developer is already good at.

Choose a game that doesn't need you to be an artist

The smartest move of all comes before any of this: pick a project whose fun doesn't live in the visuals.

Some genres are art-hungry. A hand-animated 2D adventure or a character-driven action game will fight you every step of the way if you can't draw. Others barely care what they look like, as long as they look clean, because the enjoyment is somewhere else entirely:

• Puzzle games. The satisfaction is in the mechanic. A clean, minimal look isn't a compromise, it's often the correct choice. Tetris didn't need a concept artist.
• Deck-builders and card games. Systems, numbers, and clever interactions carry these. You need readable cards and a tidy layout, not a portfolio.
• Strategy, management and simulation. Icons, tidy UI, and legible information beat lavish art. Players stare at spreadsheets dressed as cities and love it.
• Narrative and text-driven games. Words do the work. A strong visual frame and good typography go a long way, and neither requires drawing.
• Abstract and minimalist games. Geometric shapes, bold colour, and motion. An entire aesthetic built out of primitives, which happens to be exactly what a non-artist can produce.

Picking one of these isn't settling. It's playing to your strengths. A great puzzle game built by someone who can't draw will always beat an ambitious action game abandoned because its creator couldn't produce the art it demanded.

The bit nobody tells you: it's a curation problem

Once you go down this road, you discover the real bottleneck isn't making things. It's finding things. You end up with folders of packs from a dozen sources, hundreds of textures, half of them nearly identical, and no memory of which crate went with which wall or which licence let you ship which rock.

This is the boring, unglamorous work that sits underneath every asset-driven game, and it's the thing that quietly kills momentum. You didn't get into this to spend your evenings archaeologising your own Downloads folder. A game built from assets lives or dies on whether you can actually find the right asset when you need it, see it next to the others to check they agree, and trust that its licence is cleared.

That's the whole reason AssetHoard exists. It's an offline, local-first library for exactly this: everything you've collected in one place, previewable side by side so you can build a consistent palette by eye, tagged so you can find it, with the licence recorded on every single asset so shipping day holds no surprises. The making-a-game part is yours. The keeping-track-of-your-ingredients part is ours.

You were never blocked by not being able to draw

If you take one thing from this: the barrier you thought was there mostly isn't. Not being able to draw stops you from being a concept artist. It doesn't stop you from being a game developer.

Get a good pile of assets. Modify them enough to make them yours. Light them well and grade them into a mood. Pick a game where the fun lives in the design, not the pixels. And keep your ingredients organised enough that building stays fun instead of turning into filing.

The art will be fine. Go make the game.

The AssetHoard Team

You put your game on itch.io or sell it from your own site. A player downloads the build, double-clicks it, and instead of your title screen gets a full blue panel: "Windows protected your PC", publisher unknown. A good number stop right there. It is one of the quietest ways a direct-download game bleeds installs: the player never tells you, they just leave. Here is what causes it and how to fix it.

Why does my game show the Windows protected your PC warning?

It comes from Microsoft Defender SmartScreen, a reputation system in Windows. Before running a downloaded file it checks whether the file is signed by a publisher it recognises and whether that exact file has been downloaded enough to look established. A new build from an unknown developer fails both, so Windows shows the warning. Your game is not flagged as malware, only as unknown, which to a cautious player is much the same thing.

Why Steam games are fine and yours is not

The warning only appears on files carrying the Mark of the Web, a tag Windows attaches to anything that arrived through a browser. Steam files never get it: the Steam client downloads, installs and launches the build itself, so nothing comes via a browser and SmartScreen never looks. That is how you can ship a completely unsigned game on Steam and no player sees a warning.

There is an instant fix, and it is not a certificate. It is a distribution channel. Anything that installs your build for the player sidesteps SmartScreen the way Steam does, and the Microsoft Store and the itch.io desktop app both qualify. If one fits your game, that is the fastest way out.

The catch is that most itch buyers just click the download in their browser. That file lands with the Mark of the Web attached and SmartScreen stops to inspect it. Same binary as the Steam version, only the delivery changed. Sell direct and sooner or later you deal with this.

What actually clears it

To sign a build you need a code signing certificate: a file that vouches the download came from you. The standard, affordable tier is an OV (organisation validation) certificate, and that is the one to get. Do not pay extra for the EV (extended validation) tier expecting the warning to vanish, it no longer bypasses SmartScreen, so OV does the same job for far less.

Reputation builds against two things: the file hash of each build, and your signing identity. So the routine is boring and repetitive:

• Sign every release with the same identity. Unsigned builds start from zero every version.
• Timestamp at signing, so the signature stays valid after the certificate expires.
• Do not touch the binary after signing. One changed byte breaks the signature.
• Keep the same certificate and publisher name. Switching resets the clock.
• Then ship clean builds and wait. Microsoft does not publish the threshold; expect several weeks and a few hundred clean installs.

Your earliest players see the warning regardless. Put a line on your itch.io page and in your Discord telling people to click "More info" then "Run anyway". Your first supporters will not mind. The ones worth shielding are the cold visitors on your store page with no reason to trust you yet.

So be clear about what signing buys: your name replaces "Unknown publisher", and the certificate is what reputation accrues to. An unsigned build banks nothing, starting from zero every release, so without one you never get on the ladder.

Which certificate should an indie developer buy?

Every code signing certificate now keeps its private key in FIPS-compliant hardware to curb theft: either a USB token posted to you, which must stay plugged in when you sign, or a cloud HSM run by the certificate authority, where the key stays on their hardware and you sign over an API.

For a solo developer selling a paid game the shortlist is short: a cloud-signed individual certificate from SSL.com, or an individual or organisation certificate with a token from Sectigo or Comodo. Individual validation is the least painful: it verifies you as a person, needs no registered company, and still puts your name on the build. None of them clear the warning on day one, whatever you spend.

What you have to prove to get one

Individual validation: a government-issued photo ID, sometimes proof of address, and usually a short live check where you scan your ID and record a brief video. Often issued within a day or two.

Organisation validation: proof the business exists (in Australia, your ABN and ASIC registration, or a letter from your accountant or lawyer), a publicly listed phone number for a callback, and an email on a domain you own. Usually one to seven business days.

Australian sole trader: validate as an individual with just your ID, or as a business with your ABN. The one door closed to you is Microsoft's Artifact Signing, which does not cover Australia.

The short version

Move to Steam, the Microsoft Store or the itch.io desktop app and the warning disappears at once. Stay on browser downloads and no certificate removes it on day one. Get one anyway so players see your name instead of "Unknown publisher", sign every build the same way, timestamp it, and let reputation build as real people install clean copies. It is slow and there is no shortcut. Sign consistently and wait it out.

Open your subscriptions page. Go on. Add it up.

Most creatives I know are paying for at least a dozen recurring services before they've even started their actual work. Design tool, file storage, music streaming, project management, note-taking, email, a couple of streaming services they forgot to cancel, two AI assistants, a font library, a stock asset site, and somewhere in there a "productivity" app that emails them weekly to remind them they're still being charged.

None of it is really yours. You're renting the lot.

Why we swapped owning software for subscriptions

There used to be a simple deal. You'd hand over some money, get a box (or a download, eventually), and the software was yours. Forever. The company could release a new version next year and you could ignore it. Your files were files. They opened with the program you bought, on the computer you owned, whether or not the company that made it still existed.

That model didn't disappear because users wanted it gone. It disappeared because the people selling software realised they could make more money the other way. Recurring revenue is more predictable. It's easier to forecast, easier to value, easier to raise money against. A one-time purchase asks the company to keep earning your business. A subscription assumes you'll forget to cancel.

So everything became a subscription. Tools that used to cost $50 once now cost $20 a month. Add it up over five years and you've paid twenty-four times as much for the same thing, plus whatever features they've quietly moved behind the next pricing tier in the meantime.

The maths is bad. The ownership maths is worse.

If subscriptions were just expensive, that would be one thing. You could argue the convenience is worth it, or that ongoing updates justify the price. Sometimes that's even true.

The bigger problem is what happens to your stuff when the relationship ends.

Stop paying and you don't downgrade to the version you used to own. You lose access entirely. Your files are still technically yours, in the sense that they exist somewhere, but the app you used to open them is locked behind a paywall. Your project files become hostages.

Worse, a lot of "your" data isn't actually on your machine. It lives on the company's servers. Your tags, your collections, your project history, your settings, your assets. The day they pivot, get acquired, shut down, or decide your use case isn't profitable enough to support anymore, all of that work evaporates. You get a courtesy email and a 30-day window to export what you can. The metadata you spent years building, the organisation, the structure: gone.

This isn't a hypothetical. It's happened to users of dozens of creative tools in the last decade. The pattern is the same every time. Beloved tool gets acquired. Pricing changes. Features get removed. Eventually the lights go out. The CEO writes a blog post thanking you for the journey. Your data is yours to retrieve, mostly, sort of, with some asterisks.

Subscriptions also make every tool worse

There's a quieter problem with the subscription model that doesn't get talked about enough: it changes what the software is for.

When you pay once, the software's job is to be good enough that you'd recommend it. The company makes money by making something people want to buy. The incentive is to ship a great product and move on.

When you pay every month, the software's job is to keep you paying. The company makes money by making it harder to leave. That changes everything. Features get tied to the latest version, which is tied to the subscription. Export formats get worse, or proprietary. Cloud sync becomes mandatory so you can't take your data and run. The login screen appears earlier. The "cancel" button gets harder to find.

Some of this is malicious. Most of it isn't. It's just what happens when the incentive shifts from "build something good" to "keep them subscribed". Even good people, building good software, drift in that direction over time.

"But it's just a few dollars a month"

It is. Until it isn't.

The few dollars become more dollars at the next round of price increases. The features you depend on get moved to the next tier. The plan you signed up for gets renamed and what was included before now costs extra. Free tiers shrink. Trial periods shorten. The yearly plan that was a discount becomes the only way to get the features you used to have on monthly.

And it's not one subscription. It's twenty. Each one a "small" recurring fee. Together they're a second rent.

For indie developers, who are already juggling engine licences, hosting, asset store purchases, music tools, marketplaces, store fees, and tax, another subscription isn't a small ask. It's another thing to track, another auto-renewal to forget about, another vendor with a copy of your credit card.

Local-first means it's yours

The alternative is straightforward, and it used to be the default. Software that runs on your machine. Files that live on your disk. A licence you bought, not rented. A tool that keeps working whether or not the company is having a good quarter. It is the thinking behind every offline, local-first asset manager worth using.

The difference comes down to a handful of things you feel every day:

That's how AssetHoard works.

You pay once. You get the app. It runs on your computer. Your asset library is on your drive, not on our server. Your tags, your collections, your previews, your metadata, right down to the licence on each asset: all local. The catalogue file is yours. You can back it up, copy it to another machine, archive it on an external drive, hand it to your future self in ten years.

If we vanish tomorrow, your library doesn't. The app keeps running. Your files keep opening. The work you've put into organising your assets stays with you, because it's on your machine, in formats you can read, with no cloud dependency to lose.

We don't have a recurring billing system because we don't want one. We don't have an account system because you don't need one. There's no "your plan includes" because everyone's plan is the same: you bought it, it's yours.

What to expect from software you actually own

You shouldn't have to think this hard about whether a piece of software will exist next year. You shouldn't have to read a privacy policy to find out who owns your files. You shouldn't have to keep a spreadsheet of every recurring charge so you can remember what you're paying for.

The bar for software ownership used to be lower because the deal was simpler. Buying meant owning. Owning meant keeping. Keeping meant having control over your own work.

It can still be like that. It just takes choosing tools that are built on that assumption, and being willing to walk past the ones that aren't.

AssetHoard is one of those tools. There are others. Look for them.

The AssetHoard Team

The Request

A user pinged us on Discord:

the free program Paint.NET is like super-charged MS paint with layers, been using it for graphic design for years. its .pdn files also have thumbnails in Windows, on account of a Shell extension

In AssetHoard, .pdn files were landing in the library as generic blank tiles. No thumbnail, no dimensions, no layer count. For a user with a folder full of Paint.NET work, that means the grid view is useless: every asset looks identical. The fix is obvious in principle (support the format) and not so obvious in practice (Paint.NET's file format is a serialised .NET object graph, and we are not a .NET app).

This is the story of how we shipped real thumbnails for .pdn files in a few hundred lines of Rust, by piggybacking on a trick Paint.NET itself uses for the Windows Explorer preview.

What's Actually In A .pdn File

Most game-dev file formats are documented. GLTF has a spec. PSD has a spec. Aseprite publishes their format. Paint.NET is closed-source from v4 onwards, and even when v3.x was open-source, the "format" was really just .NET's BinaryFormatter serialiser dumping the in-memory Document object straight to disk. There's no neutral binary layout. To read the bitmap data you basically need to reconstruct the .NET runtime's idea of what a Document looks like.

But there's a wrinkle. The Paint.NET team needed Windows Explorer to render thumbnails. Spinning up the .NET runtime to deserialise a Document just so Explorer can draw a 96-pixel icon is absurd, so they did something cleverer: they prepend a small XML header to every .pdn file with all the cheap stuff. Dimensions, layer count, and crucially a base64-encoded PNG preview of the image.

The shell extension reads the XML, decodes the PNG, hands it to Explorer. The actual document data sits untouched after the header. We can do the exact same thing.

The Bytes

Here are the first eight bytes of a real .pdn file saved from Paint.NET v5.109, dumped as hex:

50 44 4e 33 10 04 00 3c
P  D  N  3  └──┬──┘ <
            xml length

Decoded:

Bytes 0-3:   "PDN3"                          magic
Bytes 4-6:   0x10 0x04 0x00 = 1040 (LE u24)  XML preamble length
Byte 7+:     <pdnImage ...                   XML preamble starts here

The 24-bit little-endian length is unusual. Most formats use 16 or 32 bits. Paint.NET went with 24, which is enough for a roughly 16MB XML header. You will never hit that limit. Our test fixtures have headers in the 1KB to 17KB range.

After reading those 1040 bytes of XML, you get this:

<pdnImage
  width="980"
  height="980"
  layers="1"
  savedWithVersion="5.109.9343.2610">
  <custom>
    <thumb png="iVBORw0KGgoAAAANSUhEUgAAA..." />
  </custom>
</pdnImage>

Everything we want is right there. Width, height, layer count, the Paint.NET version that saved the file, and a base64-encoded PNG thumbnail. The iVBORw0KGgo prefix is what 0x89 P N G looks like in base64, so we know the embedded payload is a real PNG.

After the XML, the rest of the file is the .NET BinaryFormatter blob, usually gzip-compressed (you can spot it by the 0x1F 0x8B marker right after the XML ends). That blob holds the full-resolution layer pixel data, blend modes, layer names. We don't touch it. Parsing NRBF (the .NET Remoting Binary Format protocol) from Rust would mean either porting hundreds of lines of deserialisation code from pypdn, or shelling out to a .NET runtime. Both are huge effort for a feature most users will never notice.

The Implementation

The whole handler is about 200 lines. The interesting part is the preamble reader:

fn read_xml_preamble(path: &Path) -> Result<String, HandlerError> {
    let mut file = File::open(path)?;
    let file_size = file.metadata()?.len();

    if file_size < 7 {
        return Err(HandlerError::ParseError(
            "PDN file shorter than 7-byte header".to_string(),
        ));
    }

    let mut header = [0u8; 7];
    file.read_exact(&mut header)?;

    if &header[0..4] != b"PDN3" {
        return Err(HandlerError::ParseError(
            "Not a PDN3 file - missing magic bytes".to_string(),
        ));
    }

    let xml_len = u32::from(header[4])
        | (u32::from(header[5]) << 8)
        | (u32::from(header[6]) << 16);

    let max_xml_len = file_size.saturating_sub(7);
    if u64::from(xml_len) > max_xml_len {
        return Err(HandlerError::ParseError(format!(
            "PDN XML preamble length {} exceeds remaining file size {}",
            xml_len, max_xml_len
        )));
    }

    let mut xml_buf = vec![0u8; xml_len as usize];
    file.read_exact(&mut xml_buf)?;

    String::from_utf8(xml_buf)
        .map_err(|e| HandlerError::ParseError(format!("PDN preamble is not valid UTF-8: {e}")))
}

A few defensive details worth calling out:

Stack-allocated header. let mut header = [0u8; 7] is a fixed-size array on the stack. No heap allocation for the seven bytes we read first. We only allocate the Vec<u8> for the XML body after we've validated the length looks sane.

Bounds checking the length. The 24-bit length field is attacker-controlled in the sense that a malformed file could claim a 16MB preamble even when only a few KB exist on disk. We compare the declared length to the actual remaining file size before allocating. Without this check, a crafted file could trick us into allocating 16MB for what's actually a 100-byte file.

UTF-8 validation. String::from_utf8 returns a Result. If the preamble isn't valid UTF-8 (shouldn't ever happen for a real Paint.NET file, but a corrupt or hostile file might present otherwise), we return a clean error instead of producing garbled output.

Once we have the XML string, the metadata extraction is straightforward:

fn extract_metadata(&self, path: &Path) -> Result<serde_json::Value, HandlerError> {
    let xml = Self::read_xml_preamble(path)?;
    let doc = roxmltree::Document::parse(&xml)
        .map_err(|e| HandlerError::ParseError(format!("Failed to parse PDN preamble: {e}")))?;

    let pdn_image = doc
        .descendants()
        .find(|n| n.tag_name().name() == "pdnImage")
        .ok_or_else(|| HandlerError::ParseError(
            "PDN preamble missing <pdnImage> root".to_string()
        ))?;

    let width = pdn_image.attribute("width").and_then(|v| v.parse::<u32>().ok());
    let height = pdn_image.attribute("height").and_then(|v| v.parse::<u32>().ok());
    let layer_count = pdn_image
        .attribute("layers")
        .and_then(|v| v.parse::<u32>().ok())
        .unwrap_or(0);
    let saved_with_version = pdn_image.attribute("savedWithVersion").map(String::from);

    // ... package into JSON
}

We use roxmltree, which was already a dependency for our Krita handler (Krita files have a similar XML manifest tucked inside a zip archive). No new crates needed.

Thumbnail extraction follows the same shape: parse the XML, find the <thumb> element, decode the base64 PNG, hand it to the image crate for resizing. The whole thumbnail path is about 30 lines.

Test Fixtures

A handler is only as trustworthy as the files you test it against. We hit the standard problem here: how do you write tests for a proprietary format without a sample file?

Our first move was the pypdn project on GitHub. It's an MIT-licensed Python reader and ships with .pdn test fixtures from Paint.NET 3.5.10 and 4.21. Useful, but those are old versions. Paint.NET v5 is a major architectural rewrite (it moved to GPU-accelerated rendering with Direct2D), and we had no proof the file format hadn't moved with it.

We asked the user who filed the ticket. They sent three v5-saved files: a single-layer drop shadow study, a 14-layer HUD mockup, and a concept-art piece at v5.108. All three opened cleanly with our parser. All three had identical header structure to the v3.5 and v4.21 samples from pypdn. The format has been stable for over a decade.

That was the moment we knew we could ship.

We checked the smaller two files into src-tauri/tests/fixtures/ as test.pdn and test_many_layers.pdn. The unit tests assert real numbers from real files: 980x980 single-layer, 969x550 with 14 layers, both saved with Paint.NET versions starting with 5..

What We Deliberately Didn't Do

Three things we left on the floor on purpose.

Layer extraction. We can report the layer count (because it's in the XML preamble) but not layer names or blend modes (those are in the BinaryFormatter blob). We could parse the blob, but it's a huge engineering investment for a feature only power users would notice. The Krita and PSD handlers do surface layer names, and the PDN file details panel will look slightly thinner by comparison. We considered showing an empty layer list panel for PDN files, then realised that looks broken. Better to show nothing than to show a panel with placeholder text.

Export as PNG. PSD and Krita both expose an "Export as PNG" context action because their handlers can flatten the document. We can't, because the composite pixels live in the BinaryFormatter blob. The embedded thumbnail is the wrong size and quality for a real export. So we left the action off entirely. Consistent absence is less confusing than a broken or low-quality option.

Render profile auto-classification. Some image handlers run a heuristic to guess whether an image is pixel art (use nearest-neighbour resizing) or a photo (use bilinear). For PDN we'd be running that heuristic on the embedded preview thumbnail, which is small and downsampled. The verdict would be unreliable, and a wrong verdict makes the preview look worse than no auto-classification at all. We skip it and let users override via the render profile UI if they care.

The Cross-Platform Bonus

One side effect of parsing the file ourselves rather than calling out to the Windows shell extension: PDN thumbnails now work even without Paint.NET installed. On macOS or Linux, the .pdn icon in Explorer would just be a generic file. In AssetHoard, you get the real thumbnail because we're reading the bytes directly. That makes AssetHoard a better PDN viewer than Windows Explorer for anyone who's been handed a .pdn file by a collaborator and doesn't have Paint.NET on their machine.

The Takeaway

Sometimes a feature that looks like it needs a major engineering investment ("parse a closed-source .NET serialisation format") turns out to have a back door that the format's own designers already built in. The Paint.NET team needed Windows Explorer thumbnails to work without spinning up .NET, so they prepended a small XML manifest with the cheap stuff. That manifest is exactly what we needed.

Total work: about a day, including format research, fixture sourcing, the handler itself, and seven new unit tests. The result is that .pdn files now sit alongside .psd and .kra in the library, with thumbnails, dimensions, and version metadata.

If you're building something that needs to read a proprietary format, take a hard look at what the format's official tooling already does cheaply. The hard work might already be done.

TLDR: just take me to the table.

You downloaded the asset. Are you allowed to ship it?

Most developers do not think about asset licences until it is too late to fix cleanly. The texture pack went into the build two years ago, the folder it came from is gone, and no one can say whether attribution was ever required, let alone provided. A typical asset library is assembled over years from dozens of sources, and the licence is the first thing to get separated from the file.

This post is a plain guide to the licences you will actually encounter on game assets and what each one requires of you. It is not legal advice. The goal is to help you recognise what you are looking at, so you know which assets are safe to use without thinking and which ones need a closer read.

Two different worlds: Creative Commons and software licences

Game assets tend to arrive under one of two families of licence, and it helps to know which family you are dealing with before anything else.

Creative Commons licences were designed for creative works: images, audio, 3D models, written text. They are the licences you will see most often on art and sound.

Software licences such as MIT, Apache 2.0 and the GPL family were designed for source code. You will see these on shaders, tools, plugins, and occasionally on asset packs distributed through code repositories.

The distinction matters because the two families use different language and were written with different assumptions. A licence written for code does not always map cleanly onto a sprite sheet. When a 3D model arrives under the MIT licence, which happens, you are relying on a reasonable reading of terms that were not written with 3D models in mind. That is usually fine, but it is worth knowing that is what you are doing.

The Creative Commons licences

Creative Commons is not a single licence. It is a set of licences built from a few interchangeable parts, and once you know the parts, the names stop being cryptic.

CC0: the closest thing to no strings

CC0 is a public domain dedication. The creator has waived their rights as far as the law allows. You can use the asset in a commercial project, modify it, and redistribute it, and you are not required to credit anyone.

CC0 is the easiest licence to work with, and it is why sites built around CC0 assets are popular with developers who want to avoid licence tracking entirely. Attribution is still a courteous thing to do, and many developers credit CC0 creators anyway, but it is a courtesy and not an obligation.

If an asset is genuinely CC0, you can use it and effectively forget about it. The difficulty is confirming that it genuinely is CC0, which comes back to record keeping, covered further down.

CC-BY: free to use, credit required

CC-BY allows commercial use, modification and redistribution, on one condition: you must give appropriate credit to the creator. That credit normally means naming the creator, linking to the original where practical, and indicating whether you made changes.

CC-BY is one of the most common licences on free game assets, and the attribution requirement is also the most commonly missed obligation in game development. Missing it is not a technicality. If you ship a commercial game using CC-BY assets and provide no credit, you are not complying with the licence.

The practical fix is simple and worth building into your process early. Keep a credits file from the first day of the project. Every time a CC-BY asset goes in, the creator goes into the file. Doing this continuously takes seconds. Reconstructing it the week before launch, from assets whose origins you no longer remember, can take days, and sometimes it cannot be done at all.

The modifier letters

The rest of the Creative Commons system is built from modifiers added to BY. Each one adds a restriction.

SA, ShareAlike. If you modify the asset, you must release your modified version under the same licence. For a self-contained asset this is usually manageable. The reason to be careful is that ShareAlike can, depending on how the work is combined, create obligations you did not anticipate for the things you build around the asset. If you are considering a CC-BY-SA asset for a commercial project, this is the one modifier worth reading closely rather than skimming.

NC, NonCommercial. The asset may not be used for commercial purposes. This is the modifier that catches developers out most painfully, because a free game is not automatically a non-commercial one. If your game is on a paid storefront, carries advertising, or exists to build a commercial studio's profile, a reasonable reading is that it is commercial. An asset marked NC is not safe for a project with any commercial dimension, and a free demo for a paid game sits in genuinely uncertain territory. The safe assumption is that NC and a commercial release do not mix.

ND, NoDerivatives. You may use the asset but you may not distribute a modified version of it. ND is uncommon on game assets and is largely impractical for them, since assets are usually resized, recoloured, recompressed or otherwise altered as a matter of course. Treat an ND asset as difficult to use in a real pipeline.

Reading a Creative Commons name

Put the parts together and the names decode themselves. CC-BY-NC-SA means: credit required, no commercial use, and modifications must carry the same licence. For most commercial game projects, the presence of NC alone is enough to set the asset aside.

One more detail worth knowing: Creative Commons licences are versioned, most commonly 3.0 and 4.0. The differences are mostly minor for game use, but if a project is significant, the version is part of what you should record.

The software licences

These appear on shaders, plugins, tools and code-adjacent asset packs.

MIT is short, permissive and common. You can use, modify and distribute MIT-licensed work, including commercially. The main requirement is that you preserve the copyright notice and licence text in your distribution. For a game, that normally means including the notice somewhere in your credits or a licences screen.

Apache 2.0 is similar to MIT in spirit, permissive and commercially usable, with more explicit wording, including an explicit grant of patent rights. It also asks that you note significant changes you have made. For most game use it behaves much like MIT with a longer licence file.

The GPL family is the one to approach with genuine care. The GPL is a copyleft licence, and depending on how GPL-licensed code is incorporated, it can require that the larger work it becomes part of is also released under the GPL. For proprietary commercial games this is often a serious problem. The LGPL is more permissive about linking and is frequently fine for libraries used in commercial software, but GPL terms reward careful reading rather than assumption. If a tool or plugin you depend on is GPL-licensed, understand the obligation before you build on it, not after.

A note specific to game engines: code licences and asset store terms are separate things. The engine you use has its own licence, and an asset bought from a storefront is governed by that storefront's terms in addition to any licence the creator attaches. Those storefront terms are part of the picture and worth reading at least once.

Licences at a glance

This table is a quick orientation, not a replacement for reading the licence on an asset that matters. "Copyleft" means a modified version must be released under the same licence, and "modifications allowed" refers to distributing a changed version rather than editing privately.

Asset store and bespoke licences

Not every asset uses a standard licence at all. Many marketplace assets ship under the storefront's own end user licence agreement, and some creators write their own terms.

These bespoke licences are where genuine surprises live. Common clauses worth checking for include limits on the number of projects or seats an asset may be used in, a requirement to hold a particular tier of licence for commercial release, restrictions on redistribution that affect whether you can include the asset in a source repository or a downloadable project template, and limits on use in AI training datasets. None of these are unusual, and none of them are visible unless you read the licence. The general rule holds: a non-standard licence is the one that most needs reading, precisely because you cannot predict it from a familiar name.

The real problem is not the licences. It is the record keeping.

Every licence above is straightforward enough to comply with on its own. The difficulty in practice is almost never understanding a single licence. It is that a finished game draws on a library built over years, and the licence information was never attached to the assets in a durable way.

The licence terms tend to live in a forum post, a storefront page, a readme that stayed in the original archive, or an email. The asset gets copied into the project. The terms do not travel with it. Two years later the asset is still in the build and the terms are unrecoverable.

The fix is to treat licence information as part of the asset itself, recorded at the moment the asset enters your library, while you still have the source in front of you. The specific tool matters less than the habit of organising assets as they arrive. What matters is that for any asset you might ship, you can answer three questions quickly: where did this come from, what licence is it under, and does that licence require attribution.

This is a problem AssetHoard is built to take off your hands. It is a local-first asset manager that keeps your whole library in one place, and licence and source are part of what it tracks alongside each asset, so the terms stay attached to the file instead of being scattered across the places you originally found them. When you reach a release and need a complete, accurate credits list, the information is already where the assets are. If you would like to see the rest of what it does, the website is the place to start.

The short version

If you remember nothing else: CC0 means use it freely. CC-BY means use it and credit the creator. NC means keep it away from anything commercial. ShareAlike and the GPL family mean read the actual terms before you build on the asset. And whatever the licence, record where the asset came from on the day it enters your library, because the licence is worth nothing to you if you cannot find it again when you ship.

The AssetHoard Team

A .tres file looks innocent. Open one in a text editor and you get something close to INI: a header, a few sections, some key-value pairs. Tiny. Readable. Surely a couple of regexes away from being parseable.

This impression survives roughly five minutes.

Godot resource files are a custom format that references other resources by path, by UID, and sometimes both. A StandardMaterial3D.tres is a small text file pointing at textures that live somewhere else. Move just the .tres to a different project and the material is broken on the other end. The textures cannot be found. The material falls back to magenta. Your asset is, for any practical purpose, useless.

This is a problem for an external asset manager. The whole point of AssetHoard is that you find a thing in one place and use it somewhere else. If "use it somewhere else" only works for self-contained files, then half of what comes out of a Godot project is excluded.

So v0.1.13 ships proper .tres support. Materials, ShaderMaterials, SpriteFrames and TileSets all get real previews instead of generic icons. More importantly, dragging a .tres out of AssetHoard now walks its reference graph and pulls every linked file along with it, reconstructing the res:// folder layout at the drop location. Drop the result into a Godot project and it just works.

This post is the long version of how that got built. Lexer, parser, resource resolution, rendering, and the drag-out behaviour. There are sharp edges in every layer.

The .tres Godot format

Before parsing anything you have to understand what you are parsing. The .tres format is text-based, deceptively simple at a glance, and full of corners.

A minimal example:

[gd_resource type="StandardMaterial3D" load_steps=3 format=3 uid="uid://abc123"]

[ext_resource type="Texture2D" uid="uid://def456" path="res://textures/stone_albedo.png" id="1_albedo"]
[ext_resource type="Texture2D" uid="uid://ghi789" path="res://textures/stone_normal.png" id="2_normal"]

[resource]
albedo_texture = ExtResource("1_albedo")
normal_enabled = true
normal_texture = ExtResource("2_normal")

The shape is sections in square brackets, each with a type and some attributes, followed by key-value pairs. [ext_resource] blocks declare external dependencies. [resource] is the main resource definition. Values can be primitives (numbers, strings, booleans) or constructor-like calls (ExtResource(...), Color(0.5, 0.5, 0.5, 1), Vector3(0, 1, 0)).

But this is the friendly version. Real files in real projects are denser, and the parser splits the work in two. A structural pass in handlers/tres.rs reads the [gd_resource] header, every [ext_resource] line, and every [sub_resource] block, because that grammar is uniform across resource types. The [resource] block is then handed off to a per-type body parser, dispatched on header.resource_type:

pub fn parse_tres(content: &str) -> Result<TresFile, TresParseError> {
    let structure = parse_tres_structure(content)?;
    let body = match structure.header.resource_type.as_str() {
        "SpriteFrames" => TresBody::SpriteFrames(
            crate::handlers::tres_spriteframes::parse_sprite_frames(content)?,
        ),
        "TileSet" => TresBody::TileSet(
            crate::handlers::tres_tileset::parse_tile_set(content)?,
        ),
        _ => TresBody::Flat(parse_resource_block_flat(content)),
    };
    Ok(TresFile { structure, body })
}

Anything without a dedicated parser falls into TresBody::Flat, a HashMap<String, String> that captures multi-line array and dict values verbatim by tracking bracket balance via a string-aware scanner. That alone covers StandardMaterial3D, ShaderMaterial, FontFile, Environment, and the long tail of Resource subclasses where the body is just key = value pairs.

Format quirks and how we handle them

What we explicitly do not support: GDScript-defined custom resources (no metadata to render against, no safe way to execute), .tscn scenes (most of the format would work, but it is not in v0.1.13), TileSetScenesCollectionSource (silently skipped), and Godot 3 SpriteFrames (the format is fundamentally different and currently returns an empty result rather than a partial parse).

Lexing and parsing

The lexer and parser live in their own module, godot_variant/, with a hard rule that it imports only from std and serde. Nothing else in the crate. The isolation is deliberate: it is a candidate to extract as a workspace crate later, then maybe to crates.io if it turns out to be useful to anyone else.

The token enum:

pub enum Token {
    LBracket, RBracket, LBrace, RBrace, Comma, Colon,
    String(String),
    StringName(String),                              // &"idle"
    Int(i64),
    Float(f64),                                      // includes inf, -inf, nan
    Bool(bool),
    Null,
    SubResourceRef(String),                          // SubResource("AtlasTexture_xyz")
    ExtResourceRef(String),                          // ExtResource("1_abc") or ExtResource(1)
    TypedCall { name: String, raw_args: String },    // Color(1,1,1,1), Vector2(0,0), ...
}

tokenize(input: &str) -> Result<Vec<Token>, LexError> returns a Vec rather than an iterator. Inputs are tiny (a few KB per animations = [...] blob), the parser benefits from look-ahead, and any error short-circuits the batch.

The parser is recursive descent and panic-free by construction. No unwrap(), no out-of-bounds indexing, every fallible operation returns Result. The AST is intentionally minimal:

pub enum VariantValue {
    Dict(HashMap<String, VariantValue>),
    Array(Vec<VariantValue>),
    String(String),
    StringName(String),
    Int(i64),
    Float(f64),
    Bool(bool),
    Null,
    SubResourceRef(String),
    ExtResourceRef(String),
    TypedCall { name: String, raw_args: String },
}

I did not seriously evaluate nom, chumsky or pest. The format is just irregular enough that a generic combinator approach would have been more code than the focused state machine, and the no-third-party-dep rule on the module makes it easier to lift into its own crate later.

Errors do not tear the whole parse down. The structural pass skips malformed [ext_resource] and [sub_resource] blocks and continues. A SpriteFrames body that fails to lex or parse on a format=2 file gets downgraded to an empty result with a debug log; on format=3 the error propagates. The TileSet parser is best-effort throughout, with partial results always valid:

let variant = match lexer::tokenize(animations_text) {
    Ok(toks) => match parser::parse_variant(toks) {
        Ok(v) => v,
        Err(e) => {
            if format == 2 {
                log::debug!(
                    "parse_sprite_frames: format=2 graceful degradation (parse): {}",
                    e
                );
                return Ok(SpriteFramesData::empty());
            }
            return Err(TresParseError::BodyParseError(format!(
                "failed to parse animations Variant: {}", e
            )));
        }
    },
    ...
};

Unit tests cover every Variant shape we have seen in the wild: Godot 4 quoted refs, Godot 3 unquoted-int refs, dicts with StringName keys, arrays of dicts, nested PackedColorArray strings containing parens. Plus panic-free torture tests for unterminated strings, unbalanced parens, garbage bytes and lone -.

Resolving references

Parsing produces a resource with a list of declared external references. That is the easy half. The hard half is resolution: figuring out where each res:// path actually lives on disk, whether the referenced file is in your library, and what to do when it is not.

Resources nest. A StandardMaterial3D references textures. A SpriteFrames might reference an AtlasTexture sub_resource that itself points at a PNG. A TileSet references atlas textures and can chain into terrain definitions. The full picture for any one .tres is a directed graph, sometimes several layers deep, but the resolver does not treat it as one. It runs per-reference on every .tres it sees during import, and the graph emerges implicitly as each asset's resolved entries link up to others in the library. Walking the graph as a graph only matters at drag-out time.

AssetHoard works on user-imported folders, and there is no guarantee a .tres lives inside a real Godot project tree. The resolver does not look for a project.godot file. Instead, for each res:// reference on a single .tres, it walks up the directory tree from the .tres's on-disk location (capped at depth 10) and at each level tries two candidates: <ancestor>/<full stripped path> to preserve the directory structure inside res://, and <ancestor>/<basename> as a flattened-pack fallback for authors who stripped the textures/ prefix when distributing. First match wins.

pub fn resolve_res_path(res_path: &str, tres_file: &Path) -> Option<PathBuf> {
    let rel = res_path.strip_prefix("res://")?;
    let rel_path = Path::new(rel);
    let basename = rel_path.file_name();

    const MAX_ANCESTOR_DEPTH: usize = 10;

    let mut current = tres_file.parent()?;
    for _ in 0..MAX_ANCESTOR_DEPTH {
        let full = current.join(rel_path);
        if full.exists() { return Some(full); }
        if let Some(name) = basename {
            let flat = current.join(name);
            if flat.exists() { return Some(flat); }
        }
        match current.parent() {
            Some(p) => current = p,
            None => break,
        }
    }
    None
}

The resolver runs as a post-import pass via the resolve_tres_references Tauri command. For each .tres asset it reads the header to assign a file_type of material / spriteframes / tileset / package, walks every [ext_resource] block, attempts to resolve each res:// path to a real file on disk, matches resolved paths against existing library assets, and writes the lot into metadata.references[] on the asset row. The pass is idempotent. Rerunning it is cheap and self-healing, so a previously-missing dependency that gets imported later picks up resolved_asset_id on the next pass.

References are not a separate table. They live as a JSON array on assets.metadata:

{
  "references": [
    {
      "path": "res://textures/stone_albedo.png",
      "resolved_asset_id": 1247,
      "disk_path": "/abs/path/to/stone_albedo.png",
      "slot": "albedo_texture"
    }
  ]
}

categorize_tres_references splits that array into three buckets at read time by stat'ing each disk_path: imported (resolved_asset_id populated), importable (unresolved but the disk path exists), missing (unresolved and the file cannot be located). Stat happens at categorise-time rather than resolve-time, so a file moved between sessions does not leave stale UI state.

Resolution is eager at import. The whole graph for a .tres is walked once, the result is cached in metadata.references[], and subsequent reads (preview, drag-out, references panel) never re-walk. The trade-off is staleness: if a referenced file moves on disk after import without rerunning the resolver, the cached disk_path is wrong. The categorise step's stat call covers the missing-now case, and there is a "Re-resolve Godot References" context action to force a re-walk.

Cycle handling lives in the drag-out path rather than the resolver itself. gather_tres_drag_payload recurses through .tres → .tres chains using a BFS queue with both a depth cap of 5 and a visited-asset-id HashSet, so a .tres referencing a .tres referencing back stops cleanly.

Rendering each resource type

Parsing and resolution are mechanical. Rendering is where the work actually became interesting, because each resource type needs its own thinking about what a useful preview looks like.

A useful preview is the one that lets you tell two similar resources apart at a glance. A generic "Material" icon fails this test immediately. A solid grey sphere is barely better. The goal is a thumbnail where the difference between stone_rough.tres and stone_polished.tres is visible without opening either file.

One overall architectural choice worth flagging up front: PBR rendering happens on the frontend via Three.js, not headless in Rust. Tauri is already shipping a WebView, the WebGL renderer is right there, and the result is a live, rotatable preview rather than a baked image. Thumbnails for the grid view are captured from the same renderer via canvas.toDataURL() and round-tripped to disk. One pipeline, two outputs.

ShaderMaterial. Render the linked .gdshader source as code with GLSL syntax highlighting via highlight.js. Trying to render an arbitrary user shader without running it is impossible, and running untrusted user shaders against a stub uniform set produces garbage at best. Code preview turns out to be more useful in practice. You can scan the shader and recognise it immediately, which is more than you can say for yet another generic sphere.

FastNoiseLite + Gradient. These are procedural materials with no texture references at all. The naive approach is "no textures, no preview, fall back to icon", which produces a folder full of identical blank spheres. Instead we feed the Godot 4 FastNoiseLite parameters extracted from the .tres body into the fastnoise-lite npm package, which is a JavaScript port of the same library Godot itself uses. The noise is sampled into a canvas, the gradient is applied pixel by pixel, and the result plugs into the same texture slot a real albedo map would. It will not be pixel-identical to Godot. RNG seed handling and Godot's seamless mode (4D noise sampled on a torus) differ. But visually it is equivalent, which is the point. An ice noise material looks like ice and a lava one looks like lava.

Custom resource scripts. There is no safe way to run user GDScript from an external tool, so these get an "indexed but no preview" fallback with the flat-properties list as their detail view. This is the weakest part of the current implementation and probably the area I would most welcome community input on.

Drag-out: reconstructing res://

The final piece is the drag-out behaviour, and this is the bit I am most pleased with.

When a user drags a .tres out of AssetHoard, the OS drag-and-drop pipeline expects a list of file paths. The naive implementation hands over the path to the .tres itself. The user drops it into their Godot project, and immediately discovers the textures are not there.

The fix is conceptually simple. Before the drag begins, build a temporary directory containing the .tres and every file in its dependency graph, arranged in the res:// layout each file expects. Hand the OS that whole tree as the drag payload. The user drops it, the operating system copies the lot, and the .tres finds its textures because the relative paths still resolve.

The drag-out logic lives in commands/tres_drag.rs. Two Tauri commands cover the cases: stage_tres_for_drag for one or more .tres assets dragged directly, and stage_tres_bundle_for_drag for dragging a bundle whose contents include .tres files. The bundle command merges the trees so the drop lands as a single self-contained project root rather than per-asset subdirectories.

Layout reconstruction is direct: the staging root is the project root. Every reference lands at <staging_root>/<res_path stripped of "res://">, and the .tres itself goes at the staging root using just its filename. After the user drops the staging tree into a Godot project, the res:// references resolve from the new location.

let staging_root = std::env::temp_dir()
    .join("assethoard_drag")
    .join(format!("tres-{}", uuid::Uuid::new_v4()));

Source priority for each reference is resolved_asset_id first (use the library copy, which is canonical and never stale), then disk_path if it still exists, then skip if missing. A join_relative helper walks the path segment by segment, dropping .., . and empty segments, and replacing Windows-illegal characters (\ : * ? " < > |) so a malformed res:// path cannot escape the staging root. Files are copied via std::fs::copy rather than symlinking. Symlinks on Windows need elevation, the asset manager has no idea what filesystem the drop target sits on, and a copy is the only thing that survives a drop into a network share or a USB drive.

Lifetime is per-drag, not per-process. The frontend gets back a staging_root path plus a list of dragged_paths (the top-level entries inside the staging root, since dragging the staging root itself would prefix every res:// with the folder name and break resolution). When the OS drag-completed callback fires, the frontend invokes cleanup_tres_drag_staging, which remove_dir_alls the staging directory while refusing to touch anything outside the assethoard_drag namespace as a safety check. As belt-and-braces against a crash mid-drag leaving directories behind, cleanup_old_drag_staging runs on app startup and sweeps any tres-* directories with stale mtimes.

The drag is best-effort, not all-or-nothing. Missing dependencies are skipped with a debug log rather than aborting, so the user gets a valid tree of whatever did resolve and can fill the gaps by hand. The references panel has already surfaced anything in the missing bucket before they get to drag, so this is not a surprise.

Within a single drag, identical sources are deduped and target-path collisions follow first-write-wins, with a warning logged. A real collision means the resolver is wrong upstream.

The behaviour is always-on for .tres assets and not user-configurable.

What is next

A few things I am still working on or thinking about.

UID-based path recovery. UIDs are parsed and stored on the [gd_resource] header and on each [ext_resource] block, but resolution is path-only today. When a referenced file moves and the path goes stale, falling back to a library-wide UID index is the planned recovery path. Tracked as a separate card.

Custom resource scripts. Anything driven by user GDScript currently gets the "indexed but no preview" fallback. The cleanest path forward is probably a render hint that resource authors can embed in their own resources, which is something I would want to coordinate with the Godot community before defining. Would love to hear what shape that should take.

Scene file (.tscn) parsing. Scene files share most of the resource format and would unlock a lot. Currently in scope but not in v0.1.13.

GDExtension resources. Outside the scope of what an external tool can reasonably parse without engine-specific knowledge. Probably an "indexed but no preview" forever, unless GDExtension authors want to ship metadata alongside their resources.

Extracting godot_variant as a crate. The lexer and parser module is std + serde only on purpose. If there is appetite for a published crate that handles Godot 3 and Godot 4 Variant grammar with graceful error recovery, get in touch.

If you have run into adjacent problems, whether that is building tooling that consumes Godot resources from outside the editor, or wrestling with the format yourself, I would genuinely like to hear about it. Discord or the contact form.

AssetHoard is a local-first asset manager for indie game devs and digital artists. The Godot work shipped in v0.1.13. Open beta, free during beta, runs offline. Feature overview at assethoard.com/godot-asset-manager.

Mark

If you've spent any time building games as an indie developer, you've probably hit the same wall: a folder full of assets that's completely out of control. Hundreds of sprites, sound files, models, textures, and Unity packages, organised by a naming convention you invented two years ago and have since partially abandoned. The folder called "final" next to the folder called "final_v2" next to the folder called "actually_final".

The obvious solution is an asset manager. The question is which one, and whether it needs to be online at all.

The problem with cloud-first tools

A lot of creative tools have gone cloud-first. It makes sense from a business perspective: recurring revenue, easy updates, cross-device sync. But for game developers, it introduces a set of problems that don't get talked about enough.

Connectivity is the obvious one. Game developers work everywhere. On trains with patchy mobile signal, at game jams where the venue wifi is already overloaded, in coffee shops with paywalled connections, on planes. If your asset library lives behind a login screen and an internet connection, you're stuck the moment you lose signal.

Then there's data ownership. If your assets and all the organisational work you've done (the tags, the collections, the metadata) live on someone else's server, you're renting access to your own library. Cloud tools shut down. Companies get acquired. Services pivot. When that happens, your organisational work evaporates. You get an email saying you have 30 days to export what you can, and then it's gone.

Worth checking the terms of service while you're at it. A surprising number of "free" creative tools quietly grant themselves a perpetual licence to your uploads, or reserve the right to use them for "improving our services" (read: training the next generative model on the concept art you spent six months on). Your assets are your IP. They shouldn't be someone else's training data.

And then there's subscription fatigue. Indie devs are already juggling engine licences, hosting costs, asset store purchases, and a dozen other recurring expenses. Another $5 or $10 a month tool adds up. A tool that helps you organise files you already own shouldn't itself be a recurring bill.

An offline, local-first approach sidesteps all of this. Your data lives on your machine. No connection required. No account to log into. No risk that the company folds and takes your library organisation with it.

What to look for

Not all offline tools are equal. A few things actually matter for game development specifically.

Local storage is the baseline: all data on your machine, no cloud dependency. From there, format support is where a lot of general-purpose tools fall short. Game development uses formats that design tools have never heard of: .unitypackage, .aseprite, .tres, .gdscript, .fbx, .gltf, .blend. An asset manager that only handles images and videos isn't much use when half your library is game-engine-specific files.

You shouldn't need an account. You should be able to install the thing and start using it immediately, without creating yet another login or agreeing to yet another privacy policy. Pricing should match: a tool that organises your files is a utility. It should be bought, not rented.

Preview capabilities are the next thing. Filenames alone aren't enough. You need to be able to see what a file actually is, whether that is viewing a 3D model, playing a sound, or previewing an animated sprite, without opening a separate application for each one.

And finally, tagging and search. Folders scale reasonably well up to a few hundred files. Past that, you need a proper tagging and search system, because hierarchical folder structures break down when a single asset fits into multiple categories.

The options

Manual folder systems

This is where everyone starts, and for good reason: it's free and requires no setup. For small libraries, say the assets for a single project, it works fine.

The problems start when your library grows across multiple projects. There's no preview beyond what your OS provides. Tagging doesn't exist. Search is limited to filenames. Duplicate files accumulate. You end up with a sprawling directory structure that only makes sense to you, and only barely.

Folders are a perfectly reasonable starting point. They stop being sufficient once you have more files than you can hold in your head.

Eagle.cool

Eagle is a polished visual file organiser with a nice interface and a solid tagging system. It handles images and video well, has a clean design, and costs $29.95 as a one-time purchase. For designers and illustrators, it's genuinely excellent.

For game developers, it falls short in some important ways. There's no support for .unitypackage or other engine-specific formats. 3D model preview isn't there. Drag-to-engine workflow isn't part of its design, because it wasn't built with game engines in mind. Eagle is a great tool aimed squarely at designers. If your asset library is primarily images, it's worth considering. If it's primarily game assets, you're using a tool that wasn't made for your use case.

Hydrus Network

Hydrus is free, open source, and extraordinarily powerful. Its tagging and search capabilities are genuinely impressive. It's built around the kind of detailed metadata management that booru-style image collections use, and it handles large libraries well.

The trade-off is complexity. The UI is dense and technical. Getting it set up and configured to your workflow takes real time and effort. And critically, it's built around images. There's no 3D model preview, no game package inspection, no concept of engine integration. It's a powerful tool for a specific use case, and that use case isn't game development.

If you want maximum tagging control and are willing to invest time learning the tool, Hydrus is worth exploring. If you want something you can use immediately with game-specific files, it's not the right fit.

AssetHoard

AssetHoard is a game asset manager built specifically for indie developers and artists. It supports 80+ game-development-specific file formats: .unitypackage, .aseprite, .tres, .krita, .fbx, .gltf, .blend, .wav, .ogg, and more.

Preview is built in for everything: 3D models with rotation, animated sprites, audio waveforms, texture tiling. You can tag assets, search across your entire library, and drag files directly into Unity or Godot. No account required. No subscription. One-time purchase at $29.

It runs on Windows and Linux, with macOS support in development.

It's narrower than Hydrus in terms of tagging depth, and it doesn't have Eagle's visual polish. What it does have is a focused set of features for the actual game development workflow, built around the file formats you're actually using.

Picking one

The best tool depends on your library size and what you're actually working with.

Folders work fine for small collections and single projects. Eagle is a good choice if your library is primarily images and you want a well-designed, general-purpose organiser. Hydrus is for power users who want deep tagging control and are willing to spend time on configuration.

If you're a game developer with a growing library of engine packages, 3D models, sprites, and audio (formats that general tools don't understand), then a purpose-built local-first asset manager is worth the investment.

You drag a 32x32 sprite into your asset browser. Something you spent an afternoon getting right, every pixel placed deliberately. The preview comes up. It looks like someone has rubbed butter on the screen.

This is not your fault, and it is not the sprite's fault. It is the rendering pipeline, and almost every general-purpose tool you have ever used gets it wrong by default.

What is actually happening

When a tool displays an image at a size different from its native resolution, it has to invent the missing pixels. There are two main approaches.

The first is interpolation. The renderer looks at the source pixels around each output pixel and blends them together to produce a smooth gradient. This is called bilinear or bicubic filtering, depending on the algorithm. It is excellent for photographs, where soft transitions between colours match how the real world actually looks. A photo upscaled with bilinear filtering looks natural. The eye accepts the smoothing because real surfaces do not have hard pixel boundaries.

The second is nearest-neighbour. Instead of blending, the renderer simply picks the closest source pixel for each output pixel. No averaging, no smoothing, no invention. The result is a clean grid where every source pixel becomes a perfect square block.

For pixel art, you want the second one. Always.

And here is the thing. Pixel art is not low-resolution photography. Every pixel in a good sprite is there on purpose. The artist sat with a four-pixel sword tip and decided whether the highlight should be one pixel or two. They placed antialiasing by hand on the edges that needed it and left the others sharp. The whole point of the medium is that the grid is the canvas, not a limitation to be papered over.

Bilinear filtering takes all of that careful work and averages it into mush. The single-pixel highlight gets smeared into the blade. Hand-placed antialiasing turns into generic blur. Hard silhouettes that read cleanly at native resolution dissolve into soft halos. The render pipeline is doing what it thinks is helpful, except the help is undoing the work.

Nearest-neighbour just gets out of the way. Whatever the artist made survives the scaling, only larger.

Why so many tools get it wrong

Two reasons, both reasonable in isolation.

The first is that photographs vastly outnumber pixel art in any general-purpose image pipeline. If a tool has to pick one default behaviour, picking the one that works for the majority is the safe choice. Bilinear filtering is fine, even good, for almost every image that is not pixel art.

The second reason is harder. Detecting pixel art automatically is not trivial. There is no metadata flag inside a PNG that announces "I am pixel art, please render me crisply." The information has to be inferred from the image itself, and any single signal can be misleading.

Small dimensions are a hint, but plenty of pixel art lives at 512x512 or larger, and plenty of photos exist at thumbnail sizes. A limited colour palette is a hint, but a stylised illustration might also have few colours. Hard edges are a hint, but high-contrast photography has hard edges too. No single check is reliable on its own.

So most tools shrug and pick the safe default. Bilinear for everything. Pixel artists then spend years either ticking the same "disable smoothing" checkbox in every tool they use, or accepting that previews are going to lie about what their work actually looks like.

What good detection looks like

The trick is to combine signals rather than rely on any single one. A reasonable stack might check:

• Image dimensions. Pixel art tends to live below a certain size threshold, particularly for sprites and tiles. This is a soft signal, not a hard rule.
• Unique colour count. Palette-limited art typically has far fewer distinct colours than a comparable photograph. A 64x64 image with twelve unique colours is almost certainly pixel art. The same image with eight thousand colours is almost certainly not.
• Edge transition analysis. Pixel art has hard transitions between adjacent pixels rather than gradients. Counting how often neighbouring pixels differ sharply gives a useful signal.
• File source hints. If an image came out of Aseprite, Pyxel, or any of the established pixel art tools, that is a strong signal in itself. Some of these tools embed identifying metadata that can be detected.

Combine those signals into a confidence score. Above a threshold, render with nearest-neighbour. Below it, fall back to bilinear. Then expose an override so the user can correct the edge cases without ceremony.

This is not glamorous engineering. It is a stack of heuristics, none of which are perfect, that together get the right answer often enough to be useful. The win is that the user stops thinking about it. They drag their sprite in, and it just looks right.

What to look for in a tool

If you work with pixel art, the question to ask of any new asset manager, file browser, or preview tool is straightforward: does it render pixel art correctly without me having to configure anything?

A few specific things to check:

• Drop a 32x32 sprite in and look at the preview. Are the pixels crisp blocks, or is the image soft and blurred?
• Try a 16x16 tile. Tiny art exposes interpolation problems most aggressively.
• Check whether the tool offers a per-asset override. Auto-detection will sometimes get it wrong, and you want to be able to fix individual cases without affecting everything else.
• See whether the setting persists. A tool that requires you to enable crisp rendering every time you open it is barely better than one that does not support it at all.

If the tool fails the first check, the rest does not matter. You will spend the relationship fighting it.

How AssetHoard handles this

AssetHoard ships with automatic pixel art detection as of v0.1.12. When you import images, the tool examines each one against a stack of heuristics and renders pixel art with nearest-neighbour scaling by default. No checkbox to find. No setting to remember.

If the detection misclassifies something, you can override on individual assets, or set the rendering mode at a category level so every sprite or tile inside inherits it automatically. The detection runs at import time, so existing libraries pick up the new behaviour as you add to them.

This is the first feature in a broader renderer system. Future renderers will handle 3D models, materials, and engine-specific package formats with the same principle: detect what the asset actually is, then render it the way the artist intended.

If you have been fighting blurry previews in your asset browser, give AssetHoard a try. It is in open beta, free to use during the beta, and runs entirely on your own machine.

Mark

If you have spent any time with 3D assets, you have seen both terms thrown around as if they are interchangeable. They are not. PBR and ORM operate at different levels of the pipeline, and understanding the distinction saves a lot of confusion when importing materials between engines.

PBR is the lighting model

PBR stands for Physically Based Rendering. It is a shading approach that simulates how light actually behaves, with energy conservation, microsurface scattering, and Fresnel effects baked into the maths. A PBR material is driven by a stack of greyscale and colour textures: base colour (sometimes called albedo), normal, roughness, metallic, and ambient occlusion, often with emissive or height on top.

The shader reads those inputs and produces results that look consistent under different lighting. A rusted iron surface looks rusted whether it is sitting in a sunlit field or a dim warehouse, because the maths accounts for the physics rather than faking it per-scene.

The textures that feed it

A PBR material is not one texture, it is a small bundle of them. Each one describes a different physical property of the surface. Here is what you will typically see in a material folder:

brick_wall/
├── brick_wall_basecolor.png     (or _albedo, _diffuse, _col)
├── brick_wall_normal.png        (or _nrm, _n)
├── brick_wall_roughness.png     (or _rough, _r)
├── brick_wall_metallic.png      (or _metal, _m)
├── brick_wall_ao.png            (or _occlusion, _occ)
├── brick_wall_height.png        (or _displacement, _disp, _h)  [optional]
└── brick_wall_emissive.png      (or _emission, _e)             [optional]

What each one does:

• Base colour is the raw surface colour with no lighting baked in. Think of it as what the surface would look like under flat, shadowless light. This is the only map stored in sRGB colour space. Everything else is linear data.
• Normal fakes surface detail by telling the shader which direction each pixel is facing. It is why a flat plane can look like a bumpy brick wall. Usually purple-blue in appearance.
• Roughness is greyscale. Black is a mirror, white is chalk. It controls how sharp or blurred reflections are.
• Metallic is also greyscale, and almost always close to pure black or pure white. Black means non-metal (plastic, wood, stone, skin). White means metal (iron, gold, aluminium). Values in between are rare outside of transition areas like rust.
• Ambient occlusion darkens crevices and contact points where light would naturally struggle to reach. Grayscale, white is fully lit, black is fully occluded.
• Height (sometimes called displacement) pushes the actual geometry in or out. More expensive than normal mapping but produces real silhouette detail.
• Emissive makes parts of the surface glow independently of scene lighting. Usually black everywhere except the glowing bits.

Naming conventions are not standardised. Some packs ship _diffuse instead of _basecolor. Some use _nrm instead of _normal. You will learn to recognise them by suffix.

ORM is a texture packing format

ORM stands for Occlusion, Roughness, Metallic. It is a way of packing three of those greyscale maps into the RGB channels of a single image:

• R channel holds Ambient Occlusion
• G channel holds Roughness
• B channel holds Metallic

This is purely an optimisation. Each of those three maps is single-channel data, so storing them as separate RGB textures wastes two-thirds of every file. Packing them together means one texture sample instead of three, less VRAM consumed, and fewer draw call overheads. It is standard practice in modern real-time pipelines.

How each engine handles it

Unreal Engine uses the standard ORM layout. Red is occlusion, green is roughness, blue is metallic. Most Unreal-ready materials on marketplaces ship with a base colour, normal, and ORM texture, sometimes with a separate emissive. The material editor expects this convention out of the box.

Unreal ORM:
├── R channel → Ambient Occlusion
├── G channel → Roughness
└── B channel → Metallic

Godot matches Unreal's convention through ORMMaterial3D. Red is occlusion, green is roughness, blue is metallic. You assign the packed texture and the engine handles channel splitting automatically. This also matches the glTF 2.0 metallic-roughness spec, which is the closest thing to a cross-engine standard.

Godot ORM (and glTF 2.0):
├── R channel → Ambient Occlusion
├── G channel → Roughness
└── B channel → Metallic

Unity does its own thing. Note that as of 2026, Unity has announced HDRP is going into maintenance mode and URP is becoming the primary rendering pipeline going forward, so URP is the convention to care about for new work.

URP's Lit and Complex Lit shaders support a channel-packed texture, but the layout is completely different from Unreal and Godot:

Unity URP (Lit/Complex Lit):
├── R channel → Metallic
├── G channel → Occlusion
├── B channel → (unused)
└── A channel → Smoothness (inverse of roughness)

Two things to note. First, red is metallic in Unity but occlusion in Unreal, so a texture packed for one engine will render incorrectly in the other without channel swapping. Second, Unity uses smoothness instead of roughness. Smoothness is the numerical inverse: a roughness value of 0.2 becomes a smoothness value of 0.8. Importing an Unreal-style ORM into Unity without conversion gives you materials that look wrong in a way that is hard to diagnose.

HDRP's Mask Map is similar but uses the blue channel for a detail mask:

Unity HDRP Mask Map (maintenance mode):
├── R channel → Metallic
├── G channel → Occlusion
├── B channel → Detail mask
└── A channel → Smoothness

Unity's older Built-in Render Pipeline Standard shader packed smoothness into the alpha channel of the metallic map with no occlusion or detail slot, which is yet another convention you will still encounter in legacy projects and older asset packs.

Blender does not have an engine preference of its own. It reads individual texture inputs on the Principled BSDF node, so working with a packed texture means using a Separate Color node to split the channels before feeding each one to the correct shader input. Most Blender addons for PBR import handle this automatically, but it is worth knowing what is happening underneath. Because Blender is agnostic, it is also the most useful place to unpack and repack textures between conventions.

The quick comparison

If you are shipping assets for multiple engines, your safest bet is to distribute individual unpacked maps alongside a pre-packed ORM for Unreal and Godot, and leave Unity users to repack using their own convention.

Where to find free samples

These are the reliable CC0 sources:

• Poly Haven has 4K and 8K PBR textures with full map sets, CC0 with no attribution required
• ambientCG (formerly CC0Textures) has more than 2,000 PBR materials, also CC0
• CG Bookcase offers 500+ PBR textures with no account required
• TextureCan has 4K-minimum textures with SBSAR files for procedural tweaking
• ShareTextures covers wood, stone, metal, and ground textures up to 4K

Most of these deliver individual PBR maps rather than pre-packed ORM textures. If you need an ORM for Unreal or Godot, you can pack one yourself in any image editor by assigning AO to the red channel, roughness to green, and metallic to blue. ImageMagick does it in a single command, and most DCC tools have built-in or plugin-based packers. If you would rather not touch the command line, an AssetHoard user has created Tiko Developments Texture Packer Tool, a browser-based packer that outputs ORM layouts for all Unreal, Unity (HDRP, SRP and URP), gLTF, Godot, and even custom.

The practical takeaway

PBR is the workflow. ORM is one way of organising the textures that feed it. When someone says a material is "PBR," they mean it works with a physically based shader. When they say it is "ORM packed," they mean the three greyscale maps are already combined into one file.

Knowing which is which makes it much easier to troubleshoot when a material looks wrong after import. Nine times out of ten, it is a channel convention mismatch rather than a broken texture.

If you work with a lot of PBR materials across different engines, keeping them organised gets painful fast. AssetHoard is a local-first desktop asset manager built for exactly this kind of library. It is free during open beta.

The AssetHoard Team

Eagle.cool has built up a loyal following among digital creatives, and for good reason. If you've been using it to organise your reference images and design assets, you already know it's a genuinely well-made piece of software. But if you're a game developer, you've probably also hit its limits.

This is a straightforward comparison of what Eagle does well, where it falls short for game-dev workflows, and whether AssetHoard might be a better fit for your library.

What Eagle does well

Let's start with the positives, because Eagle earns them.

The UI is clean and thoughtfully designed. Browsing large collections of images and video references feels snappy, and the thumbnail previews are excellent. The tagging system is flexible. You can colour-code tags, nest them into groups, and filter your library in ways that actually make sense for visual work.

The browser extension is one of Eagle's standout features. Saving reference images from the web directly into your library, with the source URL automatically attached, is genuinely useful for mood boards and inspiration collections.

Audio handling is also solid. Eagle renders snappy waveform previews and supports inline playback, so auditioning sound effects or music loops while browsing feels fluid rather than clunky.

Format support is broad for design work: PSD, AI, EPS, Sketch, Figma exports, RAW photos, video files. The annotation tools let you mark up images and build out proper mood boards. Many game developers start with Eagle and get real value from it, particularly early in a project when you're gathering references and building a visual direction.

Where Eagle falls short for game developers

Eagle was built for graphic designers and illustrators, and that's exactly where its gaps appear when you try to use it as a game asset manager.

Limited 3D model format coverage. Eagle previews FBX, OBJ, and STL, which covers some of the basics, but it doesn't handle glTF/GLB, Blender (.blend), or Collada (.dae). If your library leans on glTF (Godot's preferred format) or includes raw Blender files, those sit as flat icons.

Limited 3D animation playback. Eagle's 3D viewer can show a model, but animation playback is restricted. Scrubbing through an idle loop, checking a walk cycle, or confirming a rig animates the way you expect often means opening the file in another tool.

No material file support. Material files like .mtl, .mtlx (MaterialX), .mat (Unity), and Substance .sbsar / .sbs aren't recognised by Eagle. They sit in your library as opaque files with no preview of what the material actually looks like.

No material sphere rendering. Even when textures are organised as a PBR set, Eagle can't render them on a 3D sphere with proper lighting to show you the actual surface. You're inspecting maps, not materials.

No .unitypackage support. Unity Asset Store packages are a staple of many game developers' workflows. Eagle can't inspect or browse the contents of a .unitypackage file. You'd have to import it into Unity just to see what's inside.

No Godot resource support. If you're working with Godot, your library is likely full of .tres, .tscn, and .res files. Eagle doesn't understand these formats, so they just sit there unlabelled.

No Aseprite preview at all. Eagle doesn't render .aseprite files. If you're working with pixel art, you'll see an unsupported-format placeholder rather than the artwork or its animation.

No pixel-perfect sprite rendering. Eagle displays pixel art using a blended renderer, which works great for sunsets or pictures of people, but pixel art needs precise rendering at any scale. For pixel artists, that turns the library into a wall of soft, distorted thumbnails.

No PBR texture set grouping. A single PBR material typically comes as a set of textures: albedo, normal map, roughness, metallic, ambient occlusion. Eagle doesn't understand the relationship between these files, so they sit separately in your library with no indication that they belong together.

No Linux support. Eagle runs on Windows and macOS only. If your development machine is Linux, Eagle is off the table entirely, which rules it out for a meaningful slice of indie and open-source game developers.

None of these are criticisms of Eagle as a product. They're just evidence that it was designed with a different user in mind.

AssetHoard as an alternative

AssetHoard was built specifically for game developers and artists who are managing the kind of files that Eagle can't handle well.

Format support covers 80+ types including .unitypackage, .aseprite, .krita, .fbx, .gltf/.glb, .blend, .dae, .obj, .stl, the full range of common image and audio formats, plus material files like .mtl, .mtlx, .mat, and Substance .sbsar / .sbs.

The 3D model browser lets you rotate, zoom, and play back animations directly in the app, useful when you're trying to decide between three similar character rigs. Models from .blend, .gltf/.glb, .fbx, .dae, and .obj all sit alongside one another in the same library.

If you work with Unity, the Unity asset manager workflow lets you inspect .unitypackage contents without importing into Unity first. You can see exactly what's in a package, browse its assets, and decide whether it's worth bringing into your project. For Godot users, the Godot asset manager handles .tres, .tscn, and .res files alongside the rest of your library.

Aseprite files have full animation support, with frame-by-frame playback rather than the frozen previews you'll see elsewhere. Pixel art is detected automatically at import (by dimensions, palette, or format) and rendered with a precise pixel renderer, so sprites stay crisp at every zoom. If the auto-pick gets it wrong, you can override the renderer per asset, per bundle, or per category.

PBR texture sets are grouped automatically so albedo, normal, and roughness maps are shown together rather than scattered across your library. Material files render on a live 3D sphere with proper lighting, so you can see what a surface will actually look like before bringing it into your engine.

When you're ready to use an asset, you can drag it directly into Unity or Godot. No intermediate steps.

It's local-first. Your library lives on your machine, no cloud sync, no account required.

Honest trade-offs

AssetHoard isn't better at everything, and it's worth being clear about that.

Eagle has a larger community and more integrations with design tools. Its browser extension for collecting web references is excellent and has no equivalent in AssetHoard. If you're regularly saving inspiration from the web, that's a genuine advantage.

Eagle handles a broader range of general design formats (AI, EPS, Sketch exports), which matters if your work is more aligned to graphic design.

On platform support, the situation is reversed. AssetHoard runs on Windows, macOS, and Linux, while Eagle is Windows and macOS only. If you're on Linux, AssetHoard is the only one of the two that will work for you.

Which one is right for you

If you're primarily a graphic designer or illustrator who occasionally works on game projects, Eagle is probably the better fit. Its strengths align well with that workflow.

If you're a game developer managing a growing library of .unitypackage files, Godot resources (.tres, .tscn, .res), 3D models, sprite sheets, Aseprite animations, and audio assets, AssetHoard is built for exactly that workflow in a way Eagle isn't.

If you use both Unity or Godot and professional design tools heavily, you might find yourself reaching for both. They serve different enough use cases that there's not much overlap.

The simplest test: look at your asset library and count how many files are game-specific formats versus general design formats. That ratio will tell you which tool is doing more work for you.

The AssetHoard Team

If you have been making games for more than a year, you probably have a problem.

It starts innocently enough. A Humble Bundle here, a free asset pack from itch.io there, a few purchases from the Unity Asset Store, some textures you grabbed from a Blender artist's Gumroad. The Kenney all-in-one pack alone is over 140,000 files. Before long you have hundreds of thousands of files spread across a dozen directories, and every time you sit down to work on a project you spend the first twenty minutes just trying to remember where you put that tileset.

I have been there. This is what I learned.

The Directory Problem

The instinct most developers have is to organise assets into folders. Environment, Characters, Audio, UI, and so on. It feels logical. It falls apart immediately.

The first issue is that folder structures are rigid. When you buy a pack from Kenney, it arrives with its own folder hierarchy. So does the next pack, and the one after that. You end up with either a mess of inconsistently structured vendor directories, or you spend hours manually reorganising files into your own structure -- only to repeat that work every time you download something new.

The second issue is that moving files breaks things. If a project already references an asset at a particular path, renaming or relocating it silently breaks that reference. So you stop moving things. The folder chaos becomes permanent.

The third issue is that folders only express one dimension of organisation at a time. An asset can only live in one folder. But a leather texture might belong under Materials, or under Fantasy Environment Pack, or under Assets Bought in 2024. Pick one and you lose the rest.

Finding Assets Is Worse Than Organising Them

Imagine you are building a level and you need "rain" assets. You have them. Somewhere.

Except rain assets do not live in one place. The rain sound effect is in audio/ambient/nature/. The thunder loop is in Sonniss_GDC_Pack_2019/weather/. The water droplet impact sounds are in RPG_Sound_Pack/effects/. The lightning bolt sprite is in VFX_Essentials/particles/. The rain particle system is in UnityAssetStore/Weather_System_Pro/. And somewhere in a Blender pack you downloaded there are umbrella 3D models that would be perfect for a character prop.

No folder structure in the world connects those dots. You find the first thing you remember, forget the rest exist, and end up with an incomplete scene.

The Catalogue Approach

The shift that actually worked for me was separating the catalogue from the directory.

Instead of treating your folder structure as the source of truth, you treat it as storage. Dumb storage. Assets stay wherever they landed. Your catalogue is the layer on top that knows what everything is, where it lives, and how it relates to everything else.

This is how AssetHoard works. You point it at your asset directories and it indexes everything in place. Nothing moves. Nothing breaks. Your project file references stay intact.

Semantic Search Changes Everything

The rain problem is where semantic search earns its place.

When you search for "rain" in AssetHoard, you are not just matching filenames. The search understands context. It surfaces rain sound effects, yes, but also thunder recordings, water droplet impacts, storm ambient loops, lightning sprites, puddle textures, wet surface materials, and umbrella models -- because those things all belong to the same conceptual space.

You go from ten minutes of directory archaeology to a single search that shows you everything relevant at once.

Tags, Categories, and Your Own Taxonomy

Every developer has a different mental model for their assets. AssetHoard does not impose one.

Tags and categories let you build the taxonomy that makes sense for how you actually think about your library. Tag assets by art style, by project, by quality rating, by mood. Categories give you a flat set of broad groupings you can apply consistently across your library. Assets can have as many tags as they need -- you are not limited to one folder.

The licence field lets you record exactly what you purchased and what it covers. Notes let you capture anything else you will definitely forget -- which pack this came from, where to download updates, quirks you discovered when you imported it.

Your Catalogue and Your Directories Are Independent

This is the detail that matters most practically.

Because AssetHoard tracks assets by reference rather than by path dependency, you can reorganise your catalogue without moving a single file on disk. Create a virtual structure that makes sense to you. Rename things in the catalogue. Reclassify them. None of it touches the directory.

Projects: Smart Folders for Active Work

When you are actively working on something, you need a different kind of organisation: not a permanent taxonomy, but a working set.

Projects in AssetHoard work like smart folders you populate yourself. You are building a horror level and need atmospheric audio, dark environment textures, and a handful of character animations. You drop them all into a project. Now everything for that level is in one place, regardless of where the files actually live in your library.

You can have multiple projects running simultaneously. Assets can appear in as many projects as you want. When the project ships, the project goes away. The library stays exactly as it was.

It Adds Up

None of this is revolutionary in isolation. Cataloguing software has existed for decades in photography and stock asset workflows. The game dev world has just been slow to adopt it.

What changes when you stop fighting your directory structure is that you start actually using the assets you own. That pack you bought eighteen months ago and never properly ingested. That artist's collection you downloaded and forgot about. They are in there. You just need a way to find them.

Until now, indie developers have not had a purpose-built asset manager made for them. That is what AssetHoard is for.

The AssetHoard Team

Welcome to the first in our Artist Spotlight series, where we chat with creators in the game dev space about their work, their process, and what they've learned along the way.

First up is Shaoul from Tesseract Assets, a 3D artist specialising in props, weapons, and stylised environments.

What kind of assets do you create, and what got you into it?

Over time, that naturally grew into building more cohesive sets and recently into stylised environments, where props really shine as part of a bigger world.

What got me into it was the mix of art and problem-solving. I've always enjoyed breaking things down visually and figuring out how they're built, and game assets sit right at that intersection of creativity and technical constraints.

What does your process look like from concept to finished asset?

From there, I block out the asset in 3D to lock in the silhouette and scale. Once the shapes feel right, I model and sometimes sculpt to final forms. Texturing comes next, where I really try to push material definition and readability, especially for stylised work.

The final steps are optimisation, testing in-engine when possible, and polishing things like roughness values, edge wear, and overall presentation so the asset holds up from different angles and distances.

What tools do you use day-to-day?

My core tools are Blender for modelling, Substance Painter for texturing, a bit of ZBrush to sculpt, and Substance Designer for some tiled textures. Unreal Engine 5 for rendering and testing.

I also rely a lot on PureRef for reference and Photoshop for quick texture tweaks or presentation work. Plus some workflow apps like Upscayl, Bulk Rename Utility, XnConvert, ShareX, and Lightshot.

What's something most people don't realise about creating 3D assets?

What's been your favourite project to work on?

My last weapon pack (Volume 5) as it's the most recent and benefits from the experience gathered doing previous weapon packs.

I'm especially proud of my recent shift toward stylised environment work. Moving from individual props and weapons into a more cohesive visual world has been really rewarding. It pushed me to think more about colour, composition, and how assets support each other rather than standing alone.

Any tips for game devs on getting the most out of assets they've bought or downloaded?

Don't treat assets as untouchable. Even small adjustments to scale, roughness, colour balance, or wear can make a big difference in how well they fit your project. Consistency matters more than individual detail.

Also, test assets early in-engine and in context. Lighting, shaders, and camera distance can completely change how something reads compared to a standalone render.

What are you working on next?

I'm continuing to expand my stylised environment work, focusing on building stronger, more complete scenes and refining my visual language. I'm also experimenting more with storytelling through props and environments, making assets that feel like they belong to a lived-in world rather than just looking good on their own.

You can find more of Tesseract Assets' work on:

• YouTube
• Fab

This is the first in our Artist Spotlight series. If you're a game asset creator and want to be featured, get in touch at mark@assethoard.com.

The Dream

We built AssetHoard to solve a problem every game developer knows: assets scattered across dozens of folders, forgotten purchases buried in download directories, and no good way to find that perfect texture you know you bought three years ago.

The tech stack was solid. Tauri 2 for the native shell, SvelteKit for the frontend, Rust for the backend, SQLite for storage. Everything worked great in testing.

Then a beta tester tried to import a large asset bundle... 120,000 files.. The app froze for minutes... shit.

The Naive Approach

Our first implementation was straightforward. Scan the folder in Rust, send the file list to the frontend, let the user configure options, then import:

#[tauri::command]
fn scan_folder(path: String) -> Vec<ScannedFile> {
    walkdir::WalkDir::new(path)
        .into_iter()
        .filter_map(|e| e.ok())
        .filter(|e| is_supported_extension(e.path()))
        .map(|e| ScannedFile::from_path(e.path()))
        .collect()
}

const files = await invoke('scan_folder', { path: selectedFolder });
// files now contains 120,000 objects
setScannedFiles(files);

Simple. Elegant. Completely broken at scale.

The IPC Wall

Tauri's invoke system is fantastic for most use cases. You call a Rust function, it returns data, TypeScript receives it as a Promise. Under the hood, it serialises your Rust structs to JSON, passes them through the webview bridge, and deserialises them in JavaScript.

For 120,000 ScannedFile objects, that meant roughly 70MB of JSON serialisation in Rust, another 70MB crossing the IPC bridge, 70MB of JSON parsing in JavaScript, and 70MB stored in JavaScript memory.

During all of this, the UI thread is blocked. No spinner. No progress. Just a frozen window and a user wondering if the app crashed.

Attempt One: Stream the Data

Our first instinct was streaming. Send files in batches of 1,000, update a progress bar, keep the UI responsive.

for chunk in files.chunks(1000) {
    app_handle.emit("scan-chunk", chunk)?;
}

Better! The UI stayed responsive. But now we had a new problem: 80 separate IPC calls, each with serialisation overhead. The scan that took 8 seconds in pure Rust now took 45 seconds with the streaming overhead.

Worse still, we had to accumulate all those chunks in JavaScript memory anyway. We had traded one 70MB transfer for eighty 625KB transfers, plus the overhead of 80 event emissions.

The Revelation: Do Not Send What You Do Not Need

We stepped back and looked at what the import process actually involved. It was not a single operation but a multistep pipeline: scan the filesystem and count files, then process metadata for each asset, then generate thumbnails for previews. For smaller imports of around 2,000 files, running this as one synchronous operation worked extremely well. The user clicked import, waited a few seconds, and everything appeared in their library.

But at 120,000 files, that same pipeline ground to a halt. And the more we looked at it, the clearer it became that we were sending data to the frontend that the frontend did not actually need.

The user does not need to see 120,000 individual files. They need to see the total file count, a breakdown by type (textures, models, audio), a list of top-level folders, and maybe some detected engine packages. Everything else can stay in Rust until import time.

The Cache Pattern

We introduced a scan cache on the Rust side:

lazy_static! {
    static ref SCAN_CACHE: Mutex<HashMap<String, Vec<ScannedFile>>> =
        Mutex::new(HashMap::new());
}

#[tauri::command]
fn scan_folder_async(path: String) -> ScanSummary {
    let files: Vec<ScannedFile> = /* ... scan logic ... */;

    let scan_id = Uuid::new_v4().to_string();
    SCAN_CACHE.lock().unwrap().insert(scan_id.clone(), files.clone());

    ScanSummary {
        scan_id,
        total_files: files.len(),
        by_type: count_by_type(&files),
        top_level_folders: extract_folders(&files),
        detected_packages: find_packages(&path),
    }
}

Now the IPC payload is tiny. Maybe 2KB instead of 70MB. The frontend gets everything it needs to show the user, and when they click Import, we just send the scan_id back:

#[tauri::command]
fn import_files(scan_id: String, options: ImportOptions) -> ImportResult {
    let files = SCAN_CACHE.lock().unwrap()
        .remove(&scan_id)
        .ok_or("Scan expired")?;

    // Import using the cached files
    // ...
}

The files never cross the IPC bridge. Rust scans them, Rust stores them, Rust imports them.

Progress Events: The Right Way

With the heavy data staying in Rust, we could use Tauri's event system for what it excels at: lightweight progress updates.

#[tauri::command]
async fn scan_folder_async(path: String, app: AppHandle) -> ScanSummary {
    let mut files = Vec::new();

    for entry in WalkDir::new(&path) {
        if let Ok(e) = entry {
            if is_supported(&e) {
                files.push(ScannedFile::from(&e));

                if files.len() % 1000 == 0 {
                    app.emit("scan-progress", ScanProgress {
                        files_found: files.len(),
                        current_path: e.path().display().to_string(),
                    })?;
                }
            }
        }
    }

    // Cache and return summary...
}

Now the frontend receives a lightweight event every 1,000 files. Just two fields, maybe 200 bytes. The UI updates smoothly, the user sees "Scanning... 45,000 files found", and Rust keeps churning through the filesystem.

Send to Background

But what if the user does not want to watch a progress bar? What if they want to keep browsing their existing library while the scan runs?

We added a Send to Background button that appears after 2 seconds of scanning. Click it, and the dialog closes, a notification appears in the header with live progress, and when complete, clicking the notification reopens the import dialog with all the options ready.

This required a scan session system. A way to track that a background scan belongs to a specific notification, and when complete, the notification knows how to resume the import flow.

function handleSendToBackground() {
    const notifId = createNotification('import', `Scanning ${folderName}`, {
        progress: { current: scanProgress, total: scanProgress },
        status: 'in_progress',
    });

    const sessionId = createScanSession(folderPath, notifId);
    backgroundScanSessionId = sessionId;
    backgroundNotifId = notifId;

    importDialogOpen.set(false);
    // Original scan continues running...
}

The Subtle Race Condition

This is where we learned a painful lesson about async state management.

Our first implementation of Send to Background cancelled the current scan (set SCAN_CANCELLED = true), closed the dialog, and started a new scan in the background. Seemed logical.

But there was a bug. In Rust, every scan starts by resetting the cancellation flag:

fn scan_folder_async(...) {
    SCAN_CANCELLED.store(false, Ordering::SeqCst);  // Reset flag
    // ... scan logic that checks SCAN_CANCELLED ...
}

When we started the new background scan, it immediately cleared the cancellation flag before the original scan had checked it. Result: two concurrent scans, both running, both emitting progress events, interleaving their results.

The fix was embarrassingly simple: do not start a new scan. The original scan is already running. Just set up the notification tracking and let it complete.

Results

Before optimisation, 120,000 files caused a 47 second freeze. Users reasonably assumed the app was broken.

After optimisation, 120,000 files scan in 8 seconds with live progress. Users can send to background and keep working. Memory usage dropped by roughly 70MB because the files never hit the JavaScript heap.

Lessons Learned

IPC is not free. Treat the Tauri bridge like a network call. Minimise payload size, batch intelligently, and do not send data you do not need on the frontend.

Keep heavy data where it belongs. If Rust is going to use the data anyway, let Rust hold it. Send summaries and IDs across the bridge, not raw data.

Events are for progress, not data transfer. Tauri's event system is great for lightweight updates. Do not abuse it as a chunked data transfer mechanism.

Async state is tricky. When you have operations that can be cancelled, restarted, or sent to background, trace through every possible interleaving. Race conditions hide in the gaps.

The user's time is sacred. A frozen UI is not just a performance problem. It is a trust problem. If users cannot tell whether your app is working or crashed, they will assume crashed.

The AssetHoard Team

Last updated April 2026

Asset hunting is one of the great time sinks of indie game development. You sit down to build a level and somehow lose the morning to forum threads, broken Patreon links, and downloads that turn out to be 32x32 placeholders in disguise.

The good news is that 2026 is a genuinely excellent year to be doing this. Plenty of artists, studios, and one-person operations now release HD, professional-quality work for free, often under licences that let you ship commercially without attribution.

Here are 15 sites worth bookmarking, grouped by what they're best at.

We've also gathered the best CC0 picks from across these sites into a single free game assets directory you can filter by type, style, and engine, then jump straight to the source. It's a good starting point before you go spelunking through the full catalogues below.

The All-Rounders

These sites cover multiple asset types and should be your first stops.

itch.io

The indie darling of game distribution also happens to be one of the best places to find free assets. Head to itch.io/game-assets/free and you'll find everything from pixel art character sprites to complete game kits with 3D models, audio, and animations bundled together.

The curation is decent, the community is active, and you can filter by asset type, art style, and licence. Many creators release their work under CC0 (public domain), meaning you can use it commercially without attribution.

Best for: 2D sprites, pixel art, complete game kits, audio packs

OpenGameArt.org

The granddaddy of free game assets. OpenGameArt has been around for over a decade and hosts a massive collection of 2D art, 3D models, music, and sound effects—all under open licences like CC0, CC-BY, or GPL.

The search tools are... functional, let's say. But the depth of the library makes up for it. You'll find everything from retro pixel art to orchestral soundtracks.

Best for: Large variety, open-source projects, finding hidden gems

Kenney

If you don't know Kenney, you're missing out. This one-person operation has released over 40,000 assets—all CC0, all free, no sign-up required. The art style is clean, colourful, and remarkably consistent across packs, which means you can mix and match assets without your game looking like a ransom note.

The kenney.nl site offers 2D assets, 3D models, UI elements, fonts, and audio. There are also free tools like Asset Forge for creating your own 3D models.

Best for: Consistent art style, rapid prototyping, UI elements

Unity Asset Store (free section)

Unity's free asset filter sits inside a paid marketplace, which makes it easy to overlook, but the free catalogue is enormous. Big publishers regularly release free packs to seed adoption of their commercial ones, and Unity itself publishes high-quality demo assets and starter kits.

Worth a periodic browse rather than a one-off visit. Licences vary across publishers, so check each pack before shipping.

Best for: Unity-ready 2D and 3D packs, demo content, professional publishers

2D Assets

CraftPix

CraftPix.net offers free 2D game assets including tilesets, character sprites, backgrounds, icons, and GUI elements. Their "Game Kits" are particularly useful—complete sets with everything you need for a particular genre or theme.

The freebies are a subset of their paid catalogue, so quality is generally solid. Assets work well with engines like Unity, Godot, and Construct.

Best for: 2D platformers, RPGs, mobile games

Chequered Ink

A smaller studio that releases pixel art assets alongside their commercial games and fonts. You'll find character sprite packs, inventory icons, platformer tilesets, and UI graphics—all free for commercial use.

Check their free game assets section for regular updates.

Best for: Pixel art, retro-styled games

3D Models

Quaternius

If you're making a 3D game with a stylised low-poly look, Quaternius is essential. This Argentinian artist has released thousands of models—characters, animals, vehicles, environments, weapons—all under CC0.

The signature "Quaternius style" is instantly recognisable: clean geometry, bright colours, charming animations. Assets come rigged and animated, ready to drop into Unity, Unreal, or Godot.

Best for: Low-poly 3D games, stylised aesthetics, animated characters

Poly Haven

Poly Haven started as HDRI Haven and has grown into a comprehensive library of 3D models, HDRIs, and textures—all CC0. The models tend toward realistic props and environmental pieces rather than stylised game assets, but they're high quality and instantly usable.

No sign-up required. Just download what you need.

Best for: Realistic 3D assets, environment art, lighting reference

Sketchfab

Sketchfab is primarily a 3D model marketplace, but there's a substantial collection of free downloads. Filter by "Downloadable" and check the licence for each asset—many are CC0 or CC-BY.

The built-in 3D viewer lets you inspect models before downloading, which saves time.

Best for: Browsing and previewing 3D models, varied styles

Mixamo

Mixamo is Adobe's free library of rigged characters and motion-captured animations. Sign in with an Adobe ID, pick a character, and apply any animation in the library. Everything is free for commercial use, with no royalties or attribution required.

The animation set covers walks, runs, combat, idles, and more abstract dance and gesture clips. There is also auto-rigging for custom characters you bring in yourself, which saves a serious amount of time if rigging is not your strong suit.

Best for: Rigged 3D characters, motion-capture animations, prototyping movement

Textures and Materials

ambientCG

Formerly CC0Textures, ambientCG offers over 2,000 PBR materials, HDRIs, and 3D models—all completely free under CC0. Materials come with all the maps you need: albedo, normal, roughness, metallic, height, and ambient occlusion.

Assets are available in resolutions up to 8K (or even 16K for some), and Substance Designer source files are available for Patreon supporters.

Best for: PBR textures, realistic materials, HDRIs

CGBookcase

Another solid CC0 texture source. CGBookcase has a smaller library than ambientCG, but the quality is excellent and the site includes tutorials on creating your own PBR textures.

Best for: High-quality PBR textures, learning texture creation

Audio: Music and Sound Effects

Freesound

Freesound.org is a collaborative database of Creative Commons licensed sounds. With over 600,000 audio samples, it's massive—though quality and licensing vary by upload. Filter by CC0 if you want no-strings-attached usage.

The search can be finicky, but the depth of the library is unmatched for specific sound effects.

Best for: Specific sound effects, ambient audio, foley

Sonniss GDC Audio Bundles

Every year for GDC, Sonniss releases a free bundle of professional game audio. The archive now contains years' worth of these bundles—we're talking gigabytes of royalty-free sound effects you can use commercially with no attribution required.

These aren't amateur recordings. They're from professional sound libraries, and they're genuinely excellent.

Best for: High-quality sound effects, bulk downloads

Pixabay

Yes, the stock photo site. Pixabay also has a growing library of royalty-free sound effects and music. Everything is CC0-equivalent, so you can use it commercially without attribution.

The search and filtering are better than most audio sites.

Best for: Quick sound effect searches, background music

A Note on Licences

Before you ship anything, double-check the licence on every asset you use. The main ones you'll encounter:

• CC0 / Public Domain: Use however you want. No attribution required. Commercial use allowed.
• CC-BY: Free to use, but you must credit the creator.
• CC-BY-SA: Free to use with attribution, and derivative works must use the same licence.
• GPL/LGPL: Common for code; can have implications for your project if not careful.

When in doubt, read the licence. It takes 30 seconds and can save you headaches later.

Keeping it all organised

Here's the thing about free assets: you'll download more than you use. Way more. That sprite pack catches your eye, then a tileset, then some sound effects, then a character pack "just in case"—and suddenly you've got thousands of files scattered across your downloads folder, external drives, and cloud storage.

Finding that one animation you remember downloading six months ago becomes an archaeological expedition.

Once you have a library worth searching, AssetHoard is a game asset manager built for exactly this problem. Import your downloaded packs, preview files without opening another app, and drag assets directly into Unity or Godot. It supports 80+ formats including .unitypackage, .aseprite, .fbx, .gltf, .wav, and more—all searchable and previewable in one place.

One-time purchase, local-first, no subscription. Your files stay on your machine.

The Bottom Line

You don't need to spend money to make a good-looking game. The resources above represent thousands of hours of work that creators have generously made available to the community—often under licences that let you use them commercially without restriction.

The challenge isn't finding free assets. It's finding the right assets, keeping them organised, and actually using them before you forget they exist.

Now stop reading and go make something.

The AssetHoard Team

The Quest Begins

If you've ever whispered "where did I put that texture?" into the void at 2 AM, congratulations. You're our people.

We're the AssetHoard team, and we've spent the last year building the asset management tool we desperately needed but couldn't find. You know the drill: you've got .blend files in three different folders, a Unity Asset Store backlog that rivals your Steam library (we see you), and somewhere in the depths of your Downloads folder lurks that perfect sprite sheet you bought six months ago.

Welcome to the hoard. Make yourself at home.

Why We Built This Thing

Here's the thing about existing asset management solutions: they either want your firstborn child (subscription fees), your data (cloud-mandatory uploads), or they're so complex you need a PhD in taxonomy just to organize your pixel art.

We wanted something different:

• Local-first, because your assets are yours. Everything lives on your machine in a SQLite database. No accounts. We literally cannot see your files, and we like it that way.
• Actually searchable. Tags, filters, metadata extraction. Find that one PBR material set from 2019 without excavating through folder archaeology.
• Preview everything. Over 30 formats including Aseprite animations, glTF models (spinnable!), PSD layers, and audio with waveforms. No more "let me just open Blender real quick to see what this is."
• Drag and drop into your engine. Unity and Godot integration that just works. Like it should. In the year 2025.

Who's This For?

Indie game devs drowning in assets from too many Humble Bundles and itch.io sales. We've been there. We bought the 47,000-asset mega pack too.

2D artists with Aseprite files scattered across project folders like confetti. Now you can see your animations without opening Aseprite.

3D artists who need to preview that FBX without launching a full DCC application. Spin it, zoom it, check the polycount. Move on.

Sound designers with audio libraries that have grown beyond mortal comprehension. Waveform previews and inline playback mean you can audition sounds without leaving your library.

Basically, if you make things and those things have become... many... we built this for you.

The Tech Under the Hood

For the nerds in the audience (that's a compliment), here's what's powering the hoard:

The desktop app is built with Rust, running on Windows, macOS, and Linux. We're using SQLite for the database because it's battle-tested, fast, and (crucially) entirely local.

This website you're reading? SvelteKit with static site generation, deployed to GitHub Pages. TypeScript throughout, because we have some self-respect. No dark patterns, no cookie banners (we don't track you), no "sign up to continue reading." Just... a website. Revolutionary, we know.

What's Next?

We're actively building. The roadmap has the full picture, but the highlights:

• Collections for organizing assets into project-specific groups
• Improved 3D management with better material handling
• Blender file support (yes, .blend previews—we're working on it)
• And eventually, a plugin system for the power users who want to extend things

Join the Party

Get AssetHoard, throw your chaotic asset folders at it, and let us know what you think. We're building this for the community, and your feedback shapes where we go next.

Got questions? Feature requests? Found a bug? Hit us up through the contact form or just yell into the void on social media. We're listening.

Now if you'll excuse us, we need to go organize our own asset libraries. They're... fine. Everything is fine.

The AssetHoard Team

P.S. No light mode. We're not monsters.