That was not the point of my post. My point was that we are getting Linux games and GOG still refuses to acknowledge our space.

There are GOG games that have Linux ports and GOG just pretends they don't exist. This has nothing to do with Steam for me. It has everything to do with recognition. Dosbox, SCUMMVM, actual Linux game ports like the Humble bundle ports, etc.

That depends on the platform and approach which developers chose. Take for example OpenGL - it's cross platform. Choose Direct3D - it's already MS lock-in. Given that developers might prefer Direct3D on Windows, when they want to be cross platform, they simply implement both options or avoid locked-in ones to begin with to reduce duplication of effort.

Same thing can be said in the context of Steam which Fenixp brought above. Some feature from there can be very useful, but if developers what to avoid lock-in, they need to make that feature plugabble, to be able to replace it with alternative when the game doesn't rely on Steam. Saying that "Steam is a must" is akin to saying that Direct3D is a must, or lock-in is the only way to go.

Sure, that's why it's probably better to watch for new examples of Linux games that are really DRM free and not tied to one distributor. That will show that GOG ignores them without a valid reason.

There are several examples of games already available on GOG.com that have native Linux versions but only the Windows/Mac versions are offered on GOG. One such example is Strike Suit Zero. It's kind of strange (especially considering Linux users' general low opinion of DRM) how these games are readily available DRM-free on Windows and Mac, but the native Linux versions are only available with DRM.

Well, it's a good thing you're the only one who said that in this particular discussion ;-)

Fenixp: Did you change your mind? I'm glad. I don't find Steam-only idea for whatever potential "saving" to be reasonable.

There are lots of games that uses DosBox on GOG. I would really like to have them avaliable on Linux as well, without the Windows installer.

I like how your ability to spin what I say to be 'right'. I'm not sure why are you doing it (both saying that I have implied that you can't develop game without Steam - I have quite literally said the contrary, and that's not the only time I did - and that I have changed my mind even tho I'm clearly referring to a discussion that has taken place already), but it really, really weakens your argument when you're unable to come up with anything constructive to say and base your following posts on something that has never been said in the first place by anyone but you. It is a common behavior of people who know they're wrong but continue to oppose regardless tho, so it could just be that. Or you're just trolling. At any rate, if your goal is to persuade people that they need to stop using commercial dependencies - I'm fairly sure precisely the opposite happened.

That would be nice, but it's a mere convenience. You can unpack them with innoextract without installing. Also, config files to run the games with DosBox will have to differ for Windows and Linux. But GOG can easily package both variants in the same archive of course.

Fenixp: You either didn't express what you wanted clearly, or I didn't understand it clearly. Since from what you said, it was easy to conclude that you view development without Steam lock-in features to be too costly for developers, and you welcome Steam-only approach based on that. If you never meant that developing without Steam is not possible or not advisable - then good.

That's not what he said. Just that it is practical and removes a lot of headaches for developers that want multi-player code that is mature, easy to use and plain works. All they are doing is not re-inventing the wheel. It is akin to develop an alternative to direct-x / open-gl from the ground up, just to not be 'locked into' third party technology that's available at no cost. No-one does that. It'd be harebrained. If there'd be a similarly mature alternative to Steam net-code out there your argument may make sense. As is - it's logical why an increasing amount of developers go down that route.

Given just how much of a market share steam has they are not (massively) creating a disadvantage for themselves, especially since Steam (and with that steam net-code) now runs on all three major OS. If GOG and alternatives had an equal slice of the market share the situation may be different; they don't though. Steam is more than a shop for developer purposes - unlike GOG.

So yes, developing without Steam is possible - there just aren't many advantages from a business and project management perspective to do so, at this point. Remember that games still make the large majority of their profit early in their schedule - the long-term consequences are, financially, far less important.

You're probably right. It's a rational business decision, although a bit shortsighted and maybe underestimating the potential sales outside of Steam.

But if I would be a developer I would develop separate from Steam because I would not see them as a service that is widespread and low cost but as an additional plattform that will sooner or later restrict my income. No sense in having too many layers on top of the OS layer.

Well, good news is that you can actually get the best of both worlds. You can develop your software with Steam in mind, code your application so the Steam API can be easily replaced (i. e. - write your game with this goal in mind as well) and then, once you get income from Steam sales and experience from making the game come true, you can focus on developing a stand-alone version if you think it's worth it. This approach really shouldn't add that much to the development time and you can make an informed decision whether or not it's worth your time to strip your game of Steam (and have a back-door open in case Steam ... eh, stops)

Ye. Situation is different for 'AAA' developers than Indies, though, I'd guess. Given the time constrains and financial pressures big budget developers are under I don't really think they have that much choice. As I said - it's not the only library they fall back on - from graphic libraries to physics to licensing whole engines. They have a contract to fulfil and depend on doing so promptly - not just for the current project but to be seen viable and good investment for those in the future. Any business that acts as a contractor for external agencies that supply the funds has to jump through loads of hoops to remain viable.

Valve played this smart from early on. Offering a DRM package appealed to publishers (and developers) - developing a solid netcode API and similar features with Steam draws in developers more closely.

[Plus what Fenixp said - that requires smart planning at an early stage of development - and I am not sure that games development always follows a solid, smart, coding practise.]

It doesn't actually, your code can be a mess as long as it's reliable and you take special care to do the 'replaceable' bits properly. 'Reliable' being the operative word here, if it suddenly explodes when accepting communication from another source, you screwed up terribly somewhere :-P

:). Haven't seen any game code, but knowing the buggy mess the products tend to be when released I wouldn't put much faith in reliability. OTOH how quick pirate / hacking groups tend to pull out DRM and create something that still works I might underestimate game code robustness ....