Curmudgeon Gamer
Curmudgeoning all games equally.
27 May 2006
John Carmack: The SPOnG interview - Interview at SPOnG.com
John Carmack recently had this to say (in a SPOnG.com interview) when asked about consoles measuring up to PC hardware:

But you can get effectively three times the performance if you're targeting a fixed platform than if you're targeting the PC space.

Hrm, so why is it that Aspyr can't carry this over to the Macintosh, a relatively fixed platform? This is why Quake3Test came out Mac-first -- to help id bug test precisely by limiting the platform combinations. Why aren't there iMac-optimized ports, for instance? You can't swap out a video card to save your life. Use this to your advantage, porters! One might say this was done to a limited extent with G4 & G5 processors & Altivec, but why stop at the processor level?

I recently complained to Matt (via email) that we're right back to the Groovy Grover Cleveland $1000 Mac gaming tax I've run into the ground on this site. For $3-400, you can grab a new Win86 PC that runs Civilization 4 or you can grab a video card to slap into year or two old hardware. On the Mac end, anything less than $1300 is a no-go.

Here are the specs:

MacWin86 PC
CPU Processor: PowerPC G5/Intel chipset
CPU Speed: 1.8 GHz or faster
Memory: 512 MB or higher
Hard Disk Space: 3.5 GB free disk space
Video RAM: 64 MB or higher
Disc Drive - DVD
Processor: 1.2 GHz Intel Pentium 4 or AMD Athlon processor or equivalent
Operating System: 256 MB RAM (Windows 2000) / 512 MB RAM (Windows XP)
Hard Drive: 1.7 GB Free
CD-ROM: 4X Speed
Video Card: DirectX 9.0c-compatible 64 MB video card with Hardware T&L support


Good stuff, huh? Strangely, not only does the Mac version require $1000 more hardware, it also requires twice the hard drive space.

Why?

Oh well, at least there's another rumor of Apple hiring game programmers. And as I said to Matt, I can always find some comfort, as I did this morning, that World of Warcraft runs just fine on my old iBook. Now time to buy some [more?] sod.

Labels:

--ruffin at 08:27
Comment [ 11 ]

Comments on this post:

Macs are not at all fixed compared to consoles. There may be fewer video cards than for PCs, but different OS versions, memory capacities and peripherals means it's a different world compared to consoles. Just the different types of software a user can be running in the background introduces far too much variation.

By Anonymous Anonymous, at 27 May, 2006 09:31  

Admittedly I'm suggesting a, well, at best unconventional approach, but what's wrong with targetting, say, G5 iMacs? Seems whatever you wrote for that platform could, with a bit of hacking, work on other Macs, and you'd benefit those users that fall just under the Civ4 sysreqs.

Game companies already have a habit of forcing users to use the latest OS, so I'm not sure I'd count that as part of the shifting platform, though I do see the point. Why not have games boot the Mac? Perhaps they could be made, a la Boot Camp in a sense, to boot just those parts of the OS required for the game without loading the rest of Mac OS? MacGame Mode, perhaps?

I can't imagine there's no possible way to play the relatively stable Mac platform into some additional performance in games. That there's a huge disparity when it comes to game performance remains a real travesty.

Ultimately, the question now boils down to: If I've got an Intel Mac, why am I buying Aspyr's Civ4? Right now, I can't think of a single reason past the price of a Windows license, and that's hardly enough reason to keep me away.

By Blogger rufbo, at 27 May, 2006 12:02  

Soon as I closed the lid to the iBook after commenting, the obvious finally hit: In a year or two, when it comes down to the Grover Cleveland tax or playing games on year old Mac hardware under Boot Camp, Mac hardware users are going to move to Windows [fuller-time?]. That's bad for Aspyr, and something they need to address quickly.

By Blogger rufbo, at 27 May, 2006 12:11  

Would that be a single- or dual-core G5? nVidia 6600 LE with 128MB, 6600 with 256MB, or 7800 with 256MB? Or any of the other graphics cards they've used?

Optimizing for different CPUs, sure. PC games at least used to ship different binaries for different processors (SSE/3DNow! etc.) or runtime selection of differently-optimized key routines. I would be surprised if Mac games don't do that already, after all several OS components do that.

Keep in mind that Microsoft have been working on their gaming technologies for over ten years now, and they are a big driving factor behind their OS design. I doubt there's very much Aspyr can do about it alone, let alone quickly. Apple are advertising some game-related content at WWDC, but it seems limited to "informal lunch-time discussions".

(The quoted minimum PC specs are also very minimum. You'd definitely want something much more powerful.)

By Anonymous Anonymous, at 27 May, 2006 16:08  

I doubt there's very much Aspyr can do about it alone, let alone quickly. Apple are advertising some game-related content at WWDC, but it seems limited to "informal lunch-time discussions".

Well, it was a shame to hear, when Glenda Adams did us the huge favor of gracing our pages with an interview, that the only company she felt could change the state of gaming so that crossplatform technologies were used in place of DirectX-esque ones was, of course, Microsoft. I was too idiotic to see the forest for the trees on that one.

Regardless, I should figure out how many iMacs have been sold and do a Matt-like study of break-even attach rates for games targeting those purty all-in-ones. I wonder how far Aspyr and friends could get -- or another upstart gaming house, I suppose -- if they treated the Intel iMac as the console and other, high-end Macs as gravy.

By Blogger rufbo, at 27 May, 2006 17:42  

You guys should really get off the "cross platform technologies" complaint, as it has exactly zero to do with ports.

It's all about the money. Doing the actual porting is pretty trivial.

m.

By Blogger Michael, at 29 May, 2006 10:43  

It's all about the money. Doing the actual porting is pretty trivial.

I believe you're missing my point -- and then doing a poor job getting me to buy yours. My point is that using xplat techs makes the port truly trivial. If you port instantaneously and release concurrently... *Poof* You've made marketing trivial. Blizzard seems to have Done Things Right on those scores.

2.) If ports were trivial, then why aren't we seeing every company shooting for that extra 3% market share? Why are we seeing ports with such horrendous system requirements? Why is there such a long delay between Windows and Mac versions? Why have so many porting houses closed?

I'm afraid you're going to have to back up your claim a bit before I can give it much creedence.</unintentional flame off> ;^)

By Blogger rufbo, at 31 May, 2006 22:00  

I don't have to convince you--I ported games to alternative platforms for a living. Word is law!

1) No, using x-plat tech doesn't make it a poof task (it's such a red herring). You still need a body on it, but that's not the hard part. The hard part is arranging the retail distribution agreements, spending the money to have customer support deal with the alternative SKU, to have the QA staff deal with the quality assurance, and to market it sufficiently to the alternative SKU market to recoup the money you'd spend. It's also opportunity cost--why spend the money on a niche port when you could do it profitably somewhere else (ie, the PC).

2) Because it's *3%*. Very few people care about that money. Blizzard is the only developer that actually puts effort into it. Id half-asses it, and even EA goes through Aspyr.

The only way you can make a publisher care, as a porting house, is paying a big enough advance to them while making it 100% hands-off, plus the nice royalty rate you'll owe them. Which makes business very tight as a porting developer. Do you spend eighteen man months on the technically difficult, low-margin, low-sales target title, or let that linger and go nail the easier 2d port with a bigger SKU market? Kaching! And this tight business model leads to porting houses closing down. Why? The money! Not the technology.

As to system requirements, Mac hardware has always been under-performant vs. PC. And of course when you need to make this week's payroll with next week's game port, well, it's a lot easier to jack system reqs than it is to justify 3 man months on Mac-specific optimizations.

m.

By Blogger Michael, at 31 May, 2006 22:59  

First, a quick sideline that might be interesting in the context of this conversation: Why make xplat? "Hubris," says Matt Slot of Ambrosia, who have recently made a single "file" for Apeiron that works from 68k through Intel.

http://www.oreillynet.com/mac/blog/2006/05/port_everything_more_on_apeiro.html

I guess the obvious reply to m's latest comes from these bits:

Do you spend eighteen man months on the technically difficult, low-margin, low-sales target title, or let that linger and go nail the easier 2d port with a bigger SKU market? Kaching!

and...

it's a lot easier to jack system reqs than it is to justify 3 man months on Mac-specific optimizations.

This, my friend, is the definition of non-trivial. And as a past Java and dhtml developer, I understand the pitfalls of writing for one platform and expecting it to work on another.

That's my issue -- I don't want porting houses at all. I want the original (a la Apeiron in a sense, though the platforms there are different versions of MacOS) to be written on and tested on every platform where it needs to be run. You can't write once, run everywhere. You write once, *test* *everywhere* -- every intended platform for release, and write some more. This happens before ever releasing.

This is why Blizzard "works". There's no port. The original incorporates the Mac version. There's no extra SKU; it's a hybrid release. Voila.

This is also why one needs to have xplat techs. Otherwise you are writing two games (or a neat DirectX to OpenXX converter, like the BurgerLib, I suppose), and you can't test a single codebase everywhere.

Yes, I understand your point that it still takes testing for an app written with xplat techs for one platform before it can be run on another. It's like a Java app that uses "\" as its path separator or accesses WinAPIs -- or Cocoa. It's "Java", but it ain't. It's WinJava. Xplat techs then xplat design is the only way you get quality game releases on niche platforms.

Btw, why do you say id "half-asses"? At least in Q3, it would seem they couldn't have done it much better. Iirc, id claimed it was a case of swapping out "a few lines of code" at compile time, though later updates began to a lag a bit. Doom 3 seems to be a much different story, admittedly. It would appear id figured out 3% wasn't worth the effort, I suppose, and they didn't really give a rat's arse about [that kind of] hubris.

By Blogger rufbo, at 01 June, 2006 18:11  

You're deliberately misconstruing me--I'm comparing apples to apples to illustrate how they (sys reqs, etc.) are business issues unrelated to the actual difficulty of porting, and those business factors are what control decisions to port, not "what API we choose to use to render pixels."

Id is half-assing it because they don't directly release their own Mac version (or through their PC publisher), they do it through Aspyr. At least with Doom 3--did Quake 3 even get a retail boxed distribution?

m.

By Blogger Michael, at 01 June, 2006 19:48  

Posting anon since I'm tired of seeing my face so many times. Hope that's okay.

You're deliberately misconstruing me--I'm comparing apples to apples to illustrate how they (sys reqs, etc.) are business issues unrelated to the actual difficulty of porting, and those business factors are what control decisions to port, not "what API we choose to use to render pixels."

If I'm misconstruing, I'm afraid it is unintentional. It simply sounds like we're approaching from different angles. I'm saying, "Porting's broken. If niche platform gaming is to be fixed, changes need to happen on the frontend by changing the way those platforms are targetted." I believe xplat techs are a required part of [admittedly] completely revamping that process. You can't design a shared codebase for Macs (and Linux, etc) using DirectX. That's sort of a by definition argument.

How would sys reqs be helped with xplat techs? Well, the most obvious sense, they wouldn't at all. Yet if one tests on xplat while writing a shared codebase, I think they'll find they have a much smoother product with lower sys reqs when they're done. Xplat tech is one small but crucial portion of a new way of targetting niche platforms.

What I hear you saying is that porting isn't economical (ie, profitable), and that this stems primarily from what I'll call "business," rather than technical, issues. Fair enough, to a point. One guy working 18 months, if that's all that's needed, is very little with respect to the development budgets of today's games. 18 months plus 3 to optimize is still very small, I imagine. That's, what, let's say $200-250k in salary and hardware to be safe, perhaps? Not exactly petty cash, but arguably trivial, I suppose.

I don't believe, from my limited experience, that niche gaming has much hope of growth using the system it would appear neither of us see as particularly tenable. I do, however, believe hybrid (and therefore concurrent) releases, a benefit from targetting each platform from square one, help cut down on the sorts of backend business issues you describe.

Am I naive to hope that we could eventually find a system where games get made The Xplat Way and, long term, The Xplat Way costs less than 3% more in design/release expendatures so that the 3% more sales is a great investment? Very *very* likely so [that I'm overly naive]. That's why I asked Glenda about making xplat techs *easier* to use than, well, DirectX. Unf., my context there was xplat techs targetting more than one platform and gunning for concurrent, hybrid release, etc., which wasn't particularly clear and may explain some confusion here.

Make more sense, or am I burning more of Blogger's bytes?

Wrt Quake 3, yes, there was Mac-specific packaging (what I'd consider The Wrong Way, obviously). I believe Graeme Devine was responsible for Mac support, so that was in-house. The separate Mac release was a bad idea in my book, but the method of coding so that essentially the same codebase was used for and tested on all three target platforms was not. There, id seems to have done a very good job targetting and testing xplat throughout the app's design.

By Anonymous Anonymous, at 01 June, 2006 23:08  

Contact Us

Subscribe to
Posts [Atom]

 Feedburner

Playing

Warm bile sold separately:

Browse Curmudgeon Gamer Memorial Library

Blogroll:

Internet game search:


Archives:
Classic: 02/2002 to 10/2005
Google
 
Web curmudgeongamer.com

This page is powered by Blogger. Isn't yours?