If you have no mac programming experience, I'd say it's a tossup. With Carbon you can stick entirely to C++; however, the C interface (and the sheer size of it) can be confusing. With Cocoa, you must learn Objective-C, but the design is OO. The choice could depend on what you want to program. Because I program in OpenGL, I like using a cross-platform interface like SDL or GLFW rather than a mac-specific one.

Java is becoming the language of choice for instruction at college. It is a clean cross platform development environment where many of the tedious aspects of C/C++ are non-existent. This allows a student to focus on the science aspects of programming like classical algorithm analysis and data structures. It is not, however, well suited to game development at the moment. At least not serious game development.

I am actually going to disagree with this. ( coming from someone who truly loathes JAVA, this is a bit surprising ). JAVA is not suited for high-polygon, high-details games, that's for sure. But, considering the machines we are working with nowadays, the language overhead is pretty negligeable for, say, a poker game.

A good way to illustrate my point is to point to the zillion JAVA web-based games out there.

Remember, A game is not defined only by their graphics ( wich are, IMHO, the only serious bottleneck at the moment ) EDIT: Whoa, reading myself, this almost sounds like a flamebait, I do think that there are other bottlenecks ( collision detection most notably ), but to a much lesser extent than graphics.

Really? I'm loving java. I certainly don't think it's the end-all programming language, but it certainly makes sense to use it to replace most uses of C++. That said, I haven't been using outside of class for anything yet, but it seems like a very solid language.

Skorche Wrote:Really? I'm loving java. I certainly don't think it's the end-all programming language, but it certainly makes sense to use it to replace most uses of C++. That said, I haven't been using outside of class for anything yet, but it seems like a very solid language.

The problem with Java has never really been the language itself (though the language itself gets annoying in the amount of characters you have to type to do all the typecasting) but the APIs that come with it. This is less of a problem now than it was a few years ago, but they're still not that nice. For example, if you look at a lot of older java games, the way you blit sprites to the screen is a complete mess, and you couldn't really access buffers you created by loading images directly, making a lot of things much harder than they needed to be.

Also, this is probably also somewhat better than it used to be, but despite claiming to be cross-platform, the Java runtime libraries on different OSs are only somewhat compatible for a lot of these graphical and sound APIs, making it so something that runs on Windows might flash or do something weird on the Mac. This was also a nightmare to deal with- I assume Java3d is probably a lot more consistent across systems, but if it's anything like the compatibility in the past, it's probably terrible.

These API problems are the main reason nobody uses Java for large game development, and if you're trying to do anything with bitmap graphics I would not recommend it.

I personally went for a combination of OpenGL and SDL. Both easy to learn and you can get results fast. Now that I'm making games with them I'm getting a better feel for what I'll need to learn next.

There is no silver bullet API that will solve all your problems. They all have their limitations. Start with the one that seems to do the most for you-- in my case it was SDL. Eventually, you'll be using a combination of them.

But whatever you choose, I suggest also learning OpenGL. You can use it with Carbon, Cocoa, and SDL, and it's easy to pick up.

EDIT: There's no reason not to learn Java- it should only take you a few days if you already know C++. But as far as using it- it's a different tool for a different job. It's useful for plenty of things, but for game development C/C++/ObjC + Carbon/Cocoa/SDL/OpenGL is generally a better set of tools.

I really like the language in general, but I have noticed that libraries for multimedia seem to be really touch and go. On the other hand, I wasn't really planning on doing to much multimedia programming in java, because it seems like such a poor language for it.

I did mention that Java was not suited for serious game development. I am sure there are countless non-intensive games out there put to market quickly by the beneficial aspects of Java development. You are unlikely, however, to get a job at Game Studio without C/C++ Experience and a solid understanding of Computer Science. Projects are too big now to be hacked together. Some real distributed development techniques need to be employed. Just my two cents.

there is a macro in the Carbon library that will return you a CFString
so dealing with them isn't that much of a hassel.

CFSTR()
use that and worry not.

and the language issue depends entirely on what you're going for. Cocoa makes things a bit easier in my opinion.
But Carbon is still pretty easy once you get the hang of it. I am by no means a master of carbon but I'm learning and it's not that difficult once you get on board.

Cocoa makes things go really fast, again at least with my experinces so it is a time saver.

anonuser Wrote:But Carbon is still pretty easy once you get the hang of it. I am by no means a master of carbon but I'm learning and it's not that difficult once you get on board.

I agree, at first when I was looking at the Carbon API initially, I balked at the way the event handling model was setup (I was already brainwashed into Win32 and MFC). Then when I really go into using it my impression of it changed, I thought it was pretty cool the way message handlers were attached to events.

Java's "multiplatform" claims are in my experience very misleading. I've found many problems with inconsistent/drifting GUIs and performance (especially on Mac).
For me, C (or C++) is the "multiplatform assembler". It get's you as close to the hardware as you can be without locking yourself to a specific proccesor. My personal choice is SDL+OpenGL+C++. My current uDG entry, Okugai, is about 10000 lines long, and when I wanted to test it on a PC, porting it took me about half an hour.
For mac specific stuff (standard widows and widgets) I prefer Cocoa, but usually find myself making parts in Carbon because it gives you more control than the Cocoa wrappers (thats what most of them are) do.