Jump to content

  • Log In with Google      Sign In   
  • Create Account

File Management: Best Practices?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 AniMerrill   Members   -  Reputation: 203

Like
0Likes
Like

Posted 25 February 2013 - 10:55 PM

This is a weird question, and I'm more so looking to be pointed in the right direction than given a specific answer.

 

So I've got my game I'm making in Allegro 5, I've done basic File I/O a few times... but what's the best practices for when it comes to release time and information that was good to have in human readable language during development and debugging suddenly shouldn't be visible to the user. How might someone go about solving this?

 

Maybe here's a better example: I'm currently working on a Tilemap system for a 2d RPG type of game. The tilemap will consist of both a bitmap and a text file, probably written in XML or similar style, which says what bitmap regions get drawn where. Obviously in Debugging its awesome to have information like that readable so both me and my artist can read it without any headaches. But say it comes to release time, how do I conceal these from a player who might, say, access and edit them... or steal them... or break their game, etc.

 

I think the only time I've seen something like this implemented is when I was working with XNA for a short while, XNA has like a content pipeline which I think incorporates assets once you compile the program. I have no idea what this was called or how to implement this kind of thing, or even if that's best practice.

 

Any advice, tips, or points in the right direction?


AniMerrill, a.k.a. Ethan Merrill


Sponsor:

#2 Yourself   Crossbones+   -  Reputation: 1134

Like
1Likes
Like

Posted 26 February 2013 - 02:48 AM

What I would do in your situation is write a small 'packer' application/script.

It will take the input files (the image and xml file in your case) and write them to a single (binary) file.

Adjust the loading of the files (based on a define for example), that it will load that file instead. 

 

the advantages are that only you knows the exact file format and yet are able to use the 'raw' files for debugging.

Also you could adapt the data in the new file to fit the code layout so you have faster loading times ( for example if the xml file only contains integers, just write the integers as an array instead of the xml string data).

 

you could even extent this and pack all resources into a single file (or one file per level). 

adding a basic encryption (for example XOR cipher : http://en.wikipedia.org/wiki/XOR_cipher) would make it even more secure.



#3 frob   Moderators   -  Reputation: 21434

Like
4Likes
Like

Posted 26 February 2013 - 02:56 AM

If your biggest interest is to prevent players from mucking with your data or steal it or break their game, don't bother. They'll do that no matter what.


If your interest is to create a neatly packaged bundle of files for some builds and also allow regular directory trees during develoment, there are great tools to do that.

One such library is PhysFS.

The nice thing about these tools is that during development it can point to a regular directory tree, and in final builds it can point to a compressed file that contains the same file tree. You can even point to multiple file sources so that during development you can pull files from a directory if they exist, or pull from the compressed file if they don't exist.
Check out my personal indie blog at bryanwagstaff.com.

#4 doeme   Members   -  Reputation: 707

Like
1Likes
Like

Posted 26 February 2013 - 05:25 AM

If your biggest interest is to prevent players from mucking with your data or steal it or break their game, don't bother. They'll do that no matter what.

I agree with this, given enough time and effort all of your assets can be stolen. Despite since your tilemap will be visible on the screen nothing will prevent the user from taking screenshots anyways.

 

Also installing measures to prevent this soon will limit the ease of access to your product, which for relatively cheap mass-market products (like games) is generally a bad idea. Needing to enter a key, which is prone to be lost somewhere in your house soon gets to be a nuisance.

I develop surgical simulators for a living, and we encrypt some of our assets when creating an installer and our customers get a USB-Key (produced by a 3rd-Party vendor) which has to be plugged in to be able to decrypt and run the system. However this is far away from the cheap, mass-market product so the acceptance of the user is a bit better for stuff like this, as this also acts as a security, so there is little point in stealing the system.

 

Compiling your assets to a binary might still be a first step in preventing the users from just copying them, but I would set the primary goal there towards faster loading speed and not towards security. Consider discouraging the lazy and casual thief more as a nice side effect than anything else.


Edited by doeme, 27 February 2013 - 10:28 AM.


#5 AniMerrill   Members   -  Reputation: 203

Like
0Likes
Like

Posted 26 February 2013 - 09:18 AM

I agree with this, given enough time and effort all of your assets can be stolen. Despite since your tilemap will be visible on the screen nothing will prevent the user from taking screenshots anyways.

 

If your biggest interest is to prevent players from mucking with your data or steal it or break their game, don't bother. They'll do that no matter what.

If your biggest interest is to prevent players from mucking with your data or steal it or break their game, don't bother. They'll do that no matter what.


If your interest is to create a neatly packaged bundle of files for some builds and also allow regular directory trees during develoment, there are great tools to do that.

 

Thanks guys for your input. I guess I should have been clearer: I'm not really interested in making it hacker proof. If people are able to rip images from game cartridges 20 years ago, I don't really consider myself to be above having old Mario sprites and levels on the internet, or the ROMs for emulators. I guess I was just moreso... interested in that one layer of protection, so at least not everyone would have the ability to peek in there and accidentally muck something up. Or have access to raw PNG files.

 

So I'll definitely look into the libraries suggested or the general concept of compiling assets into binary, that sounds good enough for me.


AniMerrill, a.k.a. Ethan Merrill


#6 jbadams   Senior Staff   -  Reputation: 18717

Like
1Likes
Like

Posted 26 February 2013 - 08:17 PM

If your interest is to create a neatly packaged bundle of files for some builds and also allow regular directory trees during develoment, there are great tools to do that.

One such library is PhysFS.

See this page for integrating PhysFS with Allegro 5smile.png



#7 Sik_the_hedgehog   Crossbones+   -  Reputation: 1757

Like
0Likes
Like

Posted 27 February 2013 - 09:43 AM

I'd go with storing the level data in a binary file but just to reduce filesize, not for preventing people from peeking at it.

In fact, in the long term attempts to stop people from messing with the files it may be a bad idea. Remember modding is a big thing, if your game can be modified without much trouble, the players may be more bound to want to keep playing it. Heck, I think the main reason Wolfstein 3D became popular wasn't the graphics, but the fact the level format got cracked in under a week and players started making their own levels.

And as mentioned, if somebody really wants to steal your assets, that's going to happen no matter what.


Edited by Sik_the_hedgehog, 27 February 2013 - 09:44 AM.

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

#8 AniMerrill   Members   -  Reputation: 203

Like
0Likes
Like

Posted 27 February 2013 - 11:56 AM

See this page for integrating PhysFS with Allegro 5smile.png

 

You probably just saved my life there. :o

 

I'd go with storing the level data in a binary file but just to reduce filesize, not for preventing people from peeking at it.

In fact, in the long term attempts to stop people from messing with the files it may be a bad idea. Remember modding is a big thing, if your game can be modified without much trouble, the players may be more bound to want to keep playing it. Heck, I think the main reason Wolfstein 3D became popular wasn't the graphics, but the fact the level format got cracked in under a week and players started making their own levels.

And as mentioned, if somebody really wants to steal your assets, that's going to happen no matter what.

 

Yeah, I guess I might of worded it wrong. I basically just wanted to make it so raw pngs and txt files were not just laying around a user's computer... like, if someone wants to decompile the binary or rip the information, that's cool. I just want to make it harder for the common user to accidentally break the game, or suddenly be making a shitty sprite comic with our png XD That and I'd rather not have the game make a mess on the user's hard drive once installed with whatever directory system I had to make the game work.

 

As for modding, I'll definitely keep that in mind but I don't really see any ways this particular game would appeal to the modding community. It's a 2d, top down, Zelda style dungeon crawler... so its not like 3d where you could import different character models, you'd have to draw your own sprites to change anything. And on top of that, there's a very specific aesthetic we're going for with the art style... I don't really wanna have that changed unless the end user is spunky enough to do that.


AniMerrill, a.k.a. Ethan Merrill





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS