The advantages with Molebox are severalfold:
1) you can write your program normally, then create a single exe which includes everything and all your load calls will be changed automatically to reference packed files.
With PakMaker you need to replace every call to an external file that will be packed.
You could write wrapper code around the standard Pak calls to transparently handle cases where the packed data has not yet been packed, which would make this less of a burden during development, but it's both annoying and non-transparent.
Note that MoleBox even transparently copes with files that aren't packed (if you need to store and retrieve saved game or config files, for instance).
2) MoleBox transparently replaces file input code with code that is able to directly load moleboxed data with no intermediate file. This is both FASTER and MORE SECURE than the approaches taken by tools like PakMaker.
When you access a Pakmaker file it is decompressed and stored in an external directory. The external files may be removed manually and may get automatically deleted on the way out (I'm not sure) but -- if you alt-tab out of the running app OR kill the process, you can go find your unprotected files and steal them.
I might add that using a tool like PakMaker (which leaves unprotected files lying around on hard disks) actually contravenes the license agreements for some media (e.g. if you use licensed textures and models from Turbosquid you may discover that the media MAY NEVER be revealed in such a manner to an end-user).
3) MoleBox provides for packaging app and data separately and together and for patching. This latter is very important if your application ever actually SHIPS since you'll need to handle updates eventually, and you and your customers will pay for bandwidth and download times.
4) MoleBox allows you to encrypt your application binary (very handy if you're implementing a licensing scheme, since the code that crackers see in their debuggers will not be trivially mapped back to the actual executable).
5) MoleBox Pro allows you to embed DLLs in the executable.
Please note -- I do not use Molebox, I've just read the documentation and forums. I don't know how well it WORKS, just what it's supposed to do and how it's supposed to do it. It uses exactly the same approach we used for handling data in Prince of Destruction (including compressing and encrypting all our code).
MoleBox is kind of pricey -- $49 for the standard version and $99 for the pro version. But, unlike the other options, you don't need to start using it until your project is done. If you've COMPLETED a project and it's ready to ship, I think MoleBox is worth it. If you haven't, what do you care? (And meanwhile you don't need to worry about changing all your file load calls...)
1) you can write your program normally, then create a single exe which includes everything and all your load calls will be changed automatically to reference packed files.
With PakMaker you need to replace every call to an external file that will be packed.
You could write wrapper code around the standard Pak calls to transparently handle cases where the packed data has not yet been packed, which would make this less of a burden during development, but it's both annoying and non-transparent.
Note that MoleBox even transparently copes with files that aren't packed (if you need to store and retrieve saved game or config files, for instance).
2) MoleBox transparently replaces file input code with code that is able to directly load moleboxed data with no intermediate file. This is both FASTER and MORE SECURE than the approaches taken by tools like PakMaker.
When you access a Pakmaker file it is decompressed and stored in an external directory. The external files may be removed manually and may get automatically deleted on the way out (I'm not sure) but -- if you alt-tab out of the running app OR kill the process, you can go find your unprotected files and steal them.
I might add that using a tool like PakMaker (which leaves unprotected files lying around on hard disks) actually contravenes the license agreements for some media (e.g. if you use licensed textures and models from Turbosquid you may discover that the media MAY NEVER be revealed in such a manner to an end-user).
3) MoleBox provides for packaging app and data separately and together and for patching. This latter is very important if your application ever actually SHIPS since you'll need to handle updates eventually, and you and your customers will pay for bandwidth and download times.
4) MoleBox allows you to encrypt your application binary (very handy if you're implementing a licensing scheme, since the code that crackers see in their debuggers will not be trivially mapped back to the actual executable).
5) MoleBox Pro allows you to embed DLLs in the executable.
Please note -- I do not use Molebox, I've just read the documentation and forums. I don't know how well it WORKS, just what it's supposed to do and how it's supposed to do it. It uses exactly the same approach we used for handling data in Prince of Destruction (including compressing and encrypting all our code).
MoleBox is kind of pricey -- $49 for the standard version and $99 for the pro version. But, unlike the other options, you don't need to start using it until your project is done. If you've COMPLETED a project and it's ready to ship, I think MoleBox is worth it. If you haven't, what do you care? (And meanwhile you don't need to worry about changing all your file load calls...)