Dear Esther zostanie przeniesiony z Source na Unity

Dear Esther zostanie przeniesiony z Source na Unity

przez -
1 317
Dear Esther
Briscoe miał m.in. znaczny wkład w narzędzie Wall Worm, umożliwiające eksport danych z 3Ds Max  do Source. Niestety ostatecznie silnik Source stworzony przez Valve stał się kulą u nogi Roberta i The Chinese Room. Cofnijmy się nieco w czasie do Humble Indie Bundle 8 i pojawienie się Dear Esther na Linuksie. Wtedy The Chinese Room było zajęte inną grą, Amnesia: A Machine For Pigs i brakowało sił do stworzenia portów na Linuksa i OS X. Ostatecznie z pomocą przyszło CodeWeavers pakujące Dear Esther razem z zmodyfikowaną na potrzeby gry wersją CrossOver (Wine). Nieco później “natywny” port stworzył Ryan C. Gordon.

Wersja przygotowana przez CodeWeavers nie była oczywiście optymalnym rozwiązaniem. Problemem okazało się uzależnione od nich wsparcie techniczne (które w końcu wygasło) i obecność błędów nie tylko w samej grze ale i w CrossOver. Tymczasem port stworzony przez Ryana nigdy nie wyszedł poza fazę beta.

Jeszcze większym problemem okazało się “middleware” czyli biblioteki firm trzecich zawarte w silniku Source. Konieczne było opłacenie dodatkowych kosztów licencyjnych, gdy silnik został użyty  na innych systemach niż Windows, jak OS X czy Linux. Koszty były tak duże, że studio straciło pieniądze wydając grę na te systemy.

W decyzji o porzuceniu Source “pomógł” też fatalny kontakt z Valve podczas tworzenia portów na Playstation 3 i 4. Ten nigdy nie był dobry. Już na początku prac nad Dear Esther, Valve poinformowało Roberta Briscoe, że “skupiają się na tworzeniu gier a nie sprzedaży licencji”.   Później, podczas prac nad wersją na konsole, osoba będąca kontaktem w Valve pożegnała się z firmą, co ostatecznie spowodowało kilkumiesięczne opróżnienia.

Nowy początek na Unity

Zrzut ekranu widoczny poniżej to Dear Esther na nowym silniku. Unity ma kilka zalet jak tworzenie wersji na różne systemy “jednym kliknięciem” czy nowoczesne narzędzia. Co chyba najważniejsze, firma opracowująca silnik utrzymuje się ze sprzedawania licencji i przywiązuje wysoką wagę do kontaktu z twórcami gier.

u50ouon
Dear Esther na silniku Unity (kliknij aby zobaczyć animację)

Aktualnym planem Roberta jest stworzenie wysokiej jakości portów gry na Linuksa i OS X, a w przyszłości może nawet i porzucenie Source w wersji na Windows. Nowe wydanie Dear Esther będzie udostępnione osobom, które już nabyły grę w Humble Bundle lub Humble Store.

Więcej szczegółów o historii i przyszłości tego tytułu można się dowiedzieć z postów:

Oczekiwanie…

Dear Esther nie jest jedyną pozycją firm trzecich, która została lub ma zostać wydana na Linuksa i wykorzystującą z komercyjną wersję silnika Source (czyli nie SDK 2013 Base jak darmowe modyfikacje). Inne gry to np. Insurgency czy The Stanley Parable. Wszystkie korzystają z gałęzi “Portal 2/Counter -Strike: Global Offensive” i czekają na wydanie tychże przez Valve. Do ich premiery, pomimo upływu kolejnych miesięcy, wciąż nie dochodzi. Można tylko podejrzewać, że studio z Bellevue ma poważne problemy z usunięciem jakichś znaczących błędów w tej gałęzi silnik.

Nagranie z konferencji Steam Dev Days wskazuje, że odpluskwianie Source 1 korzystającego z translatora “Togl” może być koszmarem (10:21):

Valve zdecydowało się porzucić to rozwiązanie w przyszłej wersji silnika. Również narzędzia mają być całkiem przebudowane w Source 2. Czy kontakt z Valve okaże się lepszy w przyszłości i czy ich silnik będzie warto licencjonować? Okaże się w (zapewne niedalekiej) przyszłości.

Nie każde studio pozwala licencjonować swoje silniki. Nie można na przykład kupić Serious Engine 3.5 czy HPL2 – gdy twórcy Gone Home zbudowali prototyp na silniku Amnesii (HPL2), poprosili Frictional Games o sprzedaż licencji, to stanowczo odmówiło tłumacząc się brakiem dobrej dokumentacji i możliwości zapewnienia wsparcia technicznego. Ostatecznie Gone Home zostało zbudowane w oparciu o Unity.

Dear Esther nie jest też jedyną grą, której wydanie na Linuksa wymusza zmianę silnika. To samo dotyczy np. Hotline Miami czy McPixela (tutaj problemem jest niewspierany Adobe Air). Reasumując: przenoszenie gier na nasz system często kryje pułapki. Na szczęście w przyszłości może być tylko łatwiej – nieustannie pojawiają się nowe narzędzia, silniki czy biblioteki. Ktoś musi jednak przecierać szlaki…

  • CyberKiller

    NIe zgodzę się ze stwierdzeniem że przenoszenie gier na GNU kryje pułapki. Pułapki kryje brak odpowiedniego planowania developmentu. Uważam że należy planować od samego początku wersje na wszystkie platformy i pod tym kątem wybierać silniki/technologie do użycia. Sam jestem jedynie hobbystycznym developerem, a potrafię bezproblemowo moje aplikacje czy gry napisać, tak że działają na wszystkich standardowych (LSB) dystrybucjach GNU/Linuxa oraz Mac i Windows. Skoro ja potrafię to i każdy profesjonalny developer powinien potrafić, to nie jest wysłanie rakiety w kosmos. Niemniej jeśli ktoś na początku krótkowzrocznie wybierze przywiązanie do technologii microsoftowych to potem faktycznie ma płacz i zgrzytanie zębów jak chce portować na inne platformy – tak czy owak winny jest tylko on sam.