Kilku użytkowników Reddita zauważyło, że w ostatnim czasie firma Valve zaczęła usuwać ikonki zgodności ze SteamOS z niektórych gier. Jednymi z poszkodowanych okazali się deweloperzy gry Starbound, którzy szybko napisali do firmy z pytaniem, o co chodzi. Odpowiedź dostali jednak na Reddicie, po wrzuceniu informacji o takim kontakcie. Okazuje się, że Valve poczyniło takie kroki z powodu zewnętrznych zależności, np. w postaci bibliotek. Według firmy gra powinna działać od razu po zainstalowaniu i nie prosić i nic dodatkowego do pobrania.
Sytuacja jest o tyle dziwna, że na systemie Windows praktycznie każda gra doinstalowuje swoje zewnętrzne biblioteki, choćby DirectX i Visual C++ Redistributable. I jakoś w tej kwestii firma nie usuwa zgodności z Windowsem.
We’ve been removing the store bit from games that cannot run against just the Steam Runtime, without additional dependencies on the host system. Games that fail this are impossible to support reliably across multiple distributions, and will not be publicly advertised on the Store as supporting Linux going forward.
All concerned games are still purchasable, installable and playable on Linux.
To my knowledge all developers have been made aware as we were doing this, let’s chat on Monday.
Tylko, że pod Windows instalowaniem tych rzeczy zajmuje się infrastruktura Stream.
Pod Linuksem to trudne. Liczy się tylko ABI runtime Steam, reszta zależności nie wiadomo skąd nie daje gwarancji działania.
„Sytuacja jest o tyle dziwna, że na systemie Windows praktycznie każda
gra doinstalowuje swoje zewnętrzne biblioteki, choćby DirectX i Visual
C++ Redistributable.” Tyle, że w wypadku systemu Windows biblioteki te są zawsze ze sobą zgodne i łatwo przewidzieć ich działania. W wypadku systemu Linux problem się może pojawić, ze względu na instalacje klienta Steam na zróżnicowanych dystrybucjach (inne kernele, inne repa, inne wersje bibliotek). Nie wiem czemu producenci softu na Linuxa mają taki problem kompilowania zbiorów statycznych z wbudowanymi bibliotekami, co rozwiązywało by wiele problemów.
Statyczne linkowanie jest zabronione przez licencję, ale i tak wrzuca się całego bundle’a ze skryptem uruchamiającym i używanymi bibliotekami, a to nie jest zabronione. Jeszcze nigdy nie miałem problemu z niekompatybilnością, której nie dało się załatwić wrzuceniem .so w odpowiedniej wersji, a w ciągu tych moich 7 lat pracy na Linuksie dotyczyło to tylko raz archaicznego GTK i może 3 razy glib’a.
I dobrze, przynajmniej mam pewność, że aplikacje na steamie nie zaśmiecą mi systemu. Jak deweloperom nie wystarczy Steam Runtime to niech linkują statycznie a nie jakieś pobieranie dodatkowego softu, chyba im się systemy pomyliły.
Potem będziesz płakał, że pod Waylandem, czy innym wymysłem ci nie działa.
Twórcy gry nie muszą istnieć do końca świata.
~10 min. roboty. Nie muszą istnieć do końca świata, jak gra będzie działać na najpopularniejszych w danym momencie rozwiązaniach, to potem, ile by się nie zmieniło bez (większego) problemu będzie się ją dało odpalić. Zresztą po to jest Steam Runtime, niech go używają to nie będzie problemu, gdyby nie SR takie programowanie gier na Linuksa byłoby mordęgą, uwzględniając mnogość dystrybucji.
Jakoś wcześniej developerzy (tacy jak S2) nie mieli z tym problemu: zwykły instalator w .sh czy .bin, aktywator uchuchamiający skrypt ustawiający ścieżki do swoich bibliotek i uruchamiający odpowiednią binarkę dla danej architektury. Wszystkie zależności rozwiązane lokalnie. Przy gierce ważącej 2GiB te 40MiB bibliotek to niewielki koszt.
Raczej były inne przypadki – bywało, że gra XYZ działała z pudełka na distrze X, a na Y sypała błędami (dla mnie, przykładowo Prey czy Unreal Tournament ’99).
Bywało też, że trzeba było trochę pokombinować z binarkami, bo na dołączonych gra nie odpalała, przykładowo sypiąc błędami (np. Shadowgrounds). Często rozwiązaniem była instalacji biblioteki w systemie, usunięcie tego samego libsa w katalogu z grą i… gramy :-)
Steam Runtime sprawia przynajmniej, wersja natywna działa na Linuksie, a nie najlepiej na wybranych dystrybucjach (lub nim zagramy, trzeba wcześniej pokombinować). To jest pewne ujednolicenie. Strasznie wspominam tutaj Desurę, bo nie wiem jak dziś – ale dawniej wiele gier wymagało najpierw rozwiązania problemów z uruchomieniem, bo albo brakuje libsów, albo inny problem do rozwiązania. To użytkownik musiał zadbać, aby gra się uruchomiła.
Oczywiście nie jest tak, że wszystkie dawne gry się krzaczyły. Ale nie czarujmy rzeczywistości – czasem nim tytuł odpalił, należało poszukać how-to w sieci ;-)
Jeśli nie wiadomo o co chodzi to chodzi o SteamOS – to ma być przecież coś w rodzaju konsoli, doinstalowywanie dodatkowych i akrobacje z tym związane są trochę bez sensu, obsługa innych dystrybucji jest IMO efektem ubocznym.
Szczerze? To ma sens. Od strony użytkownika – to ma być a’la konsola, gdzie jest jak najmniej Linuksa w Linuksie.
Inna sprawa, że ikonki mogli zostawić – choćby dla lepszej identyfikacji natywnych tytułów. Ale – zrobili jak uważali za słuszne :-)
Racja. Mogliby też dodać dodatkową ikonkę dla gier wspierających Linuksa/SteamOS, a ikonkę zgodności ze SteamOS stosować zgodnie z bardziej rygorystycznymi wymogami. Może trzeba przesłać im taką sugestię.
A co wam nie pasuje w tym, aby gra pobierała własne biblioteki i właśnie z nich korzystała?
Bo użytkownik nie musi wiedzieć jak doinstalować bibliotekę, o którą prosi gra. Płaci za produkt w sklepie i produkt powinien działać out of the box. W innym przypadku problem spada na support, który ma dodatkową robotę i pewnie najczęściej jest to support Steam. Dodatkowo to kwestia wizerunkowa w przypadku instalacji i próby uruchomienia gry na SteamOS/SteamMachine – no jak to nie działa, jak to czegoś brakuje, mam dedykowany system/urządzenie i musi działać…