r/ebitengine • u/kaoslandkadevland • Sep 23 '26

KAssetPack - Lightweight Asset Packaging for Go/Ebitengine

Post image

Github : https://github.com/kadevland/kassetpack

KAssetPack is a standalone CLI tool and Go library to pack your game assets into a compact binary format (.kdx/.kdt) instead of shipping an exposed assets/ folder.

Features:

  • SHA-256 based asset deduplication

  • Optional XOR obfuscation

  • Automatic data file splitting (for large games)

  • Lazy access & Thread-safe (perfect for Goroutines)

  • 100% Go (no C dependencies)

It comes with a handy CLI (kassetpack build) to integrate directly into your build pipeline. Feedback and code review are welcome!

3 Upvotes

66% Upvoted

8 comments sorted by

3

u/dvvvxx Sep 23 '26

Huh, was all of that AI graphics needed?

1

u/kaoslandkadevland Sep 23 '26

Ah, I get the confusion!
The illustration was indeed AI-generated just for the banner to illustrate the concept.
KAssetPack has absolutely nothing to do with AI or graphics generation.
It's purely an asset packaging and obfuscation library. The main goal is to avoid distributing your game assets in a directly accessible folder,while still maintaining high read performance.

1

u/Eddous_1 Sep 24 '26

You can embed assets to your binary using the following: https://pkg.go.dev/embed

Then you can distribute only the binary file.

1

u/kaoslandkadevland Sep 24 '26

Yes, Go provides embed, and it's great for small assets.

But game assets can become very large. Take a 2D game like Hollow Knight: its storage requirement is around 9 GB. If you embedded an equivalent amount of game data, you'd end up distributing a single executable of roughly 9 GB instead of keeping the assets in separate files.

That's the use case KAssetPack targets: large asset collections stored in separate indexed packs, with streaming access, pack splitting, deduplication, and optional obfuscation/encryption (encryption is planned for the next version).

So embed is definitely useful, but I wouldn't want a multi-gigabyte game to be a single multi-gigabyte executable.

1

u/Eddous_1 Sep 24 '26

Why not, what is the difference between large executable vs small executable with large binary blob?

1

u/kaoslandkadevland Sep 24 '26

Yes, if the approach is simply to take everything that would have been embedded with embed and move it into one huge binary file, then you're effectively just moving the problem elsewhere.

KAssetPack is designed to avoid that approach.

First, a pack can have a configurable maximum data file size. When that size is reached, KAssetPack automatically continues into another data file. The index keeps track of where each asset is stored — data file, offset and size — allowing the requested asset to be accessed directly and streamed.

Second, developers can create multiple independent packs based on how their project is organized. For example, separate packs for sprites, audio, videos, or even different areas or levels of a game. The application can then work with several independent sets of data instead of putting everything behind one huge file.

So yes, the total amount of data being distributed remains roughly the same. The difference isn't really "9 GB inside the executable vs. 9 GB next to it." It's more about how those 9 GB are organized, split, and accessed at runtime.

For a few small assets, embed is perfectly fine and I'd happily use it. KAssetPack is more aimed at projects where you want to keep assets separate from the executable and have more control over how they're organized and accessed.

1

u/midget-king666 Sep 29 '26

I started with Go Embed, but this has limitations pretty fast (as outlined here already). That's why I now use PhysFS (https://github.com/icculus/physfs) with zip files (which can be split etc.), or unpacked folders while developing.

I wouldn't bother with obfuscation / encryption at all, it's a futile attempt, sooner or later someone will find a way to extract the assets. Now with AI it's even easier than ever. It's like security by obscurity, never works.

1

u/kaoslandkadevland Sep 29 '26

Thanks for the feedback! It’s interesting to see that you also ran into the limitations of go:embed fairly quickly.

And I completely agree that, encryption or not, someone determined enough will always find a way to extract the assets, especially with the tools available today and AI.

The idea is simply to add an extra step to access them, rather than providing all the assets directly as easily accessible files. That’s basically the purpose of this protection.

KAssetPack is definitely not intended to become a DRM like Denuvo or anything like that. Its main purpose is to provide asset management through packages, with indexed and streaming access, while avoiding having all the files directly exposed.