You can't really ship a non-functional product for marketing purposes. The fallout from shipping a buggy version is a lot worse than not shipping one at all because people have spent money in the first case.

WINE is like any other middleware, it has bugs that you need to work around, and it introduces an additional layer of complexity which uses resources and reduces efficiency. Once you choose to use WINE (the API, not the emulator front end), you still hit the same problem as writing native code - lack of ABI. You must still test your WINE based program on the most common Linux distros and you will encounter distro-specific problems.

Our code was very portable, it wasn't a problem to have a native version that didn't use Wine, the problem was the additional engineering needed to ship a top notch game. Game companies run on tight schedules and tight budgets. Producing a linux version would mean skimping somewhere else, so the choice comes down to making a slightly better overall product for a very slightly smaller user base, or making a less polished game that targets a few more users. We chose the former, and most other companies probably would too. It's purely a business decision, since the technical aspects can be solved, they just cost time and money.

Releasing a game for Windows, Mac and Linux sounds all well and good, and the adoption rates on the smaller platforms may be higher as a percentage of the OS install base, but it doesn't make financial sense for most companies to spend the effort to write games for the mac, or especially Linux.

I'm a former game developer who has written games for Windows, OS X, Linux, and all the consoles, so I know the market and development challenges pretty well.

Windows, for the time being, is still the prime software development platform for games, the rest just don't have the necessary tools and third party software. It's pretty much certain that all of your game data will be processed on a windows machine, so windows will have de-facto support as long as this is the case.

If the game is written with portability in mind, and quite a few nowadays are, then it may be ported to the mac. The mac's development tools aren't as good as those available on windows, but between XCode, Shark, dtrace, and the OpenGL profiler, you can get some real work done. The problem is that even if your install rate on the mac is double that on windows, you're still talking about numbers off in the noise. Windows will probably be about 90% of your users, mac would be less than 10%, but it takes more than 10% additional effort to ship the game on the mac, so most companies won't bother.

Now, Slashdot is a very pro-linux crowd, so I'm bound to get a lot of disagreement on this next point. Linux will never be a games platform. No game company will ever devote the resources to support linux as a primary platform. The reason is that "Linux" isn't really a platform, the platforms are Ubuntu, Fedora, SUSE, and stuff we don't care about. If anyone claims that you can write the code once and run on all three, you've never tried to do so for a large project. What happens in practice is that you can get your game running pretty well, with random crashes in X and OpenGL that then take a huge amount of effort to track down, per platform. These platforms differ subtly in their API's and libraries for things like OpenGL, libc, and audio so you are guaranteed that you will never ship a single linux binary.

If I was writing a game from scratch right now, I would still consider windows my primary platform and I'd probably port it to the mac, but Linux would not be worth the cost and then resulting support burden.

(apologies if this is a re-post, my previous comment seems to be missing) Releasing a game for Windows, Mac and Linux sounds all well and good, and the adoption rates on the smaller platforms may be higher as a percentage of the OS install base, but it doesn't make financial sense for most companies to spend the effort to write games for the mac, or especially Linux. I'm a former game developer who has written games for Windows, OS X, Linux, and all the consoles, so I know the market and development challenges pretty well. Windows, for the time being, is still the prime software development platform for games, the rest just don't have the necessary tools and third party software. It's pretty much certain that all of your game data will be processed on a windows machine, so windows will have de-facto support as long as this is the case. If the game is written with portability in mind, and quite a few nowadays are, then it may be ported to the mac. The mac's development tools aren't as good as those available on windows, but between XCode, Shark, dtrace, and the OpenGL profiler, you can get some real work done. The problem is that even if your install rate on the mac is double that on windows, you're still talking about numbers off in the noise. Windows will probably be about 90% of your users, mac would be less than 10%, but it takes more than 10% additional effort to ship the game on the mac, so most companies won't bother. Now, Slashdot is a very pro-linux crowd, so I'm bound to get a lot of disagreement on this next point. Linux will never be a games platform. No game company will ever devote the resources to support linux as a primary platform. The reason is that "Linux" isn't really a platform, the platforms are Ubuntu, Fedora, SUSE, and stuff we don't care about. If anyone claims that you can write the code once and run on all three, you've never tried to do so for a large project. What happens in practice is that you can get your game running pretty well, with random crashes in X and OpenGL that then take a huge amount of effort to track down, per platform. These platforms differ subtly in their API's and libraries for things like OpenGL, libc, and audio so you are guaranteed that you will never ship a single linux binary. If I was writing a game from scratch right now, I would still consider windows my primary platform and I'd probably port it to the mac, but Linux would not be worth the cost and then resulting support burden.