Przykładowo, przerobienie tego, stworzonego z myślą o FPP kodu na pasujący do RTS’a wymagałoby jedynie odpowiedniego wypozycjonowania kamery (która w RTS’ie robi w sumie za byt „gracz” i wisi sobie nad terenem nie połączona z żadną postacią na ziemi), nadania jej odpowiedniego domyślnego pochylenia i podpisanie pod [w] np. przechylenia kamery a pod „mysz” funkcje sprawdzającą czy i przy której krawędzi monitora jest kursor i przesuwającą odpowiednio kamerę – tradycyjny mechanizm z RTS’ów. Równie prosto da się uzyskać coś na kształt izometrii.
Stworzyć GoW? Prościzna
Jak więc widać zmiana perspektywy kamery jest stosunkowo prostą operacją. Sam Crystal Space’owy CEL ma domyślnie zaimplementowanych kilka – do FPS’ów, do „Tomb Raiderowego” TPP czy choćby do przygodówek. Jeśli chcemy skorzystać z jednego z nich to wystarczy go wybrać, jednak nic nie stoi na przeszkodzie by dopisać własny lub zmienić coś w tych domyślnych. To samo tyczy się całej reszty mechaniki. Oczywiście, biorąc pod uwagę, że np. Epic robi głównie FPS’y albo TPP ich silnik będzie z pewnością najlepiej nadawał się do właśnie tego typu gier i do nich będzie pasowało najwięcej funkcji jednak szczególnie przy autorskich technologiach (kiedy programiści naszego silnika siedzą dwa pokoje dalej), dopisanie nowej perspektywy nie stanowi żadnego problemu. No, chyba, że wymyślimy sobie jakąś, o której nikt wcześniej nie słyszał ale to raczej mało prawdopodobne.
Spis treści
Middleware
Middleware to ciekawe zjawisko – w sumie może być wszystkim albo niemal niczym. Middleware’em jest np. Gamebryo, czyli kompletne rozwiązanie, na którym robimy grę od początku do końca, ale także Havoc czyli fizyka, oraz SpeedTree – drzewka i krzaczki. Tylko tyle i aż tyle bo middleware robi tylko jedną rzecz u zwykle robi ją naprawdę dobrze. Cechą wszystkich Middleware’ów jest dostarczanie kompletnego rozwiązania – nie tylko odpowiedniego API ale też zestawu narzędzi, często graficznych, a nawet kodu źródłowego czy grafiki. Ułatwia to niesamowicie tworzenie gier i przyspiesza cały proces jako że budujemy ją prawie z klocków, ustawiając je często w graficznym edytorze WYSIWYG, w którym możemy nawet zaprogramować AI czy wygodnie zaznaczyć domyślne ścieżki ruchu dla samochodów czy pieszych w naszym klonie GTA. Z tego tez powodu Unreal Engine można by podciągnąć pod kategorię middleware’ów, ale już Crystal Space czy nawet idTech4 (silnik Dooma3) nie. Ani jeden ani drugi nie dostarczają bowiem wystarczającej ilości narzędzi (w silniku Dooma3 głównym narzędziem był notatnik – od razu widać, że pisane przez prawdziwego geeka) i gotowych rozwiązań.
Jeśli natomiast będziecie kiedyś szukać winowajców podobieństw między grami w dzisiejszym świecie to głównym jest nadużywanie Middleware’ów. Same w sobie nie są złe – kiedy jednak kilka gier używa tego samego a ich twórcy przesadnie posiłkują się dostarczonym przezeń kodem i grafikami robi się nieciekawie. Pamiętacie standaryzację gier w blogu Jolo? No to wiecie o czym mówię. Pozostałe elementy typowego silnika to to o czym wspomniałem przed chwilą – mnóstwo różnej maści narzędzi. Jeśli chcecie zobaczyć screeny czy poczytać więcej na ich temat, to wejdźcie na unrealtechnology.com – doskonały przykład i sporo wiadomości.
Mam nadzieję, że w miarę przystępnie wyjaśniłem z czego składa się silnik. Przejdźmy więc do czegoś innego…
SHADERY
W skrócie shader to mały programik działający bezpośrednio na karcie graficznej. Mówi jej w jaki sposób oświetlić dany obiekt. Najbardziej znane shadery to te ze słowem „mapping” w nazwie i na nich się skupię. Słowo to wzięło się stąd, że ustawienia shadera dla danego piksela bierze się z mapy, czyli specjalnej tekstury nałożonej na model 3D.Dziejsze shadery można podzielić na pixel shader (manipulacja pikselami) i geometry shader (manipulacja geometrią).
Diffuse Mapping
To jest po prostu tekstura koloru. Wspominam o tym dla porządku i żeby zapoznać Was z właściwą nazwą.
Bump Mapping
Nie cierpię tego shadera. Dlaczego? Ano dlatego, że większość graczy świata poza nim nie widzi, a tymczasem nie jest on już praktycznie używany. Choć nie jest to do końca prawdą. Bump mapping to bowiem nie tyle konkretny shader co rodzina shaderów. Mają one wspólny sposób działania, ale każda kolejna „wersja” jest potężniejsza od poprzedniej.
Tak jak ubijanie Locustów
Tym co zwykle rozumiemy pod pojęciem „bump mapping” jest pierwsza tego typu technologia. Jej podstawą jest nakładana na obiekt czarno-biała tekstura – mapa wysokości. Im ciemniejszy obszar na teksturze tym większe wgłębienie. Efekt tego wgłębienia jest uzyskiwany w następujący sposób – kiedy światło pada na piksel tekstury (texel) karta graficzna odwołuje się do jego bump mapy i odpowiednio dostosowuje oświetlenie piksela – jeśli ma być wypukłość to „zaciemnia” go. Minusem tej technologii jest czarno biała mapa mająca ogromne ograniczenia – nie obsługuje więcej niż jednego źródła światła i nie radzi sobie ze światłami padającymi pod kątem większym niż 45 stopni.
Normal Mapping
Technika należąca do kategorii bump mappingu jednak dająca znacznie lepsze rezultaty niż opisana powyżej. Dlatego ja, z uporem maniaka, nalegam zawsze by używać – dla porządku – właśnie tej nazwy, gdyż to tę technologię widzimy dzisiaj w grach. Na początek wyjaśnię o co chodzi z tym „normal”. Oczywiście nie chodzi tu o „normalny mapping” ale „mapping normali”. Otóż poligony mogą być renderowane tylko jednostronnie (jeśli wydaje się inaczej to znaczy, że zostały zduplikowane) i normale są wektorami, które tę stronę wskazują. Jednak tak naprawdę robią znacznie więcej. Określają kierunek zwrócenia poligonu.
W dzisiejszych czasach na każdy obiekt w grze przypadają dwa modele – wysoko i niskopoligonowy. W grze widzimy tylko ten drugi (obecnie do 25 tysięcy poligonów). Z pierwszego (ok. milion do 2 milionów poligonów) wypalana jest tekstura zwana normalmapą, która jest potem nakładana na model niskopoligonowy. Dzięki temu model niskopoligonowy jest cieniowany niemal dokładnie tak, jak high poly.
Ewolucja – odcinek pierwszy
Wyższość tej techniki nad bump mappingiem polega na tym, że bump nie manipuluje wyraźnie normalami na modelu. Ustawia jedynie wysokość danego piksela a i to idzie mu kiepsko. W uproszczeniu oznacza to, że może stworzyć wklęsłość jednak nie zmieni kąta nachylenia normalu danego piksela – będzie on zawsze pod kątem 90 stopni do poligonu. Jeśli spróbujemy więc zrobić delikatny stok jakiejś wypukłości to będzie on miał budowę schodkową. Efekt przypomina trochę krzywą bez antyaliasingu. Powodem jest czarno-biała mapa ustawiająca tylko wysokość. Normalmapy są kolorowe i dzięki temu można zawrzeć w nich dane na temat konkretnego ustawienia nowego normalu (kanały koloru oznaczające osie – czerwony = x, zielony = y, niebieski = z, zaś wartość koloru w każdym kanale wyznacza kierunek wektora). Dlatego też kiedy wypalona z wysokopoligonowego modelu normalmapa jest nakładana na niskopoligonowy model normale tego drugiego są usuwane i zastępowane danymi z nałożonej normalmapy. W efekcie każdy texel uzyskuje swój własny wektor normal taki sam, jak odpowiadający mu poligon na wysokopoligonowym modelu – dzięki temu uzyskujemy znacznie dokładniejsze cienie. Trochę to pogmatwane ale chodzi generalnie o to, żeby przemycić złudzenie większej ilości detali bez zwiększania ilości faktycznych poligonów w modelu i do tego normal mapping nadaje się idealnie.
Parallax Mapping
Inaczej zwany wirtualnym displacementem. Kolejne udoskonalenie technologii bumpów. Ponownie mamy tu do czynienia z czarno-białą mapą wysokości (stąd najlepiej smakuje z normal mappingiem i zwykle stosuje się obie te technologie na raz). Jednak tym razem manipulacja głębokością pikseli jest znacznie bardziej zaawansowana. Zależy bowiem od kąta patrzenia. W Bump i Normal mappingu kiedy spojrzymy pod małym kątem na np. ceglaną ścianę będzie ona wyraźnie płaska. Parallax bierze to pod uwagę i powiększa „wgłębienie” wraz ze spadkiem wartości kąta, pod którym kamera jest ustawiona do poligonu (to również jest obliczane z wykorzystaniem normali). Dzięki temu płaskość naszej ściany widać dopiero na jej krawędziach, podczas gdy cała płaszczyzna wydaje się mieć wyraźnie pofałdowaną strukturę.
Displacement Mapping
Ewolucja – odcinek drugi
Poprzednia technika nazywała się podobnie za wyjątkiem członu „wirtualny”. Brało się to stąd, że nie manipulowała samą geometrią a jedynie teksturą. Displacement wykorzystuje taką samą mapę wysokości jak parallax jednak zamiast manipulować kolorem pikseli dzieli każdy poligon na bardzo dużo mniejszych poligonów. Dzięki temu nasza ściana nawet na krawędziach ma cegły. Ta technologia ma swoją cenę – bije na głowę wymagania wszystkich poprzednich (razem wziętych) i to właśnie ona pozwala Altairowi mieć zaledwie 3 tysiące poligonów (Marcus Phoenix ma ich ponad 10 tysięcy) a mimo to wyglądać na milion. No i jest odpowiedzialna, przynajmniej częściowo, za wymagania Ass Creed. Poprzednie technologie zaliczają się do pixel shaderów, ten raczej do geometry shaderów.
Specular Mapping
Kolejny powszechny mapping. Nałożona na obiekt czarno-biała (najczęściej jednak stosuje się też np. niebieski kolor) mapa wyznacza poziom błyszczenia danego piksela.
Oczywiście istnieje jeszcze wiele innych mappingów jak choćby emissive maps (świecenie) jednak to, co opisałem jest rdzeniem wykorzystywanych w dzisiejszych grach shaderów. Poza tym istnieją też shadery bez map. Takim jest choćby subsurface scattering czyli technika używana najczęściej do uzyskiwania realistycznej skóry. Shadery są tym, co sprawia, że dzisiejsze gry wyglądają tak, jak wyglądają. W sumie gdyby nie one to nie było by widać większej różnicy pomiędzy grafiką dzisiejszych hitów i gier sprzed lat – może poza bardziej obłymi, z racji większej ilości poligonów, konturami. Jednak nadal byłyby to płaskie modele z nudnawym oświetleniem.
Ewolucja – odcinek trzeci
Technologie, które Wam dzisiaj opisałem są z pewnością trzonem dzisiejszych gier. No, silniki to trzon gier w ogóle i bez silnika żadna gra nie ma prawa powstać – nawet Flashowa. Bez shaderów zaś grafika z pewnością nie ruszyłaby się z miejsca, od czasów Max Payne. Do samego gliniarza z NY nic nie mam, ale chyba cieszymy się z tego, że gry wyglądają coraz lepiej. Narzekania na wymagania i t dlaczego wciąż rosną to oddzielny temat – choć w sumie shadery, a raczej ich nadużywanie, są tu jednym z winowajców. Wracając jednak do tematu – bez tych technologii dzisiejsza gra nie powstanie, ale do stworzenia jej potrzeba znacznie więcej narzędzi (że o pomysłach nie wspomnę) od edytorów tekstu poczynając, poprzez modelery grafiki 3D a na edytorach UML i narzędziach do planowania czy kontroli wersji kończąc.
Jak napisałem we wstępie, mało kto po „jasnej stronie mocy” interesuje się tym, co dzieje się wewnątrz gry. Mam nadzieję, że udało mi się zainteresować Was tym tematem i wyjaśnić w miarę przystępnie „nowomowę” developerską. Myślę, że teraz już nikt nie ma wątpliwości skąd biorą się kamyczki na Crysisowych plażach i dlaczego engine ma nikły wpływ na mechanikę. Oczywiście to tylko wierzchołek góry lodowej, ale być może, jeśli Siły Wyższe pozwolą, przedstawię też inne tematy. A wtedy Wikingowie hordą rzucą się na opensource’owe silniki i zaczną na potęgę tworzyć gry swoich marzeń….
ś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. . . .