AN ACTUAL ANSWER
, for having to wade through nonsense.
|Is it possible to run a program without needing extra files?|
The answer is yes, absolutely
Further, it is very easy
, which are compiled into your executable by default. You get access to the data through the standard Windows resource functions. https://docs.microsoft.com/en-us/windows/desktop/menurc/introduction-to-resources
you simply embed the data in the executable as an object, using the objcopy
utility. Read more here: https://docs.microsoft.com/en-us/windows/desktop/menurc/introduction-to-resources
On OS X
(or whatever they’re calling it now) you just stick it in your application bundle.
There exist a number of cross-platform solutions that do it differently, such as https://github.com/d-led/ris
, which is fairly nice.
All of the above assume that the assets are fixed at the time of compile, so the final executable contains all the necessary information.
This leads to an implementation issue: your libraries must be able to read those assets, either directly or by having your program unpack them into some kind of stream/input that your libraries can use. (Often, just having it as a string in memory is sufficient.)
It is also not uncommon to compile assets into a shared library to be used in a plug-in kind of way.
|So how can you prevent [people modifying the game assets]? Or is there simply no way?|
It is impossible to stop someone who is determined enough from modifying your assets.
That said, you can make it inconvenient. At the very minimum, you should apply some kind of compression on your assets.
If you wish to really secure them, though, there are different goals.
• If the goal is to prevent your game from using modified assets, then a simple checksum is sufficient. Remember, the checksum must be stored separately
from the assets, otherwise it is worthless. More on this below.
• If the goal is to prevent people from stealing your assets, then you should apply some kind of encryption. Use this in addition to a checksum. (Hint: get the Twofish
Remember also that in certain places in the world using cryptographic options are enthusiastically regulated by the government. Make sure you don’t do something that will get you in trouble.
Of course, once you unpack your assets all bets are off. As already mentioned, sometimes just a few judicious screenshots are all that is needed to steal flat images. I don’t think you have to worry to much about 3D assets in an .obj file, as long as the OBJ data is not left anywhere obvious. That is, unpack (decrypt and uncompress) into memory, then have the OBJ readers load from memory, then clear and free the memory buffer. Same for the textures applied to your 3D objects.
Finally, consider this: your game can be very, very cool, but it might not rise to the level of being worth taking extra care to protect beyond just getting paid to play it. There are typically three marketing methods:
• It’s free! No worries!
• Pay to download. For this it is worth having a server running that the game can check against for things like:
- check that the user has actually paid for the game and is running it on a registered device
- check that the checksum (for assets or anything else) matches what your server says they should be
- check for updates/patches/plugins
• Pay through advertisement revenue (click here to upgrade your <whatsit>, or watch this ad to keep playing/unlock levels/etc). Again, this will require some kind of server for the advertisements. Depending on your setup, you can also do many of the things above.
Dealing with the server issues is a whole can of worms itself, and will likely dominate your time and energy. For a single executable kind of release, honestly, you are more likely looking at the first option.
Hope this helps.