…Jednakże, jeśli czujesz się na siłach poradzić sobie bez takiego wsparcia lub jeśli fundusze są problemem to Open Sourceowy silnik jest dla ciebie”. Jak widać nie ma tu najmniejszego śladu po tak nam doskonale znanym PR’owym bełkocie. Po prostu prawda i opis sytuacji takiej jaką jest: Zamknięty silnik za milion dolarów – pewność i rozbudowany support, Otwarty silnik za darmo – potencjalne problemy i społecznościowy supportu.

Jak jest czasami w rzeczywistości z zamkniętymi technologiami to już pokazała chociażby sprawa Silicon Knights oraz ich problemów z Unreal Engine i jego „niezgodną z zamówieniem funkcjonalnością”, ale to jakby inna sytuacja i nie o tym chcę pisać. Tematem, który chcę poruszyć jest właśnie praca z Open Sourceową technologią przez pryzmat ostatniego „nieco ponad tygodnia”.

Jakiś czas temu w jednym z moich felietonów przedstawiłem Wam projekt Apricot, który ma za zadanie – między innymi – wpłynąć przyspieszająco na rozwój używanego przeze mnie silnika CrystalSpace. Efekty pracy tegoż projektu powinny już niedługo ujrzeć światło dzienne – wtedy też uwiję im gniazdko na moim dysku twardym.

Wspomniany projekt wprowadza jednak bardzo wiele zmian do sposobu w jaki w CrystalSpace pisze się gry. Nie ma sensu bym wdawał się tu w szczegóły, dość powiedzieć, że oznacza to trochę przepisywania i dostosowywania już istniejącego programu. Nie buntuję się przeciwko tym zmianom ponieważ są one zdecydowanie na lepsze, jednak nie przeczę, że perspektywa przerabiania kodu, jako czynność żmudna, nie jawi mi się w specjalnie różowych barwach. Po prostu jest to, jakby na to nie patrzeć, stosunkowo nudne w porównaniu do tworzenia nowych rzeczy. Zdając sobie jednak sprawę z korzyści jakie przyniesie nowa forma pisania w nadchodzącym, „poapricotowym” Crystalu postanowiłem wykorzystać tak zwany międzyczas (liczony od zakończenia pracy nad pewnym fragmentem mechaniki do planowanego pojawienia się gotowych paczek rodem z Instytutu Blendera, czyli jakiś tydzień, choć pewnie będą dwa) na owe modyfikacje. I tu pojawiły się schody.

Jest takie powiedzonko, że jedyne czego boją się developerzy (jakiegokolwiek oprogramowania) to pisanie dokumentacji. Dodatkowo CrystalSpace cierpi niestety na syndrom „duży projekt – mało ludzi” co sprawia, że dokumentacja niekoniecznie jest tak wyczerpująca jak być powinna. Ale sam też uderzam się w pierś, bo przecież moja wiedza, choć nikła w porównaniu z Wielkimi Developerami CrystalSpace z IRC’a, pozwalałaby mi na uzupełnienie tego i owego… No cóż, ja też się boję. Tak czy siak do tej pory jakoś sobie radziłem, choć na przykład elementy dotyczące programowania mechaniki ogólnie pojętego inventory nie były praktycznie wcale udokumentowane (pomijając API). Kiedyś nawet wspomniałem o tym na IRCu, na co w odpowiedzi otrzymałem „dzięki za jej napisanie, wszyscy jesteśmy Ci bardzo wdzięczni” – cóż, urok Open Source (w zasadzie to, to już na sto procent mógłbym dopisać tylko jakoś się zebrać nie mogę…). No właśnie, IRC. Mimo braku odpowiedniej dokumentacji czy tutoriali na IRC’u zwykle da się znaleźć choć jedną osobę znającą się wystarczająco na konkretnym fragmencie silnika (zwykle jest to po prostu ten co napisał ów fragment), która może pomóc, i najczęściej pomaga. Tym właśnie sposobem rozwiązywałem swego czasu wątpliwości dotyczące programowania inventory czy innych kwestii związanych z Pythonem (to taki bardzo przyjemny język programowania). Niestety, tym razem zabrakło mi szczęścia…

Funkcjonalność, która od chwili nadejścia Apricot będzie rdzeniem programowania mechaniki niestety jest obecnie ciągle w fazie tworzenia i choć działa już od jakiegoś czasu to jednak jej dokumentacja… Cóż, jest dość pobieżna – czyt. fragment przykładowego, podstawowego programu i kilka linijek komentarza, które pozwalają, owszem, sprawnie korzystać z tejże funkcjonalności ale tylko wtedy, kiedy wie się już dokładnie jak zacząć. Jeśli się nie wie to ma się problem. Ale przecież jest jeszcze IRC, tu na pewno będzie Człowiek od Pythona. Niestety, tydzień na niego czatowałem (próbując w międzyczasie dość niemrawo dociec gdzie nacisnąć żeby działało) i się nie doczekałem. Wywnioskowałem, co zresztą jest prawdą, że w Instytucie Blendera ostatnie prace nad Apricot pochłaniają zbyt dużo czasu by móc sobie pozwolić na siedzenie przy IRC. Niestety, dla mnie była to zła wiadomość.

Na domiar złego cała ta sytuacja zbiegła się w czasie z wezwaniem do WKU na „uzupełnienie ewidencji” (dobrze, że nie „uzupełnienie szeregów”) i kilkoma innymi sprawami, które wymagały dość sporo biegania a co za tym idzie nie dość, że złapałem doła z powodu przestoju w pracy to jeszcze musiałem latać jak wiewiórka z petardą w tyłku po całej Łodzi i okolicach (odbiło się to zresztą na mojej obecności na V). Na szczęście tydzień latania został zwieńczony opisanym w piątek wypadem do City Interactive co pozwoliło mi się wyluzować. Niestety, po powrocie z Warszawy trafiłem do tej samej rzeczywistości, z której wyjechałem – rzeczona funkcjonalność dalej nie funkcjonowała, dokumentacja się nie rozrosła a Człowiek od Pythona, dalej nie pojawiał się na IRCu. Sytuacja nie wyglądała więc zbyt ciekawie.

Nadeszła jednak niedziela kiedy to w końcu zwarłem się w sobie i postanowiłem nie odejść od komputera dopóki nie dowiem się jak to uruchomić. I co? I udało się. Coppertop zatriumfował. Oczywiście rozwiązania okazały się dość prozaiczne, nawet jeśli wymagały zaglądania do wnętrzności samego silnika, od których do tej pory, z pobożną trwogą, trzymałem się z dala. Nadal boję się, że następnym razem zjedzą mnie tam potwory voodoo ale przynajmniej się odważyłem. Szkoda tylko, że nie zrobiłem tego wcześniej, bo przez to straciłem około tygodnia czasu. Ale cóż, ważne, że działa.

Jak już wspomniałem mówiąc o mechanice inventory, nie był to pierwszy przypadek, w którym pojawiły się problemy spowodowane naturą silnika, jednak pierwszy na tyle poważny (czyt. pierwszy w którym zabrakło dostępu do pythonowej części wspaniałej społeczności CS – piszę szczerze i bez sarkazmu). Czy to sprawia, że żałuję wyboru tego silnika, lub ogólnie silnika OpenSourceowego? W żadnym wypadku. Czy zamieniłbym go na inny gdybym miał odpowiednie do tego fundusze? Możliwe. Kusi mnie przede wszystkim Source, z którym bardzo chętnie bym popracował, zobaczył co ma do zaoferowania. Jednak w żadnym wypadku nie ubolewam nad problemami jakie towarzyszą mojej przygodzie z CrystalSpace. Między innymi dlatego, że lubię ten geekowy, garażowy klimat, zapach zimnej pizzy i uczucie, które ogarnęło mnie kiedy udało mi się wreszcie po tygodniu zmusić coś do działania. Podobne emocje towarzyszyły mi kiedyś w Linuksie, w czasach (nie tak w sumie odległych, a jakże innych), kiedy to nic nie działało i niemal wszystko trzeba było ręcznie ustawiać lub poprawiać. Po prostu lubię to i póki mogę sobie na to pozwolić bez krzyczącego na mnie nadzorcy sweatshopu niespecjalnie chcę z tego rezygnować. No a poza tym, zdaję sobie sprawę z tego co zacytowałem na początku – silnik jest za darmo więc pretensji też nie można mieć. Do tego jest Open Source’owy, a to oznacza pewne ideały ale i obowiązki wobec społeczności, dlatego też lecę uzupełniać dokumentację.

[Głosów:0    Średnia:0/5]

10 KOMENTARZE

  1. A ty copper to co? Przerzuciłeś się na developer’s blog? Tak całkiem poważnie to natura otwartych technologii jest nieco pokrętna. Oczywiście chwała wszelakiemu community ze to, że tworzą za free z myślą o wyższych celach ale niestety sprawa po bliższym przyjrzeniu się, nie wygląda tak różowo. Otóż z tego co zauważyłem największym problemem w OenS nie jest brak dokumentacji, czy olbrzymie czasami ilości bugów. To można zrozumieć. Największy problem pojawia się wtedy gdy zgłębisz, zrozumiesz i już częściowo wdrożysz dane funkconalności do swojego projektu, a tu nagle okazuje się, iż. . . kolejnej funkconalności, będącej logicznym następstwem już istniejących po prostu nie ma. Przejechaliśmy się ostatnio tak na Nweton Dynamics – darmowej bibliotece zachowań fizycznych. Coś jak Havok czy Aegia tylko że 10000 razy prostsze i za free. Wprawdzie system nie jest open source, ale podobne problemy znajdujemy w większości produktów spod znaczku „Free”. Koder integrował system do silnika. Przez 3 tygodnie głowił się dlaczego pewnej rzeczy nie da się wykonać choć powinna działać bez problemu. No i się wyjaśniło. . . . tej technologii po prostu nie ma. Nie została zaimplementowana w bibliotekach a nigdzie nie zostało to napisane. Dlaczego więc jej tam nie było, choć wydawała się logicznym następstwem swoich poprzedniczek? Tego również nie wiadomo. Czarna dziura, null, zero. Takiej ilości przekleństw o zmarnowanych 3 tygodniach nie słyszałem nigdy w życiu. 🙂 Na dodatek, skoro nie ma źródeł to nie można sobie jej dopisać. Na koniec stwierdził, że już nigdy w życiu nie będzie opierał się na dziadostwie napisanym przez niedouczonych i nieodpowiedzialnych ludzi, których nawet nie można za to zje. . . . Wiem, że troszkę przesadził, ale jednak jest w tym ziarno prawdy. Tak więc korzystając z dobrodziejstw wszystkiego co darmowe, należy spodziewać się przede wszystkim problemów. Choć osobiście korzystam z wielu programików OpenS i jestem raczej zadowolony, to są to głównie małe pierdółki, które w każdej chwili mogę zastąpić czymś innym.

  2. A ty copper to co? Przerzuciłeś się na developer’s blog?

    Powiedziałbym raczej, że jest to taki mój mały eksperyment ;D. Jak widać nie do końca udany, ale co tam, raz nie zawsze a spróbować można było ;).

    Na dodatek, skoro nie ma źródeł to nie można sobie jej dopisać.

    A no właśnie i tu jest sęk 😉 Dlatego Bullet czy ODE wydają się lepsze choćby z tego względu, że masz źródła i w razie czego zawsze możesz coś dodać. Oczywiście, może się to okazać niewarte czasu, na przykład z powodu źle zaprojektowanej całości biblioteki ale cóż, z tym się trzeba niestety liczyć. Albo płacisz albo się godzisz. Z tym, że jeśli już nie płacić to lepiej wybrać coś, co w razie czego można poprawić – takie jest moje zdanie ;).

    Tak więc korzystając z dobrodziejstw wszystkiego co darmowe, należy spodziewać się przede wszystkim problemów.

    No ja jak na razie w chyba 95% korzystam z otwartego softu i na szczęście sobie chwalę (odpukać). Choć szlag mnie kiedyś trafił kiedy do Blendera dodali wypalarkę normalek. Niby owszem, super, ale okazało się, że działa tylko w przestrzeni obiektu więc do użycia w grze nie nadawało się to zupełnie. Na szczęście znalazłem wtedy inny, również opensourceowy, zewnętrzny programik, który był już w stanie zrobić to prawidłowo (czyt. tangent space). Obecnie w Blendku również poprawili tą funkcję (a raczej dodali bo to co było, było chyba jako przystawka. . . ) ale ja jednak nadal pamiętam o tamtym rozczarowaniu.

  3. To żaden problem. Istnieją bardzo fajne darmowe konwertery object to tangent space. Na przykład całkowicie darmowy XNormal. Nawiasem mówiąc posiada wiele innych bardzo ciekawych funkcjonalności.

  4. Fajnie sobie poczyta? pracy programist?d wewn?trz :)Ale czego? nie rozumiem. . . projekty open, przy wszystkich swych wadach daj? w?a?nie to, ?e jak co? nie dzia?a to da si?ajrze?o ?r? i zrozumie?laczego. Czy gotowe, programy closed source zawsze maja super dokumentacj?dzia?aja w 100% tak jak obiecywały reklamy i na dodatek maja genialny support? Z moich do?wiadcze?ko u?ytkownika to raczej tak nie jest. . . .

  5. Z moich doświadczeń jako użytkownika to raczej tak nie jest. . . .

    Jasne, że nie. Zresztą, wspomniałem choćby o sprawie Silikonowych Rycerzy (haha, jak to brzmi ;D). Różnica jest taka, że można tego wsparcia wymagać i ewentualnie a) jest na kogo nakrzyczeć i b) nie czujesz się głupio krzycząc ;D. Btw, czy tylko ja mam jakieś problemy z kodowaniem w poście Jerry’ego?

  6. Btw, czy tylko ja mam jakieś problemy z kodowaniem w poście Jerry’ego?

    Najwidoczniej nie tylko Ty, bo ja też mam problemy z kodowaniem u niego. Zamiast polskich znaków pojawiają się znaki zapytania. Może używa kodowania ISO, ale zachodniego lub Windows-1250?

  7. O Wikingowie Developerzy co sądzicie o Ogre3d pod względem funkcjonalności i ogólnej sensowności. ciekaw jestem który z darmoych silników jest najbardziej rozwinięty i niezabugowany.

  8. @SenseiCiężko powiedzieć. W sumie zastanawiałem się nawet czy nie pokusić się o jakieś, choćby pobieżne, porównanie FOSSowych (albo nawet nie FOSSowych, ale darmowych ogólnie) silników w którymś felietonie ale nie wiedziałem czy to kogoś zainteresuje. Teraz widzę, że choć popularność tego felietonu nie umywa się do tych bardziej tradycyjnych, niedeveloperskich, to jednak nie jest aż tak pusto jak myślałem 😉 (choć wiedziałem, że jeśli ktoś się odezwie to pierwszy na pewno będzie Digital_Cormac i miałem rację ;D). Ale do rzeczy. CrystalSpaceWydaje się najlepszą opcją dla takich ludzi jak ja – lubiących programowanie ale z umiarem. CEL i Celstart pozwalają skupić się na tworzeniu mechaniki bez zagłębiania się w bardziej niskopoziomowe problemy. Dlatego właśnie wybrałem ten silnik. Poza tym niemal kompletne bindingi Pythona oraz możliwość pisania skryptów (choćby i całej gry, jeśli tylko nie jest ona bardzo skomplikowana) w XML’u dodatkowo upraszczają cały proces – można nie dotykać C++ co jest dobre z kilku powodów. Po pierwsze moim zdaniem programowanie w Pythonie jest o niebo prostsze i wygodniejsze i po drugie, może nawet ważniejsze, brak kompilacji jest ogromną oszczędnością czasu. Ale nie ma róży bez kolców. Za główną wadę CrystalSpace uważam osobiście to, co wspomniałem w felietonie – mało ludzi. Co prawda ci, którzy są i pracują przy projekcie wykonują wspaniałą, tytaniczną robotę i zasługują na pomnik z platyny jednak trudno nie zauważyć, że przy poziomie rozbudowania samego Crystal’a oraz CEL’a i B2CS (exporter z Blendera) przydałoby się więcej rąk i oczu. Dodatkowo, nie wiem jak to jest w innych silnikach bo interesuję się nimi raczej pobieżnie, jednak CS jest cały czas bardzo szybko i czasem dość poważnie rozwijany. Z jednej strony jest to zaleta – zmiany są zawsze na lepsze, ale z innej wada gdyż w sumie pracować na poważnie jest sens tylko z wersją z SVN, czyli rozwojową a tu wystarczy w nieodpowiednim momencie zrobić checkout żeby posypały się portale albo wlazł, ni stąd ni z owąd jakiś segfault. Najczęściej takie rzeczy są szybko naprawiane, ale w momencie nasilonego developmentu (jak teraz) zdarzają się dość często. OGRE3DUważany za głównego rywala CrystalSpace ;). Od razu zaznaczam, że to co teraz napiszę jest „z tego co wiem” bo OGREm interesowałem się dość dawno temu. Główna różnica jest taka, że CS’owi najbliżej z OpenSource’owych silników do middleware’u, zaś OGRE to tylko silnik renderujący. To znaczy pozbawiony funkcjonalności, którą w CrystalSpace zapewnia CEL. Zdaje się, że coś podobnego zostało dla OGRE napisane, ale wątpię by dorównywało poziomem rozbudowania CEL’owi. Dla mnie osobiście powyższe całkowicie eliminuje OGRE z gry, jednak jeśli na przykład ktoś woli pisać mechanikę od zera, bez „odgórnego” systemu bytów, to OGRE jest ciekawą opcją. Co interesujące, na OGRE powstało bardzo dużo gier. Jest to zdecydowanie najpopularniejszy otwarty silnik. Ja osobiście wnioskuję z tego, że jego development jest stabilniejszy a sam silnik, jako wyłącznie renderujący, może być prostszy do opanowania od CrystalSpace. Nie wiem czy tak jest w istocie, ale tak to sobie tłumaczę ;). Dodatkowo na temat programowania w OGRE powstała też książka – czymś takim CrystalSpace o ile wiem nie może się pochwalić (nie miałoby to też sensu biorąc pod uwagę szybkość niektórych zmian). Oczywiście Ogra również można używać za pomocą Pythona, jednak nie mam zielonego pojęcia jaki jest tam status kompletności bindingów. Oba silniki mają ze sobą jednak wiele wspólnego. Mają budowę modularną co oznacza, że można korzystać tylko z określonych ich funkcji nie zawalając pamięci resztą. Poza tym, jeśli nie instalować CEL’a, to sam CS jest zasadniczo niemal równie „gołym” rendererem co OGRE. Oba korzystać mogą również z tych samych bibliotek fizyki jak ODE czy Bullet, oraz z biblioteki do tworzenia interface’u graficznego CEGUI (choć przymusu nie ma, ja na przykład zamiast niej buduję taki system od podstaw za pomocą wbudowanego w CEL systemu billboardów). Z każdym z nich można również korzystać z Blendera, choć w wypadku CrystalSpace jest to raczej wymóg. Podczas gdy OGRE posiada chyba dość rozbudowane wtyczki eksportera dla takich zamkniętych modelerów jak 3DS czy Maya, tak w wypadku Crystala chyba jedynym utrzymywanym „up to date” jest exporter dla Blendka. Plusem takiej sytuacji jest to, że CS wykorzystuje Blendera do budowania poziomów a nawet tworzenia mechaniki – oznacza to, że z poziomu Blendka nie tylko eksportujemy siatki do formatu silnika, ale możemy też wyeksportować kompletne, wyposażone w mechanikę poziomy, które można zaraz po eksporcie uruchomić. Ogólnie rzecz ujmując sprawa wygląda tak: CrystalSpace jest bardzo rozbudowanym silnikiem, który zasługuje w pełni na miano „silnika gier” – niemal all in one package. OGRE jest wyłącznie silnikiem renderującym do którego należy sobie dokooptować inne biblioteki celem uczynienia z niego silnika nadającego się do pisania gier. Czyli wybór zależy od preferencji co do stylu pracy oraz tego co i jak chcemy osiągnąć. Aha, jeszcze kwestia techniczna – oba są w pełni multiplatformowe (Windows, Linux, Mac, BSD. . . ) jednak CrystalSpace korzysta wyłącznie z OpenGL zaś OGRE może pracować również na Direct3D. Inną ciekawą opcją, choć raczej tylko dla fanów Blendera, wydaje się silnik wbudowany w tenże modeler. Umożliwia on robienie wszystkiego graficznie i powinien być dość prosty w użyciu, jednak obecnie stara jego wersja jest. . . no właśnie, stara, zaś ta tworzona przy okazji projektu Apricot (widać mieli za dużo wolnego czasu że się i za to wzięli ;D) jest jeszcze bardzo niedojrzała.

  9. Dzięki za konkretny wywód. Faktycznie przydałoby się zrobić jakieś porównianie darmowych silników ze szczególnym rozgraniczeniem czym tak naprawdę są. Silnik renderujący a middleware to dwa bardzo różne produkty, a w powodzi silników często trudno o solidne informacje. Tak sobie myślę właśnie co jest w praktyce lepszą opcją, zmontować sobie pseudo middleware na bazie np. Ogre3d oraz dodatkowych dobrych bibliotek np. fmod czy też mieć all-in-one ale z svn. Być może więcej gier powstało na Ogre gdyż ta opcja developerom wydała się mniej kłopotliwa. Tak z zupełnie innej beczki, to czy interesowałś się silnikiem mmorpg Multiverse? Masz wyrobione zdanie na jego temat?

  10. Być może więcej gier powstało na Ogre gdyż ta opcja developerom wydała się mniej kłopotliwa.

    Dokładnie, choć jak mówiłem, wszystko zależy od podejścia. Jeśli ktoś jest zaawansowanym devem, ale bez kasy pozwalającej na zakup np. UE – często wybierze Ogre. Jeśli ktoś, tak jak ja, nie ma doświadczenia wystarczającego by tańczyć z Ogrem, SDL, zupełnie oddzielnym ODE i jeszcze pisać do tego wszystkiego łączenia, ale nie boi się rozgryzać zawiłych zawiłości – zdecyduje się na CrystalSpace. A jeśli ktoś jest zupełnie początkujący i chce się tylko pobawić tworząc coś na kształt Quake’a to pewnie pójdzie w Irrlicht (nie wymieniłem go powyżej bo, z całym szacunkiem dla projektu, moim zdaniem jest to jednak zabawka).

    Faktycznie przydałoby się zrobić jakieś porównianie darmowych silników ze szczególnym rozgraniczeniem czym tak naprawdę są.

    Mówisz i masz 😉 A raczej będziesz miał, postaram się sklecić coś takiego przez weekend :). Powiem też być może trochę więcej o tym co dokładnie przyniósł już projekt Apricot.

    Tak z zupełnie innej beczki, to czy interesowałś się silnikiem mmorpg Multiverse? Masz wyrobione zdanie na jego temat?

    Nie interesowałem się silnikami skierowanymi na MMO – nie moja tematyka ;).

Skomentuj Przemek Piprek Anuluj odpowiedź

Please enter your comment!
Please enter your name here