What Should Valve Do For Linux & Open-Source?

[johnc]

On the contrary, Humble Indie Bundle have shown that Linux users pay on average more than Mac and Windows users do for the bundle.
Linux users payed twice as much as Windows users!

I wonder if those numbers are kinda skewed though. I think median is a better metric than average.

[kazetsukai]

In case you're all completely oblivious.... I hope you realize that what Valve is doing (in total) is completely without precedent. From what I can see, they're all-in, and really ready to make this a success.

Lets imagine something: Valve succeeds and brings Steam to Linux. Through hard work, it runs on most distros (as well as the games)....

Valve will have then created cross-distro application management, something that no package manager has really done in any capacity. Yeah yeah, whatever you say. Make no mistake: they have BIG opportunity here. I think we have to see some of the motivating factors behind this to understand where they're coming from: Next year, Microsoft is their competitor. Valve is going to be in the uncomfortable position of being in competition with not just (the platform they run on)'s company, but the platform itself. Windows, and its built-in Windows store, is Valve's competition. Linux, and the Linux desktop has no conflict of interest there. This landscape has been building since the inception of the xbox... Microsoft started becoming a major player in the publishing business (which also increased its presence as a publisher on Windows) and here we are.

Now, we're at the brink of a huge paradigm shift... evidenced partially by the OUYA and Valve's jump (LEAP!) to Linux, some big changes are happening. As casual gaming gets more and more heavily emphasized, the traditional gaming gap widens, and new players arrive. That's what happens when demand stays high and supply abruptly cuts off in favor of industry gimmicks like 3DTV, motion control and touchscreen gestures. "Is that an iPhone?"? Have any idea how sick iAmOfHearingThat??

In a nutshell... if successful, Linux is the future of gaming. That's what Valve thinks, and Valve's goal is Linux gamers: lots of them. Look at what they're doing, do some google-fu and tell me: Has anyone (in their position as a major, established game publisher and distribution service) ever done the things they are doing, with that kind of haste? These people are RUNNING, not walking, to Linux.

[1c3d0g]

+1, I agree 100%, A+++, QFT, well fucking said, kazetsukai!

[gamerk2]

The investment is not only for Linux, because Mac OS X uses OpenGL too. As does Android, Wii, PlayStation, etc.

First up, the Wii and PS3, while containing OpenGL ES API's, do the majority of their graphic processing via low level system API's. In the case of the PS3, PSGL is little more then a wrapper around their libgcm graphical library anyways.

Its understood that any port between the PS3, 360, and PC will have to have its graphical processing engine re-written for each platform. Just because the PS3/Wii have OpenGL API's does NOT mean you can just plop what you have into a Mac/Linux OS.

[And yes, I make the same point when the PC fanboys go "DX on consoles is holding us back".]

Also it doesn't necessarily mean more staff, just be smart and use cross-platform APIs from the start.

Inefficient. If that were the case, everyone would be using POSIX specifications, which I believe we can all agree shouldn't be done.

When coding on windows, when performance matters, we use Windows native types for everything: TCHARfor a character constant on a Windows OS, CString is preferred even to std::string, due to the ability to case natively to LPCTSTR. And so on and so on.

On the contrary, Humble Indie Bundle have shown that Linux users pay on average more than Mac and Windows users do for the bundle.
Linux users payed twice as much as Windows users!

Beware the small sample size.

Unigine, Unity, id Tech and soon Source Engine are all available on Linux.

Has Unigine been used to create an actual game yet? Last I heard, ID Tech 5 wasn't going to be licensed out by ID, and Source, while very efficient and modular, has its own limitations [not top-tier graphically, doesn't scale well beyond 4 cores]. Very good engine for a smaller company like Value though.

[gamerk2]

When it comes to porting games to Linux, there are basically two options a company can take. For the purposes of this discussion, I'm going to assume that the company in question lacks any Linux staff to start.

Option 1:

Port the game from Windows to Linux. Obviously, the graphic engine would have to be re-written to OpenGL, all the Windows code ripped out, everything run through testing, and tested against multiple kernel/distributions to ensure proper compatability. So figure at least 6 developers at a cost of $50k + benefits, over a year, plus a long term support staff of the same number at the same price for about two years. So figuring about $150k per worker per year of work (benefits, remember?), you come out to ~$900k for development and $1.8 Million for long term support. That equates to $2.7 Million in extra personel costs.

Figuring the game in question sells for $60, lets assume sold to retailers at a profit of $45 per license sold. So to break even, you would need to sell, at a minimum, 60,000 units above what would normally be purchased. (I can't stress that point enough). And that assumes full price of sale. Taking development time into accounts, users may be expecting a lower price at release, which would increase the number of required units to reach break even.

Option 2:

Let the users run the game through WINE, at no extra cost, and with no responsability for any bugs that occur because its an "unsupported configuration"


I'm a manger looking to maximize profit for my next promotion. Which option do you think I'm picking? WINE itself is a major incentive NOT to undergo native Linux ports.

[kwahoo]

At 2008 GDC Valve showed a presentation about Source as multiplatform (Windows/PS3/X360) engine.

Porting Windows->consoles (especially PS3) is a very hard task. Low memory, slow storage, in-order CPU etc.

[KameZero]

Option 1:

Port the game from Windows to Linux. Obviously, the graphic engine would have to be re-written to OpenGL, all the Windows code ripped out, everything run through testing, and tested against multiple kernel/distributions to ensure proper compatability. So figure at least 6 developers at a cost of $50k + benefits, over a year, plus a long term support staff of the same number at the same price for about two years. So figuring about $150k per worker per year of work (benefits, remember?), you come out to ~$900k for development and $1.8 Million for long term support. That equates to $2.7 Million in extra personel costs.

From your calculations here I can only assume that you're fully splitting your codebases between Operating Systems, and hiring substandard developers. Even for a large AAA game, it shouldn't take more than ONE good developer to port it given a years time. Hell, 900k just for the porting part? Just hire Icculus, he'll have it done in 3 months and then you can hire a linux dev to support it thereafter.

You're windows devs shouldn't be writing code that can't be used crossplatform. And most don't because they like being able to port to consoles.

[johnc]

Hire me, I'll port it.

But this is why I think we'd really need a Linux-based Steam console of sorts to really get anywhere. I foresee us being in a similar situation to Mac users... we'll have the Valve games plus a lot of indie-type and smaller games. Many of the bigger names won't bother and so people will be forced to stay on Windows as their one-stop gaming platform.

Which is why Valve jumping headlong into Linux doesn't make sense to me from a business perspective (outside of a console option). They might be doing it for hobbyist / "it seems like an exciting thing to work on" reasons but those aren't ultimately enough to significantly change the gaming landscape on Linux. (Or, at least, not make it any more advanced than what is on Mac today.) But casual and indie gaming is becoming increasingly popular so maybe that's all that really matters.

[Veerappan]

Port the game from Windows to Linux. Obviously, the graphic engine would have to be re-written to OpenGL, all the Windows code ripped out, everything run through testing, and tested against multiple kernel/distributions to ensure proper compatability. So figure at least 6 developers at a cost of $50k + benefits, over a year, plus a long term support staff of the same number at the same price for about two years. So figuring about $150k per worker per year of work (benefits, remember?), you come out to ~$900k for development and $1.8 Million for long term support. That equates to $2.7 Million in extra personel costs.

Figuring the game in question sells for $60, lets assume sold to retailers at a profit of $45 per license sold. So to break even, you would need to sell, at a minimum, 60,000 units above what would normally be purchased. (I can't stress that point enough). And that assumes full price of sale. Taking development time into accounts, users may be expecting a lower price at release, which would increase the number of required units to reach break even.

I think you're over-estimating costs a bit here. First, estimates of overhead costs I've seen put the number at closer to 145% of employee wages, and that's for a production facility paying $10/hour. That overhead will go down as a percentage as employee wages go up (the life/health insurance won't go up, but 401k and maybe disability will). I'd say that it's probably closer to $112k per developer.

I don't know who gives full development-stage staffing to long term support as well. Either you'll cut that number by 1/2, or you'll be getting subscriptions or putting out DLC/expansions to give the developers something to do beyond bug fixes and patches. Any game that has made it through to release and gotten its first patch shouldn't require the same number of developer hours as a game in development... At least that's the way that stuff works here (not game software, but it's still commercial software development).

I'd also like to point out utilities like MojoShader. They can't do the full job of porting your shaders and API calls to OpenGL, but between that, using something like OpenAL or SDL, and other cross-platform APIs, you can reduce the development time that would be required if you decided to scrap the entire renderer and re-write it in OpenGL from scratch.

Porting a AAA title from DX9/10/11 is still going to be expensive, I'm not denying that. But I think you've over-estimated the expenses a bit... Although if you're not talking of a simultaneous Windows/Linux release, you've also overestimated the sales price that can be expected (which you alluded to).

[1c3d0g]

When it comes to porting games to Linux, there are basically two options a company can take. For the purposes of this discussion, I'm going to assume that the company in question lacks any Linux staff to start.

Option 1:

Port the game from Windows to Linux. Obviously, the graphic engine would have to be re-written to OpenGL, all the Windows code ripped out, everything run through testing, and tested against multiple kernel/distributions to ensure proper compatability.
...

None of this is relevant if the developers did their job right the first time. If they wrote the game conforming to the specs of OpenGL (instead of DirectX), you'd instantly eliminate most of the hassle of porting (as OpenGL is multi-platform and does not suffer DirectX's platform tie-in). Professional companies like Epic have done this way back then with UT2k4 (yes, I know it had 2 renderers, but both were equally capable), and it became one of the biggest, most-played (I'll say the best) game of all time. All-in-all, this will be a huge boost for OpenGL as they're already the standard when it comes to professional applications like CAD etc. Now that more games will be rendered using the OpenGL, we as Linux users have nothing to fear, we can only gain more users and better support from larger companies, which will make Linux a viable platform for gaming.