• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
cozzie

How to 'ship' your game assets

16 posts in this topic

Hi,
Like many of us I'm working on the next top gaming title. But before that, just doing some small games.
When I finished my first game I ran into something quite basic but never thought off.

My game folder concists of:
- an executable
- a data folder with sub folders for textures and sounds (bmp, png, tga, wav, mp3, ogg)
- some ascii files with highscores and own file format 3d scene information
- some X files (binary) with 3d meshes

What I want to prevent is to have all these assets and files 'open to public' within a grasp.
How would/ do you do this?

A few first thoughts:
- compress them all to a ZIP file, rename extension to i.e .abc
at runtime unpack the contents to a temporary folder (with some ZIP/ compression API).
Remove the files when application quits (how to handle non sunny quitting?)
- use some sort of DIY encryption and rename the file extensions
- ....

It's no problem if it's not waterproof though.
Really like to know your ideas and suggestions on this.
1

Share this post


Link to post
Share on other sites

You could always make your own format, the header would be an index (which associates file 'paths' with file offsets). Each file could be individually compressed, maybe even based on its data type, as audio and images are more efficiently compressed using methods suited to each. Perhaps even a layer of encryption, on the index header, and each asset itself, using your basic XOR against some generated value (from the asset's offset, name, etc)..

 

It's not difficult to write up a quick utility that will search out all the files in a folder, and its subfolders, and add them to such an asset package.

 

The *last* thing you want to do is extract an asset back to the disk, just to load it from there. You need to re-write your code so that it directly loads the asset from the packaged file. Writing it out to disk to load it is just silly.

2

Share this post


Link to post
Share on other sites
Thanks. Those are 2 completely directions :)
I personally think to agree withoption 2, don't waste all the time. Maybe for the feeling just rename files to associate them with my own code. Regarding the ascii files I might want to think about some sort of easy encryption (to just increase the effort needed to change quite some essential things in the game, like the highscore table :))
0

Share this post


Link to post
Share on other sites

I can understand 'wanting' to secure some data but really, once it is on the players machine, there is nothing you can do they likely can't hack in less time than it takes you to implement it.  A highscore table is just as invalid if they hack collisions/lives/etc as it is if they simply modify it directly.  So, why waste the time?  The only way to secure data is simply not give it to the user and store it on a server, of course garbage data in from hacked clients is still possible and invalidates the server data also, yer pretty much screwed either way..  :)

0

Share this post


Link to post
Share on other sites

One option is to not encrypt your data, but instead to hash its data when you load it to verify that the contents of the file haven't changed. You can precompute hashes of files, store then in your program in some array/map of strings or bytes, and when you load a file take the MD5 or SHA-1 hash of it and verify that it's the same.

 

You can also mix this up with other encryption/obfuscation schemes.

 

Of course, if someone wanted to hack your game, it would literally take them only minutes to figure it out and hack your game (regardless of what you do, encrypting, obfuscating  hashing, etc.), so I wouldn't bother with it. Once one person figures it out, he/she can make a tool for everyone. It's not worth your time, most likely. But of course, if you're programming for fun, and you have fun encrypting/obfuscating/hashing/etc, then go ahead and have some fun.

0

Share this post


Link to post
Share on other sites

Personally I store my assets as resources. (the Microsoft specific standard that stores icons, menus, some strings, bitmaps etc or custom data if you want)

I assume with resource editors it's still as simple to extract non-encrypted files of course but I can ship a stand-alone exe that self-contains everything.

If this solution interests you, look into the following functions on MSN: FindResource(), LoadResource(), LockResource()

The custom type is RT_RCDATA and is "defined" as 10. You would need to pass that value to the FindResource() function.

 

As an aside, I disagree that encrypting/obfuscating a program is useless because somebody in the world (a clever hacker) will undo that anyway. You can still buy some time and avoid every script-kiddie and his grandma to already steal your assets. If it were really useless then AAA titles wouldn't go to so much trouble doing it. Whenever you ask how to do this here, you are either suspected of wanting to bypass such a scheme yourself to steal a game (which sort of proves that such a system IS useful or why would they be so afraid that you bypass it) or maybe there is some elitism in which newbies aren't encouraged to be able to code to the same protected standards.

0

Share this post


Link to post
Share on other sites

There are some older threads with a similar subject here on GDev, and some of the posts in them make a great point on the subject - in fact, it would be a shame not to reference them:

http://www.gamedev.net/topic/506247-why-do-game-companies-use-custom-texture-formats-instead-of-the-dds-format/

http://www.gamedev.net/topic/605910-encrypting-images-png-with-directx/
http://www.gamedev.net/topic/577588-what-are-some-simple-ways-to-protect-my-games-assets-sprites-sound-music-etc/
http://www.gamedev.net/topic/316093-protecting-game-assets/
http://www.gamedev.net/topic/627723-packing-the-game-resources/
http://www.gamedev.net/topic/547471-protecting-shader-code/
http://www.gamedev.net/topic/555394-binary-file-writing-making-it-unreadable-c/

To my view, the point most people make against the encryption-for-protection idea is that the best kind of protection for your assets is the legal one. Make a good copyright claim, a good EULA document.
But they do make a point for managing your game asset file formats in a sense that you should write it in a game-engine specific, binary manner so as to load it as fast as possible (meaning just dumping the data to memory and setting up your pointers, without having to parse data extensively). This kind of binary file formatting provides a "side-effect", unintentional protection as you wouldn't be dealing the original formats anymore. So as Hannah Montana would say, it's the best of both worlds.

Edited by Kryzon
0

Share this post


Link to post
Share on other sites

As an aside, I disagree that encrypting/obfuscating a program is useless because somebody in the world (a clever hacker) will undo that anyway. You can still buy some time and avoid every script-kiddie and his grandma to already steal your assets. If it were really useless then AAA titles wouldn't go to so much trouble doing it. Whenever you ask how to do this here, you are either suspected of wanting to bypass such a scheme yourself to steal a game (which sort of proves that such a system IS useful or why would they be so afraid that you bypass it) or maybe there is some elitism in which newbies aren't encouraged to be able to code to the same protected standards.

I have never encrypted data in a game client and I've shipped quite a few.  Not bothering has nothing to do with elitism, or any particular belief things should be open/free for access, it is simple practical reality, it doesn't work and is a waste of time.  Additionally, if grandma wants to make her character pink instead of brown, more power to her as long as she enjoys the game and hopefully paid for it.  The only typical encryption in AAA titles, and it's just obfuscation really, is because the formats are written custom with practical reasons in mind such as speed, i.e. pack files are used by many games purely because it is hugely faster to load multiple pieces of data from a single already opened file than it is to load from multiple loose files.  Often the data is also compressed, again, this is not usually an attempt to increase obfuscation or implied encryption, it is just a practical reason that at the cost of some CPU it is faster to load and decompress than wait for an HD to read in the entire uncompressed piece of data.  Or the data looks like garbage but is really precompiled script VM or other things like that.

1

Share this post


Link to post
Share on other sites

Perhaps something like BoxedApp is what you're looking after? It packs files into the executable and unpacks them in a virtualized environment for your game.exe to use. I'm not security expert at all (really, I haven't got the slightest idea what I am talking about!), but as far as I am concerned it gives you basic protection against DLL-injections and hides your resources from public view. Also you get a single binary for shipping. No installation required, just click the exe and run the game. Registry-values is saved in a virtual registry.

Edited by Kuxe
0

Share this post


Link to post
Share on other sites

I would have things simply renamed or compressed into zip files named something else.  The reason is that something this basic would stop many would-be hackers, and NOTHING will stop the real hackers.  Let's say that these simple things are 10% effort, with 100% being something like an all out DRM(like maybe the famous one from Spore that was cracked very quickly anyway).  The average game player may look at files, but when they don't see something familiar(like files with zip icons, etc...) they won't do much else.  Let's say this is 95% of the game players, which of course may be off, but it can't be THAT far off.  So....10% effort stops 95% of the players from hacking, and the other 5% wouldn't have been stopped even at 100% effort, so though there is no reaspon to go all out, there is also no reason to not do that small 10%.

0

Share this post


Link to post
Share on other sites

non-standard file-formats are likely to be a bigger protection than encryption:

with encryption, once they figure out the basic algorithm and/or encryption keys, they are done;

with a non-standard file-format, they have the data, but may still need to go through the time/effort to reverse-engineer the file-format and write loaders/converters/...

 

granted, many straightforward uncompressed formats can generally be worked out pretty quickly just by looking at a hex-dump, but if it is a non-standard compressed format, there wont be so many obvious visual cues (it may well just look like a garbled mess of random bits).

 

like, say, the developer uses a custom arithmetic-coded BWT variant or similar (vs something more obvious, like Deflate... like person looks at a hex-dump and spots "78 DA" from the ZLib header or something... or if savvy, will recognize the magic numbers used in things like BZip2 and similar as well, ... at which point you have pretty much already lost...).

 

even as such, a determined person will still probably have it all figured out within a few days or weeks.

 

(then again, who knows, maybe if a person can devise "sufficiently convoluted" file formats, it might well slow them down... like, say, they didn't expect some random glob of compressed data to use right-to-left bit-packing, or variable-width gray-codes as numbers, or text strings are obfuscated as pseudo Chinese, or whatever else... then maybe figuring it out takes them around a month...).

 

 

granted, there are other reasons for making custom file-formats though...

Edited by cr88192
0

Share this post


Link to post
Share on other sites

Please don't take this as offensive, but it really comes down to several simple questions.  Who are you fighting?  Why are you fighting them?  And what do you think you gain in the process?  After 20 years of making games, I still don't follow this chain of thought, much like I don't believe in DRM beyond the "enter your key" level or non-intrusive Steam style which still allows play off line.  You are blocking 95% of folks from doing something they might enjoy because 5% scare you, but you admit the 5% will do it anyway so, what is actually gained?  If it makes the customer happy to fiddle with the assets on their local computer, that's fine with me.  Grammy thinks her character should wear pink instead of black, making it easy for her grandson to make the change will make them both happy in ways beyond the initial intention of the game.  If someone wants to use an asset as their Facebook image, please do, it's free advertising and the best form of up voting possible.

 

The only time worrying about asset integrity really matters is online games where modified assets can change the game experience for *others*, I don't give a damn what the hacker does locally.  Of course, this is generally going to be the 5% everyone so far as agreed that you can't beat, they will figure it out.  Asset protection locally isn't going to work against this group and all you can do is help prevent them from ruining the game for others which has little or nothing to do with preventing asset modifications.  Yes, common cheats are to hack opponent models to include huge axis bars so they show up from a long way away as easy to see, or to change shaders to render all opponents as hot pink without lighting.  Even if you could prevent this from the assets side, they can go in with D3D/GL intercepts and add it outside of your games control.  But, ignore all of that because it is way beyond the scope here.

 

So, back to the original point, the only people a single player game is fighting through obfuscation is your paying customer base.  Err, contradiction much, you are trying to entertain them but hiding a vector of entertainment value to some of them?  What a person does with their personal computer is not a damned bit of my business, just please clear your browser history before you let my niece and nephew use your computer.  :)  Other than the multiplayer aspect, everytime I see encrypt your files, obfuscate etc, I roll my eyes.

2

Share this post


Link to post
Share on other sites

FWIW: I was sort of implying that all the effort that a person could put into encryption/obfuscation/... is ultimately pointless...

0

Share this post


Link to post
Share on other sites
Interesting thoughts, thanks everyone for all the input.
Probably this expains why ID ships big 'pak' files just to improve reading speed of the data. And another example, why valve ships a bunch of folders with wav files,which probably works fine for them in terms of speed/performance.

I'm going for the little effort option, which simply gives the folder contents the 'feel' I want it to have and keeps the 80% or 90% 'pickers' away.

@alleightup: I follow your thoughts, but when you're in startup, the beginning artist or sound guy in a team might also like it when there's at least a little measure on their content
0

Share this post


Link to post
Share on other sites

FWIW: I was sort of implying that all the effort that a person could put into encryption/obfuscation/... is ultimately pointless...

That is not entirely true and is entirely personal.

 

As the OP pointed out - the obfuscation will make the dev team feel safer about it - i.e. they're not just handing out the assets on the silver platter in the directory named "Take.Me.!!!"

 

The whole point of the obfuscation, as I see it, is to at least make it a little harder for the bastards that will take it and make them at least work for it (even if all it means for them is running another tool or two).

 

That, in my opinion, is well worth the few days of a programmer's time. What are 3-5 days on some bigger game, anyway ? It's a great learning excercise, plus it cleans out the whole directory of the old lingering mess.

 

Plus, as an added bonus, it makes those bastards curse as hell when they decrypt some nice welcome message (or some gory image you left for them in the textures directory) that you prepared for them and loose 15 more minutes - which is always welcome smile.png

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0