How to package game files

How does one package a game project into an executable in order to hide game assets such as a sprite sheet?

When I make an executable .jar from eclipse I simply extract the contents from the generated file and all my graphics are up for grabs. While I understand anyone with persistence can screen shot everything, I’d really like to hide my assets so they aren’t directly accessible. I’ve seen some simple games with one .exe file and nothing else. But I can’t seem to figure out how to get my game to run from just the .jar and to keep from extracting its contents. I have to extract all my ‘resources’ in order for the game to run.

Can anyone shed some light on this?

There’s not really that much point.
Even in cases of standalone executables, the assets are still in there, and it is usually trivial to extract them.

And even if you come up with the most secure and obscure storage system in the world, the code for loading the assets into a usable form is contained right in the executable anyway, and can easily be manipulated to ‘decode’ the resources.

However, if you’re just looking to do this for convenience reasons, in Eclipse you create a new source folder and store the assets there. Then you just adjust your code to load assets from within the jar (using ClassLoaders) instead of outside the jar using Files.

I would compare it to locking my vehicle. Stealing is against the law and even so, someone may be able to get in there by various means to take things. Maybe even the car itself. But that still doesn’t deter me from locking it whenever I exit. Of course it’s not a bullet proof method to keep my things completely safe but I’m not about to stop locking my car.

I just want something simple to package everything into a file rather than leaving all my sprites out in the open.

Your analogy isn’t really equivalent; yes you lock your car because it makes it harder to break into, but:

  1. This increased difficulty for the thief increases the chance of their detection.
  2. Which encourages the thief to go elsewhere.

Obfuscating your resources (or code) doesn’t increase the chance of detection (it remains zero), nor does it encourage the thief to go elsewhere (if they need what you have, you are the only source).

Moreover there exist tools, that operate at the binary level, able to identify & rip image, sound, and video assets both from disk & from the in-memory representation.

Obfuscating your resources might deter the casual browser; but the casual browser isn’t the one who is going to use your assets in a damaging way. (They may in fact be using them in a constructive way, building a wiki or the like)

Thus you’re at best wasting your time, and at worst impeding fans of your game.

This just begs the question, why do professionals make it so that the casual player can’t just copy-paste all the assets?

I know that there are tools for packing java projects, along with a JVM, as a native executable for a particular operating system. Perhaps you could do as HeroesGraveDev suggested by including your assets folder within your JAR file and then seek to package the JAR as an executable. Check out this stackoverflow post and see if the solution works for you.

Depending on how loading goes, you can add a byte in front of the file and completely ignore it. Of course you would only do this at distribution time, not casual testing. The same goes for the end. This goes as far as eliminating the casual browser. Memory management tools can still get in there and do its thing. Another thing is it blocks the header block from being recognized as a file by some software, too. Usually file formats have a 2-3 byte signature at the very beginning of the file to determine what file it is. PNG does this. BMP does this.

As far as text files go, don’t hide the config files. Hide the external strings, or maybe just encrypt them.

There are many simple dumb methods you can take to keep your game assets secret from the casual person.

I had started building my app this way and was wondering why the .jar wouldn’t run on its own.

Then after hours of running around testing things, found a file with a lowercase C that didn’t match the code’s String :o

You might want to be careful when dealing with jars too. If you compress your jar, you have that decompression time.

Also, with regards to your problem you had c and C do look alike. I am sorry for you having to go through that. I, myself, run into stupid crap like that every now and again. I think most recently an L and an I.

When people use LWJGL, they have a hard time distributing it. I’ve instructed countless beginners over at ThinMatrix’s youtube channel how to do this because he doesn’t have a video yet. So just remember to check your jar’s META-INF. This is a bit shakey when your are looking to do it the way HeroesGraveDev evidently does because of how URLClassLoader works. But if you know what ur doing its just another task :slight_smile:

There’s no need to mess around with META-INF or URLClassLoader to do the loading.

It’s literally 1 line of code:


InputStream input = SomeClass.class.getResource("/path/from/jar/root/file.png");

Packaging LWJGL natives is an entirely different issue, and doing that manually isn’t a good idea. There are plenty of tools that will create ‘fat JARs’ for you and do it the right way.

@ndnwarrior15 take a look at what we do with our games… (Windows, Mac, and Linux builds of all of them to look at).
Note complete lack of being arsed to stop people poking in the jars. Though we do use our own file format for images for historical reasons which makes them a bit more awkward to pinch.

Cas :slight_smile:

I was talking about libraries.