As someone who has worked extensively in the PC games industry (programming lead on Warcraft, Warcraft II, Diablo, StarCraft, Battle.net, Guild Wars) the reason is quite straightforward: that's where all the users who buy games are. During my time at Blizzard the Mac versions of our titles sold ~4% of the PC numbers, though I expect those numbers have changed with the rise of Apple and, to a much lesser extent so far, desktop Linux.
Even with the rise of Linux -- and my belief is that it will rise very rapidly with the advent of Steam for Linux -- PC game developers have years and years of development experience advantage on the Windows platform.
When I and my two co-founders (all of us programmers) started ArenaNet to build Guild Wars in 2000 we considered *nix vs. Windows for the server platform and decided that we'd be more productive continuing to build on Windows based on our previous programming background. All of us had extensive experience with low-level coding on Windows (device drivers, async coding with IOCompletion Ports) and knew that it would take time to replicate that expertise on another platform.
Beyond the learning curve we knew it would be more convenient to be able to run the game server and game client on the same computer. During development I ran two copies of the Guild Wars match-making server, and two copies of the game client, on a single desktop box to test the matching algorithm code. Having to manage that process across multiple computers would have been more of a hassle.
On a personal note, I've been spending a lot of time working on building/using Linux in a virtualized environment (https://github.com/webcoyote/linux-vm). Linux is an awesome development environment! While I much prefer doing C/C++ development using Visual Studio, Linux is better for other programming languages I use or have tried: Ruby, Python, Go, D, and Erlang. And the ecosystem, with projects like Redis, ZooKeeper, Postgres and a slew of NoSQL servers makes it incredibly powerful because it isn't necessary to write everything from scratch (except SQL), as we did for Guild Wars.
Thanks for your insights, Patrick. I've heard nothing but good things about working at ArenaNet. Nobody has every mentioned whether that's due to your guiding hand or the fact that you left
Being a very experienced game developer who tried to switch to Linux, I have posted about this before (and gotten flamed heavily by reactionary Linux people).
The main reason is that debugging is terrible on Linux. gdb is just bad to use, and all these IDEs that try to interface with gdb to "improve" it do it badly (mainly because gdb itself is not good at being interfaced with). Someone needs to nuke this site from orbit and build a new debugger from scratch, and provide a library-style API that IDEs can use to inspect executables in rich and subtle ways.
Productivity is crucial. If the lack of a reasonable debugging environment costs me even 5% of my productivity, that is too much, because games take so much work to make. At the end of a project, I just don't have 5% effort left any more. It requires everything. (But the current Linux situation is way more than a 5% productivity drain. I don't know exactly what it is, but if I were to guess, I would say it is something like 20%.)
That said, Windows / Visual Studio is, itself, not particularly great. There are lots of problems, and if someone who really understood what large-program developers really care about were to step in and develop a new system on Linux, it could be really appealing. But the problem is that this is largely about (a) user experience, and (b) getting a large number of serious technical details bang-on correct, both of which are weak spots of the open-source community.
Secondary reasons are all the flakiness and instability of the operating system generally. Every time I try to install a popular, supposedly-stable Linux distribution (e.g. an Ubuntu long-term support distro), I have basic problems with wifi, or audio, or whatever. Audio on Linux is terrible (!!!!!!), but is very important for games. I need my network to work, always. etc, etc. On Windows these things are not a problem.
OpenGL / Direct3D used to be an issue, but now this is sort of a red herring, and I think the answers in the linked thread about graphics APIs are mostly a diversion. If you are doing a modern game engine and want to launch on Windows, Mac, iOS, and next-generation consoles, you are going to be implementing both Direct3D and OpenGL, most likely. So it wouldn't be too big a deal to develop primarily on an OpenGL-based platform, if that platform were conducive to game development in other ways.
I would be very happy to switch to an open-source operating system. I really dislike what Microsoft does, especially what they are doing now with Windows 8. But today, the cost of switching to Linux is too high. I have a lot of things to do with the number of years of life I have remaining, and I can't afford to cut 20% off the number of years in my life.
I'm a linux developer who's had an internship at a game company a
few years ago. I had the opposite experience.
During my internship, there were problems with visual studio.
Intelisense made everything so slow we had to disable it. VS was
pretty slow and was hard to use without being fullscreen on a big
monitor.
I use emacs and the gdb intergration is excellent. It's never
slowed me down. I've customized it and find it painful to use
another debugger (or an unconfigured gdb) so please don't have it
nuked. When I develop under windows (without cygwin), I miss many
tools I use when programming: valgrind, objdump, grep, sed. I
also miss having more control over the compiler and
linker. Makefiles seem to be much more powerful and flexible
although more complicated then most IDE's projects. SVN and git
are more complicated to use without the command line.
The game I worked on (deus ex human revolution) was being
developed for PC, xbox360 and ps3. Developping for ps3 means that
the code goes through gcc. This caused a few headaches for my
colleagues as it is more rigorous with standards (new line at end
of file gives a warning, templates need to have class or
typename, etc). I was used to it and actually like the fact that
it respects standards.
I've had to install windows 7 on a computer recently and was
baffled by the fact the realtek ethernet, USB3, video drivers
weren't included in the base windows 7 CD. Had I used the
manufacturer's recovery option it might have helped but my
computer would have been loaded with crapware. Ubuntu longterm
support works like a charm on that computer.
From what I've written so far you might conclude that I'm a FOSS
fanboy and dismiss everything windows has to offer. That's not
it, I'm used to my tools and everything else seems slightly
quirky to me. My tools aren't terrible and don't need to be
nuked.
Most game developers have had many years experience developing
for windows and use windows as their primary
platform. Programming for linux is different, strange and
possibly frustrating. I don't think the biggest issue with linux
game developement is the quality of the tools available under
linux but the fact that most game developers are used to using
tools only available for windows.
The one thing I think is lacking for linux to be a viable game
platform is quality graphics drivers but this seems to be
improving with Valve's recent efforts.
TLDR: Using windows is just as quirky as using linux. The biggest
difference is that you are used to your quirks as I am to
mine. Most game developers are used to windows and switching to
linux is hard and uncomfortable.
> Someone needs to nuke this site from orbit and build a new debugger from scratch, and provide an library-style API that IDEs can use to inspect executables in rich and subtle ways.
LLDB[1] can do this, but I'm not sure how far along it is.
Thanks Jonathan for telling it like it is (and enduring the flames). As much as I hate Windows and like Linux, I agree on all your points. (Audio sucks ass on Linux!)
gcc/gdb tools suck because Stallman wants it this way. See Chandler Carruth's talk "Clang: Defending C++ from Murphy's Million Monkeys". Apple wanted to make gcc/gdb more modular, but Stallman doesn't want gcc/gdb to be modular and allow better tools because that would allow those tools to be non-GPL. So Apple spearheaded LLVM to ditch gcc.
LLVM/LLDB might be the way to improvements, but you are also right that the skills in building these higher level tools are not the strength of the current open source community.
So I don't end with a completely negative post on Linux development, Valgrind rocks!
The only good thing about GDB is that it can execute almost arbitrary C code in the frames. Otherwise it suffers from the same problems as GCC in that people decided that being able to embed GDB had to be as complicated as possible and it shows.
The cost of Microsoft being unfriendly to game devs on Windows 8 is likely to be the cause of other platforms getting better, NOT people running in droves to Win8.
On even days I really wish they'd get this. On odd days I hope they never figure it out.
Linux sound has randomly become much better for the last year, including usb headphones. Don't know if its randomly, or if pulseaudio has finally started get some order to thing.
There is however a different way to look at the issue of sound support. Problems in linux tend to only stay unsolved when too few people care about fixing it. The few attempts made like alsa and pulseadio has been constantly criticized to have bad designs. One could then truly wonder why we don't see proof of concept design that is superior.
The main reason is that debugging is terrible on Linux. gdb is just bad to use
I am a cross platform developer. I have spent years developing on Windows, Linux, and OSX. (Also on other OSs, but what ever.)
Debugging with gdb is very different from debugging with a GUI IDE like Visual Studio. And if you are coming form Visual Studio to gdb, then debugging with gdb might seem down right impossible.
However, if debugging with gdb is so terrible, that means that each and every UNIX and all the software which runs on them were developed with this almost impossible to use debugger.
And Linus and the entire Linux dev. community, who rolled out Git almost on a whim, are stuck with gdb and can't come up with anything better.
Can that be true? Or is gdb in fact a great debugger, but with a very steep learning curve?
In my not so humble opinion, gdb is much harder to intuitively pick up than Visual Studio. But if do take the time to learn it, it is just as productive.
Actually in my experience, it is slightly more productive, because it forces you to work slower and think more. This go slower and think more strategy has also made my Visual Studio debugging better. Although if I spend too much time in Visual Studio I can slip into a pattern of less thinking and more break point setting.
tl;dr:
It's good that you are a very experienced game developer, but being a single platform developer kind of sucks. Become the kind of developer who doesn't care what platform they get to develop on.
loved the first answer. I still remember the opengl 2.0 debates.
what puzzles me is the little mention of the horrible state of video, and audio in linux. alsa was an attempt to "fix" the audio sub(eco)system. the broken audio is probably one of the reasons why theres still no proper audio apps in linux.
video? well if you have a recent nvidia card on a desktop system you can at least play games. but that's about it. kernel developers make sure the closed source blobs don't use too many gpl features. nvidia blames it on the kernel devs, the kernel devs blame it on nvidia.
everyone talks about how awesome the opensource intel drivers are, and even though they got a lot faster recently with all the valve feedback, they were an order of magnitude slower than the windows drivers(i don't know if that's still the case). and mesa? well, you judge yourself.
I completely agree on your whole developer ecosystem. To me that is the sole reason why mac osx desktop utility apps strived while linux' more or les stagnated(no data just feeling, and maybe that's a bit harsh, but compared to osx apps that's certainly the case).
Jonathan, thanks for the post. Did you do the Braid Linux version yourself by the way, or did you get some external help in order to produce it ? From there on, based on your sentiment, does this mean that your upcoming games will not support Linux, or that you will let someone else take care of it ?
>Someone needs to nuke this site from orbit and build a new debugger from scratch, and provide an library-style API that IDEs can use to inspect executables in rich and subtle ways.
It's a really stupid question (but this does not take away from the value of the incredible first answer). It makes a huge, blind assumption (running on Windows means using DirectX and explicitly not OpenGL) and ends up assuming correlation implies causation.
There are many Windows-only games written in OpenGL, and the ones that are written with DirectX is not necessarily because DirectX is better but because there are more consumers for Windows.
The short and simple answer is that "real," modern games are ridiculously expensive projects. The highest percentage of PC-gamers can be found (at the moment) on Windows. Ergo, you will write Windows games and use libraries (OpenGL, DirectX, or otherwise) that are available on that platform.
I wouldn't say it's a stupid question. It's a broad question seeking a better understanding that most of us take for granted. And it clearly was treated as a good question by the absolutely astonishing answer it garnered.
Humanity is better for this exchange on Stackoverflow - we need more discussions like this.
It was a dumb question, but if you scroll down, someone responded with an awesome history of the war between Direct X and openGL. I'm pretty sure that's why it was posted here.
As someone who's never done any game development at all, can you give me some sense of the work that would be involved to port a Windows-only OpenGL game to Mac or Linux? What pieces of it would need to be redone or significantly overhauled?
I would have expected it would be quite minimal compared to the work involved in developing the game itself, but I guess I must be wrong if there are "many" Windows-only OpenGL games.
I don't see him making that assumption. It's the other way around: using DX means Windows, which is correct. Even so, he is asking if this could be the reason and I don't see how this is a stupid question.
So are indie games, notgames, and Minecraft all not real for you? Reserving the term "modern games" to only "ridiculously expensive projects" and dubbing the rest "not real" is... just one point of view.
What's interesting to me is the fact that makers of indie and notgames, that do not require the enormous scale and pushing the hardware and programmers to their limits - they often make them for Windows, too!
Because OpenGL is ugly as hell. DirectX is rewritten often (with new versions) to accommodate new ideas, whereas OpenGL new features/ideas are just "tacked" onto the existing code base.
OpenGL also has a huge barrier to entry compared to DirectX.
MSND DirectX resources are fantastic, whereas resources on OpenGL are often out-dated and generally pretty crap.
DirectX requires the DirectX SDK, whereas OpenGL requires GLUT, or GLEW? I think. Perhaps FreeGLUT? OpenGLUT? Or can you just use SDL? Or none of them? What? Exactly.
I wouldn't say OpenGL is ugly as hell. Modern OpenGL (using vertex buffers and such) isn't too bad. But politics, platform-compatibility and corporate hating aside, Direct3D is the better API.
OpenGL suffers from a lot of the same issues as HTML -- designed by a committee of mostly competitors. It should surprise no one that while systems that come out of such arrangements can be vital for the industry, they are very slow moving when compared to an SDK defined by a dictator (benevolent or otherwise) and much more hesitant to allow for the massive changes that new technology would otherwise allow.
I've heard this same sentiment from numerous programmers, including many who prefer Linux. I'm thinking this is probably an informed opinion, not an uninformed one, and should probably not be in the negative in votes.
This is why I chose to learn DirectX first rather than OpenGL.
It's kind of like the Android vs iOS debate. DirectX is like iOS in that there's one main feature set which runs on a lot of devices. Whereas OpenGL was pretty fragmented because of extensions.
The only fragmentation on DirectX that I remember is the vertex-texture fetch (which was only supported by NVIDIA cards) vs render to vertex buffer (only supported by ATI cards) features in DirectX 9.0c. After that, Microsoft really started emphasizing the notion of a standard feature set.
OpenGL moved away from all of that starting with OpenGL ES which is partly why it has became so popular.
Well -- after some significant time wrestling with OpenGL/DirectX under Windows -- I got totally fed up and moved to OS X with Objective C... Objective C syntax certainly takes some getting used to -- but the iTunesU developer videos and overall documentation seems much better and more cohesive than the MSDN stuff ever did.
I guess, however, it's always a balancing act... I mean -- I thought Microsoft was supporting C# as its primary language -- however, Managed DirectX (with examples and documentation) never seemed to arrive (in fact it seemed to disappear)... C++ +MFC has to be the worst development schema ever created (luckily I managed to skip that part of the development history by ducking to VC roles)... I think the only thing that is clear about MFC is that it is a M. F. C. and anything to get away from it including Interop and switching to OS X/Objective C (even if Objective C is replete with legacy C APIs etc.)...
Matter of opinion. I vastly, vastly prefer it to D3D and its unnecessary OO abstractions. The GPU is not "object oriented" and the OpenGL state machine is much closer to how the GPU works. It takes some time learning to understand the underlying philosophy, but if you stick with the core profile (3.2 or newer) and ignore the legacy profile, it will prove a really quite beautiful API to work with.
> DirectX is rewritten often (with new versions) to accommodate new ideas, whereas OpenGL new features/ideas are just "tacked" onto the existing code base
What's the problem here. New functions are added, but older ones are still valid use-cases. Seriously outdated stuff that no hardware no longer really natively supports, such as the fixed-function pipeline, is clearly and most obviously flagged everywhere as outdated legacy ("compatibility profile") API and its use discouraged. However, if you really wanna fire up an old OpenGL 1.1 app you wrote as a teen some 15 years ago, you still could. Now that's actually rather neat, isn't it?
> OpenGL also has a huge barrier to entry compared to DirectX.
Nope? Don't even need an SDK for that. It's pre-installed on all major OSes and implemented by all GPU drivers for years.
Even better is, there's no need for what in D3D results in a DirectX install on client machines. That annoys me actually, whenever I install a new game with Steam, it proceeds to "install DirectX" (sometimes v9, sometimes v10, sometimes v11). Sometimes even just when I start a readily installed game after a longer period of not playing it. WTF? DirectX has been "installed" so many times by now, isn't once enough? And can't DX11 automatically provide a DX9 layer for older games? I know that my GeForce-provided GL 4.2 driver happily implements "all GL versions ever".
> MSND DirectX resources are fantastic, whereas resources on OpenGL are often out-dated and generally pretty crap.
Khronos' GL/GLSL API documentation pages are all comprehensible, accurate, up-to-date and complete, and so are their spec PDFs if that's the preferred format. Their Wiki pages also provide a wealth of absolutely current high-quality information.
As for tutorials out there, some are good and up-to-date, some not -- same for D3D I'd wager?
> whereas OpenGL requires GLUT, or GLEW? I think. Perhaps FreeGLUT? OpenGLUT? Or can you just use SDL? Or none of them? What? Exactly.
> Old John Carmack at Id Software took one look at that trash and said, "Screw that!" and decided to write towards another API: OpenGL.
"Old John Carmack" makes me think he's some sort of half-myth crazy coot mountain man, which made me realize something: There will some day be mythology about computer programmers.
One reason is just that since game development is mostly all windows based, new programmers learn to use windows tools.. and thus become more experienced with them and not wanting to switch to something completely new which would require a loss of productivity.
Also, and that's really only based from my experiences, it seemed to me that game developers aren't that much into "hacking" linux. Things should just Work. The terminal is a deprecated tool compared to new intuitive IDE. Most of you won't agree with these statements (And I clearly don't) but that's really what I've felt every time I'd talk with a game developer friend or colleague. And, this mentality goes back to when I was an engineering students.. While I had fun learning linux and Python, friends graduating in video gaming would laugh of Python for being a "scripting non-performant language" or they would play around in visual studio with C# and making forms or build some games with XNA.
So, sometimes I think it's not that much about linux not being "good enough" but more about video game developers' mentality to not fit with it. Man, I won't lie, I'm an experienced Linux developer and user and I always have to lurk in all kind of forums and RTFM on every small things that needs to be installed (which is not in the standard library). And, it often happens that I break stuff and spend countless hours trying to fix it. Hell, even last week, I've upgraded a server on Archlinux and it totally broke my system without any warning. I really needed help so I went on #archlinux and I've been told that I should have read the archlinux news before tempting an update. Fair enough, I guess.. but I can understand that on a extremely tight schedule, games developers can't waste time on stuff like that. Compared to say, [next] [next] [finish] windows install where everything just Work.
Please, don't down-vote me if you don't agree with things I've seen from my experience. I don't agree with it neither, but I thought I'd share it here. It's really something I see coming again and again from all kind of different video games programmers.
As a games programmer with coming up to 5 years experience, I can attest that this is largely true. At every studio I've worked at, I've been given strange looks for even opening a terminal, and half of them haven't even heard of Vim. Regardless of what the actual strengths and weaknesses of the tools are, most game developers are so heavily wedded to VS and Windows that there is a huge inertia on that side.
Personally, the mobile game that I'm developing now is being developed entirely under Linux with GCC and GDB, and although GDB has a bit of a learning curve I now find it easier and quicker than VS.
>Hell, even last week, I've upgraded a server on Archlinux and it totally broke my system without any warning. I really needed help so I went on #archlinux and I've been told that I should have read the archlinux news before tempting an update. Fair enough, I guess.. but I can understand that on a extremely tight schedule, games developers can't waste time on stuff like that. Compared to say, [next] [next] [finish] windows install where everything just Work.
I don't think Arch is a fair comparison to make. The Arch wiki describes it as:
"Arch Linux is an independently developed, i686/x86-64 general purpose GNU/Linux distribution versatile enough to suit any role. Development focuses on simplicity, minimalism, and code elegance. Arch is installed as a minimal base system, configured by the user upon which their own ideal environment is assembled by installing only what is required or desired for their unique purposes. GUI configuration utilities are not officially provided, and most system configuration is performed from the shell and a text editor. Based on a rolling-release model, Arch strives to stay bleeding edge, and typically offers the latest stable versions of most software." [1]
I use Ubuntu primarily, but use Windows exlusivly to use LabView for a local robotics team. I have had issues with both systems. The difference for me is that when the issue was with Ubuntu, I can norally get it back to a workable state withing 10 minutes, or if desperate do a full reinstall in under an hour after which point I have all of my same programs installed, and my configurations/user data restored. When my problem is with windows, solving it is a full days work (or more).
[1]https://wiki.archlinux.org/index.php/Arch_Linux
> I've upgraded a server on Archlinux and it totally broke my system without any warning. I really needed help so I went on #archlinux and I've been told that I should have read the archlinux news before tempting an update. Fair enough, I guess.. but I can understand that on a extremely tight schedule, games developers can't waste time on stuff like that.
"Be careful with updates, they might break things" is common advice. "Let other people apply the service packs, and see what the problems are, before you go ahead" was (is?) common advice for people running some MS server stuff.
As 2D video game developer with many titles under my belt, I can assure you it's simply a matter of market share. The general rule (before hybrid CDs) was write it for Windows and if it sells, then write it for Mac (later we would release both Windows and Mac on a hybrid CD).
Traditionally Linux was all over the map in terms of graphics, and market share was nil. Nowadays, Linux is prevalent among computer geeks, but in the general population (that have the real $) it's effectively nonexistent.
..and then another decade passed and OpenGL ES won every growth market, returning PC gaming to its niche status. Massive niche, of course, but niche. More Temple Run, dears?
Only on mobiles and we have to thank the iPhone for that.
Before the iPhone there were only crappy 3D apis available, OpenGL done with software rendering,the J2ME 3D Mobile API and even the PocketPC had brain dead versions of DirectX.
As for the game consoles, it is a myth in the FOSS that they use OpenGL.
Except for the PS3, which has OpenGL ES + CG, most consoles not from Microsoft have an OpenGL like API, which is not the same thing.
As for the PS3, most developers actually make use of the proprietary CGM API.
Game developers target Windows because it's(was?) popular. They'll target mobile devices more and more alongside consoles more and more (although, that line is already starting to blur).
Users gravitate toward what's available, what's usable and if possible what has the most vibrant ecosystem of apps. Games, if the developers want to make any money, will target that platform. If the apps are common on a specific platform, then it stands to reason tools for developing other apps/games will also be common on that platform.
One of my friends is a gearhead, this is what he had to say:
"...Shader Model 1.1, which basically was "Whatever the 8500 does.""
Correction - it was Shader Model 1.4
The GF3 already did 1.1, and the GF4 Ti (3 years later) did 1.3.
A very good read though. A decade of drama put into simple words.
They closed the question. It irritates me that the self appointed stackoverflow police are very quick to close questions. They barely give them a chance to see if something good or creative comes a long. (Such as the first comment)
Games are already being ported to other operating systems because of microsoft greed.
MS wants to copy everybody with an app and game store, which will be the only authorized way to download and install anything on to windows 8+
They also want to charge 30% to any vendor that wants to sell in their store. Since game makers like Steam have their own content delivery system which will be blocked by MS they already panicked and announced a new linux client and have claimed to be committed to switching everything over the next few years and dumping windows
[+] [-] netcoyote|13 years ago|reply
Even with the rise of Linux -- and my belief is that it will rise very rapidly with the advent of Steam for Linux -- PC game developers have years and years of development experience advantage on the Windows platform.
When I and my two co-founders (all of us programmers) started ArenaNet to build Guild Wars in 2000 we considered *nix vs. Windows for the server platform and decided that we'd be more productive continuing to build on Windows based on our previous programming background. All of us had extensive experience with low-level coding on Windows (device drivers, async coding with IOCompletion Ports) and knew that it would take time to replicate that expertise on another platform.
Beyond the learning curve we knew it would be more convenient to be able to run the game server and game client on the same computer. During development I ran two copies of the Guild Wars match-making server, and two copies of the game client, on a single desktop box to test the matching algorithm code. Having to manage that process across multiple computers would have been more of a hassle.
On a personal note, I've been spending a lot of time working on building/using Linux in a virtualized environment (https://github.com/webcoyote/linux-vm). Linux is an awesome development environment! While I much prefer doing C/C++ development using Visual Studio, Linux is better for other programming languages I use or have tried: Ruby, Python, Go, D, and Erlang. And the ecosystem, with projects like Redis, ZooKeeper, Postgres and a slew of NoSQL servers makes it incredibly powerful because it isn't necessary to write everything from scratch (except SQL), as we did for Guild Wars.
[+] [-] RobotCaleb|13 years ago|reply
[+] [-] jblow|13 years ago|reply
The main reason is that debugging is terrible on Linux. gdb is just bad to use, and all these IDEs that try to interface with gdb to "improve" it do it badly (mainly because gdb itself is not good at being interfaced with). Someone needs to nuke this site from orbit and build a new debugger from scratch, and provide a library-style API that IDEs can use to inspect executables in rich and subtle ways.
Productivity is crucial. If the lack of a reasonable debugging environment costs me even 5% of my productivity, that is too much, because games take so much work to make. At the end of a project, I just don't have 5% effort left any more. It requires everything. (But the current Linux situation is way more than a 5% productivity drain. I don't know exactly what it is, but if I were to guess, I would say it is something like 20%.)
That said, Windows / Visual Studio is, itself, not particularly great. There are lots of problems, and if someone who really understood what large-program developers really care about were to step in and develop a new system on Linux, it could be really appealing. But the problem is that this is largely about (a) user experience, and (b) getting a large number of serious technical details bang-on correct, both of which are weak spots of the open-source community.
Secondary reasons are all the flakiness and instability of the operating system generally. Every time I try to install a popular, supposedly-stable Linux distribution (e.g. an Ubuntu long-term support distro), I have basic problems with wifi, or audio, or whatever. Audio on Linux is terrible (!!!!!!), but is very important for games. I need my network to work, always. etc, etc. On Windows these things are not a problem.
OpenGL / Direct3D used to be an issue, but now this is sort of a red herring, and I think the answers in the linked thread about graphics APIs are mostly a diversion. If you are doing a modern game engine and want to launch on Windows, Mac, iOS, and next-generation consoles, you are going to be implementing both Direct3D and OpenGL, most likely. So it wouldn't be too big a deal to develop primarily on an OpenGL-based platform, if that platform were conducive to game development in other ways.
I would be very happy to switch to an open-source operating system. I really dislike what Microsoft does, especially what they are doing now with Windows 8. But today, the cost of switching to Linux is too high. I have a lot of things to do with the number of years of life I have remaining, and I can't afford to cut 20% off the number of years in my life.
[+] [-] green7ea|13 years ago|reply
During my internship, there were problems with visual studio. Intelisense made everything so slow we had to disable it. VS was pretty slow and was hard to use without being fullscreen on a big monitor.
I use emacs and the gdb intergration is excellent. It's never slowed me down. I've customized it and find it painful to use another debugger (or an unconfigured gdb) so please don't have it nuked. When I develop under windows (without cygwin), I miss many tools I use when programming: valgrind, objdump, grep, sed. I also miss having more control over the compiler and linker. Makefiles seem to be much more powerful and flexible although more complicated then most IDE's projects. SVN and git are more complicated to use without the command line.
The game I worked on (deus ex human revolution) was being developed for PC, xbox360 and ps3. Developping for ps3 means that the code goes through gcc. This caused a few headaches for my colleagues as it is more rigorous with standards (new line at end of file gives a warning, templates need to have class or typename, etc). I was used to it and actually like the fact that it respects standards.
I've had to install windows 7 on a computer recently and was baffled by the fact the realtek ethernet, USB3, video drivers weren't included in the base windows 7 CD. Had I used the manufacturer's recovery option it might have helped but my computer would have been loaded with crapware. Ubuntu longterm support works like a charm on that computer.
From what I've written so far you might conclude that I'm a FOSS fanboy and dismiss everything windows has to offer. That's not it, I'm used to my tools and everything else seems slightly quirky to me. My tools aren't terrible and don't need to be nuked.
Most game developers have had many years experience developing for windows and use windows as their primary platform. Programming for linux is different, strange and possibly frustrating. I don't think the biggest issue with linux game developement is the quality of the tools available under linux but the fact that most game developers are used to using tools only available for windows.
The one thing I think is lacking for linux to be a viable game platform is quality graphics drivers but this seems to be improving with Valve's recent efforts.
TLDR: Using windows is just as quirky as using linux. The biggest difference is that you are used to your quirks as I am to mine. Most game developers are used to windows and switching to linux is hard and uncomfortable.
[+] [-] edsrzf|13 years ago|reply
LLDB[1] can do this, but I'm not sure how far along it is.
[1] http://lldb.llvm.org/
[+] [-] raverbashing|13 years ago|reply
Sure, gdb is awful, and don't even bother with the IDEs, but in Linux you have: strace and valgrind, and they are very helpful.
Visual Studio is great (except for, ahem, having to use MFC) but at other occasions I was using MingW on Windows.
[+] [-] dottrap|13 years ago|reply
gcc/gdb tools suck because Stallman wants it this way. See Chandler Carruth's talk "Clang: Defending C++ from Murphy's Million Monkeys". Apple wanted to make gcc/gdb more modular, but Stallman doesn't want gcc/gdb to be modular and allow better tools because that would allow those tools to be non-GPL. So Apple spearheaded LLVM to ditch gcc.
LLVM/LLDB might be the way to improvements, but you are also right that the skills in building these higher level tools are not the strength of the current open source community.
So I don't end with a completely negative post on Linux development, Valgrind rocks!
[+] [-] the_mitsuhiko|13 years ago|reply
[+] [-] kabdib|13 years ago|reply
On even days I really wish they'd get this. On odd days I hope they never figure it out.
[+] [-] belorn|13 years ago|reply
There is however a different way to look at the issue of sound support. Problems in linux tend to only stay unsolved when too few people care about fixing it. The few attempts made like alsa and pulseadio has been constantly criticized to have bad designs. One could then truly wonder why we don't see proof of concept design that is superior.
[+] [-] fghh45sdfhr3|13 years ago|reply
I am a cross platform developer. I have spent years developing on Windows, Linux, and OSX. (Also on other OSs, but what ever.)
Debugging with gdb is very different from debugging with a GUI IDE like Visual Studio. And if you are coming form Visual Studio to gdb, then debugging with gdb might seem down right impossible.
However, if debugging with gdb is so terrible, that means that each and every UNIX and all the software which runs on them were developed with this almost impossible to use debugger.
And Linus and the entire Linux dev. community, who rolled out Git almost on a whim, are stuck with gdb and can't come up with anything better.
Can that be true? Or is gdb in fact a great debugger, but with a very steep learning curve?
In my not so humble opinion, gdb is much harder to intuitively pick up than Visual Studio. But if do take the time to learn it, it is just as productive.
Actually in my experience, it is slightly more productive, because it forces you to work slower and think more. This go slower and think more strategy has also made my Visual Studio debugging better. Although if I spend too much time in Visual Studio I can slip into a pattern of less thinking and more break point setting.
tl;dr:
It's good that you are a very experienced game developer, but being a single platform developer kind of sucks. Become the kind of developer who doesn't care what platform they get to develop on.
[+] [-] rjzzleep|13 years ago|reply
what puzzles me is the little mention of the horrible state of video, and audio in linux. alsa was an attempt to "fix" the audio sub(eco)system. the broken audio is probably one of the reasons why theres still no proper audio apps in linux.
video? well if you have a recent nvidia card on a desktop system you can at least play games. but that's about it. kernel developers make sure the closed source blobs don't use too many gpl features. nvidia blames it on the kernel devs, the kernel devs blame it on nvidia.
everyone talks about how awesome the opensource intel drivers are, and even though they got a lot faster recently with all the valve feedback, they were an order of magnitude slower than the windows drivers(i don't know if that's still the case). and mesa? well, you judge yourself.
I completely agree on your whole developer ecosystem. To me that is the sole reason why mac osx desktop utility apps strived while linux' more or les stagnated(no data just feeling, and maybe that's a bit harsh, but compared to osx apps that's certainly the case).
[+] [-] ekianjo|13 years ago|reply
[+] [-] SkyMarshal|13 years ago|reply
Are you referring to the Store, Metro, secure boot, or something else (curious if 'something else' not currently on my radar)?
[+] [-] pekk|13 years ago|reply
It seems incredible that you would not even mention this for the entire post?
[+] [-] anon1385|13 years ago|reply
perhaps LLDB will solve this?
[+] [-] stuaxo|13 years ago|reply
Clang seems to provide a much more API like experience for building compilers, so something similar for debuggers is definitely needed.
[+] [-] ComputerGuru|13 years ago|reply
There are many Windows-only games written in OpenGL, and the ones that are written with DirectX is not necessarily because DirectX is better but because there are more consumers for Windows.
The short and simple answer is that "real," modern games are ridiculously expensive projects. The highest percentage of PC-gamers can be found (at the moment) on Windows. Ergo, you will write Windows games and use libraries (OpenGL, DirectX, or otherwise) that are available on that platform.
[+] [-] blindhippo|13 years ago|reply
Humanity is better for this exchange on Stackoverflow - we need more discussions like this.
[+] [-] phaus|13 years ago|reply
[+] [-] FaceKicker|13 years ago|reply
I would have expected it would be quite minimal compared to the work involved in developing the game itself, but I guess I must be wrong if there are "many" Windows-only OpenGL games.
[+] [-] kristiandupont|13 years ago|reply
[+] [-] listic|13 years ago|reply
What's interesting to me is the fact that makers of indie and notgames, that do not require the enormous scale and pushing the hardware and programmers to their limits - they often make them for Windows, too!
[+] [-] shocks|13 years ago|reply
OpenGL also has a huge barrier to entry compared to DirectX.
MSND DirectX resources are fantastic, whereas resources on OpenGL are often out-dated and generally pretty crap.
DirectX requires the DirectX SDK, whereas OpenGL requires GLUT, or GLEW? I think. Perhaps FreeGLUT? OpenGLUT? Or can you just use SDL? Or none of them? What? Exactly.
[+] [-] georgemcbay|13 years ago|reply
OpenGL suffers from a lot of the same issues as HTML -- designed by a committee of mostly competitors. It should surprise no one that while systems that come out of such arrangements can be vital for the industry, they are very slow moving when compared to an SDK defined by a dictator (benevolent or otherwise) and much more hesitant to allow for the massive changes that new technology would otherwise allow.
[+] [-] gte910h|13 years ago|reply
[+] [-] mrhyperpenguin|13 years ago|reply
It's kind of like the Android vs iOS debate. DirectX is like iOS in that there's one main feature set which runs on a lot of devices. Whereas OpenGL was pretty fragmented because of extensions.
The only fragmentation on DirectX that I remember is the vertex-texture fetch (which was only supported by NVIDIA cards) vs render to vertex buffer (only supported by ATI cards) features in DirectX 9.0c. After that, Microsoft really started emphasizing the notion of a standard feature set.
OpenGL moved away from all of that starting with OpenGL ES which is partly why it has became so popular.
[+] [-] aequrl|13 years ago|reply
I guess, however, it's always a balancing act... I mean -- I thought Microsoft was supporting C# as its primary language -- however, Managed DirectX (with examples and documentation) never seemed to arrive (in fact it seemed to disappear)... C++ +MFC has to be the worst development schema ever created (luckily I managed to skip that part of the development history by ducking to VC roles)... I think the only thing that is clear about MFC is that it is a M. F. C. and anything to get away from it including Interop and switching to OS X/Objective C (even if Objective C is replete with legacy C APIs etc.)...
[+] [-] dualogy|13 years ago|reply
Matter of opinion. I vastly, vastly prefer it to D3D and its unnecessary OO abstractions. The GPU is not "object oriented" and the OpenGL state machine is much closer to how the GPU works. It takes some time learning to understand the underlying philosophy, but if you stick with the core profile (3.2 or newer) and ignore the legacy profile, it will prove a really quite beautiful API to work with.
> DirectX is rewritten often (with new versions) to accommodate new ideas, whereas OpenGL new features/ideas are just "tacked" onto the existing code base
What's the problem here. New functions are added, but older ones are still valid use-cases. Seriously outdated stuff that no hardware no longer really natively supports, such as the fixed-function pipeline, is clearly and most obviously flagged everywhere as outdated legacy ("compatibility profile") API and its use discouraged. However, if you really wanna fire up an old OpenGL 1.1 app you wrote as a teen some 15 years ago, you still could. Now that's actually rather neat, isn't it?
> OpenGL also has a huge barrier to entry compared to DirectX.
Nope? Don't even need an SDK for that. It's pre-installed on all major OSes and implemented by all GPU drivers for years.
Even better is, there's no need for what in D3D results in a DirectX install on client machines. That annoys me actually, whenever I install a new game with Steam, it proceeds to "install DirectX" (sometimes v9, sometimes v10, sometimes v11). Sometimes even just when I start a readily installed game after a longer period of not playing it. WTF? DirectX has been "installed" so many times by now, isn't once enough? And can't DX11 automatically provide a DX9 layer for older games? I know that my GeForce-provided GL 4.2 driver happily implements "all GL versions ever".
> MSND DirectX resources are fantastic, whereas resources on OpenGL are often out-dated and generally pretty crap.
Khronos' GL/GLSL API documentation pages are all comprehensible, accurate, up-to-date and complete, and so are their spec PDFs if that's the preferred format. Their Wiki pages also provide a wealth of absolutely current high-quality information.
As for tutorials out there, some are good and up-to-date, some not -- same for D3D I'd wager?
> whereas OpenGL requires GLUT, or GLEW? I think. Perhaps FreeGLUT? OpenGLUT? Or can you just use SDL? Or none of them? What? Exactly.
I have nothing to add to BlackAura's excellent comment on this: http://news.ycombinator.com/item?id=5127185
Other than: you'll just wanna use GLFW and be done with it...
[+] [-] cmwelsh|13 years ago|reply
I think SFML is in the best place to succeed SDL: http://www.sfml-dev.org/
[+] [-] Cushman|13 years ago|reply
"Old John Carmack" makes me think he's some sort of half-myth crazy coot mountain man, which made me realize something: There will some day be mythology about computer programmers.
Whoa.
[+] [-] d0m|13 years ago|reply
Also, and that's really only based from my experiences, it seemed to me that game developers aren't that much into "hacking" linux. Things should just Work. The terminal is a deprecated tool compared to new intuitive IDE. Most of you won't agree with these statements (And I clearly don't) but that's really what I've felt every time I'd talk with a game developer friend or colleague. And, this mentality goes back to when I was an engineering students.. While I had fun learning linux and Python, friends graduating in video gaming would laugh of Python for being a "scripting non-performant language" or they would play around in visual studio with C# and making forms or build some games with XNA.
So, sometimes I think it's not that much about linux not being "good enough" but more about video game developers' mentality to not fit with it. Man, I won't lie, I'm an experienced Linux developer and user and I always have to lurk in all kind of forums and RTFM on every small things that needs to be installed (which is not in the standard library). And, it often happens that I break stuff and spend countless hours trying to fix it. Hell, even last week, I've upgraded a server on Archlinux and it totally broke my system without any warning. I really needed help so I went on #archlinux and I've been told that I should have read the archlinux news before tempting an update. Fair enough, I guess.. but I can understand that on a extremely tight schedule, games developers can't waste time on stuff like that. Compared to say, [next] [next] [finish] windows install where everything just Work.
Please, don't down-vote me if you don't agree with things I've seen from my experience. I don't agree with it neither, but I thought I'd share it here. It's really something I see coming again and again from all kind of different video games programmers.
[+] [-] NickPollard|13 years ago|reply
Personally, the mobile game that I'm developing now is being developed entirely under Linux with GCC and GDB, and although GDB has a bit of a learning curve I now find it easier and quicker than VS.
[+] [-] gizmo686|13 years ago|reply
I don't think Arch is a fair comparison to make. The Arch wiki describes it as: "Arch Linux is an independently developed, i686/x86-64 general purpose GNU/Linux distribution versatile enough to suit any role. Development focuses on simplicity, minimalism, and code elegance. Arch is installed as a minimal base system, configured by the user upon which their own ideal environment is assembled by installing only what is required or desired for their unique purposes. GUI configuration utilities are not officially provided, and most system configuration is performed from the shell and a text editor. Based on a rolling-release model, Arch strives to stay bleeding edge, and typically offers the latest stable versions of most software." [1]
I use Ubuntu primarily, but use Windows exlusivly to use LabView for a local robotics team. I have had issues with both systems. The difference for me is that when the issue was with Ubuntu, I can norally get it back to a workable state withing 10 minutes, or if desperate do a full reinstall in under an hour after which point I have all of my same programs installed, and my configurations/user data restored. When my problem is with windows, solving it is a full days work (or more). [1]https://wiki.archlinux.org/index.php/Arch_Linux
[+] [-] DanBC|13 years ago|reply
"Be careful with updates, they might break things" is common advice. "Let other people apply the service packs, and see what the problems are, before you go ahead" was (is?) common advice for people running some MS server stuff.
[+] [-] Tekker|13 years ago|reply
Traditionally Linux was all over the map in terms of graphics, and market share was nil. Nowadays, Linux is prevalent among computer geeks, but in the general population (that have the real $) it's effectively nonexistent.
TL;DR - Follow the money.
[+] [-] jpxxx|13 years ago|reply
[+] [-] pjmlp|13 years ago|reply
Before the iPhone there were only crappy 3D apis available, OpenGL done with software rendering,the J2ME 3D Mobile API and even the PocketPC had brain dead versions of DirectX.
As for the game consoles, it is a myth in the FOSS that they use OpenGL.
Except for the PS3, which has OpenGL ES + CG, most consoles not from Microsoft have an OpenGL like API, which is not the same thing.
As for the PS3, most developers actually make use of the proprietary CGM API.
[+] [-] eksith|13 years ago|reply
Users gravitate toward what's available, what's usable and if possible what has the most vibrant ecosystem of apps. Games, if the developers want to make any money, will target that platform. If the apps are common on a specific platform, then it stands to reason tools for developing other apps/games will also be common on that platform.
[+] [-] Someone|13 years ago|reply
[+] [-] godDLL|13 years ago|reply
"...Shader Model 1.1, which basically was "Whatever the 8500 does."" Correction - it was Shader Model 1.4 The GF3 already did 1.1, and the GF4 Ti (3 years later) did 1.3.
A very good read though. A decade of drama put into simple words.
[+] [-] ramayac|13 years ago|reply
[+] [-] bitL|13 years ago|reply
[+] [-] pjmlp|13 years ago|reply
[+] [-] huherto|13 years ago|reply
[+] [-] tonetheman|13 years ago|reply
[+] [-] meaty|13 years ago|reply
[+] [-] derpmaster|13 years ago|reply
MS wants to copy everybody with an app and game store, which will be the only authorized way to download and install anything on to windows 8+
They also want to charge 30% to any vendor that wants to sell in their store. Since game makers like Steam have their own content delivery system which will be blocked by MS they already panicked and announced a new linux client and have claimed to be committed to switching everything over the next few years and dumping windows