Slashdot Mirror
Mac OS X: Game Developer's Playground
Mauro Notarianni writes: "In the Stepwise article, 'Mac OS X: Game Developer's Playground,' Troy Stephens writes, "Mac OS X has the potential to be a superb launching pad for doing game development.'
The author describes how 'Cocoa's developer productivity benefits, when combined with Mac OS X's strong support for technologies such as OpenGL and QuickTime, can empower game developers to create the custom production tools they often need in a fraction of the programmer hours it takes on other platforms.'"
Most development, are made just filling in already made game-templates. These templates are called "Game-Engiens", and have names such as Unread, Quake and so on. _alot_ off games are based on these. Unread engien are sold for 100'000$ to other game developer to make there games. Implementing a new game is almost just scripting the NPCs and loading some fansy GFX.
Sorry, but maybe you should read the article before you comment it. The article talks about tools for games development, not the games themselves.
Don't forget GNUStep. Also , notice that NEXTSTEP's and Apple's and GNUStep's (and pretty much the defacto) Objective C compiler is gcc. So you're saying that Objective-C limits your platform to anywhere gcc is ported ! Thats not really what I would call a portablility issue !
Now if you had pointed out that making use of High level Cocoa classes would restrict you pretty much to Apple until GNUStep caught up then you might have had a point. But Objective-C ? gcc and GNUStep-Foundation look pretty damn portable (and Free) to me, mate.
-- Oh Well
To protect my pathetic bandwidth on the local server, the article is also available here on the graphics server. That should cover off any bandwidth issues.
Troy's article really does highlight the use of these environments for tools behind the scene's.. there is an older article on this as well that is linked from Troy's document.
Scott AnguishStepwise
http://www.stepwise.com
I have just started to develop on the OS X platform using the Apple developer tools and online tutorials, as well as Aaron Hillegass's brilliant Cocoa Programming for OS X book (the link is to Amazon, there was also a review of it here on Slashdot). Some resources I have found indispensible have been:
www.cocoadevcentral.com
& of course,
developer.apple.com
It is a nice environment to program in, although I am finding the objective C and the size of the framework to be the main hurdles. Still, there are so many great resources online and packaged with the developer tools from Apple (a free download with tons of documentation and examples), that I am slowly learning.
Hewligan
My Blog: BrainMess
but with macs holding <4% of the market it is not a viable playground...
I know that actually reading the article will just slow you down, but if you'd bothered, the emphasis was on developer. The guy was talking about how quick and easy it was to develop tools for his Playstation development on a Mac. Not about playing games on a Mac.
Thanks to SDL & OpenGL the same source code is used for all four supported platforms (Linux, Win32, MacOS9, MacOSX). There's still the odd #ifdef for things like reading directories, but that's about it.
- Andreas
More significant than this though is that you have so much choice about how you develop. You could choose to use Apple's free Project Builder (called "Application Builder" in the parent post) and Interface builder. You could just use one or the other or you could use something completely different. BBEdit is very popular for editing text files - mostly HTML but is quite suitable for code as well. JBuilder is available for the Java types or you can really cut loose and go command line. My work environment is a combination of OS X, vim and ant. You could also use make, autoconf, emacs, XEmacs, gvim or heck go wild and use ed!
OS X lets you work the way you want to work. You can choose your work environment or switch between them and then you can go a step further. You can choose which API you wanted to work with. You can quite happily combine Carbon, Cocoa, the BSD layer , Java and X-Windows into the one application. That level of choice just doesn't exist anywhere else. That's before you get into things like Real Basic (VB work-a-like) and MetaCard (HyperCard work-a-like). Oh and did I mention perl? Tk? TcL? Qt?
Pretty much any Linux (or other UNIX) tool can be run on OS X and most Windows development tools lock you into using that particular tool. On Mac OS the tools work together so well that you can select the right tool not just for the application but for each part of the application. Do yourself a favour, go out and actually try development on MacOS (even if the target is for another OS) before you make up your mind about it's worth.
Sorry for the obvious plug but Crystal Space is an Open Source 3D Engine that runs fine on GNU/Linux, Windows, OS/2, BeOS, AND MacOS/X. The MacOS/X port is very alive and kicking. We also have support for OpenGL now (giving frame rates of 100 FPS or more).
Crystal Space is free (LGPL license) and written in C++. It is a 3D engine but more accuratelly it is a game development platform for 3D and isometric games.
Check it out at crystal.sourceforge.net.
Greetings,
Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
Does anybody here really cares to read the things he/she is replying to???
The topic is game development!
For that you need some tools with which you get a certain job done fast and clean - Objective-C/{NextStep,OpenStep,Cocoa} provides just that!
The problem is you're dealing with 2 completely different kinds of technologies. One is cross-platform and relatively "free", the other is held back by proprietary code (like most Apple "innovations"). Additionally, even with the new development tools, getting QuickTime to play nicely with OpenGL is a job within itself.
DirectX is no better in the proprietary code department, but at least you can setup a few function calls that will seemlessly pull together 3D graphics, video, sound and input routines that would work on a variety of PC hardware. I just wish that the "Direct-like" projects in Linux would be more ported to Windows, and that they supported more hardware-specific calls like pixel shaders.
You forgot Python, which has Obj-C bindings on Mac OS X (there are actually modules for both Cocoa and Carbon bindings so you can write first-class Mac OS X apps in Python).
The whole point to a good OS development platform is that you can use one platform to develop for ALL. The Mac "market share" BS does not apply in this discussion. If you disagree, try developing a Java or C++ app on Windows with ONLY the software provided in the retail or OEM release and get back to us. You can't. Mac OS X, as with any good *nix distro, contains a full suite of dev apps. Apple's are notable because they give you a full-featured IDE, not just the compilers.
Mac OS X contains EVERYTHING necessary to write for anything right now. And yes, its a new OS and Apple hasn't documented everything with crystal clarity, but this is the first OS I've noted with intraplatform compatibility not only at the desktop level, but the developer level as well.
/.
Vos teneo officium eram periculosus ut vos recipero is.
I'm working in the games development industry, both console development and PC -- the article is talking about a platform for _development_, not for running the final product. In a typical game development environment, you spend half your time writing tools to create content -- if you can write tools faster on OS X with Cocoa, you'll save time and money. I found this article very interesting and I've already invested in an iBook to do some homework and try out Cocoa...
The interactive way to Go -- http://www.playgo.to/iwtg/en/
you might find it interesting that Apple just (without telling anyone) released 933Mhz and 1Ghz PowerMac G4's
I thought the same thing, for a few days.. until I just bit the bullet and made myself go through the little tutorials, etc. Now I am hacking away on some low level NNTL libraries to write the news-reader of my dreams.
Cheers
Ironic that you should make this complaint on the day that Apple becomes the first computer company to sell systems with the GForce 4 graphics card. See here.
*** Quantum Mechanics: The Dreams of Which Stuff is Made ***
We recently rewrote our game tranquility, originally for SGI, to run on OS X (100% rewrite, not a port). We selected OS X over MS because of two major reasons... (1) we hate MS and (2) we love UNIX. OS X gave us the ability to completely work around a shifting (and shifty) MS playing ground... and because OS X is based on a UNIX kernel, we felt that stability and capability were superior.
We were not wrong. OS X is a blast to write games for. While our game servers are SUN (though they could be MACs)... the client internet code was written on a SUN and compiled straight away, with no errors, on the MAC. This type of simplicity and uniformaty indeed make OS X a beauty to write for.
However... we also selected OpenGL as the clients drawing system, simply because it matched the needs of the game (which was originally written in SGI GL). Apple has yet to release its version of OpenGL in source form to developers. Releasing it would help developers to support it, increase its efficiency, as well as remove a couple of the remaining problems (it IS open source, after all, but Apple has made some changes within the code). Instead, Apple seems to prefer its game developers to use its alternative (and prop. platform)... which immediatly removes porting possibilities.
Furthermore, and sadly... Apple enjoys Objective C... which quite frankly I've never been able to properly sink my teeth into. Bastardizations of a standard language such as C, into deviants such as C++ and Objective C, do nothing good for anyone. It makes porting or even rewriting difficult... and obscures readability of the code. It also wastes development time in learning a new language.
My upshot? OS X is a WONDERFUL game platform, if you ignore Apples desires and stick to the UNIX layer and standard C, as much as possible, for your designs. Specialized tools, libraries and langauge only serve to make programming more difficult.
Actually, I am a programmer. And I wrote the article without consulting with Apple. :-)
But maybe I misssed my true calling...
-TS
He actually talked about using Cocoa / OpenStep to rapidly develop a program so he could quickly and easily map the VRAM for the PSX game he was working on, instead of having to use paper and pencil. He talks about rapid application development, that leaves one with a complete program, not a hobbled together mess of copied code. He then goes on to talk about how he loaded in some of the C++ based graphics code related to the game they were using, so he could load the textures and arrange them as if his application was a PSX.
What the article is talking about is how to use OS X / cocoa to develop back end applications for game development. OS X can also run maya and lightwave, so you got 3D rendering stuff down also. One can also spend more time using OS X to get the over all look of a game finished (UI, networking, etc.) a lot faster (and cheaper) because of Cocoa, and then after finalizing the game behavior, porting it to the more expensive and timely operating systems, such as windows.
In C++, object "granularity" is at the class/interface level, rather than the method level. You would need to have an interface which defines foo:
class IFoo {
public:
virtual void foo() =0;
};
And then you can use dynamic_cast to check if an object is an instance of your interface:
IFoo* foo_impl = dynamic_cast<IFoo*>(object);
if(NULL != foo_impl) { foo_impl->foo(); }
Whether the interface-level or method-level implementation granularity is better is a matter of personal preference... I am a proponent of strong (mostly) static typing, and I like the interface way better... Usually, an interface groups several methods together to provide a set of functionality, and testing for each individual method is rather a pain... Of course, Objective-C gives you the ability to do both, so that is perhaps good. (But also, perhaps not good, as the method-level granularity is what makes Objective-C programs typically larger and slower than C++ programs).
C++ does not provide this functionality, although some libraries/frameworks provide it with varying degrees of awkwardness. C++'s lack of good reflection support, in my opinion, a major falling point. This prevents it from being a good component programming language, and this lack is what enabled Java to succeed... (I rather like Java, but if C++ had a good language-level (rather than library-level) component model, everything Java can do would already be done better by C++).
It's been replaced with HIDManager for straight OSX. InputSprocket is guaranteed only under Carbon, and the API only.
At the last WWDC, Apple strongly encouraged HIDManager to be used instead. InputSprocket allowed for nasty, low level access which should not be available. HIDManager abstracted things out much better. There was a nice response to a request for Apple to maintain a databse of HID compliant device mappings, lifting the burden of creating configuration mappings for all those Input Devices.
HID Manager
Very similar situation applies to DrawSprocket.