iDevGames

Introduction

The recent release of version 18.001 of Crystal Space, the Open Source 3D game toolkit, may be of interest to Macintosh developers. This is the first release which natively supports Apple’s new Cocoa technology introduced in Mac OS X. As the creator and maintainer of the Mac OS X, Mac OS X Server 1.0 (Rhapsody), OpenStep, NextStep, and BeOS ports of Crystal Space, I hope to provide readers with the inside scoop on the status of Crystal Space as it relates to the Macintosh platform.

If you have any questions, comments, criticisms, or would simply like to discuss Crystal Space and/or Mac OS X, please feel free to contact me.

Clarifications

There are two completely distinct ports of Crystal Space for Macintosh.

Classic (Macintosh Toolbox)

The first port is based on the Classic Macintosh Toolbox. This port has not been Carbonized, which means that it may work with Macintosh OS 9 but is incompatible with Mac OS X. Another problem with this port is that it has seen almost no maintenance in the last year (or more) and is consequently incomplete and unstable. Unfortunately, the maintainers of this port have had very little time, recently, to devote to Crystal Space. As a consequence, it is common for several months to elapse between updates to this port. A final issue is that this port does not necessarily keep up with CodeWarrior revisions, and there have been reports of problems compiling Crystal Space with newer versions of CodeWarrior. (However, see “ate Breaking News” below.)

Cocoa

The second port is based on Apple’s brand new Cocoa technology which was inherited from NeXT and which is new in Mac OS X. This is a pure-Cocoa port. Therefore it is suitable for Mac OS X, but not for earlier Macintosh releases. This port is, in fact, the same port which runs on Mac OS X Server 1.0 (Rhapsody), OpenStep, and NextStep. I am extremely active with Crystal Space and, as a consequence, this port tends to be very well maintained.

Documentation

The Cocoa-based port of Crystal Space is fairly well documented. People interested in building and using Crystal Space on Macintosh are encouraged to read section 2.4.4 of the Crystal Space User’s Manual. People interested in actually improving or augmented the Cocoa-based port (or even people interested in the nitty-gritty details) are encouraged to read section 8.1.1 which contains an in-depth technical discussion of the Cocoa-based port.

The online documentation can be accessed on-line at:

http://www.crystalspace3d.org/tikiwiki/tiki-index.php?page=Documentation

Finally, if you have downloaded the Crystal Space 18.001 package, or if you have retrieved Crystal Space from the CVS repository, you will find these documents in the CS/docs/html and CS/docs/pubapi directories, respectively.

Caveats

Although I performed all the tasks involved in porting Crystal Space to Mac OS X, I do not actually own Macintosh hardware or have access to Mac OS X (though donations would be gladly accepted). Thus, the Mac OS X port was actually performed blindly. Just prior the 18.001 release (in fact only minutes before), we had the good fortune of having a member of the mailing-list test the Mac OS X port. This gentleman reported the good news that he succeeded at building Crystal Space’s plug-in modules and running the WalkTest demonstration program. This is particularly encouraging news given the totally blind porting effort. It also reflects well on the Cocoa technology since the same code works for Mac OS X Server 1.0 (Rhapsody), OpenStep, and NextStep.

However, beyond what was reported by the tester’s initial attempts at building and running the project, there is not yet much concrete information to report about the Cocoa-based Crystal Space port. I await further feedback from Crystal Space users and the Macintosh community. Another issue of potential concern for Macintosh users is video performance. Earlier Cocoa-based environments from NeXT did not support video hardware acceleration, so there was never any need (or indeed opportunity) to write drivers which take advantage of hardware acceleration. Consequently, only a high-level AppKit-based driver is available. This driver supports only software rendering. Although I have employed several techniques for squeezing performance out of this driver, because of its high-level nature as well as certain AppKit restrictions, it will no doubt be slower than a driver which employs a lower-level API for more direct access to the video hardware.

In the future, I would like to see the introduction of drivers based on CoreGraphics and OpenGL. Given my current lack of Macintosh hardware, there is little likelihood that I will write these drivers any time soon, but I would be happy to give guidance to any one who wants to volunteer for the task. Because of the highly encapsulated nature of drivers in Crystal Space, writing a video driver may very well prove manageable even for someone with limited exposure to the Crystal Space environment.

One final caveat deals with the build environment. Crystal Space is in a beta state and changes fairly often. Historical experience has shown that maintaining up-to-date project files can be a difficult task. As a consequence, the build procedure for Crystal Space is command-line-based and involves invoking a few commands from within the Terminal application. Although, building the project from the command-line is quite simple and straightforward, it is understandable that Macintosh developers who are used to working within an integrated development environments (IDE) may find this build procedure rather crude. In the future, I may set up a facility for automatically generating up-to-date Project Builder project files on-the-fly, much in the same way that I recently created a facility for automatically generating Visual-C++ project files.

A side effect of building Crystal Space from the command-line, using the standard makefile system employed by most other ports of Crystal Space, is that the compiled executables are not placed into application wrappers .app. One consequence of this is that it may not be possible to launch Crystal Space programs via double-click from the Finder¹.

If this is indeed the case, then programs will have to be launched manually from the command-line. The documentation which I wrote for the Crystal Space User’s Manual explains all about this limitation. To resolve this issue, in addition to the possibility of creating Project Builder project files, my plans include re-engineering Crystal Space’s makefile system to allow it to generate properly wrapped .app applications.

Future Directions

The Cocoa-based port is considered the most important Macintosh port since it is up-to-date and well maintained.

We have considered dropping the pre-Carbon port of Crystal Space on account of its incomplete and out-of-date nature. However, our decision to not (yet) drop that port is based on the understanding that it will probably take Macintosh users a year or two to transition from Mac OS 9 to Mac OS X.

It would be nice for the classic Macintosh port of Crystal Space to be Carbonized since that would allow it to run on both Mac OS X and Mac OS 9. Whether or not this will actually occur, depends on whether or not we can find developers willing to make the effort to perform the conversion and then support it afterward. (However, see the “Late Breaking News” section below.)

In the long-run, because the Cocoa-based port is built upon Apple’s newest technology, we foresee that this will be the port of choice for the future, and that the old classic Macintosh Toolbox port will ultimately be phased out.

Late Breaking News

One of the pre-Carbon Mac OS 9 port maintainers, K. Robert Bate”, has just returned from a prolonged absence and has once again started updating on the Mac OS 9 port of Crystal Space. His most recent work involves updating the CodeWarrior project files (which were extremely outdated) and ensuring that the project can be built with the most recent version of CodeWarrior. Mr. Bate has also stated his intention of Carbonizing the Mac OS 9 port, however it is unknown as to when this task will be completed.

The patched CodeWarrior project files will be made available as part of the 18.002 release of Crystal Space (for which I do not currently have a concrete release date). Patched project files can also be retrieved from the CVS repository by checking out the R0_18 branch of Crystal Space. For instance, you might invoke the following instruction from the command-line to retrieve the R0_18 branch:bq.

cvs -z9 -d

:pserver:anonymous@cvs.crystal.sourceforge.net:/cvsroot/crystal

checkout -P -rR0_18 CS

If you are a CVS user, then you may also be interested in Crystal Space version 19.dev which is under development in the main CVS trunk. Be aware, however, that this version has already diverged significantly from stable version 18, and there are no guarantees that it will even build or run on Mac OS X at this time. For the moment, we recommend that people stick with the 18 release unless they are feeling particularly adventurous.

¹ Without access to Mac OS X, I am unable to personally verify this.

introduction,mac,crystal,space,engine

kodp02.jpg
alt “Screenshot”

I designed most of the basics of the underlying economic model and the basic user interface. The design document at this point was still very rough. I knew the basic sort of interactivity and that a resource management game was the best framework to use for a hundred year story. Elise Bowditch, my Associate Producer who also did the multimedia programming with mTropolis, and myself also commissioned a few pieces of art. I found an artist and paid him to create some images to serve as a prototype, showing the three main types of screens (game play, interactive story, and myth). I also flew down to California for a meeting with Greg and we went over various cool Glorantha things that would be incorporated into the game.

Assembling the Team

We used our industry networking to locate talented artists for the project. We relied on a contract agency to fill the other positions needed to complete the project, such as user interface designer and Windows programmer. I had initially planned to use another writer, however after I heard that Robin Laws was available, I quickly asked him to join us. The Windows programmer also implemented our scripting language. Overall, the development team was on board as contractors — yes, they all had contracts which spelled out rights to the artwork.

kodp03.jpg
alt “Screenshot”

Creating a Cross-platform Product

When we began the project, the mTropolis authoring tool was the premier product for developing multimedia rich cross-platform productions. mTropolis was later purchased by Quark, who in turn killed it; despite its lack of support, though, it is still a great tool. Why mTropolis? A review in the now defunct magazine ‘Interactivity’ convinced me that it was the right tool for the project. Its cross-platform output was key, since we had no in-house Windows experience. We were familiar with Director and knew its flaws. We tested some smaller projects with mTropolis and realized the productivity gains that could be achieved with this powerful tool.

mTropolis is also extensible via C/C++, and projects can be executed without requiring outside libraries such as QuickTime to be installed. mTropolis consists of a Mac-based editor and a runtime which runs on either Mac OS or Windows. The editor compiles your project into what I’ll call a “package” since I don’t recall the official name.

When we began, mTropolis 1.0 created different packages for Mac and Windows. Version 2.0 added a cross-platform package format (which is a huge help when you’re making a cross-platform CD!). You can actually run directly off the CD — one reason we didn‚Äôt go with QuickTime. Well, Windows isn’t quite that simple, but you can still run directly without installing. Overall, mTropolis served us well over the three year development cycle.

Design and Development

Our artists all use traditional media: ink, paint, scratchboard. They used our old HP scanner, then did post work inside Photoshop. Another artist just gave me the originals and I scanned them and did almost no touchup. And then everything got DeBabelized before going into the project. The artists were mostly local, so we’d meet and go over sketches, or occasionally deal with faxes. We began by establishing the basic look of the world (the Osprey books were a great help for historical costumes). The artists came up with additional details that fit in well. Since they were contractors, most of them worked in their own facilities. We worked out of our house to save costs. Towards the end, we hired a QA guy, and he also worked out of a spare room (since it’s vital to be able to see just what happened after a crash). We relied heavily on TestTrack, a bug-tracking database, to keep the project running smoothly. We used Filemaker to check off our milestones.

The scripting language (Opal Scripting Language — Opal was our code-name) is used for the interactive scenes, and helps out a few elements of the economic model. It’s really special-purpose (though our programmer did a fine job putting in flexibility). The syntax is actually derived largely from what our writer was creating for the interactive scenes. I’d asked him to use my outline processor Acta, so there was a certain amount of structure in these already. If we had obtained additional funding we could have ramped up a bit and finished sooner, I think. (Else we would have ramped up and added features the publisher wanted and finished no sooner.) Another problem was that we wanted to sell the game at all stages (i.e. have a polished demo to show publishers). We devoted too much time towards perfecting the user interface. In hindsight, it would have been better to work out the UI and then do final rendering.

What Went Right

Unlike many games today that rely on 3D CGI eye-candy, our game combined the best of today’s interactivity technology along with traditional art media. This created a unique look for our game and made it stand out from the crowded me-too herd. Response to the finished game has been very positive from both players and the gaming media. We were very proud to have King of Dragon Pass win the award for “Best Visual Arts” at the second annual Independent Games Festival as well as being nominated for an “Origins Award.”

• Developer: A#
• Notable: Best Visual Arts Award (2nd Independent Games Festival), Nominated for an Origins Award
• Genre: Turn-Base Strategy
• Site: http://a-sharp.com/kodp
• Team size: 2
• Released date: October 1999
• Project length: 3 years
• Development hardware: Power Computing clones, PowerBook G3, Gateway machines
• Critical applications: mTropolis, Photoshop, Debabelizer

Before working on Mac DoomLegacy (MDL), what type of programming were you involved in?

When I was learning how to use OpenGL, I spent a lot of time modifying the GLUT demos supplied by Apple. I wrote a demo of my own, which was just a cloud of colored particles spinning in space, and uploaded it to my web site. I soon got lots of emails from users, some just saying how much they liked it, others requesting more features like SoundJamMP and Setting Sun support. Because I got so much feedback I didn’t want to stop adding more features, which helped me to learn more and more about Mac programming. Just the other day I got an email from a French physicist (ironic, isn’t it?) who wanted a video of my demo for part of his presentation at a conference on plasma research.

doomlegacy02.jpg

alt=“Screenshot”

How did you get involved in the DoomLegacy project?

About two years ago I posted a message in the ZDoom forum expressing an interest in doing a Mac port of ZDoomGL. Of course I was immediately flamed by many of the non-Mac programmers. So for a time, I forgot about the idea mainly because I didn’t feel experienced enough to see the project through to its conclusion. About six months later, I got an email from Peter Heinemann, a big fan of Doom and Macs. He had read my message six months after I posted it and wanted to know if I was still interested in doing a port. I thought about it and decided to give it a go—what did I have to lose? I contacted Hurdler, one of the original Legacy team members, joined the Legacy mailing list, and downloaded the source. At this point I didn’t think I would ever finish the port. I just hoped that I could get it started and then let someone else do the difficult bits and finish it off. Once I had gotten the code compiling and running, the satisfaction of getting each part working for the first time kept me motivated, so the thought of leaving it unfinished soon became untenable.

Were there any further contacts with Peter? Did he assist you?

Peter has kept in touch and is also one of the few users who believes that software rendering is central to the Doom experience. Peter isn’t a programmer, although if he was I’m sure he would have helped.

You went after a project that was very challenging due to its code-base. Did you ever consider working on a more Mac-friendly project, like the Marathon 3D engine for example?

I didn’t see Marathon as an opportunity—most of the work was done and there were already people working on it. Doom was going to be my project that I could do with as I pleased (pretty much), which appealed to me (as a relatively inexperienced developer). I’m not saying that working with other people is not what I wanted (I work with the Legacy team regularly), but I wouldn’t have attempted the more difficult tasks like the sound and network-code if there was someone more experienced willing to do it for me.

OpenGL is now a Macintosh standard but back when you first started the project did you consider QuickDraw3D?

OpenGL was the main reason why I wanted to do Mac DoomLegacy. It required little effort to port, and looks really great too. QuickDraw (or software rendering) would have been a little harder to code, would not have run as fast, and would not have used the dynamic lighting features in Legacy.

Did you experience any difficulties with OpenGL?

There were no major difficulties as the OpenGL code itself remained pretty much unchanged—one of the reasons why it’s so great. There were problems with the way Legacy read textures from files, but that was nothing to do with OpenGL itself. Also, supporting VooDoo 1/2/3 cards is a pain as they can’t use 32-bit color, so I defaulted to 16 bit with 32 bit as an option.

How did you handle the detection of the video card in the code?

Video cards aren’t detected by MDL yet, although it is a feature that I may consider adding. It would be useful for less experienced gamers who don’t know to turn options off to get decent frame rates, although most people seem to know to do these things themselves.

What portions of the code were most challenging?

For about a month I wondered how I was ever going to add sound support to Legacy, as I had never written code that used the Sound Manager. Then one day I sat down with all of the Sound documentation and sample code I could find. It took me 10 minutes to realize that the Heretic sound code (written by Brad Oliver) was very similar, and then five minutes more to do a fairly quick cut-and-paste job. The code worked beautifully, and I kicked myself for putting it off for so long, just because I didn’t have any previous experience. Aside from the network code (which I cannot test without a second computer), the most difficult issue was endianness. For those who don’t know, PowerPC processors (which are big endian) and x86 processors (little endian) store bytes in different orders to each other, e.g. when you read a 4-byte word from disk or a network, you have to swap it from 1-2-3-4 to 4-3-2-1. The Doom code already had some byte-swapping support but the newer Legacy code (developed entirely on little endian processors) did not have the same level of support. Sometimes bytes weren’t swapped at all, and sometimes they were swapped twice (reverting them back to little-endian order). As data is read from files at so many points in the code, it was a case of running Doom until it crashed and then searching for the bug using trial and error.

Some interesting non-Apple sound and graphics SDKs are available from third party developers. Do you have any experience with them?

If you’re talking about OpenAL, then yes. I compiled one of the sample applications and was very impressed by the results—even without a sound card on my computer. There was talk of OpenAL on the Legacy mailing list once, and with the SoundBlaster cards coming to the Mac it would be worth looking into a little more. 3D sound may not add that much to the Doom experience, as there is already stereo sound support, but I would like the chance to use OpenAL to see how it compares to OpenGL.

What are you most proud of accomplishing with the update?

I feel most proud about how much I have learned over the last year or so. Way back then I had very little experience, not just with programming, but with getting bug reports and posting updates. Now I feel I have the confidence to take on any job. I am also very proud of how well I play Doom now! Adding new features that even PC DoomLegacy doesn’t have is also something I’m proud of. An MP3 playlist is the only example of this at the moment but I may add more.

Can you tell us about your development machine/tools?

I use a Blue & White G3 300MHz 128MB RAM with the standard Rage128. I just got a Radeon today and it’s so good! There is no drop in frame rate now even when there are multiple dynamic light sources at 1024×768. DoomLegacy is limited only by the fill rate of your card—a 233MHz G3 will perform similarly to a 733MHz G4 (if they had the same video card).

I use CodeWarrior 5 as my development environment since the only alternative is MPW. I used MPW when I was learning C (because it was free) and quickly found that too many of the code samples I downloaded were CodeWarrior projects. I decided to switch to CodeWarrior and immediately felt at home from my previous experience with Think Pascal. A development environment with everything integrated is such a nice change from the CLI hell of MPW, which must break all of Apple’s Human Interface Guidelines! Having to edit text-files to change things like build options takes too much time and effort, whereas preferences panels are quick and easy, the way everything should be. I want to update to CodeWarrior 6 soon as it would make Mac OS X DoomLegacy a lot easier for me. I have tried using Project Builder but it’s so slow and unresponsive that getting anything done is a chore. I will wait for Mac OS X 1.0 before I make my final decision as to which one to use and hopefully by then Apple will have released the HID libraries for game input.

So you have tried the Mac OS X beta then?

Yes, I got it as soon as it came out and, whilst it looks great, it is too sluggish on my 300MHz G3. I will definitely buy the full version, though, in the hope that Apple have made Aqua a little more responsive. Until then I prefer Mac OS 9—it has all of my emails, applications, games and documents where I expect them to be. I don’t want to spend time getting used to the interface in the beta version only to find that I will have to do it all over again for the final release.

Have you had any feedback from id about your efforts?

Not yet, but I am still hoping. It would be the coolest email I have ever gotten!

With the lack of qualified Mac programmers to work on A-title games have you had any professional job offers?

No, but if any employers are reading this I would like a job over the summer! Something that is vaguely related to Mac programming would be ideal.

http://www.idevgames.com/images/articles/2001/doomlegacy03.jpg

alt=“Screenshot”

You’ve worked with the code for so long that I wonder what you think about the original programmer, the now legendary John Carmack?

Well, John Carmack did write the original code, so it goes without saying that it is well designed. The new Legacy code is also excellent. Hardware rendering was added without having to butcher the original software rendering code. You can switch resolutions in the middle of a game without restarting Legacy. In the next version you can play Heretic, with a totally different interface and game play, using the same application. There are loads of other features in Legacy that owe themselves to the way the code was designed. The console is also very important—it allows developers to output data and modify settings whilst playing the game. Without the console you have to pause and switch to the debugger or output the data to a file and read it later, wasting a lot of time. Every game should have a console, not just first-person shooters. All of the operating system specific code was contained in one group of files, which means that the code does not contain too many “@#ifdef MACOS@” and “@#ifdef WIN32@.” This means that I spent 90 percent of my time in this 10 percent of the source, reducing the amount of information I had to keep track of at any time.

Looking back, would you have done anything differently with the code the Legacy team wrote?

Not really. At this point I am only just beginning to understand how Legacy actually works. Maybe soon I will add major features/changes but until then I will follow the excellent work done by Boris, Hurdler and the rest of the team.

Based on your pre-programming days interest in physics I’m surprised you haven’t already added extra things like fog, special weapons or other neat tricks in the gameplay.

Fog is already there (”@gr_fog 1@” at the console) but the most important point about DoomLegacy is that it doesn’t change the gameplay of the original game. There are options like rocket jumping and crouching but they can be turned off by the user. If too many new features are added, Doom might end up looking more like Quake, which is not what the Legacy team wants.

Speaking of Quake, have you looked at the source code?

I spent the whole of the Christmas holidays reading it on my dad’s laptop when it was released. Seeing how a modern game engine works is invaluable to people who know how to use if() statements and while() loops but don’t have any experience of writing a game from scratch. I haven’t attempted to modify the Mac GLQuake source yet. It seems pretty good to me and everyone else has done the fun bits. Now all that there is to do is optimize or add to the engine which is not something that I find appealing at the moment.

So would you rather start on your own engine?

Probably not. There are already several pretty good Open Source engines such as Crystal Space, Quake and Doom, so anything I would attempt would not even compare. I could write an engine for another game genre (which does appeal to me) but not whilst I still have Doom and my course at university to work on.

Your site mentions Heretic. Will you be shifting your focus towards Heretic now?

MDL and Heretic are the same application so any new features will apply to both. There is very little difference in the code now that Heretic support is in there, thanks to the way Doom and Heretic were designed. I can think of loads of features that would be cool to add to Doom but I haven’t decided if I want to focus on Doom or start a new project. All of the new features in PC DoomLegacy will of course still be added to the Mac version, as they shouldn’t require much work on my side.

Do you intend releasing a software rendered version of Doom?

There are some people who believe that software rendering is better than OpenGL and that Doom is not complete without it. I agree (at least with the last statement) and have spent a lot of thought justifying the time it would take to add software rendering. The fact is most Mac gamers now have video cards that will run Legacy perfectly well, so why should I add a feature that only 5 to 10 percent of people will use? Would they not prefer OpenAL support or some other feature instead?

Doom and Heretic are both first person shooters. Do you prefer this type of game?

I loved Super Mario World, Mario Kart and Zelda on my SNES—three of the best games ever. FPS are great for eye candy and relieving stress, but I also like Escape Velocity and Sim City (2000). I don’t like real-time strategy much. They don’t satisfy my trigger-finger. In my opinion games should be only one of those two genres at any one time, not both.

Would you consider updating another open sourced game, like Nanosaur for example?

GLNanosaur? That might be interesting, but it wouldn’t be a new experience for me. Much as I would like to make games forever, it’s a case of “been there — done that.” Sometimes I feel like picking a random project from Sourceforge.net and porting it to the Mac OS, because I have so much choice available right now. I also want to make a bit of money from my work. As much as I want to believe in free software, the only way to make money as far as I can see is to write a program and sell registrations.

You’re in your second year at university now. Would it be safe to say that you are looking forward to a career in the game industry?

I find programming rewarding, fun, and interesting, so working as a programmer professionally is the most obvious career path for me to take. At the moment I still want to leave my options open, but a job doing what I have done with DoomLegacy is what I seem to be heading towards right now.

Which is the most interesting postcard you have received so far?

I haven’t gotten any yet! I thought it might be fun to brighten up my room with some postcards but I don’t expect everyone to send me one (although it would be nice of them).

Bio

Originally from Belfast, Northern Ireland, Calum currently works for Zonic, a Macintosh software company based near Reading in the South of England. He was a student at Edinburgh University, where he got his B.Sc. in Software Engineering.

calum,robinson,mac,doom,legacy

MacSoft is a software publisher. As a software publisher, are you involved in programming and development?

Yes, MacSoft is indeed a publisher, but that doesn’t preclude us from being a developer as well. Many of our titles get subcontracted, many to Westlake, some to other developers. But we also have three programmers on staff, essentially our own internal “porting studio.” This means we can get one or two additional titles done and also gives us the flexibility to deal with the unexpected.

Could you provide our readers with a general outline of a typical game’s project schedule?

Generally product development follows a fairly standard path. You start out with a proposal: a short description, maybe a couple of paragraphs, which gives a general idea of the concept without going into any real implementation details. The proposal is submitted for review and, if accepted, the project moves on to the “storyboard” or “design document” phase. This is where the program is really fleshed out. All of the screens, program flow, user interface, and implementation issues are dealt with at this stage. Some prototyping may also be done. At this point the document is generally reviewed and there are possibly changes made. After this the project coding progresses. Milestones are generally used to make sure the project adheres to the timelines. Common milestones include alpha, beta, and gold master, though these tend to be later in the life of the project.

In an article on the porting business by Glenda Adams, she mentions that it is important to browse through the original source code to determine the workload. I assume this is to some extent always done first by some of your people?

Of course. We always review the code before committing to a project — or we let Glenda do it for us if we’ve already determined that her group will be doing the port. We can also use the code review as a measuring stick to determine whether we can give the project to a new untested porting group, or if we need to give it to a more seasoned group that we know can handle it.

Over the last few years we’ve seen a rise in PC publishers’ interest in the Macintosh platform. During the PC/Console development cycle, how far ahead are they thinking in terms of future ports, and technologies that will allow for easier porting?

In our experience very few publishers are thinking ahead to multi-platform products. The source code we see has generally been specifically coded to the PC. Titles that are brought to the consoles also appear to be ported from the PC source.

From a publisher’s viewpoint, is the extra effort to simultaneously release on Mac and PC worth it? Or is better to develop the code on one platform, and port at a later date?

If you’re asking about one development house simultaneously releasing a product on two platforms then I think everyone should be doing it. The benefits are many and the cost relatively small.

If you’re talking about one developer trying to port the work of another while that work is still in progress then I would say there are many issues to consider. You are at the mercy of the primary developer. If they are behind schedule, so are you. If they decide to redesign the program halfway through the coding process, you’ve just wasted the last few months of programming. If they start releasing patches you must do the same to remain compatible.

Do you consider MacSoft to be a technology pioneer of new Macintosh technologies?

The only thing we demand from our developers is that they produce a high quality product for us. We tend to use whatever technologies make the most sense for the problem at hand. I don’t believe that makes us pioneers as much as it makes us problem solvers.

It must have been great for MacSoft to see Apple return to the consumer market with the iMac and iBook lines. However, some critics feel that the increase in iMac users doesn’t necessary mean more gamers. What’s your impression on this?

Unfortunately this assessment appears to be a bit accurate. A large percentage of iMac buyers use it to access the Internet. It doesn’t seem to be a gamer’s machine. Most of today’s games are made for the avid or hardcore game player. I believe that iMac buyers generally fall into the category of casual game player. We are currently trying to expand our presence in this market.

When Steve Jobs returned to Apple, he visited many core industries and spoke to their developers. In regards to the game industry, were there any people from MacSoft present during these strategy meetings?

Apple asked us for a list of things that we thought should be addressed, which we supplied, but we were not involved at any higher level than that.

Besides the titles from Logicware and Westlake, what approach does MacSoft take to finding a game that will appeal to Mac gamers?

We stay aware of what’s going on in the PC world and try to pick up the titles that either are big hits, or those that are likely to be.

We don’t have anyone assigned to this task, we simply keep our eyes and ears open, and listen to our development partners when they suggest a possible title.

By releasing for Mac and PC at the same time, it’s no longer possible to only choose the best sellers for a release. Does this bring extra pressure along?

This does cause some special problems. Ordinarily we can look at the PC sales and determine whether we believe it will sell well on the Macintosh. So we take a chance right out of the chute. Then, as I stated earlier, you are at the mercy of the PC development house during the development process. Finally, you have to review the product and see if it still fits your expectations. We ate a few months of development cost when we terminated a co-development project after reviews indicated that the PC version probably wouldn’t see up to expectations.

Bio:

Brian’s notable titles include Age of Empires, Civilizitation II, Falcon 4.0, Master of Orion II, Quake, UnReal.

¹ Since this interview, Brian Nesse has left MacSoft to take a position with Netscape.

A Mac-first Developer Speaks

Inside Mac Games interviewed Brian Greenstone of Pangea Software about Mac gaming during the past year. Brian had a very important comment that Apple really needs to understand. He said, “I think it’s sad that there is hardly any original development on the Mac anymore, but at the same time, I’m happy to see so many PC games being ported.“ I can’t agree more. All Mac users feel better about the quantity of Mac titles that are available compared to a few years ago. However 90 percent of Mac games are ported from the PC platform. Westlake, Aspyr, MacPlay, and MacSoft have done great jobs converting many PC titles to the Macintosh. However, Apple really needs to start courting some developers to release titles for the Mac first. Having unique and state-of-the-art technology in Mac-only titles will help to draw buyers and players to our platform. The game industry is a business, so I don’t mean to imply that the title should stay Mac-only forever. Instead, release the PC/PS2 version a few months later. Brian goes onto say, “Developers needs to return to doing more original titles which will really make the platform shine.“ Right again. I just mentioned some great Mac Developers, but of course there are many more that I didn’t list. As their revenue grows and they are able to increase their staff, I hope they will start to expand their businesses to include original titles, as well as generating revenue from the porting business—both ways.

Apple Can Help

Why don’t we have more original development of Mac titles? It really comes down to four points:

• Lack of qualified Mac game programmers
• Majority of game development tools are PC-only
• Smaller market
• Apple not being aggressive enough in the game market

Search the Internet for PC game programming pages. Depending on your search engine, you should be able to find over 100 various sites. Now, search the Internet for Mac-specific sites. Hopefully your search engine of choice will come up with one—iDevGames. There are many sites that don’t cater to a platform, but to a general area, such as AI, or OpenGL. Mac programmers can of course take advantage of the information on such sites, as they tend to be platform neutral, or the code is provided in ANSI C. Getting back to the issue, it seems that the dark period¹ caused many developers to leave our platform. Not only did developers leave, but would-be programmers looked at the gaming world and decided, “The Wintel platform is where the big bucks are.” When I talk to some programmers working on Mac ports, I sometimes hear that they refuse projects resulting from time issues and staff. Apple needs to address this problem. I’ve read different opinions on what Apple can do, ranging from “Give the Developers free Macs” to “Give away free development tools,” and even “Apple should make games.√√π I don√√t think there is a simple answer to training Mac game programmers. Hopefully, we can brainstorm some strategies and forward them to Apple.

CodeWarrior. Where would we be without CodeWarrior? Most likely we would be using six-year-old Symantec compilers, or Apple’s MPW. However, we have CodeWarrior, and thus we have a window to other platforms and they have a window to ours. (CodeWarrior is available for multiple platforms.) But CodeWarrior isn’t enough. It is a part of the tool set that a professional game developer utilizes. There are many other tools in the industry that are important to making games. However, the vast majority are PC based. Of course, many developers build their own utilities, tools, and editors. Some developers even give them away! Generally, though, the Mac lacks high-end game development tools. Let’s cross our fingers that the power of Mac OS X will convince developers who make these tools to look at the Mac market.

Point three is a tricky subject. For every argument against developing for the Mac, there is a counter argument to develop for the Mac. In my editorial “Know Thy Market,” I covered how Apple is marketing itself to game developers. Overall, this issue is like a catch-22. It goes like this:

• Not enough games for the Mac;
• Because of this, little Bobby/Susan buys a PC;
• Because little Bobby/Susan bought a PC, there are fewer Mac users and more PC users;
• Because there are fewer Mac users, there are fewer game developers releasing Mac games;
• Because there are fewer Mac games… go back to step 1.

I simplify the problem, but you get the idea. People don’t buy PC or Macs for games only, however, they do drive many consumers to a platform, or away from it.

Not too long ago, a Mac site asked a well-known game developer what Apple should do to help his company. His answer was: “Sell more Macs.” Apple has been selling more Macs since then and has a much stronger product line. The iMacs are indeed powerful machines, and they have led many new users to our platform. On the other hand, developers like Brian point out an important fact: “Apple needs to have a way to upgrade the 3D chips in older iMacs.” After the first generation of iMacs, Apple quickly moved to stop any third-party vendors from offering solutions to keep the iMac line level with current technology. Let’s hope that Apple can provide a graphic board upgrade path in future iMacs. On point four, Apple offers four programs for developers (ADC):

Premier: The Premier Program is an annual membership for professional developers who desire more one-to-one technical support and a complete suite of products and services from Apple. The Premier Program bundles an Apple Developer Connection Mailing subscription, customized for Premier members, with eight incidents of technical support, access to pre-release software seeding, discounts on Apple hardware and much more. As a Premier member, you also receive a full conference pass to Apple’s Worldwide Developer Conference. The Premier Program is priced at $3500 USD per year.

Select: The Select Program is an annual membership perfect for developers who use the Apple Developer Connection website but also rely on the Apple Developer Connection Mailing for technical information and resources. The Select Program bundles a Developer Connection Mailing subscription, customized for Select members, with two incidents of technical support, access to pre-release software seeding including Mac OS X seeds, and more. The Select Program is priced at $500 USD per year.

Student: The Student program offers en E-mail discussion list, a showcase for student applications, the Darwin SDK, various tutorials from WWDC, and the Student Program Tools Sampler CDs. The Student Program is priced at $99 USD per year. If you can’t afford $99 USD a year, you can try their sponsor program.

On-line: Developers in the free ADC On-line program may download the Mac OS X Public Beta Developer Tools, SDKs, and receive the weekly ADC News. If you’d like a more detailed comparison of the programs, you can download this PDF guide from Apple. There are three other support services Apple offers:

The Developer Hardware Purchase Program allows Apple Developer Connection members to purchase Apple hardware systems at a significant discount. Some developers in the past were a bit critical of this “benefit.” Since I’m not an ADC member I will refrain from commenting. Apple also runs many mailing lists and the ADC Developer Mailing list. I subscribe to their Game-Dev list and strongly recommend all would-be Mac game programmers to do so. Finally, whether you are starting a venture, or getting ready to release your product, Apple’s Business Resources page is worth a visit.

The relationship between Apple and its developers, if mapped on a graph, would look like a sine wave—sometimes good, sometimes bad. When Steve Jobs returned to Apple, he made a point of sitting down with the CEOs of the major Macintosh Developers. He asked:

“What isn’t Apple doing for you?”

“How can Apple help you?”

“Tell us what we need to do to win back your trust.”

His approach seemed to have worked because Macromedia and Adobe are still with us. I think it’s time for our iCEO to do the same with Game Developers. Start with the “big players” and then move down the ladder. At the end of the ladder is where I am most interested in. It’s at this end of the market where we will see innovation and hard-core dedication to the Mac platform. Investing in this end of the market also makes sense. Take id Software for example: For years, they worked on some shareware games, then along came Doom—the rest is history. Nevertheless, the impact is still being felt in the game industry. With revenue coming in like a flood, they brought on more staff.

Eventually, some staff left to form new game companies. This isn’t unique to id Software. In fact, every few months dozens of developers decide to leave the constrictions of their now “big corporate” employer to form new ventures. Except for some former staff of Bungie starting new companies, this hasn’t been happening in the Mac market. Perhaps some day when Pangea Software or Westlake Interactive employs a few dozen people, some ambitious programmers and designers will leave to form new Mac ventures.

Words of Bugdom

When Brian was asked for his number one wish as far as the Mac market goes, he replied, “More original development. I can’t say that enough times.” We can’t either! iDevGames hopes that 2001 ushers in a new era for Mac gaming. I recommend you jump over to Inside Mac Games and read the entire interview, along with other developers’ views on Mac gaming 2k. After you read the interviews, and look at all the new games on the market, come back to iDevGames and start to learn how to make games.

¹ The time when the mass media was predicting Apple’s death.

state,of,mac,gaming,2000

The Game Console Market

During a recent interview, the SEGA (Japan) president outlined some of the company’s new strategies. SEGA produces both game hardware and software, and toys, and operates a chain of large game centers in Japan. A few years ago, SEGA entered into merger talks with Bandai. Bandai is well known in and outside Japan for its characters and toys. Mac users may also recall that Bandai’s attempt to enter the game industry came to a halt when Apple abandoned the Pippin platform. Since riding high from its Genesis (MegaDrive) days, the company has been slowly losing market share to rivals Nintendo and Sony. The Dreamcast was supposed to place them back in the game. However, sales have been very sluggish around the world, and now they face threats from new game systems from Sony, Nintendo, and of course Microsoft. Price cuts and Internet gaming have done little to reverse SEGA’s dwindling market share. Sound familiar?

So what can SEGA do to remain in the game business? Since iCEO Steve Jobs has a bit too much on his plate at the moment (i.e. Pixar, Apple, Apple’s stock, magazine cover photos) and can’t lend a hand, the president has been slowly moving SEGA towards new markets. He rose from the ranks of the software division, so he thinks that software (i.e. content) is key to SEGA’s survival.

And hardware? In his interview he mentions that the hardware division is an important asset to the company but it should be slowly phased out. What does this mean? Well, it means that at some point SEGA will stop making game consoles, or perhaps license their game platform to other companies. However, without a platform, how can they survive? First, let’s talk a bit about the console business.

Each new generation of consoles takes a huge investment to develop. The costs of development and the advanced technology used are so high that game consoles are sold below cost. This means that the price the consumer pays for the game console is less than the cost to manufacture the system¹. The key to this business is licensing. Developers pay SEGA and other game console makers to obtain an official license to release their game. The revenue from the licensee is where the hardware maker generates most of its revenue. Of course, hardware companies also have their own software house to create games for their platform. In Nintendo’s case, this is an area in which they excel.

Recently, game console makers have also allowed their core games to be published on other platforms, such as Wintel computers. So the key here is software and developer support. Long ago —though not so long in the gaming world — game console makers forbid developers (i.e. their licensees) to release the same game for another company’s platform. This practice has been shattered with developers like Squaresoft, Konami, and Capcom porting their hits for multiple platforms. As developers move towards the newer generation of game consoles, SEGA is left with fewer sources of revenue. SEGA has been working very hard to move the Dreamcast into the on-line world. This is of course a very sensible move but on-line console gaming really requires high bandwidth. However, we are still a few years away from broadband everywhere. Sharp readers will note that the PS2 is ready for broadband connection, and I expect the Xbox will also offer broadband Internet gaming.

So Where is the Market Heading?

Here are my predictions based on the joint-venture activity in the industry, as well as my crystal ball:

• Nintendo: Their new game Cube will be targeted towards younger players. I also expect strong in-house games from Nintendo for this new machine. The release of the Advanced Color GameBoy is really exciting for some, but the specs don’t seem much of an improvement over their competitor’s offerings.
• Sony: PS1/2 will keep rolling along as the market leader. The PS2 will slowly morph into a “Home Gateway.”
• Microsoft: Sorry, my Apple made Crystal ball displays an error when I try to access the Xbox’s future.

I left out SEGA from my list because SEGA relates to the title of this editorial. SEGA has been quietly working on two strategies that will move them into the new millennium:

• Fiber optics networked game centers
• Wireless (Mobile) gaming

In a nutshell, SEGA has been connecting their game centers across Japan using a very high-speed backbone. Although the popularity of arcades in the US has declined over the years, they are still very popular in SEGA’s home market, Japan. The company has also hinted at going abroad with this vision.

Why the need for such a game center when everyone is buying Cable and DSL Modems? According to SEGA, their network will allow for unprecedented global gaming and put them more in the “theme park” category (i.e. not just games, but other types of entertainment).

Are You Ready For Wireless Gaming?

Ah, finally I come to the point of my editorial. Hopefully you’re still with me and not already flaming me in our forum. SEGA is working with various partners, for example Access Japan, on the emerging wireless device game market. Access is a leader in embedded-device technology for mobile phones, set-top boxes, and other devices. They have a very “Silicon Valley” approach to business, which is rare in Japan.

If any of you have visited Japan within the last four years, you probably noticed that 99 percent of the people on the streets, and driving in cars, are using mobile phones. Big deal? Actually, it is. On a recent trip to America my sister showed me her latest Motorola cellular phone. She was very proud of her phone’s small size as she handed it to me. After complimenting her on the brand because that company also sometimes makes CPUs for Macs, I let her see my Japanese mobile phone, which was half the size. She was quite amazed. Of course, US and Japanese mobile technologies are different so I couldn’t give her a full demonstration — hopefully this will change in the near future. If I did, she would have remembered one word as she walked away in sibling defeat: iMode.

The iMode system was invented by NTT DoCoMo. NTT is a bit like ATT before they were split into the Baby Bells. It’s interesting to note that NTT is engaged in acquisition of ATT’s wireless business unit. They have also moved into Europe so perhaps iMode may be in your future. So, what is special about iMode? Let’s take a look at some stats.

• 48.9% of Japan’s population uses a mobile phone for Internet access.
• DoCoMo iMode maintains a 57% market share for mobile phones in Japan. The next largest rival commands about 16%.
• NTT DoCoMo has the highest market cap in Japan. Higher than Sony, SoftBank, Toyota and even its own parent company. In US dollars the market cap comes out to about $36 billion. In a nutshell, DoCoMo is both the AOL and Microsoft of Japan.
• The 3rd most popular types of wireless sites were related to games/software.
• Games ranked as the 4th most purchased item by mobile users.

So from these stats, we can see that the mobile phone is an important platform in Japan. Mobile phone use is expected to rise even further in the future. The statistics also show that the game industry will be a very important part of this mobile revolution. By next summer, color-screens and improved audio fidelity will be common on most models. Handset makers will also improve screen-resolutions, integrate add-ons such as CMOS digital cameras, expand memory, and offer faster processors. Many models will also be able to handle removable media such as Compact Flash, the Sony Memory Stick, SD Cards, or mini-hard drives.

iMode phones will eventually be capable of using Java, and some other technologies that will make gaming on the go even better. NTT DoCoMo plans to launch the first third-generation (3G) cellular network sometime in May. This new network will initially be limited to 64Kbps, however, as network stability is tested, experts point towards 2 to 3Mps speeds. Just as Microsoft’s OS standard is being challenged in the computer market by Linux and Mac OS X, so too is DoCoMo’s position. They face some fierce competition from local and global players:

• WAP-based phones pushed by iMode’s rivals
• Palm OS based PDAs
• Psion’s EPOC platform (Managed by the Symbian consortium)
• Microsoft CE (Pocket PC) based wireless devices
• Wireless adapters for Nintendo’s Advanced Game Boy

So now we come back to SEGA and their wireless strategy. With all these mobile devices in almost everyone’s hands, SEGA is banking on becoming the premier content provider (i.e. Game Developer) for this huge market. Will they succeed? It’s hard to say but they have some very talented engineers, good intellectual properties, and an ambitious plan to make a seamless gaming world whether you are on the go, or inside one of their state-of-the-art game centers.

¹ Over time, higher production and lower component parts help to reduce the manufacturing cost.

Marketing 101

MacObserver’s Bryan Chaffin has a great article on Apple’s lack of game marketing. Bryan writes:

“Blizzard Entertainment is doing more for Mac gaming than Apple.”

He goes onto say:

“I am not criticizing the efforts of the small team of support people working on games at Apple, I am criticizing the amount of resources that Apple is putting into the effort.”

Bryan is right. When you open a magazine such as Video Maker or Digital Video, you expect to see an Apple ad that touts Firewire, or iMovie. Chances are, you will. However, take Game Developer Magazine for an example. Apple has been running some ads lately in this mostly PC and console magazine. I suppose their intent is to get developers who work on PC and console games to port their projects to the Macintosh, or perhaps to have some of them create original Mac titles. Although the ads look fine, and the Mac model they use looks slick (love that Cinema display), it is an ad that belongs in a consumer magazine. It makes no real case for why developers should be working on the Mac. They should feature some tools, list some market facts, write about less “game glut” on the Mac and lower customer support costs, or perhaps show screen shots of every major title on the Mac, or the company logos of Mac Developers. That ad tells me that Apple thinks game developers will develop for the Mac merely for the slick curves and hip colors that Macs come in. That strategy works for the general consumer market, however, I don’t think developers make business decisions based on these factors. Committing your company to porting a game or developing an original game carries certain risks. I hope my advice finds its way to Apple, so the next time I open Game Developer Magazine, I see a great ad with the caption, “All these titles are on the Mac, where’s yours?”

Mac Game Honcho Wanted

It seems to me that Apple really needs to appoint a qualified “Chief of Game Marketing.” This person should have equal power¹ to that of the people who create strategies for the music, education, and print markets. Let me list some job requirements so you can brush up your resume:

• At least 15 years experience using the Macintosh
• Know the specs of each currently shipping Mac model
• Knowledge of every major development tool for the Macintosh
• Know the difference between a FPS and a RTS game
• At least 10 years experience working in the game industry (Console marketing a big plus)
• Know the names of the top 10 Mac Game Developers
• Must have International sales experience, and retail sales experience (e-commerce experience a big plus)
• Have at least six games installed on your Macintosh

I can think of some individuals who would be good candidates. Or Apple can do a “John Sculley” again, and go outside the computer industry. Bottom line, this position needs to be created, and filled with someone who knows games and the game development business.

¹ Steve Job’s ear.

Overview

CodeWarrior is a software development tool for developing games and applications on the Macintosh platform. The industrial-strength Professional series offers support for multiple platforms and is very feature rich. The latest CodeWarrior Professional version includes support for some of Apple’s most recent technology. Long ago, Metrowerks’ product line was divided into Gold and Bronze versions, along with an academic version for students. Expanding into the consumer market, they released the “Discover Programming on the Mac” series targeted towards new programmers. Although the product included several online books and featured an attractive price, it lacked some important features of the higher-end versions. Some Macintosh programming books also include a tool called “CodeWarrior Lite.” This is a limited, trimmed-down version of the CodeWarrior Professional compiler that allows you to compile only the source code that is included with the book, or on the book’s CD-ROM.

I have been using the professional series to develop applications and games for the Macintosh for many years, so I was looking forward to reviewing Metrowerks’ latest product, CodeWarrior Learning Edition. As I waited for the review copy to hit my desk, I thought about the title “Learning Edition.” Which features would Metrowerks leave out in a tool targeted for the rest of us? And with its low price point, would it remain a viable development tool for programmers on a budget? After all, how do you simplify such a feature-rich program without crippling it? I expected to see a somewhat stripped down version of what I’m used to with CodeWarrior Pro 5, but to my surprise there’s nothing missing that a beginner or intermediate programmer would miss. The debugger is even better than my current debugger. Of course there are some features that didn’t make the cut, like the profiler.

Installation

The installation process is very straightforward. Just double click the Installer, select the target hard drive/folder and choose one of four options:

• Easy Install — Installs all the CodeWarrior Development tools needed to write and compile source code in C, C++ and Java languages. It needs approximately 330MB disk space.
• Minimal Install — Installs the bare tools required to compile C/C++ code. It needs approximately 51MB disk space.
• Java Minimal Install — Installs the bare tools required to write and compile Java programs. It needs approximately 52MB disk space. (Note that this does not include the Java Virtual Machine needed to run Java programs.)
• Custom Install — Allows you to choose which components will be installed.

I selected “Easy Install” for this review as that’s what beginners would do. The installation program displays a few flash screens during the installation process while a progress-bar shows how many files still need to be installed. (Somewhere around six thousand files in total!)

Features

Simplified Install Process

The CodeWarrior Learning Edition has a simplified installation, which takes less time to install than the full versions, and also requires less space on your hard drive. This allows students and teachers to get up and running quickly.

Simplified IDE

If you are already familiar with the full versions of CodeWarrior you will notice that the Learning Edition version has fewer tools in the toolbar. This is to simplify the interface for the user. You can add more tools to the toolbar as your experience with CodeWarrior LE increases. CodeWarrior is a project-based development tool, thus a new project must be created in order to use it. A dialog will appear and you can choose a stationery for your project or you can create a blank project. This is also the window where you decide if you want to program in Java or C/C++. A stationery is a template used to create new projects. The stationery will create a duplicate of itself and give it the project name that you assign. As easy as this may seem, it can be daunting to a new user. So, to help the new user, the CodeWarrior Learning Edition comes with training materials. This includes a complete Training Manual and a comprehensive set of Lab Exercises.

CodeWarrior Training Manual

There is a wealth of resources on the Internet that new users might find useful. To help them, Metrowerks has compiled a list of some of the best. To get to them simply double click on the file “StartHere.htm” in the CW Learning Edition folder. This launches a homepage with a table of contents that includes a quick start manual, learning materials, and standard documentation. Click on the Learning Materials link to bring up a list of the different areas a new user can look at to start using CodeWarrior effectively. Click on the Learning CodeWarrior link to display the first page of the training manual. At the bottom of the page are buttons to navigate around the training manual. Click on the Guide button to learn how to use the manual. Click on the Lessons button to bring up a series of lessons about CodeWarrior, in which you learn about such things as interface conventions, compiling basics, and how to customize CodeWarrior LE to your individual preferences.

I think most of you will find these resources very helpful. CodeWarrior LE and its Lab Exercises are the ideal tool for computer science classes. There is a set of hands-on lab exercises installed as part of the Learning Edition. These help the students practice what they have just learned in the training manual. If you would like to examine a typical lab exercise go to where you installed the CW Learning Edition directory and open the folder called Learning. It contains several complete lessons about CodeWarrior and programming.

Rapid-Application Development

During the last few years, developers have tried to reduce the costs of software development and increase speed to market their applications and games. To achieve this you need a framework that takes care of the things every application needs to do, like handling the eventloop and implementing the basic user interaction. RAD tools allow programmers to spend less time building the application’s (game’s) interface. This frees programmers from coding common parts of the program, and allows them to concentrate on what makes their application unique. A good RAD tool also allows programmers to use WYSIWYG tools to build or draw the graphic user interface of the program. As you create your program’s windows, and other portions of the graphic user interface, the RAD tool automatically generates the source code for you. If you’d like to program in C++ there’s a powerful framework that does exactly this. It’s called PowerPlant and it is one of the most flexible frameworks I know. There is also Constructor, an editor that lets you design the GUI visually. This portion of the package is very powerful but requires a bit of studying before you can become a PowerPlant guru. However, once you learn PowerPlant, you will increase your productivity and simplify your coding. I’m interested to compare PowerPlant to Apple’s Cocoa, the new framework in Mac OS X. I should also mention that there are RAD tools for Java development in CodeWarrior LE.

Conclusion

CodeWarrior Learning Edition is everything I expected it to be and then much more. It’s a great tool for those who are new to using CodeWarrior and to programming. It has a simplified yet powerful tool bar. It also contains comprehensive online training and an abundance of learning resources. The training lets you see what CodeWarrior can do and the lab exercises provide practical experience. This experience is further enhanced with the Computer Science AP package. Combining training with hands on lab exercises helps you to become a powerful code warrior.

CodeWarrior LE is a comprehensive and very powerful tool. And for $49 (US) it’s also a bargain. If you want to learn programming and code C/C++ games for the Macintosh, then pick up CodeWarrior LE. You can also add the latest Carbon SDK (Software Development Kit), which is available from Apple, and you’re ready to develop for Mac OS X.

• Rated 9
• Company: Metrowerks
• Version: 2.0
• Category: Development Environment
• MSRP: $49
• Reviewed With: iMac 800MHz, 256MB RAM, 80GB HD

REALbasic 3.0a11 from REAL Software is an easy-to-use, integrated development environment (IDE) that enables users at all levels to create powerful, native applications. This version runs on and compiles for both Classic Mac OS and Mac OS Public Beta. It also includes an important new feature for Mac OS X — the ability to pass commands to the UNIX shell, so that you can to create interfaces to built-in UNIX applications.

• Related Link: Real Software

GameDev.net has a good article called ‘Geometry Culling in 3D Engines’, by Pietari Laurila, which discusses various methods of culling 3D geometry in a 3D engine so as to improve rendering performance. For those out there who are interested in developing 3D games/applications this is one of those things that you must learn, so check it out.

• Related Link: GameDev.net: Geometry Culling in 3D Engines