Using files for game graphics data

WFleming
Unregistered
 
Post: #1
Currently working on a shareware 2D sidescrolling game. Right now I keep all the graphics, sounds, etc. in the application's resource fork. I am thinking about putting these into separate files (ie. MyGame Graphics, MyGame Sounds, etc.) which would be in the same directory as the application.

My thinking is that since the graphics for the sprites, tiles, etc. are several megs, it would make a much smaller download for an update (an update would probably be the game application rather than an updater app).

Anyways was hoping to hear some pros and cons to either way of doing it.

thanks
Quote this message in a reply
Member
Posts: 353
Joined: 2002.04
Post: #2
I would definitely put them in separate files, the only real con I can see to this approach is needing to make sure all the files are in the right spot when the game plays.

You also might want to think about alternatives to using the resource fork as it as outdated type of file.

*Note to self: practise what you preach!* I still use the resource fork of my app for sounds, menus and dialogs. Should really fix that.
Quote this message in a reply
Feanor
Unregistered
 
Post: #3
I recommend against using the Resource Fork. If you are writing a carbon game, you should be able to use the Bundle system just fine (I can't remember if the bundle looks like a folder in OS 9 but I thought they added bundle support). If you want to support pre-carbon, you can still use separate files, just give everything special icons (including your main folder) and users will know not to mess with them.

If you're feeling really clever you can put all of your data into one big data-file using an embedded directory, like the Quake series -- they .pak, .pk2 and .pk3 use uncompressed zip format, which allows for internal directories. Then of course you need a utility/code to programmatically read the contents of a zip file.

FÎanor
Quote this message in a reply
Member
Posts: 201
Joined: 2002.06
Post: #4
If you do this, it may be best to not only make special icons for it, but make the names all technical so that users understand that those files are for the computer to use and not to be messed with by the average joe. Putting "dat" or somethign like that at the end of the filename may make it appear more technical.

Archives are sometimes good. Many games use that. It would be harder to program for, but all your stuff will be in one place, meaning a lot less clutter in your applications window/data folder's window.

Haha, I feel like I'm just pretending to know what I'm talking about, not having gotten to the stage of making any real games yet other than a bad clone of Snake with no real graphics. Everything I just said is just speculation to me. Wink
Quote this message in a reply
Moderator
Posts: 608
Joined: 2002.04
Post: #5
If you were REALLY tricky, you could make the data folders invisible.
Quote this message in a reply
Member
Posts: 201
Joined: 2002.06
Post: #6
Well, wouldn't that mean that if the user moves the application none of the data files would go with it? They wouldn't know any better if it's invisible.
Quote this message in a reply
Moderator
Posts: 608
Joined: 2002.04
Post: #7
Ah, true. Though... if the user was moving it, wouldn't they just move the folder that has the game and everything else? Of course, if you have an invisible data folder, then it would be harder for the technically inclined to add their own graphics. May or may not be a good thing... Smile
Quote this message in a reply
Member
Posts: 40
Joined: 2002.04
Post: #8
I would also suggest separate VISIBLE folders. Only sneeky people trying to hack your game or curious game developers venture into the Data folders Smile

If your worried about the average user messing around with your graphics, could you not just append some data to the beginning of each image file.. or better yet put all the graphics into your own special file format, so standard image editors couldn't open it?
Wow that was just a spur of the moment idea. I might actually try that myself Smile

Seeya
Quote this message in a reply
ylaporte
Unregistered
 
Post: #9
If you are targetting MacOSX (I don't know how bundles behave in Classic), great solution is to use bundles. Basically every application is a bundle. In short, a bundle is a folder with it's content organised that the user only sees as a single file (in many cases, the application itself).

So you can have many separate files inside the bundle so they always stay with the application (since they are inside). There are many facilities in Cocoa (most of them around the class NSBundle) to access them, I believe there are in carbon as well. I can't check it right now since I am at work (on a PC).
Quote this message in a reply
Unregistered
Unregistered
 
Post: #10
I forgot to say it but you can open bundles in the finder. Just right click (control click) on it and select the show content item in the contextual menu. That way, someone or an updater program can change a bundle's content.

You can even have bundles within bundles, it is useful if you want to put all your sounds together in a bundle and place it inside the application's bundle. Then, someone could replace that bundle to update. An event more sophisticated way of updating would be to have you application be the creator and default to open the bundle's file type. And when the user would open a bundle by double clicking on it you application would open and update itself by copying the new bundle's content inside itself. I don't know if I am making sense but anyway...
Quote this message in a reply
Moderator
Posts: 365
Joined: 2002.04
Post: #11
Quote:Originally posted by ylaporte
If you are targetting MacOSX (I don't know how bundles behave in Classic), great solution is to use bundles.

Bundles work very nicely in Mac OS 9. On earlier system versions, the application will still work but the bundle appears as a folder containing an alias to the application and a Contents folder (that was a deliberate design decision by Apple). I used the Carbon based Core Foundation bundle routines in my game and it made things much easier, not least because it provides a bunch of functions for scanning for and loading resources in the bundle.

If your game runs under Carbon and you don't mind it looking a little odd under Mac OS 8.6 and earlier, I would recommend you bundle it. You can still use files with resource forks in the bundle if you really want to, but as others have said, you should probably try to phase them out. If you want to provide updates that only change the application file, you ought to provide an installer, because you can't expect novice users to crawl around inside the bundle replacing things.

Neil Carter
Nether - Mac games and comic art
Quote this message in a reply
Moderator
Posts: 608
Joined: 2002.04
Post: #12
It's not possible to create a bundle without ProjectBuilder is it?
Quote this message in a reply
Moderator
Posts: 365
Joined: 2002.04
Post: #13
Quote:Originally posted by jabber
It's not possible to create a bundle without ProjectBuilder is it?

CodeWarrior 7 can also create bundles (although it does it in a slightly freakish way). That's what I'm using. With a bit of luck CodeWarrior 8 will have better bundle support.

I think it's also possible to make your own bundles by setting up the folder heirarchy and plist files yourself and turning on the package bit for the enclosing folder, but don't quote me on that! The Apple documentation on CFBundle has information on this kind of thing.

Neil Carter
Nether - Mac games and comic art
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #14
You can make your own bundle in the Finder by putting folders with appropriate names in appropriate places. Then you need to turn on the bundle attribute for the folder, which can be done by Apple's Package First Aid application, as well as a couple in the Carbon SDK.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Text based graphics game mmorpg. MetalMouth 6 5,635 Mar 4, 2008 09:55 AM
Last Post: drslinky1500