Gracze… ciekawy gatunek. Z jednej strony kochamy swoje hobby, poświęcamy mu mnóstwo czasu, ale mało kto tak na prawdę interesuje się tym, co dzieje się „pod maską” naszych maszyn. Moim zdaniem warto wiedzieć chociażby to, że Bethesda wybrała tryb FPP nie dlatego, że mieli „silnik do FPS’a”, ale dlatego, że takie mieli widzimisię. Zaproponowałem na Valhalli, że podejmę się wyjaśnienia tego jak gry wyglądają od środka, jak się je tworzy etc… Nie wiedziałem wtedy na co się porywam.
Na pierwszy ogień pójdą dwie chyba najciekawsze, a z pewnością najmniej rozumiane elementy „wnętrzności” gier – Engine i Shadery. Co ciekawe nazwy te często pojawiają się w rozmowach czy tekstach jednak mało kto wie co tak naprawdę znaczą.
ENGINE
Engine to teoretycznie prosta sprawa. To ten główny program, który napędza grę. Niestety, wraz z rozwojem silników ich definicja stała się niejednolita i często myląca. To, co najczęściej uważamy za silnik to albo całe SDK (software development kit – cały zestaw narzędzi) albo tylko silnik renderujący. Ogromna różnica pomiędzy tymi sposobami rozumienia terminu „silnik gry komputerowej” często prowadzi do nieporozumień.
Pikselkowe potworki to przeszłość
Na początek słowo wyjaśnienia – silnikiem, z którego będę korzystał tłumacząc pojęcia jest Crystal Space. Jest to silnik, który znam w praktyce (a nie tylko z różnych materiałów jak chociażby UE) ponieważ korzystam z niego przy pracy nad swoim projektem. Ważniejszym powodem jest jednak bardzo wyraźny podział tego silnika (a w sumie powinienem powiedzieć ‚tego SDK’) na część typowo renderującą i część odpowiedzialną za programowanie mechaniki. Powinno mi to ułatwić wyjaśnianie pewnych zawiłości.
Silnik Renderujący
Oto część, którą najczęściej się zachwycamy – poligony, tekstury, shadery, czasem też fizyka (choć często jest to zewnętrzna biblioteka jak Havok czy ODE) etc. Jednak ta część nie ma nic wspólnego z faktycznym kształtem gry. Odpowiada wyłącznie za wyświetlanie obrazu na ekranie. Brzmi prosto ale to trochę bardziej skomplikowane. Po pierwsze i najważniejsze – trzeba decydować CO konkretnie ma zostać wyrenderowane. Tu pojawia się określenie „culling”, czyli zakrywanie obiektów. Silnik musi zdawać sobie sprawę z tego, co w danej chwili jest widoczne na ekranie. Wiadomo, że jeśli jakiegoś obiektu nie widać to nie ma sensu obciążać nim pamięci i procesora. Silnik odpowiada też oczywiście za oświetlenie obiektów, czyli czy obiekt ma być oświetlony w danej klatce i jak ma to oświetlenie wyglądać – to „jak” jest obliczane na podstawie map i shaderów obiektu. Kontroluje również pozycję obiektów.
Silnik renderujący w Crystalspace jest wyraźnie oddzielony od reszty. Dzięki temu można skorzystać z niego tworząc inne aplikacje – nie będące grami, ale wykorzystujące rendering obiektów 3D w czasie rzeczywistym – bez konieczności ładowania do pamięci ton zbędnych w tym wypadku mechanizmów. Oczywiście silniki służące wyłącznie do gier jak Unreal Engine nie potrzebują tak wyraźnego podziału więc ich części gameplay’owe mogą być zawarte w tym samym API co silnik renderujący. Na marginesie – API to zestaw funkcji, które może wywoływać programista w celu nakazania silnikowi lub systemowi operacyjnemu zrobienie konkretnej rzeczy. Krótko mówiąc silnik renderujący (renderer) to część odpowiadająca wyłącznie za wyświetlanie modeli 3D i 2D, decydowanie co i jak wyświetlić i ewentualnie za obliczanie fizyki.
Game Specific API
Teraz rządzą bestie z piekła rodem
Ta część natomiast służy do opisu mechaniki gry (aby ułatwić sobie dalsze pisanie dodam, że w Crystal Space nazywa się to CEL i w ten sposób będę się odnosił do tej części SDK w tekście – używam tej nazwy wyłącznie dla ułatwienia, więc nie utożsamiajcie jej ze wszystkimi takimi mechanizmami). I w sumie to właśnie na niej koncentruje się dzisiaj praca twórców gier. Odmęty API renderera są czasem wykorzystywane przez designerów i programistów gameplayu, ale tylko wtedy, kiedy jest to konieczne. W innych wypadkach pozostają zarezerwowane dla programistów samego engine’u – ludzi znających się na fizyce, algebrze liniowej i innych dziwnych sztukach voodoo. Nieodzowności tej części w dzisiejszych silnikach gier dowodzi fakt, że np. w Unreal Engine stanowi ona z rendererem nierozłączną całość.
Mechanizmy typu CEL powstały po to, by ułatwić programistom i designerom pracę. W zasadzie w dzisiejszych czasach dąży się do tego, by tworzenie gier w jak najmniejszym stopniu angażowało typowych programistów. Tworzą je więc designerzy i level designerzy. Programiści pracują głównie wtedy, kiedy designer nie może sobie z czymś poradzić lub kiedy okazuje się, że niezbędna jest mu jakaś dodatkowa funkcjonalność. CEL działa w wyższej warstwie niż silnik renderujący – mówi silnikowi co ten ma robić. Warstwą nad CEL jest mechanika gry, czyli gameplay – myślcie o niej jak o bazie danych, na której operuje CEL. Innymi słowy, mechanika mówi CEL’owi co ma robić. CEL wprowadza takie pojęcia jak entity, behaviour i property classes.
Entity
Byt – podstawowe pojęcie w mechanice gier komputerowych. Bytem jest wszystko z czym można coś zrobić w grze. NPC, AK-47, miecz, magiczna mikstura, kwiatek na parapecie, ale także elementy nie posiadające graficznej reprezentacji jak questy. Można np. stworzyć byt określający fabułę gry. Oczywiście każdemu, kto miał styczność z programowaniem zapali się tu lampeczka „toż to programowanie obiektowe”. I owszem, właśnie o to chodzi. Z tym, że ja bym to raczej określił jako programowanie obiektowe na sterydach z domieszką klocków lego. Każdy byt ma rzecz jasna swoją nazwę i można wpływać na jego behaviour za pomocą innych bytów.
Behaviour
To nie shadery, to wirtualne narkotyki
Oto rdzeń każdego entity. Sam byt jest w zasadzie niczym – pustym pojemnikiem na mechanikę, oddzielonym logicznie od reszty świata, dzięki czemu możemy o nim mówić jak o autonomicznym obiekcie. Behaviour to właśnie mechanika jaką nadajemy naszemu bytowi. Opiszę ją posługując się motoryzacyjną analogią – byt to coś jak płyta podłogowa – już wiadomo, że jest to „coś” ale nie wiadomo co dokładnie. Behaviour jest silnikiem, kołami, kierownicą, ogrzewanymi fotelami – tym co decyduje, że jeden samochód jest Zondą a inny Fiatem 500. Natomiast na to wszystko nakładany jest element z silnika renderującego czyli model 3D wraz z animacjami i teksturami – to jest nasza karoseria. I tak jak z wnętrza pojazdu można manipulować karoserią (otwierać maskę, ustawiać lusterka) tak z behaviouru możemy manipulować nasza wizualną reprezentacją (modelem 3D) – zmieniać jej teksturę, kolor, ustawienia specularity (mechanika „błyszczenia” obiektów – im wyższe ustawienie tym obiekt bardziej błyszczy) itp itd.
Oczywiście powyższa analogia jest nie do końca właściwa jednak to chyba najbliższe z prostych wyjaśnień. Behaviour to coś, co nadajemy bytowi by pobudzić go do życia. Powiedzmy „dusza” – kod, który decyduje czym jest dany byt i jak działa. Pytanie tylko jak łatwo i wygodnie sklecić behaviour. I tu pojawia się pojęcie property class a ja wyjaśnię skąd analogia do klocków Lego.
Property Class
Nowość w TVP – Jaki to shaderek?
Nazwa typowa raczej dla Crystal Space jednak podobny mechanizm istnieje w chyba każdym silniku gier, choć pewnie w każdym inaczej się nazywa. Property Classes to właśnie te klocki. Tłumacząc nazwę otrzymujemy „klasy właściwości”. Oznacza to dokładnie właściwości, z których możemy zbudować behaviour. Posłużę się przykładem.
Tworzymy mechanikę gracza. Co gracz powinien móc zrobić? Ano powinien się poruszać. Siup, w API CEL’a mamy property class „CommandInput” i „ActorMove” (no i dodatkowo Camera bo „ślepa” postać nam na nic). Odpowiednio odpowiadają one za przejmowanie i interpretowanie naciśnięć klawiszy, ruchów myszy oraz za poruszanie postacią. Dzięki tej pierwszej własności mamy możliwość prostego podpisania klawiszy i powiedzenia grze, że „w” ma spowodować ruch postaci w przód, zaś przesunięcie myszy ma dać ruch kamery. Dzięki mechanizmom typu CEL możemy napisać np. następujący kod (oczywiście w uproszczeniu), który da nam mechanikę gracza poruszającego się do przodu z obsługą mouse look.
pccommandinput_w
ActorMove.MovingForward
pccommandinput_mysz
ActorMove.MouseMove(args[„x”],args[„y”])
Tłumaczenie: Pierwsza linijka oznacza przechwycenie wciśnięcia klawisza w. Odpowiedzią na jego wciśnięcie jest kod z drugiej linii – oznacza ruch w przód z automatycznie nadawaną animacją. Trzecia linia to przechwycenie ruchu myszy, zaś czwarta oznacza uruchomienie starego jak świat FPS’ów mouse look. „args[]” to parametry oznaczające pozycję x i y kursora – na ich podstawie silnik oblicza kąt pochylenia i obrócenia kamery. I to już wszystko. Nasza postać może spacerować.
Teraz wystarczy przypisać jej odpowiedni model 3D i mamy Dooma… No, prawie. W każdym razie, jak widzicie kod jest niezwykle prosty. Skróciłem go i usunąłem rzeczy, które mogłyby uczynić go nieczytelnym dla laików, jednak w oryginale jest równie nieskomplikowany. Mamy tu więc 4 linijki kodu – zrobienie tego samego za pomocą samego silnika bez CEL’a zajęłoby znacznie więcej miejsca i byłoby ponownym wynajdowaniem koła. Dodatkowo posłużę się tym kodem do wyjaśnienia dlaczego używany do tworzenia gry silnik nie ma nic wspólnego z ostatecznym kształtem czy gatunkiem danej pozycji.
świetny artykuł 🙂 naprawdę przybliża „wnętrze” gry dla laika – dzięki wielkie!
Bardzo ciekawy tekst 🙂 Duzo wyjasnia :]Ogolnie mi sie podobal. Polecam, tekst rozwiał pare watpliwosci jakie mialem. Hehe to ja pisalem na V kiedys że Bethesda wybrała tryb FPP dla Fallouta bo mieli gotowy silnik 😛 Teraz czuje sie jak idiota hehe xDP. s 19 linijka od końca ma literówke „wymagania i TO”
Bardzo dobry artykul szczegolnie ze za rok ide na studia programistyczne thx za przyblizenie tematu
No coppertop to dałeś popalić. Teraz boję się uruchomić jakąkolwiek grę bo na mnie wyskoczą te wszystkie API CELe i inne Parallax Mappingi i mnie zrobią na biało-czarno pod kątem 90 stopni :)Bardzo dobry artykuł – wiele wyjaśnia, choć nie ukrywam, że niektóre akapity musiałem czytać dwa razy, żeby załapać 😀
Świetny artykuł :)Przyczepiłbym się tylko wyjaśnienia speculara – spec w skali szarości, owszem, jest wykorzystany, ale co najmniej równie często wykorzystuje się kolorowy.
Też jestem wielkim fanem normal mappingu :)Ciekawy felietonik „od kuchni”, każdy gracz powinien go przeczytać.
W sumie ‚przyczepie sie’ do 2 rzeczy -brakuje mi graficznych przykladow opisywanych technologii. Miejscami wystepuje,jak to nazywam ‚naukowy belkot’, ktory trudno zrozumiec ;p pozatym kawal swietnej roboty. ps. szkoda ze tylko 2 strony. . .
Artykuł jest naprawdę przystępnie napisany, dla kogoś ‚z branży’ wręcz brzmi zabawnie, zbyt prosto :)Powinieneś posłuchać jakie dyskusje czasem są prowadzone w firmach, ktoś ‚z zewnątrz’ miałby poważne problemy ze zrozumiemiem wątku 🙂
w sprawach software’owo/hardware’owych nie uwazam sie za laika (ani za jakiegos pr0, by nie bylo ;p ), ale czasami ciezko bylo zrozumiec o co chodzilo coppertopowi. Rozumiem doskonale, ze opisac tego bardziej lopatologicznie sie nie dalo 🙂
zdecydowanie przyklady sytuacji z gier.
Racja. Tak jakoś wyszło 😉 Faktycznie kolorowe są wykorzystywane równie często.
Hm, masz na myśli przykłady gier i sytuacji, w których te technologie są wykorzystywane czy screenów z przykładami? W sumie pewnie dałoby się zrobić i jedno i drugie. . . Nie pomyślałem o tym, następnym razem pomyślę, dzięki za sugestię 🙂
Racja, ale uwierz mi – starałem się możliwie jasno 😛 Chwilami faktycznie trąci jakimś laboratorium szalonego naukowca ale niestety – nie wiem jak opisać pewne rzeczy jaśniej. Z resztą wiesz, ten tekst to pewna wprawka, próba z mojej strony (choć starałem się by był jak najlepszy). Mam nadzieję, że z każdym kolejnym będzie coraz czytelniej i bardziej klarownie 🙂
Haha, a ja się bałem, że za długi będzie ;DDzięki wszystkim za pozytywne komentarze 🙂 Heh, na prawdę fajne uczucie 😉
O stary spadłes mi z nieba z tym artykułem,wszedzie szukałem właśnie tego typu artykułów i nic a tu ba i jest. Każdy servis o grach powienien miec takie coś na stanie.
Bardzo miły artykuł. Prosto, jasno i klarownie. W sam raz aby zrozumieć ogólne zasady rządzące naszymi ulubionymi zabawkami (tak, oczywiście, że terkocącymi ;])Jeżeli kogokolwiek przeraziła ilość zawartych w tekście technikalji, uspokajam – współczesne narzędzia do tworzenia conetntu w grach eliminują w zasadzie w 80% potrzebę ich dogłębnego rozumienia. Jak zwykł powiadać nasz niegdysiejszy koder – „Ty sobie tym głowy nie zawracaj, to moje prywatne voodoo. Daje ci narzędzia, a ty przy ich pomocy wyczaruj mi coś, co mnie zaskoczy” i tak właśnie ma to wyglądać. Wracając jeszcze raz do tematu – naprawdę bardzo fajny art. Gratulacje copper. Mam nadzieję, że teraz już nie zobaczymy w komentach takich perełek jak „Bupmappingi” i „Picsel shadery” ;]
Coppertop, skoro mówisz że ‚korzystam z niego przy pracy nad swoim projektem’ to znaczy że zajmujesz się pisaniem gier już na poważnie ?Jeśli tak to z ciekawości zapytam : czym głównie się zajmujesz – coś bliżej renderingu czy logiki ?A tak od siebie : tak dobra znajomość tematu u osób młodszych ode mnie czasem potrafi mnie zdemotywować do kształcenia się w tym właśnie kierunku – respect ;]
@nofink – powiedz co w tekście sprawiło Tobie trudności, zapewne autor, bądź ktoś kto się zna na temacie rozwinie wątek. Ja nie jestem programistą, tylko grafikiem, ale trochę teorii też znam 🙂
W sumie można tak powiedzieć (choć nie do końca), choć ten projekt zacząłem czysto hobbystycznie kilka lat temu w jednym celu – żeby się nauczyć tworzenia gier (a wtedy miałem o tym bardzo blade pojęcie, krótko mówiąc nie umiałem nic :P). I w sumie nadal jest to jednym z celów, choć trochę się pozmieniało – więcej ani jaśniej niestety nie mogę powiedzieć. Na temat całego projektu jest póki co „total stealth mode” bo wiele rzeczy jest jeszcze niepewnych. Ale na pewno jak już będę mógł coś ujawnić to Valhalla dowie się pierwsza ;)Jeszcze tylko, żeby nie było wątpliwości – jeśli jednak chodzi Ci o to czy pracuję w jakimś konkretnym studiu to nie.
Jak zasugerowałem w tekście odmęty samego renderera to dla mnie voodoo 😉 Z CrystalSpace (a raczej z CEL’a) tylko korzystam, moje uczestnictwo w rozwoju silnika ogranicza się do pisania na IRC „sth doesn’t work, i screwed up or is it another bug?” ;). Tak więc w moim spektrum zainteresowania są gameplay (tak design jak i implementacja – w CELstarcie, XML lub Python, to już odsyłam zainteresowanych do dokumentacji CrystalSpace CEL) i grafika (Blender).
Dzięki 😉
Dokładnie, dokładnie. Jeśli ktoś czegoś nie rozumie lub na przykład ma jakieś specjalne życzenia co do następnego tekstu (nad którym już myślę, ale mam kilka pomysłów na temat – jeśli napiszecie co Was interesuje to może ułatwicie (lub utrudnicie :P) mi wybór ;)) to piszcie 🙂
OK ,teraz rozumiem ;]. Będę musiał rzucić okiem na tego CrystalSpace . A tym którzy interesują się programowaniem silników polecam sdk do Quake 4 – kod źródłowy obejmuje praktycznie wszystko poza renderem i kilkoma podsystemami – studiuje sobie go już pół roku i jest to prawdziwa kopalnia wiedzy.
Polecam. Co prawda silnik nie ma tej jakości (ani w sensie dokumentacji ani pewności działania) co silniki typowo komercyjne (choć jak na coś, co kosztuje 0 zł 0 gr jest na prawdę dobrze biorąc pod uwagę ceny zamkniętych technologii) jednak jest na prawdę ciekawy i rozbudowany. No i ma niesamowite community (choć nie jakieś ogromne) – wspaniali, niezwykle przyjaźni i pomocni ludzie. CEL (rozwinę sobie skróta wreszcie – Crystal Entity Layer) jest dość rozbudowany i pozwala na zrobienie czego dusza zapragnie (czasem trzeba tylko poczekać aż developerzy naprawią jakiś bug, którego nikt wcześniej nie znalazł 😛 taki urok ;)). Cały silnik ładnie integruje się z Blenderem dzięki rozbudowanemu exporterowi – exportuje nie tylko grafikę ale i służy do prototypowania mechaniki. Ta integracja jest z resztą rozwijana obecnie w ramach projektu Apricot Open Game prowadzonego przez developerów silnika i Blender Institute. Bardzo ciekawy projekt i bardzo ambitne cele względem rozwoju tak CS jak i Blendera jako platformy game dev. Polecam – apricot. blender. org oraz crystalspace3d. org.
No właśnie, ciekawe kiedy otwarty zostanie sam idTech4. W sumie silnik Q3A już dawno jest i nawet całkiem sprawnie nim społeczność obraca.
Copertop a co w ogóle potrzeba do tworzenia gier? chodzi mi o sprzęt,sam komputer wystarczy? czy potrzeba jakiś dodatkowych urządeń?(chodzi mi o takie bardziej rozwinięte gry, nie o stworzenie Arkanoida w pascalu)
Zespołu ludzi ;] – czasy gdy ta sama osoba pisała kod ,robiła grafikę i muzykę odeszły bezpowrotnie. Ale taki prostszy silnik bez zestawu narzędzi to może jeden programista napisać mając jakiś dobry kompilator i mnóstwo czasu 😀
@TadOczywiście to co napisał One to podstawa. Jasne, wstępnie projektować (w sumie projektowanie jest wstępne do końca developmentu ale to już inna kwestia ;D) i uczyć się można bez zespołu, jednak prędzej czy później zespół grafików, kilku programistów i designerów okaże się niezbędnych. No i kto do muzyki. Nie należy jednak imho od kompletowania „siły roboczej” zaczynać, szczególnie, jeśli nie potrafisz nawet napisać functional specu. Lepiej najpierw stworzyć jasną, dobrze opisaną koncepcję i zdobyć podstawową wiedzę a dopiero później zbierać dream team. W sumie często jest tak, że ludzie sami się zgłoszą jeśli pomysł ich zainteresuje. Nie polecam pisania silnika samodzielnie, chyba, ze kogoś na prawdę do tego ciągnie. Po pierwsze jest wiele silników OpenSource’owych, z których można skorzystać, a po drugie – to po prostu zajmuje mnóstwo czasu i wymaga ton wiedzy, której zdobycie też wymaga trochę czasu. Obrazowo mówiąc – CrystalSpace do wersji 1. 0 dorastał 10 lat (ładnie się złożyło swoją drogą ;D) a był tworzony przez, nieduży, ale zawsze, zespół. Skoro pytasz o sprzęt. . . Cóż, do zaprojektowania i stworzenia mechaniki i grafiki wystarczy komputer – jeśli nie jest zabytkowy to się nada. Oczywiście wiadomo – im lepsze masz narzędzia tym lepiej, a skoro komputer jest tu narzędziem podstawowym to im będzie mocniejszy (i stabilniejszy ale tu akurat jeśli opracujesz pod Windows to i tak będzie się wieszać 😛 Dlatego ja używam Ubuntu ;)) tym lepiej. Do grafiki absolutnie niezbędny jest moim zdaniem tablet. Na późniejszych etapach, kiedy zaczyna się już poważniejszą pracę spektrum wykorzystywanego sprzętu może, jeśli dążymy do industry quality, objąć nawet takie rzeczy jak sprzęt do mo-capu czy studio nagraniowe. Krócej mówiąc – grę da się zrobić dysponując tylko pecetem (a raczej pecetami) jednak nie zaszkodzi dysponować czymś więcej. No i oczywiście niezbędny jest odpowiedni soft. Silnik i edytory grafiki to podstawa, do tego jakieś dobre IDE. Ważne jest jednak, by jego stopień rozbudowania dostosowywać do potrzeb – ja np. mógłbym korzystać chociażby z Eclipse jednak większość jego fukcjonalności jest mi zbędna więc nie miałoby to sensu. Zamiast niego używam niewielkiego edytora Geany – doskonale nadaje się do Pythona i XML’a a waży niewiele. Dalej to już kwestia potrzeb – niezbędny może okazać się wspomniany w tekście edytor diagramów UML czy choćby narzędzia do planowania. Absolutnie niezbędne są narzędzia do kontroli wersji. Pewnie o czymś jeszcze zapomniałem. Dalej to już kwestia gustu – ja np. do projektowania postaci korzystam z programu o nazwie MakeHuman. W sumie z rysowaniem sobie radzę, jednak ten program daje mi możliwość szybszego i wygodniejszego zaprojektowania twarzy i proporcji.
Ja uważam ,że każdy programista gier powinien w życiu jakiś lepszy czy gorszy silniczek napisać – nawet jeśli w przyszłości będzie korzystał z zakupionej technologii to na pewno zdobyte doświadczenie zaprocentuje. Idealnym rozwiązaniem było by zapewne przeanalizowanie dokładnie a potem rozbudowanie komercyjnego/open sourcowego silnika – jak pokazuje przykład np. Valve warto tworzyć własne technologie na bazie sprawdzonej ;]. Z tym czasem to też bym nie przesadzał – fakt te 2-3 lata to minimum, ale jak się zbierze porządny zespół to można stworzyć coś naprawdę dobrego w czasie krótszym niż 10 lat,a że zapewne to kupa pracy i kodowania po nocach to już inna sprawa :D.
Jeżeli wystartujesz z pisaniem silnika jutro, to za 10 lat, kiedy go skończysz, na rynku będą silniki 4ro wymiarowe. ;]
To ciekawe jak taki Crytek dał radę zrobić silnik CryEngine 1 ? ;]Jak się zbierze garstka uzdolnionych programistów to nie takie rzeczy sa w stanie zrobić. Zresztą we wrześniu zeszłego roku postanowiłem napisać sobie kompilator i interpreter języka skryptowego – jako że nie miałem bladego pojęcia jak się takie coś robi postanowiłem, że struktura skryptu będzie przypominała . . . . . assemblera ;] – grunt to prostota :P. Po kilku dniach gry pokazałem koledze pierwszy działający skrypt a on zasugerował żebym spróbował z kompilatorem obiektowym stwierdziłem tylko, że to dobry żart. Tak było do początku grudnia – wtedy zabrałem się za coś bardziej zaawansowanego – teraz mam już język z składnią typową dla języków obiektowych w kilku miejscach wyprzedzający pod względem funkcjonalności ten na którym się wzorowałem (z silnika Q4) , oczywiście nadal trzeba go zaliczać raczej do wersji aplha ale jak na 4 miesiące hobbystycznej pracy wydaje mi się że i tak jest nieźle ;]. Pomyśl co w takim czasie może zrobić kilka osób pracując nad tym poważnie a nie w przerwie między zajęciami na uczelni.
Coppertop a tak z ciekawości – co odpowiada w owym silniku za parsing XMLi? I czy są jakoś konwertowane na struktury o losowym dostępie? Zmartwiłbym się jeśli 90% pracy silnika pochłaniałoby bieganie po drzewkach. . .
Niestety na to pytanie ja Ci nie odpowiem – najzwyczajniej w świecie nigdy mnie nie interesowało jak to działa. Choć nie do końca – kiedyś chciałem się tym zainteresować, ale nie zainteresowałem się ;D Odpowiedź na to pytanie znajdziesz najprędzej na IRC #crystalspace, serwer FreeNode (oczywiście english). Ja mogę uspokoić Cię tylko w kwestii szybkości – CEL’owa mechnika zarówno napisana w XML jak i w Pythonie działa szybko i sprawnie. XML ma tu głównie taką wadę, że nie ma z jego poziomu dostępu do pełnego API, a tylko do określonych jego części – co jest raczej oczywiste.
No wiesz, jest w tym trochę racji. Kwestia tylko tego czym dany człowiek chce się zajmować 😉 Ja osobiście patrzę na to ze swojej perspektywy – designera, trochę grafika. Programowanie ograniczam do minimum – i dzięki CrystalSpace’owi za CELstart który mi to umożliwia 😉 – dlatego mam na to inne spojrzenie niż Ty, który najwidoczniej interesujesz się sztukami voodoo 😉
Wiesz, CS nie był przez 10 lat doprowadzany do używalności ;D Sądzę, że w takiej sytuacji dość szybko przestałby po prostu być rozwijany – z braku jakichkolwiek rezultatów. 10 lat (o ile oczywiście dobrze pamiętam, ale zdaje się, że tak – 1997-2007) zajęło doprowadzenie go do punktu, w którym developerzy z czystym sumieniem wystawili mu numerek 1. 0 – przechodząc wcześniej przez wiele wersji 0. x. I oczywiście silnik w sumie nie odstaje funkcjonalnością od najnowszych komercyjnych – od normal po parallax mapping, fizyka (przez ODE lub Bullet), a w CEL’u jest nawet funkcjonalność do zaimplementowania AI opartego na sieciach neuronowych i algorytmie genetycznym ;D Poważnie. Nie wiem jak i czy działa, ale jest ;P
Tekst wyjaśnia, racja, całkiem sporo, ale nadal czuje się jak na matematyce 😉
W sumie poza wszystkimi FLOSSowymi jak CS, Ogre czy Irrlicht dobrym przykładem skleconego w szopie silnika jest Offset Engine. Generalnie Offset Project jest bardzo ciekawy moim zdaniem – szkoda, że nic o nim nie słychać od jakiegoś czasu. No, poza przejęciem Offset Software przez Intela. Tak czy siak, silnik dość ciekawy i nawet już zdążyli sprzedać licencję – kolesiom z Red 5 Studios. One, zaciekawiłeś mnie tą skryptówką 😉 Szczególnie strukturą przypominającą Asma ;D Chętnie dowiedziałbym się więcej na ten temat i wypróbował 😉 Myślałeś może o założeniu projektu na Sourceforge, Google code czy tym podobnych? Imho to byłby dobry pomysł, może ktoś to podłapie i wyjdzie coś na prawdę fajnego :)Heh, wiecie, efekty tego tekstu dla mnie osobiście są dwa – po pierwsze: teraz będę się bardziej bał, żeby nie walnąć jakiejś gafy w poście ;D Po drugie: Widzę, że już techniczni wikingowie wychodzą z ukrycia i to mi się bardzo podoba 😉
Ogólnie staram się stworzyć własny UnrealScript – mam już między innymi rozszerzanie natywnych klas z C++ ,dynamiczne rzutowanie typów , bezpieczne wskaźniki do obiektów czy zmienne przechowujące typy , kolejna poważna funkcja która planuję dodać to natywne wsparcie dla stanów (znów inspiracja US :D) . Powiedzmy że szykuję podwaliny pod przyszłe projekty – od następnego semestru wchodzi mi specjalizacja – Interaktywna Grafika Trójwymiarowa – czyli po prostu tworzenie gier. Przez wakacje planuję zabrać się za Direct3D i stworzyć pierwszy pseudo render 3D (może przy odrobinie szczęścia będzie się prezentował równie dobrze jak Quake2 :P). Na razie poza silnikiem skryptowym poligonem doświadczalnym jest też dla mnie mój remake Diablo 1, który zacząłem jako projekt z PK3 (programowanie komputerów) i bawiłem się nim do grudnia . Jak uznam, że silnik skryptowy działa już wystarczająco sprawnie włączę go do projektu żeby zobaczyć jak działa w ‚praniu’ . Na Sourceforge się nie nadaje bo :1) Projekt jest pisany całkowicie z myślą o wykorzystaniu w silniku gry. 2) Inspiracje kodem Q4 są widoczne dość wyraźnie – ale jak mówią : jak się uczyć to od najlepszych 🙂
To akurat go nie dyskwalifikuje moim zdaniem. Na SourceForge jest wiele projektów o bardzo ściśle określonych zastosowaniach.
W sumie to może go dyskwalifikować. Mimo to zastanowiłbym się na Twoim miejscu chociaż nad założeniem strony internetowej – nie ważne czy przy wykorzystaniu SF itp. czy nie. Ale to już tylko taka moja sugestia. Generalnie brzmi bardzo ciekawie. Aha, jako, że jestem Pythonowcem muszę tu coś dodać – typowane zmienne to ZŁO ;P
W żadnym wypadku 😀 !Po pierwsze kontrola typów zapewnia przejrzystość kodu. Po drugie statyczne typy są szybsze ! Resumując : dynamicznym typom mówimy stanowcze NIE 😛
Świetny tekst gratulacje Croopertop 🙂 i przyznając się bez bicia że większość jest mało dla mnie rozumiała 🙂 (może to przez to że jest poniedziałek a ja nie spałem za długo poprzedniej nocy). Postaram się to przeczytać na spokojnie w domowym zaciszu na pewno wiele informacji mi się przyda 🙂 jeszcze raz gracki i podziękowania ! oby tak dalej 😉
I know, i know ;D Żarcik 😉 Choć przyznam, że dla mnie pythonowa „beztypowość” jest świetna – piszę sobie, do tablic czy słowników dodaję co mi się podoba nie martwiąc się o nic. Wygoda, po prostu wygoda. A czy działa wolniej. . . . trochę na pewno, ale to zależy od zastosowania. Gdyby mi ktoś powiedział, że chce pisać silnik w Pythonie to kazałbym mu się solidnie puknąć 😉 Ale do opisywania behaviourów jest super – dla mnie nawet wygodniejszy od XML’a. Dzięki Bhaal, cieszę się, że się podobało 😉
Artykuł bardzo wiele mi wyjaśnił. Dobrze wiedzieć jak działają takie silniki. Zawsze mnie to ciekawiło. Może sam zacznę gry robić xD
Bardzo mi pomógł ten poradnik. Nie wiedziałem że pikselowe grafiki to przeszłość chociaż wszystko się z nich składa (grafika 3D to też piksele). Dobrze że autor robi swój projekt bo przynajmniej napisał to z własnego punktu widzenia.
Może autor pokaże trochę tego projektu co zaczął robić? Było by bardzo miło:)
Baaardzo ciekawie napisany poradnik. Firmy develpoerskie robiące gry mają na prawdę masę roboty. Dlatego tak ważne dla nich jest aby te gry sprawiły radość ich użytkownikom. Jeśli się tak nie stanie to wyobraźcie sobie miny twórców – totalna klapa i co najmniej rok roboty na nic. . . .