2014-11-20 10 views
9

Jestem niezależnym programistą gier działającym na platformie Windows, ale mam praktycznie zerowe doświadczenie z Linuksem i wdrażaniem aplikacji. Intryguję moją grę napisaną w C++ '11 opartą na SDL 2.0 z kilkoma innymi zależnościami międzyplatformowymi (jak AngelScript lub PugiXML) na Windowsie i chcę ją również rozpowszechnić na Linuksie i mam kilka pytań na ten temat. Gra jest komercyjnym, zamkniętym źródłem, które jest obecnie na platformie GreenLite, ale chcę rozpowszechniać bezpłatną wersję alfa do pobrania z mojej strony internetowej, niezależnie od statusu GreenLite.Rozmieszczanie gry w C++ w Linuksie

1.) Czy główne dystrybucje Linuksa ABI (interfejs binarny aplikacji) są kompatybilne? Czy muszę skompilować moją grę na każdej obsługiwanej dystrybucji/platformie?

2.) Jeśli tak, to które dystrybucje/platformy są rozsądnymi opcjami do wsparcia?

3.) Jaki jest najlepszy sposób instalacji aplikacji i jej zależności w systemie Linux? Czytałem o systemach deb i rpm, ale nadal jest to mylące - czy istnieje sposób automatycznego generowania pakietów instalacyjnych dla różnych dystrybucji?

4.) Jak Steam współpracuje z Linuksem? Jak mam przygotować moją aplikację do dystrybucji za jej pośrednictwem?

Przepraszam jeśli pytam niewłaściwe pytania, cały świat Linux jest całkiem nowe dla mnie i zgubiłem czytając różne artykuły i strony podręcznika ...

Odpowiedz

2
  1. To zależy od tego, co pochodzi dystrybucja od. Zasadniczo, nie ma potrzeby rekompilacji programu na systemie podobnym do Ubuntu w Fedorze, o ile kod pozostaje niezmieniony. Ponieważ Ubuntu i Fedora musiałyby używać tych samych bibliotek (choć prawdopodobnie w różnych lokalizacjach) i wszystko, co związane z OpenGL byłoby problemem dla kierowcy; dlatego nie jest wymagana ponowna kompilacja oprogramowania. Byłbym bardzo zaskoczony, gdybyś musiał przekompilować swoje oprogramowanie, ponieważ wszystkie dystrybucje używają prawie tego samego zestawu bibliotek/dostają bash/używają jądra Linux, ale mają różnych menedżerów pakietów. Ostatnią częścią jest złożenie:

  2. Powyższe dystrybucje mają różnych menedżerów pakietów, co wymaga odpowiedniego przepakowania oprogramowania. Możesz uwolnić skompilowane pliki binarne pod plikiem tar.gz i po prostu mieć opiekunów dystrybucji pakiet oprogramowania; Jeśli jednak chcesz kontrolować dystrybucję swojego oprogramowania, powinieneś lepiej zrobić to samemu. Z powodu tego problemu związanego z wieloma menedżerami pakietów, ludzie wciąż uciekają się do rekompilacji kodu źródłowego poprzez plik make, który można wygenerować za pomocą cmake. Dzieje się tak tylko wtedy, gdy pewne zależności są z jakiegoś powodu "przemianowane", w którym to przypadku z powodu prostej zmiany nazwy program magicznie nie znajduje zależności. Ponieważ nie ma również konwencji nazewnictwa, nawet życie staje się trudniejsze. Najważniejszą zaletą jest tutaj Trust i Trust, aby programiści stosowali konwencje nazewnictwa, aby każdy mógł odwoływać się do tego samego pakietu o tej samej nazwie.

Najlepsze dystrybucje do wsparcia są najbardziej popularne: Ubuntu i openSUSE będą świetnymi punktami wyjściowymi. Linux Mennica, Fedora i Red Hat oraz Debian korzystają z menedżerów pakietów, podobnie jak wyżej wymienione.

  1. W międzyczasie powinieneś wiedzieć, że nie możesz statycznie połączyć kodu GPL w swoim oprogramowaniu, nie robiąc również oprogramowania GPL. Sposób obejścia tego problemu ma na celu rozwiązanie zależności przez: A. Uwzględnienie odpowiednich zależności w tym samym folderze co plik wykonywalny (podobnie jak * .dlls w systemie Windows) lub w zależności od systemu, na którym uruchamiany jest twój program, aby zajrzeć do środka te same katalogi, na które program się zajrzał podczas kompilowania i łączenia. Ta ostatnia jest bardziej ryzykowna, ponieważ zakłada, że ​​użytkownik będzie miał biblioteki i nie będzie modyfikowany. Ten pierwszy sprawi, że twoje ogólne oprogramowanie będzie zużywać mniej pamięci, ale uwzględnienie zależności będzie oznaczało tylko zwiększenie rozmiaru pakietu, ale zapewni spójność we wszystkich systemach.

Do instalacji potrzebny jest plik wykonywalny bash, który przenosi zawartość katalogu do właściwych lokalizacji. Zasadniczo główna aplikacja przechodzi do/usr/bin, a wszelkie dane związane z aplikacją trafiają do folderu domowego. To znowu zależy od dystrybucji; Szukam .lokalny katalog lub możesz utworzyć katalog dedykowany dla aplikacji, która jest ukryta. Ukryte foldery są poprzedzone kropką. Po co umieszczać te rzeczy w katalogu domowym i co? Powód: ponieważ folder macierzysty domyślnie daje wszystkim uprawnienia do odczytu i zapisu dla wszystkich. Co: wszystko, co musi być uruchamiane z aplikacją, bez konieczności autoryzowania przez użytkownika. Zależności powinny więc znajdować się w katalogu domowym, najlepiej pod własnym katalogiem. Następują różne konwencje; niektórzy mogą nie zgadzać się ze mną w tej sprawie.

Możesz również użyć funkcji API Steam, która wykonuje większość tej pracy. W wersji Steam Twoja aplikacja może znajdować się w katalogu własnym Steam i tym samym działa jako aplikacja Steam z pełną funkcjonalnością.

http://www.steampowered.com/steamworks/

Aby dowiedzieć się więcej o tym, jak dostać swoją aplikację na parze. Muszę powiedzieć, że byłem naprawdę pod wrażeniem, a nawet zawierają próbki kodu. Najlepsze jest to, że to API jest również w Linuksie. Nie wiem zbyt wiele poza tym, że Steam będzie obsługiwał wykonanie twojej aplikacji przez własną warstwę. W takim przypadku nie ma potrzeby niezależnego rozpowszechniania aplikacji w poprzednich krokach.

Pamiętaj, że możesz również rozpowszechniać swoje oprogramowanie za pośrednictwem Centrum Oprogramowania Ubuntu, jeśli jesteś zainteresowany.

http://developer.ubuntu.com/apps/

Chociaż Ubuntu ma bardziej skupić się na aplikacje uruchomione niezależnie od platformy.

Wiedz, że Linux nie ma jednej konwencji, ale jego konwencja jest po prostu wyprowadzona z pragmatyzmu, a nie z teorii. Podsumowując, sposób, w jaki oprogramowanie ma działać w systemie Linux, należy do Ciebie.

+0

Dziękuję, to zdecydowanie najlepsza odpowiedź tutaj - jeszcze jedno pytanie: jeśli będę przechowywać zależności w katalogu 'home', to czy będą one dostępne dla wszystkich użytkowników? Czy aktywa powinny być również przechowywane w 'home'? – PiotrK

4

Nie jestem programistą gry i pochodzę z społeczność open source, więc nie może naprawdę doradzać w dostarczaniu plików binarnych. Postaram się odpowiedzieć na niektóre z twoich pytań:

Valve ma runtime, do którego możesz kierować na linuxie (https://github.com/ValveSoftware/steam-runtime) - byłby to najlepszy sposób na przeniesienie twojej gry. Widziałem, jak wspomniano o tym w jednym z ich filmów na temat YouTube'a na youtube. Rozumiem, że jest to pakiet bibliotek, w których SDL jest osadzony i który ma emulować określoną wersję Ubuntu. Jeśli więc napiszesz swoją grę przeciwko środowisku uruchomieniowemu, uruchomi się ona w dowolnej dystrybucji Linuksa, w której również przeniesiono parę.

chodzi o natywnie pakowania gra jedną rzeczą do rozważenia jest, jeśli pakiet go jako deb lub rpm i instruować go zależą distro warunkiem libraies niż aplikacja może pęknąć, gdy biblioteki są aktualizowane (niektóre bibliotekami dystrybucje aktualizacji dość często - inne są bardziej stabilne). Dynamiczne łączenie z bibliotekami systemowymi działa dobrze dla otwartego kodu źródłowego, ponieważ ludzie mogą łatać kod, gdy zmiany w paczkach zmieniają się nie idealnie w przypadku materiałów pochodzących z bliskich źródeł.

Możesz statycznie połączyć plik binarny w czasie kompilacji, co oznacza, że ​​masz większy plik binarny. Ale nie musisz martwić się o awarię aplikacji, gdy biblioteki są aktualizowane.

Niektóre programy, takie jak Chrome, zawierają własne biblioteki (które są w gruncie rzeczy podstawami bibliotek systemowych), co powoduje, że rozmiar pobierania jest znacznie większy, ale może również powodować problemy z bezpieczeństwem, ludzie mają tendencję do marszczenia wzroku. (patrz: http://lwn.net/Articles/378865/)

+0

Po prostu nie mogę statycznie powiązać wszystkiego, ponieważ niektóre z moich zależności są pod GPL – PiotrK

+0

Prawdopodobnie możesz spakować biblioteki (Ale musisz dostarczyć kod źródłowy do bibliotek GPL, które pakujesz - lub przynajmniej link do źródła). Można też dynamicznie łączyć się z bibliotekami systemowymi, a w pewnym momencie może dojść do złamania. Cynicznik we mnie podejrzewa, że ​​byłoby znacznie łatwiej, gdybyś otworzył źródło swojej gry - mimo wszystko korzystasz już z bibliotek open source. – Matt

+0

@PiotrK, jeśli twoje biblioteki to GPL, twój kod też jest teraz; możesz połączyć się z kodem LGPL bez otwierania kodu, ale kod GPL * wymaga * Twój kod to także GPL (lub osiągniesz alternatywny układ licencyjny z autorami bibliotek). –

1

1.) Nie, ABI głównych dystrybucji systemu Linux nie są w pełni zgodne. W wąskim znaczeniu są one zgodne z głównie. Ale w szerszym znaczeniu, istnieje wiele różnic, w których niektóre elementy systemu działają, są skonfigurowane, itd., OTOH, tworzenie "pakietów" nie jest dużym problemem nase, tylko niektóre prace. Również to, co działa dla "głównej" dystrybucji (takiej jak Debian) działa (prawie zawsze) na wszystkich pochodnych (jak Ubuntu, Mint ...).

2.) Dobra lista startowa do obsługi to: Debian (.deb), RedHat i Fedora (.rpm oba). Ich formaty i narzędzia do pakowania są dojrzałe i dobrze znane.To "pokryje" wiele pochodnych.

3.) Istnieją pewne konstruktory pakietów, które "dzielą się między sobą", ale w większości nie są do wykonania. Pisanie skryptu definicji dla większości formatów pakietów nie jest trudne, gdy już się z tym uporasz. Ponadto, niektóre komercyjne narzędzia mają "Generatory skryptów instalacji" dla systemu Linux, które zajmują się twoimi sprawami (nie generują .deb lub .rpm, a bardziej złożony skrypt powłoki, podobny do instalatora Windows EXE)

4 .) Przykro mi, nie wiem zbyt wiele na temat Steama. O :)

Z mojego doświadczenia wynika, że ​​najlepszym sposobem, aby to zrobić, jest zaakceptowanie brzydkiej prawdy, że musisz wybrać kilka głównych dystrybucji: i ich wersje (ponieważ różne rzeczy mogą się bardzo różnić między wersjami) i tworzyć dla nich pakiety, i często testować je na wszystkich. I być szczęśliwym, że nie jesteś rozwija pewne długotrwałą jądra moduł/sterownik, bo jeśli dodać śledzenie zmian API jądra do całego obrazu ... :)