next »

[oahda]

Yo. I think this might be an interesting topic warranting it's own thread.

There are many ways to deal with assets when it comes to a game written in C++. They could just be out in the open in a folder distributed alongside the executable. Some would avoid this simply for piracy reasons, but others might argue that some sort of zipping also reduces the size on disk, and baking the assets into the executable somehow might make deployment less of a hassle if it's possible just to distribute a single file.

So, the questions:

Which way(s) do you prefer and why?
How is it done, technically? What do you recommend? Any libs?
Et cetera..!

[Polly]

Which way(s) do you prefer and why?

It entirely depends on the type of project & distribution .. but when it makes sense i quite like portable & dependency-free single file executables.

[oahda]

How do you usually accomplish that? I've never done it, so I've no idea how it works, really. I guess you need some tool that generates strings or numbers representing the files' data that can be compiled into the program somehow?

[Polly]

How do you usually accomplish that?

Depends a little on the compiler & platform. Windows for example uses the PE format for executables which supports embedded resources, so most compilers that ( can ) target Windows come with features / tools that allow you to use that. Alternatively you can just use inline-assembly in your code to include a binary blob at compile-time

[voidSkipper]

One thing to consider is that it could be quite a lot easier to patch your game if its assets are separate. Depending on the complexity of your game and the capabilities (if applicable) of your scripting engine, external resources can be quite useful.

I don't think that piracy is really a concern - there's nothing to stop the motivated pirate from pulling assets out of an EXE either. A lot of studios have compromised with using encrypted external assets, but the thing is, you have to decrypt them at some point or you're never going to be able to use them. It's very hard to keep your users out of your business, and before long you're going to end up cutting off your nose to spite your face.

I know that, for example, 5th generation pokemon games use encrypted asset data, which is decrypted into randomized locations in RAM to try to keep it hidden. Unfortunately they didn't consider that a) just following the routine that assigns the randomized locations to find the data would negate any benefits of such complexity and b) having such a routine  makes it laughably easy to mod the game, which is something they dislike and expressly forbid.

As with anything, it's a question of scope.

[bdsowers]

I use external, uncompressed, unencrypted assets. It's just dirt simple, low fuss, and if I want to quickly see an edit to one of the assets I don't have to rebuild or touch anything else - I  just quickly edit the asset and run. Plus it leaves the door open for players to mod the game if they want, which I don't mind.

The assets will get compressed when I compress the rest of the game anyway via ZIP or installer, so size isn't an issue. Also my games have 0 piracy protection, so it's not like I'm making it any easier or harder to pass around.

[oahda]

One thing to consider is that it could be quite a lot easier to patch your game if its assets are separate. Depending on the complexity of your game and the capabilities (if applicable) of your scripting engine, external resources can be quite useful.

Yeah, I think so too. But should they still be in the complete open or get installed some nice place or be in one of those compressed formats or what? Not sure what's best.

I don't think that piracy is really a concern - there's nothing to stop the motivated pirate from pulling assets out of an EXE either.

I agree, and this isn't one of my concerns. Just brought it up as a consideration some people have.

[InfiniteStateMachine]

I use external, uncompressed, unencrypted assets. It's just dirt simple, low fuss, and if I want to quickly see an edit to one of the assets I don't have to rebuild or touch anything else - I  just quickly edit the asset and run. Plus it leaves the door open for players to mod the game if they want, which I don't mind.

The assets will get compressed when I compress the rest of the game anyway via ZIP or installer, so size isn't an issue. Also my games have 0 piracy protection, so it's not like I'm making it any easier or harder to pass around.

This would be my preference for a windows desktop game as a consumer. Unless maybe it's a asset heavy game that would benefit from packing everything into a contiguous package file.

[oahda]

This would be my preference for a windows desktop game as a consumer. Unless maybe it's a asset heavy game that would benefit from packing everything into a contiguous package file.

Yeah, that's the thing I'm worrying about.

[Cheezmeister]

*shrug* If and when performance seems to be an issue, you can profile your game and see where the bottlenecks are. In the rare event that loading shazz-tons of assets is your weak link...well, zipping everything would probably worsen the issue. There are compilation-y things you can do to content at build-time to get it into memory faster at runtime, but they tend to limit portability and I don't actually know what they are. Jon Blow might

Until then, though, I favor the bdsowers approach. Keep it simple, silly!