This is a continuation of #806, clearly you are not satisfied with the response given there.
Yes, because I think this problem should be approached from the Steam side and extended for a generic situation where a game executable is not a binary for some Steam-supported OS.
Shouldn't this be up to the developers of the individual games?
No, it shouldn't. They usually just don't care. A shared DOSBox depot will solve this problem.
Btw, what about publishing free games and tools in Steam? Can we greenlight DOSBox as a standalone tool and some open-sourced DOS game (Beneath a Steel Sky seems to be a good choice) to test a solution with DOSBox mounted as a shared depot?
On Nov 16, 2013 3:03 AM, "Eugene Shatsky" [email protected] wrote:
No, it shouldn't. They usually just don't care.
—
Reply to this email directly or view it on GitHub.
They would definitely use a multiplatform environment if one was given to
them.
Also, this would improve stability and reliability while reducing download
size by removing the duplicate runtime.
However, because developers have trouble understanding that 1% of potential
users on a game that sells 100 million copies is 1 Million lost sales.
So that's what it can look like with current depots/configs concept, if I got one right:
Who does depot management and launch config writing, Steam- or publisher-side devs? If first ones, it simplifies the situation; if second, this means that publisher still has to take a step to enable new platforms.
Can there be a multi-OS depot?
Can a problem of different commands for platform-specific executables in the launch config be solved? Maybe, an embedded platform-independent pseudo-shell inside Steam? (one dosbox.sh to rule them all)
Depot management is per-steamworks dev, so either publisher or porter controlled. For some libraries like DirectX on Windows, devs can use valve supplied content, but those are /standard/ win packages with only a few iterations.
DOSBox is a rather more complicated beast, and the reply you got in #806 should stand. If you wish to encourage more dosbox using publishers to adopt multiplatform content, contact them and/or take up dosbox development :)
That's debatable.
I think that making DOSBox available as a publisher-ready tool will largely
increase the rate of positive publishers reactions to such requests.
And Steam itself will have to face the concept of compatibility layers,
sooner or later. With the current case, I imagine something like oslist=dos
launch commands which tell Steam to invoke DOSBox automatically and
transparently to the publisher.
Btw, why do you say that DOSBox is "complicated"? It's a polished,
self-sufficient tool which works well on all current Steam platforms.
My thought exactly, and if steam publishes the kit, they can make it
compliant with steam cloud sync and steamplay.
On Nov 27, 2013 4:09 PM, "Eugene Shatsky" [email protected] wrote:
That's debatable.
I think that making DOSBox available as a publisher-ready tool will largely
increase the rate of positive publishers reactions to such requests.
And Steam itself will have to face the concept of compatibility layers,
sooner or later. With the current case, I imagine something like oslist=dos
launch commands which tell Steam to invoke DOSBox automatically and
transparently to the publisher.Btw, why do you say that DOSBox is "complicated"? It's a polished,
self-sufficient tool which works well on all current Steam platforms.—
Reply to this email directly or view it on GitHubhttps://github.com/ValveSoftware/steam-for-linux/issues/2987#issuecomment-29420346
.
Currently, there is a number of DOS games in Steam which are supplied with Windows-only DOSBox by publishers and are only available for Windows. That does not make any sense. Publishers are often uninterested in making their games available on other platforms, so relying on them is a dead end. Steam should provide a common DOSBox (and, possibly, other multi-platform runtimes - e. g., Flash), and such games should be adapted for it and made available on all platforms supported by these runtimes.