How to hide or lock away the images from the player

Started by
5 comments, last by Satharis 10 years, 7 months ago

How to hide or lock away the images from the player?

The game is a "match the word to a displayed image by typing the word" game.

The reason why I do not want them to see the images inside the game folder is because the answers to each image is in fact the name of the image itself.

The game is written in Java.

1) Is there an universal technique to hiding the images that does this for all programming languages?

2) Or is every technique different from every programming languge?

3) Is this hiding technique the same as hiding game save state of the player?

What is this technique called?

Advertisement

Anything you put on the user's machine is impossible to perfectly hide. That said, you're just wanting to hide the data from regular users, not from more advanced users.

There's no real technique for that, you just find some way of packaging your data. Zipping them up in a .zip file is a common way (and then renaming the .zip extension to something else just for fun), but I think in Java you can actually store your image files in the .jar itself. I don't use Java myself, but try googling for "packing resources in a jar" or use similar search terms.

1. simplest: hide by renaming the files. image1.jpg becomes somefile.cfg, or .dat, or .ini, or .exe, or .dll, or whatever. something that makes it look like something else.

2. hide by putting all the files into one file (a resource or WAD file)

3. hide by encryption

4. hide by all of the above

5. hide by all of the above using a custom virtual machine in the game for decrypting. they'd have to reverse engineer the virtual machine before they could hack the decryption code.

6. hide by storing on a remote server and requiring a live internet connection.

me personally, i'd probably stop at 1 or 2 to keep out casual users.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

If its just the filenames then you could provide something to automatically calculate a hash value at build time to replace them and only refer to them by that value and then possibly stuff them into an archive. Also make sure only the hash values are stored in the compiled code.

Though you seem to need those values later for providing the answers which means they need to be stored somewhere. I think you could put them in some of the lowest bits of the image files if you use a lossless format.

all you really need to do is make it so they can't pull the pictures up in a paint program just like that <snap!>.

you could tack your own header onto them, then a paint program wouldn't find the signature bytes it expected.

or you could encrypt them somehow (what is that, mod 256 each byte?, is that the one?) quick, easy. no casual gamer end user will get through.

or stuff them all in one big file. a resource file might be the way to go, although back when i used one, it quickly grew into a whole library of routines for all types of data, and a resource compiler (to make the big archive file). but you can also do easy stuff like just write them all out to one big file and boom there's your archive, ready to read. a simple subroutine off the main menu in the game that writes all the images to a single file ( in any format you want ).

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

Thanks for the feedbacks guys!

Personally I think the renaming idea is pretty good, in general if someone really wants to cheat at a game they can of course manage it. But it is a good point that most "casual" people, i.e. people that open up the game folder and poke around hoping to find things they can change, are much less apt to find anything if they don't immediately see images when they open the folder.

Putting all the image data together kind of seems like a waste, you'd have to invent a tool to combine them or use some kind of archive and then code it to read them too. That makes sense for an AAA game with a couple GB of textures and model data and such but gets less convenient when you get into the smaller and smaller range.

This topic is closed to new replies.

Advertisement