How do I find beginners’ tutorials for Mac game programming?

In general, for Mac programming you’ll always find great resources on Scott Stevenson’s CocoaDevCentral and CocoaBlogs sites. There’s also the two Mac programming Wikis CocoaDev and CarbonDev.

For games programming, iDevGames is supposedly very popular. If you’re looking to do high-end, high-performance graphics work (i.e. not just the occasional animation), you’ll probably have to drop down to OpenGL, and for that the ultimate tutorial would be The NeHe OpenGL Tutorials, which also comes with info on how to do them on a Mac.

Would you recommend Cocoa or Carbon for games?

It depends. If you’re doing a lot of standard UI, Cocoa is definitely the better choice. If you’re doing a lot of custom UI, you won’t be using much of either UI library. Since Apple’s been frantically trying to saw off the branch on which Carbon sits in recent years, the decision has probably been made for you.

In the end, it again depends on your kind of game. If you’re doing a board game or another kind of game that only needs 2D graphics (and this includes pre-rendered 3D views, and thus also many isometric game graphics as long as they can’t be freely rotated), Cocoa’s NSViews will work.

Carbon has a leg up there with HIViews, because they are actually supported to be drawn overlapping. In Cocoa that works as of Leopard, though it’s a bunch more complicated. You may have to sort the view list occasionally, or switch on CoreAnimation layers (thus needlessly increasing system requirements to exclude lower-end graphics cards).

If your graphics are fairly simple (e.g. pre-rendered and similar size), you may also want to try using one huge view for all of them, and using the dirty rects (“update regions”) passed to you by the OS to selectively redraw only the parts that actually changed. This will give you less built-in behaviour, but will on the other hand forego some of the overhead all the built-in behaviour has.

Otherwise, you’ll probably be using OpenGL, which means you’ll probably just create a standard Cocoa app and stuff an NSOpenGLView in its main window, and that’ll be about all of Cocoa you’ll find yourself using. The remainder of the display code would probably be C OpenGL calls, maybe wrapped in C++ or Objective C classes for more manageability. If you’re wondering how you could use C++ in an NSOpenGLView, search the web for “Objective C++”, which is a way to use both ObjC and C++ in the same file.

What about sound?

For sound-output, Cocoa’s classes always were a bit rudimentary. Only as of Leopard, they finally allow volume control and specifying a device, making the sound loop and even specifying an output device and a channel mapping. Before that, the Carbon sound manager was close (though it was not quite easy to load sounds other than ‘snd ‘ (.sfil) and AIFF), but most people had to punt and just open an audio-only QuickTime movie and play that, either using NSMovie or later QTMovie. However, for most apps these APIs should be enough to play background music and the occasional sound effect.

If you need Tiger compatibility or anything more complicated, like real ambient sounds, you’ll probably find yourself dropping down to CoreAudio, which is a horribly complicated API for sound playback (For a taste: One CoreAudio engineer called pausing playback an “advanced feature” at a presentation). There’s an AUFilePlayer that can be made to work if your input is a file and you don’t need to know when it’s finished playing, but otherwise you’ll be in a bit of pain using that.

Alternately, you can leverage open source libraries whose Mac versions were built on top of CoreAudio, like OpenAL, to retain your sanity.

Any actual game programmers wanna chime in with their suggestions?