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.'"

72 of 218 comments (clear)

  1. The Biggest, hardest step by Anonymous Coward · · Score: 3, Insightful

    is getting all the companies writing in DirectX to start using OpenGL more often. Get some more of those damn cool PC games ported! Especially the MMORPGs!

    1. Re:The Biggest, hardest step by BitwizeGHC · · Score: 2

      They bought nonexclusive licenses to some key SGI patents related to OpenGL. Not the patents themselves. I only found this out recently; it's a relief because OpenGL is "safe".

      --
      N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
  2. Cocoa! by ciryon · · Score: 4, Interesting

    I have just started developing with Cocoa and it's really great. The "Application Builder" works flawlessly together with the "Interface Builder". It's also easy to port your *nix programs to Mac OS X. I need to take a closer look on Objective-C though, since I don't feel like using Java.

    Apple is also providing excellent documentation and tutorials.

    Ciryon

    PS. I am actually running Mac OS X on an old iMac G3 300Mhz with 64MB RAM. And it's not that slow actually!! The 10.1 update really speeds things up! Great work, Apple!

    1. Re:Cocoa! by TheAJofOZ · · Score: 4, Informative
      I have just started developing with Cocoa and it's really great. The "Application Builder" works flawlessly together with the "Interface Builder".

      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.

    2. Re:Cocoa! by tdelaney · · Score: 2, Informative

      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).

    3. Re:Cocoa! by smagoun · · Score: 2, Interesting
      You mentioned JBuilder, so I'm gonna plug the experiement I did yesterday. I have a heavily-upgraded PowerMac 7600 (pushing 6 years old) that I've installed OS X.1 on. Currently the machine is running a G4/450 accelerator. It's not exactly a speed demon, but it still manages to surprise me on occassion. I use JBuilder every day at work on a 733Mhz Pentium 3/RDRAM with a graphics accelerator. We develop under JDK 1.3, the same version that is included with OS X.

      Yesterday I decided to install JBuilder on the powermac to see if it would actually be useful. To my surprise, the JBuilder UI is actually *faster* on my powermac than it is on the Pentium - noticeably so. This is running at the same resolution (1024x768), same bit depth (24-bit) and with anti-aliased fonts in the editor on the powermac. This was using the 'metal' look and feel; the Aqua-native look and feel was, regrettably, slow. Even so, I was pretty amazed. Compiles are slower on the powermac, which didn't surprise me that much, considering the Powermac's high-speed bus (50Mhz, woohoo) and slower disk.

      I'm going to be gunning for a new DP Powermac for work. If an upgraded 6 year old machine can keep up with last year's Pentiums, I can't wait to see a DP G4 with fast disks....

    4. Re:Cocoa! by Toraz+Chryx · · Score: 2, Informative

      you might find it interesting that Apple just (without telling anyone) released 933Mhz and 1Ghz PowerMac G4's

    5. Re:Cocoa! by foobar104 · · Score: 2

      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.

      Almost. The one big thing that I've found OS X to be lacking is the dlopen()/dlsym() API for dynamic loading of shared objects. This certainly won't be a big deal for most people, but it's made it a litle harder for me to port some of my existing code to OS X.

  3. Re:Not likely by dair · · Score: 3, Insightful

    The article is talking about internal tools though - not the final shipping product, but all the little pre-production tools that get written along the way.

    Since most of these are written on a pretty ad-hoc basis without any real design, a RAD approach does make a lot of sense.

    -dair

  4. Re:Not likely by tbien · · Score: 3, Informative

    Sorry, but maybe you should read the article before you comment it. The article talks about tools for games development, not the games themselves.

  5. Re:Not likely by scrutty · · Score: 3, Informative
    Limit your platform !?
    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
  6. Re:Mac OS X may be... by boaworm · · Score: 2

    We all have to start somewhere. If the Macintosh can provide a good solid ground for rapid (cheap) game development, as well as a good platform for the gamers to play, then why not ?
    The machines does look a lot better than most common PC's, they have nice keyboards and mice etc. And MacOS X is a *nix, which does bring things to its edge, since all slashdotters loves *nix :-)
    If there were as many good games available for the Macintosh as for the PC, i'd definitly concider getting myself a Mac next time. I think its worth those 50 % extra money to get rid of windows once and for all anyways =)

    --
    Probable impossibilities are to be preferred to improbable possibilities.
    Aristotele
  7. Re:Mac OS X may be... by jgerman · · Score: 4, Insightful

    You have to realize that the box you do your developement on and the target box for the game need not be the same architecture. Many stages of developement can be done on one machine and cross-compiled to the other. I haven't tried it yet, (probably never will because I really don't have the desire to write for windows), but it would be relatively easy to set up a developement environment in Linux that builds an executable for Windows, and to launch the program for testing over a Samba share on the Windows side. So doing the same from a Mac to Windows shouldn't be that difficult.

    --
    I'm the big fish in the big pond bitch.
  8. Re:Mac OS X may be... by Wonderkid · · Score: 3, Interesting

    ...yes but if more people write great apps for MaxOS, then more people will buy Macs. And the new cool iMac is a great gaming platform. Something few comment on is that it's built in wireless networking (airport) mean you could play multi-player games via 802.11. (Assuming it is supported in the games of course.) It is these 'vertical market' applications that can transform a platform.

    --

    O'WONDERWe're working on it.

  9. Alternate URL for article by sanguish · · Score: 5, Informative

    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 Anguish
    Stepwise
    http://www.stepwise.com
  10. Re:Mac OS X may be... by night_flyer · · Score: 2

    We all have to start somewhere.

    The primary purpose a game is produced, is to ::gasp:: make money. with < 4% of machines being Macs, a smaller % running OS X and a smaller % yet of those machines being used by gamers, there isnt enough money to let programmers/producers/distributors/resellers put any in their pocket.

    --


    Thanks to file sharing, I purchase more CDs
    Thanks to the RIAA, I buy them used...
  11. Re:Not likely by Anonymous Coward · · Score: 2, Informative

    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

  12. Re:Mac OS X may be... by Stormie · · Score: 5, Informative

    ...a Game Developer's Playground
    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.

  13. Re:Mac OS X may be... by TheAJofOZ · · Score: 2
    you could play multi-player games via 802.11. (Assuming it is supported in the games of course.)

    Just to clarify (or correct depending on what was actually meant) - Airport is integrated into Mac OS the same way the modem or ethernet is so the game only has to support network play, not specifically airport.

    One other correction from this thread (but not the parent post), Mac's have about 5% market share not 4% - hence the Steve Jobs quote: "5 down, 95 to go". Also, 5% market share is a *huge* number of computers. There are more people who use Macs than people who buy Proserpine Cane Growers Suger but I assure you the Proserpine Cane Growers are making plenty of money. You don't need to target Windows to make money in the computing world - you just need to target an audience.

  14. Cross-compiling by andi75 · · Score: 2, Informative
    I build the win32 binaries for my (GPL'd 3D tron style lightcycle) game on linux. It's really just a matter of running the 'cross-configure.sh' and 'cross-make.sh' script. Ray Kelm has an excellent page on cross-compiling.

    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

  15. Re:Not likely by sconest · · Score: 2

    It is DoomEd.
    See here

    --
    Guvf vf abg n EBG zrffntr
  16. Re:Mac OS X may be... by Chainsaw · · Score: 3, Insightful

    It might be easier to make money in the Mac market. Almost all PC games are available via warez channels seconds after official release. Mac games are very hard to find, which makes you buy games more often since it's not worth the time searching for something you want.

    --
    War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
  17. C++ vs. Objective C by seletz · · Score: 2, Interesting

    Well,
    at first I'd like to say that I'm a regular OS X 1.2 user (on a TI PB, that is) and
    I like OS X quite much, and I make a living of coding (C and C++ mostly, Linux and other *nixes).

    I tried to get used of Objective C, but i find it quite cumbersome to use,
    and that's why I don't see this happen soon. To get the most
    out of Carbon/Cocoa you'll have to use Objective C. That's the
    reason why I never got to use it (mostly due to lack of time),
    because I'd first have to learn Objective C.

    I think this happens to other developers too (read: game developers).

    Just my $0.02 anyway...

    1. Re:C++ vs. Objective C by Pengo · · Score: 3, Informative


      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. :) It's very nice once you get used to it, and if you take the time to actually get used to it.. it will probably make you a better programmer in any language you chose to code in.

      Cheers

    2. Re:C++ vs. Objective C by Art+Tatum · · Score: 2
      That's why it never succeeded (well, that and the fact that the original runtime was slow--but that's gone now). But it really is a cool language and OpenStep (err, Cocoa) is the coolest API ever. Plus, with the GNUstep project, you can compile your Cocoa applications on most UNICES and someday, even Windows and BeOS (if someone writes a GUI backend for them--you can compile non-graphical tools with it now).

      Check it out!

  18. Re:Mac OS X may be... by Zenin · · Score: 4, Insightful

    The article is mostly talking about building games, and the ability to create the tools to do so.

    That said, think about the market for the "highend" gamers. You know...the %4 of us that actually buy a GeForce 3 when they first come out? Many such gamers would love to move off of Windows, especially the 98 variants. While Win2k helps a lot, in the end it's still Windows. Many are pushing for Linux to be the next great gaming OS, so much so that more then a few major game companies have already targeted it (even if not completely successful, ala Loki). Linux however, has a long, long way to go (to be very, very kind).

    If all the "hot new games" start coming out for Mac (even if they also come out for Windows and/or Linux), it suddenly makes Mac an extremely attractive system for gamers. Gamers of course, being the only people who own a computer that are likely to actually buy a new one before 2030...

    Now, if building games on Mac is easier, faster, and thus results in better games to market sooner...

    If building a game under Mac implies open standards such as OpenGL instead of DirectX, thus enabling the game to target Mac, Windows, Linux, etc without nearly so much trouble...

    The math becomes easy. Develop under Windows and we sell to say, 90% of the market. Develop our game under Mac and we sell to 100% of the market (5% Mac lets say another %5 Linux/Other)...AND we get to market faster AND our development is cheaper... The choice is clear, IMHO.

    --
    My /. uid is better then your /. uid
  19. Re:This is not true by TheAJofOZ · · Score: 2
    Most development, are made just filling in already made game-templates.

    Most of the time in your life when you want something done you pay someone else to do it. However, the fact still remains that *someone* has to actually do it or it won't get done. It doesn't matter that a lot of games are made by using licenced game engines, someone has to create the game engine and Mac OS X will be very useful for that.

  20. Crystal Space 3D Engine by Jorrit · · Score: 4, Informative

    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
    1. Re:Crystal Space 3D Engine by Jorrit · · Score: 2

      Then I recommend you try again. If you look at the Crystal Space site then you can see the MacOS/X port got a MAJOR update on 14-Jan-2002. There is a big news item on this.

      Greetings,

      --
      Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
  21. Objective C by Greyfox · · Score: 3, Interesting
    I looked at Objective C a few years back and found it delivered a lot of the dynamic goodies that object oriented programming was supposed to deliver but which C++ at the time was incapable of. Ultimately though, no one was using it at the time and indeed many of the linux tools for the language have fallen into disrepair.

    It was a spiffy little language but these days you can do most of the same things with C++ using templates and the STL, and the C++ code will be much more type safe at compile time.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    1. Re:Objective C by bnenning · · Score: 2
      It was a spiffy little language but these days you can do most of the same things with C++ using templates and the STL


      Are there C++ equivalents for these common Objective C/Cocoa uses?


      - if ([object respondsToSelector:@selector(foo)]) [object foo];

      (Determines if object responds to the "foo" method, and invokes it if so)

      - id newObject = [[NSClassFromString(someString) alloc] init];

      (Allocates an object of the class named in the someString variable)


      Last I checked C++ had nowhere near this level of dynamic capability, but please correct me if I'm wrong.

      --
      How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
    2. Re:Objective C by dustman · · Score: 3, Informative

      Are there C++ equivalents for these common Objective C/Cocoa uses?
      - if ([object respondsToSelector:@selector(foo)]) [object foo];
      (Determines if object responds to the "foo" method, and invokes it if so)

      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).

      - id newObject = [[NSClassFromString(someString) alloc] init];
      (Allocates an object of the class named in the someString variable)

      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++).
    3. Re:Objective C by jcr · · Score: 2

      It was a spiffy little language but these days you can do most of the same things with C++ using templates and the STL, and the C++ code will be much more type safe at compile time.

      I beg to differ.

      Please have a look at NSUndoManager, in particular, "Invocation-based Undo", and tell us how you'd implement the undo functionality in C++.

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
  22. Re:Potential by TheAJofOZ · · Score: 4, Insightful
    Market share is redundant (the moderators were right), the Mac is used to create tools to aid the development of the game. The target platform may or may not be a Mac. For creating little utilities quickly it is extremely hard to beat Cocoa. To give you an indication you can create a text editor with support for formatting (bold, italic, underline, different fonts, etc, etc, etc) *and* images (added to the document via drag and drop) in less than 30 lines of code and about half an hour (files save out to rtf). Oh, and that includes an as-you-type spell checker.

    You used to develop applications quickly in VB, now Cocoa has gone above and beyond, letting you build *good* applications quickly.

  23. Re:Mac OS X may be... by tbien · · Score: 2, Informative

    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!

  24. OpenGL and QuickTime by SilentChris · · Score: 4, Informative
    "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"

    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.

    1. Re:OpenGL and QuickTime by Refrag · · Score: 3, Informative

      Ummmm... QuickTime is the new standard file format for MPEG4. How is that proprietary?

      Oh, you must have been talking about one of QuickTime's codecs. Remember QuickTime is much more than a codec.

      --
      I have a website. It's about Macs.
    2. Re:OpenGL and QuickTime by foobar104 · · Score: 2

      Given the context of the conversation, he was most likely talking about the Quicktime API which is proprietary.

      Maybe you're confused. The API is fully documented.

    3. Re:OpenGL and QuickTime by SilentChris · · Score: 2
      "QuickTime is the new standard file format for MPEG4"

      Other way around. MPEG4 is (supposed) to be the new standard file format for QuickTime. How long that will take (people are still using RealAudio and Windows Media standards from 3 years ago) is anyone's guess.

      I was referring to the API which, while documented, is not "open". If you went with the comment one person made, the Windows APIs would all be "open" because they're documented. That's not "open" in the traditional Source/Slashdot sense.

      I don't absolutely require open code (heck, I think DirectX is pretty nifty for some of the things it does) but if you're trying to link Apple, OpenGL, QuickTime and "open source", you're mistaken.

    4. Re:OpenGL and QuickTime by Refrag · · Score: 2

      "MPEG4 is (supposed) to be the new standard file format for QuickTime. How long that will take (people are still using RealAudio and Windows Media standards from 3 years ago) is anyone's guess."

      Other way around. QuickTime's file format is what MPEG4's file format is based on. Google's #1 result

      --
      I have a website. It's about Macs.
    5. Re:OpenGL and QuickTime by bryan1945 · · Score: 2

      Actually, I think the QT server software is open sourced, though I forget under which license. I'm pretty sure that it was mentioned in a previous QT article, but the work day is ending so I'm going home rather than search for it.

      I know this still leaves the QT player and various codecs as proprietary, but wouldn't a developer be more interested in the server side?

      --
      Vote monkeys into Congress. They are cheaper and more trustworthy.
  25. Re:Mac OS X may be... by Spencerian · · Score: 3, Informative

    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.
  26. Re:Mac OS X may be... by smagoun · · Score: 2, Insightful

    I agree 100%. In other news, TBL didn't use the NeXT platform to develop the WWW because NeXT had virtually no market share, and everyone's favorite game, DOOM, also wasn't developed on the NeXT because it had virtually no market share. I will be updating the history books accordingly.

    </sarcasm>

  27. No, YOU missed the point... by igomaniac · · Score: 2, Informative
    Please read the article before posting next time! He's talking about PlayStation development, not Mac, not PC!


    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/
  28. Re:It's sad then... by k_187 · · Score: 3, Insightful

    Yes, but the only people that care about upgradable video cards are YOU PEOPLE! The people that would buy the iMac are not the kind that sit and fret over what kind of video card they have, and what their FPS is in Quake 8. I know its been said before around here, but the iMac is not designed for you, the iMac is designed for people who want to check their e-mail, surf the web, play their MP3s, print their digital photos, (insert iApp here); all on a box that don't look like the big beige monster took a crap on their desk. (/Rant)

    OK, glad I got that out of my system. Personally, I think OS X is the best thing since sliced bread (and maybe even cheese in a can!). The implementation of OpenGL is 3x what it is in Classic Mac OS. My Quake 2 (yes I'm a purist) framerates jumped 20 FPS just from switching to OS X. 60+ FPS on a 3 year old system on your Rage 128 makes me a happy little camper.

    --
    11 was a racehorse
    12 was 12
    1111 Race
    12112
  29. Good for Tool Chain, not the game its self... by LordZardoz · · Score: 3, Interesting

    It seems that few of you read the article its self. The article suggests that Cocoa is ideal for designing custom tools since it is easier to make iterative changes to the tool. It is not saying that it is the best target platform to develop games for.

    Mac's are also a good possiblity for console development (PS2, Gamecube). Especially since the compiler used is frequently based on GCC. OS-X's BSD core makes it easy enough to port the tools, and provides another alternative for those who are not intrested in using Linux or Cygwin based tools. However, since most of the art tools are used on NT/W2k boxes (Such as 3ds Max), it is probably simpler for the time being to stick to Windows based environments.

    END COMMUNICATION

    1. Re:Good for Tool Chain, not the game its self... by jcr · · Score: 2

      I think the guys at OmniGroup would disagree. They saved about 10K lines of code in one of their ports by using Cocoa. See www.omnigroup.com/games

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
  30. Is This Really News? by Lethyos · · Score: 2

    This is just the next logical step in form of a set of more powerful technologies (some of which have been around for a while... QuickTime is traditionally solid). The Macintosh has always been a terrific game development platform (well, except in the really early days when it only had black and white ;). The software and the hardware are remarkably consistent and homogenous respectively. How could develops expect MacOS X to be any different? Developing games for the Mac is almost as smooth as developing games for a console.

    --
    Why bother.
  31. What about MS purchase of OpenGL from SGI? by swb · · Score: 2

    I'll admit I didn't read more than the Slashdot headlines, but didn't MS just buy a bunch of OpenGL stuff from SGI?

    If they decide not to license or to restrict the use of the technology, wouldn't that begin to cripple the use of OpenGL as a development environment?

    I can't believe they would, but then again this IS MS we're talking about.

  32. Bloody marketing by mrfiddlehead · · Score: 2

    Am I the only one who thinks this particular quote stinks of AppleSpeak? You know it wasn't written by a programmer if they use the term empower. I'll leave the details of the analysis of this particular platform to a game programmer and stick to fiddling with the linux kernel for now, thanks very much (a platform which is also supported on apple hardware <w>).

    --
    :wq
    1. Re:Bloody marketing by CousinChimpy · · Score: 2, Informative

      Actually, I am a programmer. And I wrote the article without consulting with Apple.
      But maybe I misssed my true calling... :-)
      -TS

  33. Re:It's sad then... by Refrag · · Score: 2

    You know, Apple does make towers. And Mac users got the GeForce3 at least one day before the x86 crowd.

    Quit complaining about problems with Apple's product line that DON'T EXIST.

    --
    I have a website. It's about Macs.
  34. Re:Mac OS X may be... by Refrag · · Score: 2

    I believe (and he can correct me if I am wrong) that John Carmack developed Quake on a NeXT system. Mac OS X is essentially NeXT, so I see no reason for you to slight it as a development platform based on Quake's extensive success. Grame Devine (also of id Software) also uses a Mac for all of his work.

    --
    I have a website. It's about Macs.
  35. Re:It's sad then... by glenmark · · Score: 2, Informative
    ...that Apple can't be bothered to put decent video cards in most of their machines.

    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 ***
  36. OS X and Games by MrIcee · · Score: 4, Informative
    While I agree that OS X is a great new platform,and indeed, a great gameing platform, There are a couple of caveats I'd point out in reference to the article.

    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.

    1. Re:OS X and Games by bnenning · · Score: 3, Informative
      Bastardizations of a standard language such as C, into deviants such as C++ and Objective C, do nothing good for anyone.


      You might want to give Objective C another chance in the future. Unlike C++, Objective C is a 100% backwards compatible OO extension to C. The OpenStep/Cocoa APIs are specifically designed to use the features of Objective C and are outstanding for most types of application development, although possibly not for action-oriented games.

      --
      How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
    2. Re:OS X and Games by bnenning · · Score: 2
      Thus... anything C++ can do, C can do. Thus... the ONLY reason to use C++ is that (A) your boss can read it (???) or (B) your a lousy programmer.


      That's just silly. By Turing equivalence, just about any language can do anything that any other language can do. You could write scientific number-crunching apps in Perl and text processing utilities in FORTRAN, but it would be foolish to do so. Part of being a good developer is choosing the right tools so that you can spend your time implementing your program's functionality instead of fighting with the language.

      --
      How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
  37. You obviously don't earn a living coding... by alexhmit01 · · Score: 3, Insightful

    If computer costs really factor into your decision, you don't make a living coding.

    My PC environment was easily over 5K when including a laptop (bought 3 months used to save $800 off the costs), a docking station at home and the office, Win2K, Off2K Pro, Visio Enterprise Edition, Text Editors that don't suck, etc.

    We may switch the office over to Macs. The OS X experiment was promissing, but the platform isn't there yet. 6 Months? Hell yeah. We do PHP/Java development. The cost of the Windows machines don't even account for the hardware to have a Unix development environment to actually work in.

    Alex

    1. Re:You obviously don't earn a living coding... by alexhmit01 · · Score: 2

      We're talking about real development environments. Most development (including open source work) is done at work. People work on projects that their company needs. Sure, there are lots of hackers that bang out unfinished code on source forge at home, but the real work on the Linux kernel, Apache, PHP, etc., is done as part of commercial endeavors. The interesting thing is that instead of building internal tools and keeping them to yourself, you share with others and work together to build the glue you need.

      If the new development machine will save 80 hours over 2 years, you're a fool if you don't drop $3000 on a new computer.

      Most people purchasing computers aren't in the "no money," give me "free or death" crowd that frequents Slashdot. All of us were hobbyists that had a $400/year computer budget. If you start making a living with your computer, you spend the money on the tools you need to make a living and be competitive.

      Spending 8 hours playing with sound drivers on a Linux system (which I've done) is suicide in a work environment. I already ate any savings that we got by going with Linux as opposed to OS X. That's my point.

      Once your time has value, Linux on unsupported hardware isn't a bargain anymore.

      Alex

  38. Re:Mac OS X may be... by RevAaron · · Score: 2

    Quake and Doom were developed under NeXTSTEP. Carmack loves NeXT as a platform for both the end user as well as the developer. He's made various statements in his .plans throughout the ages and still dedicates his love to NeXTSTEP, OpenStep, Rhapsody and Mac OS X.

    --

    Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  39. What article did you read? by Pfhor · · Score: 3, Informative

    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.

  40. If Carmack likes it, so should you! by RevAaron · · Score: 2
    Carmack was a huge NeXT fiend. Quake and Doom were developed under NeXTSTEP, and the only reason (that he cites) he switched to NT was that it became kind of an necessity, with there not being many OpenGL-accelerated cards that worked under *STEP.

    Here you will find this lovely quote:

    If I can convince apple to do a good hardware accelerated OpenGL in rhapsody, I would be very likely to give my win NT machine the cold shoulder and do future development on rhapsody.

    More Carmack-style old pro-OS X ranting can be found here. There's a lot more around, but I gotta run. Google reveals all.

    --

    Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
  41. Re:It's better than PSX, but that's no big whoop by frankie · · Score: 5, Insightful

    You need to read the article again; that's not at all what he's talking about.

    The author described a particular problem he had while developing a PSX game -- mapping the limited VRAM was a pain. So he wanted to write an automated graphical utility to do it for him. Using OpenStep (aka Cocoa) it took about 2 days and saved his entire team man-months of tedious labor.

    This wasn't about porting some random PSX game to Macs. It was about using the language at the heart of OS X to be more productive at whatever it is you're doing. As you recall, productivity was one of the main reasons for the computer revolution (along with communication and porn, but you get the idea).

  42. Re:No fscking way by overunderunderdone · · Score: 2

    How much Cocoa/Objective C/InterfaceBuilder development have you done?

    This is not a wise-ass question. I want to know which is easier/better but want to hear the opinions of people that have used both - not just people that having used one *imagine* that it is easier than the other.

  43. Read the article. by CousinChimpy · · Score: 3, Interesting
    As several people who went to the radical extreme of actually reading the article have pointed out ... ;-) ... it's about developing and using internal game production tools on MacOSX, not about developing games for OSX (though that would certainly be nice too). (Case in point: The context of the article was a production tool I developed while working on a PlayStation game. Console development isn't done using consoles alone!)

    The article is not a testimonial about OpenGL performance on the Mac, nor is it a crisicism of OpenGL performance on the Mac. :-) Neither is it an endorsement of Objective-C as the best language in which to write a performance-critical game engine. (For that purpose I would personally choose either a tight subset of C++ or an OO approach to structuring C code.)

    The article is about the production process, and developing tools to aid in that process -- a domain in which I can say from experience that developer productivity is far more of a priority than getting every last drop of execution speed -- particularly if you can develop tools that will make a process more efficient for several artists/programmers: the efficiency of the development process then goes up in proportion to the number of people on the team who benefit. That's where Cocoa provides much needed leverage. Objective-C contributes to the efficiency of the development environment by being an appropriately flexible OO language for RAD. IMHO, as the article states & illustrates, it's very appropriate technology for the domain of custom application development. :-)

    CousinChimpy
    (Troy Stephens)

  44. What happened to InputSprockets? by oberon656 · · Score: 2, Insightful

    If Apple would *really* like to woo game developers, they should bring Input/GameSprockets to OS X. QuickTime and OpenGL are nice, but using a mouse/keyboard for game input is jsut plain unacceptable to most gamers.

    How will I get my Money Puzzle Exchanger fix?!?!

    --
    - Brad Carps Just Another Mac Perl Hacker #!/usr/bin/l33t
    1. Re:What happened to InputSprockets? by inah · · Score: 2, Informative

      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.

  45. Re:Great News by MadCamel · · Score: 2

    Oh of course. But porting a DirectX game is damn well near impossible, wheras porting an OpenGL game is much easier, so anything that moves game developers away from DirectX is fine by me.

  46. Re:Only if Apple gets their ass in gear. by Spankophile · · Score: 2

    Why is this flamebait? Apple's claim to fame is changing their direction to stay "cool". They do this with their hardware and their software.

    OS X/Carbon etc is a total departure from their old APIs and OS. How can developers trust that OS Y won't wreck everything you just learned about Macs on OSX?

  47. Re:Only if Apple gets their ass in gear. by bnenning · · Score: 2
    OS X/Carbon etc is a total departure from their old APIs and OS.


    Umm, no. The entire point of Carbon is to provide most of the "Classic" Mac OS API so that developers have an easier transition to OS X.

    --
    How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
  48. What a mess by Ars-Fartsica · · Score: 2
    You can quite happily combine Carbon, Cocoa, the BSD layer , Java and X-Windows into the one application.

    You talk about that like its a good thing.

    1. Re:What a mess by TheAJofOZ · · Score: 2
      You talk about that like its a good thing.

      It is as long as you understand the concepts of code modularity. One application does not have to be made up of one monolithic hunk of code. Component based design allows you to easily write each component in the language that is most suitable for it, rather than having to decide on the basis of the whole application.

      Not only that, but it increases the ability to reuse code as it doesn't matter if the code is in a different language it can still be plugged into the current project as another component.