How Mac Games Should Save

Putting on my GameHouse hat, I’d like to post on how games should save their state. (I often receive games that do it wrong.)

Games should not save state within the game bundle.

Games should not save state next to the application.

Both will fail if the game is run from a read-only volume (such as a disk image), or if the user doesn’t have write permissions to the /Applications folder (where someone may have installed the game).

I recommend saving to ~/Library/Preferences (or a folder therein). Locate this with FSFindFolder if you’re not using CFPreferences or NSPreferences.

Why not ~Library/Application Support? I figure most games track options such as sound effect and music volume. These are definitely preferences. Apple says of ~/Library/Application Support: “This directory should never contain any kind of user data.” And saved games are definitely user data.

So I’d say: anything the game saves goes in ~/Library/Preferences. Additional levels, downloaded user avatar images, etc. would go in ~/Library/Application Support.

Stacks in Leopard

One cool thing about a stack: you can click on its Dock icon, then drag a file. I’ve found this especially handy with the Downloads folder: you can drag a file right to the Trash, or to the Dock icon of an application you want to open it in.

I’ve written before about how the Downloads stack is useful because you can sort by date added. It’s thus easy to get at whatever I most recently downloaded. (I set this stack to View as Fan because it looks cooler, and because I have over 200 items. There’s really no point in seeing the whole thing in a menu.)

Although stacks can be fun and useful, sometimes the old standard menu was handier (especially if you had a folder of folders in the Dock). It would be great if the menu were View as > Fan | Grid | Menu — don’t get rid of stacks, but let us use the old way as well.

Leopard Spotlight searches any metadata

In Leopard, much more of Spotlight’s functionality is exposed. You can now search on any defined attribute. Several tips are floating around on how to search for system files, but the search window is far more flexible — it lets you query metadata from any application with a Spotlight importer. For example, here’s how to search for all Opal outlines with a lot of topics:

1. Open a search window (in Finder, choose File > Find)
2. Click the Kind popup
3. Choose “Other...” from the bottom of this menu (not from the “is” menu)
4. Locate “Topics,” select it, and click OK.
5. Choose “is greater than”
6. Type the number of topics

Programming in Leopard

As a developer, getting to use Leopard on a daily basis means getting to use Xcode 3.0 on a daily basis. I’m pretty happy with this update, though some of the changes simply take a bit of getting used to. The new SCM integration is much better, though it also introduces the concept of a project root. SCM applies to all files in the root. With Opal, this isn’t a problem. With a GameHouse game, it is, because each game uses 4 libraries and one game-specific folder from the root. Getting SCM info for the other 50 game-specific folders takes a lot of time, and showing said info confuses things.

It’s a little disconcerting that rebuilding a Cocoa application changes its behavior. For example, Opal’s Export as command used NSExportableAs to specify the possible types. Under Leopard, this requires the use of UTIs, which Opal didn’t use. So Export as (which worked fine in Leopard) broke as soon as I rebuilt. Another change was the preview pane in Print dialogs. This showed up only after I rebuilt in Leopard. That was cool, new behavior for free! Except it wasn’t quite right. So I had to figure out how to hook Opal’s print dialog controls so that they updated the preview. Bottom line: an application that works fine in Tiger may require significant work as soon as you touch it under Leopard.

I haven’t seen anything similar in the Carbon world (which GameHouse games use).