- 0 Posts
- 6 Comments
But they aren’t tied to a store? When you download a game from Steam, it’s just an executable on your box. You could put it on a hard drive and move it wherever you wanted. You don’t have to launch games you bought with Steam through Steam. They aren’t streamed. They are saved locally to your computer.
You can only download it from that store, sure, but that’s not apples to apples. If I buy a game from GameStop, they won’t give me another copy for free, just cause I threw away the copy they gave me. Once you download the game, that’s what they sold you, and it’s notionally your responsibility to keep track of it. Them allowing you to keep downloading new copies forever isn’t strictly necessary, and costs them money every time you do it.
And if you can run the games you downloaded without Steam, all you’re saying is “there should be other places to buy your games.” But there are. Those exist. Less people use them, sure, but what do you propose? Kill Steam because too many people use it to buy their games? Legislate that people are required to shop at other stores?
But this game is getting distribution through GoG and about a half dozen other platforms listed in the article.
Do most people game through steam? Yes. But centralization of the marketplace isn’t necessarily a bad thing. There’s a reason why people complain when they have to use other game stores an launchers. It’s the “I have 50 different streaming services” problem.
If Steam starts abusing that market position, then yes, we should care about that and they should suffer backlash. Which makes the question of “did they do the right thing here,” very much relevant.
I think there’s several reasons for that, not the least of which is that you can’t distribute python bytecode.
With java, I run through an intentional compilation step and then ship the jar file to my consumers. I’d never ship a .pyc to the field.
In python (specifically cpython), that step is just an implementation detail of the interpreter/runtime.
If you ever used something other than the default python interpreter, it probably wouldn’t implement the same bytecode subsystem under the hood. Python bytecode isn’t part of the spec.
Sure, many games are tied to various Steam services, but that’s by the choice of the games developer. Steam offers various built in services that game devs can choose to use if they want. It’s not like it’s some kind of requirement.
You might as well complain that game devs use Windows binaries, locking their games to only run on Windows. Sure, I prefer it when they target other platforms, but that’s 1000% not Microsoft’s fault that the dev chose to dev for their platform. I’m not mad at Microsoft for so many games being Windows only. I’m mad at the devs.
And games that build themselves around Steam services are of course going to be tied to Steam. That’s a choice the devs made. If they wanted their game to run without needing the Steam client, they trivially could have built it that way. They just would have had to either reimplement all those Steam features themselves, or done without.
And if people want those Steam features, every store client who wants to run those games would have to implement those features in an interoperable way. It’s easy to say “have interoperability between clients,” but that’s glossing over the potentially thousands of dev hours required to implement all of the features needed. And that’s assuming they could all agree on a spec.
And to your final point about being open source. First, it gives very “any musician who gets paid is a sellout” energy. But more than that, it doesn’t actually solve the problem you have. Even if Steam open sourced their tooling, that doesn’t mean other players in the space could integrate it. Steam has grown organically for the past 30yrs, and trying to extricate the deep inner bits and then graft them on to your own solution isn’t as easy as it sounds.