Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Apple Businesses

Mac OS X: Game Developer's Playground 218

Posted by michael from the click-and-drag dept.
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.'"
This discussion has been archived. No new comments can be posted.

Mac OS X: Game Developer's Playground More

Mac OS X: Game Developer's Playground

Comments Filter:

  • The Biggest, hardest step (Score:3, Insightful)

    by Anonymous Coward on Monday January 28, 2002 @06:47AM (#2912873)
    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!
    • DirectX is much more than a graphics lib: it's also useful for things like having a standard way of accepting input, which OpenGL (being, of course, graphics-oriented) doesn't handle. And then there's sound output. These are all things that Microsoft has done to ease writing games and apps for win32. OpenGL ... is only for graphics.

      SDL on win32 is a wrapper for DirectX. How would you get developers, who target only win32 systems, to potentially lower performance of their games by inserting a(nother) wrapper layer over the already complex system?

  • Cocoa! (Score:4, Interesting)

    by ciryon ( 218518 ) on Monday January 28, 2002 @06:52AM (#2912883) Journal
    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!

    • Re:Cocoa! (Score:4, Informative)

      by TheAJofOZ ( 215260 ) <adrian@nOSPaM.symphonious.net> on Monday January 28, 2002 @07:43AM (#2912979) Homepage Journal
      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.

      • Re:Cocoa! (Score:2, Informative)

        by tdelaney ( 458893 )
        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).

      • Re:Cocoa! (Score:2, Interesting)

        by smagoun ( 546733 )
        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....

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

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

    • Objective C (Score:3, Interesting)

      by Greyfox ( 87712 )
      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.

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

        • Re:Objective C (Score:3, Informative)

          by dustman ( 34626 )

          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++).
      • Comment removed based on user account deletion

  • Alternate URL for article (Score:5, Informative)

    by sanguish ( 130391 ) on Monday January 28, 2002 @07:08AM (#2912914) Homepage

    To protect my pathetic bandwidth on the local server, the article is also available here [stepwise.com] 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 [stepwise.com]
  • This is great news. Games written for osX will use OpenGL instead of DirectX, this means that porting them to other operating systems won't be such a chore. With the demise of Loki, it's nice to see somthing positive on the Linux/BSD gaming frontier.

  • C++ vs. Objective C (Score:2, Interesting)

    by seletz ( 192331 )
    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...

    • If you know C it only a matter of hours to understand Objective-C.

      It's just a nice and small extension to normal C with only one syntax extension - the way to send a message to an object [object doSomething].

      That's nearly all....

    • Re:C++ vs. Objective C (Score:3, Informative)

      by Pengo ( 28814 )

      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
    • 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! [gnustep.org]

  • Crystal Space 3D Engine (Score:4, Informative)

    by Jorrit ( 19549 ) on Monday January 28, 2002 @07:53AM (#2913004) Homepage
    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 [sourceforge.net].

    Greetings,

  • OpenGL and QuickTime (Score:4, Informative)

    by SilentChris ( 452960 ) on Monday January 28, 2002 @08:22AM (#2913071) Homepage
    "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.

    • OpenGL is OpenGL. QuickTime is QuickTime. And DirectX tries to be everything at once.

      I'm getting quite tired of this "Macs have fewer games" bull. Many PC game players and makers may not realize it, but Mac game players use PC game players as their "beta testers.' There are LOTS of PC games because its TOO easy to develop a game. Just because there's a ton of copies of a game doesn't mean it's a good game. A threshold of sales there has to be made. When that threshold is reached, a Mac port is usually considered.

      The best games from the PC are ALMOST ALWAYS ported to the Mac side. With a few notable exceptions (Half Life, Tribes) I play Diablo 2, Deus Ex, The Sims, the Tomb Raider series and many more titles. Portability is not the problem when you isolate the DirectX features to help the Windows port while using Apple's game support and any QuickTime feature for the Mac, and other resources in the *nix port. At the same time, using common platform tools such as OpenGL help. DirectX is not a panacea--if a developer knows nothing but it, then his games are going to suffer. A ton of PC games that sit in the bargain basket at CompUSA proves my point every day it stays there.

      And yes--I could make a PC game from my Mac using a simple IDE such as REALbasic, which works much like VB. Porting from that IDE is child's play because you develop for both platforms simultaneously.
    • 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.
      • didn't MS just buy a bunch of OpenGL stuff from SGI?

        No, they bamboozeled SGI by getting them to build NT boxes and during the romance, got SGI to disclose the OpenGL family jewels. Just like how the M$/Sega relationship begat Xbox while tanking Dreamcast, the M$/SGI relationship begat DirectX3D and a castrated SGI (and the M$ president's spot for R. Belluzo as a reward for a job well done).

        Microsoft...masters of the we-win, you-lose "relationship".

    • Re:OpenGL and QuickTime (Score:3, Informative)

      by Refrag ( 145266 )
      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.
      • "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.

        • "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 [apple.com]
    • 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?

  • Good Point (Score:1, Interesting)

    by Anonymous Coward
    The more I use OS X, the more I like it, even though my exposure to it is rather limited.

    The point of this article really is that you should use the tools you feel comfortable with to do the job. All you people who are saying stuff about the mac not having enough market share to justify it obviously haven't read the article.

    Being a person who likes low-level stuff, I rather hate using API's and stuff that make all this stuff easy. I prefer to write my own loaders, blitters and stuff... I've developed my own game tool library over the years and use it for all sorts of things because it's what i'm most comfortable with and can get things done more quickly.

    But I feel my view is similar to that of many other game developers (ones who are truly passionate about it) and we are a stubborn bunch (is this just coders in general?) and once set in our ways, tend not change them, even if another way is better.

    Sadly, in my view, game development is less of an art and more of a process now. Remember the days of DOS where you had direct access to the hardware and wrote your own graphics, input and sound routines? You really couldn't use a 3rd party library because it would conflict with your code or other libraries. Besides, that was just a lame thing to do.

    Anyways, less chat, less shovelware, more coding, more polishing.
  • What's the difference between Cocoa and Carbon? I got incredibly ticked off at my PC and sold it and went ahead and purchased the new iMac. I have every intention of programming on it and have mainly a Java background but can do C/++ if needed. Hopefully my iMac will get here soon...
    • A Carbon application uses a revised set of the Mac Toolbox, the original APIs of Mac OS 9 and prior. These APIs are generally designed to allow porting of existing Mac OS 9 apps to Mac OS X to take advantage of Mac OS X's stability, memory protection and other things. You can make Carbon apps so that a single version of an app works on either Mac OS 9 and X.

      A Cocoa app works much like a Carbon app except development for these apps use Objective C, C++, or Java. The advantage of a Cocoa app is that you can port this code to other platforms, and it gains some feature advantages in OS X that Carbon apps do not yet receive. Cocoa apps can only operate in Mac OS X.

      A true developer here can probably explain more of the particulars that I can, but that's the nutshell.
      /.

  • Neat article, but the conclusion is badly flawed. The main thrust seems to be "Cocoa/OpenGL doesn't require you to map out your VRAM like Playstation 1 did, so that makes it easy to write games!"

    Does it hell. It removes one obstacle, but it's not going to write the game for you, nor is it going to make the Mac a more attractive proposition - technically or as a market - than DirectX, either XBox or generic PC Windoze versions. Hobbyists take note, but commercial developers, don't get too excited.

    OpenGL is a fine API, and I'll happily accept that Cocoa is nice too, but the whole DirectX SDK really has matured into something usable. Many AAA Windows games now ship with only D3D (no OpenGL) 3D support (Max Payne, Operation:Flashpoint spring immediately to mind) and it doesn't hurt them. The big downside to using DirectX is cross platform portability (porting the app, and the DirectPlay network component), but commercialism comes into play again: it's better for a game to work really well under DirectX only than to work fairly well under DirectX and on Macs (or Linux for that matter).

    If this means anything to anyone, I used to work for a company that was writing native D3D Retained Mode games, back in the DirectX 3/5 days. It was a suicidally stupid thing to do, and the games side of that company did indeed collapse under the weight of ripping the thing apart and starting over with D3DIM / OpenGL / glide support. I've no historical reason to love DirectX, or to think that apps hardwired to a specific API are a good idea. But even given that, I still think that a native DirectX 8 game makes a lot more sense, both technically and commercially, than OpenGL/Cocoa on a Mac platform.

    Sorry guys, but this reads like another "I love Macs, so here comes the cognitive dissonance," article designed to get people on board the Macwagon. The only thing I can completely agree with is that developing for the Playstation 1 was like trying to teach a chimp to recite Shakespeare translated into Latin.

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

    • Re:It's better than PSX, but that's no big whoop (Score:5, Insightful)

      by frankie ( 91710 ) on Monday January 28, 2002 @10:47AM (#2913671) Journal
      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).

  • Good for Tool Chain, not the game its self... (Score:3, Interesting)

    by LordZardoz ( 155141 ) on Monday January 28, 2002 @08:49AM (#2913160)
    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
  • 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.
  • 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>).

  • OS X and Games (Score:4, Informative)

    by MrIcee ( 550834 ) on Monday January 28, 2002 @10:07AM (#2913459) Homepage
    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 [tqworld.com], 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.

    • Re:OS X and Games (Score:1, Insightful)

      by Anonymous Coward
      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.

      Hey, fogey, if we took this reasoning to its logical conclusion, we'd still be writing machine code by hand. Not assembler, mind you, machine code.

    • Re:OS X and Games (Score:3, Informative)

      by bnenning ( 58349 )
      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.

  • 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 [bluesnews.com] 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 [macgamer.com]. There's a lot more around, but I gotta run. Google reveals all.

  • Misconceptions (Score:1, Insightful)

    by Anonymous Coward
    Sadly I must say I beleive most people posting here have not understood anything about the article. The article is not about making games for MacOSX but making the tools to make the games. Like map editors, texture encoders, character editors and other authoring... And also tools to manage the actual flow of development or help with managing ressources. The PlayStation VRAM map tool is exactly that. think of it as tool to help the team manage the VRAM on the playstation.

    That doesn't mean the game is on OS X, just that OSX is nice to build support tools for game development.

    It shouldn't come as a surprise. I remember Id made a map editor on NeXTSTEP a while back in the Doom days if I remember well... anyway... NeXTSTEP is one of the ancestors to OS X.

    I must say prototyping is indeed much much faster on OS X. And I don't feel like I am a super pro in it yet. It pays to develop the concept on OSX before developing the actual app on whatever platform you need it on.

  • Read the article. (Score:3, Interesting)

    by CousinChimpy ( 227257 ) on Monday January 28, 2002 @11:17AM (#2913889) Homepage
    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)

  • 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?!?!

    • 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 [apple.com]

      Very similar situation applies to DrawSprocket.

Slashdot Top Deals

"Tell the truth and run." -- Yugoslav proverb

Close