Linked by boldingd on Tue 29th Jan 2013 23:12 UTC
Games It seems to have so far escaped OSNews' notice (if the top few hits for a site-search for 'Steam' is any indication) that Steam for Linux is now in Open Beta; you can get the Linux steam client from steampowered.com. So far, they appear to only be making an Ubuntu .deb available, and the client will require closed-source GPU drivers in order to work.
Thread beginning with comment 550826
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by Wafflez
by Ravyne on Wed 30th Jan 2013 03:38 UTC in reply to "RE[2]: Comment by Wafflez"
Ravyne
Member since:
2006-01-08

That's the way things go when people (i.e. iD) go down that route, however there are other issues with releasing the source to AAA games.

Firstly, the industry competes fiercely on technology, and licenses their engines and tooling for 10s of thousands, or even millions of dollars.

Secondly, any major AAA game engine also supports consoles, and there's a legal liability if they expose any portion of the SDK. They could do a lot of work factoring out and removing #ifdef XBOX's, maybe even treating the cleaned source code as another build target, but that's rather a lot of work for little gain. More so to retrofit it. You might have to not include any version-control history either, lest comments reveal secrets.

Then there's the overhead of accepting upstream patches, and telling contributors that, no, we can't take your patch because it doesn't work well with the secret stuff we can't disclose to you, and we can't provide any more than the vaguest of hints to redirect you, because you could then infer super-secret stuff we can't tell you and Legal will have our asses.

Honestly, a better approach is to go the other way around -- begin the project entirely open source, and then treat yourselves as a third party using the code-base. However, you still have problems forcing the codebase to be console-friendly without maintaining a whole lot of private code replacing things whole-cloth, or just branching entirely.

Really, the whole thing idea falls apart when you touch closed platforms (which is not a rebuke of consoles, just an observation.)

You can't even really point to iD's releases as a model, as iD itself isn't really actively looking to FOSS contributors to provide iD with upstream patches. Their source code releases are essentially gifts to the community and insurance that their games will remain playable into the future.

Reply Parent Score: 1

RE[4]: Comment by Wafflez
by WereCatf on Wed 30th Jan 2013 05:45 in reply to "RE[3]: Comment by Wafflez"
WereCatf Member since:
2006-02-15

Then there's the overhead of accepting upstream patches


The engine can be open-source even without the developers accepting any upstream patches at all. Accepting such is not a requirement.

Really, the whole thing idea falls apart when you touch closed platforms (which is not a rebuke of consoles, just an observation.)


You could always place the console-specific portions in separate header - and code - files and use ifdefs, and as such, that's not really as big of an issue as you would seem to believe. It is some extra work, but not much -- especially so if you plan the code-base accordingly from the get-go.

Reply Parent Score: 5

RE[4]: Comment by Wafflez
by tidux on Fri 1st Feb 2013 17:46 in reply to "RE[3]: Comment by Wafflez"
tidux Member since:
2011-08-13

> Secondly, any major AAA game engine also supports consoles, and there's a legal liability if they expose any portion of the SDK.

Why do console OEMs do this? Do they think that restricting access to the SDK will provide MORE good games?

Reply Parent Score: 2