Boxer

Developer diary: plans and progress reports.

one point one point one Tuesday 2nd August 2011

Boxer 1.1.1 is now released, bringing a gallon of improvements to joystick support and fixing several painful Lion bugs. Along the way I’ve added some pretty new notification bezels, see:

1.1.1 also removes a major irritation from Boxer’s disk-image support: the programs panel now lists programs inside disk images, and lets you set them as the default program. This really helps with CD-ROM games that leave all their programs on the CD: previously, if the game didn't put any programs on the hard drive, Boxer would force you to launch the game from the DOS prompt or write your own batch file. Ugh! No longer.

This required a change to the gamebox format: the path to the default program is now stored in Game Info.plist, instead of as a symlink. (Symlinks can’t be resolved if they point to paths that don’t exist, you see.)

What the future holds

In 1.1.x I’m focusing on refining what’s already here, rather than adding new visible features. Boxer’s codebase has become pretty shambolic in places, so this is my chance to clean house and fix some longstanding niggles. Most Pony Features will be saved up for 1.2.

The 1.1.x branch will likely be the last Boxer version that supports Leopard. Apple are making it increasingly harder to keep developing for older OS versions on newer ones, most of my user base is on Snow Leopard now, and I’ve been getting blue balls from all the time-saving new Snow Leopard and Lion goodies I’m not able to use because of Leopard. So one of my goals with 1.1.x is getting it to a mature state to leave behind on Leopard.


One new feature may make it into 1.1.x which won’t be visible at all: shadowed gameboxes. After import, a gamebox would be treated as read-only like an OS X app: all file modifications would be saved to a separate per-user “shadow” gamebox instead.

The main benefit is that it would keep your gameboxes in a pristine just-imported condition: one that can safely be shared between users on the same machine, or backed up or distributed, without worrying about savegames and cache files and other per-user detritus. It would also make it possible to launch gameboxes from read-only locations, without having games fail because they can’t write files.


For 1.2 I want to bring in the iPhoto-style game browser I’ve discussed in the past. This will be key to getting Boxer into the App Store: the old where-do-you-want-your-games approach just isn’t gonna cut it, and it feels like the games folder implementation isn’t a good fit for Lion anymore.

That’s going to be a lot of big hard UI work, because I don’t want to ship something that isn't as good as or better than Finder for managing your games. But moving to a game browser model will simplify Boxer’s UI, preferences and import workflow, and generally just fit better on the modern Mac.

Very little will actually change behind the scenes: Boxer will respect any older games folder you have, gameboxes will keep being gameboxes, you’ll still be able to browse your games from Finder and so forth. If you’re happy with how Boxer does things now, there’s nothing to worry about.


1.2 will probably also introduce preferences for tweaking your joystick controls. I’m thinking about how to bring button-to-key mappings into the fold: both to complement the existing joystick emulation (to let you make use of all those extra buttons on your gamepad) and to allow joystick-alike control for games that didn’t support the joystick at all.

My intention has been to keep any controller mappings global, to avoid stepping into the UI quicksand that is control-scheme profile management (which I regard as the point where tweaking stops being fun and starts being too much like fucking work). But controller-to-keyboard mappings obviously need to be per-game, since keyboard controls differ so much from game to game. If anyone has an example of an emulator that does per-game control schemes sanely, please speak up.

Design by 40watt.