Sell me on Developing Games on Mac/Cocoa

I'm a noob on this board. I'm an academic scientist (neuroscience/AI) who develops software for my own and now (hopefully) for others use. I'm starting my most ambitious project to date - a large scale neural network simulator with a nice GUI front end. The hope is that I can make it easier for non-programmer/non-mathematician neuroscientists to analyze their data and simulate very large neural networks. The tools I'm creating are very visual and so I find myself borrowing a lot of techniques and code from game programming and that is how I ended up here.

Before I get any deeper into this I wanted to get opinions on game dev on the Mac, as I am trying to make this package as intuitive and 'game-like' as possible for people to use. I am already comfortable with Cocoa, Bindings, Core Data, etc., for data display and manipulation so there are strong reasons for me to keep using the mac. What I am wondering is if there are any more powerful libraries for game dev (esp. 3D graphics and game physics) available for Windows and/or Linux that I will be missing out on by locking myself into the mac.

Also, If anyone knows of a post or article that has a good head to head comparison of game dev on different platforms that would be helpful.

I'm not too familiar with the neuroscience community but my first question would be whether there is a particular trend in what neuroscientists use for their computing platform.

But really, I think what you're looking for is good cross platform solution. Have you looked into SDL/OpenGL at all? This would have all the power you need for graphics and would be easy/trivial to port between OSes.

Yep Jaden, SDL is on my reading list, but thanks for the prod - I'll go back and look it over now. The 3D data displays I have written so far are all Cocoa OpenGL based.

The trend in neuroscience/AI is, in general, away from Windows and towards either Mac or Linux. The instability and inefficiency of the Windows kernel make it quite nasty for data intensive or real-time science applications. I have all three OSes (XP, Red Hat, and 10.4) running on different computers on my benchtop, and its the Windows box I consistently want to throw out the Window. Unfortunately its attached to a very expensive piece of equipment that only has Windows drivers written for it.

Rake doesn't support parallel builds. As far as I'm concerned, that's where the story ends. A build that takes 2-3x longer than necessary is a bad build!

(Yes, I know about the explicit command you can put into the Rakefile to force it to execute a particular set of tasks in parallel, but that's not really useful).

SCons has a lot more built-in knowledge -- for example, how to build static and dynamic libraries and executables with MSVC, mingw, and vanilla GCC. Usually that's a good thing; sometimes it's a little annoying (but it's completely avoidable if you want to start from scratch).

To use SCons on Mac OS X you really need the bleeding-edge version (0.96.91 or later), which occasionally has hiccups. I haven't had any serious problems, though.

Thanks for the replies so far, but I was hoping I could get some more details. What is it specifically about game dev for the Mac that makes it better? Libraries, hardware, speed (graphics, processing, or otherwise) - these are the kind of details I am looking for.

I can certainly see the value of SDL for cross platform applications - but lets say I choose to make this a Mac only product - am I better off sticking with the Cocoa and Core libraries, or are the SDL libraries better in some ways?

On Xcode - OneSadCookie, most of my development recently has been in a text editor or XCode, so I don't have a lot of experience with other modern IDEs. What makes SCons a better choice than XCode/IB?

Game development on Mac OS X is better because you get standard unix stuff to get stuff done, the best text editors on the planet (whether you think that means vi, emacs, TextMate, or even SubEthaEdit or BBEdit is up to you ), Shark and the OpenGL Profiler to tell you precisely why your game is slow.

Game development on Mac OS X is worse because you have to account for worse graphics hardware than mainstream games on Windows do (mainstream Windows games seem to currently assume a GeForce 6600 or an ATI X700 or better, and those are very high-end cards for the Mac still), and the graphics drivers are not always reliable, nor are new features readily available.

Xcode is fine if you just want to build a simple application from a collection of C/C++/ObjC source. As soon as you get more complex, for example, a custom tool to generate sources or resources, it breaks down quickly. It's also atrocious at managing a folder hierarchy of Resources. SCons is harder to set up initially, but will always elegantly do what you want.

You know what I'm surprised no one has mentioned yet? The community. It's so much more lonesome developing on the PC compared to the Mac. When you develop things on the mac there are people who are actually interested in testing and offering advice for your program.

I don't know how much that factors into what you're doing, but I know it's a big factor in why I develop my stuff on the mac platform.

Thanks for the replies so far, but I was hoping I could get some more details. What is it specifically about game dev for the Mac that makes it better? Libraries, hardware, speed (graphics, processing, or otherwise) - these are the kind of details I am looking for.

I can certainly see the value of SDL for cross platform applications - but lets say I choose to make this a Mac only product - am I better off sticking with the Cocoa and Core libraries, or are the SDL libraries better in some ways?

If you're going to go Mac-only, I'd say Cocoa for sure. If graphics speed isn't essential and you'd like nice anti-aliased graphs and stuff, then using Quartz within Cocoa is a nice option. But really, the ultimate combo is Cocoa for system UI stuff and OpenGL for graphics. You could still use Quartz for data graphs in other views though, just to make them real pretty.

The Windows equivalent to Cocoa, I suppose, would be .NET using C#. But .NET runs through the CLR, which is a virtual machine like the JVM, as far as I can tell. I guess you can write your speed-dependent code as separate DLLs, but... Cocoa operates under a runtime environment using real code on the processor, not through a virtual machine. I guess you're welcome to infer your own conclusions from that, but Cocoa seems obviously much nicer to use overall in my experience so far (which is a lot of experience with Cocoa, and just barely learning .Net, so be careful how you take this if you want unbiased).

Jaden does have a point about the community, but it can be taken both ways I'm afraid. Looking at signal to noise ratio: while there is *much* less noise in the Mac community, which makes it seem more personal, the signal is most often clearer because there isn't much signal to begin with. Many times you're left cooking your own batch of code without many resources which may be plentiful on the Windows side of things. I prefer the Mac community much more though, but available community resources is also something to consider. For your specific application, it's hard to say here since we aren't really hard AI people -- games go with weak AI, which is homebrew in all applications I know of, so libraries and resources are of little concern. There are a couple of popular physics libraries for games available on the Mac though if you need them, but YMMV.

BTW, I think Xcode is just fine, but I have my bad days with it too...

Thanks again all, here are my conclusions after a few days of hashing through all this stuff:

I am absolutely convinced that software development ON a Mac is a far more enjoyable experience than anything else I have tried, and recent explorations have only enhanced this feeling.

As I see it now, there are two main limitations for developing games FOR the Mac: graphics cards and middleware. On graphics cards - my main target is scientists who can probably afford a MacPro with a screamin card, so it is not so much of an issue, but I would like a basic version to be usable on machines with a more standard card.

Middleware is an interesting issue, because there is definitely a lot more stuff out there that is targeted for Win32, but more and more it seems like stuff is becoming cross platform. I am test driving the Unity system right now, and it is extremely nice and generates code which can run on multiple platforms and even on the web. The only complaint I have is that to add additional functionality the system expects C# or javascript code, neither of which I am particularly fond of, but its not unexpected considering the dominance of Windows for games. I am also looking through some of the open source physics engines and looking for ways to speed up my code.

In the end what I will probably do is stick with Cocoa(and some bare metal C) for the engine and UI, and then continue trying to beef up my OpenGL skills to get the viz looking sharp. I have realized that the code I have written already is pretty much a neural physics engine, and I don't want to have to port it to something else (without a really good reason) as I have used Core Data and bindings extensively to manage all the parts of the network.

BTW - the short dev time that Core Data allowed me to generate this engine makes me think you might be able to generate a really good game development system, like Unity using it and create an f-script based editing system for it.

OneSadCookie - auto-generating sources and resources sounds incredibly cool, what are you up to? I may have to talk to you more about that, as another project I have been wanting to play with is self-evolving software.

ocsrazor Wrote:OneSadCookie - auto-generating sources and resources sounds incredibly cool, what are you up to? I may have to talk to you more about that, as another project I have been wanting to play with is self-evolving software.

Nothing that fancy!

For my game Outnumbered, I use a custom build tool to convert OBJs and MD2s to a more useful model format, and another custom build tool to convert PSDs and layered TIFFs to JPEGs.